From tom.schindl at bestsolution.at Fri Jun 1 02:04:09 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 01 Jun 2012 11:04:09 +0200 Subject: Patch: issue RT-14177 In-Reply-To: <4FC83568.6040400@oracle.com> References: <201204051750.13667.fbrunnerlist@gmx.ch> <201204061910.31029.fbrunnerlist@gmx.ch> <4F7F66F5.4070005@oracle.com> <201206010047.21361.fbrunnerlist@gmx.ch> <4FC802A7.1050309@oracle.com> <6F7D7400-DF4E-447E-90AD-D4F3F5ADFACB@oracle.com> <4FC83568.6040400@oracle.com> Message-ID: <4FC88589.6000207@bestsolution.at> Hi, I've uploaded a fixed version of the patch! I think Richards patch missed to catch the CNE for the context classloader. I can not comment on other areas of the control system - just did a short Class.forName-scan and can confirm you are finding about PopControl - it even has the same fix for RT-17525 so extracing the code and moveing it to a library makes sense. CSS might have similar problems (but in case of classloading but they are harder to fix because one has to infer the correct classloader from the CSS-URI or even the target they are applied to!). FXML has fixed all iusses (beside one small remaining issue I'm just discussing with Greg on this list) because it allows to pass custom classloaders and hence stuff loaded through FXML will directly profit from the Control enhancement. FXML is IMHO different to CSS/Controls because there's a defined lifecycle and so controlling the classloader there is much easier than it is in CSS/Control space where the classloader access is happening in an async fashion. I currently have no local build so I have to rely on Florian to give feedback if it fixes the problem. From a source introspection it looks good to me with my patch 5. Tom Am 01.06.12 05:22, schrieb Jonathan Giles: > +1 on the patch, although I do wonder whether we are being consistent in > the other places where classloading comes into play. Is this something > that should be extracted and used as an internal library? > > For example, there is much the same code in PopupControl that needs to > be fixed at the same time as the patch you are submitting here, but more > abstractly, should we have a library rather than duplicate similar code > in FXML and CSS as well? > > -- Jonathan > > > On 1/06/2012 3:14 p.m., Richard Bair wrote: >> Florian / Tom, >> >> I've uploaded two patches to the issue: >> rt-14177.2.patch >> rt-14177.3.patch >> >> The .3 patch is my preferred one. Can you take a look / apply it and >> see if it solves your issue? If the .3 patch works, then I think we've >> got a clean patch which will produce no additional performance >> overhead to a correctly functioning JavaFX application today, but will >> fix your issue (at least as Tom said in the issue itself for 95% of >> the folks). >> >> We can then file a new issue for the remaining 5% cases which will >> need more time (since it involves some form of new API) whereas in >> this case it should "just work". >> >> David / Jonathan, can you guys give a quick code review? I'm pretty >> sure the code does what I want it to do, and hopefully Florian / Tom >> will tell us if what I want it to do is actually the right thing to do >> (ie: solves the issue) :-). >> >> Thanks >> Richard >> >> On May 31, 2012, at 5:45 PM, Richard Bair wrote: >> >>> Hi Florian, >>> >>> We'll get this fixed ASAP. >>> >>> Thanks >>> Richard >>> >>> On May 31, 2012, at 4:45 PM, Kevin Rushforth wrote: >>> >>>> Hi Florian, >>>> >>>> This JIRA issue is targeted for 3.0 which is just in the initial >>>> planning stages, so no one has looked at it yet. >>>> >>>> The patch as attached to the issue deals with one case of CSS >>>> loading a skin, but when the controls team evaluated it, their take >>>> was that it a more general platform issue, although it could be >>>> dealt with in isolation. In any case, even if I were to assign this >>>> back to someone on the controls team, this code would need to be >>>> evaluated for potential bugs and to ensure that there are no >>>> security issues (probably not an issue, but since it would be using >>>> a system class loader we need to make sure it is never called from a >>>> privileged context), which is unlikely to happen for the current >>>> release. >>>> >>>> -- Kevin >>>> >>>> >>>> Florian Brunner wrote: >>>>> Hi Kevin, >>>>> >>>>> What is the status of my patch? >>>>> As mentioned in JIRA, this issue is becoming a blocker! Please >>>>> increase the priority! (Nobody from Oracle is responding on JIRA). >>>>> >>>>> Can we agree then to integrate the provided patch? It improves the >>>>> situation but doesn't introduce any API additions and we can >>>>> replace/ complete it later with other solutions if needed. >>>>> Please tell me if I should change something in the patch to get it >>>>> approved. >>>>> >>>>> Regards, >>>>> Florian >>>>> >>>>> Am Freitag 06 April 2012, 23:58:13 schrieb Kevin Rushforth: >>>>> >>>>>> I attached it to the JIRA issue. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Florian Brunner wrote: >>>>>> >>>>>>> Here the patch created with "hg diff --git" and zipped. >>>>>>> >>>>>>> Regards, >>>>>>> Florian >>>>>>> >>>>>>> Am Freitag 06 April 2012, 18:31:23 schrieb Kevin Rushforth: >>>>>>> >>>>>>>> Right. Since you didn't file the issue and are not the assignee, >>>>>>>> you can't add an attachment. >>>>>>>> >>>>>>>> Copying Brian Beck in case this is something we can (and want >>>>>>>> to) fix. >>>>>>>> >>>>>>>> In the mean time, you can e-mail me the patch and I'll attach it >>>>>>>> to the bug report. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> Florian Brunner wrote: >>>>>>>> >>>>>>>>> Hi Kevin, >>>>>>>>> >>>>>>>>> Thanks for your response. >>>>>>>>> >>>>>>>>> Unfortunatly, I don't see a way to attach something to the JIRA >>>>>>>>> issue. >>>>>>>>> >>>>>>>>> Either I'm missing something or maybe I need additional rights? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Florian >>>>>>>>> >>>>>>>>> Am Donnerstag 05 April 2012, 18:54:38 schrieben Sie: >>>>>>>>> >>>>>>>>>> Great. Please attach the patch as a zip file to the JIRA issue >>>>>>>>>> (preferably generated with either webrev or "hg diff --git") >>>>>>>>>> so that it can be evaluated. >>>>>>>>>> >>>>>>>>>> -- Kevin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Florian Brunner wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Let me introduce myself: my name is Florian Brunner and I'm a >>>>>>>>>>> Senior Software Engineer from Switzerland. >>>>>>>>>>> >>>>>>>>>>> I started to use JavaFX in an OSGi environment. Now I >>>>>>>>>>> stumbled over the following issue, which blocks me: >>>>>>>>>>> http://javafx-jira.kenai.com/browse/RT-14177 >>>>>>>>>>> >>>>>>>>>>> I have written a patch now. It probably doesn't solve the >>>>>>>>>>> whole issue, but at least it unblocks me for now. >>>>>>>>>>> >>>>>>>>>>> It would be great if you could integrate it. >>>>>>>>>>> >>>>>>>>>>> Note that I contributed to OpenJDK before (Swing) and have >>>>>>>>>>> signed the Sun Contributor Agreement: >>>>>>>>>>> >>>>>>>>>>> http://www.oracle.com/technetwork/community/oca-486395.html#b >>>>>>>>>>> Florian Brunner - java.net - puce >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Florian >>>>>>>>>>> >>>>> -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From kevin.rushforth at oracle.com Fri Jun 1 05:09:20 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 01 Jun 2012 05:09:20 -0700 Subject: Patch: issue RT-14177 In-Reply-To: <4FC83568.6040400@oracle.com> References: <201204051750.13667.fbrunnerlist@gmx.ch> <201204061910.31029.fbrunnerlist@gmx.ch> <4F7F66F5.4070005@oracle.com> <201206010047.21361.fbrunnerlist@gmx.ch> <4FC802A7.1050309@oracle.com> <6F7D7400-DF4E-447E-90AD-D4F3F5ADFACB@oracle.com> <4FC83568.6040400@oracle.com> Message-ID: <4FC8B0F0.6060709@oracle.com> > I do wonder whether we are being consistent in the other places where classloading comes into play. I know that was David's concern when he initially commented on it and reassigned it. In addition to other possible places in controls, has this been rationalized with the recent changes in behavior to FXML loading? Also, as a follow-on to the security concern I raised: given that it can't / shouldn't be run in a doPrivileged block, you will need to make sure that it doesn't blow up in the normal use case when run as an applet (as long as the original code is executed first and the new code is only done as a fallback in case that fails it should be fine). -- Kevin Jonathan Giles wrote: > +1 on the patch, although I do wonder whether we are being consistent > in the other places where classloading comes into play. Is this > something that should be extracted and used as an internal library? > > For example, there is much the same code in PopupControl that needs to > be fixed at the same time as the patch you are submitting here, but > more abstractly, should we have a library rather than duplicate > similar code in FXML and CSS as well? > > -- Jonathan > > > On 1/06/2012 3:14 p.m., Richard Bair wrote: >> Florian / Tom, >> >> I've uploaded two patches to the issue: >> rt-14177.2.patch >> rt-14177.3.patch >> >> The .3 patch is my preferred one. Can you take a look / apply it and >> see if it solves your issue? If the .3 patch works, then I think >> we've got a clean patch which will produce no additional performance >> overhead to a correctly functioning JavaFX application today, but >> will fix your issue (at least as Tom said in the issue itself for 95% >> of the folks). >> >> We can then file a new issue for the remaining 5% cases which will >> need more time (since it involves some form of new API) whereas in >> this case it should "just work". >> >> David / Jonathan, can you guys give a quick code review? I'm pretty >> sure the code does what I want it to do, and hopefully Florian / Tom >> will tell us if what I want it to do is actually the right thing to >> do (ie: solves the issue) :-). >> >> Thanks >> Richard >> >> On May 31, 2012, at 5:45 PM, Richard Bair wrote: >> >>> Hi Florian, >>> >>> We'll get this fixed ASAP. >>> >>> Thanks >>> Richard >>> >>> On May 31, 2012, at 4:45 PM, Kevin Rushforth wrote: >>> >>>> Hi Florian, >>>> >>>> This JIRA issue is targeted for 3.0 which is just in the initial >>>> planning stages, so no one has looked at it yet. >>>> >>>> The patch as attached to the issue deals with one case of CSS >>>> loading a skin, but when the controls team evaluated it, their take >>>> was that it a more general platform issue, although it could be >>>> dealt with in isolation. In any case, even if I were to assign this >>>> back to someone on the controls team, this code would need to be >>>> evaluated for potential bugs and to ensure that there are no >>>> security issues (probably not an issue, but since it would be using >>>> a system class loader we need to make sure it is never called from >>>> a privileged context), which is unlikely to happen for the current >>>> release. >>>> >>>> -- Kevin >>>> >>>> >>>> Florian Brunner wrote: >>>>> Hi Kevin, >>>>> >>>>> What is the status of my patch? >>>>> As mentioned in JIRA, this issue is becoming a blocker! Please >>>>> increase the priority! (Nobody from Oracle is responding on JIRA). >>>>> >>>>> Can we agree then to integrate the provided patch? It improves the >>>>> situation but doesn't introduce any API additions and we can >>>>> replace/ complete it later with other solutions if needed. >>>>> Please tell me if I should change something in the patch to get it >>>>> approved. >>>>> >>>>> Regards, >>>>> Florian >>>>> >>>>> Am Freitag 06 April 2012, 23:58:13 schrieb Kevin Rushforth: >>>>> >>>>>> I attached it to the JIRA issue. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Florian Brunner wrote: >>>>>> >>>>>>> Here the patch created with "hg diff --git" and zipped. >>>>>>> >>>>>>> Regards, >>>>>>> Florian >>>>>>> >>>>>>> Am Freitag 06 April 2012, 18:31:23 schrieb Kevin Rushforth: >>>>>>> >>>>>>>> Right. Since you didn't file the issue and are not the >>>>>>>> assignee, you can't add an attachment. >>>>>>>> >>>>>>>> Copying Brian Beck in case this is something we can (and want >>>>>>>> to) fix. >>>>>>>> >>>>>>>> In the mean time, you can e-mail me the patch and I'll attach >>>>>>>> it to the bug report. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> Florian Brunner wrote: >>>>>>>> >>>>>>>>> Hi Kevin, >>>>>>>>> >>>>>>>>> Thanks for your response. >>>>>>>>> >>>>>>>>> Unfortunatly, I don't see a way to attach something to the >>>>>>>>> JIRA issue. >>>>>>>>> >>>>>>>>> Either I'm missing something or maybe I need additional rights? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Florian >>>>>>>>> >>>>>>>>> Am Donnerstag 05 April 2012, 18:54:38 schrieben Sie: >>>>>>>>> >>>>>>>>>> Great. Please attach the patch as a zip file to the JIRA >>>>>>>>>> issue (preferably generated with either webrev or "hg diff >>>>>>>>>> --git") so that it can be evaluated. >>>>>>>>>> >>>>>>>>>> -- Kevin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Florian Brunner wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Let me introduce myself: my name is Florian Brunner and I'm >>>>>>>>>>> a Senior Software Engineer from Switzerland. >>>>>>>>>>> >>>>>>>>>>> I started to use JavaFX in an OSGi environment. Now I >>>>>>>>>>> stumbled over the following issue, which blocks me: >>>>>>>>>>> http://javafx-jira.kenai.com/browse/RT-14177 >>>>>>>>>>> >>>>>>>>>>> I have written a patch now. It probably doesn't solve the >>>>>>>>>>> whole issue, but at least it unblocks me for now. >>>>>>>>>>> >>>>>>>>>>> It would be great if you could integrate it. >>>>>>>>>>> >>>>>>>>>>> Note that I contributed to OpenJDK before (Swing) and have >>>>>>>>>>> signed the Sun Contributor Agreement: >>>>>>>>>>> >>>>>>>>>>> http://www.oracle.com/technetwork/community/oca-486395.html#b >>>>>>>>>>> Florian Brunner - java.net - puce >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Florian >>>>>>>>>>> >>>>> From hang.vo at oracle.com Fri Jun 1 06:02:32 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 01 Jun 2012 13:02:32 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-20528 : Button Mneumonic Parsing causes leak Message-ID: <20120601130235.22D2647680@hg.openjdk.java.net> Changeset: 3f7310d8b303 Author: mickf Date: 2012-06-01 13:52 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/3f7310d8b303 RT-20528 : Button Mneumonic Parsing causes leak ! javafx-ui-common/src/com/sun/javafx/scene/KeyboardShortcutsHandler.java + javafx-ui-common/test/unit/com/sun/javafx/scene/KeyboardShortcutsTest.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ButtonSkinTest.java From richard.bair at oracle.com Fri Jun 1 07:24:27 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 1 Jun 2012 07:24:27 -0700 Subject: LCD font smoothing in Text has no effect In-Reply-To: <009e01cd3fbc$c0a7b3f0$41f71bd0$@com.au> References: <007c01cd3fa7$bbdfff40$339ffdc0$@com.au> <4FC83C05.3040105@oracle.com> <008501cd3fad$cdb166e0$691434a0$@com.au> <4FC843B8.2040806@oracle.com> <008901cd3fb3$97cec9e0$c76c5da0$@com.au> <4FC8500E.4090403@oracle.com> <009e01cd3fbc$c0a7b3f0$41f71bd0$@com.au> Message-ID: Whoa, I found that surprising. Can you file a bug and we'll investigate. Thanks Richard On May 31, 2012, at 11:06 PM, John C. Turnbull wrote: > Hmm, works in a stand-alone application. Maybe it's a bug in Scene Builder? > > Thanks, > > -jct > > -----Original Message----- > From: Phil Race [mailto:philip.race at oracle.com] > Sent: Friday, 1 June 2012 15:16 > To: John C. Turnbull > Cc: openjfx-dev at openjdk.java.net > Subject: Re: LCD font smoothing in Text has no effect > > I think you should try this outside of scene builder first to eliminate > that. > If SceneBuilder is creating a shaped window and you are embedded in it then > you won't get LCD text. > > -phil. > > On 5/31/12 10:01 PM, John C. Turnbull wrote: >> All I am doing is placing a Text object on top of a filled Rectangle >> in Scene Builder b40. >> >> Cheers, >> >> -jct >> >> -----Original Message----- >> From: Phil Race [mailto:philip.race at oracle.com] >> Sent: Friday, 1 June 2012 14:23 >> To: John C. Turnbull >> Cc: openjfx-dev at openjdk.java.net >> Subject: Re: LCD font smoothing in Text has no effect >> >> So are you using a shaped window or transparency ? >> In those cases you may get grayscale. The most recent 2.2 builds will >> fix this IFF the transparency is not under the text pixels. >> >> -phil. >> >> On 5/31/12 9:19 PM, John C. Turnbull wrote: >>> Looks like I am getting Direct3D... >>> >>> Prism pipeline init order: d3d j2d >>> Using t2k for text rasterization >>> Using dirty region optimizations >>> Prism pipeline name = com.sun.prism.d3d.D3DPipeline Loading D3D >>> native library ... >>> succeeded. >>> Direct3D initialization succeeded >>> (X) Got class = class com.sun.prism.d3d.D3DPipeline Initialized prism >>> pipeline: com.sun.prism.d3d.D3DPipeline OS Information: >>> Windows 7 build 7601 >>> D3D Driver Information: >>> NVIDIA Quadro FX 5800 >>> \\.\DISPLAY1 >>> Driver nvd3dumx.dll, version 8.17.12.9635 >>> Pixel Shader version 3.0 >>> Device : ven_10DE, dev_05FD, subsys_059310DE >>> >>> ...but I still get greyscale antialiasing. >>> >>> Cheers, >>> >>> -jct >>> >>> -----Original Message----- >>> From: Phil Race [mailto:philip.race at oracle.com] >>> Sent: Friday, 1 June 2012 13:50 >>> To: John C. Turnbull >>> Cc: openjfx-dev at openjdk.java.net >>> Subject: Re: LCD font smoothing in Text has no effect >>> >>> -Dprism.verbose=true to see which renderer is used. >>> >>> Are you getting 2D or D3D/OGL ? >>> >>> 2D isn't set up to do it and we probably won't fix that because it >>> won't matter once we stop using it in 3.0 >>> >>> -phil. >>> >>> On 5/31/12 8:36 PM, John C. Turnbull wrote: >>>> I have never been able to see any difference when I set the font >>>> smoothing option to LCD in a Text control even with the latest >>>> JavaFX >>>> 2.2 drop. Gray scale antialiasing is still in use. >>>> >>>> >>>> >>>> Is this something likely to be fixed soon? >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> >>>> -jct >>>> > From jmartine_1026 at yahoo.com Fri Jun 1 07:37:04 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Fri, 1 Jun 2012 07:37:04 -0700 (PDT) Subject: problem with PathTransition causing flickering of its Node Message-ID: <1338561424.20028.YahooMailNeo@web160902.mail.bf1.yahoo.com> In the project (a video game) I am working on I use a lot of PathTransitions to move enemy units across the map. I am noticing flickering of the Nodes in the PathTransitions. By flickering I mean they lose and gain visibility. It does not happen all the time. The paths are pretty simple Shapes... straight lines. I am using Orthogonal orientation. here are some things I have noticed.... 1) There is an increase in flickering occurring when there is a lot happening on the screen. 2) There is an increase in flickering when the PathTransition's Node is moving over another Node. 3) Points 1 and 2 might be related or have the same root cause but its hard to tell. 4) If I change the rate of PathTransition to a low number (so that the Node is moving really slow) then the Node just becomes non-visible (cant see it on the screen) yet it is there because the projectiles in the game that are shooting the Nodes are in fact striking them, so you can tell that the Node is in fact moving along the path but just not visible. ?UPDATE: ?This also happens when moving at non-slow regular rate as I found out last night. 6) I do not suspect its a performance issue because when I do cause performance issues I get a studder not a flicker and the whole game slows up. While flickering the Node still moves smoothly through the path.? Currently the Node that I am using in this case is a Group with an ImageView and an invisible Rectangle in it. ? This Group is inside another which is inside another Group which is inside the root Scene. Any ideas what could be causing the flickering? thanks jose From tom.schindl at bestsolution.at Fri Jun 1 07:44:24 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 01 Jun 2012 16:44:24 +0200 Subject: Patch: issue RT-14177 In-Reply-To: <201206011638.06564.fbrunner@gmx.ch> References: <201204051750.13667.fbrunnerlist@gmx.ch> <4FC83568.6040400@oracle.com> <4FC88589.6000207@bestsolution.at> <201206011638.06564.fbrunner@gmx.ch> Message-ID: <4FC8D548.8040901@bestsolution.at> Hi Florian, Good. I can you tell me why the super-type loop is used - I think it was already in your first patch - wondering what this is good for. Tom Am 01.06.12 16:38, schrieb Florian Brunner: > I tested rt-14177.3.patch and Tom is right, the ClassNotFoundException has to be catched otherwise the new code won't be executed. > > Unfortunatly, hg import failed for 5.patch for some reason. > > I created and tested a new patch (with "hg diff --git" as recommended by Kevin (see attachements, I don't have the necessary rights in JIRA). > > It works fine for my use case. > > I also renamed ex2 to ex3 and ex3 to ex2 and fixed some formatting issues. > > Note however that now the method contains around 100 lines of code. You might want to refactor it into several smaller methods for maintainability reasons. > > Regards, > Florian > > > Am Freitag 01 Juni 2012, 11:04:09 schrieb Tom Schindl: >> Hi, >> >> I've uploaded a fixed version of the patch! I think Richards patch >> missed to catch the CNE for the context classloader. >> >> I can not comment on other areas of the control system - just did a >> short Class.forName-scan and can confirm you are finding about >> PopControl - it even has the same fix for RT-17525 so extracing the code >> and moveing it to a library makes sense. >> >> CSS might have similar problems (but in case of classloading but they >> are harder to fix because one has to infer the correct classloader from >> the CSS-URI or even the target they are applied to!). >> >> FXML has fixed all iusses (beside one small remaining issue I'm just >> discussing with Greg on this list) because it allows to pass custom >> classloaders and hence stuff loaded through FXML will directly profit >> from the Control enhancement. >> >> FXML is IMHO different to CSS/Controls because there's a defined >> lifecycle and so controlling the classloader there is much easier than >> it is in CSS/Control space where the classloader access is happening in >> an async fashion. >> >> I currently have no local build so I have to rely on Florian to give >> feedback if it fixes the problem. From a source introspection it looks >> good to me with my patch 5. >> >> Tom >> >> Am 01.06.12 05:22, schrieb Jonathan Giles: >>> +1 on the patch, although I do wonder whether we are being consistent in >>> the other places where classloading comes into play. Is this something >>> that should be extracted and used as an internal library? >>> >>> For example, there is much the same code in PopupControl that needs to >>> be fixed at the same time as the patch you are submitting here, but more >>> abstractly, should we have a library rather than duplicate similar code >>> in FXML and CSS as well? >>> >>> -- Jonathan >>> >>> >>> On 1/06/2012 3:14 p.m., Richard Bair wrote: >>>> Florian / Tom, >>>> >>>> I've uploaded two patches to the issue: >>>> rt-14177.2.patch >>>> rt-14177.3.patch >>>> >>>> The .3 patch is my preferred one. Can you take a look / apply it and >>>> see if it solves your issue? If the .3 patch works, then I think we've >>>> got a clean patch which will produce no additional performance >>>> overhead to a correctly functioning JavaFX application today, but will >>>> fix your issue (at least as Tom said in the issue itself for 95% of >>>> the folks). >>>> >>>> We can then file a new issue for the remaining 5% cases which will >>>> need more time (since it involves some form of new API) whereas in >>>> this case it should "just work". >>>> >>>> David / Jonathan, can you guys give a quick code review? I'm pretty >>>> sure the code does what I want it to do, and hopefully Florian / Tom >>>> will tell us if what I want it to do is actually the right thing to do >>>> (ie: solves the issue) :-). >>>> >>>> Thanks >>>> Richard >>>> >>>> On May 31, 2012, at 5:45 PM, Richard Bair wrote: >>>> >>>>> Hi Florian, >>>>> >>>>> We'll get this fixed ASAP. >>>>> >>>>> Thanks >>>>> Richard >>>>> >>>>> On May 31, 2012, at 4:45 PM, Kevin Rushforth wrote: >>>>> >>>>>> Hi Florian, >>>>>> >>>>>> This JIRA issue is targeted for 3.0 which is just in the initial >>>>>> planning stages, so no one has looked at it yet. >>>>>> >>>>>> The patch as attached to the issue deals with one case of CSS >>>>>> loading a skin, but when the controls team evaluated it, their take >>>>>> was that it a more general platform issue, although it could be >>>>>> dealt with in isolation. In any case, even if I were to assign this >>>>>> back to someone on the controls team, this code would need to be >>>>>> evaluated for potential bugs and to ensure that there are no >>>>>> security issues (probably not an issue, but since it would be using >>>>>> a system class loader we need to make sure it is never called from a >>>>>> privileged context), which is unlikely to happen for the current >>>>>> release. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Florian Brunner wrote: >>>>>>> Hi Kevin, >>>>>>> >>>>>>> What is the status of my patch? >>>>>>> As mentioned in JIRA, this issue is becoming a blocker! Please >>>>>>> increase the priority! (Nobody from Oracle is responding on JIRA). >>>>>>> >>>>>>> Can we agree then to integrate the provided patch? It improves the >>>>>>> situation but doesn't introduce any API additions and we can >>>>>>> replace/ complete it later with other solutions if needed. >>>>>>> Please tell me if I should change something in the patch to get it >>>>>>> approved. >>>>>>> >>>>>>> Regards, >>>>>>> Florian >>>>>>> >>>>>>> Am Freitag 06 April 2012, 23:58:13 schrieb Kevin Rushforth: >>>>>>> >>>>>>>> I attached it to the JIRA issue. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> Florian Brunner wrote: >>>>>>>> >>>>>>>>> Here the patch created with "hg diff --git" and zipped. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Florian >>>>>>>>> >>>>>>>>> Am Freitag 06 April 2012, 18:31:23 schrieb Kevin Rushforth: >>>>>>>>> >>>>>>>>>> Right. Since you didn't file the issue and are not the assignee, >>>>>>>>>> you can't add an attachment. >>>>>>>>>> >>>>>>>>>> Copying Brian Beck in case this is something we can (and want >>>>>>>>>> to) fix. >>>>>>>>>> >>>>>>>>>> In the mean time, you can e-mail me the patch and I'll attach it >>>>>>>>>> to the bug report. >>>>>>>>>> >>>>>>>>>> -- Kevin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Florian Brunner wrote: >>>>>>>>>> >>>>>>>>>>> Hi Kevin, >>>>>>>>>>> >>>>>>>>>>> Thanks for your response. >>>>>>>>>>> >>>>>>>>>>> Unfortunatly, I don't see a way to attach something to the JIRA >>>>>>>>>>> issue. >>>>>>>>>>> >>>>>>>>>>> Either I'm missing something or maybe I need additional rights? >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Florian >>>>>>>>>>> >>>>>>>>>>> Am Donnerstag 05 April 2012, 18:54:38 schrieben Sie: >>>>>>>>>>> >>>>>>>>>>>> Great. Please attach the patch as a zip file to the JIRA issue >>>>>>>>>>>> (preferably generated with either webrev or "hg diff --git") >>>>>>>>>>>> so that it can be evaluated. >>>>>>>>>>>> >>>>>>>>>>>> -- Kevin >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Florian Brunner wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Let me introduce myself: my name is Florian Brunner and I'm a >>>>>>>>>>>>> Senior Software Engineer from Switzerland. >>>>>>>>>>>>> >>>>>>>>>>>>> I started to use JavaFX in an OSGi environment. Now I >>>>>>>>>>>>> stumbled over the following issue, which blocks me: >>>>>>>>>>>>> http://javafx-jira.kenai.com/browse/RT-14177 >>>>>>>>>>>>> >>>>>>>>>>>>> I have written a patch now. It probably doesn't solve the >>>>>>>>>>>>> whole issue, but at least it unblocks me for now. >>>>>>>>>>>>> >>>>>>>>>>>>> It would be great if you could integrate it. >>>>>>>>>>>>> >>>>>>>>>>>>> Note that I contributed to OpenJDK before (Swing) and have >>>>>>>>>>>>> signed the Sun Contributor Agreement: >>>>>>>>>>>>> >>>>>>>>>>>>> http://www.oracle.com/technetwork/community/oca-486395.html#b >>>>>>>>>>>>> Florian Brunner - java.net - puce >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Florian >>>>>>>>>>>>> >>>>>>> >> >> >> -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From kevin.rushforth at oracle.com Fri Jun 1 07:53:30 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 01 Jun 2012 07:53:30 -0700 Subject: problem with PathTransition causing flickering of its Node In-Reply-To: <1338561424.20028.YahooMailNeo@web160902.mail.bf1.yahoo.com> References: <1338561424.20028.YahooMailNeo@web160902.mail.bf1.yahoo.com> Message-ID: <4FC8D76A.2030702@oracle.com> One thing to try: can you run it with "-Dprism.dirtyopts=false" and see if the problem persists? In any case, please file a JIRA bug against the "Animation" component. -- Kevin Jose Martinez wrote: > In the project (a video game) I am working on I use a lot of PathTransitions to move enemy units across the map. I am noticing flickering of the Nodes in the PathTransitions. By flickering I mean they lose and gain visibility. It does not happen all the time. The paths are pretty simple Shapes... straight lines. I am using Orthogonal orientation. > > here are some things I have noticed.... > > 1) There is an increase in flickering occurring when there is a lot happening on the screen. > 2) There is an increase in flickering when the PathTransition's Node is moving over another Node. > 3) Points 1 and 2 might be related or have the same root cause but its hard to tell. > 4) If I change the rate of PathTransition to a low number (so that the Node is moving really slow) then the Node just becomes non-visible (cant see it on the screen) yet it is there because the projectiles in the game that are shooting the Nodes are in fact striking them, so you can tell that the Node is in fact moving along the path but just not visible. UPDATE: This also happens when moving at non-slow regular rate as I found out last night. > 6) I do not suspect its a performance issue because when I do cause performance issues I get a studder not a flicker and the whole game slows up. While flickering the Node still moves smoothly through the path. > > Currently the Node that I am using in this case is a Group with an ImageView and an invisible Rectangle in it. This Group is inside another which is inside another Group which is inside the root Scene. > > Any ideas what could be causing the flickering? > > thanks > jose > From jmartine_1026 at yahoo.com Fri Jun 1 08:05:23 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Fri, 1 Jun 2012 08:05:23 -0700 (PDT) Subject: problem with PathTransition causing flickering of its Node In-Reply-To: <4FC8D76A.2030702@oracle.com> References: <1338561424.20028.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FC8D76A.2030702@oracle.com> Message-ID: <1338563123.55283.YahooMailNeo@web160904.mail.bf1.yahoo.com> Kevin, Thanks for the quick response. ?I just tested that out and it still occurs. ?I'll run some more tests to verify if the rate of occurrence of it has changed. ?Just to be sure I did this right let me confirm... in Netbeans I added that argument to the VM options and it showed up in the JNLP file in the value of java-vm-args. ? jose ________________________________ From: Kevin Rushforth To: Jose Martinez Cc: openjfx mailing list Sent: Friday, June 1, 2012 10:53 AM Subject: Re: problem with PathTransition causing flickering of its Node One thing to try: can you run it with "-Dprism.dirtyopts=false" and see if the problem persists? In any case, please file a JIRA bug against the "Animation" component. -- Kevin Jose Martinez wrote: > In the project (a video game) I am working on I use a lot of PathTransitions to move enemy units across the map. I am noticing flickering of the Nodes in the PathTransitions. By flickering I mean they lose and gain visibility. It does not happen all the time. The paths are pretty simple Shapes... straight lines. I am using Orthogonal orientation. > > here are some things I have noticed.... > > 1) There is an increase in flickering occurring when there is a lot happening on the screen. > 2) There is an increase in flickering when the PathTransition's Node is moving over another Node. > 3) Points 1 and 2 might be related or have the same root cause but its hard to tell. > 4) If I change the rate of PathTransition to a low number (so that the Node is moving really slow) then the Node just becomes non-visible (cant see it on the screen) yet it is there because the projectiles in the game that are shooting the Nodes are in fact striking them, so you can tell that the Node is in fact moving along the path but just not visible.? UPDATE:? This also happens when moving at non-slow regular rate as I found out last night. > 6) I do not suspect its a performance issue because when I do cause performance issues I get a studder not a flicker and the whole game slows up. While flickering the Node still moves smoothly through the path. > > Currently the Node that I am using in this case is a Group with an ImageView and an invisible Rectangle in it.? This Group is inside another which is inside another Group which is inside the root Scene. > > Any ideas what could be causing the flickering? > > thanks > jose >? From joseph.andresen at oracle.com Fri Jun 1 08:05:57 2012 From: joseph.andresen at oracle.com (Joseph Andresen) Date: Fri, 1 Jun 2012 08:05:57 -0700 Subject: problem with PathTransition causing flickering of its Node In-Reply-To: <4FC8D76A.2030702@oracle.com> References: <1338561424.20028.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FC8D76A.2030702@oracle.com> Message-ID: Can you describe the state of the scene? Are you using a perspective camera? On Jun 1, 2012, at 7:53 AM, Kevin Rushforth wrote: > One thing to try: can you run it with "-Dprism.dirtyopts=false" and see if the problem persists? > > In any case, please file a JIRA bug against the "Animation" component. > > -- Kevin > > > Jose Martinez wrote: >> In the project (a video game) I am working on I use a lot of PathTransitions to move enemy units across the map. I am noticing flickering of the Nodes in the PathTransitions. By flickering I mean they lose and gain visibility. It does not happen all the time. The paths are pretty simple Shapes... straight lines. I am using Orthogonal orientation. >> >> here are some things I have noticed.... >> >> 1) There is an increase in flickering occurring when there is a lot happening on the screen. >> 2) There is an increase in flickering when the PathTransition's Node is moving over another Node. >> 3) Points 1 and 2 might be related or have the same root cause but its hard to tell. >> 4) If I change the rate of PathTransition to a low number (so that the Node is moving really slow) then the Node just becomes non-visible (cant see it on the screen) yet it is there because the projectiles in the game that are shooting the Nodes are in fact striking them, so you can tell that the Node is in fact moving along the path but just not visible. UPDATE: This also happens when moving at non-slow regular rate as I found out last night. >> 6) I do not suspect its a performance issue because when I do cause performance issues I get a studder not a flicker and the whole game slows up. While flickering the Node still moves smoothly through the path. >> Currently the Node that I am using in this case is a Group with an ImageView and an invisible Rectangle in it. This Group is inside another which is inside another Group which is inside the root Scene. >> >> Any ideas what could be causing the flickering? >> >> thanks >> jose >> From fbrunnerlist at gmx.ch Fri Jun 1 08:02:04 2012 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Fri, 1 Jun 2012 17:02:04 +0200 Subject: Patch: issue RT-14177 In-Reply-To: <4FC88589.6000207@bestsolution.at> References: <201204051750.13667.fbrunnerlist@gmx.ch> <4FC83568.6040400@oracle.com> <4FC88589.6000207@bestsolution.at> Message-ID: <201206011702.04973.fbrunnerlist@gmx.ch> --Boundary-00=_slNyPHOCAYe/RZk Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I tested rt-14177.3.patch and Tom is right, the ClassNotFoundException has to be catched otherwise the new code won't be executed. Unfortunatly, hg import failed for 5.patch for some reason. I created and tested a new patch (with "hg diff --git" as recommended by Kevin; see attachements, I don't have the necessary rights in JIRA). It works fine for my use case. I also renamed ex2 to ex3 and ex3 to ex2 and fixed some formatting issues. Note however that now the method contains around 100 lines of code. You might want to refactor it into several smaller methods for maintainability reasons. Regards, Florian Am Freitag 01 Juni 2012, 11:04:09 schrieb Tom Schindl: > Hi, > > I've uploaded a fixed version of the patch! I think Richards patch > missed to catch the CNE for the context classloader. > > I can not comment on other areas of the control system - just did a > short Class.forName-scan and can confirm you are finding about > PopControl - it even has the same fix for RT-17525 so extracing the code > and moveing it to a library makes sense. > > CSS might have similar problems (but in case of classloading but they > are harder to fix because one has to infer the correct classloader from > the CSS-URI or even the target they are applied to!). > > FXML has fixed all iusses (beside one small remaining issue I'm just > discussing with Greg on this list) because it allows to pass custom > classloaders and hence stuff loaded through FXML will directly profit > from the Control enhancement. > > FXML is IMHO different to CSS/Controls because there's a defined > lifecycle and so controlling the classloader there is much easier than > it is in CSS/Control space where the classloader access is happening in > an async fashion. > > I currently have no local build so I have to rely on Florian to give > feedback if it fixes the problem. From a source introspection it looks > good to me with my patch 5. > > Tom > > Am 01.06.12 05:22, schrieb Jonathan Giles: > > +1 on the patch, although I do wonder whether we are being consistent in > > the other places where classloading comes into play. Is this something > > that should be extracted and used as an internal library? > > > > For example, there is much the same code in PopupControl that needs to > > be fixed at the same time as the patch you are submitting here, but more > > abstractly, should we have a library rather than duplicate similar code > > in FXML and CSS as well? > > > > -- Jonathan > > > > > > On 1/06/2012 3:14 p.m., Richard Bair wrote: > >> Florian / Tom, > >> > >> I've uploaded two patches to the issue: > >> rt-14177.2.patch > >> rt-14177.3.patch > >> > >> The .3 patch is my preferred one. Can you take a look / apply it and > >> see if it solves your issue? If the .3 patch works, then I think we've > >> got a clean patch which will produce no additional performance > >> overhead to a correctly functioning JavaFX application today, but will > >> fix your issue (at least as Tom said in the issue itself for 95% of > >> the folks). > >> > >> We can then file a new issue for the remaining 5% cases which will > >> need more time (since it involves some form of new API) whereas in > >> this case it should "just work". > >> > >> David / Jonathan, can you guys give a quick code review? I'm pretty > >> sure the code does what I want it to do, and hopefully Florian / Tom > >> will tell us if what I want it to do is actually the right thing to do > >> (ie: solves the issue) :-). > >> > >> Thanks > >> Richard > >> > >> On May 31, 2012, at 5:45 PM, Richard Bair wrote: > >> > >>> Hi Florian, > >>> > >>> We'll get this fixed ASAP. > >>> > >>> Thanks > >>> Richard > >>> > >>> On May 31, 2012, at 4:45 PM, Kevin Rushforth wrote: > >>> > >>>> Hi Florian, > >>>> > >>>> This JIRA issue is targeted for 3.0 which is just in the initial > >>>> planning stages, so no one has looked at it yet. > >>>> > >>>> The patch as attached to the issue deals with one case of CSS > >>>> loading a skin, but when the controls team evaluated it, their take > >>>> was that it a more general platform issue, although it could be > >>>> dealt with in isolation. In any case, even if I were to assign this > >>>> back to someone on the controls team, this code would need to be > >>>> evaluated for potential bugs and to ensure that there are no > >>>> security issues (probably not an issue, but since it would be using > >>>> a system class loader we need to make sure it is never called from a > >>>> privileged context), which is unlikely to happen for the current > >>>> release. > >>>> > >>>> -- Kevin > >>>> > >>>> > >>>> Florian Brunner wrote: > >>>>> Hi Kevin, > >>>>> > >>>>> What is the status of my patch? > >>>>> As mentioned in JIRA, this issue is becoming a blocker! Please > >>>>> increase the priority! (Nobody from Oracle is responding on JIRA). > >>>>> > >>>>> Can we agree then to integrate the provided patch? It improves the > >>>>> situation but doesn't introduce any API additions and we can > >>>>> replace/ complete it later with other solutions if needed. > >>>>> Please tell me if I should change something in the patch to get it > >>>>> approved. > >>>>> > >>>>> Regards, > >>>>> Florian > >>>>> > >>>>> Am Freitag 06 April 2012, 23:58:13 schrieb Kevin Rushforth: > >>>>> > >>>>>> I attached it to the JIRA issue. > >>>>>> > >>>>>> -- Kevin > >>>>>> > >>>>>> > >>>>>> Florian Brunner wrote: > >>>>>> > >>>>>>> Here the patch created with "hg diff --git" and zipped. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Florian > >>>>>>> > >>>>>>> Am Freitag 06 April 2012, 18:31:23 schrieb Kevin Rushforth: > >>>>>>> > >>>>>>>> Right. Since you didn't file the issue and are not the assignee, > >>>>>>>> you can't add an attachment. > >>>>>>>> > >>>>>>>> Copying Brian Beck in case this is something we can (and want > >>>>>>>> to) fix. > >>>>>>>> > >>>>>>>> In the mean time, you can e-mail me the patch and I'll attach it > >>>>>>>> to the bug report. > >>>>>>>> > >>>>>>>> -- Kevin > >>>>>>>> > >>>>>>>> > >>>>>>>> Florian Brunner wrote: > >>>>>>>> > >>>>>>>>> Hi Kevin, > >>>>>>>>> > >>>>>>>>> Thanks for your response. > >>>>>>>>> > >>>>>>>>> Unfortunatly, I don't see a way to attach something to the JIRA > >>>>>>>>> issue. > >>>>>>>>> > >>>>>>>>> Either I'm missing something or maybe I need additional rights? > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Florian > >>>>>>>>> > >>>>>>>>> Am Donnerstag 05 April 2012, 18:54:38 schrieben Sie: > >>>>>>>>> > >>>>>>>>>> Great. Please attach the patch as a zip file to the JIRA issue > >>>>>>>>>> (preferably generated with either webrev or "hg diff --git") > >>>>>>>>>> so that it can be evaluated. > >>>>>>>>>> > >>>>>>>>>> -- Kevin > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Florian Brunner wrote: > >>>>>>>>>> > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> Let me introduce myself: my name is Florian Brunner and I'm a > >>>>>>>>>>> Senior Software Engineer from Switzerland. > >>>>>>>>>>> > >>>>>>>>>>> I started to use JavaFX in an OSGi environment. Now I > >>>>>>>>>>> stumbled over the following issue, which blocks me: > >>>>>>>>>>> http://javafx-jira.kenai.com/browse/RT-14177 > >>>>>>>>>>> > >>>>>>>>>>> I have written a patch now. It probably doesn't solve the > >>>>>>>>>>> whole issue, but at least it unblocks me for now. > >>>>>>>>>>> > >>>>>>>>>>> It would be great if you could integrate it. > >>>>>>>>>>> > >>>>>>>>>>> Note that I contributed to OpenJDK before (Swing) and have > >>>>>>>>>>> signed the Sun Contributor Agreement: > >>>>>>>>>>> > >>>>>>>>>>> http://www.oracle.com/technetwork/community/oca-486395.html#b > >>>>>>>>>>> Florian Brunner - java.net - puce > >>>>>>>>>>> > >>>>>>>>>>> Regards, > >>>>>>>>>>> Florian > >>>>>>>>>>> > >>>>> > > > --Boundary-00=_slNyPHOCAYe/RZk Content-Type: application/zip; name="rt-14177.6.patch.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rt-14177.6.patch.zip" UEsDBBQAAAAIAIh9wUABypVawAIAAGsLAAAQABwAcnQtMTQxNzcuNi5wYXRjaFVUCQADL8fIT2bH yE91eAsAAQToAwAABGQAAACtlsty2jAUhvd+itNNCgHbIWlCLk3LTKadLjpdlHS6FvYxdqJIjCwH mA7vXl0MGCMDuZwF2LL0n9sn2XGWJOD740wCCR/IM0lmfpH5EWdScJqHuYjK4TCPkGFYPgnv7H+g H8Lo1Us93/ff4NnrdDpv8T4YgH91cdntnUNH/59dwWDgwdIW68v1lRRz+Of5ULE7SvL889cvkD9m zNzcbE4IQ/h97/f656fncA1/cgQdDs4kRHo2UE5iFMAZnUOWWL0g4eIXeUJISEbzwOvs9gi3wApK bzbnJRkjFIZSZGxsfRnJ2/U6fR+MUbbaN151pStPbVWHG3G2HJLtWh0WEBEZpdCy87j8zgsWf5tF OJEZZypChm2XV1WU1n0qkMRBVAiBTNq7Vls7urPFNKI/TSlbbfhgC+KUqyfyMulAt8uMHJKzzRup anpDJDIVfGpyr3VPm0LnXnXiocilwUQ3UqZom7k9vbk9q+63a172NQVnuoZbniwfW8NlzO+L+9I0 BpUMbYfh6OiFDayy4fRTr+Q78+H0udge3t+ZU2cKDiknWLpJn3r9/rVBjHL+qOkqJmvAoMg3gFu1 LtFjTtG1leWyK7swJbSqTzNFtNLJiwkKMwUdPG8IEhZDlGJkZJCoytg4nrowQsUPwkjBox/qmSb0 PYomMQebDv6c7DUStDqgl8zMJ/rY1cQYMJoomKYZxQbIq1KHELxjhy6tCnlFPljG6UC68Ryp2n5y z3aGrm2zcrXohitqGktp4jh8rx24Z/7aEwpjkFy/XuOtzULYvOQSyIg/IzwhYYr/nMMUPypIx7wJ TCVpDnr7RtAKDfWTKZFKTVW5GKdS7QVBMxRvhda6xVntS8CWZ9et+ZDqnZz1u5fQ6Z1c9LoX5kPK W062L77y12Z7/H5WBnPsyulVtlYcyjnFYYoo4Yc6VMzh8jrF/1BLAQIeAxQAAAAIAIh9wUABypVa wAIAAGsLAAAQABgAAAAAAAEAAACkgQAAAABydC0xNDE3Ny42LnBhdGNoVVQFAAMvx8hPdXgLAAEE 6AMAAARkAAAAUEsFBgAAAAABAAEAVgAAAAoDAAAAAA== --Boundary-00=_slNyPHOCAYe/RZk-- From steve.x.northover at oracle.com Fri Jun 1 08:09:22 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Fri, 01 Jun 2012 11:09:22 -0400 Subject: problem with PathTransition causing flickering of its Node In-Reply-To: References: <1338561424.20028.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FC8D76A.2030702@oracle.com> Message-ID: <4FC8DB22.2040704@oracle.com> First off, what platform are you on? Second can you create a simple example that flickers and either post it here or enter a JIRA? Thanks! Steve On 01/06/2012 11:05 AM, Joseph Andresen wrote: > Can you describe the state of the scene? Are you using a perspective camera? > > > > On Jun 1, 2012, at 7:53 AM, Kevin Rushforth wrote: > >> One thing to try: can you run it with "-Dprism.dirtyopts=false" and see if the problem persists? >> >> In any case, please file a JIRA bug against the "Animation" component. >> >> -- Kevin >> >> >> Jose Martinez wrote: >>> In the project (a video game) I am working on I use a lot of PathTransitions to move enemy units across the map. I am noticing flickering of the Nodes in the PathTransitions. By flickering I mean they lose and gain visibility. It does not happen all the time. The paths are pretty simple Shapes... straight lines. I am using Orthogonal orientation. >>> >>> here are some things I have noticed.... >>> >>> 1) There is an increase in flickering occurring when there is a lot happening on the screen. >>> 2) There is an increase in flickering when the PathTransition's Node is moving over another Node. >>> 3) Points 1 and 2 might be related or have the same root cause but its hard to tell. >>> 4) If I change the rate of PathTransition to a low number (so that the Node is moving really slow) then the Node just becomes non-visible (cant see it on the screen) yet it is there because the projectiles in the game that are shooting the Nodes are in fact striking them, so you can tell that the Node is in fact moving along the path but just not visible. UPDATE: This also happens when moving at non-slow regular rate as I found out last night. >>> 6) I do not suspect its a performance issue because when I do cause performance issues I get a studder not a flicker and the whole game slows up. While flickering the Node still moves smoothly through the path. >>> Currently the Node that I am using in this case is a Group with an ImageView and an invisible Rectangle in it. This Group is inside another which is inside another Group which is inside the root Scene. >>> >>> Any ideas what could be causing the flickering? >>> >>> thanks >>> jose >>> From kevin.rushforth at oracle.com Fri Jun 1 08:14:39 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 01 Jun 2012 08:14:39 -0700 Subject: problem with PathTransition causing flickering of its Node In-Reply-To: <1338563123.55283.YahooMailNeo@web160904.mail.bf1.yahoo.com> References: <1338561424.20028.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FC8D76A.2030702@oracle.com> <1338563123.55283.YahooMailNeo@web160904.mail.bf1.yahoo.com> Message-ID: <4FC8DC5F.9020603@oracle.com> Yes, adding it to vm args is correct. -- Kevin Jose Martinez wrote: > Kevin, > > Thanks for the quick response. I just tested that out and it still > occurs. I'll run some more tests to verify if the rate of occurrence > of it has changed. Just to be sure I did this right let me confirm... > in Netbeans I added that argument to the VM options and it showed up > in the JNLP file in the value of java-vm-args. > > > jose > ------------------------------------------------------------------------ > *From:* Kevin Rushforth > *To:* Jose Martinez > *Cc:* openjfx mailing list > *Sent:* Friday, June 1, 2012 10:53 AM > *Subject:* Re: problem with PathTransition causing flickering of its Node > > One thing to try: can you run it with "-Dprism.dirtyopts=false" and see > if the problem persists? > > In any case, please file a JIRA bug against the "Animation" component. > > -- Kevin > > > Jose Martinez wrote: > > In the project (a video game) I am working on I use a lot of > PathTransitions to move enemy units across the map. I am noticing > flickering of the Nodes in the PathTransitions. By flickering I mean > they lose and gain visibility. It does not happen all the time. The > paths are pretty simple Shapes... straight lines. I am using > Orthogonal orientation. > > > > here are some things I have noticed.... > > > > 1) There is an increase in flickering occurring when there is a lot > happening on the screen. > > 2) There is an increase in flickering when the PathTransition's Node > is moving over another Node. > > 3) Points 1 and 2 might be related or have the same root cause but > its hard to tell. > > 4) If I change the rate of PathTransition to a low number (so that > the Node is moving really slow) then the Node just becomes non-visible > (cant see it on the screen) yet it is there because the projectiles in > the game that are shooting the Nodes are in fact striking them, so you > can tell that the Node is in fact moving along the path but just not > visible. UPDATE: This also happens when moving at non-slow regular > rate as I found out last night. > > 6) I do not suspect its a performance issue because when I do cause > performance issues I get a studder not a flicker and the whole game > slows up. While flickering the Node still moves smoothly through the > path. > > > > Currently the Node that I am using in this case is a Group with an > ImageView and an invisible Rectangle in it. This Group is inside > another which is inside another Group which is inside the root Scene. > > > > Any ideas what could be causing the flickering? > > > > thanks > > jose > > > > From jmartine_1026 at yahoo.com Fri Jun 1 08:15:22 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Fri, 1 Jun 2012 08:15:22 -0700 (PDT) Subject: problem with PathTransition causing flickering of its Node In-Reply-To: References: <1338561424.20028.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FC8D76A.2030702@oracle.com> Message-ID: <1338563722.35286.YahooMailNeo@web160904.mail.bf1.yahoo.com> Joseph, I leave the Scene alone, so what ever it has as default is what it is using ? ? ? ? primaryStage.setScene(new Scene(root, WIDTH, HEIGHT)); ? ? ? ? primaryStage.setResizable(false); ? ? ? ? primaryStage.show(); where "root" is: ? ? private static Group root = new Group(); I then add to "root" another Group that I call "round", which has another Group called "enemyUnits", and in there is where the Nodes with their PathTransition are located. ? jose ________________________________ From: Joseph Andresen To: Kevin Rushforth Cc: Jose Martinez ; openjfx mailing list Sent: Friday, June 1, 2012 11:05 AM Subject: Re: problem with PathTransition causing flickering of its Node Can you describe the state of the scene? Are you using a perspective camera? On Jun 1, 2012, at 7:53 AM, Kevin Rushforth wrote: > One thing to try: can you run it with "-Dprism.dirtyopts=false" and see if the problem persists? > > In any case, please file a JIRA bug against the "Animation" component. > > -- Kevin > > > Jose Martinez wrote: >> In the project (a video game) I am working on I use a lot of PathTransitions to move enemy units across the map. I am noticing flickering of the Nodes in the PathTransitions. By flickering I mean they lose and gain visibility. It does not happen all the time. The paths are pretty simple Shapes... straight lines. I am using Orthogonal orientation. >> >> here are some things I have noticed.... >> >> 1) There is an increase in flickering occurring when there is a lot happening on the screen. >> 2) There is an increase in flickering when the PathTransition's Node is moving over another Node. >> 3) Points 1 and 2 might be related or have the same root cause but its hard to tell. >> 4) If I change the rate of PathTransition to a low number (so that the Node is moving really slow) then the Node just becomes non-visible (cant see it on the screen) yet it is there because the projectiles in the game that are shooting the Nodes are in fact striking them, so you can tell that the Node is in fact moving along the path but just not visible.? UPDATE:? This also happens when moving at non-slow regular rate as I found out last night. >> 6) I do not suspect its a performance issue because when I do cause performance issues I get a studder not a flicker and the whole game slows up. While flickering the Node still moves smoothly through the path. >> Currently the Node that I am using in this case is a Group with an ImageView and an invisible Rectangle in it.? This Group is inside another which is inside another Group which is inside the root Scene. >> >> Any ideas what could be causing the flickering? >> >> thanks >> jose >>? From jmartine_1026 at yahoo.com Fri Jun 1 08:19:15 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Fri, 1 Jun 2012 08:19:15 -0700 (PDT) Subject: problem with PathTransition causing flickering of its Node In-Reply-To: <4FC8DB22.2040704@oracle.com> References: <1338561424.20028.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FC8D76A.2030702@oracle.com> <4FC8DB22.2040704@oracle.com> Message-ID: <1338563955.89149.YahooMailNeo@web160902.mail.bf1.yahoo.com> Steve, Here is all the information: Netbeans 7.2 (though this happened in 7.1) running as WebStart. Java 7u4 JFX 2.1 Windows 7 Doing the sample might be a little difficult but I will give it a try. ? I wonder if there is a way I can setup my groups, maybe flatten the whole thing out so that there is less nested Groups, so that this would occur less. ? thanks jose ________________________________ From: "steve.x.northover at oracle.com" To: openjfx-dev at openjdk.java.net Sent: Friday, June 1, 2012 11:09 AM Subject: Re: problem with PathTransition causing flickering of its Node First off, what platform are you on?? Second can you create a simple example that flickers and either post it here or enter a JIRA? Thanks! Steve On 01/06/2012 11:05 AM, Joseph Andresen wrote: > Can you describe the state of the scene? Are you using a perspective camera? > > > > On Jun 1, 2012, at 7:53 AM, Kevin Rushforth? wrote: > >> One thing to try: can you run it with "-Dprism.dirtyopts=false" and see if the problem persists? >> >> In any case, please file a JIRA bug against the "Animation" component. >> >> -- Kevin >> >> >> Jose Martinez wrote: >>> In the project (a video game) I am working on I use a lot of PathTransitions to move enemy units across the map. I am noticing flickering of the Nodes in the PathTransitions. By flickering I mean they lose and gain visibility. It does not happen all the time. The paths are pretty simple Shapes... straight lines. I am using Orthogonal orientation. >>> >>> here are some things I have noticed.... >>> >>> 1) There is an increase in flickering occurring when there is a lot happening on the screen. >>> 2) There is an increase in flickering when the PathTransition's Node is moving over another Node. >>> 3) Points 1 and 2 might be related or have the same root cause but its hard to tell. >>> 4) If I change the rate of PathTransition to a low number (so that the Node is moving really slow) then the Node just becomes non-visible (cant see it on the screen) yet it is there because the projectiles in the game that are shooting the Nodes are in fact striking them, so you can tell that the Node is in fact moving along the path but just not visible.? UPDATE:? This also happens when moving at non-slow regular rate as I found out last night. >>> 6) I do not suspect its a performance issue because when I do cause performance issues I get a studder not a flicker and the whole game slows up. While flickering the Node still moves smoothly through the path. >>> Currently the Node that I am using in this case is a Group with an ImageView and an invisible Rectangle in it.? This Group is inside another which is inside another Group which is inside the root Scene. >>> >>> Any ideas what could be causing the flickering? >>> >>> thanks >>> jose >>> From kevin.rushforth at oracle.com Fri Jun 1 08:36:44 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 01 Jun 2012 08:36:44 -0700 Subject: problem with PathTransition causing flickering of its Node In-Reply-To: <1338563955.89149.YahooMailNeo@web160902.mail.bf1.yahoo.com> References: <1338561424.20028.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FC8D76A.2030702@oracle.com> <4FC8DB22.2040704@oracle.com> <1338563955.89149.YahooMailNeo@web160902.mail.bf1.yahoo.com> Message-ID: <4FC8E18C.9000108@oracle.com> Hi Jose, We are about to release JavaFX 2.2. Can you try it with the latest developer preview version of 2.2? -- Kevin Jose Martinez wrote: > Steve, > > Here is all the information: > > Netbeans 7.2 (though this happened in 7.1) running as WebStart. > Java 7u4 > JFX 2.1 > Windows 7 > > Doing the sample might be a little difficult but I will give it a try. > > I wonder if there is a way I can setup my groups, maybe flatten the whole thing out so that there is less nested Groups, so that this would occur less. > > thanks > jose > > > ________________________________ > From: "steve.x.northover at oracle.com" > To: openjfx-dev at openjdk.java.net > Sent: Friday, June 1, 2012 11:09 AM > Subject: Re: problem with PathTransition causing flickering of its Node > > First off, what platform are you on? Second can you create a simple > example that flickers and either post it here or enter a JIRA? > > Thanks! > Steve > > On 01/06/2012 11:05 AM, Joseph Andresen wrote: > >> Can you describe the state of the scene? Are you using a perspective camera? >> >> >> >> On Jun 1, 2012, at 7:53 AM, Kevin Rushforth wrote: >> >> >>> One thing to try: can you run it with "-Dprism.dirtyopts=false" and see if the problem persists? >>> >>> In any case, please file a JIRA bug against the "Animation" component. >>> >>> -- Kevin >>> >>> >>> Jose Martinez wrote: >>> >>>> In the project (a video game) I am working on I use a lot of PathTransitions to move enemy units across the map. I am noticing flickering of the Nodes in the PathTransitions. By flickering I mean they lose and gain visibility. It does not happen all the time. The paths are pretty simple Shapes... straight lines. I am using Orthogonal orientation. >>>> >>>> here are some things I have noticed.... >>>> >>>> 1) There is an increase in flickering occurring when there is a lot happening on the screen. >>>> 2) There is an increase in flickering when the PathTransition's Node is moving over another Node. >>>> 3) Points 1 and 2 might be related or have the same root cause but its hard to tell. >>>> 4) If I change the rate of PathTransition to a low number (so that the Node is moving really slow) then the Node just becomes non-visible (cant see it on the screen) yet it is there because the projectiles in the game that are shooting the Nodes are in fact striking them, so you can tell that the Node is in fact moving along the path but just not visible. UPDATE: This also happens when moving at non-slow regular rate as I found out last night. >>>> 6) I do not suspect its a performance issue because when I do cause performance issues I get a studder not a flicker and the whole game slows up. While flickering the Node still moves smoothly through the path. >>>> Currently the Node that I am using in this case is a Group with an ImageView and an invisible Rectangle in it. This Group is inside another which is inside another Group which is inside the root Scene. >>>> >>>> Any ideas what could be causing the flickering? >>>> >>>> thanks >>>> jose >>>> >>>> From joseph.andresen at oracle.com Fri Jun 1 08:38:37 2012 From: joseph.andresen at oracle.com (Joseph Andresen) Date: Fri, 1 Jun 2012 08:38:37 -0700 Subject: problem with PathTransition causing flickering of its Node In-Reply-To: <1338563123.55283.YahooMailNeo@web160904.mail.bf1.yahoo.com> References: <1338561424.20028.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FC8D76A.2030702@oracle.com> <1338563123.55283.YahooMailNeo@web160904.mail.bf1.yahoo.com> Message-ID: <78018C97-F07E-466B-AB26-2C9073ECFB8D@oracle.com> To help answer Steve's question, add -Dprism.verbose=true to the vm args and report that as well. On Jun 1, 2012, at 8:05 AM, Jose Martinez wrote: > Kevin, > > Thanks for the quick response. I just tested that out and it still occurs. I'll run some more tests to verify if the rate of occurrence of it has changed. Just to be sure I did this right let me confirm... in Netbeans I added that argument to the VM options and it showed up in the JNLP file in the value of java-vm-args. > > > jose > > > ________________________________ > From: Kevin Rushforth > To: Jose Martinez > Cc: openjfx mailing list > Sent: Friday, June 1, 2012 10:53 AM > Subject: Re: problem with PathTransition causing flickering of its Node > > One thing to try: can you run it with "-Dprism.dirtyopts=false" and see > if the problem persists? > > In any case, please file a JIRA bug against the "Animation" component. > > -- Kevin > > > Jose Martinez wrote: >> In the project (a video game) I am working on I use a lot of PathTransitions to move enemy units across the map. I am noticing flickering of the Nodes in the PathTransitions. By flickering I mean they lose and gain visibility. It does not happen all the time. The paths are pretty simple Shapes... straight lines. I am using Orthogonal orientation. >> >> here are some things I have noticed.... >> >> 1) There is an increase in flickering occurring when there is a lot happening on the screen. >> 2) There is an increase in flickering when the PathTransition's Node is moving over another Node. >> 3) Points 1 and 2 might be related or have the same root cause but its hard to tell. >> 4) If I change the rate of PathTransition to a low number (so that the Node is moving really slow) then the Node just becomes non-visible (cant see it on the screen) yet it is there because the projectiles in the game that are shooting the Nodes are in fact striking them, so you can tell that the Node is in fact moving along the path but just not visible. UPDATE: This also happens when moving at non-slow regular rate as I found out last night. >> 6) I do not suspect its a performance issue because when I do cause performance issues I get a studder not a flicker and the whole game slows up. While flickering the Node still moves smoothly through the path. >> >> Currently the Node that I am using in this case is a Group with an ImageView and an invisible Rectangle in it. This Group is inside another which is inside another Group which is inside the root Scene. >> >> Any ideas what could be causing the flickering? >> >> thanks >> jose >> From jmartine_1026 at yahoo.com Fri Jun 1 08:40:04 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Fri, 1 Jun 2012 08:40:04 -0700 (PDT) Subject: problem with PathTransition causing flickering of its Node In-Reply-To: <4FC8E18C.9000108@oracle.com> References: <1338561424.20028.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FC8D76A.2030702@oracle.com> <4FC8DB22.2040704@oracle.com> <1338563955.89149.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FC8E18C.9000108@oracle.com> Message-ID: <1338565204.9321.YahooMailNeo@web160901.mail.bf1.yahoo.com> Ok i'll do that now. ? jose ________________________________ From: Kevin Rushforth To: Jose Martinez Cc: "steve.x.northover at oracle.com" ; "openjfx-dev at openjdk.java.net" Sent: Friday, June 1, 2012 11:36 AM Subject: Re: problem with PathTransition causing flickering of its Node Hi Jose, We are about to release JavaFX 2.2. Can you try it with the latest developer preview version of 2.2? -- Kevin Jose Martinez wrote: > Steve, > > Here is all the information: > > Netbeans 7.2 (though this happened in 7.1) running as WebStart. > Java 7u4 > JFX 2.1 > Windows 7 > > Doing the sample might be a little difficult but I will give it a try.? > > I wonder if there is a way I can setup my groups, maybe flatten the whole thing out so that there is less nested Groups, so that this would occur less. >? > thanks > jose > > > ________________________________ >? From: "steve.x.northover at oracle.com" > To: openjfx-dev at openjdk.java.net > Sent: Friday, June 1, 2012 11:09 AM > Subject: Re: problem with PathTransition causing flickering of its Node >? > First off, what platform are you on?? Second can you create a simple > example that flickers and either post it here or enter a JIRA? > > Thanks! > Steve > > On 01/06/2012 11:05 AM, Joseph Andresen wrote: >? >> Can you describe the state of the scene? Are you using a perspective camera? >> >> >> >> On Jun 1, 2012, at 7:53 AM, Kevin Rushforth? wrote: >> >>? ? >>> One thing to try: can you run it with "-Dprism.dirtyopts=false" and see if the problem persists? >>> >>> In any case, please file a JIRA bug against the "Animation" component. >>> >>> -- Kevin >>> >>> >>> Jose Martinez wrote: >>>? ? ? >>>> In the project (a video game) I am working on I use a lot of PathTransitions to move enemy units across the map. I am noticing flickering of the Nodes in the PathTransitions. By flickering I mean they lose and gain visibility. It does not happen all the time. The paths are pretty simple Shapes... straight lines. I am using Orthogonal orientation. >>>> >>>> here are some things I have noticed.... >>>> >>>> 1) There is an increase in flickering occurring when there is a lot happening on the screen. >>>> 2) There is an increase in flickering when the PathTransition's Node is moving over another Node. >>>> 3) Points 1 and 2 might be related or have the same root cause but its hard to tell. >>>> 4) If I change the rate of PathTransition to a low number (so that the Node is moving really slow) then the Node just becomes non-visible (cant see it on the screen) yet it is there because the projectiles in the game that are shooting the Nodes are in fact striking them, so you can tell that the Node is in fact moving along the path but just not visible.? UPDATE:? This also happens when moving at non-slow regular rate as I found out last night. >>>> 6) I do not suspect its a performance issue because when I do cause performance issues I get a studder not a flicker and the whole game slows up. While flickering the Node still moves smoothly through the path. >>>> Currently the Node that I am using in this case is a Group with an ImageView and an invisible Rectangle in it.? This Group is inside another which is inside another Group which is inside the root Scene. >>>> >>>> Any ideas what could be causing the flickering? >>>> >>>> thanks >>>> jose >>>> >>>>? ? ? ? From fbrunnerlist at gmx.ch Fri Jun 1 08:15:33 2012 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Fri, 1 Jun 2012 17:15:33 +0200 Subject: Patch: issue RT-14177 In-Reply-To: <4FC88589.6000207@bestsolution.at> References: <201204051750.13667.fbrunnerlist@gmx.ch> <4FC83568.6040400@oracle.com> <4FC88589.6000207@bestsolution.at> Message-ID: <201206011715.33779.fbrunnerlist@gmx.ch> Hmm, something went wrong with the attachement... ------------------------------------------ I tested rt-14177.3.patch and Tom is right, the ClassNotFoundException has to be catched otherwise the new code won't be executed. Unfortunatly, hg import failed for 5.patch for some reason. I created and tested a new patch (with "hg diff --git" as recommended by Kevin; see attachements, I don't have the necessary rights in JIRA). It works fine for my use case. I also renamed ex2 to ex3 and ex3 to ex2 and fixed some formatting issues. Note however that now the method contains around 100 lines of code. You might want to refactor it into several smaller methods for maintainability reasons. Regards, Florian Am Freitag 01 Juni 2012, 11:04:09 schrieb Tom Schindl: > Hi, > > I've uploaded a fixed version of the patch! I think Richards patch > missed to catch the CNE for the context classloader. > > I can not comment on other areas of the control system - just did a > short Class.forName-scan and can confirm you are finding about > PopControl - it even has the same fix for RT-17525 so extracing the code > and moveing it to a library makes sense. > > CSS might have similar problems (but in case of classloading but they > are harder to fix because one has to infer the correct classloader from > the CSS-URI or even the target they are applied to!). > > FXML has fixed all iusses (beside one small remaining issue I'm just > discussing with Greg on this list) because it allows to pass custom > classloaders and hence stuff loaded through FXML will directly profit > from the Control enhancement. > > FXML is IMHO different to CSS/Controls because there's a defined > lifecycle and so controlling the classloader there is much easier than > it is in CSS/Control space where the classloader access is happening in > an async fashion. > > I currently have no local build so I have to rely on Florian to give > feedback if it fixes the problem. From a source introspection it looks > good to me with my patch 5. > > Tom > > Am 01.06.12 05:22, schrieb Jonathan Giles: > > +1 on the patch, although I do wonder whether we are being consistent in > > the other places where classloading comes into play. Is this something > > that should be extracted and used as an internal library? > > > > For example, there is much the same code in PopupControl that needs to > > be fixed at the same time as the patch you are submitting here, but more > > abstractly, should we have a library rather than duplicate similar code > > in FXML and CSS as well? > > > > -- Jonathan > > > > > > On 1/06/2012 3:14 p.m., Richard Bair wrote: > >> Florian / Tom, > >> > >> I've uploaded two patches to the issue: > >> rt-14177.2.patch > >> rt-14177.3.patch > >> > >> The .3 patch is my preferred one. Can you take a look / apply it and > >> see if it solves your issue? If the .3 patch works, then I think we've > >> got a clean patch which will produce no additional performance > >> overhead to a correctly functioning JavaFX application today, but will > >> fix your issue (at least as Tom said in the issue itself for 95% of > >> the folks). > >> > >> We can then file a new issue for the remaining 5% cases which will > >> need more time (since it involves some form of new API) whereas in > >> this case it should "just work". > >> > >> David / Jonathan, can you guys give a quick code review? I'm pretty > >> sure the code does what I want it to do, and hopefully Florian / Tom > >> will tell us if what I want it to do is actually the right thing to do > >> (ie: solves the issue) :-). > >> > >> Thanks > >> Richard > >> > >> On May 31, 2012, at 5:45 PM, Richard Bair wrote: > >> > >>> Hi Florian, > >>> > >>> We'll get this fixed ASAP. > >>> > >>> Thanks > >>> Richard > >>> > >>> On May 31, 2012, at 4:45 PM, Kevin Rushforth wrote: > >>> > >>>> Hi Florian, > >>>> > >>>> This JIRA issue is targeted for 3.0 which is just in the initial > >>>> planning stages, so no one has looked at it yet. > >>>> > >>>> The patch as attached to the issue deals with one case of CSS > >>>> loading a skin, but when the controls team evaluated it, their take > >>>> was that it a more general platform issue, although it could be > >>>> dealt with in isolation. In any case, even if I were to assign this > >>>> back to someone on the controls team, this code would need to be > >>>> evaluated for potential bugs and to ensure that there are no > >>>> security issues (probably not an issue, but since it would be using > >>>> a system class loader we need to make sure it is never called from a > >>>> privileged context), which is unlikely to happen for the current > >>>> release. > >>>> > >>>> -- Kevin > >>>> > >>>> > >>>> Florian Brunner wrote: > >>>>> Hi Kevin, > >>>>> > >>>>> What is the status of my patch? > >>>>> As mentioned in JIRA, this issue is becoming a blocker! Please > >>>>> increase the priority! (Nobody from Oracle is responding on JIRA). > >>>>> > >>>>> Can we agree then to integrate the provided patch? It improves the > >>>>> situation but doesn't introduce any API additions and we can > >>>>> replace/ complete it later with other solutions if needed. > >>>>> Please tell me if I should change something in the patch to get it > >>>>> approved. > >>>>> > >>>>> Regards, > >>>>> Florian > >>>>> > >>>>> Am Freitag 06 April 2012, 23:58:13 schrieb Kevin Rushforth: > >>>>> > >>>>>> I attached it to the JIRA issue. > >>>>>> > >>>>>> -- Kevin > >>>>>> > >>>>>> > >>>>>> Florian Brunner wrote: > >>>>>> > >>>>>>> Here the patch created with "hg diff --git" and zipped. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Florian > >>>>>>> > >>>>>>> Am Freitag 06 April 2012, 18:31:23 schrieb Kevin Rushforth: > >>>>>>> > >>>>>>>> Right. Since you didn't file the issue and are not the assignee, > >>>>>>>> you can't add an attachment. > >>>>>>>> > >>>>>>>> Copying Brian Beck in case this is something we can (and want > >>>>>>>> to) fix. > >>>>>>>> > >>>>>>>> In the mean time, you can e-mail me the patch and I'll attach it > >>>>>>>> to the bug report. > >>>>>>>> > >>>>>>>> -- Kevin > >>>>>>>> > >>>>>>>> > >>>>>>>> Florian Brunner wrote: > >>>>>>>> > >>>>>>>>> Hi Kevin, > >>>>>>>>> > >>>>>>>>> Thanks for your response. > >>>>>>>>> > >>>>>>>>> Unfortunatly, I don't see a way to attach something to the JIRA > >>>>>>>>> issue. > >>>>>>>>> > >>>>>>>>> Either I'm missing something or maybe I need additional rights? > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Florian > >>>>>>>>> > >>>>>>>>> Am Donnerstag 05 April 2012, 18:54:38 schrieben Sie: > >>>>>>>>> > >>>>>>>>>> Great. Please attach the patch as a zip file to the JIRA issue > >>>>>>>>>> (preferably generated with either webrev or "hg diff --git") > >>>>>>>>>> so that it can be evaluated. > >>>>>>>>>> > >>>>>>>>>> -- Kevin > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Florian Brunner wrote: > >>>>>>>>>> > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> Let me introduce myself: my name is Florian Brunner and I'm a > >>>>>>>>>>> Senior Software Engineer from Switzerland. > >>>>>>>>>>> > >>>>>>>>>>> I started to use JavaFX in an OSGi environment. Now I > >>>>>>>>>>> stumbled over the following issue, which blocks me: > >>>>>>>>>>> http://javafx-jira.kenai.com/browse/RT-14177 > >>>>>>>>>>> > >>>>>>>>>>> I have written a patch now. It probably doesn't solve the > >>>>>>>>>>> whole issue, but at least it unblocks me for now. > >>>>>>>>>>> > >>>>>>>>>>> It would be great if you could integrate it. > >>>>>>>>>>> > >>>>>>>>>>> Note that I contributed to OpenJDK before (Swing) and have > >>>>>>>>>>> signed the Sun Contributor Agreement: > >>>>>>>>>>> > >>>>>>>>>>> http://www.oracle.com/technetwork/community/oca-486395.html#b > >>>>>>>>>>> Florian Brunner - java.net - puce > >>>>>>>>>>> > >>>>>>>>>>> Regards, > >>>>>>>>>>> Florian > >>>>>>>>>>> > >>>>> > > > From jmartine_1026 at yahoo.com Fri Jun 1 09:04:24 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Fri, 1 Jun 2012 09:04:24 -0700 (PDT) Subject: problem with PathTransition causing flickering of its Node In-Reply-To: <1338565204.9321.YahooMailNeo@web160901.mail.bf1.yahoo.com> References: <1338561424.20028.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FC8D76A.2030702@oracle.com> <4FC8DB22.2040704@oracle.com> <1338563955.89149.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FC8E18C.9000108@oracle.com> <1338565204.9321.YahooMailNeo@web160901.mail.bf1.yahoo.com> Message-ID: <1338566664.16717.YahooMailNeo@web160903.mail.bf1.yahoo.com> Kevin, Just a few tests and I do NOT see the flickering. ?Wow i'm pretty impressed. ?I will continue to run tests through today and into tonight. ?I'll respond with an update tonight. BTW, I am going to send out another email for this other problem I am having but figure I give a heads up now since I still see the problem?happening?in 2.2. ?I get ghost images (images remaining after they have moved). ?Where the enemy units use PathTransitions to move, the projectiles use a Timeline that binds to the projectiles TranslateYProperty. ?I'll send another email for this issue, but it is?happening?in 2.2. ? ? thanks jose ________________________________ From: Jose Martinez To: Kevin Rushforth Cc: "openjfx-dev at openjdk.java.net" Sent: Friday, June 1, 2012 11:40 AM Subject: Re: problem with PathTransition causing flickering of its Node Ok i'll do that now. ? jose ________________________________ From: Kevin Rushforth To: Jose Martinez Cc: "steve.x.northover at oracle.com" ; "openjfx-dev at openjdk.java.net" Sent: Friday, June 1, 2012 11:36 AM Subject: Re: problem with PathTransition causing flickering of its Node Hi Jose, We are about to release JavaFX 2.2. Can you try it with the latest developer preview version of 2.2? -- Kevin Jose Martinez wrote: > Steve, > > Here is all the information: > > Netbeans 7.2 (though this happened in 7.1) running as WebStart. > Java 7u4 > JFX 2.1 > Windows 7 > > Doing the sample might be a little difficult but I will give it a try.? > > I wonder if there is a way I can setup my groups, maybe flatten the whole thing out so that there is less nested Groups, so that this would occur less. >? > thanks > jose > > > ________________________________ >? From: "steve.x.northover at oracle.com" > To: openjfx-dev at openjdk.java.net > Sent: Friday, June 1, 2012 11:09 AM > Subject: Re: problem with PathTransition causing flickering of its Node >? > First off, what platform are you on?? Second can you create a simple > example that flickers and either post it here or enter a JIRA? > > Thanks! > Steve > > On 01/06/2012 11:05 AM, Joseph Andresen wrote: >? >> Can you describe the state of the scene? Are you using a perspective camera? >> >> >> >> On Jun 1, 2012, at 7:53 AM, Kevin Rushforth? wrote: >> >>? ? >>> One thing to try: can you run it with "-Dprism.dirtyopts=false" and see if the problem persists? >>> >>> In any case, please file a JIRA bug against the "Animation" component. >>> >>> -- Kevin >>> >>> >>> Jose Martinez wrote: >>>? ? ? >>>> In the project (a video game) I am working on I use a lot of PathTransitions to move enemy units across the map. I am noticing flickering of the Nodes in the PathTransitions. By flickering I mean they lose and gain visibility. It does not happen all the time. The paths are pretty simple Shapes... straight lines. I am using Orthogonal orientation. >>>> >>>> here are some things I have noticed.... >>>> >>>> 1) There is an increase in flickering occurring when there is a lot happening on the screen. >>>> 2) There is an increase in flickering when the PathTransition's Node is moving over another Node. >>>> 3) Points 1 and 2 might be related or have the same root cause but its hard to tell. >>>> 4) If I change the rate of PathTransition to a low number (so that the Node is moving really slow) then the Node just becomes non-visible (cant see it on the screen) yet it is there because the projectiles in the game that are shooting the Nodes are in fact striking them, so you can tell that the Node is in fact moving along the path but just not visible.? UPDATE:? This also happens when moving at non-slow regular rate as I found out last night. >>>> 6) I do not suspect its a performance issue because when I do cause performance issues I get a studder not a flicker and the whole game slows up. While flickering the Node still moves smoothly through the path. >>>> Currently the Node that I am using in this case is a Group with an ImageView and an invisible Rectangle in it.?? This Group is inside another which is inside another Group which is inside the root Scene. >>>> >>>> Any ideas what could be causing the flickering? >>>> >>>> thanks >>>> jose >>>> >>>>? ? ? ? From fbrunnerlist at gmx.ch Fri Jun 1 09:10:08 2012 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Fri, 1 Jun 2012 18:10:08 +0200 Subject: Patch: issue RT-14177 In-Reply-To: <4FC8D548.8040901@bestsolution.at> References: <201204051750.13667.fbrunnerlist@gmx.ch> <201206011638.06564.fbrunner@gmx.ch> <4FC8D548.8040901@bestsolution.at> Message-ID: <201206011810.09092.fbrunnerlist@gmx.ch> Hi Tom, I have the following bundles: Bundle A: SomeBaseControl with a custom skin in a different (most commonly private) package Bundle B SomeControl extends SomeBaseControl Bundle C Instantiates SomeControl Just using: getClass().getClassLoader().loadClass(className); in Control resulted in a ClassNotFoundException (here: getClass() == SomeControl.class; className=skin class name for SomeBaseControl). So I started to loop over the super-types to get a class which is in the same bundle as the custom skin class. That worked. Do you see a better way without changing the API? Regards, Florian Am Freitag 01 Juni 2012, 16:44:24 schrieb Tom Schindl: > Hi Florian, > > Good. I can you tell me why the super-type loop is used - I think it was > already in your first patch - wondering what this is good for. > > Tom > > Am 01.06.12 16:38, schrieb Florian Brunner: > > I tested rt-14177.3.patch and Tom is right, the ClassNotFoundException has to be catched otherwise the new code won't be executed. > > > > Unfortunatly, hg import failed for 5.patch for some reason. > > > > I created and tested a new patch (with "hg diff --git" as recommended by Kevin (see attachements, I don't have the necessary rights in JIRA). > > > > It works fine for my use case. > > > > I also renamed ex2 to ex3 and ex3 to ex2 and fixed some formatting issues. > > > > Note however that now the method contains around 100 lines of code. You might want to refactor it into several smaller methods for maintainability reasons. > > > > Regards, > > Florian > > > > > > Am Freitag 01 Juni 2012, 11:04:09 schrieb Tom Schindl: > >> Hi, > >> > >> I've uploaded a fixed version of the patch! I think Richards patch > >> missed to catch the CNE for the context classloader. > >> > >> I can not comment on other areas of the control system - just did a > >> short Class.forName-scan and can confirm you are finding about > >> PopControl - it even has the same fix for RT-17525 so extracing the code > >> and moveing it to a library makes sense. > >> > >> CSS might have similar problems (but in case of classloading but they > >> are harder to fix because one has to infer the correct classloader from > >> the CSS-URI or even the target they are applied to!). > >> > >> FXML has fixed all iusses (beside one small remaining issue I'm just > >> discussing with Greg on this list) because it allows to pass custom > >> classloaders and hence stuff loaded through FXML will directly profit > >> from the Control enhancement. > >> > >> FXML is IMHO different to CSS/Controls because there's a defined > >> lifecycle and so controlling the classloader there is much easier than > >> it is in CSS/Control space where the classloader access is happening in > >> an async fashion. > >> > >> I currently have no local build so I have to rely on Florian to give > >> feedback if it fixes the problem. From a source introspection it looks > >> good to me with my patch 5. > >> > >> Tom > >> > >> Am 01.06.12 05:22, schrieb Jonathan Giles: > >>> +1 on the patch, although I do wonder whether we are being consistent in > >>> the other places where classloading comes into play. Is this something > >>> that should be extracted and used as an internal library? > >>> > >>> For example, there is much the same code in PopupControl that needs to > >>> be fixed at the same time as the patch you are submitting here, but more > >>> abstractly, should we have a library rather than duplicate similar code > >>> in FXML and CSS as well? > >>> > >>> -- Jonathan > >>> > >>> > >>> On 1/06/2012 3:14 p.m., Richard Bair wrote: > >>>> Florian / Tom, > >>>> > >>>> I've uploaded two patches to the issue: > >>>> rt-14177.2.patch > >>>> rt-14177.3.patch > >>>> > >>>> The .3 patch is my preferred one. Can you take a look / apply it and > >>>> see if it solves your issue? If the .3 patch works, then I think we've > >>>> got a clean patch which will produce no additional performance > >>>> overhead to a correctly functioning JavaFX application today, but will > >>>> fix your issue (at least as Tom said in the issue itself for 95% of > >>>> the folks). > >>>> > >>>> We can then file a new issue for the remaining 5% cases which will > >>>> need more time (since it involves some form of new API) whereas in > >>>> this case it should "just work". > >>>> > >>>> David / Jonathan, can you guys give a quick code review? I'm pretty > >>>> sure the code does what I want it to do, and hopefully Florian / Tom > >>>> will tell us if what I want it to do is actually the right thing to do > >>>> (ie: solves the issue) :-). > >>>> > >>>> Thanks > >>>> Richard > >>>> > >>>> On May 31, 2012, at 5:45 PM, Richard Bair wrote: > >>>> > >>>>> Hi Florian, > >>>>> > >>>>> We'll get this fixed ASAP. > >>>>> > >>>>> Thanks > >>>>> Richard > >>>>> > >>>>> On May 31, 2012, at 4:45 PM, Kevin Rushforth wrote: > >>>>> > >>>>>> Hi Florian, > >>>>>> > >>>>>> This JIRA issue is targeted for 3.0 which is just in the initial > >>>>>> planning stages, so no one has looked at it yet. > >>>>>> > >>>>>> The patch as attached to the issue deals with one case of CSS > >>>>>> loading a skin, but when the controls team evaluated it, their take > >>>>>> was that it a more general platform issue, although it could be > >>>>>> dealt with in isolation. In any case, even if I were to assign this > >>>>>> back to someone on the controls team, this code would need to be > >>>>>> evaluated for potential bugs and to ensure that there are no > >>>>>> security issues (probably not an issue, but since it would be using > >>>>>> a system class loader we need to make sure it is never called from a > >>>>>> privileged context), which is unlikely to happen for the current > >>>>>> release. > >>>>>> > >>>>>> -- Kevin > >>>>>> > >>>>>> > >>>>>> Florian Brunner wrote: > >>>>>>> Hi Kevin, > >>>>>>> > >>>>>>> What is the status of my patch? > >>>>>>> As mentioned in JIRA, this issue is becoming a blocker! Please > >>>>>>> increase the priority! (Nobody from Oracle is responding on JIRA). > >>>>>>> > >>>>>>> Can we agree then to integrate the provided patch? It improves the > >>>>>>> situation but doesn't introduce any API additions and we can > >>>>>>> replace/ complete it later with other solutions if needed. > >>>>>>> Please tell me if I should change something in the patch to get it > >>>>>>> approved. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Florian > >>>>>>> > >>>>>>> Am Freitag 06 April 2012, 23:58:13 schrieb Kevin Rushforth: > >>>>>>> > >>>>>>>> I attached it to the JIRA issue. > >>>>>>>> > >>>>>>>> -- Kevin > >>>>>>>> > >>>>>>>> > >>>>>>>> Florian Brunner wrote: > >>>>>>>> > >>>>>>>>> Here the patch created with "hg diff --git" and zipped. > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Florian > >>>>>>>>> > >>>>>>>>> Am Freitag 06 April 2012, 18:31:23 schrieb Kevin Rushforth: > >>>>>>>>> > >>>>>>>>>> Right. Since you didn't file the issue and are not the assignee, > >>>>>>>>>> you can't add an attachment. > >>>>>>>>>> > >>>>>>>>>> Copying Brian Beck in case this is something we can (and want > >>>>>>>>>> to) fix. > >>>>>>>>>> > >>>>>>>>>> In the mean time, you can e-mail me the patch and I'll attach it > >>>>>>>>>> to the bug report. > >>>>>>>>>> > >>>>>>>>>> -- Kevin > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Florian Brunner wrote: > >>>>>>>>>> > >>>>>>>>>>> Hi Kevin, > >>>>>>>>>>> > >>>>>>>>>>> Thanks for your response. > >>>>>>>>>>> > >>>>>>>>>>> Unfortunatly, I don't see a way to attach something to the JIRA > >>>>>>>>>>> issue. > >>>>>>>>>>> > >>>>>>>>>>> Either I'm missing something or maybe I need additional rights? > >>>>>>>>>>> > >>>>>>>>>>> Regards, > >>>>>>>>>>> Florian > >>>>>>>>>>> > >>>>>>>>>>> Am Donnerstag 05 April 2012, 18:54:38 schrieben Sie: > >>>>>>>>>>> > >>>>>>>>>>>> Great. Please attach the patch as a zip file to the JIRA issue > >>>>>>>>>>>> (preferably generated with either webrev or "hg diff --git") > >>>>>>>>>>>> so that it can be evaluated. > >>>>>>>>>>>> > >>>>>>>>>>>> -- Kevin > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Florian Brunner wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Hi, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Let me introduce myself: my name is Florian Brunner and I'm a > >>>>>>>>>>>>> Senior Software Engineer from Switzerland. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I started to use JavaFX in an OSGi environment. Now I > >>>>>>>>>>>>> stumbled over the following issue, which blocks me: > >>>>>>>>>>>>> http://javafx-jira.kenai.com/browse/RT-14177 > >>>>>>>>>>>>> > >>>>>>>>>>>>> I have written a patch now. It probably doesn't solve the > >>>>>>>>>>>>> whole issue, but at least it unblocks me for now. > >>>>>>>>>>>>> > >>>>>>>>>>>>> It would be great if you could integrate it. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Note that I contributed to OpenJDK before (Swing) and have > >>>>>>>>>>>>> signed the Sun Contributor Agreement: > >>>>>>>>>>>>> > >>>>>>>>>>>>> http://www.oracle.com/technetwork/community/oca-486395.html#b > >>>>>>>>>>>>> Florian Brunner - java.net - puce > >>>>>>>>>>>>> > >>>>>>>>>>>>> Regards, > >>>>>>>>>>>>> Florian > >>>>>>>>>>>>> > >>>>>>> > >> > >> > >> > > > From tom.schindl at bestsolution.at Fri Jun 1 09:21:37 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 01 Jun 2012 18:21:37 +0200 Subject: Patch: issue RT-14177 In-Reply-To: <201206011810.09092.fbrunnerlist@gmx.ch> References: <201204051750.13667.fbrunnerlist@gmx.ch> <201206011638.06564.fbrunner@gmx.ch> <4FC8D548.8040901@bestsolution.at> <201206011810.09092.fbrunnerlist@gmx.ch> Message-ID: <4FC8EC11.5090609@bestsolution.at> Ok - that makes sense. Classloader B only sees public packages from A. Need to leave for a weekend after work beer. So I'm fine with the last patch from Florian. Tom Am 01.06.12 18:10, schrieb Florian Brunner: > Hi Tom, > > I have the following bundles: > > Bundle A: > SomeBaseControl with a custom skin in a different (most commonly private) package > > Bundle B > SomeControl extends SomeBaseControl > > Bundle C > Instantiates SomeControl > > Just using: > > getClass().getClassLoader().loadClass(className); > > in Control resulted in a ClassNotFoundException (here: getClass() == SomeControl.class; className=skin class name for SomeBaseControl). > So I started to loop over the super-types to get a class which is in the same bundle as the custom skin class. That worked. > > Do you see a better way without changing the API? > > Regards, > Florian > > > Am Freitag 01 Juni 2012, 16:44:24 schrieb Tom Schindl: >> Hi Florian, >> >> Good. I can you tell me why the super-type loop is used - I think it was >> already in your first patch - wondering what this is good for. >> >> Tom >> >> Am 01.06.12 16:38, schrieb Florian Brunner: >>> I tested rt-14177.3.patch and Tom is right, the ClassNotFoundException has to be catched otherwise the new code won't be executed. >>> >>> Unfortunatly, hg import failed for 5.patch for some reason. >>> >>> I created and tested a new patch (with "hg diff --git" as recommended by Kevin (see attachements, I don't have the necessary rights in JIRA). >>> >>> It works fine for my use case. >>> >>> I also renamed ex2 to ex3 and ex3 to ex2 and fixed some formatting issues. >>> >>> Note however that now the method contains around 100 lines of code. You might want to refactor it into several smaller methods for maintainability reasons. >>> >>> Regards, >>> Florian >>> >>> >>> Am Freitag 01 Juni 2012, 11:04:09 schrieb Tom Schindl: >>>> Hi, >>>> >>>> I've uploaded a fixed version of the patch! I think Richards patch >>>> missed to catch the CNE for the context classloader. >>>> >>>> I can not comment on other areas of the control system - just did a >>>> short Class.forName-scan and can confirm you are finding about >>>> PopControl - it even has the same fix for RT-17525 so extracing the code >>>> and moveing it to a library makes sense. >>>> >>>> CSS might have similar problems (but in case of classloading but they >>>> are harder to fix because one has to infer the correct classloader from >>>> the CSS-URI or even the target they are applied to!). >>>> >>>> FXML has fixed all iusses (beside one small remaining issue I'm just >>>> discussing with Greg on this list) because it allows to pass custom >>>> classloaders and hence stuff loaded through FXML will directly profit >>>> from the Control enhancement. >>>> >>>> FXML is IMHO different to CSS/Controls because there's a defined >>>> lifecycle and so controlling the classloader there is much easier than >>>> it is in CSS/Control space where the classloader access is happening in >>>> an async fashion. >>>> >>>> I currently have no local build so I have to rely on Florian to give >>>> feedback if it fixes the problem. From a source introspection it looks >>>> good to me with my patch 5. >>>> >>>> Tom >>>> >>>> Am 01.06.12 05:22, schrieb Jonathan Giles: >>>>> +1 on the patch, although I do wonder whether we are being consistent in >>>>> the other places where classloading comes into play. Is this something >>>>> that should be extracted and used as an internal library? >>>>> >>>>> For example, there is much the same code in PopupControl that needs to >>>>> be fixed at the same time as the patch you are submitting here, but more >>>>> abstractly, should we have a library rather than duplicate similar code >>>>> in FXML and CSS as well? >>>>> >>>>> -- Jonathan >>>>> >>>>> >>>>> On 1/06/2012 3:14 p.m., Richard Bair wrote: >>>>>> Florian / Tom, >>>>>> >>>>>> I've uploaded two patches to the issue: >>>>>> rt-14177.2.patch >>>>>> rt-14177.3.patch >>>>>> >>>>>> The .3 patch is my preferred one. Can you take a look / apply it and >>>>>> see if it solves your issue? If the .3 patch works, then I think we've >>>>>> got a clean patch which will produce no additional performance >>>>>> overhead to a correctly functioning JavaFX application today, but will >>>>>> fix your issue (at least as Tom said in the issue itself for 95% of >>>>>> the folks). >>>>>> >>>>>> We can then file a new issue for the remaining 5% cases which will >>>>>> need more time (since it involves some form of new API) whereas in >>>>>> this case it should "just work". >>>>>> >>>>>> David / Jonathan, can you guys give a quick code review? I'm pretty >>>>>> sure the code does what I want it to do, and hopefully Florian / Tom >>>>>> will tell us if what I want it to do is actually the right thing to do >>>>>> (ie: solves the issue) :-). >>>>>> >>>>>> Thanks >>>>>> Richard >>>>>> >>>>>> On May 31, 2012, at 5:45 PM, Richard Bair wrote: >>>>>> >>>>>>> Hi Florian, >>>>>>> >>>>>>> We'll get this fixed ASAP. >>>>>>> >>>>>>> Thanks >>>>>>> Richard >>>>>>> >>>>>>> On May 31, 2012, at 4:45 PM, Kevin Rushforth wrote: >>>>>>> >>>>>>>> Hi Florian, >>>>>>>> >>>>>>>> This JIRA issue is targeted for 3.0 which is just in the initial >>>>>>>> planning stages, so no one has looked at it yet. >>>>>>>> >>>>>>>> The patch as attached to the issue deals with one case of CSS >>>>>>>> loading a skin, but when the controls team evaluated it, their take >>>>>>>> was that it a more general platform issue, although it could be >>>>>>>> dealt with in isolation. In any case, even if I were to assign this >>>>>>>> back to someone on the controls team, this code would need to be >>>>>>>> evaluated for potential bugs and to ensure that there are no >>>>>>>> security issues (probably not an issue, but since it would be using >>>>>>>> a system class loader we need to make sure it is never called from a >>>>>>>> privileged context), which is unlikely to happen for the current >>>>>>>> release. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> Florian Brunner wrote: >>>>>>>>> Hi Kevin, >>>>>>>>> >>>>>>>>> What is the status of my patch? >>>>>>>>> As mentioned in JIRA, this issue is becoming a blocker! Please >>>>>>>>> increase the priority! (Nobody from Oracle is responding on JIRA). >>>>>>>>> >>>>>>>>> Can we agree then to integrate the provided patch? It improves the >>>>>>>>> situation but doesn't introduce any API additions and we can >>>>>>>>> replace/ complete it later with other solutions if needed. >>>>>>>>> Please tell me if I should change something in the patch to get it >>>>>>>>> approved. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Florian >>>>>>>>> >>>>>>>>> Am Freitag 06 April 2012, 23:58:13 schrieb Kevin Rushforth: >>>>>>>>> >>>>>>>>>> I attached it to the JIRA issue. >>>>>>>>>> >>>>>>>>>> -- Kevin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Florian Brunner wrote: >>>>>>>>>> >>>>>>>>>>> Here the patch created with "hg diff --git" and zipped. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Florian >>>>>>>>>>> >>>>>>>>>>> Am Freitag 06 April 2012, 18:31:23 schrieb Kevin Rushforth: >>>>>>>>>>> >>>>>>>>>>>> Right. Since you didn't file the issue and are not the assignee, >>>>>>>>>>>> you can't add an attachment. >>>>>>>>>>>> >>>>>>>>>>>> Copying Brian Beck in case this is something we can (and want >>>>>>>>>>>> to) fix. >>>>>>>>>>>> >>>>>>>>>>>> In the mean time, you can e-mail me the patch and I'll attach it >>>>>>>>>>>> to the bug report. >>>>>>>>>>>> >>>>>>>>>>>> -- Kevin >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Florian Brunner wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Kevin, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for your response. >>>>>>>>>>>>> >>>>>>>>>>>>> Unfortunatly, I don't see a way to attach something to the JIRA >>>>>>>>>>>>> issue. >>>>>>>>>>>>> >>>>>>>>>>>>> Either I'm missing something or maybe I need additional rights? >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Florian >>>>>>>>>>>>> >>>>>>>>>>>>> Am Donnerstag 05 April 2012, 18:54:38 schrieben Sie: >>>>>>>>>>>>> >>>>>>>>>>>>>> Great. Please attach the patch as a zip file to the JIRA issue >>>>>>>>>>>>>> (preferably generated with either webrev or "hg diff --git") >>>>>>>>>>>>>> so that it can be evaluated. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- Kevin >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Florian Brunner wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Let me introduce myself: my name is Florian Brunner and I'm a >>>>>>>>>>>>>>> Senior Software Engineer from Switzerland. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I started to use JavaFX in an OSGi environment. Now I >>>>>>>>>>>>>>> stumbled over the following issue, which blocks me: >>>>>>>>>>>>>>> http://javafx-jira.kenai.com/browse/RT-14177 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have written a patch now. It probably doesn't solve the >>>>>>>>>>>>>>> whole issue, but at least it unblocks me for now. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It would be great if you could integrate it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Note that I contributed to OpenJDK before (Swing) and have >>>>>>>>>>>>>>> signed the Sun Contributor Agreement: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://www.oracle.com/technetwork/community/oca-486395.html#b >>>>>>>>>>>>>>> Florian Brunner - java.net - puce >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> Florian >>>>>>>>>>>>>>> >>>>>>>>> >>>> >>>> >>>> >> >> >> > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From jasper.potts at oracle.com Fri Jun 1 09:33:30 2012 From: jasper.potts at oracle.com (Jasper Potts) Date: Fri, 1 Jun 2012 09:33:30 -0700 Subject: LCD font smoothing in Text has no effect In-Reply-To: References: <007c01cd3fa7$bbdfff40$339ffdc0$@com.au> <4FC83C05.3040105@oracle.com> <008501cd3fad$cdb166e0$691434a0$@com.au> <4FC843B8.2040806@oracle.com> <008901cd3fb3$97cec9e0$c76c5da0$@com.au> <4FC8500E.4090403@oracle.com> <009e01cd3fbc$c0a7b3f0$41f71bd0$@com.au> Message-ID: It's a known issue fixed in 2.2 as Phil said. No LCD text in transparent windows such as used in SceneBuilder. Should be fixed with SB 1.0 release on 2.2. Jasper On Jun 1, 2012, at 7:24 AM, Richard Bair wrote: > Whoa, I found that surprising. Can you file a bug and we'll investigate. > > Thanks > Richard > > On May 31, 2012, at 11:06 PM, John C. Turnbull wrote: > >> Hmm, works in a stand-alone application. Maybe it's a bug in Scene Builder? >> >> Thanks, >> >> -jct >> >> -----Original Message----- >> From: Phil Race [mailto:philip.race at oracle.com] >> Sent: Friday, 1 June 2012 15:16 >> To: John C. Turnbull >> Cc: openjfx-dev at openjdk.java.net >> Subject: Re: LCD font smoothing in Text has no effect >> >> I think you should try this outside of scene builder first to eliminate >> that. >> If SceneBuilder is creating a shaped window and you are embedded in it then >> you won't get LCD text. >> >> -phil. >> >> On 5/31/12 10:01 PM, John C. Turnbull wrote: >>> All I am doing is placing a Text object on top of a filled Rectangle >>> in Scene Builder b40. >>> >>> Cheers, >>> >>> -jct >>> >>> -----Original Message----- >>> From: Phil Race [mailto:philip.race at oracle.com] >>> Sent: Friday, 1 June 2012 14:23 >>> To: John C. Turnbull >>> Cc: openjfx-dev at openjdk.java.net >>> Subject: Re: LCD font smoothing in Text has no effect >>> >>> So are you using a shaped window or transparency ? >>> In those cases you may get grayscale. The most recent 2.2 builds will >>> fix this IFF the transparency is not under the text pixels. >>> >>> -phil. >>> >>> On 5/31/12 9:19 PM, John C. Turnbull wrote: >>>> Looks like I am getting Direct3D... >>>> >>>> Prism pipeline init order: d3d j2d >>>> Using t2k for text rasterization >>>> Using dirty region optimizations >>>> Prism pipeline name = com.sun.prism.d3d.D3DPipeline Loading D3D >>>> native library ... >>>> succeeded. >>>> Direct3D initialization succeeded >>>> (X) Got class = class com.sun.prism.d3d.D3DPipeline Initialized prism >>>> pipeline: com.sun.prism.d3d.D3DPipeline OS Information: >>>> Windows 7 build 7601 >>>> D3D Driver Information: >>>> NVIDIA Quadro FX 5800 >>>> \\.\DISPLAY1 >>>> Driver nvd3dumx.dll, version 8.17.12.9635 >>>> Pixel Shader version 3.0 >>>> Device : ven_10DE, dev_05FD, subsys_059310DE >>>> >>>> ...but I still get greyscale antialiasing. >>>> >>>> Cheers, >>>> >>>> -jct >>>> >>>> -----Original Message----- >>>> From: Phil Race [mailto:philip.race at oracle.com] >>>> Sent: Friday, 1 June 2012 13:50 >>>> To: John C. Turnbull >>>> Cc: openjfx-dev at openjdk.java.net >>>> Subject: Re: LCD font smoothing in Text has no effect >>>> >>>> -Dprism.verbose=true to see which renderer is used. >>>> >>>> Are you getting 2D or D3D/OGL ? >>>> >>>> 2D isn't set up to do it and we probably won't fix that because it >>>> won't matter once we stop using it in 3.0 >>>> >>>> -phil. >>>> >>>> On 5/31/12 8:36 PM, John C. Turnbull wrote: >>>>> I have never been able to see any difference when I set the font >>>>> smoothing option to LCD in a Text control even with the latest >>>>> JavaFX >>>>> 2.2 drop. Gray scale antialiasing is still in use. >>>>> >>>>> >>>>> >>>>> Is this something likely to be fixed soon? >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> >>>>> -jct >>>>> >> > From richard.bair at oracle.com Fri Jun 1 09:36:54 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 1 Jun 2012 09:36:54 -0700 Subject: LCD font smoothing in Text has no effect In-Reply-To: References: <007c01cd3fa7$bbdfff40$339ffdc0$@com.au> <4FC83C05.3040105@oracle.com> <008501cd3fad$cdb166e0$691434a0$@com.au> <4FC843B8.2040806@oracle.com> <008901cd3fb3$97cec9e0$c76c5da0$@com.au> <4FC8500E.4090403@oracle.com> <009e01cd3fbc$c0a7b3f0$41f71bd0$@com.au> Message-ID: <1C4CC0E6-1B7B-4FFB-99AD-5813437C2D9D@oracle.com> OK, so what you see in SB was gray scale, but if you actually run the app produced using SceneBuilder, it would be LCD? Richard On Jun 1, 2012, at 9:33 AM, Jasper Potts wrote: > It's a known issue fixed in 2.2 as Phil said. No LCD text in transparent windows such as used in SceneBuilder. Should be fixed with SB 1.0 release on 2.2. > > Jasper > > On Jun 1, 2012, at 7:24 AM, Richard Bair wrote: > >> Whoa, I found that surprising. Can you file a bug and we'll investigate. >> >> Thanks >> Richard >> >> On May 31, 2012, at 11:06 PM, John C. Turnbull wrote: >> >>> Hmm, works in a stand-alone application. Maybe it's a bug in Scene Builder? >>> >>> Thanks, >>> >>> -jct >>> >>> -----Original Message----- >>> From: Phil Race [mailto:philip.race at oracle.com] >>> Sent: Friday, 1 June 2012 15:16 >>> To: John C. Turnbull >>> Cc: openjfx-dev at openjdk.java.net >>> Subject: Re: LCD font smoothing in Text has no effect >>> >>> I think you should try this outside of scene builder first to eliminate >>> that. >>> If SceneBuilder is creating a shaped window and you are embedded in it then >>> you won't get LCD text. >>> >>> -phil. >>> >>> On 5/31/12 10:01 PM, John C. Turnbull wrote: >>>> All I am doing is placing a Text object on top of a filled Rectangle >>>> in Scene Builder b40. >>>> >>>> Cheers, >>>> >>>> -jct >>>> >>>> -----Original Message----- >>>> From: Phil Race [mailto:philip.race at oracle.com] >>>> Sent: Friday, 1 June 2012 14:23 >>>> To: John C. Turnbull >>>> Cc: openjfx-dev at openjdk.java.net >>>> Subject: Re: LCD font smoothing in Text has no effect >>>> >>>> So are you using a shaped window or transparency ? >>>> In those cases you may get grayscale. The most recent 2.2 builds will >>>> fix this IFF the transparency is not under the text pixels. >>>> >>>> -phil. >>>> >>>> On 5/31/12 9:19 PM, John C. Turnbull wrote: >>>>> Looks like I am getting Direct3D... >>>>> >>>>> Prism pipeline init order: d3d j2d >>>>> Using t2k for text rasterization >>>>> Using dirty region optimizations >>>>> Prism pipeline name = com.sun.prism.d3d.D3DPipeline Loading D3D >>>>> native library ... >>>>> succeeded. >>>>> Direct3D initialization succeeded >>>>> (X) Got class = class com.sun.prism.d3d.D3DPipeline Initialized prism >>>>> pipeline: com.sun.prism.d3d.D3DPipeline OS Information: >>>>> Windows 7 build 7601 >>>>> D3D Driver Information: >>>>> NVIDIA Quadro FX 5800 >>>>> \\.\DISPLAY1 >>>>> Driver nvd3dumx.dll, version 8.17.12.9635 >>>>> Pixel Shader version 3.0 >>>>> Device : ven_10DE, dev_05FD, subsys_059310DE >>>>> >>>>> ...but I still get greyscale antialiasing. >>>>> >>>>> Cheers, >>>>> >>>>> -jct >>>>> >>>>> -----Original Message----- >>>>> From: Phil Race [mailto:philip.race at oracle.com] >>>>> Sent: Friday, 1 June 2012 13:50 >>>>> To: John C. Turnbull >>>>> Cc: openjfx-dev at openjdk.java.net >>>>> Subject: Re: LCD font smoothing in Text has no effect >>>>> >>>>> -Dprism.verbose=true to see which renderer is used. >>>>> >>>>> Are you getting 2D or D3D/OGL ? >>>>> >>>>> 2D isn't set up to do it and we probably won't fix that because it >>>>> won't matter once we stop using it in 3.0 >>>>> >>>>> -phil. >>>>> >>>>> On 5/31/12 8:36 PM, John C. Turnbull wrote: >>>>>> I have never been able to see any difference when I set the font >>>>>> smoothing option to LCD in a Text control even with the latest >>>>>> JavaFX >>>>>> 2.2 drop. Gray scale antialiasing is still in use. >>>>>> >>>>>> >>>>>> >>>>>> Is this something likely to be fixed soon? >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> >>>>>> >>>>>> -jct >>>>>> >>> >> From jasper.potts at oracle.com Fri Jun 1 09:43:05 2012 From: jasper.potts at oracle.com (Jasper Potts) Date: Fri, 1 Jun 2012 09:43:05 -0700 Subject: LCD font smoothing in Text has no effect In-Reply-To: <1C4CC0E6-1B7B-4FFB-99AD-5813437C2D9D@oracle.com> References: <007c01cd3fa7$bbdfff40$339ffdc0$@com.au> <4FC83C05.3040105@oracle.com> <008501cd3fad$cdb166e0$691434a0$@com.au> <4FC843B8.2040806@oracle.com> <008901cd3fb3$97cec9e0$c76c5da0$@com.au> <4FC8500E.4090403@oracle.com> <009e01cd3fbc$c0a7b3f0$41f71bd0$@com.au> <1C4CC0E6-1B7B-4FFB-99AD-5813437C2D9D@oracle.com> Message-ID: <7BC3DC44-C072-4565-8C53-72CDD1885CF3@oracle.com> Correct unless the built app also has transparent window. The issue is we fell back to greyscale when drawing to a transparent surface such as transparent window or popup. Jasper On Jun 1, 2012, at 9:36 AM, Richard Bair wrote: > OK, so what you see in SB was gray scale, but if you actually run the app produced using SceneBuilder, it would be LCD? > > Richard > > On Jun 1, 2012, at 9:33 AM, Jasper Potts wrote: > >> It's a known issue fixed in 2.2 as Phil said. No LCD text in transparent windows such as used in SceneBuilder. Should be fixed with SB 1.0 release on 2.2. >> >> Jasper >> >> On Jun 1, 2012, at 7:24 AM, Richard Bair wrote: >> >>> Whoa, I found that surprising. Can you file a bug and we'll investigate. >>> >>> Thanks >>> Richard >>> >>> On May 31, 2012, at 11:06 PM, John C. Turnbull wrote: >>> >>>> Hmm, works in a stand-alone application. Maybe it's a bug in Scene Builder? >>>> >>>> Thanks, >>>> >>>> -jct >>>> >>>> -----Original Message----- >>>> From: Phil Race [mailto:philip.race at oracle.com] >>>> Sent: Friday, 1 June 2012 15:16 >>>> To: John C. Turnbull >>>> Cc: openjfx-dev at openjdk.java.net >>>> Subject: Re: LCD font smoothing in Text has no effect >>>> >>>> I think you should try this outside of scene builder first to eliminate >>>> that. >>>> If SceneBuilder is creating a shaped window and you are embedded in it then >>>> you won't get LCD text. >>>> >>>> -phil. >>>> >>>> On 5/31/12 10:01 PM, John C. Turnbull wrote: >>>>> All I am doing is placing a Text object on top of a filled Rectangle >>>>> in Scene Builder b40. >>>>> >>>>> Cheers, >>>>> >>>>> -jct >>>>> >>>>> -----Original Message----- >>>>> From: Phil Race [mailto:philip.race at oracle.com] >>>>> Sent: Friday, 1 June 2012 14:23 >>>>> To: John C. Turnbull >>>>> Cc: openjfx-dev at openjdk.java.net >>>>> Subject: Re: LCD font smoothing in Text has no effect >>>>> >>>>> So are you using a shaped window or transparency ? >>>>> In those cases you may get grayscale. The most recent 2.2 builds will >>>>> fix this IFF the transparency is not under the text pixels. >>>>> >>>>> -phil. >>>>> >>>>> On 5/31/12 9:19 PM, John C. Turnbull wrote: >>>>>> Looks like I am getting Direct3D... >>>>>> >>>>>> Prism pipeline init order: d3d j2d >>>>>> Using t2k for text rasterization >>>>>> Using dirty region optimizations >>>>>> Prism pipeline name = com.sun.prism.d3d.D3DPipeline Loading D3D >>>>>> native library ... >>>>>> succeeded. >>>>>> Direct3D initialization succeeded >>>>>> (X) Got class = class com.sun.prism.d3d.D3DPipeline Initialized prism >>>>>> pipeline: com.sun.prism.d3d.D3DPipeline OS Information: >>>>>> Windows 7 build 7601 >>>>>> D3D Driver Information: >>>>>> NVIDIA Quadro FX 5800 >>>>>> \\.\DISPLAY1 >>>>>> Driver nvd3dumx.dll, version 8.17.12.9635 >>>>>> Pixel Shader version 3.0 >>>>>> Device : ven_10DE, dev_05FD, subsys_059310DE >>>>>> >>>>>> ...but I still get greyscale antialiasing. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> -jct >>>>>> >>>>>> -----Original Message----- >>>>>> From: Phil Race [mailto:philip.race at oracle.com] >>>>>> Sent: Friday, 1 June 2012 13:50 >>>>>> To: John C. Turnbull >>>>>> Cc: openjfx-dev at openjdk.java.net >>>>>> Subject: Re: LCD font smoothing in Text has no effect >>>>>> >>>>>> -Dprism.verbose=true to see which renderer is used. >>>>>> >>>>>> Are you getting 2D or D3D/OGL ? >>>>>> >>>>>> 2D isn't set up to do it and we probably won't fix that because it >>>>>> won't matter once we stop using it in 3.0 >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 5/31/12 8:36 PM, John C. Turnbull wrote: >>>>>>> I have never been able to see any difference when I set the font >>>>>>> smoothing option to LCD in a Text control even with the latest >>>>>>> JavaFX >>>>>>> 2.2 drop. Gray scale antialiasing is still in use. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Is this something likely to be fixed soon? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> >>>>>>> >>>>>>> -jct >>>>>>> >>>> >>> > From fbrunner at gmx.ch Fri Jun 1 07:38:06 2012 From: fbrunner at gmx.ch (Florian Brunner) Date: Fri, 1 Jun 2012 16:38:06 +0200 Subject: Patch: issue RT-14177 In-Reply-To: <4FC88589.6000207@bestsolution.at> References: <201204051750.13667.fbrunnerlist@gmx.ch> <4FC83568.6040400@oracle.com> <4FC88589.6000207@bestsolution.at> Message-ID: <201206011638.06564.fbrunner@gmx.ch> I tested rt-14177.3.patch and Tom is right, the ClassNotFoundException has to be catched otherwise the new code won't be executed. Unfortunatly, hg import failed for 5.patch for some reason. I created and tested a new patch (with "hg diff --git" as recommended by Kevin (see attachements, I don't have the necessary rights in JIRA). It works fine for my use case. I also renamed ex2 to ex3 and ex3 to ex2 and fixed some formatting issues. Note however that now the method contains around 100 lines of code. You might want to refactor it into several smaller methods for maintainability reasons. Regards, Florian Am Freitag 01 Juni 2012, 11:04:09 schrieb Tom Schindl: > Hi, > > I've uploaded a fixed version of the patch! I think Richards patch > missed to catch the CNE for the context classloader. > > I can not comment on other areas of the control system - just did a > short Class.forName-scan and can confirm you are finding about > PopControl - it even has the same fix for RT-17525 so extracing the code > and moveing it to a library makes sense. > > CSS might have similar problems (but in case of classloading but they > are harder to fix because one has to infer the correct classloader from > the CSS-URI or even the target they are applied to!). > > FXML has fixed all iusses (beside one small remaining issue I'm just > discussing with Greg on this list) because it allows to pass custom > classloaders and hence stuff loaded through FXML will directly profit > from the Control enhancement. > > FXML is IMHO different to CSS/Controls because there's a defined > lifecycle and so controlling the classloader there is much easier than > it is in CSS/Control space where the classloader access is happening in > an async fashion. > > I currently have no local build so I have to rely on Florian to give > feedback if it fixes the problem. From a source introspection it looks > good to me with my patch 5. > > Tom > > Am 01.06.12 05:22, schrieb Jonathan Giles: > > +1 on the patch, although I do wonder whether we are being consistent in > > the other places where classloading comes into play. Is this something > > that should be extracted and used as an internal library? > > > > For example, there is much the same code in PopupControl that needs to > > be fixed at the same time as the patch you are submitting here, but more > > abstractly, should we have a library rather than duplicate similar code > > in FXML and CSS as well? > > > > -- Jonathan > > > > > > On 1/06/2012 3:14 p.m., Richard Bair wrote: > >> Florian / Tom, > >> > >> I've uploaded two patches to the issue: > >> rt-14177.2.patch > >> rt-14177.3.patch > >> > >> The .3 patch is my preferred one. Can you take a look / apply it and > >> see if it solves your issue? If the .3 patch works, then I think we've > >> got a clean patch which will produce no additional performance > >> overhead to a correctly functioning JavaFX application today, but will > >> fix your issue (at least as Tom said in the issue itself for 95% of > >> the folks). > >> > >> We can then file a new issue for the remaining 5% cases which will > >> need more time (since it involves some form of new API) whereas in > >> this case it should "just work". > >> > >> David / Jonathan, can you guys give a quick code review? I'm pretty > >> sure the code does what I want it to do, and hopefully Florian / Tom > >> will tell us if what I want it to do is actually the right thing to do > >> (ie: solves the issue) :-). > >> > >> Thanks > >> Richard > >> > >> On May 31, 2012, at 5:45 PM, Richard Bair wrote: > >> > >>> Hi Florian, > >>> > >>> We'll get this fixed ASAP. > >>> > >>> Thanks > >>> Richard > >>> > >>> On May 31, 2012, at 4:45 PM, Kevin Rushforth wrote: > >>> > >>>> Hi Florian, > >>>> > >>>> This JIRA issue is targeted for 3.0 which is just in the initial > >>>> planning stages, so no one has looked at it yet. > >>>> > >>>> The patch as attached to the issue deals with one case of CSS > >>>> loading a skin, but when the controls team evaluated it, their take > >>>> was that it a more general platform issue, although it could be > >>>> dealt with in isolation. In any case, even if I were to assign this > >>>> back to someone on the controls team, this code would need to be > >>>> evaluated for potential bugs and to ensure that there are no > >>>> security issues (probably not an issue, but since it would be using > >>>> a system class loader we need to make sure it is never called from a > >>>> privileged context), which is unlikely to happen for the current > >>>> release. > >>>> > >>>> -- Kevin > >>>> > >>>> > >>>> Florian Brunner wrote: > >>>>> Hi Kevin, > >>>>> > >>>>> What is the status of my patch? > >>>>> As mentioned in JIRA, this issue is becoming a blocker! Please > >>>>> increase the priority! (Nobody from Oracle is responding on JIRA). > >>>>> > >>>>> Can we agree then to integrate the provided patch? It improves the > >>>>> situation but doesn't introduce any API additions and we can > >>>>> replace/ complete it later with other solutions if needed. > >>>>> Please tell me if I should change something in the patch to get it > >>>>> approved. > >>>>> > >>>>> Regards, > >>>>> Florian > >>>>> > >>>>> Am Freitag 06 April 2012, 23:58:13 schrieb Kevin Rushforth: > >>>>> > >>>>>> I attached it to the JIRA issue. > >>>>>> > >>>>>> -- Kevin > >>>>>> > >>>>>> > >>>>>> Florian Brunner wrote: > >>>>>> > >>>>>>> Here the patch created with "hg diff --git" and zipped. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Florian > >>>>>>> > >>>>>>> Am Freitag 06 April 2012, 18:31:23 schrieb Kevin Rushforth: > >>>>>>> > >>>>>>>> Right. Since you didn't file the issue and are not the assignee, > >>>>>>>> you can't add an attachment. > >>>>>>>> > >>>>>>>> Copying Brian Beck in case this is something we can (and want > >>>>>>>> to) fix. > >>>>>>>> > >>>>>>>> In the mean time, you can e-mail me the patch and I'll attach it > >>>>>>>> to the bug report. > >>>>>>>> > >>>>>>>> -- Kevin > >>>>>>>> > >>>>>>>> > >>>>>>>> Florian Brunner wrote: > >>>>>>>> > >>>>>>>>> Hi Kevin, > >>>>>>>>> > >>>>>>>>> Thanks for your response. > >>>>>>>>> > >>>>>>>>> Unfortunatly, I don't see a way to attach something to the JIRA > >>>>>>>>> issue. > >>>>>>>>> > >>>>>>>>> Either I'm missing something or maybe I need additional rights? > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> Florian > >>>>>>>>> > >>>>>>>>> Am Donnerstag 05 April 2012, 18:54:38 schrieben Sie: > >>>>>>>>> > >>>>>>>>>> Great. Please attach the patch as a zip file to the JIRA issue > >>>>>>>>>> (preferably generated with either webrev or "hg diff --git") > >>>>>>>>>> so that it can be evaluated. > >>>>>>>>>> > >>>>>>>>>> -- Kevin > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Florian Brunner wrote: > >>>>>>>>>> > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> Let me introduce myself: my name is Florian Brunner and I'm a > >>>>>>>>>>> Senior Software Engineer from Switzerland. > >>>>>>>>>>> > >>>>>>>>>>> I started to use JavaFX in an OSGi environment. Now I > >>>>>>>>>>> stumbled over the following issue, which blocks me: > >>>>>>>>>>> http://javafx-jira.kenai.com/browse/RT-14177 > >>>>>>>>>>> > >>>>>>>>>>> I have written a patch now. It probably doesn't solve the > >>>>>>>>>>> whole issue, but at least it unblocks me for now. > >>>>>>>>>>> > >>>>>>>>>>> It would be great if you could integrate it. > >>>>>>>>>>> > >>>>>>>>>>> Note that I contributed to OpenJDK before (Swing) and have > >>>>>>>>>>> signed the Sun Contributor Agreement: > >>>>>>>>>>> > >>>>>>>>>>> http://www.oracle.com/technetwork/community/oca-486395.html#b > >>>>>>>>>>> Florian Brunner - java.net - puce > >>>>>>>>>>> > >>>>>>>>>>> Regards, > >>>>>>>>>>> Florian > >>>>>>>>>>> > >>>>> > > > From richard.bair at oracle.com Fri Jun 1 09:58:22 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 1 Jun 2012 09:58:22 -0700 Subject: Patch: issue RT-14177 In-Reply-To: <4FC8EC11.5090609@bestsolution.at> References: <201204051750.13667.fbrunnerlist@gmx.ch> <201206011638.06564.fbrunner@gmx.ch> <4FC8D548.8040901@bestsolution.at> <201206011810.09092.fbrunnerlist@gmx.ch> <4FC8EC11.5090609@bestsolution.at> Message-ID: <29140440-7968-4E40-8F2E-560674849A08@oracle.com> Thanks guys! Thanks Jonathan & Tom for pointing out the other location in PopupControl. I've uploaded rt-14177.6.patch, which moves the code into com.sun.javafx.Utils and then has PopupControl and Control use it. As such the logic was rearranged a bit (for example, the methods just return the looked up class or fail with an exception, instead of assigning to a variable). Florian if you are still online and can test it out that would be great. Another code review would be appreciated. Thanks Richard On Jun 1, 2012, at 9:21 AM, Tom Schindl wrote: > Ok - that makes sense. Classloader B only sees public packages from A. > > Need to leave for a weekend after work beer. So I'm fine with the last > patch from Florian. > > Tom > > Am 01.06.12 18:10, schrieb Florian Brunner: >> Hi Tom, >> >> I have the following bundles: >> >> Bundle A: >> SomeBaseControl with a custom skin in a different (most commonly private) package >> >> Bundle B >> SomeControl extends SomeBaseControl >> >> Bundle C >> Instantiates SomeControl >> >> Just using: >> >> getClass().getClassLoader().loadClass(className); >> >> in Control resulted in a ClassNotFoundException (here: getClass() == SomeControl.class; className=skin class name for SomeBaseControl). >> So I started to loop over the super-types to get a class which is in the same bundle as the custom skin class. That worked. >> >> Do you see a better way without changing the API? >> >> Regards, >> Florian >> >> >> Am Freitag 01 Juni 2012, 16:44:24 schrieb Tom Schindl: >>> Hi Florian, >>> >>> Good. I can you tell me why the super-type loop is used - I think it was >>> already in your first patch - wondering what this is good for. >>> >>> Tom >>> >>> Am 01.06.12 16:38, schrieb Florian Brunner: >>>> I tested rt-14177.3.patch and Tom is right, the ClassNotFoundException has to be catched otherwise the new code won't be executed. >>>> >>>> Unfortunatly, hg import failed for 5.patch for some reason. >>>> >>>> I created and tested a new patch (with "hg diff --git" as recommended by Kevin (see attachements, I don't have the necessary rights in JIRA). >>>> >>>> It works fine for my use case. >>>> >>>> I also renamed ex2 to ex3 and ex3 to ex2 and fixed some formatting issues. >>>> >>>> Note however that now the method contains around 100 lines of code. You might want to refactor it into several smaller methods for maintainability reasons. >>>> >>>> Regards, >>>> Florian >>>> >>>> >>>> Am Freitag 01 Juni 2012, 11:04:09 schrieb Tom Schindl: >>>>> Hi, >>>>> >>>>> I've uploaded a fixed version of the patch! I think Richards patch >>>>> missed to catch the CNE for the context classloader. >>>>> >>>>> I can not comment on other areas of the control system - just did a >>>>> short Class.forName-scan and can confirm you are finding about >>>>> PopControl - it even has the same fix for RT-17525 so extracing the code >>>>> and moveing it to a library makes sense. >>>>> >>>>> CSS might have similar problems (but in case of classloading but they >>>>> are harder to fix because one has to infer the correct classloader from >>>>> the CSS-URI or even the target they are applied to!). >>>>> >>>>> FXML has fixed all iusses (beside one small remaining issue I'm just >>>>> discussing with Greg on this list) because it allows to pass custom >>>>> classloaders and hence stuff loaded through FXML will directly profit >>>>> from the Control enhancement. >>>>> >>>>> FXML is IMHO different to CSS/Controls because there's a defined >>>>> lifecycle and so controlling the classloader there is much easier than >>>>> it is in CSS/Control space where the classloader access is happening in >>>>> an async fashion. >>>>> >>>>> I currently have no local build so I have to rely on Florian to give >>>>> feedback if it fixes the problem. From a source introspection it looks >>>>> good to me with my patch 5. >>>>> >>>>> Tom >>>>> >>>>> Am 01.06.12 05:22, schrieb Jonathan Giles: >>>>>> +1 on the patch, although I do wonder whether we are being consistent in >>>>>> the other places where classloading comes into play. Is this something >>>>>> that should be extracted and used as an internal library? >>>>>> >>>>>> For example, there is much the same code in PopupControl that needs to >>>>>> be fixed at the same time as the patch you are submitting here, but more >>>>>> abstractly, should we have a library rather than duplicate similar code >>>>>> in FXML and CSS as well? >>>>>> >>>>>> -- Jonathan >>>>>> >>>>>> >>>>>> On 1/06/2012 3:14 p.m., Richard Bair wrote: >>>>>>> Florian / Tom, >>>>>>> >>>>>>> I've uploaded two patches to the issue: >>>>>>> rt-14177.2.patch >>>>>>> rt-14177.3.patch >>>>>>> >>>>>>> The .3 patch is my preferred one. Can you take a look / apply it and >>>>>>> see if it solves your issue? If the .3 patch works, then I think we've >>>>>>> got a clean patch which will produce no additional performance >>>>>>> overhead to a correctly functioning JavaFX application today, but will >>>>>>> fix your issue (at least as Tom said in the issue itself for 95% of >>>>>>> the folks). >>>>>>> >>>>>>> We can then file a new issue for the remaining 5% cases which will >>>>>>> need more time (since it involves some form of new API) whereas in >>>>>>> this case it should "just work". >>>>>>> >>>>>>> David / Jonathan, can you guys give a quick code review? I'm pretty >>>>>>> sure the code does what I want it to do, and hopefully Florian / Tom >>>>>>> will tell us if what I want it to do is actually the right thing to do >>>>>>> (ie: solves the issue) :-). >>>>>>> >>>>>>> Thanks >>>>>>> Richard >>>>>>> >>>>>>> On May 31, 2012, at 5:45 PM, Richard Bair wrote: >>>>>>> >>>>>>>> Hi Florian, >>>>>>>> >>>>>>>> We'll get this fixed ASAP. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Richard >>>>>>>> >>>>>>>> On May 31, 2012, at 4:45 PM, Kevin Rushforth wrote: >>>>>>>> >>>>>>>>> Hi Florian, >>>>>>>>> >>>>>>>>> This JIRA issue is targeted for 3.0 which is just in the initial >>>>>>>>> planning stages, so no one has looked at it yet. >>>>>>>>> >>>>>>>>> The patch as attached to the issue deals with one case of CSS >>>>>>>>> loading a skin, but when the controls team evaluated it, their take >>>>>>>>> was that it a more general platform issue, although it could be >>>>>>>>> dealt with in isolation. In any case, even if I were to assign this >>>>>>>>> back to someone on the controls team, this code would need to be >>>>>>>>> evaluated for potential bugs and to ensure that there are no >>>>>>>>> security issues (probably not an issue, but since it would be using >>>>>>>>> a system class loader we need to make sure it is never called from a >>>>>>>>> privileged context), which is unlikely to happen for the current >>>>>>>>> release. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> Florian Brunner wrote: >>>>>>>>>> Hi Kevin, >>>>>>>>>> >>>>>>>>>> What is the status of my patch? >>>>>>>>>> As mentioned in JIRA, this issue is becoming a blocker! Please >>>>>>>>>> increase the priority! (Nobody from Oracle is responding on JIRA). >>>>>>>>>> >>>>>>>>>> Can we agree then to integrate the provided patch? It improves the >>>>>>>>>> situation but doesn't introduce any API additions and we can >>>>>>>>>> replace/ complete it later with other solutions if needed. >>>>>>>>>> Please tell me if I should change something in the patch to get it >>>>>>>>>> approved. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Florian >>>>>>>>>> >>>>>>>>>> Am Freitag 06 April 2012, 23:58:13 schrieb Kevin Rushforth: >>>>>>>>>> >>>>>>>>>>> I attached it to the JIRA issue. >>>>>>>>>>> >>>>>>>>>>> -- Kevin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Florian Brunner wrote: >>>>>>>>>>> >>>>>>>>>>>> Here the patch created with "hg diff --git" and zipped. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Florian >>>>>>>>>>>> >>>>>>>>>>>> Am Freitag 06 April 2012, 18:31:23 schrieb Kevin Rushforth: >>>>>>>>>>>> >>>>>>>>>>>>> Right. Since you didn't file the issue and are not the assignee, >>>>>>>>>>>>> you can't add an attachment. >>>>>>>>>>>>> >>>>>>>>>>>>> Copying Brian Beck in case this is something we can (and want >>>>>>>>>>>>> to) fix. >>>>>>>>>>>>> >>>>>>>>>>>>> In the mean time, you can e-mail me the patch and I'll attach it >>>>>>>>>>>>> to the bug report. >>>>>>>>>>>>> >>>>>>>>>>>>> -- Kevin >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Florian Brunner wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Kevin, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for your response. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Unfortunatly, I don't see a way to attach something to the JIRA >>>>>>>>>>>>>> issue. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Either I'm missing something or maybe I need additional rights? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> Florian >>>>>>>>>>>>>> >>>>>>>>>>>>>> Am Donnerstag 05 April 2012, 18:54:38 schrieben Sie: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Great. Please attach the patch as a zip file to the JIRA issue >>>>>>>>>>>>>>> (preferably generated with either webrev or "hg diff --git") >>>>>>>>>>>>>>> so that it can be evaluated. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- Kevin >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Florian Brunner wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Let me introduce myself: my name is Florian Brunner and I'm a >>>>>>>>>>>>>>>> Senior Software Engineer from Switzerland. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I started to use JavaFX in an OSGi environment. Now I >>>>>>>>>>>>>>>> stumbled over the following issue, which blocks me: >>>>>>>>>>>>>>>> http://javafx-jira.kenai.com/browse/RT-14177 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I have written a patch now. It probably doesn't solve the >>>>>>>>>>>>>>>> whole issue, but at least it unblocks me for now. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It would be great if you could integrate it. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Note that I contributed to OpenJDK before (Swing) and have >>>>>>>>>>>>>>>> signed the Sun Contributor Agreement: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://www.oracle.com/technetwork/community/oca-486395.html#b >>>>>>>>>>>>>>>> Florian Brunner - java.net - puce >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> Florian >>>>>>>>>>>>>>>> >>>>>>>>>> >>>>> >>>>> >>>>> >>> >>> >>> >> > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From richard.bair at oracle.com Fri Jun 1 10:25:03 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 1 Jun 2012 10:25:03 -0700 Subject: Patch: issue RT-14177 In-Reply-To: <1DE3DC4E-5E73-49F5-A324-4734AC2788E4@oracle.com> References: <201204051750.13667.fbrunnerlist@gmx.ch> <201206011638.06564.fbrunner@gmx.ch> <4FC8D548.8040901@bestsolution.at> <201206011810.09092.fbrunnerlist@gmx.ch> <4FC8EC11.5090609@bestsolution.at> <29140440-7968-4E40-8F2E-560674849A08@oracle.com> <1DE3DC4E-5E73-49F5-A324-4734AC2788E4@oracle.com> Message-ID: <03BF8184-4C57-400E-BCBE-234DB0F8A7BD@oracle.com> I don't think this patch changes anything with regard to those two issues, except for the case where the class referenced by -fx-skin really doesn't exist. > This should be tested from an applet or with applet-like java.policy, no? I mean, if it's called from user code by way of Control or PopupControl, will it throw a SecurityException? We're not doing anything now that we weren't doing before. Doesn't the Class.forName handle the security issues when used by an Applet? > Also, loadSkinClass is a bottle neck and I fear this will make it worse. We may need to think about caching. I think caching would be a great idea, although I'm not sure it would always be correct (especially when class loaders are taken into account -- you could cache per class loader perhaps but which class loader to cache by?). In any case, because I loop over the class hierarchy last in the lookup sequence, the only time this will be worse than it is today for existing, working applications is when they are trying to load a skin that doesn't exist. For other apps currently out there, the lookup times will be exactly as they are now (except for the extra method call overhead which, with a JIT at least, is negligible). For Florian, he's going to pay some additional cost as we look up the skin by walking up the hierarchy, but hopefully not much. Richard From tom.schindl at bestsolution.at Fri Jun 1 10:54:34 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 01 Jun 2012 19:54:34 +0200 Subject: Patch: issue RT-14177 In-Reply-To: <03BF8184-4C57-400E-BCBE-234DB0F8A7BD@oracle.com> References: <201204051750.13667.fbrunnerlist@gmx.ch> <201206011638.06564.fbrunner@gmx.ch> <4FC8D548.8040901@bestsolution.at> <201206011810.09092.fbrunnerlist@gmx.ch> <4FC8EC11.5090609@bestsolution.at> <29140440-7968-4E40-8F2E-560674849A08@oracle.com> <1DE3DC4E-5E73-49F5-A324-4734AC2788E4@oracle.com> <03BF8184-4C57-400E-BCBE-234DB0F8A7BD@oracle.com> Message-ID: <4FC901DA.3050808@bestsolution.at> Looks good to me - I don't see the security problem because as Richard said we don't change the logic run before running the last resort code to use the classloader the classes before us have been loaded with (if there would have been a security problem those classes would have failed to load already not?). I think we can live for now with the performance degration in OSGi - the other option is even worse. Thank you very much Richard for taking care of this! Tom Am 01.06.12 19:25, schrieb Richard Bair: > I don't think this patch changes anything with regard to those two issues, except for the case where the class referenced by -fx-skin really doesn't exist. > >> This should be tested from an applet or with applet-like java.policy, no? I mean, if it's called from user code by way of Control or PopupControl, will it throw a SecurityException? > > We're not doing anything now that we weren't doing before. Doesn't the Class.forName handle the security issues when used by an Applet? > >> Also, loadSkinClass is a bottle neck and I fear this will make it worse. We may need to think about caching. > > I think caching would be a great idea, although I'm not sure it would always be correct (especially when class loaders are taken into account -- you could cache per class loader perhaps but which class loader to cache by?). > > In any case, because I loop over the class hierarchy last in the lookup sequence, the only time this will be worse than it is today for existing, working applications is when they are trying to load a skin that doesn't exist. For other apps currently out there, the lookup times will be exactly as they are now (except for the extra method call overhead which, with a JIT at least, is negligible). For Florian, he's going to pay some additional cost as we look up the skin by walking up the hierarchy, but hopefully not much. > > Richard > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From kevin.rushforth at oracle.com Fri Jun 1 11:16:45 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 01 Jun 2012 11:16:45 -0700 Subject: Patch: issue RT-14177 In-Reply-To: <4FC901DA.3050808@bestsolution.at> References: <201204051750.13667.fbrunnerlist@gmx.ch> <201206011638.06564.fbrunner@gmx.ch> <4FC8D548.8040901@bestsolution.at> <201206011810.09092.fbrunnerlist@gmx.ch> <4FC8EC11.5090609@bestsolution.at> <29140440-7968-4E40-8F2E-560674849A08@oracle.com> <1DE3DC4E-5E73-49F5-A324-4734AC2788E4@oracle.com> <03BF8184-4C57-400E-BCBE-234DB0F8A7BD@oracle.com> <4FC901DA.3050808@bestsolution.at> Message-ID: <4FC9070D.4020309@oracle.com> > > I don't see the security problem because as Richard > said we don't change the logic run before running the last resort code Yeah, this makes it very unlikely that there will be any problem. Having said that, testing that applets still work is good due diligence (and is required of team integrators before pushing anything into the master). -- Kevin Tom Schindl wrote: > Looks good to me - I don't see the security problem because as Richard > said we don't change the logic run before running the last resort code > to use the classloader the classes before us have been loaded with (if > there would have been a security problem those classes would have failed > to load already not?). > > I think we can live for now with the performance degration in OSGi - the > other option is even worse. > > Thank you very much Richard for taking care of this! > > Tom > > Am 01.06.12 19:25, schrieb Richard Bair: > >> I don't think this patch changes anything with regard to those two issues, except for the case where the class referenced by -fx-skin really doesn't exist. >> >> >>> This should be tested from an applet or with applet-like java.policy, no? I mean, if it's called from user code by way of Control or PopupControl, will it throw a SecurityException? >>> >> We're not doing anything now that we weren't doing before. Doesn't the Class.forName handle the security issues when used by an Applet? >> >> >>> Also, loadSkinClass is a bottle neck and I fear this will make it worse. We may need to think about caching. >>> >> I think caching would be a great idea, although I'm not sure it would always be correct (especially when class loaders are taken into account -- you could cache per class loader perhaps but which class loader to cache by?). >> >> In any case, because I loop over the class hierarchy last in the lookup sequence, the only time this will be worse than it is today for existing, working applications is when they are trying to load a skin that doesn't exist. For other apps currently out there, the lookup times will be exactly as they are now (except for the extra method call overhead which, with a JIT at least, is negligible). For Florian, he's going to pay some additional cost as we look up the skin by walking up the hierarchy, but hopefully not much. >> >> Richard >> >> > > > From richard.bair at oracle.com Fri Jun 1 13:17:40 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 1 Jun 2012 13:17:40 -0700 Subject: problem with PathTransition causing flickering of its Node In-Reply-To: <1338566664.16717.YahooMailNeo@web160903.mail.bf1.yahoo.com> References: <1338561424.20028.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FC8D76A.2030702@oracle.com> <4FC8DB22.2040704@oracle.com> <1338563955.89149.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FC8E18C.9000108@oracle.com> <1338565204.9321.YahooMailNeo@web160901.mail.bf1.yahoo.com> <1338566664.16717.YahooMailNeo@web160903.mail.bf1.yahoo.com> Message-ID: <3BD2EDBF-5A71-49FB-8D5F-F606A016CBBE@oracle.com> OK cool, the flickering images was surprising but good to see it isn't there on the latest :-). As for the other issue, that one is almost certainly a dirty region bug, in which case setting dirty opts off should fix it. Richard On Jun 1, 2012, at 9:04 AM, Jose Martinez wrote: > Kevin, > > Just a few tests and I do NOT see the flickering. Wow i'm pretty impressed. I will continue to run tests through today and into tonight. I'll respond with an update tonight. > > BTW, I am going to send out another email for this other problem I am having but figure I give a heads up now since I still see the problem happening in 2.2. I get ghost images (images remaining after they have moved). Where the enemy units use PathTransitions to move, the projectiles use a Timeline that binds to the projectiles TranslateYProperty. I'll send another email for this issue, but it is happening in 2.2. > > thanks > jose > > > ________________________________ > From: Jose Martinez > To: Kevin Rushforth > Cc: "openjfx-dev at openjdk.java.net" > Sent: Friday, June 1, 2012 11:40 AM > Subject: Re: problem with PathTransition causing flickering of its Node > > Ok i'll do that now. > > jose > > > ________________________________ > From: Kevin Rushforth > To: Jose Martinez > Cc: "steve.x.northover at oracle.com" ; "openjfx-dev at openjdk.java.net" > Sent: Friday, June 1, 2012 11:36 AM > Subject: Re: problem with PathTransition causing flickering of its Node > > Hi Jose, > > We are about to release JavaFX 2.2. Can you try it with the latest > developer preview version of 2.2? > > -- Kevin > > > Jose Martinez wrote: >> Steve, >> >> Here is all the information: >> >> Netbeans 7.2 (though this happened in 7.1) running as WebStart. >> Java 7u4 >> JFX 2.1 >> Windows 7 >> >> Doing the sample might be a little difficult but I will give it a try. >> >> I wonder if there is a way I can setup my groups, maybe flatten the whole thing out so that there is less nested Groups, so that this would occur less. >> >> thanks >> jose >> >> >> ________________________________ >> From: "steve.x.northover at oracle.com" >> To: openjfx-dev at openjdk.java.net >> Sent: Friday, June 1, 2012 11:09 AM >> Subject: Re: problem with PathTransition causing flickering of its Node >> >> First off, what platform are you on? Second can you create a simple >> example that flickers and either post it here or enter a JIRA? >> >> Thanks! >> Steve >> >> On 01/06/2012 11:05 AM, Joseph Andresen wrote: >> >>> Can you describe the state of the scene? Are you using a perspective camera? >>> >>> >>> >>> On Jun 1, 2012, at 7:53 AM, Kevin Rushforth wrote: >>> >>> >>>> One thing to try: can you run it with "-Dprism.dirtyopts=false" and see if the problem persists? >>>> >>>> In any case, please file a JIRA bug against the "Animation" component. >>>> >>>> -- Kevin >>>> >>>> >>>> Jose Martinez wrote: >>>> >>>>> In the project (a video game) I am working on I use a lot of PathTransitions to move enemy units across the map. I am noticing flickering of the Nodes in the PathTransitions. By flickering I mean they lose and gain visibility. It does not happen all the time. The paths are pretty simple Shapes... straight lines. I am using Orthogonal orientation. >>>>> >>>>> here are some things I have noticed.... >>>>> >>>>> 1) There is an increase in flickering occurring when there is a lot happening on the screen. >>>>> 2) There is an increase in flickering when the PathTransition's Node is moving over another Node. >>>>> 3) Points 1 and 2 might be related or have the same root cause but its hard to tell. >>>>> 4) If I change the rate of PathTransition to a low number (so that the Node is moving really slow) then the Node just becomes non-visible (cant see it on the screen) yet it is there because the projectiles in the game that are shooting the Nodes are in fact striking them, so you can tell that the Node is in fact moving along the path but just not visible. UPDATE: This also happens when moving at non-slow regular rate as I found out last night. >>>>> 6) I do not suspect its a performance issue because when I do cause performance issues I get a studder not a flicker and the whole game slows up. While flickering the Node still moves smoothly through the path. >>>>> Currently the Node that I am using in this case is a Group with an ImageView and an invisible Rectangle in it. This Group is inside another which is inside another Group which is inside the root Scene. >>>>> >>>>> Any ideas what could be causing the flickering? >>>>> >>>>> thanks >>>>> jose >>>>> >>>>> From richard.bair at oracle.com Fri Jun 1 13:54:07 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 1 Jun 2012 13:54:07 -0700 Subject: Patch: issue RT-14177 In-Reply-To: <4FC9070D.4020309@oracle.com> References: <201204051750.13667.fbrunnerlist@gmx.ch> <201206011638.06564.fbrunner@gmx.ch> <4FC8D548.8040901@bestsolution.at> <201206011810.09092.fbrunnerlist@gmx.ch> <4FC8EC11.5090609@bestsolution.at> <29140440-7968-4E40-8F2E-560674849A08@oracle.com> <1DE3DC4E-5E73-49F5-A324-4734AC2788E4@oracle.com> <03BF8184-4C57-400E-BCBE-234DB0F8A7BD@oracle.com> <4FC901DA.3050808@bestsolution.at> <4FC9070D.4020309@oracle.com> Message-ID: <395446C7-1B53-4035-BA83-3AC263470D36@oracle.com> OK, now for the tricky part. Writing the tests! I figure I might also add a sample to Ensemble showing how to use -fx-skin (feeling a little ambitious for a Friday afternoon :-)). Richard From hang.vo at oracle.com Fri Jun 1 14:32:24 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 01 Jun 2012 21:32:24 +0000 Subject: hg: openjfx/2.2/controls/rt: Fixed RT-21860: Virtual Keyboard throws an exception Message-ID: <20120601213226.C719C4768C@hg.openjdk.java.net> Changeset: 503bac65e6bc Author: leifs Date: 2012-06-01 14:16 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/503bac65e6bc Fixed RT-21860: Virtual Keyboard throws an exception ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java From jonathan.giles at oracle.com Fri Jun 1 14:32:51 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Sat, 02 Jun 2012 09:32:51 +1200 Subject: Defaulting a comboBox's buttonCell to the cellFactory In-Reply-To: References: Message-ID: <4FC93503.7010209@oracle.com> So, in summary, Urs and I would appreciate votes on option A or option B: Option A: the ComboBox buttonCell by default uses a cell from the provided cell factory. Option B: The ComboBox buttonCell DOES NOT use a cell from the provided cell factory, and instead requires the user to manually create a cell and set it in the buttonCell property. Option A is consistent with the approach used in JavaFX 2.1, whereas Option B is the current approach used in JavaFX 2.2. The answer to this question largely comes down to the more common use case when using the cell factory: do we expect users to want to use the same cell in the button and the list, or do we expect them to want to have different cells (and perhaps the default cell in the button area). I'm totally not against changing this, so I welcome your votes on this matter. -- Jonathan On 1/06/2012 5:39 p.m., Urs Reupke wrote: > Hi all, > back in April, Jonathan proposed a change to comboBoxes that allowed > to separate the button's rendering from the list's rendering.[1] > > In the JIRA issue accompanying that discussion [2], he also mentioned > ways to render the button when the new buttonCell property is not set: > "If this is not set, there are two options: > 1) Use a cell from the ComboBox.cellFactory > 2) Not style the button at all, and use a default cell from the skin" > > Now, in FX2.2b10, the buttonCell is rendered as toString if the > property is not set. > I believe that his option 1) would be a great improvement to the > behaviour, and Jonathan asked me to make that proposal public. > My reasoning is that those who need the buttonCell to be rendered > differently can do it, whereas those whose buttons and listcells look > alike don't need to think about it. From my experience, the latter > should be the majority. > > I appreciate your feedback on the matter. > > Thank you > -Urs > > [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-April/001209.html > [2] http://javafx-jira.kenai.com/browse/RT-21023 From thor.johannesson at oracle.com Fri Jun 1 15:57:32 2012 From: thor.johannesson at oracle.com (Thor Johannesson) Date: Fri, 1 Jun 2012 15:57:32 -0700 Subject: LCD font smoothing in Text has no effect In-Reply-To: <1C4CC0E6-1B7B-4FFB-99AD-5813437C2D9D@oracle.com> References: <007c01cd3fa7$bbdfff40$339ffdc0$@com.au> <4FC83C05.3040105@oracle.com> <008501cd3fad$cdb166e0$691434a0$@com.au> <4FC843B8.2040806@oracle.com> <008901cd3fb3$97cec9e0$c76c5da0$@com.au> <4FC8500E.4090403@oracle.com> <009e01cd3fbc$c0a7b3f0$41f71bd0$@com.au> <1C4CC0E6-1B7B-4FFB-99AD-5813437C2D9D@oracle.com> Message-ID: <5D6F4A6A-8DCD-4D7B-BDE7-B48D09E9B13E@oracle.com> I just wanted to elaborate on LCD Text when there is transparency. Before 2.2 we would fallback to grayscale if any transparency was detected, in destination. In 2.2, LCD text is rendered with whatever color information is there. If there is no background color (completely transparent) then results of lcd blending will look like AA gray-scale text. So same rendered, just different results. There are a lot of conditions where it does not make sense to use LCD text rendering. Leading to some restrictions. Some current restrictions on LCD Text rendering: - Certain effects will use a different render path - Text paint must be a color - BlendMode must be SRC_OVER (default) - Stroked text will be rendered in gray scale. - Very large text will be rendered as shapes (Gray) - Platform support, and restrictions (Mac default is gray) -Thor On Jun 1, 2012, at 9:36 AM, Richard Bair wrote: > OK, so what you see in SB was gray scale, but if you actually run the app produced using SceneBuilder, it would be LCD? > > Richard > > On Jun 1, 2012, at 9:33 AM, Jasper Potts wrote: > >> It's a known issue fixed in 2.2 as Phil said. No LCD text in transparent windows such as used in SceneBuilder. Should be fixed with SB 1.0 release on 2.2. >> >> Jasper >> >> On Jun 1, 2012, at 7:24 AM, Richard Bair wrote: >> >>> Whoa, I found that surprising. Can you file a bug and we'll investigate. >>> >>> Thanks >>> Richard >>> >>> On May 31, 2012, at 11:06 PM, John C. Turnbull wrote: >>> >>>> Hmm, works in a stand-alone application. Maybe it's a bug in Scene Builder? >>>> >>>> Thanks, >>>> >>>> -jct >>>> >>>> -----Original Message----- >>>> From: Phil Race [mailto:philip.race at oracle.com] >>>> Sent: Friday, 1 June 2012 15:16 >>>> To: John C. Turnbull >>>> Cc: openjfx-dev at openjdk.java.net >>>> Subject: Re: LCD font smoothing in Text has no effect >>>> >>>> I think you should try this outside of scene builder first to eliminate >>>> that. >>>> If SceneBuilder is creating a shaped window and you are embedded in it then >>>> you won't get LCD text. >>>> >>>> -phil. >>>> >>>> On 5/31/12 10:01 PM, John C. Turnbull wrote: >>>>> All I am doing is placing a Text object on top of a filled Rectangle >>>>> in Scene Builder b40. >>>>> >>>>> Cheers, >>>>> >>>>> -jct >>>>> >>>>> -----Original Message----- >>>>> From: Phil Race [mailto:philip.race at oracle.com] >>>>> Sent: Friday, 1 June 2012 14:23 >>>>> To: John C. Turnbull >>>>> Cc: openjfx-dev at openjdk.java.net >>>>> Subject: Re: LCD font smoothing in Text has no effect >>>>> >>>>> So are you using a shaped window or transparency ? >>>>> In those cases you may get grayscale. The most recent 2.2 builds will >>>>> fix this IFF the transparency is not under the text pixels. >>>>> >>>>> -phil. >>>>> >>>>> On 5/31/12 9:19 PM, John C. Turnbull wrote: >>>>>> Looks like I am getting Direct3D... >>>>>> >>>>>> Prism pipeline init order: d3d j2d >>>>>> Using t2k for text rasterization >>>>>> Using dirty region optimizations >>>>>> Prism pipeline name = com.sun.prism.d3d.D3DPipeline Loading D3D >>>>>> native library ... >>>>>> succeeded. >>>>>> Direct3D initialization succeeded >>>>>> (X) Got class = class com.sun.prism.d3d.D3DPipeline Initialized prism >>>>>> pipeline: com.sun.prism.d3d.D3DPipeline OS Information: >>>>>> Windows 7 build 7601 >>>>>> D3D Driver Information: >>>>>> NVIDIA Quadro FX 5800 >>>>>> \\.\DISPLAY1 >>>>>> Driver nvd3dumx.dll, version 8.17.12.9635 >>>>>> Pixel Shader version 3.0 >>>>>> Device : ven_10DE, dev_05FD, subsys_059310DE >>>>>> >>>>>> ...but I still get greyscale antialiasing. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> -jct >>>>>> >>>>>> -----Original Message----- >>>>>> From: Phil Race [mailto:philip.race at oracle.com] >>>>>> Sent: Friday, 1 June 2012 13:50 >>>>>> To: John C. Turnbull >>>>>> Cc: openjfx-dev at openjdk.java.net >>>>>> Subject: Re: LCD font smoothing in Text has no effect >>>>>> >>>>>> -Dprism.verbose=true to see which renderer is used. >>>>>> >>>>>> Are you getting 2D or D3D/OGL ? >>>>>> >>>>>> 2D isn't set up to do it and we probably won't fix that because it >>>>>> won't matter once we stop using it in 3.0 >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 5/31/12 8:36 PM, John C. Turnbull wrote: >>>>>>> I have never been able to see any difference when I set the font >>>>>>> smoothing option to LCD in a Text control even with the latest >>>>>>> JavaFX >>>>>>> 2.2 drop. Gray scale antialiasing is still in use. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Is this something likely to be fixed soon? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> >>>>>>> >>>>>>> -jct >>>>>>> >>>> >>> > From hang.vo at oracle.com Fri Jun 1 16:32:36 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 01 Jun 2012 23:32:36 +0000 Subject: hg: openjfx/2.2/controls/rt: Fixed RT-19171: [TextArea, Linux] text under selection can be white and black Message-ID: <20120601233237.C650747696@hg.openjdk.java.net> Changeset: d7e46d20f756 Author: leifs Date: 2012-06-01 16:25 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/d7e46d20f756 Fixed RT-19171: [TextArea, Linux] text under selection can be white and black ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java From hang.vo at oracle.com Fri Jun 1 18:33:03 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 02 Jun 2012 01:33:03 +0000 Subject: hg: openjfx/2.2/graphics/rt: 3 new changesets Message-ID: <20120602013309.487824769A@hg.openjdk.java.net> Changeset: 63b0d121d3cd Author: kcr Date: 2012-06-01 16:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/63b0d121d3cd RT-21973: Suppress warning message when Toolkit is unable to load msvcr100.dll Reviewed by Igor ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java Changeset: 9be4d697d70f Author: kcr Date: 2012-06-01 16:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/9be4d697d70f RT-21789: node snapshot: wrong snapshot area Reviewed by Jim ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: a2b59544661f Author: kcr Date: 2012-06-01 16:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a2b59544661f RT-21924: Passing in a null Callback as an argument to snapshot should throw NPE back to caller Reviewed by Jim ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java From jmartine_1026 at yahoo.com Fri Jun 1 21:51:26 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Fri, 1 Jun 2012 21:51:26 -0700 (PDT) Subject: problem with PathTransition causing flickering of its Node In-Reply-To: <3BD2EDBF-5A71-49FB-8D5F-F606A016CBBE@oracle.com> References: <1338561424.20028.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FC8D76A.2030702@oracle.com> <4FC8DB22.2040704@oracle.com> <1338563955.89149.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FC8E18C.9000108@oracle.com> <1338565204.9321.YahooMailNeo@web160901.mail.bf1.yahoo.com> <1338566664.16717.YahooMailNeo@web160903.mail.bf1.yahoo.com> <3BD2EDBF-5A71-49FB-8D5F-F606A016CBBE@oracle.com> Message-ID: <1338612686.88630.YahooMailNeo@web160906.mail.bf1.yahoo.com> After testing thoroughly I have not seen flickering return. ?Also, while using the prism options (-Dprism.dirtyopts=false -Dprism.verbose=true) I do not see the ghost images occurring on the projectiles. But I am still seeing these two issues... 1) ?If the PathTransition has a very slow rate then their nodes will be invisible. 2) ?In the game there is a turret with a long barrel that follows your mouse (using onMouseMoved). ?If I move the mouse up through the middle of the turret so that the rotation angle changes by 180 degrees in one instance, then the barrel will flip to the other side leaving a ghost image of the barrel at its previous position. ?The ghost image disappears once something gets drawn at its position. BTW, thank you for to all those that responded so far, that flickering issue was stressing me out. jose ________________________________ From: Richard Bair To: Jose Martinez Cc: Kevin Rushforth ; "openjfx-dev at openjdk.java.net" Sent: Friday, June 1, 2012 4:17 PM Subject: Re: problem with PathTransition causing flickering of its Node OK cool, the flickering images was surprising but good to see it isn't there on the latest :-). As for the other issue, that one is almost certainly a dirty region bug, in which case setting dirty opts off should fix it. Richard On Jun 1, 2012, at 9:04 AM, Jose Martinez wrote: > Kevin, > > Just a few tests and I do NOT see the flickering.? Wow i'm pretty impressed.? I will continue to run tests through today and into tonight.? I'll respond with an update tonight. > > BTW, I am going to send out another email for this other problem I am having but figure I give a heads up now since I still see the problem happening in 2.2.? I get ghost images (images remaining after they have moved).? Where the enemy units use PathTransitions to move, the projectiles use a Timeline that binds to the projectiles TranslateYProperty.? I'll send another email for this issue, but it is happening in 2.2.? >? > thanks > jose > > > ________________________________ > From: Jose Martinez > To: Kevin Rushforth > Cc: "openjfx-dev at openjdk.java.net" > Sent: Friday, June 1, 2012 11:40 AM > Subject: Re: problem with PathTransition causing flickering of its Node > > Ok i'll do that now. >? > jose > > > ________________________________ > From: Kevin Rushforth > To: Jose Martinez > Cc: "steve.x.northover at oracle.com" ; "openjfx-dev at openjdk.java.net" > Sent: Friday, June 1, 2012 11:36 AM > Subject: Re: problem with PathTransition causing flickering of its Node > > Hi Jose, > > We are about to release JavaFX 2.2. Can you try it with the latest > developer preview version of 2.2? > > -- Kevin > > > Jose Martinez wrote: >> Steve, >> >> Here is all the information: >> >> Netbeans 7.2 (though this happened in 7.1) running as WebStart. >> Java 7u4 >> JFX 2.1 >> Windows 7 >> >> Doing the sample might be a little difficult but I will give it a try.? >> >> I wonder if there is a way I can setup my groups, maybe flatten the whole thing out so that there is less nested Groups, so that this would occur less. >>? >> thanks >> jose >> >> >> ________________________________ >>? From: "steve.x.northover at oracle.com" >> To: openjfx-dev at openjdk.java.net >> Sent: Friday, June 1, 2012 11:09 AM >> Subject: Re: problem with PathTransition causing flickering of its Node >>? >> First off, what platform are you on?? Second can you create a simple >> example that flickers and either post it here or enter a JIRA? >> >> Thanks! >> Steve >> >> On 01/06/2012 11:05 AM, Joseph Andresen wrote: >>? >>> Can you describe the state of the scene? Are you using a perspective camera? >>> >>> >>> >>> On Jun 1, 2012, at 7:53 AM, Kevin Rushforth? wrote: >>> >>>? ? >>>> One thing to try: can you run it with "-Dprism.dirtyopts=false" and see if the problem persists? >>>> >>>> In any case, please file a JIRA bug against the "Animation" component. >>>> >>>> -- Kevin >>>> >>>> >>>> Jose Martinez wrote: >>>>? ? ? >>>>> In the project (a video game) I am working on I use a lot of PathTransitions to move enemy units across the map. I am noticing flickering of the Nodes in the PathTransitions. By flickering I mean they lose and gain visibility. It does not happen all the time. The paths are pretty simple Shapes... straight lines. I am using Orthogonal orientation. >>>>> >>>>> here are some things I have noticed.... >>>>> >>>>> 1) There is an increase in flickering occurring when there is a lot happening on the screen. >>>>> 2) There is an increase in flickering when the PathTransition's Node is moving over another Node. >>>>> 3) Points 1 and 2 might be related or have the same root cause but its hard to tell. >>>>> 4) If I change the rate of PathTransition to a low number (so that the Node is moving really slow) then the Node just becomes non-visible (cant see it on the screen) yet it is there because the projectiles in the game that are shooting the Nodes are in fact striking them, so you can tell that the Node is in fact moving along the path but just not visible.? UPDATE:? This also happens when moving at non-slow regular rate as I found out last night. >>>>> 6) I do not suspect its a performance issue because when I do cause performance issues I get a studder not a flicker and the whole game slows up. While flickering the Node still moves smoothly through the path. >>>>> Currently the Node that I am using in this case is a Group with an ImageView and an invisible Rectangle in it.? This Group is inside another which is inside another Group which is inside the root Scene. >>>>> >>>>> Any ideas what could be causing the flickering? >>>>> >>>>> thanks >>>>> jose >>>>> >>>>>? ? ? ? From jmartine_1026 at yahoo.com Fri Jun 1 22:35:35 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Fri, 1 Jun 2012 22:35:35 -0700 (PDT) Subject: gc options for best JFX performance Message-ID: <1338615335.99438.YahooMailNeo@web160906.mail.bf1.yahoo.com> Hello, I have tried the following GC modes but none of them get rid of the?noticeable 'stop the world' delays. -XX:+UseParallelGC? -XX:-UseParallelOldGC -XX:-UseParNewGC? -XX:+UseConcMarkSweepGC Out of those my favorite so far is?UseParNewGC. I also use the following options. --Xms150m -Xmx200m ?-XX:MaxGCPauseMillis=1?? ? Are there other options that you would recommend? ?Has anyone come up with a concoction of options that works best or a rule of thumb for configuring GC in JFX applications? If I cannot find a good set of options I will have to resort to calling System.gc() at strategic intervals. ? thanks jose From goddard at seznam.cz Sat Jun 2 01:52:39 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Sat, 02 Jun 2012 10:52:39 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20gc=20options=20for=20best=20JFX=20performance?= In-Reply-To: <1338615335.99438.YahooMailNeo@web160906.mail.bf1.yahoo.com> Message-ID: <128787.9377.27812-4781-85080501-1338627159@seznam.cz> Hi, I believe there're no generic JVM settings for "best performance" Until you have perf. issues, I'd live with the default. If you want to do perf. tuning, it's application / environment dependent. Identify your bottleneck (network, i/o, memory, code etc.) and then try specific settings for that one. If you have big GC pauses, think about how much memory your app uses and if the heap is not too large, or what's the lifetime of objects in your app and adjust the generations in the heap accordingly. Regards, Jiri ------------ P?vodn? zpr?va ------------ Od: Jose Martinez P?edm?t: gc options for best JFX performance Datum: 02.6.2012 07:36:54 ---------------------------------------- Hello, I have tried the following GC modes but none of them get rid of the?noticeable 'stop the world' delays. -XX:+UseParallelGC? -XX:-UseParallelOldGC -XX:-UseParNewGC? -XX:+UseConcMarkSweepGC Out of those my favorite so far is?UseParNewGC. I also use the following options. --Xms150m -Xmx200m ?-XX:MaxGCPauseMillis=1?? ? Are there other options that you would recommend? ?Has anyone come up with a concoction of options that works best or a rule of thumb for configuring GC in JFX applications? If I cannot find a good set of options I will have to resort to calling System.gc() at strategic intervals. ? thanks jose From jmartine_1026 at yahoo.com Sat Jun 2 07:06:03 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Sat, 2 Jun 2012 07:06:03 -0700 (PDT) Subject: gc options for best JFX performance In-Reply-To: <128787.9377.27812-4781-85080501-1338627159@seznam.cz> References: <1338615335.99438.YahooMailNeo@web160906.mail.bf1.yahoo.com> <128787.9377.27812-4781-85080501-1338627159@seznam.cz> Message-ID: <1338645963.21954.YahooMailNeo@web160905.mail.bf1.yahoo.com> Thanks Jiri. ?Yeah I understand those things. ?I was naively hoping that there was some magic concoction of JVM options that works ideally for JFX apps. I try very hard not to create new objects during game play but because the KeyFrame and KeyValue classes ?immutable I imagine that those are what are building up in memory and getting cleaned up by the GC. ?I create all my projectiles and enemy units before the round begins. ?But with each shot fired I have to create KeyFrames and KeyValues to send the projectile to its destination. ?Maybe making those classes non-immutable will help in keeping memory down. ?I imagine there might be some complexity to changing a Keyframe that is attached to a Timeline, or a KayValue that is attached to a KeyFrame, which is?probably?why they were designed to be immutable. Also I have to create new Duration objects to keep track of time. thanks jose ________________________________ From: "goddard at seznam.cz" To: Jose Martinez Cc: openjfx mailing list Sent: Saturday, June 2, 2012 4:52 AM Subject: Re: gc options for best JFX performance Hi, I believe there're no generic JVM settings for "best performance" Until you have perf. issues, I'd live with the default. If you want to do perf. tuning, it's application / environment dependent. Identify your bottleneck (network, i/o, memory, code etc.) and then try specific settings for that one. If you have big GC pauses, think about how much memory your app uses and if the heap is not too large, or what's the lifetime of objects in your app and adjust the generations in the heap accordingly. Regards, Jiri ------------ P?vodn? zpr?va ------------ Od: Jose Martinez P?edm?t: gc options for best JFX performance Datum: 02.6.2012 07:36:54 ---------------------------------------- Hello, I have tried the following GC modes but none of them get rid of the?noticeable 'stop the world' delays. -XX:+UseParallelGC? -XX:-UseParallelOldGC -XX:-UseParNewGC? -XX:+UseConcMarkSweepGC Out of those my favorite so far is?UseParNewGC. I also use the following options. --Xms150m -Xmx200m ?-XX:MaxGCPauseMillis=1?? ? Are there other options that you would recommend? ?Has anyone come up with a concoction of options that works best or a rule of thumb for configuring GC in JFX applications? If I cannot find a good set of options I will have to resort to calling System.gc() at strategic intervals. ? thanks jose From goddard at seznam.cz Sat Jun 2 09:16:59 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Sat, 02 Jun 2012 18:16:59 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Re=3A=20gc=20options=20for=20best=20JFX=20performance?= In-Reply-To: <1338645963.21954.YahooMailNeo@web160905.mail.bf1.yahoo.com> Message-ID: <128795.9372.27797-23404-1609599015-1338653819@seznam.cz> Hi Jose, you don't have to build the Timeline animation objects dynamically, e. g. use "new KeyFrame" or "new KeyValue" each time you trigger firing. You can create them earlier, before you enter the event handler. In addition, I think that the animation API is highly optimized so it doesn't create too many objects etc. Take a heap dump, java core and analyze it. Or you can use the application profiler (VisualVM) in Netbeans. Unless you know exactly what's going on, it's hard to make the right decision and move forward. Regards, Jiri ------------ P?vodn? zpr?va ------------ Od: Jose Martinez P?edm?t: Re: gc options for best JFX performance Datum: 02.6.2012 16:21:52 ---------------------------------------- Thanks Jiri. ?Yeah I understand those things. ?I was naively hoping that there was some magic concoction of JVM options that works ideally for JFX apps. I try very hard not to create new objects during game play but because the KeyFrame and KeyValue classes ?immutable I imagine that those are what are building up in memory and getting cleaned up by the GC. ?I create all my projectiles and enemy units before the round begins. ?But with each shot fired I have to create KeyFrames and KeyValues to send the projectile to its destination. ?Maybe making those classes non-immutable will help in keeping memory down. ?I imagine there might be some complexity to changing a Keyframe that is attached to a Timeline, or a KayValue that is attached to a KeyFrame, which is?probably?why they were designed to be immutable. Also I have to create new Duration objects to keep track of time. thanks jose ________________________________ From: "goddard at seznam.cz" To: Jose Martinez Cc: openjfx mailing list Sent: Saturday, June 2, 2012 4:52 AM Subject: Re: gc options for best JFX performance Hi, I believe there're no generic JVM settings for "best performance" Until you have perf. issues, I'd live with the default. If you want to do perf. tuning, it's application / environment dependent. Identify your bottleneck (network, i/o, memory, code etc.) and then try specific settings for that one. If you have big GC pauses, think about how much memory your app uses and if the heap is not too large, or what's the lifetime of objects in your app and adjust the generations in the heap accordingly. Regards, Jiri ------------ P?vodn? zpr?va ------------ Od: Jose Martinez P?edm?t: gc options for best JFX performance Datum: 02.6.2012 07:36:54 ---------------------------------------- Hello, I have tried the following GC modes but none of them get rid of the?noticeable 'stop the world' delays. -XX:+UseParallelGC? -XX:-UseParallelOldGC -XX:-UseParNewGC? -XX:+UseConcMarkSweepGC Out of those my favorite so far is?UseParNewGC. I also use the following options. --Xms150m -Xmx200m ?-XX:MaxGCPauseMillis=1?? ? Are there other options that you would recommend? ?Has anyone come up with a concoction of options that works best or a rule of thumb for configuring GC in JFX applications? If I cannot find a good set of options I will have to resort to calling System.gc() at strategic intervals. ? thanks jose From richard.bair at oracle.com Sat Jun 2 12:13:21 2012 From: richard.bair at oracle.com (Richard Bair) Date: Sat, 2 Jun 2012 12:13:21 -0700 Subject: gc options for best JFX performance In-Reply-To: <128795.9372.27797-23404-1609599015-1338653819@seznam.cz> References: <128795.9372.27797-23404-1609599015-1338653819@seznam.cz> Message-ID: I would be interested in seeing how much time is being spent in GC. Sometimes the best thing is to have a small heap size -- maybe you ought to try to set it to 32M or something (not sure how small you can make it and still fit all your images etc in the heap). Large heaps lead to longer pauses (of course my data may be out of date). Also are you running on Mac or Windows? ON Mac we've got some synchronization issues which I think were just very recently fixed, so you would get jerky animations, whereas on Windows it should be pretty smooth. Richard On Jun 2, 2012, at 9:16 AM, goddard at seznam.cz wrote: > Hi Jose, > > you don't have to build the Timeline animation objects dynamically, e. g. use "new KeyFrame" or "new KeyValue" each time you trigger firing. You can create them earlier, before you enter the event handler. > In addition, I think that the animation API is highly optimized so it doesn't create too many objects etc. > Take a heap dump, java core and analyze it. Or you can use the application profiler (VisualVM) in Netbeans. > Unless you know exactly what's going on, it's hard to make the right decision and move forward. > > Regards, Jiri > > ------------ P?vodn? zpr?va ------------ > Od: Jose Martinez > P?edm?t: Re: gc options for best JFX performance > Datum: 02.6.2012 16:21:52 > ---------------------------------------- > Thanks Jiri. Yeah I understand those things. I was naively hoping that there > was some magic concoction of JVM options that works ideally for JFX apps. > > I try very hard not to create new objects during game play but because the > KeyFrame and KeyValue classes immutable I imagine that those are what are > building up in memory and getting cleaned up by the GC. I create all my > projectiles and enemy units before the round begins. But with each shot fired I > have to create KeyFrames and KeyValues to send the projectile to its > destination. Maybe making those classes non-immutable will help in keeping > memory down. I imagine there might be some complexity to changing a Keyframe > that is attached to a Timeline, or a KayValue that is attached to a KeyFrame, > which is probably why they were designed to be immutable. > > Also I have to create new Duration objects to keep track of time. > > thanks > jose > > > ________________________________ > From: "goddard at seznam.cz" > To: Jose Martinez > Cc: openjfx mailing list > Sent: Saturday, June 2, 2012 4:52 AM > Subject: Re: gc options for best JFX performance > > Hi, > > I believe there're no generic JVM settings for "best performance" Until you have > perf. issues, I'd live with the default. > If you want to do perf. tuning, it's application / environment dependent. > Identify your bottleneck (network, i/o, memory, code etc.) and then try specific > settings for that one. > If you have big GC pauses, think about how much memory your app uses and if the > heap is not too large, or what's the lifetime of objects in your app and adjust > the generations in the heap accordingly. > > Regards, Jiri > > ------------ P?vodn? zpr?va ------------ > Od: Jose Martinez > P?edm?t: gc options for best JFX performance > Datum: 02.6.2012 07:36:54 > ---------------------------------------- > Hello, > > I have tried the following GC modes but none of them get rid of the noticeable > 'stop the world' delays. > > -XX:+UseParallelGC > > -XX:-UseParallelOldGC > > -XX:-UseParNewGC > > -XX:+UseConcMarkSweepGC > > > Out of those my favorite so far is UseParNewGC. > > I also use the following options. > --Xms150m -Xmx200m -XX:MaxGCPauseMillis=1 > > > Are there other options that you would recommend? Has anyone come up with a > concoction of options that works best or a rule of thumb for configuring GC in > JFX applications? > > If I cannot find a good set of options I will have to resort to calling > System.gc() at strategic intervals. > > thanks > jose > > From hjohn at xs4all.nl Sat Jun 2 15:49:49 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Sun, 03 Jun 2012 00:49:49 +0200 Subject: gc options for best JFX performance In-Reply-To: <1338645963.21954.YahooMailNeo@web160905.mail.bf1.yahoo.com> References: <1338615335.99438.YahooMailNeo@web160906.mail.bf1.yahoo.com> <128787.9377.27812-4781-85080501-1338627159@seznam.cz> <1338645963.21954.YahooMailNeo@web160905.mail.bf1.yahoo.com> Message-ID: <4FCA988D.30401@xs4all.nl> I really don't think a few KeyFrame and KeyValues is going to have any impact -- making them mutable is not going to happen. Just moving the mouse over the screen is going to create more objects than that. Create some heap dumps, look through them, or profile your application and find out where you might be able to optimize a bit -- it's often surprising where the real memory/performance issues are coming from. On 2/06/2012 16:06, Jose Martinez wrote: > Thanks Jiri. Yeah I understand those things. I was naively hoping that there was some magic concoction of JVM options that works ideally for JFX apps. > > I try very hard not to create new objects during game play but because the KeyFrame and KeyValue classes immutable I imagine that those are what are building up in memory and getting cleaned up by the GC. I create all my projectiles and enemy units before the round begins. But with each shot fired I have to create KeyFrames and KeyValues to send the projectile to its destination. Maybe making those classes non-immutable will help in keeping memory down. I imagine there might be some complexity to changing a Keyframe that is attached to a Timeline, or a KayValue that is attached to a KeyFrame, which is probably why they were designed to be immutable. > > Also I have to create new Duration objects to keep track of time. > > thanks > jose > > > ________________________________ > From: "goddard at seznam.cz" > To: Jose Martinez > Cc: openjfx mailing list > Sent: Saturday, June 2, 2012 4:52 AM > Subject: Re: gc options for best JFX performance > > Hi, > > I believe there're no generic JVM settings for "best performance" Until you have perf. issues, I'd live with the default. > If you want to do perf. tuning, it's application / environment dependent. Identify your bottleneck (network, i/o, memory, code etc.) and then try specific settings for that one. > If you have big GC pauses, think about how much memory your app uses and if the heap is not too large, or what's the lifetime of objects in your app and adjust the generations in the heap accordingly. > > Regards, Jiri > > ------------ P?vodn? zpr?va ------------ > Od: Jose Martinez > P?edm?t: gc options for best JFX performance > Datum: 02.6.2012 07:36:54 > ---------------------------------------- > Hello, > > I have tried the following GC modes but none of them get rid of the noticeable > 'stop the world' delays. > > -XX:+UseParallelGC > > -XX:-UseParallelOldGC > > -XX:-UseParNewGC > > -XX:+UseConcMarkSweepGC > > > Out of those my favorite so far is UseParNewGC. > > I also use the following options. > --Xms150m -Xmx200m -XX:MaxGCPauseMillis=1 > > > Are there other options that you would recommend? Has anyone come up with a > concoction of options that works best or a rule of thumb for configuring GC in > JFX applications? > > If I cannot find a good set of options I will have to resort to calling > System.gc() at strategic intervals. > > thanks > jose > From jmartine_1026 at yahoo.com Sat Jun 2 21:26:34 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Sat, 2 Jun 2012 21:26:34 -0700 (PDT) Subject: problem with PathTransition causing flickering of its Node In-Reply-To: <1338612686.88630.YahooMailNeo@web160906.mail.bf1.yahoo.com> References: <1338561424.20028.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FC8D76A.2030702@oracle.com> <4FC8DB22.2040704@oracle.com> <1338563955.89149.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FC8E18C.9000108@oracle.com> <1338565204.9321.YahooMailNeo@web160901.mail.bf1.yahoo.com> <1338566664.16717.YahooMailNeo@web160903.mail.bf1.yahoo.com> <3BD2EDBF-5A71-49FB-8D5F-F606A016CBBE@oracle.com> <1338612686.88630.YahooMailNeo@web160906.mail.bf1.yahoo.com> Message-ID: <1338697594.10140.YahooMailNeo@web160905.mail.bf1.yahoo.com> Was able to reproduce the ghost image artifact in test code. ?Here is a screen shot of it occurring. https://s3.amazonaws.com/turretmaster/images/ghostImage.png? jira issue created...?http://javafx-jira.kenai.com/browse/RT-22002 thanks jose ________________________________ From: Jose Martinez To: "openjfx-dev at openjdk.java.net" Sent: Saturday, June 2, 2012 12:51 AM Subject: Re: problem with PathTransition causing flickering of its Node After testing thoroughly I have not seen flickering return. ?Also, while using the prism options (-Dprism.dirtyopts=false -Dprism.verbose=true) I do not see the ghost images occurring on the projectiles. But I am still seeing these two issues... 1) ?If the PathTransition has a very slow rate then their nodes will be invisible. 2) ?In the game there is a turret with a long barrel that follows your mouse (using onMouseMoved). ?If I move the mouse up through the middle of the turret so that the rotation angle changes by 180 degrees in one instance, then the barrel will flip to the other side leaving a ghost image of the barrel at its previous position. ?The ghost image disappears once something gets drawn at its position. BTW, thank you for to all those that responded so far, that flickering issue was stressing me out. jose ________________________________ From: Richard Bair To: Jose Martinez Cc: Kevin Rushforth ; "openjfx-dev at openjdk.java.net" Sent: Friday, June 1, 2012 4:17 PM Subject: Re: problem with PathTransition causing flickering of its Node OK cool, the flickering images was surprising but good to see it isn't there on the latest :-). As for the other issue, that one is almost certainly a dirty region bug, in which case setting dirty opts off should fix it. Richard On Jun 1, 2012, at 9:04 AM, Jose Martinez wrote: > Kevin, > > Just a few tests and I do NOT see the flickering.? Wow i'm pretty impressed.? I will continue to run tests through today and into tonight.? I'll respond with an update tonight. > > BTW, I am going to send out another email for this other problem I am having but figure I give a heads up now since I still see the problem happening in 2.2.? I get ghost images (images remaining after they have moved).? Where the enemy units use PathTransitions to move, the projectiles use a Timeline that binds to the projectiles TranslateYProperty.? I'll send another email for this issue, but it is happening in 2.2.? >? > thanks > jose > > > ________________________________ > From: Jose Martinez > To: Kevin Rushforth > Cc: "openjfx-dev at openjdk.java.net" > Sent: Friday, June 1, 2012 11:40 AM > Subject: Re: problem with PathTransition causing flickering of its Node > > Ok i'll do that now. >? > jose > > > ________________________________ > From: Kevin Rushforth > To: Jose Martinez > Cc: "steve.x.northover at oracle.com" ; "openjfx-dev at openjdk.java.net" > Sent: Friday, June 1, 2012 11:36 AM > Subject: Re: problem with PathTransition causing flickering of its Node > > Hi Jose, > > We are about to release JavaFX 2.2. Can you try it with the latest > developer preview version of 2.2? > > -- Kevin > > > Jose Martinez wrote: >> Steve, >> >> Here is all the information: >> >> Netbeans 7.2 (though this happened in 7.1) running as WebStart. >> Java 7u4 >> JFX 2.1 >> Windows 7 >> >> Doing the sample might be a little difficult but I will give it a try.? >> >> I wonder if there is a way I can setup my groups, maybe flatten the whole thing out so that there is less nested Groups, so that this would occur less. >>? >> thanks >> jose >> >> >> ________________________________ >>? From: "steve.x.northover at oracle.com" >> To: openjfx-dev at openjdk.java.net >> Sent: Friday, June 1, 2012 11:09 AM >> Subject: Re: problem with PathTransition causing flickering of its Node >>? >> First off, what platform are you on?? Second can you create a simple >> example that flickers and either post it here or enter a JIRA? >> >> Thanks! >> Steve >> >> On 01/06/2012 11:05 AM, Joseph Andresen wrote: >>? >>> Can you describe the state of the scene? Are you using a perspective camera? >>> >>> >>> >>> On Jun 1, 2012, at 7:53 AM, Kevin Rushforth? wrote: >>> >>>? ? >>>> One thing to try: can you run it with "-Dprism.dirtyopts=false" and see if the problem persists? >>>> >>>> In any case, please file a JIRA bug against the "Animation" component. >>>> >>>> -- Kevin >>>> >>>> >>>> Jose Martinez wrote: >>>>? ? ? >>>>> In the project (a video game) I am working on I use a lot of PathTransitions to move enemy units across the map. I am noticing flickering of the Nodes in the PathTransitions. By flickering I mean they lose and gain visibility. It does not happen all the time. The paths are pretty simple Shapes... straight lines. I am using Orthogonal orientation. >>>>> >>>>> here are some things I have noticed.... >>>>> >>>>> 1) There is an increase in flickering occurring when there is a lot happening on the screen. >>>>> 2) There is an increase in flickering when the PathTransition's Node is moving over another Node. >>>>> 3) Points 1 and 2 might be related or have the same root cause but its hard to tell. >>>>> 4) If I change the rate of PathTransition to a low number (so that the Node is moving really slow) then the Node just becomes non-visible (cant see it on the screen) yet it is there because the projectiles in the game that are shooting the Nodes are in fact striking them, so you can tell that the Node is in fact moving along the path but just not visible.? UPDATE:? This also happens when moving at non-slow regular rate as I found out last night. >>>>> 6) I do not suspect its a performance issue because when I do cause performance issues I get a studder not a flicker and the whole game slows up. While flickering the Node still moves smoothly through the path. >>>>> Currently the Node that I am using in this case is a Group with an ImageView and an invisible Rectangle in it.? This Group is inside another which is inside another Group which is inside the root Scene. >>>>> >>>>> Any ideas what could be causing the flickering? >>>>> >>>>> thanks >>>>> jose >>>>> >>>>>? ? ? ? From jmartine_1026 at yahoo.com Sun Jun 3 08:03:18 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Sun, 3 Jun 2012 08:03:18 -0700 (PDT) Subject: gc options for best JFX performance In-Reply-To: <4FCA988D.30401@xs4all.nl> References: <1338615335.99438.YahooMailNeo@web160906.mail.bf1.yahoo.com> <128787.9377.27812-4781-85080501-1338627159@seznam.cz> <1338645963.21954.YahooMailNeo@web160905.mail.bf1.yahoo.com> <4FCA988D.30401@xs4all.nl> Message-ID: <1338735798.70058.YahooMailNeo@web160905.mail.bf1.yahoo.com> Thanks a lot guys for the good feedback. ?I'll follow up on it over the next few days. ?If anything pops up relating JFX I'll respond. thanks jose ________________________________ From: John Hendrikx To: openjfx-dev at openjdk.java.net Sent: Saturday, June 2, 2012 6:49 PM Subject: Re: gc options for best JFX performance I really don't think a few KeyFrame and KeyValues is going to have any impact -- making them mutable is not going to happen.? Just moving the mouse over the screen is going to create more objects than that. Create some heap dumps, look through them, or profile your application and find out where you might be able to optimize a bit -- it's often surprising where the real memory/performance issues are coming from. On 2/06/2012 16:06, Jose Martinez wrote: > Thanks Jiri.? Yeah I understand those things.? I was naively hoping that there was some magic concoction of JVM options that works ideally for JFX apps. > > I try very hard not to create new objects during game play but because the KeyFrame and KeyValue classes? immutable I imagine that those are what are building up in memory and getting cleaned up by the GC.? I create all my projectiles and enemy units before the round begins.? But with each shot fired I have to create KeyFrames and KeyValues to send the projectile to its destination.? Maybe making those classes non-immutable will help in keeping memory down.? I imagine there might be some complexity to changing a Keyframe that is attached to a Timeline, or a KayValue that is attached to a KeyFrame, which is probably why they were designed to be immutable. > > Also I have to create new Duration objects to keep track of time. > > thanks > jose > > > ________________________________ >? From: "goddard at seznam.cz" > To: Jose Martinez > Cc: openjfx mailing list > Sent: Saturday, June 2, 2012 4:52 AM > Subject: Re: gc options for best JFX performance > > Hi, > > I believe there're no generic JVM settings for "best performance" Until you have perf. issues, I'd live with the default. > If you want to do perf. tuning, it's application / environment dependent. Identify your bottleneck (network, i/o, memory, code etc.) and then try specific settings for that one. > If you have big GC pauses, think about how much memory your app uses and if the heap is not too large, or what's the lifetime of objects in your app and adjust the generations in the heap accordingly. > > Regards, Jiri > > ------------ P?vodn? zpr?va ------------ > Od: Jose Martinez > P?edm?t: gc options for best JFX performance > Datum: 02.6.2012 07:36:54 > ---------------------------------------- > Hello, > > I have tried the following GC modes but none of them get rid of the noticeable > 'stop the world' delays. > > -XX:+UseParallelGC > > -XX:-UseParallelOldGC > > -XX:-UseParNewGC > > -XX:+UseConcMarkSweepGC > > > Out of those my favorite so far is UseParNewGC. > > I also use the following options. > --Xms150m -Xmx200m? -XX:MaxGCPauseMillis=1? > >? > Are there other options that you would recommend?? Has anyone come up with a > concoction of options that works best or a rule of thumb for configuring GC in > JFX applications? > > If I cannot find a good set of options I will have to resort to calling > System.gc() at strategic intervals. >? > thanks > jose > From michael.heinrichs at oracle.com Mon Jun 4 01:25:59 2012 From: michael.heinrichs at oracle.com (Michael Heinrichs) Date: Mon, 4 Jun 2012 10:25:59 +0200 Subject: gc options for best JFX performance In-Reply-To: <1338735798.70058.YahooMailNeo@web160905.mail.bf1.yahoo.com> References: <1338615335.99438.YahooMailNeo@web160906.mail.bf1.yahoo.com> <128787.9377.27812-4781-85080501-1338627159@seznam.cz> <1338645963.21954.YahooMailNeo@web160905.mail.bf1.yahoo.com> <4FCA988D.30401@xs4all.nl> <1338735798.70058.YahooMailNeo@web160905.mail.bf1.yahoo.com> Message-ID: <6D563220-B773-489D-966E-92A51DADE97C@oracle.com> Hi Jose, just two short questions so I understand your use case better. Are you using PathTransition (as your other mail suggests) or Timeline for your animations? I think Timeline is pretty compact while PathTransition has room for improvements. :-) Nobody (I know of) used PathTransition extensively so far and it never became a priority. Maybe your case can change that. About how many moving objects are we talking? If you have really a lot of objects, say hundreds, you may be better off writing your own animation routine based on AnimationTimer. The classes you find in the JavaFX runtime are usually optimized for fast performance first and memory only second. If memory is your main concern, a custom implementation can give you significant improvements, especially if most of your animations are similar and you can take advantage of that. - Michael On 03.06.2012, at 17:03, Jose Martinez wrote: > Thanks a lot guys for the good feedback. I'll follow up on it over the next few days. If anything pops up relating JFX I'll respond. > > thanks > jose > > > ________________________________ > From: John Hendrikx > To: openjfx-dev at openjdk.java.net > Sent: Saturday, June 2, 2012 6:49 PM > Subject: Re: gc options for best JFX performance > > I really don't think a few KeyFrame and KeyValues is going to have any > impact -- making them mutable is not going to happen. Just moving the > mouse over the screen is going to create more objects than that. > > Create some heap dumps, look through them, or profile your application > and find out where you might be able to optimize a bit -- it's often > surprising where the real memory/performance issues are coming from. > > On 2/06/2012 16:06, Jose Martinez wrote: >> Thanks Jiri. Yeah I understand those things. I was naively hoping that there was some magic concoction of JVM options that works ideally for JFX apps. >> >> I try very hard not to create new objects during game play but because the KeyFrame and KeyValue classes immutable I imagine that those are what are building up in memory and getting cleaned up by the GC. I create all my projectiles and enemy units before the round begins. But with each shot fired I have to create KeyFrames and KeyValues to send the projectile to its destination. Maybe making those classes non-immutable will help in keeping memory down. I imagine there might be some complexity to changing a Keyframe that is attached to a Timeline, or a KayValue that is attached to a KeyFrame, which is probably why they were designed to be immutable. >> >> Also I have to create new Duration objects to keep track of time. >> >> thanks >> jose >> >> >> ________________________________ >> From: "goddard at seznam.cz" >> To: Jose Martinez >> Cc: openjfx mailing list >> Sent: Saturday, June 2, 2012 4:52 AM >> Subject: Re: gc options for best JFX performance >> >> Hi, >> >> I believe there're no generic JVM settings for "best performance" Until you have perf. issues, I'd live with the default. >> If you want to do perf. tuning, it's application / environment dependent. Identify your bottleneck (network, i/o, memory, code etc.) and then try specific settings for that one. >> If you have big GC pauses, think about how much memory your app uses and if the heap is not too large, or what's the lifetime of objects in your app and adjust the generations in the heap accordingly. >> >> Regards, Jiri >> >> ------------ P?vodn? zpr?va ------------ >> Od: Jose Martinez >> P?edm?t: gc options for best JFX performance >> Datum: 02.6.2012 07:36:54 >> ---------------------------------------- >> Hello, >> >> I have tried the following GC modes but none of them get rid of the noticeable >> 'stop the world' delays. >> >> -XX:+UseParallelGC >> >> -XX:-UseParallelOldGC >> >> -XX:-UseParNewGC >> >> -XX:+UseConcMarkSweepGC >> >> >> Out of those my favorite so far is UseParNewGC. >> >> I also use the following options. >> --Xms150m -Xmx200m -XX:MaxGCPauseMillis=1 >> >> >> Are there other options that you would recommend? Has anyone come up with a >> concoction of options that works best or a rule of thumb for configuring GC in >> JFX applications? >> >> If I cannot find a good set of options I will have to resort to calling >> System.gc() at strategic intervals. >> >> thanks >> jose >> From hang.vo at oracle.com Mon Jun 4 02:03:21 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Jun 2012 09:03:21 +0000 Subject: hg: openjfx/2.2/graphics/rt: Minor javadoc improvements for input events (fixes RT-22005). Message-ID: <20120604090326.37BBA476CB@hg.openjdk.java.net> Changeset: 2faa9edf67c9 Author: Pavel Safrata Date: 2012-06-04 10:56 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/2faa9edf67c9 Minor javadoc improvements for input events (fixes RT-22005). ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/KeyEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchEvent.java From tobi at ultramixer.com Mon Jun 4 02:06:52 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Mon, 4 Jun 2012 11:06:52 +0200 Subject: Painting images using PixelWriter Message-ID: Hi, since JFX 2.2 there is the new class PixelWriter. Would it be possible to draw Images like from a webcam using a shared ByteBuffer (or IntBuffer)? Wo what I would like to do is to fill a shared ByteBuffer from C (with JNI) and use the same bytebuffer for the JavaFX Image object.... Best regards, Tobi -- Tobias Bley Chief Executive Officer -------------------------------------------------------- UltraMixer Digital Audio Solutions Schillerstra?e 29 D-01326 Dresden Germany -------------------------------------------------------- bley at ultramixer.com http://www.ultramixer.com From jmartine_1026 at yahoo.com Mon Jun 4 08:33:46 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Mon, 4 Jun 2012 08:33:46 -0700 (PDT) Subject: gc options for best JFX performance In-Reply-To: <6D563220-B773-489D-966E-92A51DADE97C@oracle.com> References: <1338615335.99438.YahooMailNeo@web160906.mail.bf1.yahoo.com> <128787.9377.27812-4781-85080501-1338627159@seznam.cz> <1338645963.21954.YahooMailNeo@web160905.mail.bf1.yahoo.com> <4FCA988D.30401@xs4all.nl> <1338735798.70058.YahooMailNeo@web160905.mail.bf1.yahoo.com> <6D563220-B773-489D-966E-92A51DADE97C@oracle.com> Message-ID: <1338824026.26882.YahooMailNeo@web160905.mail.bf1.yahoo.com> That is correct, PathTransitions are being used extensively. During game play up to 500 enemy units attack in small waves (though this might go up to 1000 in future rounds). ?Each unit uses one PathTransition. ?Once the small waves begin, memory starts going up. ?At most there would be a few dozen units on screen at one time (PathTransitions running). So with regards to PathTransitions, do they use up memory while running or only an instantiation? ?So far I am not concerned with the overall memory footprint they use up while not running. ?With all the objects created before game play beings it comes out to about 100 - 150meg... this is very acceptable. ?I do not know where the memory tops off at because the GC kicks in but I would wager it goes up to 300 - 400 megs (i'll need to verify). There are a lot of ImageViews being added and removed from children ObservableList. ?Though I do not see how but could this be a source of memory usage? ?Every unit is animated and I created an AnimatedImageView class that flips through their List of ImageViews at very fast rates. ?I will test if there is memory usage related to adding/removing to ObservableList via this AnimatedImageView class. BTW, I strongly agree performance first memory second. ?I expect to do profiling of the code tonight. ?Will also look into custom PathTransitions as suggested. ?Thank you for the feedback, this conversation is sparking ideas that I would otherwise of not come up with. thanks jose ________________________________ From: Michael Heinrichs To: Jose Martinez Cc: "openjfx-dev at openjdk.java.net" Sent: Monday, June 4, 2012 4:25 AM Subject: Re: gc options for best JFX performance Hi Jose, just two short questions so I understand your use case better. Are you using PathTransition (as your other mail suggests) or Timeline for your animations? I think Timeline is pretty compact while PathTransition has room for improvements. :-) Nobody (I know of) used PathTransition extensively so far and it never became a priority. Maybe your case can change that. About how many moving objects are we talking? If you have really a lot of objects, say hundreds, you may be better off writing your own animation routine based on AnimationTimer. The classes you find in the JavaFX runtime are usually optimized for fast performance first and memory only second. If memory is your main concern, a custom implementation can give you significant improvements, especially if most of your animations are similar and you can take advantage of that. - Michael On 03.06.2012, at 17:03, Jose Martinez wrote: > Thanks a lot guys for the good feedback.? I'll follow up on it over the next few days.? If anything pops up relating JFX I'll respond. > > thanks > jose > > > ________________________________ > From: John Hendrikx > To: openjfx-dev at openjdk.java.net > Sent: Saturday, June 2, 2012 6:49 PM > Subject: Re: gc options for best JFX performance > > I really don't think a few KeyFrame and KeyValues is going to have any > impact -- making them mutable is not going to happen.? Just moving the > mouse over the screen is going to create more objects than that. > > Create some heap dumps, look through them, or profile your application > and find out where you might be able to optimize a bit -- it's often > surprising where the real memory/performance issues are coming from. > > On 2/06/2012 16:06, Jose Martinez wrote: >> Thanks Jiri.? Yeah I understand those things.? I was naively hoping that there was some magic concoction of JVM options that works ideally for JFX apps. >> >> I try very hard not to create new objects during game play but because the KeyFrame and KeyValue classes? immutable I imagine that those are what are building up in memory and getting cleaned up by the GC.? I create all my projectiles and enemy units before the round begins.? But with each shot fired I have to create KeyFrames and KeyValues to send the projectile to its destination.? Maybe making those classes non-immutable will help in keeping memory down.? I imagine there might be some complexity to changing a Keyframe that is attached to a Timeline, or a KayValue that is attached to a KeyFrame, which is probably why they were designed to be immutable. >> >> Also I have to create new Duration objects to keep track of time. >> >> thanks >> jose >> >> >> ________________________________ >>? ? From: "goddard at seznam.cz" >> To: Jose Martinez >> Cc: openjfx mailing list >> Sent: Saturday, June 2, 2012 4:52 AM >> Subject: Re: gc options for best JFX performance >> >> Hi, >> >> I believe there're no generic JVM settings for "best performance" Until you have perf. issues, I'd live with the default. >> If you want to do perf. tuning, it's application / environment dependent. Identify your bottleneck (network, i/o, memory, code etc.) and then try specific settings for that one. >> If you have big GC pauses, think about how much memory your app uses and if the heap is not too large, or what's the lifetime of objects in your app and adjust the generations in the heap accordingly. >> >> Regards, Jiri >> >> ------------ P?vodn? zpr?va ------------ >> Od: Jose Martinez >> P?edm?t: gc options for best JFX performance >> Datum: 02.6.2012 07:36:54 >> ---------------------------------------- >> Hello, >> >> I have tried the following GC modes but none of them get rid of the noticeable >> 'stop the world' delays. >> >> -XX:+UseParallelGC >> >> -XX:-UseParallelOldGC >> >> -XX:-UseParNewGC >> >> -XX:+UseConcMarkSweepGC >> >> >> Out of those my favorite so far is UseParNewGC. >> >> I also use the following options. >> --Xms150m -Xmx200m? -XX:MaxGCPauseMillis=1? >> >>? >> Are there other options that you would recommend?? Has anyone come up with a >> concoction of options that works best or a rule of thumb for configuring GC in >> JFX applications? >> >> If I cannot find a good set of options I will have to resort to calling >> System.gc() at strategic intervals. >>? >> thanks >> jose >> From hang.vo at oracle.com Mon Jun 4 10:17:58 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Jun 2012 17:17:58 +0000 Subject: hg: openjfx/2.2/graphics/rt: 2 new changesets Message-ID: <20120604171802.1B704476E2@hg.openjdk.java.net> Changeset: 87d53f13f4d4 Author: hudson Date: 2012-05-31 13:21 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/87d53f13f4d4 Added tag 2.2-b11 for changeset 85b700eea97b ! .hgtags Changeset: c795c8396f82 Author: Yao Wang Date: 2012-06-04 10:07 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/c795c8396f82 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt From goddard at seznam.cz Mon Jun 4 10:44:39 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Mon, 04 Jun 2012 19:44:39 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Re=3A=20gc=20options=20for=20best=20JFX=20performance?= In-Reply-To: <1338824026.26882.YahooMailNeo@web160905.mail.bf1.yahoo.com> Message-ID: <128851.9102.27644-19368-457210881-1338831879@seznam.cz> Wow, few dozens of enemies sounds like a lot at one time. What's the target resolution? Regarding the adding / removing nodes, do you use add / remove or toFront / toBack? The latter should be more effective. BTW would be nice to see the game :) Regards, Jiri ------------ P?vodn? zpr?va ------------ Od: Jose Martinez P?edm?t: Re: gc options for best JFX performance Datum: 04.6.2012 17:36:52 ---------------------------------------- That is correct, PathTransitions are being used extensively. During game play up to 500 enemy units attack in small waves (though this might go up to 1000 in future rounds). ?Each unit uses one PathTransition. ?Once the small waves begin, memory starts going up. ?At most there would be a few dozen units on screen at one time (PathTransitions running). So with regards to PathTransitions, do they use up memory while running or only an instantiation? ?So far I am not concerned with the overall memory footprint they use up while not running. ?With all the objects created before game play beings it comes out to about 100 - 150meg... this is very acceptable. ?I do not know where the memory tops off at because the GC kicks in but I would wager it goes up to 300 - 400 megs (i'll need to verify). There are a lot of ImageViews being added and removed from children ObservableList. ?Though I do not see how but could this be a source of memory usage? ?Every unit is animated and I created an AnimatedImageView class that flips through their List of ImageViews at very fast rates. ?I will test if there is memory usage related to adding/removing to ObservableList via this AnimatedImageView class. BTW, I strongly agree performance first memory second. ?I expect to do profiling of the code tonight. ?Will also look into custom PathTransitions as suggested. ?Thank you for the feedback, this conversation is sparking ideas that I would otherwise of not come up with. thanks jose ________________________________ From: Michael Heinrichs To: Jose Martinez Cc: "openjfx-dev at openjdk.java.net" Sent: Monday, June 4, 2012 4:25 AM Subject: Re: gc options for best JFX performance Hi Jose, just two short questions so I understand your use case better. Are you using PathTransition (as your other mail suggests) or Timeline for your animations? I think Timeline is pretty compact while PathTransition has room for improvements. :-) Nobody (I know of) used PathTransition extensively so far and it never became a priority. Maybe your case can change that. About how many moving objects are we talking? If you have really a lot of objects, say hundreds, you may be better off writing your own animation routine based on AnimationTimer. The classes you find in the JavaFX runtime are usually optimized for fast performance first and memory only second. If memory is your main concern, a custom implementation can give you significant improvements, especially if most of your animations are similar and you can take advantage of that. - Michael On 03.06.2012, at 17:03, Jose Martinez wrote: > Thanks a lot guys for the good feedback.? I'll follow up on it over the next few days.? If anything pops up relating JFX I'll respond. > > thanks > jose > > > ________________________________ > From: John Hendrikx > To: openjfx-dev at openjdk.java.net > Sent: Saturday, June 2, 2012 6:49 PM > Subject: Re: gc options for best JFX performance > > I really don't think a few KeyFrame and KeyValues is going to have any > impact -- making them mutable is not going to happen.? Just moving the > mouse over the screen is going to create more objects than that. > > Create some heap dumps, look through them, or profile your application > and find out where you might be able to optimize a bit -- it's often > surprising where the real memory/performance issues are coming from. > > On 2/06/2012 16:06, Jose Martinez wrote: >> Thanks Jiri.? Yeah I understand those things.? I was naively hoping that there was some magic concoction of JVM options that works ideally for JFX apps. >> >> I try very hard not to create new objects during game play but because the KeyFrame and KeyValue classes? immutable I imagine that those are what are building up in memory and getting cleaned up by the GC.? I create all my projectiles and enemy units before the round begins.? But with each shot fired I have to create KeyFrames and KeyValues to send the projectile to its destination.? Maybe making those classes non-immutable will help in keeping memory down.? I imagine there might be some complexity to changing a Keyframe that is attached to a Timeline, or a KayValue that is attached to a KeyFrame, which is probably why they were designed to be immutable. >> >> Also I have to create new Duration objects to keep track of time. >> >> thanks >> jose >> >> >> ________________________________ >>? ? From: "goddard at seznam.cz" >> To: Jose Martinez >> Cc: openjfx mailing list >> Sent: Saturday, June 2, 2012 4:52 AM >> Subject: Re: gc options for best JFX performance >> >> Hi, >> >> I believe there're no generic JVM settings for "best performance" Until you have perf. issues, I'd live with the default. >> If you want to do perf. tuning, it's application / environment dependent. Identify your bottleneck (network, i/o, memory, code etc.) and then try specific settings for that one. >> If you have big GC pauses, think about how much memory your app uses and if the heap is not too large, or what's the lifetime of objects in your app and adjust the generations in the heap accordingly. >> >> Regards, Jiri >> >> ------------ P?vodn? zpr?va ------------ >> Od: Jose Martinez >> P?edm?t: gc options for best JFX performance >> Datum: 02.6.2012 07:36:54 >> ---------------------------------------- >> Hello, >> >> I have tried the following GC modes but none of them get rid of the noticeable >> 'stop the world' delays. >> >> -XX:+UseParallelGC >> >> -XX:-UseParallelOldGC >> >> -XX:-UseParNewGC >> >> -XX:+UseConcMarkSweepGC >> >> >> Out of those my favorite so far is UseParNewGC. >> >> I also use the following options. >> --Xms150m -Xmx200m? -XX:MaxGCPauseMillis=1? >> >>? >> Are there other options that you would recommend?? Has anyone come up with a >> concoction of options that works best or a rule of thumb for configuring GC in >> JFX applications? >> >> If I cannot find a good set of options I will have to resort to calling >> System.gc() at strategic intervals. >>? >> thanks >> jose >> From hang.vo at oracle.com Mon Jun 4 10:48:00 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Jun 2012 17:48:00 +0000 Subject: hg: openjfx/2.2/controls/rt: Fix for RT-14177: -fx-skin can't work in OSGi-Envs. Tests forthcoming. Message-ID: <20120604174804.7B8DD476E3@hg.openjdk.java.net> Changeset: ba58ca4a265f Author: rbair Date: 2012-06-04 10:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/ba58ca4a265f Fix for RT-14177: -fx-skin can't work in OSGi-Envs. Tests forthcoming. ! javafx-ui-common/src/com/sun/javafx/Utils.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java From richard.bair at oracle.com Mon Jun 4 11:03:34 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 4 Jun 2012 11:03:34 -0700 Subject: Patch: issue RT-14177 In-Reply-To: <395446C7-1B53-4035-BA83-3AC263470D36@oracle.com> References: <201204051750.13667.fbrunnerlist@gmx.ch> <201206011638.06564.fbrunner@gmx.ch> <4FC8D548.8040901@bestsolution.at> <201206011810.09092.fbrunnerlist@gmx.ch> <4FC8EC11.5090609@bestsolution.at> <29140440-7968-4E40-8F2E-560674849A08@oracle.com> <1DE3DC4E-5E73-49F5-A324-4734AC2788E4@oracle.com> <03BF8184-4C57-400E-BCBE-234DB0F8A7BD@oracle.com> <4FC901DA.3050808@bestsolution.at> <4FC9070D.4020309@oracle.com> <395446C7-1B53-4035-BA83-3AC263470D36@oracle.com> Message-ID: I've pushed the latest patch we agreed to over the weekend: Changeset: ba58ca4a265f Author: rbair Date: 2012-06-04 10:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/ba58ca4a265f Now I am having some difficulty devising a unit test for this. I need to replicate (in as simple a manner as possible) the test scenario. I created a custom ClassLoader which only loads the FakeSkin, FakeControl, or FakeControlBase classes as necessary (so that class loader A only loads the FakeSkin and FakeControlBase, class loader B loads the FakeControl and delegates to A if necessary, etc). However the problem is that the original Class.forName("...FakeSkin") call always succeeds because the system class loader knows how to find and load it. How do I hide the class from the system class loader? Richard On Jun 1, 2012, at 1:54 PM, Richard Bair wrote: > OK, now for the tricky part. Writing the tests! I figure I might also add a sample to Ensemble showing how to use -fx-skin (feeling a little ambitious for a Friday afternoon :-)). > > Richard From jmartine_1026 at yahoo.com Mon Jun 4 11:30:28 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Mon, 4 Jun 2012 11:30:28 -0700 (PDT) Subject: gc options for best JFX performance In-Reply-To: <128851.9102.27644-19368-457210881-1338831879@seznam.cz> References: <1338824026.26882.YahooMailNeo@web160905.mail.bf1.yahoo.com> <128851.9102.27644-19368-457210881-1338831879@seznam.cz> Message-ID: <1338834628.47678.YahooMailNeo@web160903.mail.bf1.yahoo.com> I use add/remove. ?toBack is used when one of the units turns into a mine (he is carrying a mine and drops it when he dies). ?I had to add it recently when I noticed subsequent units walking under the mine. There is a version in Java 6, JFX 1.3 that is playable. ?It is far from complete (even some core concepts are being changed) but would be good to show off to the JFX developers how their hard work is being used. here it is: ?https://s3.amazonaws.com/turretmaster/tm/dist/index.html My apologies for not signing it. ?I purchased a certificate recently but have not gone back to add it to this older version. ?I can try to release this old version signed if prompted to. This older version has performance issues on older AMD's... I used to be a fan of AMD CPU's until now. ?I think the JFX 2.2 version will run better on AMD's (which is what I am developing on). thanks jose ________________________________ From: "goddard at seznam.cz" To: Jose Martinez Cc: Michael Heinrichs ; openjfx-dev at openjdk.java.net Sent: Monday, June 4, 2012 1:44 PM Subject: Re: Re: gc options for best JFX performance Wow, few dozens of enemies sounds like a lot at one time. What's the target resolution? Regarding the adding / removing nodes, do you use add / remove or toFront / toBack? The latter should be more effective. BTW would be nice to see the game :) Regards, Jiri ------------ P?vodn? zpr?va ------------ Od: Jose Martinez P?edm?t: Re: gc options for best JFX performance Datum: 04.6.2012 17:36:52 ---------------------------------------- That is correct, PathTransitions are being used extensively. During game play up to 500 enemy units attack in small waves (though this might go up to 1000 in future rounds). ?Each unit uses one PathTransition. ?Once the small waves begin, memory starts going up. ?At most there would be a few dozen units on screen at one time (PathTransitions running). So with regards to PathTransitions, do they use up memory while running or only an instantiation? ?So far I am not concerned with the overall memory footprint they use up while not running. ?With all the objects created before game play beings it comes out to about 100 - 150meg... this is very acceptable. ?I do not know where the memory tops off at because the GC kicks in but I would wager it goes up to 300 - 400 megs (i'll need to verify). There are a lot of ImageViews being added and removed from children ObservableList. ?Though I do not see how but could this be a source of memory usage? ?Every unit is animated and I created an AnimatedImageView class that flips through their List of ImageViews at very fast rates. ?I will test if there is memory usage related to adding/removing to ObservableList via this AnimatedImageView class. BTW, I strongly agree performance first memory second. ?I expect to do profiling of the code tonight. ?Will also look into custom PathTransitions as suggested. ?Thank you for the feedback, this conversation is sparking ideas that I would otherwise of not come up with. thanks jose ________________________________ From: Michael Heinrichs To: Jose Martinez Cc: "openjfx-dev at openjdk.java.net" Sent: Monday, June 4, 2012 4:25 AM Subject: Re: gc options for best JFX performance Hi Jose, just two short questions so I understand your use case better. Are you using PathTransition (as your other mail suggests) or Timeline for your animations? I think Timeline is pretty compact while PathTransition has room for improvements. :-) Nobody (I know of) used PathTransition extensively so far and it never became a priority. Maybe your case can change that. About how many moving objects are we talking? If you have really a lot of objects, say hundreds, you may be better off writing your own animation routine based on AnimationTimer. The classes you find in the JavaFX runtime are usually optimized for fast performance first and memory only second. If memory is your main concern, a custom implementation can give you significant improvements, especially if most of your animations are similar and you can take advantage of that. - Michael On 03.06.2012, at 17:03, Jose Martinez wrote: > Thanks a lot guys for the good feedback.? I'll follow up on it over the next few days.? If anything pops up relating JFX I'll respond. > > thanks > jose > > > ________________________________ > From: John Hendrikx > To: openjfx-dev at openjdk.java.net > Sent: Saturday, June 2, 2012 6:49 PM > Subject: Re: gc options for best JFX performance > > I really don't think a few KeyFrame and KeyValues is going to have any > impact -- making them mutable is not going to happen.? Just moving the > mouse over the screen is going to create more objects than that. > > Create some heap dumps, look through them, or profile your application > and find out where you might be able to optimize a bit -- it's often > surprising where the real memory/performance issues are coming from. > > On 2/06/2012 16:06, Jose Martinez wrote: >> Thanks Jiri.? Yeah I understand those things.? I was naively hoping that there was some magic concoction of JVM options that works ideally for JFX apps. >> >> I try very hard not to create new objects during game play but because the KeyFrame and KeyValue classes? immutable I imagine that those are what are building up in memory and getting cleaned up by the GC.? I create all my projectiles and enemy units before the round begins.? But with each shot fired I have to create KeyFrames and KeyValues to send the projectile to its destination.? Maybe making those classes non-immutable will help in keeping memory down.? I imagine there might be some complexity to changing a Keyframe that is attached to a Timeline, or a KayValue that is attached to a KeyFrame, which is probably why they were designed to be immutable. >> >> Also I have to create new Duration objects to keep track of time. >> >> thanks >> jose >> >> >> ________________________________ >>? ? From: "goddard at seznam.cz" >> To: Jose Martinez >> Cc: openjfx mailing list >> Sent: Saturday, June 2, 2012 4:52 AM >> Subject: Re: gc options for best JFX performance >> >> Hi, >> >> I believe there're no generic JVM settings for "best performance" Until you have perf. issues, I'd live with the default. >> If you want to do perf. tuning, it's application / environment dependent. Identify your bottleneck (network, i/o, memory, code etc.) and then try specific settings for that one. >> If you have big GC pauses, think about how much memory your app uses and if the heap is not too large, or what's the lifetime of objects in your app and adjust the generations in the heap accordingly. >> >> Regards, Jiri >> >> ------------ P?vodn? zpr?va ------------ >> Od: Jose Martinez >> P?edm?t: gc options for best JFX performance >> Datum: 02.6.2012 07:36:54 >> ---------------------------------------- >> Hello, >> >> I have tried the following GC modes but none of them get rid of the noticeable >> 'stop the world' delays. >> >> -XX:+UseParallelGC >> >> -XX:-UseParallelOldGC >> >> -XX:-UseParNewGC >> >> -XX:+UseConcMarkSweepGC >> >> >> Out of those my favorite so far is UseParNewGC. >> >> I also use the following options. >> --Xms150m -Xmx200m? -XX:MaxGCPauseMillis=1? >> >>? >> Are there other options that you would recommend?? Has anyone come up with a >> concoction of options that works best or a rule of thumb for configuring GC in >> JFX applications? >> >> If I cannot find a good set of options I will have to resort to calling >> System.gc() at strategic intervals. >>? >> thanks >> jose >> From hang.vo at oracle.com Mon Jun 4 12:03:19 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Jun 2012 19:03:19 +0000 Subject: hg: openjfx/2.2/controls/rt: 2 new changesets Message-ID: <20120604190321.1D951476E4@hg.openjdk.java.net> Changeset: 887eb9b3f2bb Author: Paru Somashekar Date: 2012-06-04 12:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/887eb9b3f2bb fix RT-22032 : ColorPicker preview color should reflect final selected value. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPalette.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! javafx-ui-controls/src/javafx/scene/control/ColorPicker.java ! javafx-ui-controls/src/javafx/scene/control/ComboBoxBase.java Changeset: 959854f544a9 Author: Kinsley Wong Date: 2012-06-04 12:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/959854f544a9 RT-20573: GridPane: When ColumnConstraints.maxWidth=USE_PREF_SIZE and ColumnConstraints.prefWidth=USE_COMPUTED_SIZE then ColumnConstraints.minWidth is ignored.GridPane: When ColumnConstraints.maxWidth=USE_PREF_SIZE and ColumnConstraints.prefWidth=USE_COMPUTED_SIZE then ColumnConstraints.minWidth is ignored. ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/test/unit/javafx/scene/layout/GridPaneTest.java From hang.vo at oracle.com Mon Jun 4 12:48:31 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Jun 2012 19:48:31 +0000 Subject: hg: openjfx/2.2/controls/rt: Virtual keyboard: Add ID to key buttons for test purposes. Message-ID: <20120604194832.5E7BD476E7@hg.openjdk.java.net> Changeset: 841f85729d35 Author: leifs Date: 2012-06-04 12:37 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/841f85729d35 Virtual keyboard: Add ID to key buttons for test purposes. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java From jasper.potts at oracle.com Mon Jun 4 13:17:52 2012 From: jasper.potts at oracle.com (Jasper Potts) Date: Mon, 4 Jun 2012 13:17:52 -0700 Subject: Painting images using PixelWriter In-Reply-To: References: Message-ID: <0FF02AC5-D49E-4696-B17A-9588F7B4E1E9@oracle.com> Hi, There will always be at minimum one copy operation because JavaFX runs on two threads. So at the point when you set pixels a copy will be made so it can be safe to access that new copy from our internal render thread. So you can have your own ByteBuffer access from native and every time you call setPixels a copy will be taken for the JavaFX platform to use. So you will need to make sure the content is static during that setPixels (copy) operation. Jasper On Jun 4, 2012, at 2:06 AM, Tobias Bley wrote: > Hi, > > since JFX 2.2 there is the new class PixelWriter. Would it be possible to draw Images like from a webcam using a shared ByteBuffer (or IntBuffer)? Wo what I would like to do is to fill a shared ByteBuffer from C (with JNI) and use the same bytebuffer for the JavaFX Image object.... > > Best regards, > Tobi > > > > -- > Tobias Bley > Chief Executive Officer > > -------------------------------------------------------- > > UltraMixer Digital Audio Solutions > Schillerstra?e 29 > D-01326 Dresden > Germany > > -------------------------------------------------------- > bley at ultramixer.com http://www.ultramixer.com > > > From hang.vo at oracle.com Mon Jun 4 13:33:03 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Jun 2012 20:33:03 +0000 Subject: hg: openjfx/2.2/controls/rt: Fixed RT-20244: TextField consume ESC, thus cancel button not working when focus on a textfield Message-ID: <20120604203304.583E4476E8@hg.openjdk.java.net> Changeset: 1ea744e2e264 Author: leifs Date: 2012-06-04 13:27 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/1ea744e2e264 Fixed RT-20244: TextField consume ESC, thus cancel button not working when focus on a textfield ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java From jmartine_1026 at yahoo.com Mon Jun 4 13:44:37 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Mon, 4 Jun 2012 13:44:37 -0700 (PDT) Subject: gc options for best JFX performance In-Reply-To: <1338834628.47678.YahooMailNeo@web160903.mail.bf1.yahoo.com> References: <1338824026.26882.YahooMailNeo@web160905.mail.bf1.yahoo.com> <128851.9102.27644-19368-457210881-1338831879@seznam.cz> <1338834628.47678.YahooMailNeo@web160903.mail.bf1.yahoo.com> Message-ID: <1338842677.51370.YahooMailNeo@web160901.mail.bf1.yahoo.com> Ok just signed it and it looks like the new signed jar broke things. ?Fails the blue JNLP load. ?Argggggg. ? thanks jose ________________________________ From: Jose Martinez To: "goddard at seznam.cz" Cc: "openjfx-dev at openjdk.java.net" Sent: Monday, June 4, 2012 2:30 PM Subject: Re: Re: gc options for best JFX performance I use add/remove. ?toBack is used when one of the units turns into a mine (he is carrying a mine and drops it when he dies). ?I had to add it recently when I noticed subsequent units walking under the mine. There is a version in Java 6, JFX 1.3 that is playable. ?It is far from complete (even some core concepts are being changed) but would be good to show off to the JFX developers how their hard work is being used. here it is: ?https://s3.amazonaws.com/turretmaster/tm/dist/index.html My apologies for not signing it. ?I purchased a certificate recently but have not gone back to add it to this older version. ?I can try to release this old version signed if prompted to. This older version has performance issues on older AMD's... I used to be a fan of AMD CPU's until now. ?I think the JFX 2.2 version will run better on AMD's (which is what I am developing on). thanks jose ________________________________ From: "goddard at seznam.cz" To: Jose Martinez Cc: Michael Heinrichs ; openjfx-dev at openjdk.java.net Sent: Monday, June 4, 2012 1:44 PM Subject: Re: Re: gc options for best JFX performance Wow, few dozens of enemies sounds like a lot at one time. What's the target resolution? Regarding the adding / removing nodes, do you use add / remove or toFront / toBack? The latter should be more effective. BTW would be nice to see the game :) Regards, Jiri ------------ P?vodn? zpr?va ------------ Od: Jose Martinez P?edm?t: Re: gc options for best JFX performance Datum: 04.6.2012 17:36:52 ---------------------------------------- That is correct, PathTransitions are being used extensively. During game play up to 500 enemy units attack in small waves (though this might go up to 1000 in future rounds). ?Each unit uses one PathTransition. ?Once the small waves begin, memory starts going up. ?At most there would be a few dozen units on screen at one time (PathTransitions running). So with regards to PathTransitions, do they use up memory while running or only an instantiation? ?So far I am not concerned with the overall memory footprint they use up while not running. ?With all the objects created before game play beings it comes out to about 100 - 150meg... this is very acceptable. ?I do not know where the memory tops off at because the GC kicks in but I would wager it goes up to 300 - 400 megs (i'll need to verify). There are a lot of ImageViews being added and removed from children ObservableList. ?Though I do not see how but could this be a source of memory usage? ?Every unit is animated and I created an AnimatedImageView class that flips through their List of ImageViews at very fast rates. ?I will test if there is memory usage related to adding/removing to ObservableList via this AnimatedImageView class. BTW, I strongly agree performance first memory second. ?I expect to do profiling of the code tonight. ?Will also look into custom PathTransitions as suggested. ?Thank you for the feedback, this conversation is sparking ideas that I would otherwise of not come up with. thanks jose ________________________________ From: Michael Heinrichs To: Jose Martinez Cc: "openjfx-dev at openjdk.java.net" Sent: Monday, June 4, 2012 4:25 AM Subject: Re: gc options for best JFX performance Hi Jose, just two short questions so I understand your use case better. Are you using PathTransition (as your other mail suggests) or Timeline for your animations? I think Timeline is pretty compact while PathTransition has room for improvements. :-) Nobody (I know of) used PathTransition extensively so far and it never became a priority. Maybe your case can change that. About how many moving objects are we talking? If you have really a lot of objects, say hundreds, you may be better off writing your own animation routine based on AnimationTimer. The classes you find in the JavaFX runtime are usually optimized for fast performance first and memory only second. If memory is your main concern, a custom implementation can give you significant improvements, especially if most of your animations are similar and you can take advantage of that. - Michael On 03.06.2012, at 17:03, Jose Martinez wrote: > Thanks a lot guys for the good feedback.? I'll follow up on it over the next few days.? If anything pops up relating JFX I'll respond. > > thanks > jose > > > ________________________________ > From: John Hendrikx > To: openjfx-dev at openjdk.java.net > Sent: Saturday, June 2, 2012 6:49 PM > Subject: Re: gc options for best JFX performance > > I really don't think a few KeyFrame and KeyValues is going to have any > impact -- making them mutable is not going to happen.? Just moving the > mouse over the screen is going to create more objects than that. > > Create some heap dumps, look through them, or profile your application > and find out where you might be able to optimize a bit -- it's often > surprising where the real memory/performance issues are coming from. > > On 2/06/2012 16:06, Jose Martinez wrote: >> Thanks Jiri.? Yeah I understand those things.? I was naively hoping that there was some magic concoction of JVM options that works ideally for JFX apps. >> >> I try very hard not to create new objects during game play but because the KeyFrame and KeyValue classes? immutable I imagine that those are what are building up in memory and getting cleaned up by the GC.? I create all my projectiles and enemy units before the round begins.? But with each shot fired I have to create KeyFrames and KeyValues to send the projectile to its destination.? Maybe making those classes non-immutable will help in keeping memory down.? I imagine there might be some complexity to changing a Keyframe that is attached to a Timeline, or a KayValue that is attached to a KeyFrame, which is probably why they were designed to be immutable. >> >> Also I have to create new Duration objects to keep track of time. >> >> thanks >> jose >> >> >> ________________________________ >>? ? From: "goddard at seznam.cz" >> To: Jose Martinez >> Cc: openjfx mailing list >> Sent: Saturday, June 2, 2012 4:52 AM >> Subject: Re: gc options for best JFX performance >> >> Hi, >> >> I believe there're no generic JVM settings for "best performance" Until you have perf. issues, I'd live with the default. >> If you want to do perf. tuning, it's application / environment dependent. Identify your bottleneck (network, i/o, memory, code etc.) and then try specific settings for that one. >> If you have big GC pauses, think about how much memory your app uses and if the heap is not too large, or what's the lifetime of objects in your app and adjust the generations in the heap accordingly. >> >> Regards, Jiri >> >> ------------ P?vodn? zpr?va ------------ >> Od: Jose Martinez >> P?edm?t: gc options for best JFX performance >> Datum: 02.6.2012 07:36:54 >> ---------------------------------------- >> Hello, >> >> I have tried the following GC modes but none of them get rid of the noticeable >> 'stop the world' delays. >> >> -XX:+UseParallelGC >> >> -XX:-UseParallelOldGC >> >> -XX:-UseParNewGC >> >> -XX:+UseConcMarkSweepGC >> >> >> Out of those my favorite so far is UseParNewGC. >> >> I also use the following options. >> --Xms150m -Xmx200m? -XX:MaxGCPauseMillis=1? >> >>? >> Are there other options that you would recommend?? Has anyone come up with a >> concoction of options that works best or a rule of thumb for configuring GC in >> JFX applications? >> >> If I cannot find a good set of options I will have to resort to calling >> System.gc() at strategic intervals. >>? >> thanks >> jose >> From tobi at ultramixer.com Mon Jun 4 14:06:35 2012 From: tobi at ultramixer.com (Tobias Bley (UltraMixer)) Date: Mon, 4 Jun 2012 23:06:35 +0200 Subject: Painting images using PixelWriter In-Reply-To: <0FF02AC5-D49E-4696-B17A-9588F7B4E1E9@oracle.com> References: <0FF02AC5-D49E-4696-B17A-9588F7B4E1E9@oracle.com> Message-ID: HI Jasper, do you think it would be possible to change this to one shared buffer? IMO thats the big advantage of NIO buffers. So we could get a much better performance when showing webcam images or video frames. So I could query the webcam by JNI and fill in a Java IO buffer which is rendered by JavaFX. But if there is a need to copy the complete image every 40ms (framerate 25fps) the performance could be poor. Best regards, Tobi -- Tobias Bley Gesch?ftsf?hrer/ Managing Director ------------------------------------------------------------------------ UltraMixer Digital Audio Solutions Schillerstrasse 29 01326 Dresden ------------------------------------------------------------------------- info at ultramixer.com http://www.ultramixer.com Am 04.06.2012 um 22:17 schrieb Jasper Potts: > Hi, > > There will always be at minimum one copy operation because JavaFX runs on two threads. So at the point when you set pixels a copy will be made so it can be safe to access that new copy from our internal render thread. So you can have your own ByteBuffer access from native and every time you call setPixels a copy will be taken for the JavaFX platform to use. So you will need to make sure the content is static during that setPixels (copy) operation. > > Jasper > > On Jun 4, 2012, at 2:06 AM, Tobias Bley wrote: > >> Hi, >> >> since JFX 2.2 there is the new class PixelWriter. Would it be possible to draw Images like from a webcam using a shared ByteBuffer (or IntBuffer)? Wo what I would like to do is to fill a shared ByteBuffer from C (with JNI) and use the same bytebuffer for the JavaFX Image object.... >> >> Best regards, >> Tobi >> >> >> >> -- >> Tobias Bley >> Chief Executive Officer >> >> -------------------------------------------------------- >> >> UltraMixer Digital Audio Solutions >> Schillerstra?e 29 >> D-01326 Dresden >> Germany >> >> -------------------------------------------------------- >> bley at ultramixer.com http://www.ultramixer.com >> >> >> > From richard.bair at oracle.com Mon Jun 4 14:11:54 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 4 Jun 2012 14:11:54 -0700 Subject: JavaFX 3D In-Reply-To: <4FC1F70F.8020901@gmail.com> References: <127996.13253.7562-20772-1461349531-1337461207@seznam.cz> <194FBC30-2A1A-4071-92DA-2416D6F93334@oracle.com> <4FC1F70F.8020901@gmail.com> Message-ID: Hi Anthony, On May 27, 2012, at 2:42 AM, Anthony Vanelverdinghe wrote: > I agree with having a unified scene graph, but wouldn't it be possible to see everything as 3D objects, where 2D nodes are merely part of the surface of those 3D objects? (to me this would imply discarding 2.5D transforms altogether) I don't think so. The problem is that for a typical 2D application, 2.5D is semantically correct (and easy!) whereas for a 3D program 2.5D is incorrect. So if you are building a 3D app, then yes you want to be able to take any normal 2D content and texture map it onto the 3D surface. That will need to be supported. But for a predominantly 2D application, you really want 2.5D (in terms of semantics). For example, suppose you have a 3D flip rotation in a 2D app. Really you just want to write: RotateTransition tx = new RotateTransition(nodeToRotate, Duration.seconds(3)); tx.setRotationAxis(Rotate.Y_AXIS); tx.play(); (or whatnot) And that would be it. However in a 3D scene graph, this would look different than in a 2.5D. In 2.5D, the camera used to draw the result of the rotation will be positioned differently than one that is observing the entire application as a 3D scene. In the former case, the camera is positioned such that it is looking directly at the node being rotated, whereas in the latter case the camera is positioned "head on" looking at the entire scene. The perspective on the flipping content will be different depending on where that camera is positioned. In addition, some things like "opacity" just have different semantic meaning between a 2D and 3D scene graph, so I think we can't just treat the whole scene as if it were a pure 3D scene graph. I mean, we could, but then "normal" or typical operations in a 2D world would acquire surprising new behaviors. For example, observe the difference between these two scene's: Rectangle r1 = new Rectangle(10, 10, 100, 100); Rectangle r2 = new Rectangle(20, 20, 90, 90); Rectangle r3 = new Rectangle(30, 30, 80, 80); Rectangle r4 = new Rectangle(40, 40, 70, 70); Group g = new Group(r1, r2, r3, r4); g.setOpacity(.5); vs. Rectangle r1 = new Rectangle(10, 10, 100, 100); Rectangle r2 = new Rectangle(20, 20, 90, 90); Rectangle r3 = new Rectangle(30, 30, 80, 80); Rectangle r4 = new Rectangle(40, 40, 70, 70); Group g = new Group(r1, r2, r3, r4); for (Node n : g.getChildren()) n.setOpacity(.5); The first scene shows the normal 2D semantic for setting opacity on the group. The second scene shows what it would look like if you had set the opacity on the group but with normal 3D semantics (which essentially just pass the state down onto the children). So ultimately I don't think we can just treat everything as 3D. That makes sense if you are writing a 3D app, but it doesn't make sense if you are writing a 2D app. So some provision for 2.5D I think makes sense. > Just an idea that may or may not be useful, but suppose, as an example: > * a cube > * a property "paint" (of type Paint) for the surface of a 3D object > * make a new subclass of Paint, ScenicPaint, which has the same behavior of a Scene, but allows to be used as the paint of the surface of a 3D object > * a property "interactive" (a boolean) for a surface. This means it allows the user to double-click on the surface, which would cause the camera to be centered on this surface, so that it fills the whole scene (cfr. the lookAt property of Camera) > > So i would then be able to create a cube, create 6 scenes exactly the same as i currently would for a 2D application. Then i would set each of those scenes on a different surface of the cube & make the whole cube interactive. Then the user could watch the cube from different angles & double-click any surface. The scene is then centered on that surface, allowing the user to interact with the controls on it (e.g. filling in a form) and when the user is done, it 's easy to go back to the "3D world" (so a ScenicPaint would only be interactive while the surface "has focus"). Of course there may be menu's & such, allowing to immediately center on another surface in the 3D world. It should thus also be possible to disable "going 3D" altogether, so that the application appears as a simple 2D program, but is really 3D behind the curtains (e.g. have a simple cube, centered on the front side, where the paint property is changed every time the user switches scenes). Yes I think that makes sense, although I would not have an "interactive" property. Instead you just have an event handler on the node in question and when it fires you then adjust the camera etc manually (ie: the "interactive" property is too use case specific, but you should be able to implement this use case on top of the scene graph we define). Cheers Richard From kevin.rushforth at oracle.com Mon Jun 4 14:14:11 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 04 Jun 2012 14:14:11 -0700 Subject: Painting images using PixelWriter In-Reply-To: References: <0FF02AC5-D49E-4696-B17A-9588F7B4E1E9@oracle.com> Message-ID: <4FCD2523.4070003@oracle.com> No, this is not possible since we do not expose the rendering thread, and anything that directly touched the copy being used for rendering would not be a good idea. I doubt that this extra copy will be an issue in most cases. One possible future improvement would be to have some way for you to pass in a buffer "by reference" with the understanding that once you do, you cannot touch it until it is "released". This would allow an app to double-buffer a pair of NIO buffers, filling one while FX was uploading the other to a texture. -- Kevin Tobias Bley (UltraMixer) wrote: > HI Jasper, > > do you think it would be possible to change this to one shared buffer? IMO thats the big advantage of NIO buffers. So we could get a much better performance when showing webcam images or video frames. So I could query the webcam by JNI and fill in a Java IO buffer which is rendered by JavaFX. But if there is a need to copy the complete image every 40ms (framerate 25fps) the performance could be poor. > > Best regards, > Tobi > > > -- > Tobias Bley > Gesch?ftsf?hrer/ Managing Director > > ------------------------------------------------------------------------ > > UltraMixer Digital Audio Solutions > Schillerstrasse 29 > 01326 Dresden > > ------------------------------------------------------------------------- > info at ultramixer.com http://www.ultramixer.com > > Am 04.06.2012 um 22:17 schrieb Jasper Potts: > > >> Hi, >> >> There will always be at minimum one copy operation because JavaFX runs on two threads. So at the point when you set pixels a copy will be made so it can be safe to access that new copy from our internal render thread. So you can have your own ByteBuffer access from native and every time you call setPixels a copy will be taken for the JavaFX platform to use. So you will need to make sure the content is static during that setPixels (copy) operation. >> >> Jasper >> >> On Jun 4, 2012, at 2:06 AM, Tobias Bley wrote: >> >> >>> Hi, >>> >>> since JFX 2.2 there is the new class PixelWriter. Would it be possible to draw Images like from a webcam using a shared ByteBuffer (or IntBuffer)? Wo what I would like to do is to fill a shared ByteBuffer from C (with JNI) and use the same bytebuffer for the JavaFX Image object.... >>> >>> Best regards, >>> Tobi >>> >>> >>> >>> -- >>> Tobias Bley >>> Chief Executive Officer >>> >>> -------------------------------------------------------- >>> >>> UltraMixer Digital Audio Solutions >>> Schillerstra?e 29 >>> D-01326 Dresden >>> Germany >>> >>> -------------------------------------------------------- >>> bley at ultramixer.com http://www.ultramixer.com >>> >>> >>> >>> > > From hang.vo at oracle.com Mon Jun 4 14:17:35 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Jun 2012 21:17:35 +0000 Subject: hg: openjfx/2.2/controls/rt: 12 new changesets Message-ID: <20120604211745.68DAE476E9@hg.openjdk.java.net> Changeset: 87d53f13f4d4 Author: hudson Date: 2012-05-31 13:21 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/87d53f13f4d4 Added tag 2.2-b11 for changeset 85b700eea97b ! .hgtags Changeset: c8c19d5e7527 Author: rbair Date: 2012-05-30 09:25 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/c8c19d5e7527 Fix for RT-21914: CheckBox API documentation example misnames as Checkbox ! javafx-ui-controls/src/javafx/scene/control/CheckBox.java Changeset: 9e776e8ca832 Author: rbair Date: 2012-05-30 12:24 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/9e776e8ca832 Fix for RT-21830: Improve Color startup by shortening the rgb calls for the predefined colors. The fix was to add a private constructor which takes 3 params instead of 4, all floats. (The 3 vs. 4 params makes it easier to make sure that we're only calling this constructor internally for the static colors). The static colors were converted over to use this constructor, and using pre-computed r, g, b float values (vs. the old approach of / 255.0 for each color at runtime). As this was a "Medium" priorty issue, probably actually a "Minor", I don't expect major gains from this. Just a little piece of salami. ! javafx-ui-common/src/javafx/scene/paint/Color.java Changeset: 7cdd9f231eff Author: rbair Date: 2012-05-30 12:32 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/7cdd9f231eff Fixed duplicate color declaration. ! javafx-ui-common/src/javafx/scene/paint/Color.java Changeset: 3edb1c7201e5 Author: rbair Date: 2012-05-30 14:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/3edb1c7201e5 Fix for RT-20880: IllegalStateException thrown from Service#restart(). Under some circumstances (such as if the task had already run) cancel returns false and the state is not changed to CANCELLED. Due to concurrency, the bindings & state of the service have not completed by the time reset is called by restart, and it is in the wrong state and throws an exception. Test added. ! javafx-concurrent/src/javafx/concurrent/Service.java ! javafx-concurrent/test/javafx/concurrent/ServiceLifecycleTest.java Changeset: bd432837e714 Author: rbair Date: 2012-05-30 15:24 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/bd432837e714 Fix for RT-19645: Task updateProgress should take double values, not long values ! javafx-concurrent/src/javafx/concurrent/Task.java Changeset: 63b0d121d3cd Author: kcr Date: 2012-06-01 16:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/63b0d121d3cd RT-21973: Suppress warning message when Toolkit is unable to load msvcr100.dll Reviewed by Igor ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java Changeset: 9be4d697d70f Author: kcr Date: 2012-06-01 16:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/9be4d697d70f RT-21789: node snapshot: wrong snapshot area Reviewed by Jim ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: a2b59544661f Author: kcr Date: 2012-06-01 16:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/a2b59544661f RT-21924: Passing in a null Callback as an argument to snapshot should throw NPE back to caller Reviewed by Jim ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 2faa9edf67c9 Author: Pavel Safrata Date: 2012-06-04 10:56 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/2faa9edf67c9 Minor javadoc improvements for input events (fixes RT-22005). ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/KeyEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchEvent.java Changeset: c795c8396f82 Author: Yao Wang Date: 2012-06-04 10:07 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/c795c8396f82 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt Changeset: 04cd43ba99ec Author: leifs Date: 2012-06-04 14:02 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/04cd43ba99ec Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt ! javafx-ui-common/src/javafx/scene/Node.java From james.graham at oracle.com Mon Jun 4 15:18:23 2012 From: james.graham at oracle.com (Jim Graham) Date: Mon, 04 Jun 2012 15:18:23 -0700 Subject: Painting images using PixelWriter In-Reply-To: <4FCD2523.4070003@oracle.com> References: <0FF02AC5-D49E-4696-B17A-9588F7B4E1E9@oracle.com> <4FCD2523.4070003@oracle.com> Message-ID: <4FCD342F.40709@oracle.com> Also, please do not draw any conclusions about the performance of this API just yet. The version you are working with in the promoted builds is essentially sending the pixel data over one pixel at a time using several method calls per pixel, just to get the API into your hands so you can see if it does the things you want it to do (ignoring performance). We are just now about to integrate the code that will start doing optimized copies of the pixel data into our internal rendering buffers and the performance should improve by several orders of magnitude. In a few days you may have a better understanding of how its performance will meet your needs in addition to the form of the API... ...jim On 6/4/2012 2:14 PM, Kevin Rushforth wrote: > No, this is not possible since we do not expose the rendering thread, > and anything that directly touched the copy being used for rendering > would not be a good idea. I doubt that this extra copy will be an issue > in most cases. > > One possible future improvement would be to have some way for you to > pass in a buffer "by reference" with the understanding that once you do, > you cannot touch it until it is "released". This would allow an app to > double-buffer a pair of NIO buffers, filling one while FX was uploading > the other to a texture. > > -- Kevin > > > Tobias Bley (UltraMixer) wrote: >> HI Jasper, >> >> do you think it would be possible to change this to one shared buffer? >> IMO thats the big advantage of NIO buffers. So we could get a much >> better performance when showing webcam images or video frames. So I >> could query the webcam by JNI and fill in a Java IO buffer which is >> rendered by JavaFX. But if there is a need to copy the complete image >> every 40ms (framerate 25fps) the performance could be poor. >> >> Best regards, >> Tobi >> >> >> -- >> Tobias Bley >> Gesch?ftsf?hrer/ Managing Director >> >> ------------------------------------------------------------------------ >> >> UltraMixer Digital Audio Solutions >> Schillerstrasse 29 >> 01326 Dresden >> >> ------------------------------------------------------------------------- >> info at ultramixer.com http://www.ultramixer.com >> >> Am 04.06.2012 um 22:17 schrieb Jasper Potts: >> >>> Hi, >>> >>> There will always be at minimum one copy operation because JavaFX >>> runs on two threads. So at the point when you set pixels a copy will >>> be made so it can be safe to access that new copy from our internal >>> render thread. So you can have your own ByteBuffer access from native >>> and every time you call setPixels a copy will be taken for the JavaFX >>> platform to use. So you will need to make sure the content is static >>> during that setPixels (copy) operation. >>> >>> Jasper >>> >>> On Jun 4, 2012, at 2:06 AM, Tobias Bley wrote: >>> >>>> Hi, >>>> >>>> since JFX 2.2 there is the new class PixelWriter. Would it be >>>> possible to draw Images like from a webcam using a shared ByteBuffer >>>> (or IntBuffer)? Wo what I would like to do is to fill a shared >>>> ByteBuffer from C (with JNI) and use the same bytebuffer for the >>>> JavaFX Image object.... >>>> >>>> Best regards, >>>> Tobi >>>> >>>> >>>> >>>> -- >>>> Tobias Bley >>>> Chief Executive Officer >>>> >>>> -------------------------------------------------------- >>>> >>>> UltraMixer Digital Audio Solutions >>>> Schillerstra?e 29 >>>> D-01326 Dresden >>>> Germany >>>> >>>> -------------------------------------------------------- >>>> bley at ultramixer.com http://www.ultramixer.com >>>> >>>> >>>> >> From fbrunnerlist at gmx.ch Mon Jun 4 16:40:33 2012 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Tue, 5 Jun 2012 01:40:33 +0200 Subject: b10: regression? In-Reply-To: <4FC80FA5.50708@oracle.com> References: <201206010032.52257.fbrunnerlist@gmx.ch> <986676B1-08EF-409A-A17A-6433CBB2C6CD@oracle.com> <4FC80FA5.50708@oracle.com> Message-ID: <201206050140.34333.fbrunnerlist@gmx.ch> Hi Jonathan, Thanks for your response. Could you already integrate your patch? Do you have a JIRA issue for this or should I create one? Regards, Florian Am Freitag 01 Juni 2012, 02:41:09 schrieb Jonathan Giles: > Actually, controls do need to know the screen, but this is just a recent > change for use in embedded situations. We need to know the screen > resolution to determine what CSS to load (so we can load CSS more suited > to lower resolution monitors). > > However, this email thread has popped up an issue - we're testing > whether we're on a QVGA screen even when isEmbedded() is false. Moving > the check inside the isEmbedded() if block will present getting the > screen measurements. I'll make this change after lunch. > > diff --git > a/javafx-ui-controls/src/javafx/scene/control/UAStylesheetLoader.java > b/javafx-ui-controls/src/javafx/scene/control/UAStylesheetLoader.java > --- a/javafx-ui-controls/src/javafx/scene/control/UAStylesheetLoader.java > +++ b/javafx-ui-controls/src/javafx/scene/control/UAStylesheetLoader.java > @@ -64,12 +64,13 @@ > if (com.sun.javafx.PlatformUtil.isEmbedded()) { > url = > SkinBase.class.getResource("caspian/embedded.css"); > > StyleManager.getInstance().addUserAgentStylesheet(url.toExternalForm()); > + > + if (com.sun.javafx.Utils.isQVGAScreen()) { > + url = > SkinBase.class.getResource("caspian/embedded-qvga.css"); > + > StyleManager.getInstance().addUserAgentStylesheet(url.toExternalForm()); > + } > } > > - if (com.sun.javafx.Utils.isQVGAScreen()) { > - url = > SkinBase.class.getResource("caspian/embedded-qvga.css"); > - > StyleManager.getInstance().addUserAgentStylesheet(url.toExternalForm()); > - } > stylesheetLoaded = true; > return null; > } > > -- Jonathan > > > On 1/06/2012 12:34 p.m., Richard Bair wrote: > > Definitely file a bug. CheckBox should never (ever!) require the Screen to be queried, since looking up the Screens takes time and will negatively impact startup. > > > > Thanks > > Richard > > > > On May 31, 2012, at 3:32 PM, Florian Brunner wrote: > > > >> Hi, > >> > >> On Linux (32-bit) with JavaFX 2.2 b08 I was able to instantiate a control in a unit test, e.g. > >> > >> import javafx.scene.control.CheckBox; > >> import org.junit.After; > >> import org.junit.Before; > >> import org.junit.Test; > >> > >> > >> public class MyTest { > >> > >> public MyTest() { > >> } > >> > >> > >> @Before > >> public void setUp() { > >> CheckBox cb = new CheckBox("test"); > >> } > >> > >> @After > >> public void tearDown() { > >> } > >> > >> > >> @Test > >> public void someTest() { > >> System.out.println("someTest"); > >> } > >> > >> } > >> > >> With b10 I'm getting an error: > >> > >> java.lang.ExceptionInInitializerError > >> at mypackage.MyTest.setUp(MyTest.java:28) > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > >> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >> at java.lang.reflect.Method.invoke(Method.java:601) > >> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > >> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > >> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > >> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) > >> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) > >> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > >> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > >> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > >> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > >> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > >> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > >> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > >> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > >> at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > >> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236) > >> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134) > >> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113) > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > >> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >> at java.lang.reflect.Method.invoke(Method.java:601) > >> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) > >> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) > >> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) > >> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103) > >> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74) > >> Caused by: java.lang.NullPointerException > >> at com.sun.glass.ui.Screen.getMainScreen(Screen.java:15) > >> at com.sun.javafx.tk.quantum.QuantumToolkit.getPrimaryScreen(QuantumToolkit.java:589) > >> at javafx.stage.Screen.updateConfiguration(Screen.java:102) > >> at javafx.stage.Screen.checkDirty(Screen.java:97) > >> at javafx.stage.Screen.getPrimary(Screen.java:176) > >> at com.sun.javafx.Utils.isQVGAScreen(Utils.java:813) > >> at javafx.scene.control.UAStylesheetLoader$1.run(UAStylesheetLoader.java:69) > >> at java.security.AccessController.doPrivileged(Native Method) > >> at javafx.scene.control.UAStylesheetLoader.loadUAStylesheet(UAStylesheetLoader.java:58) > >> at javafx.scene.control.UAStylesheetLoader.doLoad(UAStylesheetLoader.java:51) > >> at javafx.scene.control.Control.(Control.java:95) > >> ... 31 more > >> > >> > >> Is this a regression or a desired behaviour? If it's a desired behaviour: Is there a way to write some simple JUnit tests for controls? > >> > >> Regards, > >> Florian > From kevin.rushforth at oracle.com Mon Jun 4 17:01:12 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 04 Jun 2012 17:01:12 -0700 Subject: Patch: issue RT-14177 In-Reply-To: References: <201204051750.13667.fbrunnerlist@gmx.ch> <201206011638.06564.fbrunner@gmx.ch> <4FC8D548.8040901@bestsolution.at> <201206011810.09092.fbrunnerlist@gmx.ch> <4FC8EC11.5090609@bestsolution.at> <29140440-7968-4E40-8F2E-560674849A08@oracle.com> <1DE3DC4E-5E73-49F5-A324-4734AC2788E4@oracle.com> <03BF8184-4C57-400E-BCBE-234DB0F8A7BD@oracle.com> <4FC901DA.3050808@bestsolution.at> <4FC9070D.4020309@oracle.com> <395446C7-1B53-4035-BA83-3AC263470D36@oracle.com> Message-ID: <4FCD4C48.2000602@oracle.com> I ended up facing a similar issue when testing out the context class loader changes I made for http://javafx-jira.kenai.com/browse/RT-20843 (among other similar issues). I ended up creating two jar files in two separate netbeans projects: one for the support classes (in your case FakeSkin and FakeControlBase) and one for the unit test itself. The support jar is not on the classpath when I run the unit test. -- Kevin Richard Bair wrote: > I've pushed the latest patch we agreed to over the weekend: > > Changeset: ba58ca4a265f > Author: rbair > Date: 2012-06-04 10:40 -0700 > URL: > http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/ba58ca4a265f > > > Now I am having some difficulty devising a unit test for this. I need > to replicate (in as simple a manner as possible) the test scenario. I > created a custom ClassLoader which only loads the FakeSkin, > FakeControl, or FakeControlBase classes as necessary (so that class > loader A only loads the FakeSkin and FakeControlBase, class loader B > loads the FakeControl and delegates to A if necessary, etc). However > the problem is that the original Class.forName("...FakeSkin") call > always succeeds because the system class loader knows how to find and > load it. How do I hide the class from the system class loader? > > Richard > > > On Jun 1, 2012, at 1:54 PM, Richard Bair wrote: > >> OK, now for the tricky part. Writing the tests! I figure I might also >> add a sample to Ensemble showing how to use -fx-skin (feeling a >> little ambitious for a Friday afternoon :-)). >> >> Richard > From hang.vo at oracle.com Mon Jun 4 17:32:58 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Jun 2012 00:32:58 +0000 Subject: hg: openjfx/2.2/controls/rt: 4 new changesets Message-ID: <20120605003301.C5E47476EB@hg.openjdk.java.net> Changeset: c43de60706fc Author: jgiles Date: 2012-06-02 09:27 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/c43de60706fc RT-21988: Controls CSS should not check screen resolution unless on an embedded device ! javafx-ui-controls/src/javafx/scene/control/UAStylesheetLoader.java Changeset: 222c53eada42 Author: jgiles Date: 2012-06-02 09:28 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/222c53eada42 [DOC ONLY] Improved ComboBox javadoc to talk about how to use the buttonCell API to custom the button appearance. ! javafx-ui-controls/src/javafx/scene/control/ComboBox.java Changeset: cf257b36b8d1 Author: jgiles Date: 2012-06-02 10:14 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/cf257b36b8d1 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 32f6a7948935 Author: jgiles Date: 2012-06-05 12:23 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/32f6a7948935 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt From hang.vo at oracle.com Mon Jun 4 17:47:37 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Jun 2012 00:47:37 +0000 Subject: hg: openjfx/2.2/controls/rt: Fixed RT-21806: NLS: Please keep non-translatable resource strings in a separate resource file Message-ID: <20120605004738.1E817476EC@hg.openjdk.java.net> Changeset: aa001f13bd63 Author: leifs Date: 2012-06-04 17:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/aa001f13bd63 Fixed RT-21806: NLS: Please keep non-translatable resource strings in a separate resource file ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/EmbeddedResources.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls.properties + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/embedded.properties From tbee at tbee.org Mon Jun 4 22:20:44 2012 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 05 Jun 2012 07:20:44 +0200 Subject: JavaFX 3D In-Reply-To: References: <127996.13253.7562-20772-1461349531-1337461207@seznam.cz> <194FBC30-2A1A-4071-92DA-2416D6F93334@oracle.com> <4FC1F70F.8020901@gmail.com> Message-ID: <4FCD972B.8080509@tbee.org> On 2012-06-04 23:11, Richard Bair wrote: > Rectangle r1 = new Rectangle(10, 10, 100, 100); > Rectangle r2 = new Rectangle(20, 20, 90, 90); > Rectangle r3 = new Rectangle(30, 30, 80, 80); > Rectangle r4 = new Rectangle(40, 40, 70, 70); > Group g = new Group(r1, r2, r3, r4); > g.setOpacity(.5); > > vs. > > Rectangle r1 = new Rectangle(10, 10, 100, 100); > Rectangle r2 = new Rectangle(20, 20, 90, 90); > Rectangle r3 = new Rectangle(30, 30, 80, 80); > Rectangle r4 = new Rectangle(40, 40, 70, 70); > Group g = new Group(r1, r2, r3, r4); > for (Node n : g.getChildren()) n.setOpacity(.5); > > > The first scene shows the normal 2D semantic for setting opacity on the group. The second scene shows what it would look like if you had set the opacity on the group but with normal 3D semantics (which essentially just pass the state down onto the children). > > So ultimately I don't think we can just treat everything as 3D. That makes sense if you are writing a 3D app, but it doesn't make sense if you are writing a 2D app. So some provision for 2.5D I think makes sense. > I'm totally trusting that your research and knowledge into this topic is correct, but I'm interested in the difference anyhow. The example you describe above does not bring any "ah ha" experience. I figured that the first example actually is a shorthand for the second. It apparently is not. In 2d: what if it were? Tom From hang.vo at oracle.com Tue Jun 5 00:34:34 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Jun 2012 07:34:34 +0000 Subject: hg: openjfx/2.2/graphics/rt: Fix RT-21688: optimize PixelReader and PixelWriter implementations Message-ID: <20120605073437.BD35A476F4@hg.openjdk.java.net> Changeset: a9419005d78b Author: flar Date: 2012-06-05 00:21 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a9419005d78b Fix RT-21688: optimize PixelReader and PixelWriter implementations + javafx-ui-common/src/com/sun/javafx/image/AlphaType.java + javafx-ui-common/src/com/sun/javafx/image/BytePixelAccessor.java + javafx-ui-common/src/com/sun/javafx/image/BytePixelGetter.java + javafx-ui-common/src/com/sun/javafx/image/BytePixelSetter.java + javafx-ui-common/src/com/sun/javafx/image/ByteToBytePixelConverter.java + javafx-ui-common/src/com/sun/javafx/image/ByteToIntPixelConverter.java + javafx-ui-common/src/com/sun/javafx/image/IntPixelAccessor.java + javafx-ui-common/src/com/sun/javafx/image/IntPixelGetter.java + javafx-ui-common/src/com/sun/javafx/image/IntPixelSetter.java + javafx-ui-common/src/com/sun/javafx/image/IntToBytePixelConverter.java + javafx-ui-common/src/com/sun/javafx/image/IntToIntPixelConverter.java + javafx-ui-common/src/com/sun/javafx/image/PixelAccessor.java + javafx-ui-common/src/com/sun/javafx/image/PixelConverter.java + javafx-ui-common/src/com/sun/javafx/image/PixelGetter.java + javafx-ui-common/src/com/sun/javafx/image/PixelSetter.java + javafx-ui-common/src/com/sun/javafx/image/PixelUtils.java + javafx-ui-common/src/com/sun/javafx/image/impl/BaseByteToByteConverter.java + javafx-ui-common/src/com/sun/javafx/image/impl/BaseByteToIntConverter.java + javafx-ui-common/src/com/sun/javafx/image/impl/BaseIntToByteConverter.java + javafx-ui-common/src/com/sun/javafx/image/impl/BaseIntToIntConverter.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteArgb.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteBgra.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteBgraPre.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteGray.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteGrayAlpha.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteGrayAlphaPre.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteRgb.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteRgba.java + javafx-ui-common/src/com/sun/javafx/image/impl/General.java + javafx-ui-common/src/com/sun/javafx/image/impl/IntArgb.java + javafx-ui-common/src/com/sun/javafx/image/impl/IntArgbPre.java ! javafx-ui-common/src/com/sun/javafx/tk/PlatformImage.java ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java ! javafx-ui-common/src/javafx/scene/image/Image.java ! javafx-ui-common/src/javafx/scene/image/WritableImage.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubPlatformImage.java From hang.vo at oracle.com Tue Jun 5 09:34:25 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Jun 2012 16:34:25 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-21777: Changes for snapshot completely break the NetBeans VisualDebugger feature Message-ID: <20120605163427.A3BA847704@hg.openjdk.java.net> Changeset: 0498a5aa3193 Author: kcr Date: 2012-06-05 08:42 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/0498a5aa3193 RT-21777: Changes for snapshot completely break the NetBeans VisualDebugger feature ! javafx-ui-common/src/javafx/scene/Scene.java From hang.vo at oracle.com Tue Jun 5 10:48:56 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Jun 2012 17:48:56 +0000 Subject: hg: openjfx/2.2/controls/rt: Fixed RT-22054: TextInputControl default editing actions badly handled when TextInputControl is not editable Message-ID: <20120605174900.EC28A47705@hg.openjdk.java.net> Changeset: aa28336a1e58 Author: leifs Date: 2012-06-05 10:42 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/aa28336a1e58 Fixed RT-22054: TextInputControl default editing actions badly handled when TextInputControl is not editable ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java From hang.vo at oracle.com Tue Jun 5 14:49:25 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Jun 2012 21:49:25 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-20931: GridPaneDesignInfo.getCellBounds() is not consistent with GridPane.getLayoutBounds(). Message-ID: <20120605214929.913644770D@hg.openjdk.java.net> Changeset: 46dadf1d60fc Author: Kinsley Wong Date: 2012-06-05 14:44 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/46dadf1d60fc RT-20931: GridPaneDesignInfo.getCellBounds() is not consistent with GridPane.getLayoutBounds(). ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/test/unit/javafx/scene/layout/GridPaneTest.java From pedro.duquevieira at gmail.com Tue Jun 5 16:38:15 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 6 Jun 2012 00:38:15 +0100 Subject: ScrollPane - transparent track issue Message-ID: Hi, I'm trying to achieve a minimal look in a ScrollPane on a project of mine. To do this I only want to show the ScrollPane thumbs and nothing else. One of the things I've done to try to achieve this was to put the background of the tracks transparent the problem is that what is shown instead of the track is the ScrollPane background excluding it's contents. The result is a gap between the scrollpane contents and its edges with the scrollpane background in between. I guess that the contents of the scrollpane are only being drawn till the scrollpane track is reached, what needs to be done to get my problem fixed is that they need to be drawn all the way till the edges of the scrollpane. Did I explain my problem clearly enough or do I need to rewrite it? Thanks in advance, best regards, -- Pedro Duque Vieira From hang.vo at oracle.com Tue Jun 5 17:04:06 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Jun 2012 00:04:06 +0000 Subject: hg: openjfx/2.2/controls/rt: 2 new changesets Message-ID: <20120606000410.9D51347716@hg.openjdk.java.net> Changeset: b855ec5afa28 Author: Kinsley Wong Date: 2012-06-05 16:49 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/b855ec5afa28 RT-22026: [Pagination] need strict specification of behavior on max page indicators count. ! javafx-ui-controls/src/javafx/scene/control/Pagination.java ! javafx-ui-controls/test/javafx/scene/control/PaginationTest.java Changeset: bbf040d2b20e Author: Kinsley Wong Date: 2012-06-05 16:54 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/bbf040d2b20e RT-21910: [DOC ONLY] Pagination callback property default value is not specified. ! javafx-ui-controls/src/javafx/scene/control/Pagination.java From hang.vo at oracle.com Tue Jun 5 19:03:41 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Jun 2012 02:03:41 +0000 Subject: hg: openjfx/2.2/graphics/rt: Fix RT-21831: Specify ranges for WritableImage constructor parameters. Message-ID: <20120606020342.274124772E@hg.openjdk.java.net> Changeset: 7eb62ef86e4f Author: flar Date: 2012-06-05 18:58 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/7eb62ef86e4f Fix RT-21831: Specify ranges for WritableImage constructor parameters. ! javafx-ui-common/src/javafx/scene/image/Image.java ! javafx-ui-common/src/javafx/scene/image/WritableImage.java From hang.vo at oracle.com Tue Jun 5 23:48:44 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Jun 2012 06:48:44 +0000 Subject: hg: openjfx/2.2/controls/rt: fix RT-20285 MemoryLeak in javafx.scene.controls.MenuBar Message-ID: <20120606064846.4C0484773D@hg.openjdk.java.net> Changeset: 819d61e7effb Author: Paru Somashekar Date: 2012-06-05 23:39 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/819d61e7effb fix RT-20285 MemoryLeak in javafx.scene.controls.MenuBar ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java From hang.vo at oracle.com Wed Jun 6 03:19:15 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Jun 2012 10:19:15 +0000 Subject: hg: openjfx/2.2/graphics/rt: Fix for RT-22015: workaround for incorrect fullscreen visual bounds Message-ID: <20120606101918.7097447743@hg.openjdk.java.net> Changeset: 188ee39990fe Author: Lubomir Nerad Date: 2012-06-06 12:14 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/188ee39990fe Fix for RT-22015: workaround for incorrect fullscreen visual bounds ! javafx-ui-common/src/com/sun/javafx/Utils.java ! javafx-ui-common/src/javafx/stage/PopupWindow.java ! javafx-ui-common/test/unit/javafx/stage/PopupTest.java From ozemale at ozemail.com.au Wed Jun 6 07:34:49 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Thu, 7 Jun 2012 00:34:49 +1000 Subject: Font outlines? Message-ID: <001a01cd43f1$878a0080$969e0180$@com.au> Would it be possible to enhance the Font class or add associated classes so that it is possible to get the shape of a glyph for a given font and character? I would like to do some fancy things with text a la WordArt and I will need this information. Thanks, -jct From omurata at ga2.so-net.ne.jp Wed Jun 6 08:02:24 2012 From: omurata at ga2.so-net.ne.jp (Tadashi Ohmura) Date: Thu, 07 Jun 2012 00:02:24 +0900 Subject: Font outlines? In-Reply-To: <001a01cd43f1$878a0080$969e0180$@com.au> References: <001a01cd43f1$878a0080$969e0180$@com.au> Message-ID: <4FCF7100.6010804@ga2.so-net.ne.jp> (2012/06/06 23:34), John C. Turnbull wrote: > Would it be possible to enhance the Font class or add associated classes so > that it is possible to get the shape of a glyph for a given font and > character? I would like to do some fancy things with text a la WordArt and > I will need this information. I also want this function in JavaFX. It is just like as *java.awt.font.GlyphVector* Best Regards Tadashi Ohmura From hang.vo at oracle.com Wed Jun 6 08:04:00 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Jun 2012 15:04:00 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-21090 : ListView ignores initial scrolling Message-ID: <20120606150404.DB79147748@hg.openjdk.java.net> Changeset: a447a52d7abd Author: mickf Date: 2012-06-06 15:47 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/a447a52d7abd RT-21090 : ListView ignores initial scrolling ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/VirtualFlowTest.java From hang.vo at oracle.com Wed Jun 6 09:03:54 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Jun 2012 16:03:54 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-22096: Fixed coordinates of touch points delivered to a transformed node. Message-ID: <20120606160356.CA56E4774B@hg.openjdk.java.net> Changeset: a4bd88439e22 Author: Pavel Safrata Date: 2012-06-06 18:00 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a4bd88439e22 RT-22096: Fixed coordinates of touch points delivered to a transformed node. ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/TouchPoint.java ! javafx-ui-common/test/unit/javafx/scene/input/TouchEventTest.java From jonathan.giles at oracle.com Wed Jun 6 09:28:42 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 07 Jun 2012 04:28:42 +1200 Subject: Defaulting a comboBox's buttonCell to the cellFactory In-Reply-To: References: <4FC93503.7010209@oracle.com> Message-ID: <4FCF853A.1090005@oracle.com> We don't have a formal poll approach, but if we were to just take lazy consensus it would seem you have the only vote :-) Let's leave this open for another 24 hours, and then we'll change the behaviour back to the 2.1 behaviour if no other feedback is made. -- Jonathan On 6/06/2012 11:39 p.m., Urs Reupke wrote: > My vote is for A, as I indicated above. > > Jonathan, how long do polls usually run on this list, and what does a > lack of response mean for the proposed change? > > -Urs From philip.race at oracle.com Wed Jun 6 09:44:13 2012 From: philip.race at oracle.com (Phil Race) Date: Wed, 06 Jun 2012 09:44:13 -0700 Subject: Font outlines? In-Reply-To: <001a01cd43f1$878a0080$969e0180$@com.au> References: <001a01cd43f1$878a0080$969e0180$@com.au> Message-ID: <4FCF88DD.6040007@oracle.com> Its possible but its not in any plan. I am not sure how FX-like this would be to put it on Font. Perhaps instead a method to extract the Path from a Text node. However I guess the question then is how you intend to use it? You need to put it back into some kind of node for this and I don't see what you can then do that you could not have done with a Text node to begin with. You can apply effects, transforms, set strokes, fills (inc. gradient and ImagePattern fills) to the Text node. -phil. On 6/6/2012 7:34 AM, John C. Turnbull wrote: > Would it be possible to enhance the Font class or add associated classes so > that it is possible to get the shape of a glyph for a given font and > character? I would like to do some fancy things with text a la WordArt and > I will need this information. > > > > Thanks, > > > > -jct > From hang.vo at oracle.com Wed Jun 6 10:04:11 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Jun 2012 17:04:11 +0000 Subject: hg: openjfx/2.2/graphics/rt: 48 new changesets Message-ID: <20120606170452.6F3094774F@hg.openjdk.java.net> Changeset: 9e9695205c34 Author: Paru Somashekar Date: 2012-05-29 11:34 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/9e9695205c34 fix RT-21393 FXML declaration of javafx.scene.control.MenuItem does not propagate fx:id ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java Changeset: d60d057a30c9 Author: Kinsley Wong Date: 2012-05-29 11:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/d60d057a30c9 RT-21089: Tab.setOnSelectionChanged fires twice even if nothing has changed. ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java Changeset: 826caf92b089 Author: Kinsley Wong Date: 2012-05-29 12:33 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/826caf92b089 DOC Only: Fix typo in CheckBox example. ! javafx-ui-controls/src/javafx/scene/control/CheckBox.java Changeset: 34b65763aa33 Author: Kinsley Wong Date: 2012-05-29 14:02 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/34b65763aa33 RT-18815: TabPane drop-down tab list has no content if Tab text not set. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java Changeset: 29d96bd2ff47 Author: Paru Somashekar Date: 2012-05-29 16:03 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/29d96bd2ff47 fix RT-20121 Menu showing property change listener is not called on showing by keyboard. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! javafx-ui-controls/test/javafx/scene/control/MenuBarTest.java Changeset: 2605b68cbb49 Author: Kinsley Wong Date: 2012-05-29 17:03 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/2605b68cbb49 RT-20929: A button with setDefaultButton(true) consumes Enter event, even when it is disabled. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ButtonBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ButtonSkin.java ! javafx-ui-controls/test/javafx/scene/control/ButtonTest.java Changeset: 39958459bb92 Author: leifs Date: 2012-05-30 08:04 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/39958459bb92 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt Changeset: 30dacbe31d13 Author: Paru Somashekar Date: 2012-05-30 09:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/30dacbe31d13 fix RT-20792 Menu doesn't consume events properly. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java Changeset: 68d800e6784e Author: Paru Somashekar Date: 2012-05-30 12:09 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/68d800e6784e fix RT-21917 references in caspian css for colorpicker needs to be more specific RT-21113 Colorpicker if scene change its position, popup doesn't follow. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: 6a4a164faeff Author: leifs Date: 2012-05-30 14:25 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/6a4a164faeff Fixed RT-21493: RT-10392 introduced a 3-7% startup regression for GUIMark2 apps ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls.properties ! javafx-ui-controls/src/javafx/scene/control/Labeled.java Changeset: 8fb9ef26d4bc Author: David Grieve Date: 2012-05-30 17:58 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/8fb9ef26d4bc RT-21906: need to clear style cache when creating new StyleHelper ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java Changeset: d54eba721712 Author: jgiles Date: 2012-05-29 16:24 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/d54eba721712 Fix for TableView sorting that was accidently disabled. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java Changeset: 3275052b54fa Author: jgiles Date: 2012-05-29 16:40 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/3275052b54fa RT-21170: Make parent of nested columns end on the same coordinate as its final child ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java Changeset: ced2772737ea Author: jgiles Date: 2012-05-30 10:51 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/ced2772737ea RT-20300: TableView is not refreshed when TableColumn are added dynamically ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: 3009735752fb Author: jgiles Date: 2012-05-31 10:02 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/3009735752fb RT-21920: ComboBox editor should never be null when requested ! javafx-ui-controls/src/javafx/scene/control/ComboBox.java Changeset: 12d9e19e9c1a Author: jgiles Date: 2012-05-31 10:02 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/12d9e19e9c1a Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 42244b08c655 Author: Paru Somashekar Date: 2012-05-30 15:10 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/42244b08c655 fix RT-21552 ColorPicker esc behavior in custom colors dialog not implemented. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPalette.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ColorPickerPaletteRetriever.java ! javafx-ui-controls/test/javafx/scene/control/ColorPickerTest.java Changeset: a3957c32490c Author: Paru Somashekar Date: 2012-05-30 15:14 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a3957c32490c merge Changeset: c8cde1376f90 Author: Kinsley Wong Date: 2012-05-30 16:09 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/c8cde1376f90 RT-21899: [Pagination] default property of page count is not as in docs. ! javafx-ui-controls/src/javafx/scene/control/Pagination.java Changeset: 28ee2f1219e1 Author: Kinsley Wong Date: 2012-05-30 16:11 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/28ee2f1219e1 RT-21899: reapply java doc fix for [Pagination] default property of page count is not as in docs. ! javafx-ui-controls/src/javafx/scene/control/Pagination.java Changeset: 686665e4dfa4 Author: Kinsley Wong Date: 2012-05-30 16:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/686665e4dfa4 RT-21902: [Pagination] STYLE_CLASS_BULLET is not applied fully. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 3771cf73348e Author: David Grieve Date: 2012-05-30 21:41 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/3771cf73348e RT-21906: fix NPE caused by previous changeset for this bug ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: 79ea942b7252 Author: David Grieve Date: 2012-05-30 21:43 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/79ea942b7252 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 3f7e8bfab133 Author: Paru Somashekar Date: 2012-05-30 23:43 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/3f7e8bfab133 fix RT-19359 It is impossible to jump over the disabled menu element. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! javafx-ui-controls/test/javafx/scene/control/MenuBarTest.java Changeset: ed79d22b904a Author: Kinsley Wong Date: 2012-05-31 11:21 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/ed79d22b904a RT-21903: Pagination indicators can be drawn outside of the control. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: c7f8d4c2bed0 Author: David Grieve Date: 2012-05-31 14:44 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/c7f8d4c2bed0 RT-21407: strip quotes from font-family value ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: c0638045c8c4 Author: Kinsley Wong Date: 2012-05-31 13:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/c0638045c8c4 RT-19951:Testcase testParentMinPrefMaxWidthAreEqual and testParentMinPrefMaxHeightAreEqual (javafx.scene.layout.ResizabilityTest) fail on hudson ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/test/unit/javafx/scene/layout/ResizabilityTest.java Changeset: 9bb30177cd6d Author: jgiles Date: 2012-06-01 09:38 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/9bb30177cd6d Fix for unit test failure based on recent changes to ComboBox editor behavior ! javafx-ui-controls/test/javafx/scene/control/ComboBoxTest.java Changeset: 1268d048f9b4 Author: jgiles Date: 2012-06-01 09:38 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/1268d048f9b4 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 4ed3df281641 Author: Kinsley Wong Date: 2012-05-31 15:01 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/4ed3df281641 RT-21854: Wrong SplitPane divider position. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SplitPaneSkin.java Changeset: cc964812fd59 Author: Paru Somashekar Date: 2012-05-31 15:43 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/cc964812fd59 fix RT-21959 Boolean styleable property -fx-color-label-visible does not work. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java Changeset: c954001bb9b5 Author: David Grieve Date: 2012-05-31 18:55 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/c954001bb9b5 RT-21960: when looking up font, set weight and posture from parsed value, not from converted font ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/test/unit/com/sun/javafx/css/FontTypeTest.java Changeset: 11001b9fd4d1 Author: Kinsley Wong Date: 2012-05-31 16:12 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/11001b9fd4d1 RT-21941: [TabPane] it is possible to select disabled tab from dropdown. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java Changeset: c398812e496c Author: David Grieve Date: 2012-05-31 20:11 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/c398812e496c RT-21965: css parse flag is the negation of binary.css system property, if it is set. ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: 7810088c2621 Author: David Grieve Date: 2012-05-31 20:13 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/7810088c2621 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: e5ccb1183358 Author: Kinsley Wong Date: 2012-05-31 18:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/e5ccb1183358 RT-21956: [Pagination] content can be not updated, if change factory during scrolling. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 3f7310d8b303 Author: mickf Date: 2012-06-01 13:52 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/3f7310d8b303 RT-20528 : Button Mneumonic Parsing causes leak ! javafx-ui-common/src/com/sun/javafx/scene/KeyboardShortcutsHandler.java + javafx-ui-common/test/unit/com/sun/javafx/scene/KeyboardShortcutsTest.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ButtonSkinTest.java Changeset: 503bac65e6bc Author: leifs Date: 2012-06-01 14:16 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/503bac65e6bc Fixed RT-21860: Virtual Keyboard throws an exception ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java Changeset: d7e46d20f756 Author: leifs Date: 2012-06-01 16:25 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/d7e46d20f756 Fixed RT-19171: [TextArea, Linux] text under selection can be white and black ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java Changeset: ba58ca4a265f Author: rbair Date: 2012-06-04 10:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/ba58ca4a265f Fix for RT-14177: -fx-skin can't work in OSGi-Envs. Tests forthcoming. ! javafx-ui-common/src/com/sun/javafx/Utils.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 887eb9b3f2bb Author: Paru Somashekar Date: 2012-06-04 12:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/887eb9b3f2bb fix RT-22032 : ColorPicker preview color should reflect final selected value. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPalette.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! javafx-ui-controls/src/javafx/scene/control/ColorPicker.java ! javafx-ui-controls/src/javafx/scene/control/ComboBoxBase.java Changeset: 959854f544a9 Author: Kinsley Wong Date: 2012-06-04 12:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/959854f544a9 RT-20573: GridPane: When ColumnConstraints.maxWidth=USE_PREF_SIZE and ColumnConstraints.prefWidth=USE_COMPUTED_SIZE then ColumnConstraints.minWidth is ignored.GridPane: When ColumnConstraints.maxWidth=USE_PREF_SIZE and ColumnConstraints.prefWidth=USE_COMPUTED_SIZE then ColumnConstraints.minWidth is ignored. ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/test/unit/javafx/scene/layout/GridPaneTest.java Changeset: 841f85729d35 Author: leifs Date: 2012-06-04 12:37 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/841f85729d35 Virtual keyboard: Add ID to key buttons for test purposes. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java Changeset: 1ea744e2e264 Author: leifs Date: 2012-06-04 13:27 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/1ea744e2e264 Fixed RT-20244: TextField consume ESC, thus cancel button not working when focus on a textfield ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java Changeset: 04cd43ba99ec Author: leifs Date: 2012-06-04 14:02 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/04cd43ba99ec Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt ! javafx-ui-common/src/javafx/scene/Node.java Changeset: d39767c34385 Author: mfang Date: 2012-06-01 00:03 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/d39767c34385 RT-21970: NLS: 2.2 message drop 10 integration - non-deploy files ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_de.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_es.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_fr.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_it.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_ja.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_ko.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_pt_BR.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_sv.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_zh_CN.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_zh_TW.properties Changeset: 348de34f8273 Author: igor Date: 2012-06-05 16:41 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/348de34f8273 Merge Changeset: 6593c5847d5b Author: Yao Wang Date: 2012-06-06 09:51 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/6593c5847d5b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt ! javafx-ui-common/src/com/sun/javafx/Utils.java From hang.vo at oracle.com Wed Jun 6 11:33:55 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Jun 2012 18:33:55 +0000 Subject: hg: openjfx/2.2/controls/rt: 3 new changesets Message-ID: <20120606183359.6666947756@hg.openjdk.java.net> Changeset: 1f9d7d6bb729 Author: Kinsley Wong Date: 2012-06-06 10:19 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/1f9d7d6bb729 RT22012: Pagination AIOBE when size is set small. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: d82a7c6d2cac Author: Kinsley Wong Date: 2012-06-06 11:20 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/d82a7c6d2cac RT-22098: [Pagination] current page is not updated, when page count is reduced. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: c0039fe78883 Author: Kinsley Wong Date: 2012-06-06 11:23 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/c0039fe78883 Merge From david.grieve at oracle.com Fri Jun 1 10:20:37 2012 From: david.grieve at oracle.com (David Grieve) Date: Fri, 1 Jun 2012 13:20:37 -0400 Subject: Patch: issue RT-14177 In-Reply-To: <29140440-7968-4E40-8F2E-560674849A08@oracle.com> References: <201204051750.13667.fbrunnerlist@gmx.ch> <201206011638.06564.fbrunner@gmx.ch> <4FC8D548.8040901@bestsolution.at> <201206011810.09092.fbrunnerlist@gmx.ch> <4FC8EC11.5090609@bestsolution.at> <29140440-7968-4E40-8F2E-560674849A08@oracle.com> Message-ID: <1DE3DC4E-5E73-49F5-A324-4734AC2788E4@oracle.com> This should be tested from an applet or with applet-like java.policy, no? I mean, if it's called from user code by way of Control or PopupControl, will it throw a SecurityException? Also, loadSkinClass is a bottle neck and I fear this will make it worse. We may need to think about caching. On Jun 1, 2012, at 12:58 PM, Richard Bair wrote: > Thanks guys! Thanks Jonathan & Tom for pointing out the other location in PopupControl. I've uploaded rt-14177.6.patch, which moves the code into com.sun.javafx.Utils and then has PopupControl and Control use it. As such the logic was rearranged a bit (for example, the methods just return the looked up class or fail with an exception, instead of assigning to a variable). > > Florian if you are still online and can test it out that would be great. Another code review would be appreciated. > > Thanks > Richard > > On Jun 1, 2012, at 9:21 AM, Tom Schindl wrote: > >> Ok - that makes sense. Classloader B only sees public packages from A. >> >> Need to leave for a weekend after work beer. So I'm fine with the last >> patch from Florian. >> >> Tom >> >> Am 01.06.12 18:10, schrieb Florian Brunner: >>> Hi Tom, >>> >>> I have the following bundles: >>> >>> Bundle A: >>> SomeBaseControl with a custom skin in a different (most commonly private) package >>> >>> Bundle B >>> SomeControl extends SomeBaseControl >>> >>> Bundle C >>> Instantiates SomeControl >>> >>> Just using: >>> >>> getClass().getClassLoader().loadClass(className); >>> >>> in Control resulted in a ClassNotFoundException (here: getClass() == SomeControl.class; className=skin class name for SomeBaseControl). >>> So I started to loop over the super-types to get a class which is in the same bundle as the custom skin class. That worked. >>> >>> Do you see a better way without changing the API? >>> >>> Regards, >>> Florian >>> >>> >>> Am Freitag 01 Juni 2012, 16:44:24 schrieb Tom Schindl: >>>> Hi Florian, >>>> >>>> Good. I can you tell me why the super-type loop is used - I think it was >>>> already in your first patch - wondering what this is good for. >>>> >>>> Tom >>>> >>>> Am 01.06.12 16:38, schrieb Florian Brunner: >>>>> I tested rt-14177.3.patch and Tom is right, the ClassNotFoundException has to be catched otherwise the new code won't be executed. >>>>> >>>>> Unfortunatly, hg import failed for 5.patch for some reason. >>>>> >>>>> I created and tested a new patch (with "hg diff --git" as recommended by Kevin (see attachements, I don't have the necessary rights in JIRA). >>>>> >>>>> It works fine for my use case. >>>>> >>>>> I also renamed ex2 to ex3 and ex3 to ex2 and fixed some formatting issues. >>>>> >>>>> Note however that now the method contains around 100 lines of code. You might want to refactor it into several smaller methods for maintainability reasons. >>>>> >>>>> Regards, >>>>> Florian >>>>> >>>>> >>>>> Am Freitag 01 Juni 2012, 11:04:09 schrieb Tom Schindl: >>>>>> Hi, >>>>>> >>>>>> I've uploaded a fixed version of the patch! I think Richards patch >>>>>> missed to catch the CNE for the context classloader. >>>>>> >>>>>> I can not comment on other areas of the control system - just did a >>>>>> short Class.forName-scan and can confirm you are finding about >>>>>> PopControl - it even has the same fix for RT-17525 so extracing the code >>>>>> and moveing it to a library makes sense. >>>>>> >>>>>> CSS might have similar problems (but in case of classloading but they >>>>>> are harder to fix because one has to infer the correct classloader from >>>>>> the CSS-URI or even the target they are applied to!). >>>>>> >>>>>> FXML has fixed all iusses (beside one small remaining issue I'm just >>>>>> discussing with Greg on this list) because it allows to pass custom >>>>>> classloaders and hence stuff loaded through FXML will directly profit >>>>>> from the Control enhancement. >>>>>> >>>>>> FXML is IMHO different to CSS/Controls because there's a defined >>>>>> lifecycle and so controlling the classloader there is much easier than >>>>>> it is in CSS/Control space where the classloader access is happening in >>>>>> an async fashion. >>>>>> >>>>>> I currently have no local build so I have to rely on Florian to give >>>>>> feedback if it fixes the problem. From a source introspection it looks >>>>>> good to me with my patch 5. >>>>>> >>>>>> Tom >>>>>> >>>>>> Am 01.06.12 05:22, schrieb Jonathan Giles: >>>>>>> +1 on the patch, although I do wonder whether we are being consistent in >>>>>>> the other places where classloading comes into play. Is this something >>>>>>> that should be extracted and used as an internal library? >>>>>>> >>>>>>> For example, there is much the same code in PopupControl that needs to >>>>>>> be fixed at the same time as the patch you are submitting here, but more >>>>>>> abstractly, should we have a library rather than duplicate similar code >>>>>>> in FXML and CSS as well? >>>>>>> >>>>>>> -- Jonathan >>>>>>> >>>>>>> >>>>>>> On 1/06/2012 3:14 p.m., Richard Bair wrote: >>>>>>>> Florian / Tom, >>>>>>>> >>>>>>>> I've uploaded two patches to the issue: >>>>>>>> rt-14177.2.patch >>>>>>>> rt-14177.3.patch >>>>>>>> >>>>>>>> The .3 patch is my preferred one. Can you take a look / apply it and >>>>>>>> see if it solves your issue? If the .3 patch works, then I think we've >>>>>>>> got a clean patch which will produce no additional performance >>>>>>>> overhead to a correctly functioning JavaFX application today, but will >>>>>>>> fix your issue (at least as Tom said in the issue itself for 95% of >>>>>>>> the folks). >>>>>>>> >>>>>>>> We can then file a new issue for the remaining 5% cases which will >>>>>>>> need more time (since it involves some form of new API) whereas in >>>>>>>> this case it should "just work". >>>>>>>> >>>>>>>> David / Jonathan, can you guys give a quick code review? I'm pretty >>>>>>>> sure the code does what I want it to do, and hopefully Florian / Tom >>>>>>>> will tell us if what I want it to do is actually the right thing to do >>>>>>>> (ie: solves the issue) :-). >>>>>>>> >>>>>>>> Thanks >>>>>>>> Richard >>>>>>>> >>>>>>>> On May 31, 2012, at 5:45 PM, Richard Bair wrote: >>>>>>>> >>>>>>>>> Hi Florian, >>>>>>>>> >>>>>>>>> We'll get this fixed ASAP. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Richard >>>>>>>>> >>>>>>>>> On May 31, 2012, at 4:45 PM, Kevin Rushforth wrote: >>>>>>>>> >>>>>>>>>> Hi Florian, >>>>>>>>>> >>>>>>>>>> This JIRA issue is targeted for 3.0 which is just in the initial >>>>>>>>>> planning stages, so no one has looked at it yet. >>>>>>>>>> >>>>>>>>>> The patch as attached to the issue deals with one case of CSS >>>>>>>>>> loading a skin, but when the controls team evaluated it, their take >>>>>>>>>> was that it a more general platform issue, although it could be >>>>>>>>>> dealt with in isolation. In any case, even if I were to assign this >>>>>>>>>> back to someone on the controls team, this code would need to be >>>>>>>>>> evaluated for potential bugs and to ensure that there are no >>>>>>>>>> security issues (probably not an issue, but since it would be using >>>>>>>>>> a system class loader we need to make sure it is never called from a >>>>>>>>>> privileged context), which is unlikely to happen for the current >>>>>>>>>> release. >>>>>>>>>> >>>>>>>>>> -- Kevin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Florian Brunner wrote: >>>>>>>>>>> Hi Kevin, >>>>>>>>>>> >>>>>>>>>>> What is the status of my patch? >>>>>>>>>>> As mentioned in JIRA, this issue is becoming a blocker! Please >>>>>>>>>>> increase the priority! (Nobody from Oracle is responding on JIRA). >>>>>>>>>>> >>>>>>>>>>> Can we agree then to integrate the provided patch? It improves the >>>>>>>>>>> situation but doesn't introduce any API additions and we can >>>>>>>>>>> replace/ complete it later with other solutions if needed. >>>>>>>>>>> Please tell me if I should change something in the patch to get it >>>>>>>>>>> approved. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Florian >>>>>>>>>>> >>>>>>>>>>> Am Freitag 06 April 2012, 23:58:13 schrieb Kevin Rushforth: >>>>>>>>>>> >>>>>>>>>>>> I attached it to the JIRA issue. >>>>>>>>>>>> >>>>>>>>>>>> -- Kevin >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Florian Brunner wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Here the patch created with "hg diff --git" and zipped. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Florian >>>>>>>>>>>>> >>>>>>>>>>>>> Am Freitag 06 April 2012, 18:31:23 schrieb Kevin Rushforth: >>>>>>>>>>>>> >>>>>>>>>>>>>> Right. Since you didn't file the issue and are not the assignee, >>>>>>>>>>>>>> you can't add an attachment. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Copying Brian Beck in case this is something we can (and want >>>>>>>>>>>>>> to) fix. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In the mean time, you can e-mail me the patch and I'll attach it >>>>>>>>>>>>>> to the bug report. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- Kevin >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Florian Brunner wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Kevin, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for your response. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Unfortunatly, I don't see a way to attach something to the JIRA >>>>>>>>>>>>>>> issue. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Either I'm missing something or maybe I need additional rights? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> Florian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Am Donnerstag 05 April 2012, 18:54:38 schrieben Sie: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Great. Please attach the patch as a zip file to the JIRA issue >>>>>>>>>>>>>>>> (preferably generated with either webrev or "hg diff --git") >>>>>>>>>>>>>>>> so that it can be evaluated. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- Kevin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Florian Brunner wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Let me introduce myself: my name is Florian Brunner and I'm a >>>>>>>>>>>>>>>>> Senior Software Engineer from Switzerland. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I started to use JavaFX in an OSGi environment. Now I >>>>>>>>>>>>>>>>> stumbled over the following issue, which blocks me: >>>>>>>>>>>>>>>>> http://javafx-jira.kenai.com/browse/RT-14177 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I have written a patch now. It probably doesn't solve the >>>>>>>>>>>>>>>>> whole issue, but at least it unblocks me for now. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It would be great if you could integrate it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Note that I contributed to OpenJDK before (Swing) and have >>>>>>>>>>>>>>>>> signed the Sun Contributor Agreement: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://www.oracle.com/technetwork/community/oca-486395.html#b >>>>>>>>>>>>>>>>> Florian Brunner - java.net - puce >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>> Florian >>>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>> >> >> >> -- >> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >> ------------------------------------------------------------------------ >> tom schindl gesch?ftsf?hrer/CEO >> ------------------------------------------------------------------------ >> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >> http://www.BestSolution.at phone ++43 512 935834 > David Grieve | Principal Member of Technical Staff Mobile: +16033121013 Oracle Java Client UI and Tools Durham, NH 03824 Oracle is committed to developing practices and products that help protect the environment From fbrunner at gmx.ch Wed Jun 6 07:30:38 2012 From: fbrunner at gmx.ch (Florian Brunner) Date: Wed, 6 Jun 2012 16:30:38 +0200 Subject: Patch: issue RT-14177 In-Reply-To: References: <201204051750.13667.fbrunnerlist@gmx.ch> <395446C7-1B53-4035-BA83-3AC263470D36@oracle.com> Message-ID: <201206061630.38210.fbrunner@gmx.ch> Hi Richard, Thanks for pushing the patch. What is the best way to test it? Will it be part of build b12 or b13? Regards, Florian Am Montag 04 Juni 2012, 20:03:34 schrieb Richard Bair: > I've pushed the latest patch we agreed to over the weekend: > > Changeset: ba58ca4a265f > Author: rbair > Date: 2012-06-04 10:40 -0700 > URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/ba58ca4a265f > > > Now I am having some difficulty devising a unit test for this. I need to replicate (in as simple a manner as possible) the test scenario. I created a custom ClassLoader which only loads the FakeSkin, FakeControl, or FakeControlBase classes as necessary (so that class loader A only loads the FakeSkin and FakeControlBase, class loader B loads the FakeControl and delegates to A if necessary, etc). However the problem is that the original Class.forName("...FakeSkin") call always succeeds because the system class loader knows how to find and load it. How do I hide the class from the system class loader? > > Richard > > > On Jun 1, 2012, at 1:54 PM, Richard Bair wrote: > > > OK, now for the tricky part. Writing the tests! I figure I might also add a sample to Ensemble showing how to use -fx-skin (feeling a little ambitious for a Friday afternoon :-)). > > > > Richard > > From ursreupke at googlemail.com Wed Jun 6 04:39:52 2012 From: ursreupke at googlemail.com (Urs Reupke) Date: Wed, 6 Jun 2012 13:39:52 +0200 Subject: Defaulting a comboBox's buttonCell to the cellFactory In-Reply-To: <4FC93503.7010209@oracle.com> References: <4FC93503.7010209@oracle.com> Message-ID: My vote is for A, as I indicated above. Jonathan, how long do polls usually run on this list, and what does a lack of response mean for the proposed change? -Urs From hang.vo at oracle.com Wed Jun 6 13:18:47 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Jun 2012 20:18:47 +0000 Subject: hg: openjfx/2.2/controls/rt: Fixed RT-21788: Handles should be displayed in TextBox components, not outside. Message-ID: <20120606201849.0FDE74775B@hg.openjdk.java.net> Changeset: a3977b2b77b5 Author: leifs Date: 2012-06-06 13:06 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/a3977b2b77b5 Fixed RT-21788: Handles should be displayed in TextBox components, not outside. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/embedded.css From hang.vo at oracle.com Wed Jun 6 13:33:33 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Jun 2012 20:33:33 +0000 Subject: hg: openjfx/2.2/controls/rt: 3 new changesets Message-ID: <20120606203335.F41814775C@hg.openjdk.java.net> Changeset: d39767c34385 Author: mfang Date: 2012-06-01 00:03 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/d39767c34385 RT-21970: NLS: 2.2 message drop 10 integration - non-deploy files ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_de.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_es.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_fr.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_it.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_ja.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_ko.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_pt_BR.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_sv.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_zh_CN.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_zh_TW.properties Changeset: 348de34f8273 Author: igor Date: 2012-06-05 16:41 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/348de34f8273 Merge Changeset: 0cbd6a3c74bb Author: leifs Date: 2012-06-06 13:26 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/0cbd6a3c74bb Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt From pedro.duquevieira at gmail.com Wed Jun 6 13:44:52 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 6 Jun 2012 21:44:52 +0100 Subject: ScrollPane - transparent track issue In-Reply-To: References: Message-ID: I don't think my message went through, probably didn't explain myself well. Here is a picture of the problem: http://yfrog.com/0xx6pp I'm using javafx 2.1 and I also tried setting the track visibility to hidden which doesn't do anything. Thanks, best regards, On Wed, Jun 6, 2012 at 12:38 AM, Pedro Duque Vieira < pedro.duquevieira at gmail.com> wrote: > Hi, > > I'm trying to achieve a minimal look in a ScrollPane on a project of mine. > To do this I only want to show the ScrollPane thumbs and nothing else. > One of the things I've done to try to achieve this was to put the > background of the tracks transparent the problem is that what is shown > instead of the track is the ScrollPane background excluding it's contents. > The result is a gap between the scrollpane contents and its edges with the > scrollpane background in between. > > I guess that the contents of the scrollpane are only being drawn till the > scrollpane track is reached, what needs to be done to get my problem fixed > is that they need to be drawn all the way till the edges of the scrollpane. > > Did I explain my problem clearly enough or do I need to rewrite it? > > Thanks in advance, best regards, > -- > Pedro Duque Vieira > -- Pedro Duque Vieira From hang.vo at oracle.com Wed Jun 6 13:48:28 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Jun 2012 20:48:28 +0000 Subject: hg: openjfx/2.2/controls/rt: Virtual keyboard: disable VK for non-editable text controls. Message-ID: <20120606204828.DB8E24775D@hg.openjdk.java.net> Changeset: b14d29378d60 Author: leifs Date: 2012-06-06 13:44 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/b14d29378d60 Virtual keyboard: disable VK for non-editable text controls. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java From richard.bair at oracle.com Wed Jun 6 14:01:05 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 6 Jun 2012 14:01:05 -0700 Subject: JavaFX 3D In-Reply-To: <4FCD972B.8080509@tbee.org> References: <127996.13253.7562-20772-1461349531-1337461207@seznam.cz> <194FBC30-2A1A-4071-92DA-2416D6F93334@oracle.com> <4FC1F70F.8020901@gmail.com> <4FCD972B.8080509@tbee.org> Message-ID: <56920DEB-F511-474F-A674-4D3CD2C870D3@oracle.com> Hi Tom, Here is an example application. Run it, and move the slider. You can see several differences between the left & right examples. You can switch between "createContent" and "createContent2" for different examples of the problems. Richard package javafxapplication1; import javafx.application.Application; import javafx.beans.InvalidationListener; import javafx.beans.Observable; import javafx.geometry.Insets; import javafx.scene.Node; import javafx.scene.Parent; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.Slider; import javafx.scene.control.Tab; import javafx.scene.control.TabPane; import javafx.scene.effect.DropShadow; import javafx.scene.layout.HBox; import javafx.scene.layout.StackPane; import javafx.scene.layout.VBox; import javafx.scene.paint.Color; import javafx.scene.shape.Rectangle; import javafx.stage.Stage; /** * * @author richardbair */ public class OpacityTest extends Application { @Override public void start(final Stage primaryStage) throws Exception { final Parent a = createContent2(); final Parent b = createContent2(); HBox hbox = new HBox(); hbox.getChildren().addAll(a, b); final Slider slider = new Slider(); slider.setMin(0); slider.setMax(1); slider.setValue(1); slider.valueProperty().addListener(new InvalidationListener() { @Override public void invalidated(Observable arg0) { a.setOpacity(slider.getValue()); setOpacity(b, slider.getValue()); } }); VBox root = new VBox(); root.setPadding(new Insets(5)); root.getChildren().addAll(hbox, slider); Scene scene = new Scene(root); primaryStage.setScene(scene); primaryStage.show(); primaryStage.setResizable(false); } private Parent createContent() { Rectangle cyan = new Rectangle(400, 400, Color.CYAN); Rectangle magenta = new Rectangle(300, 300, Color.MAGENTA); Rectangle yellow = new Rectangle(200, 200, Color.YELLOW); Rectangle black = new Rectangle(100, 100, Color.BLACK); StackPane stackPane = new StackPane(); stackPane.getChildren().addAll(cyan, magenta, yellow, black); return stackPane; } private Parent createContent2() { TabPane tabPane = new TabPane(); tabPane.getStyleClass().add(TabPane.STYLE_CLASS_FLOATING); Tab t1 = new Tab("First"); Tab t2 = new Tab("Second"); tabPane.getTabs().addAll(t1, t2); StackPane p1 = new StackPane(); Button b1 = new Button("Button1"); b1.setPrefSize(100, 100); b1.setEffect(new DropShadow()); p1.getChildren().add(b1); t1.setContent(p1); StackPane p2 = new StackPane(); Button b2 = new Button("Button2"); b2.setPrefSize(100, 100); b2.setEffect(new DropShadow()); p2.getChildren().add(b2); t2.setContent(p2); tabPane.setPrefSize(400, 400); StackPane stackPane = new StackPane(); stackPane.getChildren().addAll(tabPane); return stackPane; } private void setOpacity(Parent parent, double value) { for (Node n : parent.getChildrenUnmodifiable()) { if (n instanceof Parent) { setOpacity((Parent)n, value); } n.setOpacity(value); } } public static void main(String[] args) { launch(args); } } From hang.vo at oracle.com Wed Jun 6 16:48:35 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Jun 2012 23:48:35 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22106: Cancel and Default buttons still receive onAction events triggered by ESC and Enter keys when they are removed from the scene. Message-ID: <20120606234837.B1E0A47766@hg.openjdk.java.net> Changeset: c03a7b34ec86 Author: Kinsley Wong Date: 2012-06-06 16:37 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/c03a7b34ec86 RT-22106: Cancel and Default buttons still receive onAction events triggered by ESC and Enter keys when they are removed from the scene. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ButtonSkin.java ! javafx-ui-controls/test/javafx/scene/control/ButtonTest.java From hang.vo at oracle.com Wed Jun 6 17:02:40 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Jun 2012 00:02:40 +0000 Subject: hg: openjfx/2.2/master/rt: 58 new changesets Message-ID: <20120607000330.B49F147767@hg.openjdk.java.net> Changeset: c8c19d5e7527 Author: rbair Date: 2012-05-30 09:25 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/c8c19d5e7527 Fix for RT-21914: CheckBox API documentation example misnames as Checkbox ! javafx-ui-controls/src/javafx/scene/control/CheckBox.java Changeset: 9e776e8ca832 Author: rbair Date: 2012-05-30 12:24 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/9e776e8ca832 Fix for RT-21830: Improve Color startup by shortening the rgb calls for the predefined colors. The fix was to add a private constructor which takes 3 params instead of 4, all floats. (The 3 vs. 4 params makes it easier to make sure that we're only calling this constructor internally for the static colors). The static colors were converted over to use this constructor, and using pre-computed r, g, b float values (vs. the old approach of / 255.0 for each color at runtime). As this was a "Medium" priorty issue, probably actually a "Minor", I don't expect major gains from this. Just a little piece of salami. ! javafx-ui-common/src/javafx/scene/paint/Color.java Changeset: 7cdd9f231eff Author: rbair Date: 2012-05-30 12:32 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/7cdd9f231eff Fixed duplicate color declaration. ! javafx-ui-common/src/javafx/scene/paint/Color.java Changeset: 3edb1c7201e5 Author: rbair Date: 2012-05-30 14:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/3edb1c7201e5 Fix for RT-20880: IllegalStateException thrown from Service#restart(). Under some circumstances (such as if the task had already run) cancel returns false and the state is not changed to CANCELLED. Due to concurrency, the bindings & state of the service have not completed by the time reset is called by restart, and it is in the wrong state and throws an exception. Test added. ! javafx-concurrent/src/javafx/concurrent/Service.java ! javafx-concurrent/test/javafx/concurrent/ServiceLifecycleTest.java Changeset: bd432837e714 Author: rbair Date: 2012-05-30 15:24 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/bd432837e714 Fix for RT-19645: Task updateProgress should take double values, not long values ! javafx-concurrent/src/javafx/concurrent/Task.java Changeset: 63b0d121d3cd Author: kcr Date: 2012-06-01 16:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/63b0d121d3cd RT-21973: Suppress warning message when Toolkit is unable to load msvcr100.dll Reviewed by Igor ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java Changeset: 9be4d697d70f Author: kcr Date: 2012-06-01 16:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/9be4d697d70f RT-21789: node snapshot: wrong snapshot area Reviewed by Jim ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: a2b59544661f Author: kcr Date: 2012-06-01 16:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/a2b59544661f RT-21924: Passing in a null Callback as an argument to snapshot should throw NPE back to caller Reviewed by Jim ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 2faa9edf67c9 Author: Pavel Safrata Date: 2012-06-04 10:56 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/2faa9edf67c9 Minor javadoc improvements for input events (fixes RT-22005). ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/KeyEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchEvent.java Changeset: c795c8396f82 Author: Yao Wang Date: 2012-06-04 10:07 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/c795c8396f82 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt Changeset: 9e9695205c34 Author: Paru Somashekar Date: 2012-05-29 11:34 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/9e9695205c34 fix RT-21393 FXML declaration of javafx.scene.control.MenuItem does not propagate fx:id ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java Changeset: d60d057a30c9 Author: Kinsley Wong Date: 2012-05-29 11:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/d60d057a30c9 RT-21089: Tab.setOnSelectionChanged fires twice even if nothing has changed. ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java Changeset: 826caf92b089 Author: Kinsley Wong Date: 2012-05-29 12:33 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/826caf92b089 DOC Only: Fix typo in CheckBox example. ! javafx-ui-controls/src/javafx/scene/control/CheckBox.java Changeset: 34b65763aa33 Author: Kinsley Wong Date: 2012-05-29 14:02 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/34b65763aa33 RT-18815: TabPane drop-down tab list has no content if Tab text not set. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java Changeset: 29d96bd2ff47 Author: Paru Somashekar Date: 2012-05-29 16:03 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/29d96bd2ff47 fix RT-20121 Menu showing property change listener is not called on showing by keyboard. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! javafx-ui-controls/test/javafx/scene/control/MenuBarTest.java Changeset: 2605b68cbb49 Author: Kinsley Wong Date: 2012-05-29 17:03 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/2605b68cbb49 RT-20929: A button with setDefaultButton(true) consumes Enter event, even when it is disabled. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ButtonBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ButtonSkin.java ! javafx-ui-controls/test/javafx/scene/control/ButtonTest.java Changeset: 39958459bb92 Author: leifs Date: 2012-05-30 08:04 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/39958459bb92 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt Changeset: 30dacbe31d13 Author: Paru Somashekar Date: 2012-05-30 09:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/30dacbe31d13 fix RT-20792 Menu doesn't consume events properly. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java Changeset: 68d800e6784e Author: Paru Somashekar Date: 2012-05-30 12:09 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/68d800e6784e fix RT-21917 references in caspian css for colorpicker needs to be more specific RT-21113 Colorpicker if scene change its position, popup doesn't follow. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: 6a4a164faeff Author: leifs Date: 2012-05-30 14:25 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/6a4a164faeff Fixed RT-21493: RT-10392 introduced a 3-7% startup regression for GUIMark2 apps ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls.properties ! javafx-ui-controls/src/javafx/scene/control/Labeled.java Changeset: 8fb9ef26d4bc Author: David Grieve Date: 2012-05-30 17:58 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/8fb9ef26d4bc RT-21906: need to clear style cache when creating new StyleHelper ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java Changeset: d54eba721712 Author: jgiles Date: 2012-05-29 16:24 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/d54eba721712 Fix for TableView sorting that was accidently disabled. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java Changeset: 3275052b54fa Author: jgiles Date: 2012-05-29 16:40 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/3275052b54fa RT-21170: Make parent of nested columns end on the same coordinate as its final child ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java Changeset: ced2772737ea Author: jgiles Date: 2012-05-30 10:51 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/ced2772737ea RT-20300: TableView is not refreshed when TableColumn are added dynamically ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: 3009735752fb Author: jgiles Date: 2012-05-31 10:02 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/3009735752fb RT-21920: ComboBox editor should never be null when requested ! javafx-ui-controls/src/javafx/scene/control/ComboBox.java Changeset: 12d9e19e9c1a Author: jgiles Date: 2012-05-31 10:02 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/12d9e19e9c1a Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 42244b08c655 Author: Paru Somashekar Date: 2012-05-30 15:10 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/42244b08c655 fix RT-21552 ColorPicker esc behavior in custom colors dialog not implemented. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPalette.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ColorPickerPaletteRetriever.java ! javafx-ui-controls/test/javafx/scene/control/ColorPickerTest.java Changeset: a3957c32490c Author: Paru Somashekar Date: 2012-05-30 15:14 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/a3957c32490c merge Changeset: c8cde1376f90 Author: Kinsley Wong Date: 2012-05-30 16:09 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/c8cde1376f90 RT-21899: [Pagination] default property of page count is not as in docs. ! javafx-ui-controls/src/javafx/scene/control/Pagination.java Changeset: 28ee2f1219e1 Author: Kinsley Wong Date: 2012-05-30 16:11 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/28ee2f1219e1 RT-21899: reapply java doc fix for [Pagination] default property of page count is not as in docs. ! javafx-ui-controls/src/javafx/scene/control/Pagination.java Changeset: 686665e4dfa4 Author: Kinsley Wong Date: 2012-05-30 16:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/686665e4dfa4 RT-21902: [Pagination] STYLE_CLASS_BULLET is not applied fully. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 3771cf73348e Author: David Grieve Date: 2012-05-30 21:41 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/3771cf73348e RT-21906: fix NPE caused by previous changeset for this bug ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: 79ea942b7252 Author: David Grieve Date: 2012-05-30 21:43 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/79ea942b7252 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 3f7e8bfab133 Author: Paru Somashekar Date: 2012-05-30 23:43 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/3f7e8bfab133 fix RT-19359 It is impossible to jump over the disabled menu element. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! javafx-ui-controls/test/javafx/scene/control/MenuBarTest.java Changeset: ed79d22b904a Author: Kinsley Wong Date: 2012-05-31 11:21 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/ed79d22b904a RT-21903: Pagination indicators can be drawn outside of the control. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: c7f8d4c2bed0 Author: David Grieve Date: 2012-05-31 14:44 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/c7f8d4c2bed0 RT-21407: strip quotes from font-family value ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: c0638045c8c4 Author: Kinsley Wong Date: 2012-05-31 13:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/c0638045c8c4 RT-19951:Testcase testParentMinPrefMaxWidthAreEqual and testParentMinPrefMaxHeightAreEqual (javafx.scene.layout.ResizabilityTest) fail on hudson ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/test/unit/javafx/scene/layout/ResizabilityTest.java Changeset: 9bb30177cd6d Author: jgiles Date: 2012-06-01 09:38 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/9bb30177cd6d Fix for unit test failure based on recent changes to ComboBox editor behavior ! javafx-ui-controls/test/javafx/scene/control/ComboBoxTest.java Changeset: 1268d048f9b4 Author: jgiles Date: 2012-06-01 09:38 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/1268d048f9b4 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 4ed3df281641 Author: Kinsley Wong Date: 2012-05-31 15:01 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/4ed3df281641 RT-21854: Wrong SplitPane divider position. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SplitPaneSkin.java Changeset: cc964812fd59 Author: Paru Somashekar Date: 2012-05-31 15:43 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/cc964812fd59 fix RT-21959 Boolean styleable property -fx-color-label-visible does not work. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java Changeset: c954001bb9b5 Author: David Grieve Date: 2012-05-31 18:55 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/c954001bb9b5 RT-21960: when looking up font, set weight and posture from parsed value, not from converted font ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/test/unit/com/sun/javafx/css/FontTypeTest.java Changeset: 11001b9fd4d1 Author: Kinsley Wong Date: 2012-05-31 16:12 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/11001b9fd4d1 RT-21941: [TabPane] it is possible to select disabled tab from dropdown. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java Changeset: c398812e496c Author: David Grieve Date: 2012-05-31 20:11 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/c398812e496c RT-21965: css parse flag is the negation of binary.css system property, if it is set. ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: 7810088c2621 Author: David Grieve Date: 2012-05-31 20:13 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/7810088c2621 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: e5ccb1183358 Author: Kinsley Wong Date: 2012-05-31 18:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/e5ccb1183358 RT-21956: [Pagination] content can be not updated, if change factory during scrolling. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 3f7310d8b303 Author: mickf Date: 2012-06-01 13:52 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/3f7310d8b303 RT-20528 : Button Mneumonic Parsing causes leak ! javafx-ui-common/src/com/sun/javafx/scene/KeyboardShortcutsHandler.java + javafx-ui-common/test/unit/com/sun/javafx/scene/KeyboardShortcutsTest.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ButtonSkinTest.java Changeset: 503bac65e6bc Author: leifs Date: 2012-06-01 14:16 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/503bac65e6bc Fixed RT-21860: Virtual Keyboard throws an exception ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java Changeset: d7e46d20f756 Author: leifs Date: 2012-06-01 16:25 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/d7e46d20f756 Fixed RT-19171: [TextArea, Linux] text under selection can be white and black ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java Changeset: ba58ca4a265f Author: rbair Date: 2012-06-04 10:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/ba58ca4a265f Fix for RT-14177: -fx-skin can't work in OSGi-Envs. Tests forthcoming. ! javafx-ui-common/src/com/sun/javafx/Utils.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 887eb9b3f2bb Author: Paru Somashekar Date: 2012-06-04 12:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/887eb9b3f2bb fix RT-22032 : ColorPicker preview color should reflect final selected value. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPalette.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! javafx-ui-controls/src/javafx/scene/control/ColorPicker.java ! javafx-ui-controls/src/javafx/scene/control/ComboBoxBase.java Changeset: 959854f544a9 Author: Kinsley Wong Date: 2012-06-04 12:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/959854f544a9 RT-20573: GridPane: When ColumnConstraints.maxWidth=USE_PREF_SIZE and ColumnConstraints.prefWidth=USE_COMPUTED_SIZE then ColumnConstraints.minWidth is ignored.GridPane: When ColumnConstraints.maxWidth=USE_PREF_SIZE and ColumnConstraints.prefWidth=USE_COMPUTED_SIZE then ColumnConstraints.minWidth is ignored. ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/test/unit/javafx/scene/layout/GridPaneTest.java Changeset: 841f85729d35 Author: leifs Date: 2012-06-04 12:37 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/841f85729d35 Virtual keyboard: Add ID to key buttons for test purposes. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java Changeset: 1ea744e2e264 Author: leifs Date: 2012-06-04 13:27 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/1ea744e2e264 Fixed RT-20244: TextField consume ESC, thus cancel button not working when focus on a textfield ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java Changeset: 04cd43ba99ec Author: leifs Date: 2012-06-04 14:02 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/04cd43ba99ec Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt ! javafx-ui-common/src/javafx/scene/Node.java Changeset: d39767c34385 Author: mfang Date: 2012-06-01 00:03 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/d39767c34385 RT-21970: NLS: 2.2 message drop 10 integration - non-deploy files ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_de.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_es.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_fr.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_it.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_ja.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_ko.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_pt_BR.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_sv.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_zh_CN.properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls_zh_TW.properties Changeset: 348de34f8273 Author: igor Date: 2012-06-05 16:41 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/348de34f8273 Merge Changeset: 7be3c836bb43 Author: hudson Date: 2012-06-06 16:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/7be3c836bb43 Added tag 2.2-b12 for changeset 348de34f8273 ! .hgtags From hang.vo at oracle.com Wed Jun 6 17:04:29 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Jun 2012 00:04:29 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-22083 - fix GlobalMenuAdapter so menu action doesn't fire during validation Message-ID: <20120607000430.DD3D347768@hg.openjdk.java.net> Changeset: 2bbfe01c80b3 Author: Morris Meyer Date: 2012-06-06 19:59 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/2bbfe01c80b3 RT-22083 - fix GlobalMenuAdapter so menu action doesn't fire during validation ! javafx-ui-controls/src/com/sun/javafx/scene/control/GlobalMenuAdapter.java From hang.vo at oracle.com Wed Jun 6 18:49:02 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Jun 2012 01:49:02 +0000 Subject: hg: openjfx/2.2/controls/rt: 7 new changesets Message-ID: <20120607014908.879894776E@hg.openjdk.java.net> Changeset: b2064c0c3ba3 Author: jgiles Date: 2012-06-05 14:56 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/b2064c0c3ba3 RT-22038: HelloTableView layout problem ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableCellSkin.java Changeset: 12c454b407e2 Author: jgiles Date: 2012-06-05 15:40 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/12c454b407e2 RT-21336: Not editable ComboBox does not paint value setting by code (setValue()) when it does not exist in the list. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 612f0c898954 Author: jgiles Date: 2012-06-06 10:59 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/612f0c898954 RT-21207: ComboBox list width doesn't fit its content when first displayed (if the content is dynamically generated onShowing) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java Changeset: 0f911a5c52bb Author: jgiles Date: 2012-06-06 13:09 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/0f911a5c52bb RT-22025: [ComboBox] initial size doesn't respond the size of the widest content ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 29dd9c8675ec Author: jgiles Date: 2012-06-07 11:13 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/29dd9c8675ec RT-21341: TableView: Moving column to the left of next column moves it to the right of the next column ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkin.java Changeset: 9897f5b8a23d Author: jgiles Date: 2012-06-07 12:51 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/9897f5b8a23d RT-22122: When reordering TableColumns in a TableView, sometimes the header area disappears ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableHeaderRow.java Changeset: 60301b7fd01f Author: jgiles Date: 2012-06-07 13:43 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/60301b7fd01f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt From jmartine_1026 at yahoo.com Wed Jun 6 20:44:30 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Wed, 6 Jun 2012 20:44:30 -0700 (PDT) Subject: setting prism.dirtyopts in WebStart Message-ID: <1339040670.81459.YahooMailNeo@web160902.mail.bf1.yahoo.com> Hello, Has it been confirmed that setting prism.dirtyopts to false via JNLP is possible? ?Is there a way to check? In my tests it looks like it is not being set because I still see problems that went away by setting prism.dirtyopts to false in standalone mode. ? From the JNLP syntax document it suggests that it is not possible. ?http://docs.oracle.com/javase/7/docs/technotes/guides/javaws/developersguide/syntax.html#resources?(scroll down to jvm-args attribute and property element) The?java-vm-args attribute is restricted to the list of options in that link. ?The "property" elements seems to be restricted also. thanks jose From kevin.rushforth at oracle.com Wed Jun 6 20:55:24 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 06 Jun 2012 20:55:24 -0700 Subject: setting prism.dirtyopts in WebStart In-Reply-To: <1339040670.81459.YahooMailNeo@web160902.mail.bf1.yahoo.com> References: <1339040670.81459.YahooMailNeo@web160902.mail.bf1.yahoo.com> Message-ID: <4FD0262C.1040008@oracle.com> If you mean can you set this in your JNLP file, then no you cannot set arbitrary System properties. On your local system, you can set it for testing via the Java Control Panel (doing so with affect this for all Java Web Start apps). -- Kevin Jose Martinez wrote: > Hello, > > Has it been confirmed that setting prism.dirtyopts to false via JNLP is possible? Is there a way to check? > > In my tests it looks like it is not being set because I still see problems that went away by setting prism.dirtyopts to false in standalone mode. > > From the JNLP syntax document it suggests that it is not possible. http://docs.oracle.com/javase/7/docs/technotes/guides/javaws/developersguide/syntax.html#resources (scroll down to jvm-args attribute and property element) The java-vm-args attribute is restricted to the list of options in that link. The "property" elements seems to be restricted also. > > thanks > jose > From jmartine_1026 at yahoo.com Wed Jun 6 20:56:33 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Wed, 6 Jun 2012 20:56:33 -0700 (PDT) Subject: temporary performance issues when prism.dirtyopts set to false Message-ID: <1339041393.88493.YahooMailNeo@web160902.mail.bf1.yahoo.com> Hello, I notice performance issues when prism.dirtyopts is set to false. ?But it only happens during the first minute or so of game play. ?The animation is not smooth, it looks as if it has a low frame rate. ?But after a minute the animations becomes smooth for the rest of the program execution. ?The poor animation performance returns if I restart the application. Is this a known issue? ? thanks jose From jonathan.giles at oracle.com Wed Jun 6 21:04:28 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 07 Jun 2012 16:04:28 +1200 Subject: temporary performance issues when prism.dirtyopts set to false In-Reply-To: <1339041393.88493.YahooMailNeo@web160902.mail.bf1.yahoo.com> References: <1339041393.88493.YahooMailNeo@web160902.mail.bf1.yahoo.com> Message-ID: <4FD0284C.5090900@oracle.com> I am not in the graphics team, but given the present state of timezones I thought I'd reply to try to give some clarity. Hopefully someone will follow this up at a more suitable hour with a correct answer :-) Dirty opts in JavaFX is synonymous with the concept known as dirty rectangles, I believe. You can learn more about dirty rectangles at [1]. Basically it is an optimisation designed to limit the amount of drawing on the screen to only the areas that have changed since the last update. If dirty opts are disabled, as you are doing, you are basically telling JavaFX to redraw the whole screen on every pulse. This is clearly a far more expensive operation than just drawing the 'dirty' areas. So, in short, yes, this is a known issue with disabling dirty opts. Except it really isn't an issue - it is just the nature of things. The reason why Kevin asked for you to disable dirty opts was to try to trouble shoot the other issues you raised. You shouldn't go without dirty opts if at all possible. [1] http://c2.com/cgi/wiki?DirtyRectangles -- Jonathan On 7/06/2012 3:56 p.m., Jose Martinez wrote: > Hello, > > I notice performance issues when prism.dirtyopts is set to false. But it only happens during the first minute or so of game play. The animation is not smooth, it looks as if it has a low frame rate. But after a minute the animations becomes smooth for the rest of the program execution. The poor animation performance returns if I restart the application. > > Is this a known issue? > > thanks > jose From igor.nekrestyanov at oracle.com Wed Jun 6 21:05:47 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Wed, 06 Jun 2012 21:05:47 -0700 Subject: setting prism.dirtyopts in WebStart In-Reply-To: <1339040670.81459.YahooMailNeo@web160902.mail.bf1.yahoo.com> References: <1339040670.81459.YahooMailNeo@web160902.mail.bf1.yahoo.com> Message-ID: <4FD0289B.6090502@oracle.com> As it is not secure property you need to sign application. For tests on specific system you can set property in the Java Control Panel or use environment variables: http://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-Desktop/html/plugin.html#gcexdd -igor On 6/6/12 8:44 PM, Jose Martinez wrote: > Hello, > > Has it been confirmed that setting prism.dirtyopts to false via JNLP is possible? Is there a way to check? > > In my tests it looks like it is not being set because I still see problems that went away by setting prism.dirtyopts to false in standalone mode. > > From the JNLP syntax document it suggests that it is not possible. http://docs.oracle.com/javase/7/docs/technotes/guides/javaws/developersguide/syntax.html#resources (scroll down to jvm-args attribute and property element) The java-vm-args attribute is restricted to the list of options in that link. The "property" elements seems to be restricted also. > > thanks > jose From jmartine_1026 at yahoo.com Wed Jun 6 21:21:55 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Wed, 6 Jun 2012 21:21:55 -0700 (PDT) Subject: temporary performance issues when prism.dirtyopts set to false In-Reply-To: <4FD0284C.5090900@oracle.com> References: <1339041393.88493.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FD0284C.5090900@oracle.com> Message-ID: <1339042915.11923.YahooMailNeo@web160902.mail.bf1.yahoo.com> Thanks for the response. ?Please note that the poor performance is only temporary, during the first minute of game play. ?So I suspect there is hope to obtain good performance for the whole time. ? jose ________________________________ From: Jonathan Giles To: Jose Martinez Cc: openjfx mailing list Sent: Thursday, June 7, 2012 12:04 AM Subject: Re: temporary performance issues when prism.dirtyopts set to false I am not in the graphics team, but given the present state of timezones I thought I'd reply to try to give some clarity. Hopefully someone will follow this up at a more suitable hour with a correct answer :-) Dirty opts in JavaFX is synonymous with the concept known as dirty rectangles, I believe. You can learn more about dirty rectangles at [1]. Basically it is an optimisation designed to limit the amount of drawing on the screen to only the areas that have changed since the last update. If dirty opts are disabled, as you are doing, you are basically telling JavaFX to redraw the whole screen on every pulse. This is clearly a far more expensive operation than just drawing the 'dirty' areas. So, in short, yes, this is a known issue with disabling dirty opts. Except it really isn't an issue - it is just the nature of things. The reason why Kevin asked for you to disable dirty opts was to try to trouble shoot the other issues you raised. You shouldn't go without dirty opts if at all possible. [1] http://c2.com/cgi/wiki?DirtyRectangles -- Jonathan On 7/06/2012 3:56 p.m., Jose Martinez wrote: > Hello, > > I notice performance issues when prism.dirtyopts is set to false.? But it only happens during the first minute or so of game play.? The animation is not smooth, it looks as if it has a low frame rate.? But after a minute the animations becomes smooth for the rest of the program execution.? The poor animation performance returns if I restart the application. > > Is this a known issue? >? thanks > jose From jmartine_1026 at yahoo.com Wed Jun 6 21:23:36 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Wed, 6 Jun 2012 21:23:36 -0700 (PDT) Subject: setting prism.dirtyopts in WebStart In-Reply-To: <4FD0289B.6090502@oracle.com> References: <1339040670.81459.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FD0289B.6090502@oracle.com> Message-ID: <1339043016.26891.YahooMailNeo@web160903.mail.bf1.yahoo.com> Thanks a lot guys. ?Will give that a shot. But even if that works what can I do when this is released to the masses? ?Anyway I can set the value within code? ? thanks jose ________________________________ From: Igor Nekrestyanov To: Jose Martinez Cc: openjfx mailing list Sent: Thursday, June 7, 2012 12:05 AM Subject: Re: setting prism.dirtyopts in WebStart As it is not secure property you need to sign application. For tests on specific system you can set property in the Java Control Panel or use environment variables: ? http://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-Desktop/html/plugin.html#gcexdd -igor On 6/6/12 8:44 PM, Jose Martinez wrote: > Hello, > > Has it been confirmed that setting prism.dirtyopts to false via JNLP is possible?? Is there a way to check? > > In my tests it looks like it is not being set because I still see problems that went away by setting prism.dirtyopts to false in standalone mode. >? ? From the JNLP syntax document it suggests that it is not possible.? http://docs.oracle.com/javase/7/docs/technotes/guides/javaws/developersguide/syntax.html#resources (scroll down to jvm-args attribute and property element) The java-vm-args attribute is restricted to the list of options in that link.? The "property" elements seems to be restricted also. > > thanks > jose From pavel.safrata at oracle.com Wed Jun 6 22:58:36 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 07 Jun 2012 07:58:36 +0200 Subject: temporary performance issues when prism.dirtyopts set to false In-Reply-To: <1339042915.11923.YahooMailNeo@web160902.mail.bf1.yahoo.com> References: <1339041393.88493.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FD0284C.5090900@oracle.com> <1339042915.11923.YahooMailNeo@web160902.mail.bf1.yahoo.com> Message-ID: <4FD0430C.2030503@oracle.com> Hi Jose, Jonathan is absolutely right. Disabling dirty opts is a good tool for narrowing the problem, but you should never want to do it for public use. The performance is significantly worse and will always be. The application must render the same screens with and without dirty opts and if it doesn't, there is a bug in FX that needs to be fixed immediately. Could you please file one? Thanks, Pavel On 7.6.2012 6:21, Jose Martinez wrote: > Thanks for the response. Please note that the poor performance is only temporary, during the first minute of game play. So I suspect there is hope to obtain good performance for the whole time. > > jose > > > ________________________________ > From: Jonathan Giles > To: Jose Martinez > Cc: openjfx mailing list > Sent: Thursday, June 7, 2012 12:04 AM > Subject: Re: temporary performance issues when prism.dirtyopts set to false > > I am not in the graphics team, but given the present state of timezones I thought I'd reply to try to give some clarity. Hopefully someone will follow this up at a more suitable hour with a correct answer :-) > > Dirty opts in JavaFX is synonymous with the concept known as dirty rectangles, I believe. You can learn more about dirty rectangles at [1]. Basically it is an optimisation designed to limit the amount of drawing on the screen to only the areas that have changed since the last update. If dirty opts are disabled, as you are doing, you are basically telling JavaFX to redraw the whole screen on every pulse. This is clearly a far more expensive operation than just drawing the 'dirty' areas. > > So, in short, yes, this is a known issue with disabling dirty opts. Except it really isn't an issue - it is just the nature of things. The reason why Kevin asked for you to disable dirty opts was to try to trouble shoot the other issues you raised. You shouldn't go without dirty opts if at all possible. > > [1] http://c2.com/cgi/wiki?DirtyRectangles > > -- Jonathan > > > On 7/06/2012 3:56 p.m., Jose Martinez wrote: >> Hello, >> >> I notice performance issues when prism.dirtyopts is set to false. But it only happens during the first minute or so of game play. The animation is not smooth, it looks as if it has a low frame rate. But after a minute the animations becomes smooth for the rest of the program execution. The poor animation performance returns if I restart the application. >> >> Is this a known issue? >> thanks >> jose From jmartine_1026 at yahoo.com Wed Jun 6 23:10:47 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Wed, 6 Jun 2012 23:10:47 -0700 (PDT) Subject: temporary performance issues when prism.dirtyopts set to false In-Reply-To: <4FD0430C.2030503@oracle.com> References: <1339041393.88493.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FD0284C.5090900@oracle.com> <1339042915.11923.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FD0430C.2030503@oracle.com> Message-ID: <1339049447.68617.YahooMailNeo@web160901.mail.bf1.yahoo.com> Ok I follow, that's a good point. ?Will fill two out for the problems I am seeing when ditryopts is set to true.... didn't realize ditryopts set to false is only for testing. Thank you! jose ________________________________ From: Pavel Safrata To: openjfx-dev at openjdk.java.net Sent: Thursday, June 7, 2012 1:58 AM Subject: Re: temporary performance issues when prism.dirtyopts set to false Hi Jose, Jonathan is absolutely right. Disabling dirty opts is a good tool for narrowing the problem, but you should never want to do it for public use. The performance is significantly worse and will always be. The application must render the same screens with and without dirty opts and if it doesn't, there is a bug in FX that needs to be fixed immediately. Could you please file one? Thanks, Pavel On 7.6.2012 6:21, Jose Martinez wrote: > Thanks for the response.? Please note that the poor performance is only temporary, during the first minute of game play.? So I suspect there is hope to obtain good performance for the whole time. >? > jose > > > ________________________________ >? From: Jonathan Giles > To: Jose Martinez > Cc: openjfx mailing list > Sent: Thursday, June 7, 2012 12:04 AM > Subject: Re: temporary performance issues when prism.dirtyopts set to false > > I am not in the graphics team, but given the present state of timezones I thought I'd reply to try to give some clarity. Hopefully someone will follow this up at a more suitable hour with a correct answer :-) > > Dirty opts in JavaFX is synonymous with the concept known as dirty rectangles, I believe. You can learn more about dirty rectangles at [1]. Basically it is an optimisation designed to limit the amount of drawing on the screen to only the areas that have changed since the last update. If dirty opts are disabled, as you are doing, you are basically telling JavaFX to redraw the whole screen on every pulse. This is clearly a far more expensive operation than just drawing the 'dirty' areas. > > So, in short, yes, this is a known issue with disabling dirty opts. Except it really isn't an issue - it is just the nature of things. The reason why Kevin asked for you to disable dirty opts was to try to trouble shoot the other issues you raised. You shouldn't go without dirty opts if at all possible. > > [1] http://c2.com/cgi/wiki?DirtyRectangles > > -- Jonathan > > > On 7/06/2012 3:56 p.m., Jose Martinez wrote: >> Hello, >> >> I notice performance issues when prism.dirtyopts is set to false.? But it only happens during the first minute or so of game play.? The animation is not smooth, it looks as if it has a low frame rate.? But after a minute the animations becomes smooth for the rest of the program execution.? The poor animation performance returns if I restart the application. >> >> Is this a known issue? >>? ? thanks >> jose From jmartine_1026 at yahoo.com Wed Jun 6 23:44:34 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Wed, 6 Jun 2012 23:44:34 -0700 (PDT) Subject: temporary performance issues when prism.dirtyopts set to false In-Reply-To: <1339049447.68617.YahooMailNeo@web160901.mail.bf1.yahoo.com> References: <1339041393.88493.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FD0284C.5090900@oracle.com> <1339042915.11923.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FD0430C.2030503@oracle.com> <1339049447.68617.YahooMailNeo@web160901.mail.bf1.yahoo.com> Message-ID: <1339051474.15454.YahooMailNeo@web160906.mail.bf1.yahoo.com> Jira 22127 and 22126 created. ? jose ________________________________ From: Jose Martinez To: Pavel Safrata ; "openjfx-dev at openjdk.java.net" Sent: Thursday, June 7, 2012 2:10 AM Subject: Re: temporary performance issues when prism.dirtyopts set to false Ok I follow, that's a good point. ?Will fill two out for the problems I am seeing when ditryopts is set to true.... didn't realize ditryopts set to false is only for testing. Thank you! jose ________________________________ From: Pavel Safrata To: openjfx-dev at openjdk.java.net Sent: Thursday, June 7, 2012 1:58 AM Subject: Re: temporary performance issues when prism.dirtyopts set to false Hi Jose, Jonathan is absolutely right. Disabling dirty opts is a good tool for narrowing the problem, but you should never want to do it for public use. The performance is significantly worse and will always be. The application must render the same screens with and without dirty opts and if it doesn't, there is a bug in FX that needs to be fixed immediately. Could you please file one? Thanks, Pavel On 7.6.2012 6:21, Jose Martinez wrote: > Thanks for the response.? Please note that the poor performance is only temporary, during the first minute of game play.? So I suspect there is hope to obtain good performance for the whole time. >? > jose > > > ________________________________ >?? From: Jonathan Giles > To: Jose Martinez > Cc: openjfx mailing list > Sent: Thursday, June 7, 2012 12:04 AM > Subject: Re: temporary performance issues when prism.dirtyopts set to false > > I am not in the graphics team, but given the present state of timezones I thought I'd reply to try to give some clarity. Hopefully someone will follow this up at a more suitable hour with a correct answer :-) > > Dirty opts in JavaFX is synonymous with the concept known as dirty rectangles, I believe. You can learn more about dirty rectangles at [1]. Basically it is an optimisation designed to limit the amount of drawing on the screen to only the areas that have changed since the last update. If dirty opts are disabled, as you are doing, you are basically telling JavaFX to redraw the whole screen on every pulse. This is clearly a far more expensive operation than just drawing the 'dirty' areas. > > So, in short, yes, this is a known issue with disabling dirty opts. Except it really isn't an issue - it is just the nature of things. The reason why Kevin asked for you to disable dirty opts was to try to trouble shoot the other issues you raised. You shouldn't go without dirty opts if at all possible. > > [1] http://c2.com/cgi/wiki?DirtyRectangles > > -- Jonathan > > > On 7/06/2012 3:56 p.m., Jose Martinez wrote: >> Hello, >> >> I notice performance issues when prism.dirtyopts is set to false.? But it only happens during the first minute or so of game play.? The animation is not smooth, it looks as if it has a low frame rate.? But after a minute the animations becomes smooth for the rest of the program execution.? The poor animation performance returns if I restart the application. >> >> Is this a known issue? >>? ?? thanks >> jose From pavel.safrata at oracle.com Wed Jun 6 23:45:46 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 07 Jun 2012 08:45:46 +0200 Subject: temporary performance issues when prism.dirtyopts set to false In-Reply-To: <1339051474.15454.YahooMailNeo@web160906.mail.bf1.yahoo.com> References: <1339041393.88493.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FD0284C.5090900@oracle.com> <1339042915.11923.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FD0430C.2030503@oracle.com> <1339049447.68617.YahooMailNeo@web160901.mail.bf1.yahoo.com> <1339051474.15454.YahooMailNeo@web160906.mail.bf1.yahoo.com> Message-ID: <4FD04E1A.10008@oracle.com> Thanks! Pavel On 7.6.2012 8:44, Jose Martinez wrote: > Jira 22127 and 22126 created. > jose > ------------------------------------------------------------------------ > *From:* Jose Martinez > *To:* Pavel Safrata ; > "openjfx-dev at openjdk.java.net" > *Sent:* Thursday, June 7, 2012 2:10 AM > *Subject:* Re: temporary performance issues when prism.dirtyopts set > to false > > Ok I follow, that's a good point. Will fill two out for the problems > I am seeing when ditryopts is set to true.... didn't realize ditryopts > set to false is only for testing. > > Thank you! > jose > > > ________________________________ > From: Pavel Safrata > > To: openjfx-dev at openjdk.java.net > Sent: Thursday, June 7, 2012 1:58 AM > Subject: Re: temporary performance issues when prism.dirtyopts set to > false > > Hi Jose, > Jonathan is absolutely right. Disabling dirty opts is a good tool for > narrowing the problem, but you should never want to do it for public > use. The performance is significantly worse and will always be. The > application must render the same screens with and without dirty opts and > if it doesn't, there is a bug in FX that needs to be fixed immediately. > Could you please file one? > Thanks, > Pavel > > On 7.6.2012 6:21, Jose Martinez wrote: > > Thanks for the response. Please note that the poor performance is > only temporary, during the first minute of game play. So I suspect > there is hope to obtain good performance for the whole time. > > > > jose > > > > > > ________________________________ > > From: Jonathan Giles > > > To: Jose Martinez > > > Cc: openjfx mailing list > > > Sent: Thursday, June 7, 2012 12:04 AM > > Subject: Re: temporary performance issues when prism.dirtyopts set > to false > > > > I am not in the graphics team, but given the present state of > timezones I thought I'd reply to try to give some clarity. Hopefully > someone will follow this up at a more suitable hour with a correct > answer :-) > > > > Dirty opts in JavaFX is synonymous with the concept known as dirty > rectangles, I believe. You can learn more about dirty rectangles at > [1]. Basically it is an optimisation designed to limit the amount of > drawing on the screen to only the areas that have changed since the > last update. If dirty opts are disabled, as you are doing, you are > basically telling JavaFX to redraw the whole screen on every pulse. > This is clearly a far more expensive operation than just drawing the > 'dirty' areas. > > > > So, in short, yes, this is a known issue with disabling dirty opts. > Except it really isn't an issue - it is just the nature of things. The > reason why Kevin asked for you to disable dirty opts was to try to > trouble shoot the other issues you raised. You shouldn't go without > dirty opts if at all possible. > > > > [1] http://c2.com/cgi/wiki?DirtyRectangles > > > > -- Jonathan > > > > > > On 7/06/2012 3:56 p.m., Jose Martinez wrote: > >> Hello, > >> > >> I notice performance issues when prism.dirtyopts is set to false. > But it only happens during the first minute or so of game play. The > animation is not smooth, it looks as if it has a low frame rate. But > after a minute the animations becomes smooth for the rest of the > program execution. The poor animation performance returns if I > restart the application. > >> > >> Is this a known issue? > >> thanks > >> jose > > From kevin.rushforth at oracle.com Thu Jun 7 05:08:14 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 07 Jun 2012 05:08:14 -0700 Subject: temporary performance issues when prism.dirtyopts set to false In-Reply-To: <1339049447.68617.YahooMailNeo@web160901.mail.bf1.yahoo.com> References: <1339041393.88493.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FD0284C.5090900@oracle.com> <1339042915.11923.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FD0430C.2030503@oracle.com> <1339049447.68617.YahooMailNeo@web160901.mail.bf1.yahoo.com> Message-ID: <4FD099AE.3030808@oracle.com> Yes, sorry for not making that clear when I asked you to set it to help narrow down the problem. We do not intend that prism.dirtyopts, or any other debugging flag be used in production by an application. -- Kevin Jose Martinez wrote: > Ok I follow, that's a good point. Will fill two out for the problems I am seeing when ditryopts is set to true.... didn't realize ditryopts set to false is only for testing. > > Thank you! > jose > > > ________________________________ > From: Pavel Safrata > To: openjfx-dev at openjdk.java.net > Sent: Thursday, June 7, 2012 1:58 AM > Subject: Re: temporary performance issues when prism.dirtyopts set to false > > Hi Jose, > Jonathan is absolutely right. Disabling dirty opts is a good tool for > narrowing the problem, but you should never want to do it for public > use. The performance is significantly worse and will always be. The > application must render the same screens with and without dirty opts and > if it doesn't, there is a bug in FX that needs to be fixed immediately. > Could you please file one? > Thanks, > Pavel > > On 7.6.2012 6:21, Jose Martinez wrote: > >> Thanks for the response. Please note that the poor performance is only temporary, during the first minute of game play. So I suspect there is hope to obtain good performance for the whole time. >> >> jose >> >> >> ________________________________ >> From: Jonathan Giles >> To: Jose Martinez >> Cc: openjfx mailing list >> Sent: Thursday, June 7, 2012 12:04 AM >> Subject: Re: temporary performance issues when prism.dirtyopts set to false >> >> I am not in the graphics team, but given the present state of timezones I thought I'd reply to try to give some clarity. Hopefully someone will follow this up at a more suitable hour with a correct answer :-) >> >> Dirty opts in JavaFX is synonymous with the concept known as dirty rectangles, I believe. You can learn more about dirty rectangles at [1]. Basically it is an optimisation designed to limit the amount of drawing on the screen to only the areas that have changed since the last update. If dirty opts are disabled, as you are doing, you are basically telling JavaFX to redraw the whole screen on every pulse. This is clearly a far more expensive operation than just drawing the 'dirty' areas. >> >> So, in short, yes, this is a known issue with disabling dirty opts. Except it really isn't an issue - it is just the nature of things. The reason why Kevin asked for you to disable dirty opts was to try to trouble shoot the other issues you raised. You shouldn't go without dirty opts if at all possible. >> >> [1] http://c2.com/cgi/wiki?DirtyRectangles >> >> -- Jonathan >> >> >> On 7/06/2012 3:56 p.m., Jose Martinez wrote: >> >>> Hello, >>> >>> I notice performance issues when prism.dirtyopts is set to false. But it only happens during the first minute or so of game play. The animation is not smooth, it looks as if it has a low frame rate. But after a minute the animations becomes smooth for the rest of the program execution. The poor animation performance returns if I restart the application. >>> >>> Is this a known issue? >>> thanks >>> jose >>> From hang.vo at oracle.com Thu Jun 7 05:18:57 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Jun 2012 12:18:57 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-21888: fixed intial state of FocusedProperty. Message-ID: <20120607121902.7F1B247787@hg.openjdk.java.net> Changeset: 2b45c041ff58 Author: Pavel Safrata Date: 2012-06-07 14:03 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/2b45c041ff58 RT-21888: fixed intial state of FocusedProperty. ! javafx-ui-common/src/javafx/scene/Node.java From hang.vo at oracle.com Thu Jun 7 08:05:01 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Jun 2012 15:05:01 +0000 Subject: hg: openjfx/2.2/graphics/rt: Fix for RT-22142: Intermittent unit test failures in javafx.stage.PopupTest with JDK7 Message-ID: <20120607150503.B62DC47796@hg.openjdk.java.net> Changeset: dd0048db6e86 Author: Lubomir Nerad Date: 2012-06-07 16:59 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/dd0048db6e86 Fix for RT-22142: Intermittent unit test failures in javafx.stage.PopupTest with JDK7 ! javafx-ui-common/test/unit/javafx/stage/PopupTest.java From hang.vo at oracle.com Thu Jun 7 10:18:52 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Jun 2012 17:18:52 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-21952 : Click on button opens context menu Message-ID: <20120607171854.B1466477A1@hg.openjdk.java.net> Changeset: defcb2e3aa77 Author: mickf Date: 2012-06-07 18:03 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/defcb2e3aa77 RT-21952 : Click on button opens context menu ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ButtonSkin.java ! javafx-ui-controls/test/javafx/scene/control/ButtonTest.java From hang.vo at oracle.com Thu Jun 7 12:04:07 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Jun 2012 19:04:07 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-21782 - Embedded : ScrollPane : ScrollBars need to account for corner when both are present. Message-ID: <20120607190409.3D0D4477AE@hg.openjdk.java.net> Changeset: 966cbfed8d62 Author: mickf Date: 2012-06-07 19:50 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/966cbfed8d62 RT-21782 - Embedded : ScrollPane : ScrollBars need to account for corner when both are present. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java From hang.vo at oracle.com Thu Jun 7 13:04:27 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Jun 2012 20:04:27 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-21006: unit test canvas update Message-ID: <20120607200429.BA206477B8@hg.openjdk.java.net> Changeset: 4427dc34e097 Author: "Joseph Andresen" Date: 2012-06-07 11:26 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/4427dc34e097 RT-21006: unit test canvas update ! javafx-ui-common/test/unit/javafx/scene/canvas/CanvasTest.java From hang.vo at oracle.com Thu Jun 7 13:04:34 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Jun 2012 20:04:34 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22027: Exception raised for a ComboBox in an Accordion. Message-ID: <20120607200435.72F78477B9@hg.openjdk.java.net> Changeset: dfa7572ff039 Author: Kinsley Wong Date: 2012-06-07 12:47 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/dfa7572ff039 RT-22027: Exception raised for a ComboBox in an Accordion. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/AccordionBehavior.java ! javafx-ui-controls/test/javafx/scene/control/AccordionTest.java From hang.vo at oracle.com Fri Jun 8 00:49:45 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Jun 2012 07:49:45 +0000 Subject: hg: openjfx/2.2/graphics/rt: TouchPoint constructor removed from public API. Message-ID: <20120608074947.AEA62477E9@hg.openjdk.java.net> Changeset: c9f8ab00f5be Author: Pavel Safrata Date: 2012-06-08 09:39 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/c9f8ab00f5be TouchPoint constructor removed from public API. ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/TouchPoint.java - javafx-ui-common/test/unit/javafx/scene/input/TouchPoint_builder_Test.java From hang.vo at oracle.com Fri Jun 8 04:34:34 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Jun 2012 11:34:34 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-22150: fixed event delivery to nodes with non-invertible transformation. Message-ID: <20120608113436.917A7477EF@hg.openjdk.java.net> Changeset: d5146a3b928f Author: Pavel Safrata Date: 2012-06-08 13:16 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/d5146a3b928f RT-22150: fixed event delivery to nodes with non-invertible transformation. ! javafx-ui-common/src/com/sun/javafx/scene/input/InputEventUtils.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java ! javafx-ui-common/src/javafx/scene/input/DragEvent.java ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchPoint.java ! javafx-ui-common/test/unit/javafx/scene/MouseTest.java From tom.schindl at bestsolution.at Fri Jun 8 07:33:36 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 08 Jun 2012 16:33:36 +0200 Subject: Doubts on LinearGradient#proportional=true Message-ID: <4FD20D40.3040809@bestsolution.at> Hi, I'm not sure if i understood proportional true wrong or I'm found a serious bug. > import java.util.ArrayList; > import java.util.List; > > import javafx.application.Application; > import javafx.scene.Group; > import javafx.scene.Scene; > import javafx.scene.paint.Color; > import javafx.scene.paint.CycleMethod; > import javafx.scene.paint.LinearGradient; > import javafx.scene.paint.Stop; > import javafx.scene.shape.Rectangle; > import javafx.stage.Stage; > > public class TestGradient extends Application { > > /** > * @param args > */ > public static void main(String[] args) { > launch(args); > } > > @Override > public void start(Stage primaryStage) throws Exception { > Group g = new Group(); > Rectangle r = new Rectangle(40,0,90,75); > List stops = new ArrayList(); > stops.add(new Stop(0, Color.RED)); > stops.add(new Stop(1, Color.BLUE)); > LinearGradient lg = new LinearGradient(0, 0, 90, 0, false, CycleMethod.NO_CYCLE, stops); > r.setFill(lg); > g.getChildren().add(r); > Scene s = new Scene(g,200,200); > primaryStage.setScene(s); > primaryStage.show(); > } > > } Running this code gives me an UI like shown in the attached screenshot. Is this really the right behaviour? I'd expect red to start on the left of the rect and end at 1/2 of the width. Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From han.solo at muenster.de Fri Jun 8 07:40:16 2012 From: han.solo at muenster.de (Gerrit Grunwald) Date: Fri, 8 Jun 2012 16:40:16 +0200 Subject: Doubts on LinearGradient#proportional=true In-Reply-To: <4FD20D40.3040809@bestsolution.at> References: <4FD20D40.3040809@bestsolution.at> Message-ID: <95F7C6E7-2D60-4C4D-B4D8-50408517B9FA@muenster.de> Hi, But you defined the LinearGradient to start at 0, 0 and the Rectangle starts at 40, 0 so i guess the behavior is correct. The following code should give you what you expected to get: LinearGradient lg = new LinearGradient(r.getX(), 0, r.getWidth(), 0, false, CycleMethod.NO_CYCLE, stops); Cheers, Gerrit Am 08.06.2012 um 16:33 schrieb Tom Schindl: > Hi, > > I'm not sure if i understood proportional true wrong or I'm found a > serious bug. > >> import java.util.ArrayList; >> import java.util.List; >> >> import javafx.application.Application; >> import javafx.scene.Group; >> import javafx.scene.Scene; >> import javafx.scene.paint.Color; >> import javafx.scene.paint.CycleMethod; >> import javafx.scene.paint.LinearGradient; >> import javafx.scene.paint.Stop; >> import javafx.scene.shape.Rectangle; >> import javafx.stage.Stage; >> >> public class TestGradient extends Application { >> >> /** >> * @param args >> */ >> public static void main(String[] args) { >> launch(args); >> } >> >> @Override >> public void start(Stage primaryStage) throws Exception { >> Group g = new Group(); >> Rectangle r = new Rectangle(40,0,90,75); >> List stops = new ArrayList(); >> stops.add(new Stop(0, Color.RED)); >> stops.add(new Stop(1, Color.BLUE)); >> LinearGradient lg = new LinearGradient(0, 0, 90, 0, false, CycleMethod.NO_CYCLE, stops); >> r.setFill(lg); >> g.getChildren().add(r); >> Scene s = new Scene(g,200,200); >> primaryStage.setScene(s); >> primaryStage.show(); >> } >> >> } > > Running this code gives me an UI like shown in the attached screenshot. > Is this really the right behaviour? I'd expect red to start on the left > of the rect and end at 1/2 of the width. > > Tom > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From tom.schindl at bestsolution.at Fri Jun 8 07:44:29 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 08 Jun 2012 16:44:29 +0200 Subject: Doubts on LinearGradient#proportional=true In-Reply-To: <4FD20D40.3040809@bestsolution.at> References: <4FD20D40.3040809@bestsolution.at> Message-ID: <4FD20FCD.4050601@bestsolution.at> Naturally the title should proportional=false! Tom Am 08.06.12 16:33, schrieb Tom Schindl: > Hi, > > I'm not sure if i understood proportional true wrong or I'm found a > serious bug. > >> import java.util.ArrayList; >> import java.util.List; >> >> import javafx.application.Application; >> import javafx.scene.Group; >> import javafx.scene.Scene; >> import javafx.scene.paint.Color; >> import javafx.scene.paint.CycleMethod; >> import javafx.scene.paint.LinearGradient; >> import javafx.scene.paint.Stop; >> import javafx.scene.shape.Rectangle; >> import javafx.stage.Stage; >> >> public class TestGradient extends Application { >> >> /** >> * @param args >> */ >> public static void main(String[] args) { >> launch(args); >> } >> >> @Override >> public void start(Stage primaryStage) throws Exception { >> Group g = new Group(); >> Rectangle r = new Rectangle(40,0,90,75); >> List stops = new ArrayList(); >> stops.add(new Stop(0, Color.RED)); >> stops.add(new Stop(1, Color.BLUE)); >> LinearGradient lg = new LinearGradient(0, 0, 90, 0, false, CycleMethod.NO_CYCLE, stops); >> r.setFill(lg); >> g.getChildren().add(r); >> Scene s = new Scene(g,200,200); >> primaryStage.setScene(s); >> primaryStage.show(); >> } >> >> } > > Running this code gives me an UI like shown in the attached screenshot. > Is this really the right behaviour? I'd expect red to start on the left > of the rect and end at 1/2 of the width. > > Tom > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From pavel.safrata at oracle.com Fri Jun 8 07:44:41 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Fri, 08 Jun 2012 16:44:41 +0200 Subject: Doubts on LinearGradient#proportional=true In-Reply-To: <4FD20D40.3040809@bestsolution.at> References: <4FD20D40.3040809@bestsolution.at> Message-ID: <4FD20FD9.7020900@oracle.com> Hi Tom, did you forget to attach the image or did the system strip it somewhere along the way? I executed your code and saw exactly what you expected - gradient in the left half of the rectangle, what do you see? By the way, the code uses proportional=false, unlike suggested in the description, so please try to clarify your question. Thanks, Pavel On 8.6.2012 16:33, Tom Schindl wrote: > Hi, > > I'm not sure if i understood proportional true wrong or I'm found a > serious bug. > >> import java.util.ArrayList; >> import java.util.List; >> >> import javafx.application.Application; >> import javafx.scene.Group; >> import javafx.scene.Scene; >> import javafx.scene.paint.Color; >> import javafx.scene.paint.CycleMethod; >> import javafx.scene.paint.LinearGradient; >> import javafx.scene.paint.Stop; >> import javafx.scene.shape.Rectangle; >> import javafx.stage.Stage; >> >> public class TestGradient extends Application { >> >> /** >> * @param args >> */ >> public static void main(String[] args) { >> launch(args); >> } >> >> @Override >> public void start(Stage primaryStage) throws Exception { >> Group g = new Group(); >> Rectangle r = new Rectangle(40,0,90,75); >> List stops = new ArrayList(); >> stops.add(new Stop(0, Color.RED)); >> stops.add(new Stop(1, Color.BLUE)); >> LinearGradient lg = new LinearGradient(0, 0, 90, 0, false, CycleMethod.NO_CYCLE, stops); >> r.setFill(lg); >> g.getChildren().add(r); >> Scene s = new Scene(g,200,200); >> primaryStage.setScene(s); >> primaryStage.show(); >> } >> >> } > Running this code gives me an UI like shown in the attached screenshot. > Is this really the right behaviour? I'd expect red to start on the left > of the rect and end at 1/2 of the width. > > Tom > From tom.schindl at bestsolution.at Fri Jun 8 07:48:26 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 08 Jun 2012 16:48:26 +0200 Subject: Doubts on LinearGradient#proportional=true In-Reply-To: <4FD20FD9.7020900@oracle.com> References: <4FD20D40.3040809@bestsolution.at> <4FD20FD9.7020900@oracle.com> Message-ID: <4FD210BA.8010406@bestsolution.at> It looks like the image gets stripped. Let me upload it somewhere and come back to you Tom Am 08.06.12 16:44, schrieb Pavel Safrata: > Hi Tom, > did you forget to attach the image or did the system strip it somewhere > along the way? I executed your code and saw exactly what you expected - > gradient in the left half of the rectangle, what do you see? By the way, > the code uses proportional=false, unlike suggested in the description, > so please try to clarify your question. > Thanks, > Pavel > > On 8.6.2012 16:33, Tom Schindl wrote: >> Hi, >> >> I'm not sure if i understood proportional true wrong or I'm found a >> serious bug. >> >>> import java.util.ArrayList; >>> import java.util.List; >>> >>> import javafx.application.Application; >>> import javafx.scene.Group; >>> import javafx.scene.Scene; >>> import javafx.scene.paint.Color; >>> import javafx.scene.paint.CycleMethod; >>> import javafx.scene.paint.LinearGradient; >>> import javafx.scene.paint.Stop; >>> import javafx.scene.shape.Rectangle; >>> import javafx.stage.Stage; >>> >>> public class TestGradient extends Application { >>> >>> /** >>> * @param args >>> */ >>> public static void main(String[] args) { >>> launch(args); >>> } >>> >>> @Override >>> public void start(Stage primaryStage) throws Exception { >>> Group g = new Group(); >>> Rectangle r = new Rectangle(40,0,90,75); >>> List stops = new ArrayList(); >>> stops.add(new Stop(0, Color.RED)); >>> stops.add(new Stop(1, Color.BLUE)); >>> LinearGradient lg = new LinearGradient(0, 0, 90, 0, false, >>> CycleMethod.NO_CYCLE, stops); >>> r.setFill(lg); >>> g.getChildren().add(r); >>> Scene s = new Scene(g,200,200); >>> primaryStage.setScene(s); >>> primaryStage.show(); >>> } >>> >>> } >> Running this code gives me an UI like shown in the attached screenshot. >> Is this really the right behaviour? I'd expect red to start on the left >> of the rect and end at 1/2 of the width. >> >> Tom >> -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From tom.schindl at bestsolution.at Fri Jun 8 07:50:25 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 08 Jun 2012 16:50:25 +0200 Subject: Doubts on LinearGradient#proportional=true In-Reply-To: <95F7C6E7-2D60-4C4D-B4D8-50408517B9FA@muenster.de> References: <4FD20D40.3040809@bestsolution.at> <95F7C6E7-2D60-4C4D-B4D8-50408517B9FA@muenster.de> Message-ID: <4FD21131.4050407@bestsolution.at> yes but why do I need to let the gradient start at 40? I would expect the gradient to start at the left bound of the node. For a rect-x is fairly easy to calculate for a SVGPath-Node it gets fairly impossible. Tom Am 08.06.12 16:40, schrieb Gerrit Grunwald: > Hi, > > But you defined the LinearGradient to start at 0, 0 and the Rectangle starts at 40, 0 so i guess the behavior is correct. > The following code should give you what you expected to get: > > LinearGradient lg = new LinearGradient(r.getX(), 0, r.getWidth(), 0, false, CycleMethod.NO_CYCLE, stops); > > > Cheers, > > Gerrit > > Am 08.06.2012 um 16:33 schrieb Tom Schindl: > >> Hi, >> >> I'm not sure if i understood proportional true wrong or I'm found a >> serious bug. >> >>> import java.util.ArrayList; >>> import java.util.List; >>> >>> import javafx.application.Application; >>> import javafx.scene.Group; >>> import javafx.scene.Scene; >>> import javafx.scene.paint.Color; >>> import javafx.scene.paint.CycleMethod; >>> import javafx.scene.paint.LinearGradient; >>> import javafx.scene.paint.Stop; >>> import javafx.scene.shape.Rectangle; >>> import javafx.stage.Stage; >>> >>> public class TestGradient extends Application { >>> >>> /** >>> * @param args >>> */ >>> public static void main(String[] args) { >>> launch(args); >>> } >>> >>> @Override >>> public void start(Stage primaryStage) throws Exception { >>> Group g = new Group(); >>> Rectangle r = new Rectangle(40,0,90,75); >>> List stops = new ArrayList(); >>> stops.add(new Stop(0, Color.RED)); >>> stops.add(new Stop(1, Color.BLUE)); >>> LinearGradient lg = new LinearGradient(0, 0, 90, 0, false, CycleMethod.NO_CYCLE, stops); >>> r.setFill(lg); >>> g.getChildren().add(r); >>> Scene s = new Scene(g,200,200); >>> primaryStage.setScene(s); >>> primaryStage.show(); >>> } >>> >>> } >> >> Running this code gives me an UI like shown in the attached screenshot. >> Is this really the right behaviour? I'd expect red to start on the left >> of the rect and end at 1/2 of the width. >> >> Tom >> >> -- >> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >> ------------------------------------------------------------------------ >> tom schindl gesch?ftsf?hrer/CEO >> ------------------------------------------------------------------------ >> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >> http://www.BestSolution.at phone ++43 512 935834 > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From han.solo at muenster.de Fri Jun 8 07:55:10 2012 From: han.solo at muenster.de (Gerrit Grunwald) Date: Fri, 8 Jun 2012 16:55:10 +0200 Subject: Doubts on LinearGradient#proportional=true In-Reply-To: <4FD21131.4050407@bestsolution.at> References: <4FD20D40.3040809@bestsolution.at> <95F7C6E7-2D60-4C4D-B4D8-50408517B9FA@muenster.de> <4FD21131.4050407@bestsolution.at> Message-ID: Ok got it, but it seems the gradient coordinates are related to the complete drawing area instead of the node which makes sense to me. Otherwise you won't be able to create gradients outside of the bounds of a node right ? Am 08.06.2012 um 16:50 schrieb Tom Schindl: >>>> Group g = new Group(); >>>> Rectangle r = new Rectangle(40,0,90,75); >>>> List stops = new ArrayList(); >>>> stops.add(new Stop(0, Color.RED)); >>>> stops.add(new Stop(1, Color.BLUE)); >>>> LinearGradient lg = new LinearGradient(0, 0, 90, 0, false, CycleMethod.NO_CYCLE, stops); >>>> r.setFill(lg); >>>> g.getChildren().add(r); From tom.schindl at bestsolution.at Fri Jun 8 07:56:20 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 08 Jun 2012 16:56:20 +0200 Subject: Doubts on LinearGradient#proportional=true In-Reply-To: References: <4FD20D40.3040809@bestsolution.at> <95F7C6E7-2D60-4C4D-B4D8-50408517B9FA@muenster.de> <4FD21131.4050407@bestsolution.at> Message-ID: <4FD21294.2000608@bestsolution.at> well then would be a negative value not? Tom Am 08.06.12 16:55, schrieb Gerrit Grunwald: > Ok got it, but it seems the gradient coordinates are related to the > complete drawing area instead of the node which makes sense to me. > Otherwise you won't be able to create gradients outside of the bounds of > a node right ? > > Am 08.06.2012 um 16:50 schrieb Tom Schindl: > >>>>> Group g = new Group(); >>>>> Rectangle r = new Rectangle(40,0,90,75); >>>>> List stops = new ArrayList(); >>>>> stops.add(new Stop(0, Color.RED)); >>>>> stops.add(new Stop(1, Color.BLUE)); >>>>> LinearGradient lg = new LinearGradient(0, 0, 90, 0, false, >>>>> CycleMethod.NO_CYCLE, stops); >>>>> r.setFill(lg); >>>>> g.getChildren().add(r); > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From tom.schindl at bestsolution.at Fri Jun 8 07:56:30 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 08 Jun 2012 16:56:30 +0200 Subject: Doubts on LinearGradient#proportional=true In-Reply-To: <4FD210BA.8010406@bestsolution.at> References: <4FD20D40.3040809@bestsolution.at> <4FD20FD9.7020900@oracle.com> <4FD210BA.8010406@bestsolution.at> Message-ID: <4FD2129E.7000702@bestsolution.at> here it is. The rect I get: http://www.efxclipse.org/screen.png The rect I expected: http://www.efxclipse.org/screen_expected.png Tom Am 08.06.12 16:48, schrieb Tom Schindl: > It looks like the image gets stripped. Let me upload it somewhere and > come back to you > > Tom > > Am 08.06.12 16:44, schrieb Pavel Safrata: >> Hi Tom, >> did you forget to attach the image or did the system strip it somewhere >> along the way? I executed your code and saw exactly what you expected - >> gradient in the left half of the rectangle, what do you see? By the way, >> the code uses proportional=false, unlike suggested in the description, >> so please try to clarify your question. >> Thanks, >> Pavel >> >> On 8.6.2012 16:33, Tom Schindl wrote: >>> Hi, >>> >>> I'm not sure if i understood proportional true wrong or I'm found a >>> serious bug. >>> >>>> import java.util.ArrayList; >>>> import java.util.List; >>>> >>>> import javafx.application.Application; >>>> import javafx.scene.Group; >>>> import javafx.scene.Scene; >>>> import javafx.scene.paint.Color; >>>> import javafx.scene.paint.CycleMethod; >>>> import javafx.scene.paint.LinearGradient; >>>> import javafx.scene.paint.Stop; >>>> import javafx.scene.shape.Rectangle; >>>> import javafx.stage.Stage; >>>> >>>> public class TestGradient extends Application { >>>> >>>> /** >>>> * @param args >>>> */ >>>> public static void main(String[] args) { >>>> launch(args); >>>> } >>>> >>>> @Override >>>> public void start(Stage primaryStage) throws Exception { >>>> Group g = new Group(); >>>> Rectangle r = new Rectangle(40,0,90,75); >>>> List stops = new ArrayList(); >>>> stops.add(new Stop(0, Color.RED)); >>>> stops.add(new Stop(1, Color.BLUE)); >>>> LinearGradient lg = new LinearGradient(0, 0, 90, 0, false, >>>> CycleMethod.NO_CYCLE, stops); >>>> r.setFill(lg); >>>> g.getChildren().add(r); >>>> Scene s = new Scene(g,200,200); >>>> primaryStage.setScene(s); >>>> primaryStage.show(); >>>> } >>>> >>>> } >>> Running this code gives me an UI like shown in the attached screenshot. >>> Is this really the right behaviour? I'd expect red to start on the left >>> of the rect and end at 1/2 of the width. >>> >>> Tom >>> > > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From kimtopley at gmail.com Fri Jun 8 08:00:23 2012 From: kimtopley at gmail.com (kimtopley at gmail.com) Date: Fri, 8 Jun 2012 15:00:23 +0000 Subject: Doubts on LinearGradient#proportional=true In-Reply-To: <4FD21294.2000608@bestsolution.at> References: <4FD20D40.3040809@bestsolution.at> <95F7C6E7-2D60-4C4D-B4D8-50408517B9FA@muenster.de> <4FD21131.4050407@bestsolution.at> <4FD21294.2000608@bestsolution.at> Message-ID: <166566711-1339167624-cardhu_decombobulator_blackberry.rim.net-263749516-@b1.c12.bise6.blackberry> The coordinate origin for the rectangle is not at its top left corner -- the (0, 0) point is at the coordinate origin of its parent. If you create the rectangle as new Rectangle(0, 0, 90 75) and the translate it, I think you will get the result you want. Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Tom Schindl Sender: openjfx-dev-bounces at openjdk.java.net Date: Fri, 08 Jun 2012 16:56:20 Cc: openjfx-dev at openjdk.java.net Subject: Re: Doubts on LinearGradient#proportional=true well then would be a negative value not? Tom Am 08.06.12 16:55, schrieb Gerrit Grunwald: > Ok got it, but it seems the gradient coordinates are related to the > complete drawing area instead of the node which makes sense to me. > Otherwise you won't be able to create gradients outside of the bounds of > a node right ? > > Am 08.06.2012 um 16:50 schrieb Tom Schindl: > >>>>> Group g = new Group(); >>>>> Rectangle r = new Rectangle(40,0,90,75); >>>>> List stops = new ArrayList(); >>>>> stops.add(new Stop(0, Color.RED)); >>>>> stops.add(new Stop(1, Color.BLUE)); >>>>> LinearGradient lg = new LinearGradient(0, 0, 90, 0, false, >>>>> CycleMethod.NO_CYCLE, stops); >>>>> r.setFill(lg); >>>>> g.getChildren().add(r); > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From richard.bair at oracle.com Fri Jun 8 08:06:12 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 8 Jun 2012 08:06:12 -0700 Subject: Doubts on LinearGradient#proportional=true In-Reply-To: <4FD2129E.7000702@bestsolution.at> References: <4FD20D40.3040809@bestsolution.at> <4FD20FD9.7020900@oracle.com> <4FD210BA.8010406@bestsolution.at> <4FD2129E.7000702@bestsolution.at> Message-ID: <80F6E6F4-61DA-4E5E-8AA4-77D6E15D2C93@oracle.com> Perhaps you are being tripped up by the coordinate spaces. The rectangle is drawn at 40 in the x of it's coordinate system, and the gradient starts at 0. So the first 40px of gradient are to the left of the left edge of the rectangle. If the rect were at 0 you would see what you expect, I think. If you translate the rect vs move it you would see what you expected as well. On Jun 8, 2012, at 7:56 AM, Tom Schindl wrote: > here it is. > > The rect I get: > http://www.efxclipse.org/screen.png > > The rect I expected: > http://www.efxclipse.org/screen_expected.png > > Tom > > Am 08.06.12 16:48, schrieb Tom Schindl: >> It looks like the image gets stripped. Let me upload it somewhere and >> come back to you >> >> Tom >> >> Am 08.06.12 16:44, schrieb Pavel Safrata: >>> Hi Tom, >>> did you forget to attach the image or did the system strip it somewhere >>> along the way? I executed your code and saw exactly what you expected - >>> gradient in the left half of the rectangle, what do you see? By the way, >>> the code uses proportional=false, unlike suggested in the description, >>> so please try to clarify your question. >>> Thanks, >>> Pavel >>> >>> On 8.6.2012 16:33, Tom Schindl wrote: >>>> Hi, >>>> >>>> I'm not sure if i understood proportional true wrong or I'm found a >>>> serious bug. >>>> >>>>> import java.util.ArrayList; >>>>> import java.util.List; >>>>> >>>>> import javafx.application.Application; >>>>> import javafx.scene.Group; >>>>> import javafx.scene.Scene; >>>>> import javafx.scene.paint.Color; >>>>> import javafx.scene.paint.CycleMethod; >>>>> import javafx.scene.paint.LinearGradient; >>>>> import javafx.scene.paint.Stop; >>>>> import javafx.scene.shape.Rectangle; >>>>> import javafx.stage.Stage; >>>>> >>>>> public class TestGradient extends Application { >>>>> >>>>> /** >>>>> * @param args >>>>> */ >>>>> public static void main(String[] args) { >>>>> launch(args); >>>>> } >>>>> >>>>> @Override >>>>> public void start(Stage primaryStage) throws Exception { >>>>> Group g = new Group(); >>>>> Rectangle r = new Rectangle(40,0,90,75); >>>>> List stops = new ArrayList(); >>>>> stops.add(new Stop(0, Color.RED)); >>>>> stops.add(new Stop(1, Color.BLUE)); >>>>> LinearGradient lg = new LinearGradient(0, 0, 90, 0, false, >>>>> CycleMethod.NO_CYCLE, stops); >>>>> r.setFill(lg); >>>>> g.getChildren().add(r); >>>>> Scene s = new Scene(g,200,200); >>>>> primaryStage.setScene(s); >>>>> primaryStage.show(); >>>>> } >>>>> >>>>> } >>>> Running this code gives me an UI like shown in the attached screenshot. >>>> Is this really the right behaviour? I'd expect red to start on the left >>>> of the rect and end at 1/2 of the width. >>>> >>>> Tom >>>> >> >> > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From tom.schindl at bestsolution.at Fri Jun 8 08:17:52 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 08 Jun 2012 17:17:52 +0200 Subject: Doubts on LinearGradient#proportional=true In-Reply-To: <80F6E6F4-61DA-4E5E-8AA4-77D6E15D2C93@oracle.com> References: <4FD20D40.3040809@bestsolution.at> <4FD20FD9.7020900@oracle.com> <4FD210BA.8010406@bestsolution.at> <4FD2129E.7000702@bestsolution.at> <80F6E6F4-61DA-4E5E-8AA4-77D6E15D2C93@oracle.com> Message-ID: <4FD217A0.5020200@bestsolution.at> But how does it then work if one uses a proportional=false and 0,0,1,0? I'm trying to translate SVG linear gradients to FXML and it fails because of this behavior. I'm having a hard time understanding how I'd map their definition to FXML. For Rects calculating the offset would be easy. Tom Am 08.06.12 17:06, schrieb Richard Bair: > Perhaps you are being tripped up by the coordinate spaces. The rectangle is drawn at 40 in the x of it's coordinate system, and the gradient starts at 0. So the first 40px of gradient are to the left of the left edge of the rectangle. If the rect were at 0 you would see what you expect, I think. If you translate the rect vs move it you would see what you expected as well. > > > > On Jun 8, 2012, at 7:56 AM, Tom Schindl wrote: > >> here it is. >> >> The rect I get: >> http://www.efxclipse.org/screen.png >> >> The rect I expected: >> http://www.efxclipse.org/screen_expected.png >> >> Tom >> >> Am 08.06.12 16:48, schrieb Tom Schindl: >>> It looks like the image gets stripped. Let me upload it somewhere and >>> come back to you >>> >>> Tom >>> >>> Am 08.06.12 16:44, schrieb Pavel Safrata: >>>> Hi Tom, >>>> did you forget to attach the image or did the system strip it somewhere >>>> along the way? I executed your code and saw exactly what you expected - >>>> gradient in the left half of the rectangle, what do you see? By the way, >>>> the code uses proportional=false, unlike suggested in the description, >>>> so please try to clarify your question. >>>> Thanks, >>>> Pavel >>>> >>>> On 8.6.2012 16:33, Tom Schindl wrote: >>>>> Hi, >>>>> >>>>> I'm not sure if i understood proportional true wrong or I'm found a >>>>> serious bug. >>>>> >>>>>> import java.util.ArrayList; >>>>>> import java.util.List; >>>>>> >>>>>> import javafx.application.Application; >>>>>> import javafx.scene.Group; >>>>>> import javafx.scene.Scene; >>>>>> import javafx.scene.paint.Color; >>>>>> import javafx.scene.paint.CycleMethod; >>>>>> import javafx.scene.paint.LinearGradient; >>>>>> import javafx.scene.paint.Stop; >>>>>> import javafx.scene.shape.Rectangle; >>>>>> import javafx.stage.Stage; >>>>>> >>>>>> public class TestGradient extends Application { >>>>>> >>>>>> /** >>>>>> * @param args >>>>>> */ >>>>>> public static void main(String[] args) { >>>>>> launch(args); >>>>>> } >>>>>> >>>>>> @Override >>>>>> public void start(Stage primaryStage) throws Exception { >>>>>> Group g = new Group(); >>>>>> Rectangle r = new Rectangle(40,0,90,75); >>>>>> List stops = new ArrayList(); >>>>>> stops.add(new Stop(0, Color.RED)); >>>>>> stops.add(new Stop(1, Color.BLUE)); >>>>>> LinearGradient lg = new LinearGradient(0, 0, 90, 0, false, >>>>>> CycleMethod.NO_CYCLE, stops); >>>>>> r.setFill(lg); >>>>>> g.getChildren().add(r); >>>>>> Scene s = new Scene(g,200,200); >>>>>> primaryStage.setScene(s); >>>>>> primaryStage.show(); >>>>>> } >>>>>> >>>>>> } >>>>> Running this code gives me an UI like shown in the attached screenshot. >>>>> Is this really the right behaviour? I'd expect red to start on the left >>>>> of the rect and end at 1/2 of the width. >>>>> >>>>> Tom >>>>> >>> >>> >> >> >> -- >> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >> ------------------------------------------------------------------------ >> tom schindl gesch?ftsf?hrer/CEO >> ------------------------------------------------------------------------ >> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >> http://www.BestSolution.at phone ++43 512 935834 -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From hang.vo at oracle.com Fri Jun 8 08:19:00 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Jun 2012 15:19:00 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-19754 - CSS: -fx-padding doesn't work properly on ProgressIndicator Message-ID: <20120608151903.978AB477FD@hg.openjdk.java.net> Changeset: abbc696491cb Author: mickf Date: 2012-06-08 16:04 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/abbc696491cb RT-19754 - CSS: -fx-padding doesn't work properly on ProgressIndicator ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java From tom.schindl at bestsolution.at Fri Jun 8 08:40:05 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 08 Jun 2012 17:40:05 +0200 Subject: Doubts on LinearGradient#proportional=true In-Reply-To: <4FD217A0.5020200@bestsolution.at> References: <4FD20D40.3040809@bestsolution.at> <4FD20FD9.7020900@oracle.com> <4FD210BA.8010406@bestsolution.at> <4FD2129E.7000702@bestsolution.at> <80F6E6F4-61DA-4E5E-8AA4-77D6E15D2C93@oracle.com> <4FD217A0.5020200@bestsolution.at> Message-ID: <4FD21CD5.2090301@bestsolution.at> Have to correct myself :-( I think I'm the one responsible for the wrong behavior. Looks like I'm not handling gradientTransform appropriately :-( Am 08.06.12 17:17, schrieb Tom Schindl: > But how does it then work if one uses a proportional=false and 0,0,1,0? > > I'm trying to translate SVG linear gradients to FXML and it fails > because of this behavior. I'm having a hard time understanding how I'd > map their definition to FXML. For Rects calculating the offset would be > easy. > > Tom > > Am 08.06.12 17:06, schrieb Richard Bair: >> Perhaps you are being tripped up by the coordinate spaces. The rectangle is drawn at 40 in the x of it's coordinate system, and the gradient starts at 0. So the first 40px of gradient are to the left of the left edge of the rectangle. If the rect were at 0 you would see what you expect, I think. If you translate the rect vs move it you would see what you expected as well. >> >> >> >> On Jun 8, 2012, at 7:56 AM, Tom Schindl wrote: >> >>> here it is. >>> >>> The rect I get: >>> http://www.efxclipse.org/screen.png >>> >>> The rect I expected: >>> http://www.efxclipse.org/screen_expected.png >>> >>> Tom >>> >>> Am 08.06.12 16:48, schrieb Tom Schindl: >>>> It looks like the image gets stripped. Let me upload it somewhere and >>>> come back to you >>>> >>>> Tom >>>> >>>> Am 08.06.12 16:44, schrieb Pavel Safrata: >>>>> Hi Tom, >>>>> did you forget to attach the image or did the system strip it somewhere >>>>> along the way? I executed your code and saw exactly what you expected - >>>>> gradient in the left half of the rectangle, what do you see? By the way, >>>>> the code uses proportional=false, unlike suggested in the description, >>>>> so please try to clarify your question. >>>>> Thanks, >>>>> Pavel >>>>> >>>>> On 8.6.2012 16:33, Tom Schindl wrote: >>>>>> Hi, >>>>>> >>>>>> I'm not sure if i understood proportional true wrong or I'm found a >>>>>> serious bug. >>>>>> >>>>>>> import java.util.ArrayList; >>>>>>> import java.util.List; >>>>>>> >>>>>>> import javafx.application.Application; >>>>>>> import javafx.scene.Group; >>>>>>> import javafx.scene.Scene; >>>>>>> import javafx.scene.paint.Color; >>>>>>> import javafx.scene.paint.CycleMethod; >>>>>>> import javafx.scene.paint.LinearGradient; >>>>>>> import javafx.scene.paint.Stop; >>>>>>> import javafx.scene.shape.Rectangle; >>>>>>> import javafx.stage.Stage; >>>>>>> >>>>>>> public class TestGradient extends Application { >>>>>>> >>>>>>> /** >>>>>>> * @param args >>>>>>> */ >>>>>>> public static void main(String[] args) { >>>>>>> launch(args); >>>>>>> } >>>>>>> >>>>>>> @Override >>>>>>> public void start(Stage primaryStage) throws Exception { >>>>>>> Group g = new Group(); >>>>>>> Rectangle r = new Rectangle(40,0,90,75); >>>>>>> List stops = new ArrayList(); >>>>>>> stops.add(new Stop(0, Color.RED)); >>>>>>> stops.add(new Stop(1, Color.BLUE)); >>>>>>> LinearGradient lg = new LinearGradient(0, 0, 90, 0, false, >>>>>>> CycleMethod.NO_CYCLE, stops); >>>>>>> r.setFill(lg); >>>>>>> g.getChildren().add(r); >>>>>>> Scene s = new Scene(g,200,200); >>>>>>> primaryStage.setScene(s); >>>>>>> primaryStage.show(); >>>>>>> } >>>>>>> >>>>>>> } >>>>>> Running this code gives me an UI like shown in the attached screenshot. >>>>>> Is this really the right behaviour? I'd expect red to start on the left >>>>>> of the rect and end at 1/2 of the width. >>>>>> >>>>>> Tom >>>>>> >>>> >>>> >>> >>> >>> -- >>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>> ------------------------------------------------------------------------ >>> tom schindl gesch?ftsf?hrer/CEO >>> ------------------------------------------------------------------------ >>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>> http://www.BestSolution.at phone ++43 512 935834 > > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From hang.vo at oracle.com Fri Jun 8 10:19:22 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Jun 2012 17:19:22 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-19738 : Invalid layout behavior with rotates applied Message-ID: <20120608171924.8D7DE47806@hg.openjdk.java.net> Changeset: c7813fd4d4a0 Author: mickf Date: 2012-06-08 18:15 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/c7813fd4d4a0 RT-19738 : Invalid layout behavior with rotates applied ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java From tom.schindl at bestsolution.at Fri Jun 8 10:35:23 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 08 Jun 2012 19:35:23 +0200 Subject: Doubts on LinearGradient#proportional=true In-Reply-To: <4FD21CD5.2090301@bestsolution.at> References: <4FD20D40.3040809@bestsolution.at> <4FD20FD9.7020900@oracle.com> <4FD210BA.8010406@bestsolution.at> <4FD2129E.7000702@bestsolution.at> <80F6E6F4-61DA-4E5E-8AA4-77D6E15D2C93@oracle.com> <4FD217A0.5020200@bestsolution.at> <4FD21CD5.2090301@bestsolution.at> Message-ID: <4FD237DB.8060505@bestsolution.at> If anyone on here has an idea how to apply the gradienttransform from SVG [1] to JavaFX. I'd be very grateful. The current code I have does the following but is not correct: List parts = ... /*matrix(....)*/ AffineTransform t = new AffineTransform( Double.parseDouble(parts.get(0)), Double.parseDouble(parts.get(1)), Double.parseDouble(parts.get(2)), Double.parseDouble(parts.get(3)), Double.parseDouble(parts.get(4)), Double.parseDouble(parts.get(5))); double startX = t.transform( new Point2D.Double(x1,y1), null).x; double startY = t.transform( new Point2D.Double(x1,y1), null).y; double endX = t.transform( new Point2D.Double(x2,y2), null).x; double endY = t.transform( new Point2D.Double(x2,y2), null).y; You can find an example svg and my current restult at [2]. Tom [1]http://www.w3.org/TR/SVG/pservers.html#LinearGradientElementGradientTransformAttribute [2]http://www.efxclipse.org/svg/ Am 08.06.12 17:40, schrieb Tom Schindl: > Have to correct myself :-( I think I'm the one responsible for the wrong > behavior. Looks like I'm not handling gradientTransform appropriately :-( > > Am 08.06.12 17:17, schrieb Tom Schindl: >> But how does it then work if one uses a proportional=false and 0,0,1,0? >> >> I'm trying to translate SVG linear gradients to FXML and it fails >> because of this behavior. I'm having a hard time understanding how I'd >> map their definition to FXML. For Rects calculating the offset would be >> easy. >> >> Tom >> >> Am 08.06.12 17:06, schrieb Richard Bair: >>> Perhaps you are being tripped up by the coordinate spaces. The rectangle is drawn at 40 in the x of it's coordinate system, and the gradient starts at 0. So the first 40px of gradient are to the left of the left edge of the rectangle. If the rect were at 0 you would see what you expect, I think. If you translate the rect vs move it you would see what you expected as well. >>> >>> >>> >>> On Jun 8, 2012, at 7:56 AM, Tom Schindl wrote: >>> >>>> here it is. >>>> >>>> The rect I get: >>>> http://www.efxclipse.org/screen.png >>>> >>>> The rect I expected: >>>> http://www.efxclipse.org/screen_expected.png >>>> >>>> Tom >>>> >>>> Am 08.06.12 16:48, schrieb Tom Schindl: >>>>> It looks like the image gets stripped. Let me upload it somewhere and >>>>> come back to you >>>>> >>>>> Tom >>>>> >>>>> Am 08.06.12 16:44, schrieb Pavel Safrata: >>>>>> Hi Tom, >>>>>> did you forget to attach the image or did the system strip it somewhere >>>>>> along the way? I executed your code and saw exactly what you expected - >>>>>> gradient in the left half of the rectangle, what do you see? By the way, >>>>>> the code uses proportional=false, unlike suggested in the description, >>>>>> so please try to clarify your question. >>>>>> Thanks, >>>>>> Pavel >>>>>> >>>>>> On 8.6.2012 16:33, Tom Schindl wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'm not sure if i understood proportional true wrong or I'm found a >>>>>>> serious bug. >>>>>>> >>>>>>>> import java.util.ArrayList; >>>>>>>> import java.util.List; >>>>>>>> >>>>>>>> import javafx.application.Application; >>>>>>>> import javafx.scene.Group; >>>>>>>> import javafx.scene.Scene; >>>>>>>> import javafx.scene.paint.Color; >>>>>>>> import javafx.scene.paint.CycleMethod; >>>>>>>> import javafx.scene.paint.LinearGradient; >>>>>>>> import javafx.scene.paint.Stop; >>>>>>>> import javafx.scene.shape.Rectangle; >>>>>>>> import javafx.stage.Stage; >>>>>>>> >>>>>>>> public class TestGradient extends Application { >>>>>>>> >>>>>>>> /** >>>>>>>> * @param args >>>>>>>> */ >>>>>>>> public static void main(String[] args) { >>>>>>>> launch(args); >>>>>>>> } >>>>>>>> >>>>>>>> @Override >>>>>>>> public void start(Stage primaryStage) throws Exception { >>>>>>>> Group g = new Group(); >>>>>>>> Rectangle r = new Rectangle(40,0,90,75); >>>>>>>> List stops = new ArrayList(); >>>>>>>> stops.add(new Stop(0, Color.RED)); >>>>>>>> stops.add(new Stop(1, Color.BLUE)); >>>>>>>> LinearGradient lg = new LinearGradient(0, 0, 90, 0, false, >>>>>>>> CycleMethod.NO_CYCLE, stops); >>>>>>>> r.setFill(lg); >>>>>>>> g.getChildren().add(r); >>>>>>>> Scene s = new Scene(g,200,200); >>>>>>>> primaryStage.setScene(s); >>>>>>>> primaryStage.show(); >>>>>>>> } >>>>>>>> >>>>>>>> } >>>>>>> Running this code gives me an UI like shown in the attached screenshot. >>>>>>> Is this really the right behaviour? I'd expect red to start on the left >>>>>>> of the rect and end at 1/2 of the width. >>>>>>> >>>>>>> Tom >>>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>>> ------------------------------------------------------------------------ >>>> tom schindl gesch?ftsf?hrer/CEO >>>> ------------------------------------------------------------------------ >>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>>> http://www.BestSolution.at phone ++43 512 935834 >> >> > > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From hang.vo at oracle.com Fri Jun 8 11:33:51 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Jun 2012 18:33:51 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-20285 memory leak in javafx.scene.controls.MenuBar Message-ID: <20120608183353.940C64780A@hg.openjdk.java.net> Changeset: e1200e6556ab Author: Paru Somashekar Date: 2012-06-08 11:23 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/e1200e6556ab RT-20285 memory leak in javafx.scene.controls.MenuBar ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java From hang.vo at oracle.com Fri Jun 8 12:34:09 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Jun 2012 19:34:09 +0000 Subject: hg: openjfx/2.2/graphics/rt: [DOC-ONLY] fixing tag in the javadoc for Font#loadFont() Message-ID: <20120608193411.4974B4780E@hg.openjdk.java.net> Changeset: 796a3a759c37 Author: Felipe Heidrich Date: 2012-06-08 12:23 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/796a3a759c37 [DOC-ONLY] fixing tag in the javadoc for Font#loadFont() ! javafx-ui-common/src/javafx/scene/text/Font.java From hang.vo at oracle.com Fri Jun 8 12:48:56 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Jun 2012 19:48:56 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-21891 ChoiceBox popup looks strange after refilling. Message-ID: <20120608194858.43B7E4780F@hg.openjdk.java.net> Changeset: 527e107cfec5 Author: Paru Somashekar Date: 2012-06-08 12:52 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/527e107cfec5 RT-21891 ChoiceBox popup looks strange after refilling. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ChoiceBoxSkin.java From hang.vo at oracle.com Fri Jun 8 16:34:11 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Jun 2012 23:34:11 +0000 Subject: hg: openjfx/2.2/graphics/rt: 2 new changesets Message-ID: <20120608233414.81A1E47811@hg.openjdk.java.net> Changeset: 7be3c836bb43 Author: hudson Date: 2012-06-06 16:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/7be3c836bb43 Added tag 2.2-b12 for changeset 348de34f8273 ! .hgtags Changeset: 261c8cd885ec Author: kcr Date: 2012-06-08 16:25 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/261c8cd885ec Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt - javafx-ui-common/test/unit/javafx/scene/input/TouchPoint_builder_Test.java From jmartine_1026 at yahoo.com Sat Jun 9 06:07:20 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Sat, 9 Jun 2012 06:07:20 -0700 (PDT) Subject: temporary performance issues when prism.dirtyopts set to false References: <1339041393.88493.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FD0284C.5090900@oracle.com> <1339042915.11923.YahooMailNeo@web160902.mail.bf1.yahoo.com> <4FD0430C.2030503@oracle.com> <1339049447.68617.YahooMailNeo@web160901.mail.bf1.yahoo.com> <4FD099AE.3030808@oracle.com> Message-ID: <1339247240.50298.YahooMailNeo@web160902.mail.bf1.yahoo.com> Ok the issue with the ghost images of the projectiles (RT-22126) has been isolated. ?When I was creating my many PathTransitions I used a function called getPath that takes as input a list of Point2D. ?The problem was that I was adding the first point in that list twice into the Path, once as a MoveTo and again as a LineTo. ?I suspect this screwed up the ORTHOGONAL_TO_TANGENT, since obtaining the angle from point 1 to point 2 might have resulted in a value of NaN. I will post this to the ticket. ?Unfortunately I failed to reproduce in test code. ?In test code I entered the same Point2D multiple times into the beginning of my Path (one MoveTo and multiple LineTo's) but the problem did not happen. ?Either way it is fixed in my production code (one line fix). While a fix for this that messes up performance is unadvised maybe a check for duplicate subsequent PathElement property values when the PathElements are being entered into the Path might be worth considering.... does not matter to me since now I know to be more cognizant of this :-) thanks? jose ________________________________ From: Kevin Rushforth To: Jose Martinez Cc: Pavel Safrata ; "openjfx-dev at openjdk.java.net" Sent: Thursday, June 7, 2012 8:08 AM Subject: Re: temporary performance issues when prism.dirtyopts set to false Yes, sorry for not making that clear when I asked you to set it to help narrow down the problem. We do not intend that prism.dirtyopts, or any other debugging flag be used in production by an application. -- Kevin Jose Martinez wrote: > Ok I follow, that's a good point.? Will fill two out for the problems I am seeing when ditryopts is set to true.... didn't realize ditryopts set to false is only for testing. > > Thank you! > jose > > > ________________________________ >? From: Pavel Safrata > To: openjfx-dev at openjdk.java.net Sent: Thursday, June 7, 2012 1:58 AM > Subject: Re: temporary performance issues when prism.dirtyopts set to false >? Hi Jose, > Jonathan is absolutely right. Disabling dirty opts is a good tool for narrowing the problem, but you should never want to do it for public use. The performance is significantly worse and will always be. The application must render the same screens with and without dirty opts and if it doesn't, there is a bug in FX that needs to be fixed immediately. Could you please file one? > Thanks, > Pavel > > On 7.6.2012 6:21, Jose Martinez wrote: >? >> Thanks for the response.? Please note that the poor performance is only temporary, during the first minute of game play.? So I suspect there is hope to obtain good performance for the whole time. >>? jose >> >> >> ________________________________ >>? ? From: Jonathan Giles >> To: Jose Martinez >> Cc: openjfx mailing list >> Sent: Thursday, June 7, 2012 12:04 AM >> Subject: Re: temporary performance issues when prism.dirtyopts set to false >> >> I am not in the graphics team, but given the present state of timezones I thought I'd reply to try to give some clarity. Hopefully someone will follow this up at a more suitable hour with a correct answer :-) >> >> Dirty opts in JavaFX is synonymous with the concept known as dirty rectangles, I believe. You can learn more about dirty rectangles at [1]. Basically it is an optimisation designed to limit the amount of drawing on the screen to only the areas that have changed since the last update. If dirty opts are disabled, as you are doing, you are basically telling JavaFX to redraw the whole screen on every pulse. This is clearly a far more expensive operation than just drawing the 'dirty' areas. >> >> So, in short, yes, this is a known issue with disabling dirty opts. Except it really isn't an issue - it is just the nature of things. The reason why Kevin asked for you to disable dirty opts was to try to trouble shoot the other issues you raised. You shouldn't go without dirty opts if at all possible. >> >> [1] http://c2.com/cgi/wiki?DirtyRectangles >> >> -- Jonathan >> >> >> On 7/06/2012 3:56 p.m., Jose Martinez wrote: >>? ? >>> Hello, >>> >>> I notice performance issues when prism.dirtyopts is set to false.? But it only happens during the first minute or so of game play.? The animation is not smooth, it looks as if it has a low frame rate.? But after a minute the animations becomes smooth for the rest of the program execution.? The poor animation performance returns if I restart the application. >>> >>> Is this a known issue? >>>? ? ? thanks >>> jose >>>? ? ? From tom.schindl at bestsolution.at Sat Jun 9 10:28:07 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sat, 09 Jun 2012 19:28:07 +0200 Subject: FXML and Classloading In-Reply-To: <9B51790B-3C01-42DD-9EB5-CB674C287DB1@oracle.com> References: <4FC77028.4000906@bestsolution.at> <46000A52-5DCD-4D7B-86CC-94ECF64F979D@oracle.com> <4FC77912.3050104@bestsolution.at> <1F1F2E73-47A4-4BDA-A2B7-6621B4E1F7E6@oracle.com> <4FC78763.6070602@bestsolution.at> <4FC79049.9080205@bestsolution.at> <9B51790B-3C01-42DD-9EB5-CB674C287DB1@oracle.com> Message-ID: <4FD387A7.1060606@bestsolution.at> So where do we go from here? We do agree that there's something to be done? So I should file a JIRA-Ticket? Tom Am 31.05.12 18:11, schrieb Greg Brown: >> The problem is that if I'm using composition I don't get the correct >> classloader > > Sure you do. You just need to propagate it to your nested builder factory. > >> I think you should not set a default classloader at all but let the >> type-classloader be the default - it is the classloader used by the >> FXMLLoader while constructing the Object graph. > > OK. I *think* the only real issue here is whether or not we truly need to pass a class loader to JavaFXBuilderFactory. The only place where we actually need the class loader in JavaFXBuilderFactory is when we are trying to load the generated builder class for a given type. If we assume that the builder class will be loaded by the same class loader that was used to load the original type, then you are right - we don't need to explicitly pass a class loader to the JavaFXBuilderFactory constructor. However, I'm not sure that is a safe assumption. But I also don't think it is a major inconvenience to have to do so - if you need to use a custom class loader in your app, you just need to make sure you pass it to your JavaFXBuilderFactory instance. > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From greg.x.brown at oracle.com Sun Jun 10 04:47:19 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Sun, 10 Jun 2012 07:47:19 -0400 Subject: FXML and Classloading In-Reply-To: <4FD387A7.1060606@bestsolution.at> References: <4FC77028.4000906@bestsolution.at> <46000A52-5DCD-4D7B-86CC-94ECF64F979D@oracle.com> <4FC77912.3050104@bestsolution.at> <1F1F2E73-47A4-4BDA-A2B7-6621B4E1F7E6@oracle.com> <4FC78763.6070602@bestsolution.at> <4FC79049.9080205@bestsolution.at> <9B51790B-3C01-42DD-9EB5-CB674C287DB1@oracle.com> <4FD387A7.1060606@bestsolution.at> Message-ID: Hi Tom, As I mentioned, while I understand the motivation, I'm still not convinced that it is necessary. But yes, please go ahead and file a JIRA ticket. Thanks. Greg On Jun 9, 2012, at 1:28 PM, Tom Schindl wrote: > So where do we go from here? We do agree that there's something to be > done? So I should file a JIRA-Ticket? > > Tom > > Am 31.05.12 18:11, schrieb Greg Brown: >>> The problem is that if I'm using composition I don't get the correct >>> classloader >> >> Sure you do. You just need to propagate it to your nested builder factory. >> >>> I think you should not set a default classloader at all but let the >>> type-classloader be the default - it is the classloader used by the >>> FXMLLoader while constructing the Object graph. >> >> OK. I *think* the only real issue here is whether or not we truly need to pass a class loader to JavaFXBuilderFactory. The only place where we actually need the class loader in JavaFXBuilderFactory is when we are trying to load the generated builder class for a given type. If we assume that the builder class will be loaded by the same class loader that was used to load the original type, then you are right - we don't need to explicitly pass a class loader to the JavaFXBuilderFactory constructor. However, I'm not sure that is a safe assumption. But I also don't think it is a major inconvenience to have to do so - if you need to use a custom class loader in your app, you just need to make sure you pass it to your JavaFXBuilderFactory instance. >> > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From goddard at seznam.cz Sun Jun 10 13:45:45 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Sun, 10 Jun 2012 22:45:45 +0200 (CEST) Subject: =?us-ascii?Q?JIRA=20down=3F?= Message-ID: <129145.7942.26881-16395-573353230-1339361145@seznam.cz> Hi, is JIRA down? JIRA Startup Failed You cannot access JIRA at present. Look at the table below to identify the reasons Description The jira.home directory '/issues/jira-42' is already locked. Please see the JIRA documentation for more information on locked jira.home directories. This is what I was welcomed with when I wanted to check something. Regards, Jiri From goddard at seznam.cz Sun Jun 10 13:53:36 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Sun, 10 Jun 2012 22:53:36 +0200 (CEST) Subject: =?us-ascii?Q?Property=20updates?= Message-ID: <129148.7942.26881-16840-356981267-1339361616@seznam.cz> Hello, the following code should create a Circle at random coords and animate the translation to random coords. The point is to randomly translate the circle from one location to another successively: package boyle; import javafx.animation.KeyFrame; import javafx.animation.KeyValue; import javafx.animation.Timeline; import javafx.animation.TimelineBuilder; import javafx.application.Application; import javafx.beans.property.DoubleProperty; import javafx.beans.property.SimpleDoubleProperty; import javafx.event.ActionEvent; import javafx.event.EventHandler; import javafx.scene.Group; import javafx.scene.Scene; import javafx.scene.paint.Color; import javafx.scene.shape.Circle; import javafx.scene.shape.CircleBuilder; import javafx.stage.Stage; import javafx.util.Duration; /** * * @author jiri */ public class Boyle extends Application { public static final int WIDTH = 800; public static final int HEIGHT = 512; /** * @param args the command line arguments */ public static void main(String[] args) { launch(args); } // end the animation at random coords private DoubleProperty x = new SimpleDoubleProperty(Math.random() * WIDTH); private DoubleProperty y = new SimpleDoubleProperty(Math.random() * HEIGHT); @Override public void start(Stage primaryStage) { final Circle c = CircleBuilder.create() // start the animation at random coords .centerX(Math.random() * WIDTH) .centerY(Math.random() * HEIGHT) .radius(15).fill(Color.BLACK) .build(); final DoubleProperty[] randCoords = {x, y}; final Timeline t = TimelineBuilder.create() .keyFrames(new KeyFrame(Duration.seconds(5), new KeyValue(c.centerXProperty(), randCoords[0].get()), new KeyValue(c.centerYProperty(), randCoords[1].get()))) .build(); // refreshes coords at every end of the animation t.setOnFinished(new EventHandler() { @Override public void handle(ActionEvent ae) { System.out.println("centerX"+ c.centerXProperty()); // set animation end coords to the target c.centerXProperty().set(randCoords[0].get()); c.centerYProperty().set(randCoords[1].get()); System.out.println("x: "+ randCoords[0]); // generate new coords for the animation end randCoords[0].set(Math.random() * WIDTH); randCoords[1].set(Math.random() * HEIGHT); t.play(); } }); t.play(); Group root = new Group(); root.getChildren().add(c); Scene scene = new Scene(root, WIDTH, HEIGHT); primaryStage.setTitle("@javafxcz - Boyle - www.dredwerkz.cz"); primaryStage.setScene(scene); primaryStage.show(); } } However, the circle appears moving to its target coords instead to its end coords, and update of the target coords doesn't work - unlike for the end coords. Plus, there's a significant 1-2 seconds long pause before the animation starts again in the handler, but just for the first time. Then it runs smoothly. Help in form of explanation / code sample is appreciated. Regards, Jiri From jonathan.giles at oracle.com Sun Jun 10 16:52:10 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 11 Jun 2012 11:52:10 +1200 Subject: JavaFX Form Validation Message-ID: <4FD5332A.5080608@oracle.com> Hi all, I'm currently in the very, very early stages of developing a validation API for future inclusion into JavaFX. I thought rather than get too far into the research and development of a proof of concept, I would see what you all think. Any feedback now would be very useful. Essentially, there are a few common styles related to form validation. Some of the more likely approaches include: * The 'JGoodies Validation framework' [1] approach, where the developer provides a Validator that will then run over the form and gather feedback to return to the user (for example, it would test that the 'name field' is not empty, and that the email address is of the correct style - if either of these rules are invalid, the Validator would return ValidationMessage instances inside a ValidationResult). If validation fails the user is shown the text out of the ValidationMessage feedback, otherwise the form would submit as per usual. This validation may happen at a number of times (during form submission, when focus is lost, as a key is typed, etc). The nice thing about this approach is that the Validator can be a part of the domain model, the presentation model, or a separate thing altogether. * The JSR-303 approach which uses annotations to indicate the rules applicable to each field. These annotations are on the domain model, and therefore assumes that the form is directly tied to a domain object (which may not always be correct). I think the JSR-303 API is too complex for what is needed in JavaFX, but a similar implementation could be developed with a simpler API that follows this approach. * For lack of a better reference point, the FXForm approach [3] which encapsulates the validation inside a Form object that can be placed in the scene. I know this isn't explicitly (in the case of FXForm) about validation, but I think it is another approach to consider. So, what does JavaFX need out of a validation framework? It's really five things (I think): 1. A way for developers to validate a form by providing some means of specifying rules, as well as a way to specify when it runs, how it is visually represented, etc. 2. A way for the validation to impact upon the visual state of the form (using consistent CSS pseudoclass states / style classes, as well as by showing custom overlays, error messages beside the component (or grouped together at the top of the form)). There must be API to specify all of this. 3. Convenient API to simplify the validation process [3] (e.g. isEmpty(String), isAlphanumeric(String), etc, etc, etc). 4. An API that does not require it be integrated with UI controls. Doing so would prevent 3rd party UI controls to be able to be validated without also implementing the API, which may prove burdensome. Instead, the validation API should be separate. 5. A means to integrate nicely with the bindings and properties API present in JavaFX today. Of the three approaches above, my personal preference is to follow the JGoodies approach as I think it is the most powerful and flexible. However, nothing is set in stone and I want to learn what others think. Note that at present this research does not extend to considering whether there should be API related to automatically generating a form from a (JavaFX) bean (and making use of the validation API to ensure the input is correct). However, I am not against discussing this topic as well, as long as it too integrates nicely with the rules above, as well as the validation API itself, obviously. This research may full into requirement three above. [1] http://www.jgoodies.com/freeware/libraries/validation/ [2] https://github.com/dooApp/FXForm2 [3] http://www.jarvana.com/jarvana/view/com/jgoodies/validation/2.0.1/validation-2.0.1-javadoc.jar!/com/jgoodies/validation/util/ValidationUtils.html Thanks, -- Jonathan From tbee at tbee.org Mon Jun 11 00:13:13 2012 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 11 Jun 2012 09:13:13 +0200 Subject: JavaFX Form Validation In-Reply-To: <4FD5332A.5080608@oracle.com> References: <4FD5332A.5080608@oracle.com> Message-ID: <4FD59A89.80703@tbee.org> Hi all, Ah, a topic that is close to my heart. Personally I'm big on reuse, so initially approach 1 seems to come closest. However I'm even a bigger fan of clear separation, and having a form validation in a domain model is debatable. Here is my brain dump; Normally, one would split out the validation activity around a form in multiple parts; 1. simple validation; usually these kinds of validation are implemented directly on the setter, like "age >= 0" and can be displayed immediately after the field is exited / committed. Normally one would use a IllegalArgumentException in the setter to enforce it, contrarily to annotations on the setter, an IAE is enforced always and requires no reflection on the UI side. However the current bindings do not allow proper handling of this (see my blog post of a year back). 2. grouped validation; these are validations between fields, things like "before < after". You could do this in the setters, but that usually creates entry issues. So this needs to be in some kind of post setter validation call on the entity, probably on submit of the form. 3. general on submit form level validations, the mandatory fields fall into this category. You could try to merge this with grouped validation. 3. But not all forms are directly bound to entities, for example a wizard collects all kinds of information and usually only in the end are entities involved. These forms usually are backed by a backing class, which basically has the same validations features as entities, only do not reside in the domain model. 4. 99% of all the validations would fall in the contexts above, but there is always that form specific thing. So a form internal validation is required as well. 5. Lastly grouping and enabling. You can use forms in different contexts, e.g. editing an entity or a template (which is then used to easy create new entities). Such a template probably has a lot of constraints disabled. So it would be good to be able to partially disabled groups of constraints for a form. Summary: - per field direct validation - on submit validations - both in directly in the entity or on backing classes (or a combination) - form internal validation - grouping and enabling Personally I would go for an approach where a validator can be registered to any control or container. There could be an easy reflection based implementation which is parallel to the binding; so if you bind the control to an property on an entity, a validation also is set that looks at the annotations of that property, maybe even automatically. A form can be bound to an form validator. But it is always possible to create ones own validator and override the behavior. Since we need something of a "form" class anyhow, the context of the validation (what is enabled and what not) should be set there. A validator can be be assigned one or more group ids, and call for validation gets the form as a parameter, implicitely giving it access to the validation context, so it can check if it is enabled or not. Makes the above any sense? Your 5 summary points are perfect. How to visualize, external to the controls, join up with binding. Yup. Tom On 2012-06-11 01:52, Jonathan Giles wrote: > Hi all, > > I'm currently in the very, very early stages of developing a validation API for future inclusion into JavaFX. I thought rather than get too far into the research and development of a proof of concept, I would see what you all think. Any feedback now would be very useful. > > Essentially, there are a few common styles related to form validation. Some of the more likely approaches include: > > * The 'JGoodies Validation framework' [1] approach, where the > developer provides a Validator that will then run over the form and > gather feedback to return to the user (for example, it would test > that the 'name field' is not empty, and that the email address is of > the correct style - if either of these rules are invalid, the > Validator would return ValidationMessage instances inside a > ValidationResult). If validation fails the user is shown the text > out of the ValidationMessage feedback, otherwise the form would > submit as per usual. This validation may happen at a number of times > (during form submission, when focus is lost, as a key is typed, > etc). The nice thing about this approach is that the Validator can > be a part of the domain model, the presentation model, or a separate > thing altogether. > * The JSR-303 approach which uses annotations to indicate the rules > applicable to each field. These annotations are on the domain model, > and therefore assumes that the form is directly tied to a domain > object (which may not always be correct). I think the JSR-303 API is > too complex for what is needed in JavaFX, but a similar > implementation could be developed with a simpler API that follows > this approach. > * For lack of a better reference point, the FXForm approach [3] which > encapsulates the validation inside a Form object that can be placed > in the scene. I know this isn't explicitly (in the case of FXForm) > about validation, but I think it is another approach to consider. > > So, what does JavaFX need out of a validation framework? It's really five things (I think): > > 1. A way for developers to validate a form by providing some means of > specifying rules, as well as a way to specify when it runs, how it > is visually represented, etc. > 2. A way for the validation to impact upon the visual state of the form > (using consistent CSS pseudoclass states / style classes, as well as > by showing custom overlays, error messages beside the component (or > grouped together at the top of the form)). There must be API to > specify all of this. > 3. Convenient API to simplify the validation process [3] (e.g. > isEmpty(String), isAlphanumeric(String), etc, etc, etc). > 4. An API that does not require it be integrated with UI controls. > Doing so would prevent 3rd party UI controls to be able to be > validated without also implementing the API, which may prove > burdensome. Instead, the validation API should be separate. > 5. A means to integrate nicely with the bindings and properties API > present in JavaFX today. > > Of the three approaches above, my personal preference is to follow the JGoodies approach as I think it is the most powerful and flexible. However, nothing is set in stone and I want to learn what others think. > > Note that at present this research does not extend to considering whether there should be API related to automatically generating a form from a (JavaFX) bean (and making use of the validation API to ensure the input is correct). However, I am not against discussing this topic as well, as long as it too integrates nicely with the rules above, as well as the validation API itself, obviously. This research may full into requirement three above. > > [1] http://www.jgoodies.com/freeware/libraries/validation/ > [2] https://github.com/dooApp/FXForm2 > [3] http://www.jarvana.com/jarvana/view/com/jgoodies/validation/2.0.1/validation-2.0.1-javadoc.jar!/com/jgoodies/validation/util/ValidationUtils.html > > Thanks, > -- Jonathan > From tom.schindl at bestsolution.at Mon Jun 11 00:21:51 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 11 Jun 2012 09:21:51 +0200 Subject: JavaFX Form Validation In-Reply-To: <4FD59A89.80703@tbee.org> References: <4FD5332A.5080608@oracle.com> <4FD59A89.80703@tbee.org> Message-ID: <4FD59C8F.6090903@bestsolution.at> Hi, I don't think it is the task of JavaFX to provide a validation system. All it needs to provide is an API on the controls to show validation results. Tom Am 11.06.12 09:13, schrieb Tom Eugelink: > Hi all, > > Ah, a topic that is close to my heart. Personally I'm big on reuse, so > initially approach 1 seems to come closest. However I'm even a bigger > fan of clear separation, and having a form validation in a domain model > is debatable. Here is my brain dump; > > Normally, one would split out the validation activity around a form in > multiple parts; > 1. simple validation; usually these kinds of validation are implemented > directly on the setter, like "age >= 0" and can be displayed immediately > after the field is exited / committed. Normally one would use a > IllegalArgumentException in the setter to enforce it, contrarily to > annotations on the setter, an IAE is enforced always and requires no > reflection on the UI side. However the current bindings do not allow > proper handling of this (see my blog post of a year back). > > 2. grouped validation; these are validations between fields, things like > "before < after". You could do this in the setters, but that usually > creates entry issues. So this needs to be in some kind of post setter > validation call on the entity, probably on submit of the form. > > 3. general on submit form level validations, the mandatory fields fall > into this category. You could try to merge this with grouped validation. > > 3. But not all forms are directly bound to entities, for example a > wizard collects all kinds of information and usually only in the end are > entities involved. These forms usually are backed by a backing class, > which basically has the same validations features as entities, only do > not reside in the domain model. > > 4. 99% of all the validations would fall in the contexts above, but > there is always that form specific thing. So a form internal validation > is required as well. > > 5. Lastly grouping and enabling. You can use forms in different > contexts, e.g. editing an entity or a template (which is then used to > easy create new entities). Such a template probably has a lot of > constraints disabled. So it would be good to be able to partially > disabled groups of constraints for a form. > > Summary: > - per field direct validation > - on submit validations > - both in directly in the entity or on backing classes (or a combination) > - form internal validation > - grouping and enabling > > Personally I would go for an approach where a validator can be > registered to any control or container. There could be an easy > reflection based implementation which is parallel to the binding; so if > you bind the control to an property on an entity, a validation also is > set that looks at the annotations of that property, maybe even > automatically. A form can be bound to an form validator. But it is > always possible to create ones own validator and override the behavior. > Since we need something of a "form" class anyhow, the context of the > validation (what is enabled and what not) should be set there. A > validator can be be assigned one or more group ids, and call for > validation gets the form as a parameter, implicitely giving it access to > the validation context, so it can check if it is enabled or not. > > Makes the above any sense? > > Your 5 summary points are perfect. How to visualize, external to the > controls, join up with binding. Yup. > > Tom > > > On 2012-06-11 01:52, Jonathan Giles wrote: >> Hi all, >> >> I'm currently in the very, very early stages of developing a >> validation API for future inclusion into JavaFX. I thought rather than >> get too far into the research and development of a proof of concept, I >> would see what you all think. Any feedback now would be very useful. >> >> Essentially, there are a few common styles related to form validation. >> Some of the more likely approaches include: >> >> * The 'JGoodies Validation framework' [1] approach, where the >> developer provides a Validator that will then run over the form and >> gather feedback to return to the user (for example, it would test >> that the 'name field' is not empty, and that the email address is of >> the correct style - if either of these rules are invalid, the >> Validator would return ValidationMessage instances inside a >> ValidationResult). If validation fails the user is shown the text >> out of the ValidationMessage feedback, otherwise the form would >> submit as per usual. This validation may happen at a number of times >> (during form submission, when focus is lost, as a key is typed, >> etc). The nice thing about this approach is that the Validator can >> be a part of the domain model, the presentation model, or a separate >> thing altogether. >> * The JSR-303 approach which uses annotations to indicate the rules >> applicable to each field. These annotations are on the domain model, >> and therefore assumes that the form is directly tied to a domain >> object (which may not always be correct). I think the JSR-303 API is >> too complex for what is needed in JavaFX, but a similar >> implementation could be developed with a simpler API that follows >> this approach. >> * For lack of a better reference point, the FXForm approach [3] which >> encapsulates the validation inside a Form object that can be placed >> in the scene. I know this isn't explicitly (in the case of FXForm) >> about validation, but I think it is another approach to consider. >> >> So, what does JavaFX need out of a validation framework? It's really >> five things (I think): >> >> 1. A way for developers to validate a form by providing some means of >> specifying rules, as well as a way to specify when it runs, how it >> is visually represented, etc. >> 2. A way for the validation to impact upon the visual state of the form >> (using consistent CSS pseudoclass states / style classes, as well as >> by showing custom overlays, error messages beside the component (or >> grouped together at the top of the form)). There must be API to >> specify all of this. >> 3. Convenient API to simplify the validation process [3] (e.g. >> isEmpty(String), isAlphanumeric(String), etc, etc, etc). >> 4. An API that does not require it be integrated with UI controls. >> Doing so would prevent 3rd party UI controls to be able to be >> validated without also implementing the API, which may prove >> burdensome. Instead, the validation API should be separate. >> 5. A means to integrate nicely with the bindings and properties API >> present in JavaFX today. >> >> Of the three approaches above, my personal preference is to follow the >> JGoodies approach as I think it is the most powerful and flexible. >> However, nothing is set in stone and I want to learn what others think. >> >> Note that at present this research does not extend to considering >> whether there should be API related to automatically generating a form >> from a (JavaFX) bean (and making use of the validation API to ensure >> the input is correct). However, I am not against discussing this topic >> as well, as long as it too integrates nicely with the rules above, as >> well as the validation API itself, obviously. This research may full >> into requirement three above. >> >> [1] http://www.jgoodies.com/freeware/libraries/validation/ >> [2] https://github.com/dooApp/FXForm2 >> [3] >> http://www.jarvana.com/jarvana/view/com/jgoodies/validation/2.0.1/validation-2.0.1-javadoc.jar!/com/jgoodies/validation/util/ValidationUtils.html >> >> >> Thanks, >> -- Jonathan >> > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From christian.schudt at gmx.de Mon Jun 11 00:32:24 2012 From: christian.schudt at gmx.de (Christian Schudt) Date: Mon, 11 Jun 2012 09:32:24 +0200 Subject: JavaFX Form Validation In-Reply-To: <4FD5332A.5080608@oracle.com> References: <4FD5332A.5080608@oracle.com> Message-ID: <20120611073224.10730@gmx.net> Hi all, I don't know the JGoodies framework, but I do know the Adobe Flex 3.5 validation framework, which seems to be very similar, from what you described (JGoodies). Basically you have an (abstract) Validator class, with concrete default implementations like EMailValidator. A validator has a source property (which is the Control to validate) and a String property which points to the property name of that control (this could be done nicer in Java with ObservableValue instead of String, default would be textProperty()). Furthermore you can specifiy the control's event which should trigger the validator and a listener (the default listener is again the Control). This could be a little bit more inconvenient, since the focus lost event is just a property change. The control then listens to a ValidationResultEvent and displays a validation message from the event object. That also means that (each?) Control has to implement an ValidationListener interface. That's it basically. There is a little bit other stuff like ValidationSummaries and so on. It's very flexible. If you want to make a custom validator, just derive from abstract Validator and provide your own logic. If you want to add other ValidationResult listeners, just tell it the Validator. ==== JSR 303: Alluring, but.... I've done a very simple validation with this approach since I thought it is the cleanest way. But the need of a domain model, which matches exactly the form, can be cumbersome, especially if you have to validate if field 1 matches field 2 (e.g. in the case, if you want to validate two passwords to be equal). Furthermore you don't have direct access to the control, but only to the domain model you are validating, which can be troublesome. Furthermore I needed to write logic to enhance a domain object (pojo) with JavaFX properties, in order to use binding! But maybe all these little disadvantages can be solved in a nice flexible way. I also feel, that the first approach is the most flexible one, but the JSR 303 is also nice, if you can manage to design a good flexible api. Kind regards Christian -------- Original-Nachricht -------- > Datum: Mon, 11 Jun 2012 11:52:10 +1200 > Von: Jonathan Giles > An: "openjfx-dev at openjdk.java.net" > Betreff: JavaFX Form Validation > Hi all, > > I'm currently in the very, very early stages of developing a validation > API for future inclusion into JavaFX. I thought rather than get too far > into the research and development of a proof of concept, I would see > what you all think. Any feedback now would be very useful. > > Essentially, there are a few common styles related to form validation. > Some of the more likely approaches include: > > * The 'JGoodies Validation framework' [1] approach, where the > developer provides a Validator that will then run over the form and > gather feedback to return to the user (for example, it would test > that the 'name field' is not empty, and that the email address is of > the correct style - if either of these rules are invalid, the > Validator would return ValidationMessage instances inside a > ValidationResult). If validation fails the user is shown the text > out of the ValidationMessage feedback, otherwise the form would > submit as per usual. This validation may happen at a number of times > (during form submission, when focus is lost, as a key is typed, > etc). The nice thing about this approach is that the Validator can > be a part of the domain model, the presentation model, or a separate > thing altogether. > * The JSR-303 approach which uses annotations to indicate the rules > applicable to each field. These annotations are on the domain model, > and therefore assumes that the form is directly tied to a domain > object (which may not always be correct). I think the JSR-303 API is > too complex for what is needed in JavaFX, but a similar > implementation could be developed with a simpler API that follows > this approach. > * For lack of a better reference point, the FXForm approach [3] which > encapsulates the validation inside a Form object that can be placed > in the scene. I know this isn't explicitly (in the case of FXForm) > about validation, but I think it is another approach to consider. > > So, what does JavaFX need out of a validation framework? It's really > five things (I think): > > 1. A way for developers to validate a form by providing some means of > specifying rules, as well as a way to specify when it runs, how it > is visually represented, etc. > 2. A way for the validation to impact upon the visual state of the form > (using consistent CSS pseudoclass states / style classes, as well as > by showing custom overlays, error messages beside the component (or > grouped together at the top of the form)). There must be API to > specify all of this. > 3. Convenient API to simplify the validation process [3] (e.g. > isEmpty(String), isAlphanumeric(String), etc, etc, etc). > 4. An API that does not require it be integrated with UI controls. > Doing so would prevent 3rd party UI controls to be able to be > validated without also implementing the API, which may prove > burdensome. Instead, the validation API should be separate. > 5. A means to integrate nicely with the bindings and properties API > present in JavaFX today. > > Of the three approaches above, my personal preference is to follow the > JGoodies approach as I think it is the most powerful and flexible. > However, nothing is set in stone and I want to learn what others think. > > Note that at present this research does not extend to considering > whether there should be API related to automatically generating a form > from a (JavaFX) bean (and making use of the validation API to ensure the > input is correct). However, I am not against discussing this topic as > well, as long as it too integrates nicely with the rules above, as well > as the validation API itself, obviously. This research may full into > requirement three above. > > [1] http://www.jgoodies.com/freeware/libraries/validation/ > [2] https://github.com/dooApp/FXForm2 > [3] > http://www.jarvana.com/jarvana/view/com/jgoodies/validation/2.0.1/validation-2.0.1-javadoc.jar!/com/jgoodies/validation/util/ValidationUtils.html > > Thanks, > -- Jonathan > -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de From tbee at tbee.org Mon Jun 11 00:35:27 2012 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 11 Jun 2012 09:35:27 +0200 Subject: JavaFX Form Validation In-Reply-To: <4FD59C8F.6090903@bestsolution.at> References: <4FD5332A.5080608@oracle.com> <4FD59A89.80703@tbee.org> <4FD59C8F.6090903@bestsolution.at> Message-ID: <4FD59FBF.9020204@tbee.org> Hi, I see what you want to do; leaving all the handling to the coders. Visualization could be a stand alone API, but a lot of coders would prefer a more integrated solution, not having to figure out how to do validation. This was something that the Swing framework was trying to add to swing. So the validation logic can be layered, and visualization is the lowest layer, but I would take it up a few notches. Tom On 2012-06-11 09:21, Tom Schindl wrote: > Hi, > > I don't think it is the task of JavaFX to provide a validation system. > > All it needs to provide is an API on the controls to show validation > results. > > Tom > > From hang.vo at oracle.com Mon Jun 11 01:03:46 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Jun 2012 08:03:46 +0000 Subject: hg: openjfx/2.2/graphics/rt: Fixed mouse event copying problem introduced by fix for RT-22150. Message-ID: <20120611080349.1E4834783C@hg.openjdk.java.net> Changeset: 62938da54121 Author: Pavel Safrata Date: 2012-06-11 09:56 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/62938da54121 Fixed mouse event copying problem introduced by fix for RT-22150. ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java From hjohn at xs4all.nl Mon Jun 11 01:33:04 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Mon, 11 Jun 2012 10:33:04 +0200 Subject: JavaFX Form Validation In-Reply-To: <4FD59A89.80703@tbee.org> References: <4FD5332A.5080608@oracle.com> <4FD59A89.80703@tbee.org> Message-ID: <4FD5AD40.8090402@xs4all.nl> Hi Tom, Just a note, I think your simple validation doesn't go far enough already. I want validation after every key typed, so any bound fields would need to accept values that are considered illegal (when entering an age > 20, it should not balk after I only typed one character, but it should display a marker that the value is not yet within the accepted range). On 11/06/2012 09:13, Tom Eugelink wrote: > Hi all, > > Ah, a topic that is close to my heart. Personally I'm big on reuse, so > initially approach 1 seems to come closest. However I'm even a bigger > fan of clear separation, and having a form validation in a domain > model is debatable. Here is my brain dump; > > Normally, one would split out the validation activity around a form in > multiple parts; > 1. simple validation; usually these kinds of validation are > implemented directly on the setter, like "age >= 0" and can be > displayed immediately after the field is exited / committed. Normally > one would use a IllegalArgumentException in the setter to enforce it, > contrarily to annotations on the setter, an IAE is enforced always and > requires no reflection on the UI side. However the current bindings do > not allow proper handling of this (see my blog post of a year back). > > 2. grouped validation; these are validations between fields, things > like "before < after". You could do this in the setters, but that > usually creates entry issues. So this needs to be in some kind of post > setter validation call on the entity, probably on submit of the form. > > 3. general on submit form level validations, the mandatory fields fall > into this category. You could try to merge this with grouped validation. > > 3. But not all forms are directly bound to entities, for example a > wizard collects all kinds of information and usually only in the end > are entities involved. These forms usually are backed by a backing > class, which basically has the same validations features as entities, > only do not reside in the domain model. > > 4. 99% of all the validations would fall in the contexts above, but > there is always that form specific thing. So a form internal > validation is required as well. > > 5. Lastly grouping and enabling. You can use forms in different > contexts, e.g. editing an entity or a template (which is then used to > easy create new entities). Such a template probably has a lot of > constraints disabled. So it would be good to be able to partially > disabled groups of constraints for a form. From jonathan.giles at oracle.com Mon Jun 11 01:43:54 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 11 Jun 2012 20:43:54 +1200 Subject: JavaFX Form Validation In-Reply-To: <4FD59A89.80703@tbee.org> References: <4FD5332A.5080608@oracle.com> <4FD59A89.80703@tbee.org> Message-ID: <4FD5AFCA.2080308@oracle.com> Thanks Tom for your response. I'm going to approach this email as an advocate for my preferred approach - the JGoodies validation approach. This does not mean that my preferred approach is right, so feel free to disagree! My comments are inline. On 11/06/2012 7:13 p.m., Tom Eugelink wrote: > Hi all, > > Ah, a topic that is close to my heart. Personally I'm big on reuse, so > initially approach 1 seems to come closest. However I'm even a bigger > fan of clear separation, and having a form validation in a domain > model is debatable. Here is my brain dump; It is totally fair to say that validation in the domain model is debatable. However, approach 1 does not force this approach. Refer to the following link for a PDF containing a number of approaches to validation that the JGoodies approach offers: http://www.jgoodies.com/download/presentations/validation.pdf > > Normally, one would split out the validation activity around a form in > multiple parts; > 1. simple validation; usually these kinds of validation are > implemented directly on the setter, like "age >= 0" and can be > displayed immediately after the field is exited / committed. Normally > one would use a IllegalArgumentException in the setter to enforce it, > contrarily to annotations on the setter, an IAE is enforced always and > requires no reflection on the UI side. However the current bindings do > not allow proper handling of this (see my blog post of a year back). In JavaFX setters are final methods, and putting any logic into them (when a property exists) is fundamentally flawed as the setter logic is not guaranteed to be executed (e.g. setFoo(bar) is the same as fooProperty().set(bar), and this completely bypasses the setter logic). The obvious response to this is to put the validation logic in the property set method. Unfortunately, in this case, it is too late - the value has already been set (and events fired). Therefore, I would imagine that without support for vetoing property changes, this is a non-starter. I would think that a better approach is to use the JGoodies approach of providing a Validator, and simply configuring when the validation should occur to suit the needs of the application. > > 2. grouped validation; these are validations between fields, things > like "before < after". You could do this in the setters, but that > usually creates entry issues. So this needs to be in some kind of post > setter validation call on the entity, probably on submit of the form. Agreed. So, in my current position of favouring the JGoodies approach, this requirement is supported as-is. > > 3. general on submit form level validations, the mandatory fields fall > into this category. You could try to merge this with grouped validation. Again, covered by JGoodies Validation. > > 3. But not all forms are directly bound to entities, for example a > wizard collects all kinds of information and usually only in the end > are entities involved. These forms usually are backed by a backing > class, which basically has the same validations features as entities, > only do not reside in the domain model. Same again: covered by JGoodies Validation. > > 4. 99% of all the validations would fall in the contexts above, but > there is always that form specific thing. So a form internal > validation is required as well. Can you expand here? > > 5. Lastly grouping and enabling. You can use forms in different > contexts, e.g. editing an entity or a template (which is then used to > easy create new entities). Such a template probably has a lot of > constraints disabled. So it would be good to be able to partially > disabled groups of constraints for a form. In the JGoodies sense, this is completely in the control of the developer - they are the ones creating the Validator, and they can control what tests are run as part of it. > > Personally I would go for an approach where a validator can be > registered to any control or container. There could be an easy > reflection based implementation which is parallel to the binding; so > if you bind the control to an property on an entity, a validation also > is set that looks at the annotations of that property, maybe even > automatically. A form can be bound to an form validator. But it is > always possible to create ones own validator and override the > behavior. Since we need something of a "form" class anyhow, the > context of the validation (what is enabled and what not) should be set > there. A validator can be be assigned one or more group ids, and call > for validation gets the form as a parameter, implicitely giving it > access to the validation context, so it can check if it is enabled or > not. I'm not sure we've quite crossed the bridge regarding needing 'something of a form class anyhow'. To me, so far anyway, there is no clear requirement for a Form class. Can you expand on what this would provide? In fact, I'm not sure we even need to register a Validator on a control or container. Instead, a Validator could be initiated by a developer as part of their usual form submission code (e.g. an action event on a Button). Again, is there a compelling reason that I am missing? Thanks, Jonathan From jonathan.giles at oracle.com Mon Jun 11 01:46:27 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 11 Jun 2012 20:46:27 +1200 Subject: JavaFX Form Validation In-Reply-To: <20120611073224.10730@gmx.net> References: <4FD5332A.5080608@oracle.com> <20120611073224.10730@gmx.net> Message-ID: <4FD5B063.5010101@oracle.com> Christian, Thanks. I'm unfamiliar with the Flex approach, but will spend some time tomorrow getting to know it so that I'm better informed. I agree with your concerns regarding support for validation using annotations. That is a big sticking point against this approach. -- Jonathan On 11/06/2012 7:32 p.m., Christian Schudt wrote: > Hi all, > > I don't know the JGoodies framework, but I do know the Adobe Flex 3.5 validation framework, which seems to be very similar, from what you described (JGoodies). > > Basically you have an (abstract) Validator class, with concrete default implementations like EMailValidator. A validator has a source property (which is the Control to validate) and a String property which points to the property name of that control (this could be done nicer in Java with ObservableValue instead of String, default would be textProperty()). > Furthermore you can specifiy the control's event which should trigger the validator and a listener (the default listener is again the Control). > This could be a little bit more inconvenient, since the focus lost event is just a property change. > > The control then listens to a ValidationResultEvent and displays a validation message from the event object. > That also means that (each?) Control has to implement an ValidationListener interface. > > That's it basically. There is a little bit other stuff like ValidationSummaries and so on. > It's very flexible. If you want to make a custom validator, just derive from abstract Validator and provide your own logic. > If you want to add other ValidationResult listeners, just tell it the Validator. > > ==== > > JSR 303: Alluring, but.... I've done a very simple validation with this approach since I thought it is the cleanest way. But the need of a domain model, which matches exactly the form, can be cumbersome, especially if you have to validate if field 1 matches field 2 (e.g. in the case, if you want to validate two passwords to be equal). > Furthermore you don't have direct access to the control, but only to the domain model you are validating, which can be troublesome. > Furthermore I needed to write logic to enhance a domain object (pojo) with JavaFX properties, in order to use binding! > > But maybe all these little disadvantages can be solved in a nice flexible way. > > I also feel, that the first approach is the most flexible one, but the JSR 303 is also nice, if you can manage to design a good flexible api. > > Kind regards > Christian > > > -------- Original-Nachricht -------- >> Datum: Mon, 11 Jun 2012 11:52:10 +1200 >> Von: Jonathan Giles >> An: "openjfx-dev at openjdk.java.net" >> Betreff: JavaFX Form Validation >> Hi all, >> >> I'm currently in the very, very early stages of developing a validation >> API for future inclusion into JavaFX. I thought rather than get too far >> into the research and development of a proof of concept, I would see >> what you all think. Any feedback now would be very useful. >> >> Essentially, there are a few common styles related to form validation. >> Some of the more likely approaches include: >> >> * The 'JGoodies Validation framework' [1] approach, where the >> developer provides a Validator that will then run over the form and >> gather feedback to return to the user (for example, it would test >> that the 'name field' is not empty, and that the email address is of >> the correct style - if either of these rules are invalid, the >> Validator would return ValidationMessage instances inside a >> ValidationResult). If validation fails the user is shown the text >> out of the ValidationMessage feedback, otherwise the form would >> submit as per usual. This validation may happen at a number of times >> (during form submission, when focus is lost, as a key is typed, >> etc). The nice thing about this approach is that the Validator can >> be a part of the domain model, the presentation model, or a separate >> thing altogether. >> * The JSR-303 approach which uses annotations to indicate the rules >> applicable to each field. These annotations are on the domain model, >> and therefore assumes that the form is directly tied to a domain >> object (which may not always be correct). I think the JSR-303 API is >> too complex for what is needed in JavaFX, but a similar >> implementation could be developed with a simpler API that follows >> this approach. >> * For lack of a better reference point, the FXForm approach [3] which >> encapsulates the validation inside a Form object that can be placed >> in the scene. I know this isn't explicitly (in the case of FXForm) >> about validation, but I think it is another approach to consider. >> >> So, what does JavaFX need out of a validation framework? It's really >> five things (I think): >> >> 1. A way for developers to validate a form by providing some means of >> specifying rules, as well as a way to specify when it runs, how it >> is visually represented, etc. >> 2. A way for the validation to impact upon the visual state of the form >> (using consistent CSS pseudoclass states / style classes, as well as >> by showing custom overlays, error messages beside the component (or >> grouped together at the top of the form)). There must be API to >> specify all of this. >> 3. Convenient API to simplify the validation process [3] (e.g. >> isEmpty(String), isAlphanumeric(String), etc, etc, etc). >> 4. An API that does not require it be integrated with UI controls. >> Doing so would prevent 3rd party UI controls to be able to be >> validated without also implementing the API, which may prove >> burdensome. Instead, the validation API should be separate. >> 5. A means to integrate nicely with the bindings and properties API >> present in JavaFX today. >> >> Of the three approaches above, my personal preference is to follow the >> JGoodies approach as I think it is the most powerful and flexible. >> However, nothing is set in stone and I want to learn what others think. >> >> Note that at present this research does not extend to considering >> whether there should be API related to automatically generating a form >> from a (JavaFX) bean (and making use of the validation API to ensure the >> input is correct). However, I am not against discussing this topic as >> well, as long as it too integrates nicely with the rules above, as well >> as the validation API itself, obviously. This research may full into >> requirement three above. >> >> [1] http://www.jgoodies.com/freeware/libraries/validation/ >> [2] https://github.com/dooApp/FXForm2 >> [3] >> http://www.jarvana.com/jarvana/view/com/jgoodies/validation/2.0.1/validation-2.0.1-javadoc.jar!/com/jgoodies/validation/util/ValidationUtils.html >> >> Thanks, >> -- Jonathan >> From fbrunnerlist at gmx.ch Mon Jun 11 01:47:14 2012 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Mon, 11 Jun 2012 10:47:14 +0200 Subject: JavaFX Form Validation In-Reply-To: <4FD5332A.5080608@oracle.com> References: <4FD5332A.5080608@oracle.com> Message-ID: <201206111047.14489.fbrunnerlist@gmx.ch> Hi, I haven't worked with JSR-303, yet, but I would appreciate if the Java community could come up with a validation framework which can be used consistently on various layers. If JSR-303 currently doesn't fit the needs of JavaFX, maybe the JavaFX team could get involved in JSR-303 to make sure it fits the needs of JavaFX as well? Regards, Florian Am Montag 11 Juni 2012, 01:52:10 schrieb Jonathan Giles: > Hi all, > > I'm currently in the very, very early stages of developing a validation > API for future inclusion into JavaFX. I thought rather than get too far > into the research and development of a proof of concept, I would see > what you all think. Any feedback now would be very useful. > > Essentially, there are a few common styles related to form validation. > Some of the more likely approaches include: > > * The 'JGoodies Validation framework' [1] approach, where the > developer provides a Validator that will then run over the form and > gather feedback to return to the user (for example, it would test > that the 'name field' is not empty, and that the email address is of > the correct style - if either of these rules are invalid, the > Validator would return ValidationMessage instances inside a > ValidationResult). If validation fails the user is shown the text > out of the ValidationMessage feedback, otherwise the form would > submit as per usual. This validation may happen at a number of times > (during form submission, when focus is lost, as a key is typed, > etc). The nice thing about this approach is that the Validator can > be a part of the domain model, the presentation model, or a separate > thing altogether. > * The JSR-303 approach which uses annotations to indicate the rules > applicable to each field. These annotations are on the domain model, > and therefore assumes that the form is directly tied to a domain > object (which may not always be correct). I think the JSR-303 API is > too complex for what is needed in JavaFX, but a similar > implementation could be developed with a simpler API that follows > this approach. > * For lack of a better reference point, the FXForm approach [3] which > encapsulates the validation inside a Form object that can be placed > in the scene. I know this isn't explicitly (in the case of FXForm) > about validation, but I think it is another approach to consider. > > So, what does JavaFX need out of a validation framework? It's really > five things (I think): > > 1. A way for developers to validate a form by providing some means of > specifying rules, as well as a way to specify when it runs, how it > is visually represented, etc. > 2. A way for the validation to impact upon the visual state of the form > (using consistent CSS pseudoclass states / style classes, as well as > by showing custom overlays, error messages beside the component (or > grouped together at the top of the form)). There must be API to > specify all of this. > 3. Convenient API to simplify the validation process [3] (e.g. > isEmpty(String), isAlphanumeric(String), etc, etc, etc). > 4. An API that does not require it be integrated with UI controls. > Doing so would prevent 3rd party UI controls to be able to be > validated without also implementing the API, which may prove > burdensome. Instead, the validation API should be separate. > 5. A means to integrate nicely with the bindings and properties API > present in JavaFX today. > > Of the three approaches above, my personal preference is to follow the > JGoodies approach as I think it is the most powerful and flexible. > However, nothing is set in stone and I want to learn what others think. > > Note that at present this research does not extend to considering > whether there should be API related to automatically generating a form > from a (JavaFX) bean (and making use of the validation API to ensure the > input is correct). However, I am not against discussing this topic as > well, as long as it too integrates nicely with the rules above, as well > as the validation API itself, obviously. This research may full into > requirement three above. > > [1] http://www.jgoodies.com/freeware/libraries/validation/ > [2] https://github.com/dooApp/FXForm2 > [3] > http://www.jarvana.com/jarvana/view/com/jgoodies/validation/2.0.1/validation-2.0.1-javadoc.jar!/com/jgoodies/validation/util/ValidationUtils.html > > Thanks, > -- Jonathan > > From hjohn at xs4all.nl Mon Jun 11 01:48:50 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Mon, 11 Jun 2012 10:48:50 +0200 Subject: JavaFX Task/Service thread checks Message-ID: <4FD5B0F2.1080908@xs4all.nl> Hi all, JavaFX currently provides many interesting new ways of doing things we've been doing for years. For example, I find myself using JavaFX packages outside the scope of the UI more and more often. Examples are changing domain objects to include the JavaFX style Property methods for easy binding and using Task objects to make use of its convenient State property (to which one can attach listeners). However, I'm wondering, why is there a 'checkThread' in for example the stateProperty method of a Task? Wasn't it said that manipulating JavaFX objects that are NOT part of a Scene was to be allowed on any thread? Do I need to worry that other (reusable without UI) API's in JavaFX will have this checkThread method sprinkled through them? I mean, shouldn't it be allowed to create a new Task object, have it get executed on some thread of my choosing, and then be able to monitor its progress by attaching a ChangeListener to its State property? This is a lot more convenient than say a FutureTask, for which I'm forced to either wrap it inside another Runnable (to do a little bit of clean-up after it finished, on the same thread), create another thread so I can use the blocking 'get()' call or adding a simplistic Listener system to it notify me when it completes (again, on the same thread). My Task is not attached to the UI in any way, yet it forces me to wrap the call to 'stateProperty()' in a Platform.runLater() -- all I want is its feedback when it finishes without me having to build this system myself or spawning yet another Thread. Best regards, John Hendrikx From tom.schindl at bestsolution.at Mon Jun 11 01:53:37 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 11 Jun 2012 10:53:37 +0200 Subject: JavaFX Form Validation In-Reply-To: <4FD59FBF.9020204@tbee.org> References: <4FD5332A.5080608@oracle.com> <4FD59A89.80703@tbee.org> <4FD59C8F.6090903@bestsolution.at> <4FD59FBF.9020204@tbee.org> Message-ID: <4FD5B211.7090805@bestsolution.at> Well my fear is that the more functions you push into JavaFX the more code they have to maintain and the less time they can spend on controls I still see missing (e.g. TreeTable control) who hurt JavaFX a lot more than a missing validation system. If you push every piece of highlevel feature (and yes I see validation as a highlevel feature) into a Graphics and Control-Library - at least this is my understanding of JavaFX - then you end up with a big beast you have to abandon one day once more. So while I understand that having a standard validation system I'd like to see resources invested in: a) A validation visualization API at the control level b) Implementing Controls Tom Am 11.06.12 09:35, schrieb Tom Eugelink: > Hi, > > I see what you want to do; leaving all the handling to the coders. > Visualization could be a stand alone API, but a lot of coders would > prefer a more integrated solution, not having to figure out how to do > validation. This was something that the Swing framework was trying to > add to swing. So the validation logic can be layered, and visualization > is the lowest layer, but I would take it up a few notches. > > Tom > > > > On 2012-06-11 09:21, Tom Schindl wrote: >> Hi, >> >> I don't think it is the task of JavaFX to provide a validation system. >> >> All it needs to provide is an API on the controls to show validation >> results. >> >> Tom >> >> > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From tbee at tbee.org Mon Jun 11 01:57:40 2012 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 11 Jun 2012 10:57:40 +0200 Subject: JavaFX Form Validation In-Reply-To: <201206111047.14489.fbrunnerlist@gmx.ch> References: <4FD5332A.5080608@oracle.com> <201206111047.14489.fbrunnerlist@gmx.ch> Message-ID: <4FD5B304.6040703@tbee.org> There is something to be said for that, yes. On 2012-06-11 10:47, Florian Brunner wrote: > Hi, > > I haven't worked with JSR-303, yet, but I would appreciate if the Java community could come up with a validation framework which can be used consistently on various layers. > > If JSR-303 currently doesn't fit the needs of JavaFX, maybe the JavaFX team could get involved in JSR-303 to make sure it fits the needs of JavaFX as well? > > Regards, > Florian > > From sven.reimers at gmail.com Mon Jun 11 01:56:57 2012 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 11 Jun 2012 10:56:57 +0200 Subject: JIRA down? In-Reply-To: <129145.7942.26881-16395-573353230-1339361145@seznam.cz> References: <129145.7942.26881-16395-573353230-1339361145@seznam.cz> Message-ID: I still see that same problem - any updates? -Sven On Sun, Jun 10, 2012 at 10:45 PM, wrote: > Hi, > > is JIRA down? > > JIRA Startup Failed > You cannot access JIRA at present. Look at the table below to identify the reasons > > Description > The jira.home directory '/issues/jira-42' is already locked. Please see the JIRA documentation for more information on locked jira.home directories. > > This is what I was welcomed with when I wanted to check something. > > Regards, Jiri -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * Community Leader? NetBeans: http://community.java.net/netbeans ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 ? ? ? ? ? ? ? ? ?? http://www.linkedin.com/groups?gid=107402 ? ? ? ? ? ? ? ? ?? http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From jonathan.giles at oracle.com Mon Jun 11 01:57:03 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 11 Jun 2012 20:57:03 +1200 Subject: JavaFX Form Validation In-Reply-To: <4FD59C8F.6090903@bestsolution.at> References: <4FD5332A.5080608@oracle.com> <4FD59A89.80703@tbee.org> <4FD59C8F.6090903@bestsolution.at> Message-ID: <4FD5B2DF.8020801@oracle.com> Tom, It is perfectly valid to argue against adding more API to JavaFX. Heck - the less I have to maintain the happier I am, so I'm (nearly) on your side! :-) I don't have a compelling argument for including validation support in JavaFX, however I think the best argument I have is that it is likely to be something required by the vast majority of developers. Just having support for showing validation results seems to me to be a little too low-level given the assumed needs of most developers (in my very humble and gut-feeling opinion). I also think that it is likely that by being part of the core JavaFX API it would allow for validation support to be baked in at a lower level (in particular better UI styling in the case of validation failures). -- Jonathan On 11/06/2012 7:21 p.m., Tom Schindl wrote: > Hi, > > I don't think it is the task of JavaFX to provide a validation system. > > All it needs to provide is an API on the controls to show validation > results. > > Tom > > Am 11.06.12 09:13, schrieb Tom Eugelink: >> Hi all, >> >> Ah, a topic that is close to my heart. Personally I'm big on reuse, so >> initially approach 1 seems to come closest. However I'm even a bigger >> fan of clear separation, and having a form validation in a domain model >> is debatable. Here is my brain dump; >> >> Normally, one would split out the validation activity around a form in >> multiple parts; >> 1. simple validation; usually these kinds of validation are implemented >> directly on the setter, like "age>= 0" and can be displayed immediately >> after the field is exited / committed. Normally one would use a >> IllegalArgumentException in the setter to enforce it, contrarily to >> annotations on the setter, an IAE is enforced always and requires no >> reflection on the UI side. However the current bindings do not allow >> proper handling of this (see my blog post of a year back). >> >> 2. grouped validation; these are validations between fields, things like >> "before< after". You could do this in the setters, but that usually >> creates entry issues. So this needs to be in some kind of post setter >> validation call on the entity, probably on submit of the form. >> >> 3. general on submit form level validations, the mandatory fields fall >> into this category. You could try to merge this with grouped validation. >> >> 3. But not all forms are directly bound to entities, for example a >> wizard collects all kinds of information and usually only in the end are >> entities involved. These forms usually are backed by a backing class, >> which basically has the same validations features as entities, only do >> not reside in the domain model. >> >> 4. 99% of all the validations would fall in the contexts above, but >> there is always that form specific thing. So a form internal validation >> is required as well. >> >> 5. Lastly grouping and enabling. You can use forms in different >> contexts, e.g. editing an entity or a template (which is then used to >> easy create new entities). Such a template probably has a lot of >> constraints disabled. So it would be good to be able to partially >> disabled groups of constraints for a form. >> >> Summary: >> - per field direct validation >> - on submit validations >> - both in directly in the entity or on backing classes (or a combination) >> - form internal validation >> - grouping and enabling >> >> Personally I would go for an approach where a validator can be >> registered to any control or container. There could be an easy >> reflection based implementation which is parallel to the binding; so if >> you bind the control to an property on an entity, a validation also is >> set that looks at the annotations of that property, maybe even >> automatically. A form can be bound to an form validator. But it is >> always possible to create ones own validator and override the behavior. >> Since we need something of a "form" class anyhow, the context of the >> validation (what is enabled and what not) should be set there. A >> validator can be be assigned one or more group ids, and call for >> validation gets the form as a parameter, implicitely giving it access to >> the validation context, so it can check if it is enabled or not. >> >> Makes the above any sense? >> >> Your 5 summary points are perfect. How to visualize, external to the >> controls, join up with binding. Yup. >> >> Tom >> >> >> On 2012-06-11 01:52, Jonathan Giles wrote: >>> Hi all, >>> >>> I'm currently in the very, very early stages of developing a >>> validation API for future inclusion into JavaFX. I thought rather than >>> get too far into the research and development of a proof of concept, I >>> would see what you all think. Any feedback now would be very useful. >>> >>> Essentially, there are a few common styles related to form validation. >>> Some of the more likely approaches include: >>> >>> * The 'JGoodies Validation framework' [1] approach, where the >>> developer provides a Validator that will then run over the form and >>> gather feedback to return to the user (for example, it would test >>> that the 'name field' is not empty, and that the email address is of >>> the correct style - if either of these rules are invalid, the >>> Validator would return ValidationMessage instances inside a >>> ValidationResult). If validation fails the user is shown the text >>> out of the ValidationMessage feedback, otherwise the form would >>> submit as per usual. This validation may happen at a number of times >>> (during form submission, when focus is lost, as a key is typed, >>> etc). The nice thing about this approach is that the Validator can >>> be a part of the domain model, the presentation model, or a separate >>> thing altogether. >>> * The JSR-303 approach which uses annotations to indicate the rules >>> applicable to each field. These annotations are on the domain model, >>> and therefore assumes that the form is directly tied to a domain >>> object (which may not always be correct). I think the JSR-303 API is >>> too complex for what is needed in JavaFX, but a similar >>> implementation could be developed with a simpler API that follows >>> this approach. >>> * For lack of a better reference point, the FXForm approach [3] which >>> encapsulates the validation inside a Form object that can be placed >>> in the scene. I know this isn't explicitly (in the case of FXForm) >>> about validation, but I think it is another approach to consider. >>> >>> So, what does JavaFX need out of a validation framework? It's really >>> five things (I think): >>> >>> 1. A way for developers to validate a form by providing some means of >>> specifying rules, as well as a way to specify when it runs, how it >>> is visually represented, etc. >>> 2. A way for the validation to impact upon the visual state of the form >>> (using consistent CSS pseudoclass states / style classes, as well as >>> by showing custom overlays, error messages beside the component (or >>> grouped together at the top of the form)). There must be API to >>> specify all of this. >>> 3. Convenient API to simplify the validation process [3] (e.g. >>> isEmpty(String), isAlphanumeric(String), etc, etc, etc). >>> 4. An API that does not require it be integrated with UI controls. >>> Doing so would prevent 3rd party UI controls to be able to be >>> validated without also implementing the API, which may prove >>> burdensome. Instead, the validation API should be separate. >>> 5. A means to integrate nicely with the bindings and properties API >>> present in JavaFX today. >>> >>> Of the three approaches above, my personal preference is to follow the >>> JGoodies approach as I think it is the most powerful and flexible. >>> However, nothing is set in stone and I want to learn what others think. >>> >>> Note that at present this research does not extend to considering >>> whether there should be API related to automatically generating a form >>> from a (JavaFX) bean (and making use of the validation API to ensure >>> the input is correct). However, I am not against discussing this topic >>> as well, as long as it too integrates nicely with the rules above, as >>> well as the validation API itself, obviously. This research may full >>> into requirement three above. >>> >>> [1] http://www.jgoodies.com/freeware/libraries/validation/ >>> [2] https://github.com/dooApp/FXForm2 >>> [3] >>> http://www.jarvana.com/jarvana/view/com/jgoodies/validation/2.0.1/validation-2.0.1-javadoc.jar!/com/jgoodies/validation/util/ValidationUtils.html >>> >>> >>> Thanks, >>> -- Jonathan >>> > From jonathan.giles at oracle.com Mon Jun 11 02:01:13 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 11 Jun 2012 21:01:13 +1200 Subject: JavaFX Form Validation In-Reply-To: <201206111047.14489.fbrunnerlist@gmx.ch> References: <4FD5332A.5080608@oracle.com> <201206111047.14489.fbrunnerlist@gmx.ch> Message-ID: <4FD5B3D9.7000508@oracle.com> Florian, My understanding of JSR-303 is that it is well past the stages of being active. According to [1], it starting in July 2006, and produced its final release (along with final API) in November of 2009. Also, from my understanding of JSR-303, it appears to be more focused on the Java EE needs of a container such as Hibernate (one component of which is the reference implementation of JSR-303). I would imagine that this would lead to it being far more complex than is necessary in a JavaFX API. However, I am not ruling it out, but I just worry that it may be ill-fitting for JavaFX. I would be totally happy to be proven wrong, and will look into it more tomorrow to be sure. [1] http://jcp.org/en/jsr/detail?id=303 -- Jonathan On 11/06/2012 8:47 p.m., Florian Brunner wrote: > Hi, > > I haven't worked with JSR-303, yet, but I would appreciate if the Java community could come up with a validation framework which can be used consistently on various layers. > > If JSR-303 currently doesn't fit the needs of JavaFX, maybe the JavaFX team could get involved in JSR-303 to make sure it fits the needs of JavaFX as well? > > Regards, > Florian > > Am Montag 11 Juni 2012, 01:52:10 schrieb Jonathan Giles: >> Hi all, >> >> I'm currently in the very, very early stages of developing a validation >> API for future inclusion into JavaFX. I thought rather than get too far >> into the research and development of a proof of concept, I would see >> what you all think. Any feedback now would be very useful. >> >> Essentially, there are a few common styles related to form validation. >> Some of the more likely approaches include: >> >> * The 'JGoodies Validation framework' [1] approach, where the >> developer provides a Validator that will then run over the form and >> gather feedback to return to the user (for example, it would test >> that the 'name field' is not empty, and that the email address is of >> the correct style - if either of these rules are invalid, the >> Validator would return ValidationMessage instances inside a >> ValidationResult). If validation fails the user is shown the text >> out of the ValidationMessage feedback, otherwise the form would >> submit as per usual. This validation may happen at a number of times >> (during form submission, when focus is lost, as a key is typed, >> etc). The nice thing about this approach is that the Validator can >> be a part of the domain model, the presentation model, or a separate >> thing altogether. >> * The JSR-303 approach which uses annotations to indicate the rules >> applicable to each field. These annotations are on the domain model, >> and therefore assumes that the form is directly tied to a domain >> object (which may not always be correct). I think the JSR-303 API is >> too complex for what is needed in JavaFX, but a similar >> implementation could be developed with a simpler API that follows >> this approach. >> * For lack of a better reference point, the FXForm approach [3] which >> encapsulates the validation inside a Form object that can be placed >> in the scene. I know this isn't explicitly (in the case of FXForm) >> about validation, but I think it is another approach to consider. >> >> So, what does JavaFX need out of a validation framework? It's really >> five things (I think): >> >> 1. A way for developers to validate a form by providing some means of >> specifying rules, as well as a way to specify when it runs, how it >> is visually represented, etc. >> 2. A way for the validation to impact upon the visual state of the form >> (using consistent CSS pseudoclass states / style classes, as well as >> by showing custom overlays, error messages beside the component (or >> grouped together at the top of the form)). There must be API to >> specify all of this. >> 3. Convenient API to simplify the validation process [3] (e.g. >> isEmpty(String), isAlphanumeric(String), etc, etc, etc). >> 4. An API that does not require it be integrated with UI controls. >> Doing so would prevent 3rd party UI controls to be able to be >> validated without also implementing the API, which may prove >> burdensome. Instead, the validation API should be separate. >> 5. A means to integrate nicely with the bindings and properties API >> present in JavaFX today. >> >> Of the three approaches above, my personal preference is to follow the >> JGoodies approach as I think it is the most powerful and flexible. >> However, nothing is set in stone and I want to learn what others think. >> >> Note that at present this research does not extend to considering >> whether there should be API related to automatically generating a form >> from a (JavaFX) bean (and making use of the validation API to ensure the >> input is correct). However, I am not against discussing this topic as >> well, as long as it too integrates nicely with the rules above, as well >> as the validation API itself, obviously. This research may full into >> requirement three above. >> >> [1] http://www.jgoodies.com/freeware/libraries/validation/ >> [2] https://github.com/dooApp/FXForm2 >> [3] >> http://www.jarvana.com/jarvana/view/com/jgoodies/validation/2.0.1/validation-2.0.1-javadoc.jar!/com/jgoodies/validation/util/ValidationUtils.html >> >> Thanks, >> -- Jonathan >> >> From jonathan.giles at oracle.com Mon Jun 11 02:02:01 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 11 Jun 2012 21:02:01 +1200 Subject: JIRA down? In-Reply-To: References: <129145.7942.26881-16395-573353230-1339361145@seznam.cz> Message-ID: <4FD5B409.9020303@oracle.com> The issue was escalated today, and will be dealt with as soon as possible. -- Jonathan On 11/06/2012 8:56 p.m., Sven Reimers wrote: > I still see that same problem - any updates? > > -Sven > > On Sun, Jun 10, 2012 at 10:45 PM, wrote: >> Hi, >> >> is JIRA down? >> >> JIRA Startup Failed >> You cannot access JIRA at present. Look at the table below to identify the reasons >> >> Description >> The jira.home directory '/issues/jira-42' is already locked. Please see the JIRA documentation for more information on locked jira.home directories. >> >> This is what I was welcomed with when I wanted to check something. >> >> Regards, Jiri > > From jonathan.giles at oracle.com Mon Jun 11 02:04:01 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 11 Jun 2012 21:04:01 +1200 Subject: JavaFX Form Validation In-Reply-To: <4FD5B211.7090805@bestsolution.at> References: <4FD5332A.5080608@oracle.com> <4FD59A89.80703@tbee.org> <4FD59C8F.6090903@bestsolution.at> <4FD59FBF.9020204@tbee.org> <4FD5B211.7090805@bestsolution.at> Message-ID: <4FD5B481.8010003@oracle.com> On 11/06/2012 8:53 p.m., Tom Schindl wrote: > So while I understand that having a standard validation system I'd like > to see resources invested in: > a) A validation visualization API at the control level > b) Implementing Controls > I would too :-) By the way, we're always on the lookout for talent resources, I mean, individuals. -- Jonathan From hjohn at xs4all.nl Mon Jun 11 02:14:35 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Mon, 11 Jun 2012 11:14:35 +0200 Subject: JavaFX Form Validation In-Reply-To: <4FD5B2DF.8020801@oracle.com> References: <4FD5332A.5080608@oracle.com> <4FD59A89.80703@tbee.org> <4FD59C8F.6090903@bestsolution.at> <4FD5B2DF.8020801@oracle.com> Message-ID: <4FD5B6FB.90604@xs4all.nl> I do tend to agree with Tom, JavaFX should provide the means for tight integration of *a* Validation system, but it doesn't necessarily have to provide one out of the box (although it could of course). I do think however that any validation framework offered by JavaFX should be re-usable outside its scope without the use of Platform.runLater() calls everywhere, otherwise you will end up with complex applications that need two different frameworks because one of them is tied to the UI part of JavaFX and cannot be re-used for input coming from different sources. --John On 11/06/2012 10:57, Jonathan Giles wrote: > Tom, > > It is perfectly valid to argue against adding more API to JavaFX. Heck > - the less I have to maintain the happier I am, so I'm (nearly) on > your side! :-) > > I don't have a compelling argument for including validation support in > JavaFX, however I think the best argument I have is that it is likely > to be something required by the vast majority of developers. Just > having support for showing validation results seems to me to be a > little too low-level given the assumed needs of most developers (in my > very humble and gut-feeling opinion). > > I also think that it is likely that by being part of the core JavaFX > API it would allow for validation support to be baked in at a lower > level (in particular better UI styling in the case of validation > failures). > > -- Jonathan > > > On 11/06/2012 7:21 p.m., Tom Schindl wrote: >> Hi, >> >> I don't think it is the task of JavaFX to provide a validation system. >> >> All it needs to provide is an API on the controls to show validation >> results. >> >> Tom >> >> Am 11.06.12 09:13, schrieb Tom Eugelink: >>> Hi all, >>> >>> Ah, a topic that is close to my heart. Personally I'm big on reuse, so >>> initially approach 1 seems to come closest. However I'm even a bigger >>> fan of clear separation, and having a form validation in a domain model >>> is debatable. Here is my brain dump; >>> >>> Normally, one would split out the validation activity around a form in >>> multiple parts; >>> 1. simple validation; usually these kinds of validation are implemented >>> directly on the setter, like "age>= 0" and can be displayed immediately >>> after the field is exited / committed. Normally one would use a >>> IllegalArgumentException in the setter to enforce it, contrarily to >>> annotations on the setter, an IAE is enforced always and requires no >>> reflection on the UI side. However the current bindings do not allow >>> proper handling of this (see my blog post of a year back). >>> >>> 2. grouped validation; these are validations between fields, things >>> like >>> "before< after". You could do this in the setters, but that usually >>> creates entry issues. So this needs to be in some kind of post setter >>> validation call on the entity, probably on submit of the form. >>> >>> 3. general on submit form level validations, the mandatory fields fall >>> into this category. You could try to merge this with grouped >>> validation. >>> >>> 3. But not all forms are directly bound to entities, for example a >>> wizard collects all kinds of information and usually only in the end >>> are >>> entities involved. These forms usually are backed by a backing class, >>> which basically has the same validations features as entities, only do >>> not reside in the domain model. >>> >>> 4. 99% of all the validations would fall in the contexts above, but >>> there is always that form specific thing. So a form internal validation >>> is required as well. >>> >>> 5. Lastly grouping and enabling. You can use forms in different >>> contexts, e.g. editing an entity or a template (which is then used to >>> easy create new entities). Such a template probably has a lot of >>> constraints disabled. So it would be good to be able to partially >>> disabled groups of constraints for a form. >>> >>> Summary: >>> - per field direct validation >>> - on submit validations >>> - both in directly in the entity or on backing classes (or a >>> combination) >>> - form internal validation >>> - grouping and enabling >>> >>> Personally I would go for an approach where a validator can be >>> registered to any control or container. There could be an easy >>> reflection based implementation which is parallel to the binding; so if >>> you bind the control to an property on an entity, a validation also is >>> set that looks at the annotations of that property, maybe even >>> automatically. A form can be bound to an form validator. But it is >>> always possible to create ones own validator and override the behavior. >>> Since we need something of a "form" class anyhow, the context of the >>> validation (what is enabled and what not) should be set there. A >>> validator can be be assigned one or more group ids, and call for >>> validation gets the form as a parameter, implicitely giving it >>> access to >>> the validation context, so it can check if it is enabled or not. >>> >>> Makes the above any sense? >>> >>> Your 5 summary points are perfect. How to visualize, external to the >>> controls, join up with binding. Yup. >>> >>> Tom >>> >>> >>> On 2012-06-11 01:52, Jonathan Giles wrote: >>>> Hi all, >>>> >>>> I'm currently in the very, very early stages of developing a >>>> validation API for future inclusion into JavaFX. I thought rather than >>>> get too far into the research and development of a proof of concept, I >>>> would see what you all think. Any feedback now would be very useful. >>>> >>>> Essentially, there are a few common styles related to form validation. >>>> Some of the more likely approaches include: >>>> >>>> * The 'JGoodies Validation framework' [1] approach, where the >>>> developer provides a Validator that will then run over the form >>>> and >>>> gather feedback to return to the user (for example, it would test >>>> that the 'name field' is not empty, and that the email address >>>> is of >>>> the correct style - if either of these rules are invalid, the >>>> Validator would return ValidationMessage instances inside a >>>> ValidationResult). If validation fails the user is shown the text >>>> out of the ValidationMessage feedback, otherwise the form would >>>> submit as per usual. This validation may happen at a number of >>>> times >>>> (during form submission, when focus is lost, as a key is typed, >>>> etc). The nice thing about this approach is that the Validator can >>>> be a part of the domain model, the presentation model, or a >>>> separate >>>> thing altogether. >>>> * The JSR-303 approach which uses annotations to indicate the rules >>>> applicable to each field. These annotations are on the domain >>>> model, >>>> and therefore assumes that the form is directly tied to a domain >>>> object (which may not always be correct). I think the JSR-303 >>>> API is >>>> too complex for what is needed in JavaFX, but a similar >>>> implementation could be developed with a simpler API that follows >>>> this approach. >>>> * For lack of a better reference point, the FXForm approach [3] >>>> which >>>> encapsulates the validation inside a Form object that can be >>>> placed >>>> in the scene. I know this isn't explicitly (in the case of FXForm) >>>> about validation, but I think it is another approach to consider. >>>> >>>> So, what does JavaFX need out of a validation framework? It's really >>>> five things (I think): >>>> >>>> 1. A way for developers to validate a form by providing some means of >>>> specifying rules, as well as a way to specify when it runs, how it >>>> is visually represented, etc. >>>> 2. A way for the validation to impact upon the visual state of the >>>> form >>>> (using consistent CSS pseudoclass states / style classes, as >>>> well as >>>> by showing custom overlays, error messages beside the component >>>> (or >>>> grouped together at the top of the form)). There must be API to >>>> specify all of this. >>>> 3. Convenient API to simplify the validation process [3] (e.g. >>>> isEmpty(String), isAlphanumeric(String), etc, etc, etc). >>>> 4. An API that does not require it be integrated with UI controls. >>>> Doing so would prevent 3rd party UI controls to be able to be >>>> validated without also implementing the API, which may prove >>>> burdensome. Instead, the validation API should be separate. >>>> 5. A means to integrate nicely with the bindings and properties API >>>> present in JavaFX today. >>>> >>>> Of the three approaches above, my personal preference is to follow the >>>> JGoodies approach as I think it is the most powerful and flexible. >>>> However, nothing is set in stone and I want to learn what others >>>> think. >>>> >>>> Note that at present this research does not extend to considering >>>> whether there should be API related to automatically generating a form >>>> from a (JavaFX) bean (and making use of the validation API to ensure >>>> the input is correct). However, I am not against discussing this topic >>>> as well, as long as it too integrates nicely with the rules above, as >>>> well as the validation API itself, obviously. This research may full >>>> into requirement three above. >>>> >>>> [1] http://www.jgoodies.com/freeware/libraries/validation/ >>>> [2] https://github.com/dooApp/FXForm2 >>>> [3] >>>> http://www.jarvana.com/jarvana/view/com/jgoodies/validation/2.0.1/validation-2.0.1-javadoc.jar!/com/jgoodies/validation/util/ValidationUtils.html >>>> >>>> >>>> >>>> Thanks, >>>> -- Jonathan >>>> >> > From fbrunnerlist at gmx.ch Mon Jun 11 02:15:17 2012 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Mon, 11 Jun 2012 11:15:17 +0200 Subject: JavaFX Form Validation In-Reply-To: <4FD5B3D9.7000508@oracle.com> References: <4FD5332A.5080608@oracle.com> <201206111047.14489.fbrunnerlist@gmx.ch> <4FD5B3D9.7000508@oracle.com> Message-ID: <201206111115.17895.fbrunnerlist@gmx.ch> Hi Jonathan, From: https://blogs.oracle.com/theaquarium/entry/beanvalidation_1_1_is_now --------------------------------------- JBoss' Emmanuel Bernard has submitted Bean Validation 1.1 as JSR 349. This version should be part of Java EE 7 and an important goal for this release is further integration with other platform JSRs. In addition to JSF and JPA, integrations with JAX-RS, JAXB, CDI and EJB are also considered. Other important evolutions include a potential API to validate parameters and return values of method calls as well as another API to declare constraints (as opposed to annotations today). The JSR page and this earlier blog post have more details. Note that the current Bean Validation API can also very much be used with JavaSE. Ballot results for this JSR are due on July 25th, 2011. --------------------------------------- Bean Validation is currently developed under JSR 349. The goal seems to be among others a better integration with JSF (which is also a GUI technology) and Java SE. Thus I think JavaFX should be considered as well. Regards, Florian Am Montag 11 Juni 2012, 11:01:13 schrieb Jonathan Giles: > Florian, > > My understanding of JSR-303 is that it is well past the stages of being > active. According to [1], it starting in July 2006, and produced its > final release (along with final API) in November of 2009. > > Also, from my understanding of JSR-303, it appears to be more focused on > the Java EE needs of a container such as Hibernate (one component of > which is the reference implementation of JSR-303). I would imagine that > this would lead to it being far more complex than is necessary in a > JavaFX API. > > However, I am not ruling it out, but I just worry that it may be > ill-fitting for JavaFX. I would be totally happy to be proven wrong, and > will look into it more tomorrow to be sure. > > [1] http://jcp.org/en/jsr/detail?id=303 > > -- Jonathan > > > On 11/06/2012 8:47 p.m., Florian Brunner wrote: > > Hi, > > > > I haven't worked with JSR-303, yet, but I would appreciate if the Java community could come up with a validation framework which can be used consistently on various layers. > > > > If JSR-303 currently doesn't fit the needs of JavaFX, maybe the JavaFX team could get involved in JSR-303 to make sure it fits the needs of JavaFX as well? > > > > Regards, > > Florian > > > > Am Montag 11 Juni 2012, 01:52:10 schrieb Jonathan Giles: > >> Hi all, > >> > >> I'm currently in the very, very early stages of developing a validation > >> API for future inclusion into JavaFX. I thought rather than get too far > >> into the research and development of a proof of concept, I would see > >> what you all think. Any feedback now would be very useful. > >> > >> Essentially, there are a few common styles related to form validation. > >> Some of the more likely approaches include: > >> > >> * The 'JGoodies Validation framework' [1] approach, where the > >> developer provides a Validator that will then run over the form and > >> gather feedback to return to the user (for example, it would test > >> that the 'name field' is not empty, and that the email address is of > >> the correct style - if either of these rules are invalid, the > >> Validator would return ValidationMessage instances inside a > >> ValidationResult). If validation fails the user is shown the text > >> out of the ValidationMessage feedback, otherwise the form would > >> submit as per usual. This validation may happen at a number of times > >> (during form submission, when focus is lost, as a key is typed, > >> etc). The nice thing about this approach is that the Validator can > >> be a part of the domain model, the presentation model, or a separate > >> thing altogether. > >> * The JSR-303 approach which uses annotations to indicate the rules > >> applicable to each field. These annotations are on the domain model, > >> and therefore assumes that the form is directly tied to a domain > >> object (which may not always be correct). I think the JSR-303 API is > >> too complex for what is needed in JavaFX, but a similar > >> implementation could be developed with a simpler API that follows > >> this approach. > >> * For lack of a better reference point, the FXForm approach [3] which > >> encapsulates the validation inside a Form object that can be placed > >> in the scene. I know this isn't explicitly (in the case of FXForm) > >> about validation, but I think it is another approach to consider. > >> > >> So, what does JavaFX need out of a validation framework? It's really > >> five things (I think): > >> > >> 1. A way for developers to validate a form by providing some means of > >> specifying rules, as well as a way to specify when it runs, how it > >> is visually represented, etc. > >> 2. A way for the validation to impact upon the visual state of the form > >> (using consistent CSS pseudoclass states / style classes, as well as > >> by showing custom overlays, error messages beside the component (or > >> grouped together at the top of the form)). There must be API to > >> specify all of this. > >> 3. Convenient API to simplify the validation process [3] (e.g. > >> isEmpty(String), isAlphanumeric(String), etc, etc, etc). > >> 4. An API that does not require it be integrated with UI controls. > >> Doing so would prevent 3rd party UI controls to be able to be > >> validated without also implementing the API, which may prove > >> burdensome. Instead, the validation API should be separate. > >> 5. A means to integrate nicely with the bindings and properties API > >> present in JavaFX today. > >> > >> Of the three approaches above, my personal preference is to follow the > >> JGoodies approach as I think it is the most powerful and flexible. > >> However, nothing is set in stone and I want to learn what others think. > >> > >> Note that at present this research does not extend to considering > >> whether there should be API related to automatically generating a form > >> from a (JavaFX) bean (and making use of the validation API to ensure the > >> input is correct). However, I am not against discussing this topic as > >> well, as long as it too integrates nicely with the rules above, as well > >> as the validation API itself, obviously. This research may full into > >> requirement three above. > >> > >> [1] http://www.jgoodies.com/freeware/libraries/validation/ > >> [2] https://github.com/dooApp/FXForm2 > >> [3] > >> http://www.jarvana.com/jarvana/view/com/jgoodies/validation/2.0.1/validation-2.0.1-javadoc.jar!/com/jgoodies/validation/util/ValidationUtils.html > >> > >> Thanks, > >> -- Jonathan > >> > >> > From han.solo at muenster.de Mon Jun 11 02:22:36 2012 From: han.solo at muenster.de (Gerrit Grunwald) Date: Mon, 11 Jun 2012 11:22:36 +0200 Subject: JavaFX Form Validation In-Reply-To: <4FD59C8F.6090903@bestsolution.at> References: <4FD5332A.5080608@oracle.com> <4FD59A89.80703@tbee.org> <4FD59C8F.6090903@bestsolution.at> Message-ID: Hi there, I agree to Tom Schindl. We for example have a validation system in place (and i guess many others have too) and i've simply added methods to validate/invalidate controls. This is a very general approach that makes it possible to use different validation systems. But i also agree that it would be nice to have a validation system that comes with JavaFX in case you don't have one but it should not be bound to the controls. Just my 2 cents... Cheers, Gerrit Am 11.06.2012 um 09:21 schrieb Tom Schindl: > Hi, > > I don't think it is the task of JavaFX to provide a validation system. > > All it needs to provide is an API on the controls to show validation > results. > > Tom > > Am 11.06.12 09:13, schrieb Tom Eugelink: >> Hi all, >> >> Ah, a topic that is close to my heart. Personally I'm big on reuse, so >> initially approach 1 seems to come closest. However I'm even a bigger >> fan of clear separation, and having a form validation in a domain model >> is debatable. Here is my brain dump; >> >> Normally, one would split out the validation activity around a form in >> multiple parts; >> 1. simple validation; usually these kinds of validation are implemented >> directly on the setter, like "age >= 0" and can be displayed immediately >> after the field is exited / committed. Normally one would use a >> IllegalArgumentException in the setter to enforce it, contrarily to >> annotations on the setter, an IAE is enforced always and requires no >> reflection on the UI side. However the current bindings do not allow >> proper handling of this (see my blog post of a year back). >> >> 2. grouped validation; these are validations between fields, things like >> "before < after". You could do this in the setters, but that usually >> creates entry issues. So this needs to be in some kind of post setter >> validation call on the entity, probably on submit of the form. >> >> 3. general on submit form level validations, the mandatory fields fall >> into this category. You could try to merge this with grouped validation. >> >> 3. But not all forms are directly bound to entities, for example a >> wizard collects all kinds of information and usually only in the end are >> entities involved. These forms usually are backed by a backing class, >> which basically has the same validations features as entities, only do >> not reside in the domain model. >> >> 4. 99% of all the validations would fall in the contexts above, but >> there is always that form specific thing. So a form internal validation >> is required as well. >> >> 5. Lastly grouping and enabling. You can use forms in different >> contexts, e.g. editing an entity or a template (which is then used to >> easy create new entities). Such a template probably has a lot of >> constraints disabled. So it would be good to be able to partially >> disabled groups of constraints for a form. >> >> Summary: >> - per field direct validation >> - on submit validations >> - both in directly in the entity or on backing classes (or a combination) >> - form internal validation >> - grouping and enabling >> >> Personally I would go for an approach where a validator can be >> registered to any control or container. There could be an easy >> reflection based implementation which is parallel to the binding; so if >> you bind the control to an property on an entity, a validation also is >> set that looks at the annotations of that property, maybe even >> automatically. A form can be bound to an form validator. But it is >> always possible to create ones own validator and override the behavior. >> Since we need something of a "form" class anyhow, the context of the >> validation (what is enabled and what not) should be set there. A >> validator can be be assigned one or more group ids, and call for >> validation gets the form as a parameter, implicitely giving it access to >> the validation context, so it can check if it is enabled or not. >> >> Makes the above any sense? >> >> Your 5 summary points are perfect. How to visualize, external to the >> controls, join up with binding. Yup. >> >> Tom >> >> >> On 2012-06-11 01:52, Jonathan Giles wrote: >>> Hi all, >>> >>> I'm currently in the very, very early stages of developing a >>> validation API for future inclusion into JavaFX. I thought rather than >>> get too far into the research and development of a proof of concept, I >>> would see what you all think. Any feedback now would be very useful. >>> >>> Essentially, there are a few common styles related to form validation. >>> Some of the more likely approaches include: >>> >>> * The 'JGoodies Validation framework' [1] approach, where the >>> developer provides a Validator that will then run over the form and >>> gather feedback to return to the user (for example, it would test >>> that the 'name field' is not empty, and that the email address is of >>> the correct style - if either of these rules are invalid, the >>> Validator would return ValidationMessage instances inside a >>> ValidationResult). If validation fails the user is shown the text >>> out of the ValidationMessage feedback, otherwise the form would >>> submit as per usual. This validation may happen at a number of times >>> (during form submission, when focus is lost, as a key is typed, >>> etc). The nice thing about this approach is that the Validator can >>> be a part of the domain model, the presentation model, or a separate >>> thing altogether. >>> * The JSR-303 approach which uses annotations to indicate the rules >>> applicable to each field. These annotations are on the domain model, >>> and therefore assumes that the form is directly tied to a domain >>> object (which may not always be correct). I think the JSR-303 API is >>> too complex for what is needed in JavaFX, but a similar >>> implementation could be developed with a simpler API that follows >>> this approach. >>> * For lack of a better reference point, the FXForm approach [3] which >>> encapsulates the validation inside a Form object that can be placed >>> in the scene. I know this isn't explicitly (in the case of FXForm) >>> about validation, but I think it is another approach to consider. >>> >>> So, what does JavaFX need out of a validation framework? It's really >>> five things (I think): >>> >>> 1. A way for developers to validate a form by providing some means of >>> specifying rules, as well as a way to specify when it runs, how it >>> is visually represented, etc. >>> 2. A way for the validation to impact upon the visual state of the form >>> (using consistent CSS pseudoclass states / style classes, as well as >>> by showing custom overlays, error messages beside the component (or >>> grouped together at the top of the form)). There must be API to >>> specify all of this. >>> 3. Convenient API to simplify the validation process [3] (e.g. >>> isEmpty(String), isAlphanumeric(String), etc, etc, etc). >>> 4. An API that does not require it be integrated with UI controls. >>> Doing so would prevent 3rd party UI controls to be able to be >>> validated without also implementing the API, which may prove >>> burdensome. Instead, the validation API should be separate. >>> 5. A means to integrate nicely with the bindings and properties API >>> present in JavaFX today. >>> >>> Of the three approaches above, my personal preference is to follow the >>> JGoodies approach as I think it is the most powerful and flexible. >>> However, nothing is set in stone and I want to learn what others think. >>> >>> Note that at present this research does not extend to considering >>> whether there should be API related to automatically generating a form >>> from a (JavaFX) bean (and making use of the validation API to ensure >>> the input is correct). However, I am not against discussing this topic >>> as well, as long as it too integrates nicely with the rules above, as >>> well as the validation API itself, obviously. This research may full >>> into requirement three above. >>> >>> [1] http://www.jgoodies.com/freeware/libraries/validation/ >>> [2] https://github.com/dooApp/FXForm2 >>> [3] >>> http://www.jarvana.com/jarvana/view/com/jgoodies/validation/2.0.1/validation-2.0.1-javadoc.jar!/com/jgoodies/validation/util/ValidationUtils.html >>> >>> >>> Thanks, >>> -- Jonathan >>> >> > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From tbee at tbee.org Mon Jun 11 02:45:02 2012 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 11 Jun 2012 11:45:02 +0200 Subject: JavaFX Form Validation In-Reply-To: <4FD5AFCA.2080308@oracle.com> References: <4FD5332A.5080608@oracle.com> <4FD59A89.80703@tbee.org> <4FD5AFCA.2080308@oracle.com> Message-ID: <4FD5BE1E.70500@tbee.org> On 2012-06-11 10:43, Jonathan Giles wrote: > Thanks Tom for your response. I'm going to approach this email as an advocate for my preferred approach - the JGoodies validation approach. This does not mean that my preferred approach is right, so feel free to disagree! Since I'm using JGoodies binding all over my Swing apps, I'm not going to be sad about that. :-) Although my opinion sometimes slightly deviates from Karsten's (author of JGoodies), I usually skip his presentation model and work directly on entities, it most definitely is a well thought through approach. Ya can't go very wrong. > > http://www.jgoodies.com/download/presentations/validation.pdf Good PDF! Not enough time right now to read it with enough dedication. > > In JavaFX setters are final methods, and putting any logic into them (when a property exists) is fundamentally flawed as the setter logic is not guaranteed to be executed (e.g. setFoo(bar) is the same as fooProperty().set(bar), and this completely bypasses the setter logic). The obvious response to this is to put the validation logic in the property set method. Unfortunately, in this case, it is too late - the value has already been set (and events fired). Yeah, I know. That's all not so very good, especially when migrating an existing BM to use JFX. There really should be a decent hook into this binding and setter thing. But let's not mix stuff up. > Therefore, I would imagine that without support for vetoing property changes, this is a non-starter. I would think that a better approach is to use the JGoodies approach of providing a Validator, and simply configuring when the validation should occur to suit the needs of the application. Well, setters in the end still can throw exceptions, and these should / could be handled. Why not as as validation errors? > >> >> 4. 99% of all the validations would fall in the contexts above, but there is always that form specific thing. So a form internal validation is required as well. > Can you expand here? Up until now I had mentioned validation directly on the entity and as part of the process (wizard). Assume these two are running remotely, and all of a sudden the connection drops. Then the form itself would require a "ConnectionAliveValidator" to nicely handle that situation. Yes, this can be handled out side of the validation, since formally it may not be validation. But IF you have a validation functionality available, with all the nice error showing and CSS and happy users, make life easy by reusing it to the max. You get nice representation and maybe logging and stuff. Come to think of it; manually adding validation messages as part of the business process is also such a point. But I've seen that in the PDF I think. >> >> 5. Lastly grouping and enabling. You can use forms in different contexts, e.g. editing an entity or a template (which is then used to easy create new entities). Such a template probably has a lot of constraints disabled. So it would be good to be able to partially disabled groups of constraints for a form. > In the JGoodies sense, this is completely in the control of the developer - they are the ones creating the Validator, and they can control what tests are run as part of it. True, but it may be convenient to help them a bit. Sure, it's not that hard to do it yourself; set some variable that indicates a validation context and have the validates check them. But again, Swing Framework, let's create a Form class that has a little bit of administration to assist here. http://www.jroller.com/eyallupu/entry/jsr_303_beans_validation_using >> > I'm not sure we've quite crossed the bridge regarding needing 'something of a form class anyhow'. To me, so far anyway, there is no clear requirement for a Form class. Can you expand on what this would provide? See above. My gut tells me that having the concept of a form (like in HTML) can be very beneficial. It is the natural way to look at a screen; groups of controls. Again, is it required? No, and one could do it yourself, but the concept that a number of button all trigger a submit on the same a form and the form holds the validations over the current set of controls just makes sense and a message renderer can be bound to the form to show them. Swing Framework also added it I believe. I probably need some thinking time to come up with an irrefutable argument. But with the validation you're stepping a level up from simple controls. Now relations between controls become important. > > In fact, I'm not sure we even need to register a Validator on a control or container. Instead, a Validator could be initiated by a developer as part of their usual form submission code (e.g. an action event on a Button). Again, is there a compelling reason that I am missing? No and yes. Hm, I'm not able to put the finger on it. Ask you self the question: if a new JFX would need to create form level validations and checks, where should he put them and how are they visualized? Should we let him invent the wheel or help? If you would place controls in a form (which is something different from layout), then there is a place to collect the messages. Tom From goddard at seznam.cz Mon Jun 11 03:48:42 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Mon, 11 Jun 2012 12:48:42 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Property=20updates?= In-Reply-To: <129148.7942.26881-16840-356981267-1339361616@seznam.cz> Message-ID: <129188.7774.26775-21151-491445893-1339411722@seznam.cz> This is the output from the println statements: centerXDoubleProperty [bean: Circle at 157a5c3, name: centerX, value: 396.34924225837125] x: DoubleProperty [value: 396.34924225837125] centerXDoubleProperty [bean: Circle at 157a5c3, name: centerX, value: 396.34924225837125] x: DoubleProperty [value: 563.9584002793741] centerXDoubleProperty [bean: Circle at 157a5c3, name: centerX, value: 396.34924225837125] x: DoubleProperty [value: 337.0834495091644] As you can see, the centerX value doesn't change at all. Any help is appreciated. Regards, jiri ------------ P?vodn? zpr?va ------------ Od: P?edm?t: Property updates Datum: 10.6.2012 22:54:59 ---------------------------------------- Hello, the following code should create a Circle at random coords and animate the translation to random coords. The point is to randomly translate the circle from one location to another successively: package boyle; import javafx.animation.KeyFrame; import javafx.animation.KeyValue; import javafx.animation.Timeline; import javafx.animation.TimelineBuilder; import javafx.application.Application; import javafx.beans.property.DoubleProperty; import javafx.beans.property.SimpleDoubleProperty; import javafx.event.ActionEvent; import javafx.event.EventHandler; import javafx.scene.Group; import javafx.scene.Scene; import javafx.scene.paint.Color; import javafx.scene.shape.Circle; import javafx.scene.shape.CircleBuilder; import javafx.stage.Stage; import javafx.util.Duration; /** * * @author jiri */ public class Boyle extends Application { public static final int WIDTH = 800; public static final int HEIGHT = 512; /** * @param args the command line arguments */ public static void main(String[] args) { launch(args); } // end the animation at random coords private DoubleProperty x = new SimpleDoubleProperty(Math.random() * WIDTH); private DoubleProperty y = new SimpleDoubleProperty(Math.random() * HEIGHT); @Override public void start(Stage primaryStage) { final Circle c = CircleBuilder.create() // start the animation at random coords .centerX(Math.random() * WIDTH) .centerY(Math.random() * HEIGHT) .radius(15).fill(Color.BLACK) .build(); final DoubleProperty[] randCoords = {x, y}; final Timeline t = TimelineBuilder.create() .keyFrames(new KeyFrame(Duration.seconds(5), new KeyValue(c.centerXProperty(), randCoords[0].get()), new KeyValue(c.centerYProperty(), randCoords[1].get()))) .build(); // refreshes coords at every end of the animation t.setOnFinished(new EventHandler() { @Override public void handle(ActionEvent ae) { System.out.println("centerX"+ c.centerXProperty()); // set animation end coords to the target c.centerXProperty().set(randCoords[0].get()); c.centerYProperty().set(randCoords[1].get()); System.out.println("x: "+ randCoords[0]); // generate new coords for the animation end randCoords[0].set(Math.random() * WIDTH); randCoords[1].set(Math.random() * HEIGHT); t.play(); } }); t.play(); Group root = new Group(); root.getChildren().add(c); Scene scene = new Scene(root, WIDTH, HEIGHT); primaryStage.setTitle("@javafxcz - Boyle - www.dredwerkz.cz"); primaryStage.setScene(scene); primaryStage.show(); } } However, the circle appears moving to its target coords instead to its end coords, and update of the target coords doesn't work - unlike for the end coords. Plus, there's a significant 1-2 seconds long pause before the animation starts again in the handler, but just for the first time. Then it runs smoothly. Help in form of explanation / code sample is appreciated. Regards, Jiri From randahl at rockit.dk Mon Jun 11 04:08:25 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Mon, 11 Jun 2012 13:08:25 +0200 Subject: JavaFX Form Validation In-Reply-To: <4FD5D12C.6060400@rockit.dk> References: <4FD5D12C.6060400@rockit.dk> Message-ID: <4FD5D1A9.50501@rockit.dk> Hi Jonathan Thanks for starting an open debate on this. I have a number of additional points for the validation API wish-list: 1. Decoupling from internationalization mechanism: Other validation API's (like the one found in JSF 1.x) require developers to use property files for the validation messages gathered. This is a bad choice, since some organizations store their internationalized messages in central systems, in which message spelling errors can be fixed without rebuilding the app. Solution: Ensure that the application - not JavaFX - decides where messages come from - it is fine to support the use of property files, but such use should never be a requirement. A sound design will provide an pluggable mechanism for retrieving message resources, and deliver a default mechanism which supports property files, which can be replaced if needed. 2. Support for validation dependencies (ordering): If a UI has 2 input fields A and B, it is sometimes the case, that it makes no sense to run B's validator before A has been edited by the user to a valid state. One such example is, if B is only a required field for some values of A. It is a really annoying/confusing user experience to enter just a single character into the A field only to see all other fields of the UI turn invalid (in this case B). Instead, allow dependencies so developers can express that the validation of B does not start before the validation of A is valid. This way, the UI will tell the user that A is invalid and needs to be edited, and only after A has been edited to a valid state, will the UI tell the user that now B has to be edited. Apart from the improved user experience, this is also a much less resource intensive approach to validation (recall that in some cases validation may require network communication, etc.). 3. Support group validation: One of the areas where the JSF 1.x validation framework failed miserably, was the lack of multiple field validation. Say a user enters a date interval using two fields called Start and End, and the requirement is that the End date has to be later than the Start date. The problem with JSF 1.x validation was, each validator was always tied to a particular field, not multiple fields or the form as a whole, so there was no way that the Start field's validator could check if the value was earlier than the End value. As an application developer, you do not want to define both that Start comes before End and that End comes after Start, you want to define just one thing: Start < End. So ideally, you should be able to write validator, which look at a number of fields, where looking at a single field (as some validators do) is just a simple case of "a number of fields". 4. Support full plug-and-play reusability: Reusing a component in different applications requires not only the ability to reuse the visual component's presentation logic, but also the ability to reuse the validation logic and messages which applies to that particular component. Say I am developing and selling an EmailAddressField component for JavaFX. For that component to be valuable to other organisations, it has to include logic for validating e-mail adresses, and it has to include proper default messages such as "An e-mail address must contain exactly one @". JavaFX should allow me to provide this message in many different languages allong with the validation logic and share this alongside the component. Finally, from what I have seen of the JGoodies approach, it looks very procedural, and very programming intensive. I found this example online: |public ValidationResult validate() { ValidationResult result = new ValidationResult(); if (ValidationUtils.isEmpty(mUser.getUserName())) { result.addError("User name is required"); } if (ValidationUtils.isEmpty(mUser.getPassword())) { result.addError("Password is required"); } return result; }| Even though the validation logic to check for emptiness is reusable, the developer still has to write a lot of if-then logic. I would much rather want JavaFX to have an object oriented approach, allowing me to write something like TextField userNameTextField = new TextField(new UserNameValidator()); where the UserNameValidator class does all of the JGoodies stuff above for me and can easily be reused among different parts of my application. With this approach it is obvious that people will start sharing EmailAddressValidator, ConfigurablePasswordValidator, LicensePlateValidator, etc. Yours Randahl On 11/06/12 01.52, Jonathan Giles wrote: > Hi all, > > I'm currently in the very, very early stages of developing a > validation API for future inclusion into JavaFX. I thought rather than > get too far into the research and development of a proof of concept, I > would see what you all think. Any feedback now would be very useful. > > Essentially, there are a few common styles related to form validation. > Some of the more likely approaches include: > > * The 'JGoodies Validation framework' [1] approach, where the > developer provides a Validator that will then run over the form and > gather feedback to return to the user (for example, it would test > that the 'name field' is not empty, and that the email address is of > the correct style - if either of these rules are invalid, the > Validator would return ValidationMessage instances inside a > ValidationResult). If validation fails the user is shown the text > out of the ValidationMessage feedback, otherwise the form would > submit as per usual. This validation may happen at a number of times > (during form submission, when focus is lost, as a key is typed, > etc). The nice thing about this approach is that the Validator can > be a part of the domain model, the presentation model, or a separate > thing altogether. > * The JSR-303 approach which uses annotations to indicate the rules > applicable to each field. These annotations are on the domain model, > and therefore assumes that the form is directly tied to a domain > object (which may not always be correct). I think the JSR-303 API is > too complex for what is needed in JavaFX, but a similar > implementation could be developed with a simpler API that follows > this approach. > * For lack of a better reference point, the FXForm approach [3] which > encapsulates the validation inside a Form object that can be placed > in the scene. I know this isn't explicitly (in the case of FXForm) > about validation, but I think it is another approach to consider. > > So, what does JavaFX need out of a validation framework? It's really > five things (I think): > > 1. A way for developers to validate a form by providing some means of > specifying rules, as well as a way to specify when it runs, how it > is visually represented, etc. > 2. A way for the validation to impact upon the visual state of the form > (using consistent CSS pseudoclass states / style classes, as well as > by showing custom overlays, error messages beside the component (or > grouped together at the top of the form)). There must be API to > specify all of this. > 3. Convenient API to simplify the validation process [3] (e.g. > isEmpty(String), isAlphanumeric(String), etc, etc, etc). > 4. An API that does not require it be integrated with UI controls. > Doing so would prevent 3rd party UI controls to be able to be > validated without also implementing the API, which may prove > burdensome. Instead, the validation API should be separate. > 5. A means to integrate nicely with the bindings and properties API > present in JavaFX today. > > Of the three approaches above, my personal preference is to follow the > JGoodies approach as I think it is the most powerful and flexible. > However, nothing is set in stone and I want to learn what others think. > > Note that at present this research does not extend to considering > whether there should be API related to automatically generating a form > from a (JavaFX) bean (and making use of the validation API to ensure > the input is correct). However, I am not against discussing this topic > as well, as long as it too integrates nicely with the rules above, as > well as the validation API itself, obviously. This research may full > into requirement three above. > > [1] http://www.jgoodies.com/freeware/libraries/validation/ > [2] https://github.com/dooApp/FXForm2 > [3] > http://www.jarvana.com/jarvana/view/com/jgoodies/validation/2.0.1/validation-2.0.1-javadoc.jar!/com/jgoodies/validation/util/ValidationUtils.html > > Thanks, > -- Jonathan > From tbee at tbee.org Mon Jun 11 04:27:04 2012 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 11 Jun 2012 13:27:04 +0200 Subject: JavaFX Form Validation In-Reply-To: <4FD5D1A9.50501@rockit.dk> References: <4FD5D12C.6060400@rockit.dk> <4FD5D1A9.50501@rockit.dk> Message-ID: <4FD5D608.3090608@tbee.org> +1 on the style. I was thinking in the line of this: new TextField().validators(new MandatoryValidator(), new UserNameValidator()); Tom On 2012-06-11 13:08, Randahl Fink Isaksen wrote: > > > Finally, from what I have seen of the JGoodies approach, it looks very procedural, and very programming intensive. I found this example online: > > |public ValidationResult validate() { > ValidationResult result = new ValidationResult(); > if (ValidationUtils.isEmpty(mUser.getUserName())) { > result.addError("User name is required"); > } > if (ValidationUtils.isEmpty(mUser.getPassword())) { > result.addError("Password is required"); > } > return result; > }| > > > Even though the validation logic to check for emptiness is reusable, the developer still has to write a lot of if-then logic. I would much rather want JavaFX to have an object oriented approach, allowing me to write something like > > TextField userNameTextField = new TextField(new UserNameValidator()); > > where the UserNameValidator class does all of the JGoodies stuff above for me and can easily be reused among different parts of my application. With this approach it is obvious that people will start sharing EmailAddressValidator, ConfigurablePasswordValidator, LicensePlateValidator, etc. From greg.x.brown at oracle.com Mon Jun 11 04:28:59 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Mon, 11 Jun 2012 07:28:59 -0400 Subject: JavaFX Form Validation In-Reply-To: <4FD5D608.3090608@tbee.org> References: <4FD5D12C.6060400@rockit.dk> <4FD5D1A9.50501@rockit.dk> <4FD5D608.3090608@tbee.org> Message-ID: <863923E4-846D-4514-A773-19C9845556BF@oracle.com> In order to place nicely with FXML, the syntax should be more along the lines of: TextField textField = new TextField(); textField.getValidators().add(new MandatoryValidator()); textField.getValidators().add(new UserNameValidator()); That way, the equivalent markup could be declared as follows: However, I imagine the generated builder syntax might look similar to what is described below. G On Jun 11, 2012, at 7:27 AM, Tom Eugelink wrote: > +1 on the style. I was thinking in the line of this: > > new TextField().validators(new MandatoryValidator(), new UserNameValidator()); > > Tom > > > > > On 2012-06-11 13:08, Randahl Fink Isaksen wrote: >> >> >> Finally, from what I have seen of the JGoodies approach, it looks very procedural, and very programming intensive. I found this example online: >> >> |public ValidationResult validate() { >> ValidationResult result = new ValidationResult(); >> if (ValidationUtils.isEmpty(mUser.getUserName())) { >> result.addError("User name is required"); >> } >> if (ValidationUtils.isEmpty(mUser.getPassword())) { >> result.addError("Password is required"); >> } >> return result; >> }| >> >> >> Even though the validation logic to check for emptiness is reusable, the developer still has to write a lot of if-then logic. I would much rather want JavaFX to have an object oriented approach, allowing me to write something like >> >> TextField userNameTextField = new TextField(new UserNameValidator()); >> >> where the UserNameValidator class does all of the JGoodies stuff above for me and can easily be reused among different parts of my application. With this approach it is obvious that people will start sharing EmailAddressValidator, ConfigurablePasswordValidator, LicensePlateValidator, etc. > From randahl at rockit.dk Mon Jun 11 04:30:01 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Mon, 11 Jun 2012 13:30:01 +0200 Subject: JavaFX Form Validation In-Reply-To: <4FD5D608.3090608@tbee.org> References: <4FD5D12C.6060400@rockit.dk> <4FD5D1A9.50501@rockit.dk> <4FD5D608.3090608@tbee.org> Message-ID: <4FD5D6B9.7000803@rockit.dk> I like your idea Tom. But if it should look like the existing JavaFX API's, it will probably be more like myTextField.getValidators().addAll(new MandatoryValidator(), new UserNameValidator()); Randahl On 11/06/12 13.27, Tom Eugelink wrote: > +1 on the style. I was thinking in the line of this: > > new TextField().validators(new MandatoryValidator(), new > UserNameValidator()); > > Tom > > > > > On 2012-06-11 13:08, Randahl Fink Isaksen wrote: >> >> >> Finally, from what I have seen of the JGoodies approach, it looks >> very procedural, and very programming intensive. I found this example >> online: >> >> |public ValidationResult validate() { >> ValidationResult result = new ValidationResult(); >> if (ValidationUtils.isEmpty(mUser.getUserName())) { >> result.addError("User name is required"); >> } >> if (ValidationUtils.isEmpty(mUser.getPassword())) { >> result.addError("Password is required"); >> } >> return result; >> }| >> >> >> Even though the validation logic to check for emptiness is reusable, >> the developer still has to write a lot of if-then logic. I would much >> rather want JavaFX to have an object oriented approach, allowing me >> to write something like >> >> TextField userNameTextField = new TextField(new UserNameValidator()); >> >> where the UserNameValidator class does all of the JGoodies stuff >> above for me and can easily be reused among different parts of my >> application. With this approach it is obvious that people will start >> sharing EmailAddressValidator, ConfigurablePasswordValidator, >> LicensePlateValidator, etc. > From pavel.safrata at oracle.com Mon Jun 11 04:46:51 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 11 Jun 2012 13:46:51 +0200 Subject: Property updates In-Reply-To: <129188.7774.26775-21151-491445893-1339411722@seznam.cz> References: <129188.7774.26775-21151-491445893-1339411722@seznam.cz> Message-ID: <4FD5DAAB.1080805@oracle.com> Hello Jiri, the coordinates are updated during the animation, but always finish on the same value. It's because you create the timeline passing the current values of the x and y properties and then run it over and over without updating it, so it always finishes with the circle on the same coordinates (the first random values generated for x an y). The pause is caused by the fact that your code makes the second run of the timeline begin on the same place where it ends (so the animation runs and moves the circle about zero pixels). With regards, Pavel On 11.6.2012 12:48, goddard at seznam.cz wrote: > This is the output from the println statements: > centerXDoubleProperty [bean: Circle at 157a5c3, name: centerX, value: 396.34924225837125] > x: DoubleProperty [value: 396.34924225837125] > centerXDoubleProperty [bean: Circle at 157a5c3, name: centerX, value: 396.34924225837125] > x: DoubleProperty [value: 563.9584002793741] > centerXDoubleProperty [bean: Circle at 157a5c3, name: centerX, value: 396.34924225837125] > x: DoubleProperty [value: 337.0834495091644] > > As you can see, the centerX value doesn't change at all. Any help is appreciated. > > Regards, jiri > > ------------ P?vodn? zpr?va ------------ > Od: > P?edm?t: Property updates > Datum: 10.6.2012 22:54:59 > ---------------------------------------- > Hello, > > the following code should create a Circle at random coords and animate the > translation to random coords. The point is to randomly translate the circle from > one location to another successively: > > package boyle; > > import javafx.animation.KeyFrame; > import javafx.animation.KeyValue; > import javafx.animation.Timeline; > import javafx.animation.TimelineBuilder; > import javafx.application.Application; > import javafx.beans.property.DoubleProperty; > import javafx.beans.property.SimpleDoubleProperty; > import javafx.event.ActionEvent; > import javafx.event.EventHandler; > import javafx.scene.Group; > import javafx.scene.Scene; > import javafx.scene.paint.Color; > import javafx.scene.shape.Circle; > import javafx.scene.shape.CircleBuilder; > import javafx.stage.Stage; > import javafx.util.Duration; > > /** > * > * @author jiri > */ > public class Boyle extends Application { > > public static final int WIDTH = 800; > public static final int HEIGHT = 512; > > /** > * @param args the command line arguments > */ > public static void main(String[] args) { > launch(args); > } > > // end the animation at random coords > private DoubleProperty x = new SimpleDoubleProperty(Math.random() * WIDTH); > private DoubleProperty y = new SimpleDoubleProperty(Math.random() * > HEIGHT); > > @Override public void start(Stage primaryStage) { > final Circle c = CircleBuilder.create() > // start the animation at random coords > .centerX(Math.random() * WIDTH) > .centerY(Math.random() * HEIGHT) > .radius(15).fill(Color.BLACK) > .build(); > > final DoubleProperty[] randCoords = {x, y}; > > final Timeline t = TimelineBuilder.create() > .keyFrames(new KeyFrame(Duration.seconds(5), > new KeyValue(c.centerXProperty(), randCoords[0].get()), > new KeyValue(c.centerYProperty(), randCoords[1].get()))) > .build(); > > // refreshes coords at every end of the animation > t.setOnFinished(new EventHandler() { > > @Override > public void handle(ActionEvent ae) { > System.out.println("centerX"+ c.centerXProperty()); > // set animation end coords to the target > c.centerXProperty().set(randCoords[0].get()); > c.centerYProperty().set(randCoords[1].get()); > System.out.println("x: "+ randCoords[0]); > // generate new coords for the animation end > randCoords[0].set(Math.random() * WIDTH); > randCoords[1].set(Math.random() * HEIGHT); > t.play(); > } > }); > > t.play(); > > Group root = new Group(); > root.getChildren().add(c); > > Scene scene = new Scene(root, WIDTH, HEIGHT); > > primaryStage.setTitle("@javafxcz - Boyle - www.dredwerkz.cz"); > primaryStage.setScene(scene); > primaryStage.show(); > } > } > > However, the circle appears moving to its target coords instead to its end > coords, and update of the target coords doesn't work - unlike for the end > coords. Plus, there's a significant 1-2 seconds long pause before the animation > starts again in the handler, but just for the first time. Then it runs > smoothly. > Help in form of explanation / code sample is appreciated. > > Regards, Jiri > > From scekics at gmail.com Mon Jun 11 04:49:33 2012 From: scekics at gmail.com (Slavko Scekic) Date: Mon, 11 Jun 2012 13:49:33 +0200 Subject: JavaFX Form Validation In-Reply-To: <4FD5D1A9.50501@rockit.dk> References: <4FD5D12C.6060400@rockit.dk> <4FD5D1A9.50501@rockit.dk> Message-ID: I agree with everything Randahl said, especially the internationalization part. Also, if we're considering bean validation, we must take into account that sometimes forms can be backed by multiple beans (person and contact informations, for example). If I remember correctly, Daniel (Zonski) created some sort of validation framework based on JSR303 (namely Hibernate Validator), which is limited by having to choose only one bean per controller to validate. But, nevertheless, he started a good argument on the subject on the JFX OTN Discussion Forum. It would be good to have his input on this too. On Mon, Jun 11, 2012 at 1:08 PM, Randahl Fink Isaksen wrote: > Hi Jonathan > > Thanks for starting an open debate on this. I have a number of additional > points for the validation API wish-list: > > 1. Decoupling from internationalization mechanism: Other validation API's > (like the one found in JSF 1.x) require developers to use property files > for the validation messages gathered. This is a bad choice, since some > organizations store their internationalized messages in central systems, in > which message spelling errors can be fixed without rebuilding the app. > Solution: Ensure that the application - not JavaFX - decides where messages > come from - it is fine to support the use of property files, but such use > should never be a requirement. A sound design will provide an pluggable > mechanism for retrieving message resources, and deliver a default mechanism > which supports property files, which can be replaced if needed. > > 2. Support for validation dependencies (ordering): If a UI has 2 input > fields A and B, it is sometimes the case, that it makes no sense to run B's > validator before A has been edited by the user to a valid state. One such > example is, if B is only a required field for some values of A. It is a > really annoying/confusing user experience to enter just a single character > into the A field only to see all other fields of the UI turn invalid (in > this case B). Instead, allow dependencies so developers can express that > the validation of B does not start before the validation of A is valid. > This way, the UI will tell the user that A is invalid and needs to be > edited, and only after A has been edited to a valid state, will the UI tell > the user that now B has to be edited. Apart from the improved user > experience, this is also a much less resource intensive approach to > validation (recall that in some cases validation may require network > communication, etc.). > > 3. Support group validation: One of the areas where the JSF 1.x validation > framework failed miserably, was the lack of multiple field validation. Say > a user enters a date interval using two fields called Start and End, and > the requirement is that the End date has to be later than the Start date. > The problem with JSF 1.x validation was, each validator was always tied to > a particular field, not multiple fields or the form as a whole, so there > was no way that the Start field's validator could check if the value was > earlier than the End value. As an application developer, you do not want to > define both that Start comes before End and that End comes after Start, you > want to define just one thing: Start < End. So ideally, you should be able > to write validator, which look at a number of fields, where looking at a > single field (as some validators do) is just a simple case of "a number of > fields". > > 4. Support full plug-and-play reusability: Reusing a component in > different applications requires not only the ability to reuse the visual > component's presentation logic, but also the ability to reuse the > validation logic and messages which applies to that particular component. > Say I am developing and selling an EmailAddressField component for JavaFX. > For that component to be valuable to other organisations, it has to include > logic for validating e-mail adresses, and it has to include proper default > messages such as "An e-mail address must contain exactly one @". JavaFX > should allow me to provide this message in many different languages allong > with the validation logic and share this alongside the component. > > Finally, from what I have seen of the JGoodies approach, it looks very > procedural, and very programming intensive. I found this example online: > > |public ValidationResult validate() { > ValidationResult result = new ValidationResult(); > if (ValidationUtils.isEmpty(**mUser.getUserName())) { > result.addError("User name is required"); > } > if (ValidationUtils.isEmpty(**mUser.getPassword())) { > result.addError("Password is required"); > } > return result; > }| > > > Even though the validation logic to check for emptiness is reusable, the > developer still has to write a lot of if-then logic. I would much rather > want JavaFX to have an object oriented approach, allowing me to write > something like > > TextField userNameTextField = new TextField(new UserNameValidator()); > > where the UserNameValidator class does all of the JGoodies stuff above for > me and can easily be reused among different parts of my application. With > this approach it is obvious that people will start sharing > EmailAddressValidator, ConfigurablePasswordValidator, > LicensePlateValidator, etc. > > Yours > > Randahl > > > > On 11/06/12 01.52, Jonathan Giles wrote: > >> Hi all, >> >> I'm currently in the very, very early stages of developing a validation >> API for future inclusion into JavaFX. I thought rather than get too far >> into the research and development of a proof of concept, I would see what >> you all think. Any feedback now would be very useful. >> >> Essentially, there are a few common styles related to form validation. >> Some of the more likely approaches include: >> >> * The 'JGoodies Validation framework' [1] approach, where the >> developer provides a Validator that will then run over the form and >> gather feedback to return to the user (for example, it would test >> that the 'name field' is not empty, and that the email address is of >> the correct style - if either of these rules are invalid, the >> Validator would return ValidationMessage instances inside a >> ValidationResult). If validation fails the user is shown the text >> out of the ValidationMessage feedback, otherwise the form would >> submit as per usual. This validation may happen at a number of times >> (during form submission, when focus is lost, as a key is typed, >> etc). The nice thing about this approach is that the Validator can >> be a part of the domain model, the presentation model, or a separate >> thing altogether. >> * The JSR-303 approach which uses annotations to indicate the rules >> applicable to each field. These annotations are on the domain model, >> and therefore assumes that the form is directly tied to a domain >> object (which may not always be correct). I think the JSR-303 API is >> too complex for what is needed in JavaFX, but a similar >> implementation could be developed with a simpler API that follows >> this approach. >> * For lack of a better reference point, the FXForm approach [3] which >> encapsulates the validation inside a Form object that can be placed >> in the scene. I know this isn't explicitly (in the case of FXForm) >> about validation, but I think it is another approach to consider. >> >> So, what does JavaFX need out of a validation framework? It's really five >> things (I think): >> >> 1. A way for developers to validate a form by providing some means of >> specifying rules, as well as a way to specify when it runs, how it >> is visually represented, etc. >> 2. A way for the validation to impact upon the visual state of the form >> (using consistent CSS pseudoclass states / style classes, as well as >> by showing custom overlays, error messages beside the component (or >> grouped together at the top of the form)). There must be API to >> specify all of this. >> 3. Convenient API to simplify the validation process [3] (e.g. >> isEmpty(String), isAlphanumeric(String), etc, etc, etc). >> 4. An API that does not require it be integrated with UI controls. >> Doing so would prevent 3rd party UI controls to be able to be >> validated without also implementing the API, which may prove >> burdensome. Instead, the validation API should be separate. >> 5. A means to integrate nicely with the bindings and properties API >> present in JavaFX today. >> >> Of the three approaches above, my personal preference is to follow the >> JGoodies approach as I think it is the most powerful and flexible. However, >> nothing is set in stone and I want to learn what others think. >> >> Note that at present this research does not extend to considering whether >> there should be API related to automatically generating a form from a >> (JavaFX) bean (and making use of the validation API to ensure the input is >> correct). However, I am not against discussing this topic as well, as long >> as it too integrates nicely with the rules above, as well as the validation >> API itself, obviously. This research may full into requirement three above. >> >> [1] http://www.jgoodies.com/**freeware/libraries/validation/ >> [2] https://github.com/dooApp/**FXForm2 >> [3] http://www.jarvana.com/**jarvana/view/com/jgoodies/** >> validation/2.0.1/validation-2.**0.1-javadoc.jar!/com/jgoodies/** >> validation/util/**ValidationUtils.html >> >> Thanks, >> -- Jonathan >> >> From tbee at tbee.org Mon Jun 11 05:07:03 2012 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 11 Jun 2012 14:07:03 +0200 Subject: JavaFX Form Validation In-Reply-To: <4FD5D6B9.7000803@rockit.dk> References: <4FD5D12C.6060400@rockit.dk> <4FD5D1A9.50501@rockit.dk> <4FD5D608.3090608@tbee.org> <4FD5D6B9.7000803@rockit.dk> Message-ID: <4FD5DF67.10309@tbee.org> Yup, close enough. This is the better combination between my suggestion and Greg's FXML version. IMHO. Tom On 2012-06-11 13:30, Randahl Fink Isaksen wrote: > I like your idea Tom. But if it should look like the existing JavaFX API's, it will probably be more like > > myTextField.getValidators().addAll(new MandatoryValidator(), new UserNameValidator()); > > Randahl > From goddard at seznam.cz Mon Jun 11 07:52:01 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Mon, 11 Jun 2012 16:52:01 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Re=3A=20Property=20updates?= In-Reply-To: <4FD5DAAB.1080805@oracle.com> Message-ID: <129211.7688.26710-2472-1934098557-1339426321@seznam.cz> Hi, thanks for the answer. I've thought that my code does this: - create circle at random coords - create random end coords - create animation with all these coords - call setOnFinished every time when animation ends - inside handle, do following: -- assign the current end coords to the target coords, so the next animation starts at the end -- generate new end coords, so the next animation ends at different coords -- play next animation >From the point where I'm callung the setOnFinished, it should be like a never-ending loop. Accordning to the println output, I'm updating the end coords, but the circle coords are not updated even I'm calling set() on the cX/Y property. I'm not sure what I should change in the code so it works properly. Apologies, Jiri ------------ P?vodn? zpr?va ------------ Od: Pavel Safrata P?edm?t: Re: Property updates Datum: 11.6.2012 13:48:14 ---------------------------------------- Hello Jiri, the coordinates are updated during the animation, but always finish on the same value. It's because you create the timeline passing the current values of the x and y properties and then run it over and over without updating it, so it always finishes with the circle on the same coordinates (the first random values generated for x an y). The pause is caused by the fact that your code makes the second run of the timeline begin on the same place where it ends (so the animation runs and moves the circle about zero pixels). With regards, Pavel On 11.6.2012 12:48, goddard at seznam.cz wrote: > This is the output from the println statements: > centerXDoubleProperty [bean: Circle at 157a5c3, name: centerX, value: 396.34924225837125] > x: DoubleProperty [value: 396.34924225837125] > centerXDoubleProperty [bean: Circle at 157a5c3, name: centerX, value: 396.34924225837125] > x: DoubleProperty [value: 563.9584002793741] > centerXDoubleProperty [bean: Circle at 157a5c3, name: centerX, value: 396.34924225837125] > x: DoubleProperty [value: 337.0834495091644] > > As you can see, the centerX value doesn't change at all. Any help is appreciated. > > Regards, jiri > > ------------ P?vodn? zpr?va ------------ > Od: > P?edm?t: Property updates > Datum: 10.6.2012 22:54:59 > ---------------------------------------- > Hello, > > the following code should create a Circle at random coords and animate the > translation to random coords. The point is to randomly translate the circle from > one location to another successively: > > package boyle; > > import javafx.animation.KeyFrame; > import javafx.animation.KeyValue; > import javafx.animation.Timeline; > import javafx.animation.TimelineBuilder; > import javafx.application.Application; > import javafx.beans.property.DoubleProperty; > import javafx.beans.property.SimpleDoubleProperty; > import javafx.event.ActionEvent; > import javafx.event.EventHandler; > import javafx.scene.Group; > import javafx.scene.Scene; > import javafx.scene.paint.Color; > import javafx.scene.shape.Circle; > import javafx.scene.shape.CircleBuilder; > import javafx.stage.Stage; > import javafx.util.Duration; > > /** > * > * @author jiri > */ > public class Boyle extends Application { > > public static final int WIDTH = 800; > public static final int HEIGHT = 512; > > /** > * @param args the command line arguments > */ > public static void main(String[] args) { > launch(args); > } > > // end the animation at random coords > private DoubleProperty x = new SimpleDoubleProperty(Math.random() * WIDTH); > private DoubleProperty y = new SimpleDoubleProperty(Math.random() * > HEIGHT); > > @Override public void start(Stage primaryStage) { > final Circle c = CircleBuilder.create() > // start the animation at random coords > .centerX(Math.random() * WIDTH) > .centerY(Math.random() * HEIGHT) > .radius(15).fill(Color.BLACK) > .build(); > > final DoubleProperty[] randCoords = {x, y}; > > final Timeline t = TimelineBuilder.create() > .keyFrames(new KeyFrame(Duration.seconds(5), > new KeyValue(c.centerXProperty(), randCoords[0].get()), > new KeyValue(c.centerYProperty(), randCoords[1].get()))) > .build(); > > // refreshes coords at every end of the animation > t.setOnFinished(new EventHandler() { > > @Override > public void handle(ActionEvent ae) { > System.out.println("centerX"+ c.centerXProperty()); > // set animation end coords to the target > c.centerXProperty().set(randCoords[0].get()); > c.centerYProperty().set(randCoords[1].get()); > System.out.println("x: "+ randCoords[0]); > // generate new coords for the animation end > randCoords[0].set(Math.random() * WIDTH); > randCoords[1].set(Math.random() * HEIGHT); > t.play(); > } > }); > > t.play(); > > Group root = new Group(); > root.getChildren().add(c); > > Scene scene = new Scene(root, WIDTH, HEIGHT); > > primaryStage.setTitle("@javafxcz - Boyle - www.dredwerkz.cz"); > primaryStage.setScene(scene); > primaryStage.show(); > } > } > > However, the circle appears moving to its target coords instead to its end > coords, and update of the target coords doesn't work - unlike for the end > coords. Plus, there's a significant 1-2 seconds long pause before the animation > starts again in the handler, but just for the first time. Then it runs > smoothly. > Help in form of explanation / code sample is appreciated. > > Regards, Jiri > > From pavel.safrata at oracle.com Mon Jun 11 08:30:47 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 11 Jun 2012 17:30:47 +0200 Subject: Property updates In-Reply-To: <129211.7688.26710-2472-1934098557-1339426321@seznam.cz> References: <129211.7688.26710-2472-1934098557-1339426321@seznam.cz> Message-ID: <4FD60F27.5040702@oracle.com> Hi, On 11.6.2012 16:52, goddard at seznam.cz wrote: > Hi, > > thanks for the answer. I've thought that my code does this: > - create circle at random coords > - create random end coords > - create animation with all these coords > - call setOnFinished every time when animation ends > - inside handle, do following: > -- assign the current end coords to the target coords, so the next > animation starts at the end > -- generate new end coords, so the next animation ends at different > coords Here is your problem. You generate new coords, but you store them to the randCoords array, which has no influence on the timeline. During creation of the timeline, you call new KeyValue(c.centerXProperty(), randCoords[0].get()) In the above call, randCoords[0].get() is called, returns a number (the first generated random end coordinate), and this number is passed to KeyValue's constructor. So the KeyValue then always moves centerXProperty to the point specified by the number and has no reference to the randCoords array you later keep updating. > -- play next animation > > From the point where I'm callung the setOnFinished, it should be like > a never-ending loop. Accordning to the println output, I'm updating > the end coords, but the circle coords are not updated even I'm calling > set() on the cX/Y property. I can see the printline is above the setters. It shows the coordinates of the end of the animation, which are always the same. If you move the printline below the setters, it will certainly show the new values. > I'm not sure what I should change in the code so it works properly. For moving nodes you should generally use transitions, but if this is a simplification of some more complex code, you need to update the timeline's key frame each time you are starting new round. I hope I've made it more clear this time.. With regards, Pavel > > Apologies, Jiri > > ------------ P?vodn? zpr?va ------------ > Od: Pavel Safrata > P?edm?t: Re: Property updates > Datum: 11.6.2012 13:48:14 > ---------------------------------------- > Hello Jiri, > the coordinates are updated during the animation, but always finish on > the same value. It's because you create the timeline passing the > current values of the x and y properties and then run it over and over > without updating it, so it always finishes with the circle on the same > coordinates (the first random values generated for x an y). The pause > is caused by the fact that your code makes the second run of the > timeline begin on the same place where it ends (so the animation runs > and moves the circle about zero pixels). > With regards, > Pavel > > On 11.6.2012 12:48, goddard at seznam.cz wrote: >> This is the output from the println statements: >> centerXDoubleProperty [bean: Circle at 157a5c3, name: centerX, value: > 396.34924225837125] >> x: DoubleProperty [value: 396.34924225837125] >> centerXDoubleProperty [bean: Circle at 157a5c3, name: centerX, value: > 396.34924225837125] >> x: DoubleProperty [value: 563.9584002793741] >> centerXDoubleProperty [bean: Circle at 157a5c3, name: centerX, value: > 396.34924225837125] >> x: DoubleProperty [value: 337.0834495091644] >> >> As you can see, the centerX value doesn't change at all. Any help is > appreciated. >> >> Regards, jiri >> >> ------------ P?vodn? zpr?va ------------ >> Od: >> P?edm?t: Property updates >> Datum: 10.6.2012 22:54:59 >> ---------------------------------------- >> Hello, >> >> the following code should create a Circle at random coords and >> animate the >> translation to random coords. The point is to randomly translate the >> circle > from >> one location to another successively: >> >> package boyle; >> >> import javafx.animation.KeyFrame; >> import javafx.animation.KeyValue; >> import javafx.animation.Timeline; >> import javafx.animation.TimelineBuilder; >> import javafx.application.Application; >> import javafx.beans.property.DoubleProperty; >> import javafx.beans.property.SimpleDoubleProperty; >> import javafx.event.ActionEvent; >> import javafx.event.EventHandler; >> import javafx.scene.Group; >> import javafx.scene.Scene; >> import javafx.scene.paint.Color; >> import javafx.scene.shape.Circle; >> import javafx.scene.shape.CircleBuilder; >> import javafx.stage.Stage; >> import javafx.util.Duration; >> >> /** >> * >> * @author jiri >> */ >> public class Boyle extends Application { >> >> public static final int WIDTH = 800; >> public static final int HEIGHT = 512; >> >> /** >> * @param args the command line arguments >> */ >> public static void main(String[] args) { >> launch(args); >> } >> >> // end the animation at random coords >> private DoubleProperty x = new SimpleDoubleProperty(Math.random() * > WIDTH); >> private DoubleProperty y = new SimpleDoubleProperty(Math.random() * >> HEIGHT); >> >> @Override public void start(Stage primaryStage) { >> final Circle c = CircleBuilder.create() >> // start the animation at random coords >> .centerX(Math.random() * WIDTH) >> .centerY(Math.random() * HEIGHT) >> .radius(15).fill(Color.BLACK) >> .build(); >> >> final DoubleProperty[] randCoords = {x, y}; >> >> final Timeline t = TimelineBuilder.create() >> .keyFrames(new KeyFrame(Duration.seconds(5), >> new KeyValue(c.centerXProperty(), randCoords[0].get()), >> new KeyValue(c.centerYProperty(), >> randCoords[1].get()))) >> .build(); >> >> // refreshes coords at every end of the animation >> t.setOnFinished(new EventHandler() { >> >> @Override >> public void handle(ActionEvent ae) { >> System.out.println("centerX"+ c.centerXProperty()); >> // set animation end coords to the target >> c.centerXProperty().set(randCoords[0].get()); >> c.centerYProperty().set(randCoords[1].get()); >> System.out.println("x: "+ randCoords[0]); >> // generate new coords for the animation end >> randCoords[0].set(Math.random() * WIDTH); >> randCoords[1].set(Math.random() * HEIGHT); >> t.play(); >> } >> }); >> >> t.play(); >> >> Group root = new Group(); >> root.getChildren().add(c); >> >> Scene scene = new Scene(root, WIDTH, HEIGHT); >> >> primaryStage.setTitle("@javafxcz - Boyle - www.dredwerkz.cz"); >> primaryStage.setScene(scene); >> primaryStage.show(); >> } >> } >> >> However, the circle appears moving to its target coords instead to >> its end >> coords, and update of the target coords doesn't work - unlike for the >> end >> coords. Plus, there's a significant 1-2 seconds long pause before the > animation >> starts again in the handler, but just for the first time. Then it runs >> smoothly. >> Help in form of explanation / code sample is appreciated. >> >> Regards, Jiri >> >> > > From richard.bair at oracle.com Mon Jun 11 09:02:43 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 11 Jun 2012 09:02:43 -0700 Subject: JavaFX Form Validation In-Reply-To: <4FD5332A.5080608@oracle.com> References: <4FD5332A.5080608@oracle.com> Message-ID: Hi Jonathan, Another place you should go check is the HTML 5 Validation system. I think that it would form the "minimalist" base layer that Tom S. and Gerrit are looking for, but is also the foundation you'd want for just about any validation framework. Basically, each Control would get a "valid" boolean property, and would set a pseudo-class "valid" or "invalid" depending on the boolean. A developer (or framework) is then responsible for binding the valid state of any control to the results of validation for that application. http://stephenwalther.com/archive/2012/03/13/html5-form-validation.aspx Worth a read. I didn't see the link I was looking for but the above should point in some right directions anyway. Richard From hang.vo at oracle.com Mon Jun 11 10:03:37 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Jun 2012 17:03:37 +0000 Subject: hg: openjfx/2.2/controls/rt: Fixed RT-21658: Touch : TextArea : hard to differentiate between block selection and scrolling Message-ID: <20120611170342.BA8C147863@hg.openjdk.java.net> Changeset: 8bc39da3d194 Author: leifs Date: 2012-06-11 10:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/8bc39da3d194 Fixed RT-21658: Touch : TextArea : hard to differentiate between block selection and scrolling ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java From greg.x.brown at oracle.com Mon Jun 11 10:31:48 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Mon, 11 Jun 2012 13:31:48 -0400 Subject: JavaFX Form Validation In-Reply-To: <4FD5DF67.10309@tbee.org> References: <4FD5D12C.6060400@rockit.dk> <4FD5D1A9.50501@rockit.dk> <4FD5D608.3090608@tbee.org> <4FD5D6B9.7000803@rockit.dk> <4FD5DF67.10309@tbee.org> Message-ID: <9EE2552D-5EB1-444B-BD8C-CBFF72F6D743@oracle.com> This is the same as what I proposed. I just broke the addAll() into two add() calls to show parity with the FXML version. On Jun 11, 2012, at 8:07 AM, Tom Eugelink wrote: > Yup, close enough. This is the better combination between my suggestion and Greg's FXML version. IMHO. > > Tom > > On 2012-06-11 13:30, Randahl Fink Isaksen wrote: >> I like your idea Tom. But if it should look like the existing JavaFX API's, it will probably be more like >> >> myTextField.getValidators().addAll(new MandatoryValidator(), new UserNameValidator()); >> >> Randahl >> > From hang.vo at oracle.com Mon Jun 11 10:48:39 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Jun 2012 17:48:39 +0000 Subject: hg: openjfx/2.2/controls/rt: Fixed RT-22112: ComboBox : regression with editor selection Message-ID: <20120611174842.598E347866@hg.openjdk.java.net> Changeset: 85d4575070f8 Author: leifs Date: 2012-06-11 10:45 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/85d4575070f8 Fixed RT-22112: ComboBox : regression with editor selection ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java From hang.vo at oracle.com Mon Jun 11 11:18:22 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Jun 2012 18:18:22 +0000 Subject: hg: openjfx/2.2/controls/rt: Corrected fix for RT-21788: Adjust padding in TextArea and TextField for Embedded. Message-ID: <20120611181823.2CA1F47868@hg.openjdk.java.net> Changeset: 52cf4be61cfe Author: leifs Date: 2012-06-11 11:02 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/52cf4be61cfe Corrected fix for RT-21788: Adjust padding in TextArea and TextField for Embedded. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/embedded-qvga.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/embedded.css From anthony.vanelverdinghe at gmail.com Mon Jun 11 11:24:28 2012 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Mon, 11 Jun 2012 20:24:28 +0200 Subject: JavaFX Form Validation In-Reply-To: <201206111115.17895.fbrunnerlist@gmx.ch> References: <4FD5332A.5080608@oracle.com> <201206111047.14489.fbrunnerlist@gmx.ch> <4FD5B3D9.7000508@oracle.com> <201206111115.17895.fbrunnerlist@gmx.ch> Message-ID: <4FD637DC.4010704@gmail.com> Hi Jonathan I wholeheartedly agree with Florian on this. Please have a look at the roadmap as well: http://beanvalidation.org/roadmap/ It says: "Bean Validation standardizes constraint definition, declaration and validation for the /Java platform/." and the expert group clearly expresses the intent to accommodate the integration with other JSRs: "[...] the Bean Validation expert group will adjust or add new features to the core of the Bean Validation specification as deemed necessary to achieve a successful integration." In my opinion it would be a natural choice for JavaFX to make use of the framework that is used throughout the Java EE stack already. The least that JavaFX should do, is to be able to make use of existing Bean Validation metadata. Kind regards Anthony Op 11/06/2012 11:15, Florian Brunner schreef: > Hi Jonathan, > > From: https://blogs.oracle.com/theaquarium/entry/beanvalidation_1_1_is_now > > --------------------------------------- > JBoss' Emmanuel Bernard has submitted Bean Validation 1.1 as JSR 349. This version should be part of Java EE 7 and an important goal for this release is further integration with other platform JSRs. > > In addition to JSF and JPA, integrations with JAX-RS, JAXB, CDI and EJB are also considered. Other important evolutions include a potential API to validate parameters and return values of method calls as well as another API to declare constraints (as opposed to annotations today). The JSR page and this earlier blog post have more details. > > Note that the current Bean Validation API can also very much be used with JavaSE. Ballot results for this JSR are due on July 25th, 2011. > --------------------------------------- > > Bean Validation is currently developed under JSR 349. The goal seems to be among others a better integration with JSF (which is also a GUI technology) and Java SE. Thus I think JavaFX should be considered as well. > > Regards, > Florian > > > Am Montag 11 Juni 2012, 11:01:13 schrieb Jonathan Giles: >> Florian, >> >> My understanding of JSR-303 is that it is well past the stages of being >> active. According to [1], it starting in July 2006, and produced its >> final release (along with final API) in November of 2009. >> >> Also, from my understanding of JSR-303, it appears to be more focused on >> the Java EE needs of a container such as Hibernate (one component of >> which is the reference implementation of JSR-303). I would imagine that >> this would lead to it being far more complex than is necessary in a >> JavaFX API. >> >> However, I am not ruling it out, but I just worry that it may be >> ill-fitting for JavaFX. I would be totally happy to be proven wrong, and >> will look into it more tomorrow to be sure. >> >> [1] http://jcp.org/en/jsr/detail?id=303 >> >> -- Jonathan >> >> >> On 11/06/2012 8:47 p.m., Florian Brunner wrote: >>> Hi, >>> >>> I haven't worked with JSR-303, yet, but I would appreciate if the Java community could come up with a validation framework which can be used consistently on various layers. >>> >>> If JSR-303 currently doesn't fit the needs of JavaFX, maybe the JavaFX team could get involved in JSR-303 to make sure it fits the needs of JavaFX as well? >>> >>> Regards, >>> Florian >>> >>> Am Montag 11 Juni 2012, 01:52:10 schrieb Jonathan Giles: >>>> Hi all, >>>> >>>> I'm currently in the very, very early stages of developing a validation >>>> API for future inclusion into JavaFX. I thought rather than get too far >>>> into the research and development of a proof of concept, I would see >>>> what you all think. Any feedback now would be very useful. >>>> >>>> Essentially, there are a few common styles related to form validation. >>>> Some of the more likely approaches include: >>>> >>>> * The 'JGoodies Validation framework' [1] approach, where the >>>> developer provides a Validator that will then run over the form and >>>> gather feedback to return to the user (for example, it would test >>>> that the 'name field' is not empty, and that the email address is of >>>> the correct style - if either of these rules are invalid, the >>>> Validator would return ValidationMessage instances inside a >>>> ValidationResult). If validation fails the user is shown the text >>>> out of the ValidationMessage feedback, otherwise the form would >>>> submit as per usual. This validation may happen at a number of times >>>> (during form submission, when focus is lost, as a key is typed, >>>> etc). The nice thing about this approach is that the Validator can >>>> be a part of the domain model, the presentation model, or a separate >>>> thing altogether. >>>> * The JSR-303 approach which uses annotations to indicate the rules >>>> applicable to each field. These annotations are on the domain model, >>>> and therefore assumes that the form is directly tied to a domain >>>> object (which may not always be correct). I think the JSR-303 API is >>>> too complex for what is needed in JavaFX, but a similar >>>> implementation could be developed with a simpler API that follows >>>> this approach. >>>> * For lack of a better reference point, the FXForm approach [3] which >>>> encapsulates the validation inside a Form object that can be placed >>>> in the scene. I know this isn't explicitly (in the case of FXForm) >>>> about validation, but I think it is another approach to consider. >>>> >>>> So, what does JavaFX need out of a validation framework? It's really >>>> five things (I think): >>>> >>>> 1. A way for developers to validate a form by providing some means of >>>> specifying rules, as well as a way to specify when it runs, how it >>>> is visually represented, etc. >>>> 2. A way for the validation to impact upon the visual state of the form >>>> (using consistent CSS pseudoclass states / style classes, as well as >>>> by showing custom overlays, error messages beside the component (or >>>> grouped together at the top of the form)). There must be API to >>>> specify all of this. >>>> 3. Convenient API to simplify the validation process [3] (e.g. >>>> isEmpty(String), isAlphanumeric(String), etc, etc, etc). >>>> 4. An API that does not require it be integrated with UI controls. >>>> Doing so would prevent 3rd party UI controls to be able to be >>>> validated without also implementing the API, which may prove >>>> burdensome. Instead, the validation API should be separate. >>>> 5. A means to integrate nicely with the bindings and properties API >>>> present in JavaFX today. >>>> >>>> Of the three approaches above, my personal preference is to follow the >>>> JGoodies approach as I think it is the most powerful and flexible. >>>> However, nothing is set in stone and I want to learn what others think. >>>> >>>> Note that at present this research does not extend to considering >>>> whether there should be API related to automatically generating a form >>>> from a (JavaFX) bean (and making use of the validation API to ensure the >>>> input is correct). However, I am not against discussing this topic as >>>> well, as long as it too integrates nicely with the rules above, as well >>>> as the validation API itself, obviously. This research may full into >>>> requirement three above. >>>> >>>> [1] http://www.jgoodies.com/freeware/libraries/validation/ >>>> [2] https://github.com/dooApp/FXForm2 >>>> [3] >>>> http://www.jarvana.com/jarvana/view/com/jgoodies/validation/2.0.1/validation-2.0.1-javadoc.jar!/com/jgoodies/validation/util/ValidationUtils.html >>>> >>>> Thanks, >>>> -- Jonathan >>>> >>>> From mcdonnell.john at gmail.com Mon Jun 11 11:26:01 2012 From: mcdonnell.john at gmail.com (John McDonnell) Date: Mon, 11 Jun 2012 19:26:01 +0100 Subject: JavaFX Form Validation In-Reply-To: <9EE2552D-5EB1-444B-BD8C-CBFF72F6D743@oracle.com> References: <4FD5D12C.6060400@rockit.dk> <4FD5D1A9.50501@rockit.dk> <4FD5D608.3090608@tbee.org> <4FD5D6B9.7000803@rockit.dk> <4FD5DF67.10309@tbee.org> <9EE2552D-5EB1-444B-BD8C-CBFF72F6D743@oracle.com> Message-ID: I would just like to chime in here and say agree with Randahl's points, particularly in regards to validation dependencies. Its something that is required where I work as we use wizards a lot, and the validation has to be run in a defined order. Just a question, but should the validation also be tied to any JPA annotations on the entity bean, for example if a property in a bean is has an annotation like @Column(nullable = false) then it would seem repetitive to declare a Not Null validator on the property elsewhere in the code John On 11 June 2012 18:31, Greg Brown wrote: > This is the same as what I proposed. I just broke the addAll() into two > add() calls to show parity with the FXML version. > > On Jun 11, 2012, at 8:07 AM, Tom Eugelink wrote: > > > Yup, close enough. This is the better combination between my suggestion > and Greg's FXML version. IMHO. > > > > Tom > > > > On 2012-06-11 13:30, Randahl Fink Isaksen wrote: > >> I like your idea Tom. But if it should look like the existing JavaFX > API's, it will probably be more like > >> > >> myTextField.getValidators().addAll(new MandatoryValidator(), new > UserNameValidator()); > >> > >> Randahl > >> > > > > -- John From hang.vo at oracle.com Mon Jun 11 13:18:09 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Jun 2012 20:18:09 +0000 Subject: hg: openjfx/2.2/controls/rt: 2 new changesets Message-ID: <20120611201812.2814D4786E@hg.openjdk.java.net> Changeset: 7be3c836bb43 Author: hudson Date: 2012-06-06 16:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/7be3c836bb43 Added tag 2.2-b12 for changeset 348de34f8273 ! .hgtags Changeset: 6809fcdc77f4 Author: leifs Date: 2012-06-11 13:04 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/6809fcdc77f4 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt From richard.bair at oracle.com Mon Jun 11 13:49:06 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 11 Jun 2012 13:49:06 -0700 Subject: JavaFX Task/Service thread checks In-Reply-To: <4FD5B0F2.1080908@xs4all.nl> References: <4FD5B0F2.1080908@xs4all.nl> Message-ID: <057F3E46-C275-4337-9D94-17450D3ED7D3@oracle.com> Hi John, This is a good question. Can you file a feature request? One possible solution is that whatever thread created the Task / Service is the thread that is authorized to attach listeners etc, and then also possibly have a "setOwnerThread" method (or whatnot) for changing what that owner thread is. There are several issues here which are annoying. One is that, for example, if you create a bunch of Tasks on the preloader startup thread (which may be different from the fx app thread) and then either (a) they don't work or (b) they are later touched from the fx app thread and you have several threads talking to the same Task. Richard On Jun 11, 2012, at 1:48 AM, John Hendrikx wrote: > Hi all, > > JavaFX currently provides many interesting new ways of doing things we've been doing for years. For example, I find myself using JavaFX packages outside the scope of the UI more and more often. Examples are changing domain objects to include the JavaFX style Property methods for easy binding and using Task objects to make use of its convenient State property (to which one can attach listeners). > > However, I'm wondering, why is there a 'checkThread' in for example the stateProperty method of a Task? Wasn't it said that manipulating JavaFX objects that are NOT part of a Scene was to be allowed on any thread? Do I need to worry that other (reusable without UI) API's in JavaFX will have this checkThread method sprinkled through them? > > I mean, shouldn't it be allowed to create a new Task object, have it get executed on some thread of my choosing, and then be able to monitor its progress by attaching a ChangeListener to its State property? This is a lot more convenient than say a FutureTask, for which I'm forced to either wrap it inside another Runnable (to do a little bit of clean-up after it finished, on the same thread), create another thread so I can use the blocking 'get()' call or adding a simplistic Listener system to it notify me when it completes (again, on the same thread). > > My Task is not attached to the UI in any way, yet it forces me to wrap the call to 'stateProperty()' in a Platform.runLater() -- all I want is its feedback when it finishes without me having to build this system myself or spawning yet another Thread. > > Best regards, > John Hendrikx From hang.vo at oracle.com Mon Jun 11 14:03:13 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Jun 2012 21:03:13 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-21925: Canvas consistent handling of text alignment. When multiple lines of text. Doc only change. Message-ID: <20120611210315.CA4C94786F@hg.openjdk.java.net> Changeset: 97b7b1b4a358 Author: Thor johannesson Date: 2012-06-11 13:49 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/97b7b1b4a358 RT-21925: Canvas consistent handling of text alignment. When multiple lines of text. Doc only change. ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java From hjohn at xs4all.nl Mon Jun 11 14:06:30 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Mon, 11 Jun 2012 23:06:30 +0200 Subject: JavaFX Task/Service thread checks In-Reply-To: <057F3E46-C275-4337-9D94-17450D3ED7D3@oracle.com> References: <4FD5B0F2.1080908@xs4all.nl> <057F3E46-C275-4337-9D94-17450D3ED7D3@oracle.com> Message-ID: <4FD65DD6.9050302@xs4all.nl> Could you explain what the issues are when different Threads have listeners attached to a Task's stateProperty? AFAIK, all the listeners get fired (one by one) on the fx thread, not on the thread that attached the listener in the first place. I can understand that a method like setState() (if it existed) must be called from the fx-thread, as that could cause listeners to fire (which must be on the fx thread afaik)... but attaching a listener should be possible from any thread (barring issues with managing and traversing the listener list itself -- those would need synchronization) ...... I guess that last one probably touches upon why this thread check is there as the other thread would be holding a lock preventing the fx-thread from proceeding -- although such a lock would never be held for long... I'll add a JIRA issue to track it. On 11/06/2012 22:49, Richard Bair wrote: > Hi John, > > This is a good question. Can you file a feature request? One possible solution is that whatever thread created the Task / Service is the thread that is authorized to attach listeners etc, and then also possibly have a "setOwnerThread" method (or whatnot) for changing what that owner thread is. > > There are several issues here which are annoying. One is that, for example, if you create a bunch of Tasks on the preloader startup thread (which may be different from the fx app thread) and then either (a) they don't work or (b) they are later touched from the fx app thread and you have several threads talking to the same Task. > > Richard > > On Jun 11, 2012, at 1:48 AM, John Hendrikx wrote: > >> Hi all, >> >> JavaFX currently provides many interesting new ways of doing things we've been doing for years. For example, I find myself using JavaFX packages outside the scope of the UI more and more often. Examples are changing domain objects to include the JavaFX style Property methods for easy binding and using Task objects to make use of its convenient State property (to which one can attach listeners). >> >> However, I'm wondering, why is there a 'checkThread' in for example the stateProperty method of a Task? Wasn't it said that manipulating JavaFX objects that are NOT part of a Scene was to be allowed on any thread? Do I need to worry that other (reusable without UI) API's in JavaFX will have this checkThread method sprinkled through them? >> >> I mean, shouldn't it be allowed to create a new Task object, have it get executed on some thread of my choosing, and then be able to monitor its progress by attaching a ChangeListener to its State property? This is a lot more convenient than say a FutureTask, for which I'm forced to either wrap it inside another Runnable (to do a little bit of clean-up after it finished, on the same thread), create another thread so I can use the blocking 'get()' call or adding a simplistic Listener system to it notify me when it completes (again, on the same thread). >> >> My Task is not attached to the UI in any way, yet it forces me to wrap the call to 'stateProperty()' in a Platform.runLater() -- all I want is its feedback when it finishes without me having to build this system myself or spawning yet another Thread. >> >> Best regards, >> John Hendrikx From hang.vo at oracle.com Mon Jun 11 14:48:06 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Jun 2012 21:48:06 +0000 Subject: hg: openjfx/2.2/controls/rt: 4 new changesets Message-ID: <20120611214810.059F047879@hg.openjdk.java.net> Changeset: f848576e5df0 Author: jgiles Date: 2012-06-07 15:15 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/f848576e5df0 RT-20945: ComboBox, computing the items inside showing property handler fires unwanted onAction event ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java Changeset: d09cc9910784 Author: jgiles Date: 2012-06-08 13:56 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/d09cc9910784 RT-22079: No change event on selection when selected row is removed from TableView ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: 634e4bbb4cf5 Author: jgiles Date: 2012-06-08 15:15 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/634e4bbb4cf5 RT-22077: TableView updates not working when ValueFactory returns a new Binding ! javafx-ui-controls/src/javafx/scene/control/TableCell.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java Changeset: cc8d7f8bbab8 Author: jgiles Date: 2012-06-12 09:44 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/cc8d7f8bbab8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt From jonathan.giles at oracle.com Mon Jun 11 16:18:11 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 12 Jun 2012 11:18:11 +1200 Subject: JavaFX Form Validation In-Reply-To: <4FD5332A.5080608@oracle.com> References: <4FD5332A.5080608@oracle.com> Message-ID: <4FD67CB3.1050102@oracle.com> Thanks all for your feedback and taking the time to have a good discussion on this topic. I'll go off and digest everything that was said and will resurface in the coming weeks with a first draft plan of attack for your review. I feel like I am far more informed of the needs, and of the opinions, of the community now. Feel free to continue to leave your thoughts and use cases in this thread. However, for now, I need to return to bug fixing on JavaFX 2.2. Thanks again, -- Jonathan On 11/06/2012 11:52 a.m., Jonathan Giles wrote: > Hi all, > > I'm currently in the very, very early stages of developing a > validation API for future inclusion into JavaFX. I thought rather than > get too far into the research and development of a proof of concept, I > would see what you all think. Any feedback now would be very useful. > > Essentially, there are a few common styles related to form validation. > Some of the more likely approaches include: > > * The 'JGoodies Validation framework' [1] approach, where the > developer provides a Validator that will then run over the form and > gather feedback to return to the user (for example, it would test > that the 'name field' is not empty, and that the email address is of > the correct style - if either of these rules are invalid, the > Validator would return ValidationMessage instances inside a > ValidationResult). If validation fails the user is shown the text > out of the ValidationMessage feedback, otherwise the form would > submit as per usual. This validation may happen at a number of times > (during form submission, when focus is lost, as a key is typed, > etc). The nice thing about this approach is that the Validator can > be a part of the domain model, the presentation model, or a separate > thing altogether. > * The JSR-303 approach which uses annotations to indicate the rules > applicable to each field. These annotations are on the domain model, > and therefore assumes that the form is directly tied to a domain > object (which may not always be correct). I think the JSR-303 API is > too complex for what is needed in JavaFX, but a similar > implementation could be developed with a simpler API that follows > this approach. > * For lack of a better reference point, the FXForm approach [3] which > encapsulates the validation inside a Form object that can be placed > in the scene. I know this isn't explicitly (in the case of FXForm) > about validation, but I think it is another approach to consider. > > So, what does JavaFX need out of a validation framework? It's really > five things (I think): > > 1. A way for developers to validate a form by providing some means of > specifying rules, as well as a way to specify when it runs, how it > is visually represented, etc. > 2. A way for the validation to impact upon the visual state of the form > (using consistent CSS pseudoclass states / style classes, as well as > by showing custom overlays, error messages beside the component (or > grouped together at the top of the form)). There must be API to > specify all of this. > 3. Convenient API to simplify the validation process [3] (e.g. > isEmpty(String), isAlphanumeric(String), etc, etc, etc). > 4. An API that does not require it be integrated with UI controls. > Doing so would prevent 3rd party UI controls to be able to be > validated without also implementing the API, which may prove > burdensome. Instead, the validation API should be separate. > 5. A means to integrate nicely with the bindings and properties API > present in JavaFX today. > > Of the three approaches above, my personal preference is to follow the > JGoodies approach as I think it is the most powerful and flexible. > However, nothing is set in stone and I want to learn what others think. > > Note that at present this research does not extend to considering > whether there should be API related to automatically generating a form > from a (JavaFX) bean (and making use of the validation API to ensure > the input is correct). However, I am not against discussing this topic > as well, as long as it too integrates nicely with the rules above, as > well as the validation API itself, obviously. This research may full > into requirement three above. > > [1] http://www.jgoodies.com/freeware/libraries/validation/ > [2] https://github.com/dooApp/FXForm2 > [3] > http://www.jarvana.com/jarvana/view/com/jgoodies/validation/2.0.1/validation-2.0.1-javadoc.jar!/com/jgoodies/validation/util/ValidationUtils.html > > Thanks, > -- Jonathan > From hang.vo at oracle.com Mon Jun 11 22:03:30 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Jun 2012 05:03:30 +0000 Subject: hg: openjfx/2.2/controls/rt: 2 new changesets Message-ID: <20120612050333.ACB314788A@hg.openjdk.java.net> Changeset: 388637d028f3 Author: jgiles Date: 2012-06-12 15:17 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/388637d028f3 Reinstating a commented out public method on TableColumn that was commented out by mistake in a previous changeset. Unit tests failed because of this, and now pass again. ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java Changeset: a636b9ba88ac Author: jgiles Date: 2012-06-12 16:55 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/a636b9ba88ac Fix for second unit test failure, this time related to listview selection events not firing properly when the row index does not change, but the selected item does. ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java From lubomir.nerad at oracle.com Tue Jun 12 04:47:35 2012 From: lubomir.nerad at oracle.com (Lubomir Nerad) Date: Tue, 12 Jun 2012 13:47:35 +0200 Subject: API REVIEW: Weak event handler Message-ID: <4FD72C57.1040609@oracle.com> Hi All, there is a request to add a WeakEventHandler to the API (http://javafx-jira.kenai.com/browse/RT-13706). This will be a simple wrapper for the target event handler to which it will delegate the handle calls. It will reference the target weakly and so it won't prevent it from being garbage collected. My proposal for this class is: package javafx.event; public final class WeakEventHandler extends WeakReference> implements EventHandler { private WeakEventHandler(EventHandler eventHandler) { ... } @Override public void handle(final T event) { ... } public static WeakEventHandler create(EventHandler eventHandler) { ... } } I decided to make this class both an EventHandler (implements) and a WeakReference (extends). Mainly I needed to have some way how to test from event handler containers whether the target event handler for a stored wrapper has been garbage collected and so the wrapper can be removed as well. Extending WeakReference adds the required method (WeakReference.get()) and saves some object instances. It also brings the clear method, which can simplify testing of this feature. WeakEventHandler instances will be created through the create factory method. This is to avoid repetition of the event type during event handler registration. So instead of: node.setOnMousePressed(new WeakEventHandler(new EventHandler() { ... })); we can use: node.setOnMousePressed(WeakEventHandler.create(new EventHandler() { ... })); I also considered to define the WeakEventHandler as an interface which extends EventHandler, but adds no additional methods. Then leave it to event handler containers to reference such event handlers weakly. This has very simple and direct usage, but also its own problems. We can discuss it further if you find this solution preferred to the wrapper approach. Thanks, Lubo From tbee at tbee.org Tue Jun 12 04:53:32 2012 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 12 Jun 2012 13:53:32 +0200 Subject: JavaFX Form Validation In-Reply-To: References: <4FD5332A.5080608@oracle.com> Message-ID: <4FD72DBC.8030103@tbee.org> The first thing I noticed is that javascript code is being rolled in pretty quickly there; mandatory, pattern, code. Which in fact would support the coded validator approach of JGoodies. Tom On 11-6-2012 18:02, Richard Bair wrote: > Hi Jonathan, > > Another place you should go check is the HTML 5 Validation system. I think that it would form the "minimalist" base layer that Tom S. and Gerrit are looking for, but is also the foundation you'd want for just about any validation framework. Basically, each Control would get a "valid" boolean property, and would set a pseudo-class "valid" or "invalid" depending on the boolean. A developer (or framework) is then responsible for binding the valid state of any control to the results of validation for that application. > > http://stephenwalther.com/archive/2012/03/13/html5-form-validation.aspx > > Worth a read. I didn't see the link I was looking for but the above should point in some right directions anyway. > > Richard From sven.reimers at gmail.com Tue Jun 12 07:55:35 2012 From: sven.reimers at gmail.com (Sven Reimers) Date: Tue, 12 Jun 2012 16:55:35 +0200 Subject: Fwd: API REVIEW: Weak event handler In-Reply-To: References: <4FD72C57.1040609@oracle.com> Message-ID: Ups, forgot the mailinglist reply... Sorry for that. Sven ---------- Forwarded message ---------- From: Sven Reimers Date: Tue, Jun 12, 2012 at 4:55 PM Subject: Re: API REVIEW: Weak event handler To: Lubomir Nerad Any reason why public static WeakEventHandler create(EventHandler eventHandler) { ... } is not public static EventHandler create(EventHandler eventHandler) { ... } Is there a special use case why the usaer of the API should know about the implementation? From my ?point of view just hide it behind a static method call on EventHandler itself.. Regards Sven On Tue, Jun 12, 2012 at 1:47 PM, Lubomir Nerad wrote: > Hi All, > > there is a request to add a WeakEventHandler to the API > (http://javafx-jira.kenai.com/browse/RT-13706). This will be a simple > wrapper for the target event handler to which it will delegate the handle > calls. It will reference the target weakly and so it won't prevent it from > being garbage collected. > > My proposal for this class is: > > package javafx.event; > > public final class WeakEventHandler > ? ? ? ?extends WeakReference> > ? ? ? ?implements EventHandler { > > ? ?private WeakEventHandler(EventHandler eventHandler) { ... } > > ? ?@Override public void handle(final T event) { ... } > > ? ?public static WeakEventHandler > create(EventHandler eventHandler) { ... } > } > > I decided to make this class both an EventHandler (implements) and a > WeakReference (extends). Mainly I needed to have some way how to test from > event handler containers whether the target event handler for a stored > wrapper has been garbage collected and so the wrapper can be removed as > well. Extending WeakReference adds the required method (WeakReference.get()) > and saves some object instances. It also brings the clear method, which can > simplify testing of this feature. > > WeakEventHandler instances will be created through the create factory > method. This is to avoid repetition of the event type during event handler > registration. > > So instead of: > node.setOnMousePressed(new WeakEventHandler(new > EventHandler() { ... })); > > we can use: > node.setOnMousePressed(WeakEventHandler.create(new > EventHandler() { ... })); > > I also considered to define the WeakEventHandler as an interface which > extends EventHandler, but adds no additional methods. Then leave it to event > handler containers to reference such event handlers weakly. This has very > simple and direct usage, but also its own problems. We can discuss it > further if you find this solution preferred to the wrapper approach. > > Thanks, > Lubo > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * Community Leader? NetBeans: http://community.java.net/netbeans ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 ? ? ? ? ? ? ? ? ?? http://www.linkedin.com/groups?gid=107402 ? ? ? ? ? ? ? ? ?? http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * Community Leader? NetBeans: http://community.java.net/netbeans ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 ? ? ? ? ? ? ? ? ?? http://www.linkedin.com/groups?gid=107402 ? ? ? ? ? ? ? ? ?? http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From lubomir.nerad at oracle.com Tue Jun 12 08:15:02 2012 From: lubomir.nerad at oracle.com (Lubomir Nerad) Date: Tue, 12 Jun 2012 17:15:02 +0200 Subject: Fwd: API REVIEW: Weak event handler In-Reply-To: References: <4FD72C57.1040609@oracle.com> Message-ID: <4FD75CF6.80705@oracle.com> Hi Sven, > Any reason why > > public static WeakEventHandler > create(EventHandler eventHandler) { ... } > > is not > > public static EventHandler create(EventHandler > eventHandler) { ... } > > Is there a special use case why the usaer of the API should know about > the implementation? I don't see any harm specifying that we return WeakEventHandler from the method. The WeakEventHandler is to be part of the public API and anybody who will be creating some container for event handlers will need to be aware of it. > From my point of view just hide it behind a > static method call on EventHandler itself.. The EventHandler is an interface. > Regards > > Sven Thanks, Lubo > On Tue, Jun 12, 2012 at 1:47 PM, Lubomir Nerad wrote: >> Hi All, >> >> there is a request to add a WeakEventHandler to the API >> (http://javafx-jira.kenai.com/browse/RT-13706). This will be a simple >> wrapper for the target event handler to which it will delegate the handle >> calls. It will reference the target weakly and so it won't prevent it from >> being garbage collected. >> >> My proposal for this class is: >> >> package javafx.event; >> >> public final class WeakEventHandler >> extends WeakReference> >> implements EventHandler { >> >> private WeakEventHandler(EventHandler eventHandler) { ... } >> >> @Override public void handle(final T event) { ... } >> >> public static WeakEventHandler >> create(EventHandler eventHandler) { ... } >> } >> >> I decided to make this class both an EventHandler (implements) and a >> WeakReference (extends). Mainly I needed to have some way how to test from >> event handler containers whether the target event handler for a stored >> wrapper has been garbage collected and so the wrapper can be removed as >> well. Extending WeakReference adds the required method (WeakReference.get()) >> and saves some object instances. It also brings the clear method, which can >> simplify testing of this feature. >> >> WeakEventHandler instances will be created through the create factory >> method. This is to avoid repetition of the event type during event handler >> registration. >> >> So instead of: >> node.setOnMousePressed(new WeakEventHandler(new >> EventHandler() { ... })); >> >> we can use: >> node.setOnMousePressed(WeakEventHandler.create(new >> EventHandler() { ... })); >> >> I also considered to define the WeakEventHandler as an interface which >> extends EventHandler, but adds no additional methods. Then leave it to event >> handler containers to reference such event handlers weakly. This has very >> simple and direct usage, but also its own problems. We can discuss it >> further if you find this solution preferred to the wrapper approach. >> >> Thanks, >> Lubo >> > > > -- > Sven Reimers > > * Senior Expert Software Architect > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * Duke's Choice Award Winner 2009 > * Blog: http://nbguru.blogspot.com > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 > > From java.whoover at gmail.com Tue Jun 12 08:50:27 2012 From: java.whoover at gmail.com (Will Hoover) Date: Tue, 12 Jun 2012 11:50:27 -0400 Subject: JavaFX Form Validation In-Reply-To: <4FD5332A.5080608@oracle.com> References: <4FD5332A.5080608@oracle.com> Message-ID: <4fd76555.09d6e00a.463f.7a12@mx.google.com> Although you may disagree... The issue I see with a lot of validation frameworks is that they UI control centric. The problem with this approach is that it's very redundant. If you use the same entity/domain model fields in multiple controls (which happens more frequently than one would think- different forms) then the developer is left with the responsibility of ensuring the consistency of the validations across different UI controls. It also makes it a bit more difficult to manage validations between multiple UI controls (group validation) because an additional mechanism has to be introduced to handle cross-control validation. The potential of producing conflicting validation logic as an application increases in complexity becomes a much higher risk. Some see validation that impacts an applications domain models as being somewhat invasive, but I think that having multiple validation points in UI controls is far more problematic. In addition it's not perceived as invasive when it integrates with an existing entity-neutral framework ;) Florian's comment about JSR-349 looks like it may be promising. I really like the idea of integration of existing validation points from the Bean perspective. A lot of other frameworks have adopted this approach (like OpenJPA's use of JSR-303). I agree JSR-303 is a little dated and lacks a robust validation scheme, but maybe an active JavaFX role in JSR-349 may be an alternative? As you mention, the downside to this approach are cases where the validation isn't domain model specific. Although, IMHO, the use of validation that doesn't pertain to domain models is more of an exception to the rule versus the rule itself... My initial thought to resolve this would be to provide hooks into the Property API that allows you to define validation annotations that are not using a domain model: 1) With POJO domain model + a reusable BeanValidationAdaptor (similar to com.sun.javafx.fxml.BeanAdaptor): public class Person { @NotNull @Pattern(regexp="\\(\\d{3}\\)\\d{3}-\\d{4}") private String phoneNumber; public String getPhoneNumber(){return phoneNumber;} public void setPhoneNumber(String phoneNumber){this.phoneNumber = phoneNumber;} } BeanValidationAdaptor bva = new BeanValidationAdaptor<>(personInstance); TextField tf = new TextField(); Bindings.bindValidator(bva.stringProperty("phoneNumber"), tf.textProperty()); 2) With JavaFX specific model: public class PersonBean { @NotNull @Pattern(regexp="\\(\\d{3}\\)\\d{3}-\\d{4}") private StringProperty phoneNumber = new SimpleStringProperty(); public String getPhoneNumber(){return phoneNumber.get();} public void setPhoneNumber(String phoneNumber){phoneNumber.set(phoneNumber);} public StringProperty phoneNumberProperty() {return phoneNumber;} } TextField tf = new TextField(); Bindings.bindValidator(personBeanInstance.phoneNumberProperty(), tf.textProperty()); 3) With agonistic control (JavaFX provided ValidationProperty + ValidationEvent): ValidationProperty vp = new ValidationProperty<>() { @NotNull @Pattern(regexp="\\(\\d{3}\\)\\d{3}-\\d{4}") @Override public void validate(ValidationEvent event) { // if needed, additional fine-grain validation could also occur here using // event.getTarget(), event.getSource(), and event.consume() return super.validate(event); } }; TextField tf = new TextField(); Bindings.bindValidator(vp, tf.textProperty()); It would make bindings integration seem a bit more natural and self-contained, yet still provide the reusability of domain model validation annotations across tiers. All validation would be referenced in either domain model annotations or within annotations within the property itself. UI controls would not have to contain any validation definitions and would simply use internal triggers from underlying properties to propagate visual aides to the end user. -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Jonathan Giles Sent: Sunday, June 10, 2012 7:52 PM To: openjfx-dev at openjdk.java.net Subject: JavaFX Form Validation Hi all, I'm currently in the very, very early stages of developing a validation API for future inclusion into JavaFX. I thought rather than get too far into the research and development of a proof of concept, I would see what you all think. Any feedback now would be very useful. Essentially, there are a few common styles related to form validation. Some of the more likely approaches include: * The 'JGoodies Validation framework' [1] approach, where the developer provides a Validator that will then run over the form and gather feedback to return to the user (for example, it would test that the 'name field' is not empty, and that the email address is of the correct style - if either of these rules are invalid, the Validator would return ValidationMessage instances inside a ValidationResult). If validation fails the user is shown the text out of the ValidationMessage feedback, otherwise the form would submit as per usual. This validation may happen at a number of times (during form submission, when focus is lost, as a key is typed, etc). The nice thing about this approach is that the Validator can be a part of the domain model, the presentation model, or a separate thing altogether. * The JSR-303 approach which uses annotations to indicate the rules applicable to each field. These annotations are on the domain model, and therefore assumes that the form is directly tied to a domain object (which may not always be correct). I think the JSR-303 API is too complex for what is needed in JavaFX, but a similar implementation could be developed with a simpler API that follows this approach. * For lack of a better reference point, the FXForm approach [3] which encapsulates the validation inside a Form object that can be placed in the scene. I know this isn't explicitly (in the case of FXForm) about validation, but I think it is another approach to consider. So, what does JavaFX need out of a validation framework? It's really five things (I think): 1. A way for developers to validate a form by providing some means of specifying rules, as well as a way to specify when it runs, how it is visually represented, etc. 2. A way for the validation to impact upon the visual state of the form (using consistent CSS pseudoclass states / style classes, as well as by showing custom overlays, error messages beside the component (or grouped together at the top of the form)). There must be API to specify all of this. 3. Convenient API to simplify the validation process [3] (e.g. isEmpty(String), isAlphanumeric(String), etc, etc, etc). 4. An API that does not require it be integrated with UI controls. Doing so would prevent 3rd party UI controls to be able to be validated without also implementing the API, which may prove burdensome. Instead, the validation API should be separate. 5. A means to integrate nicely with the bindings and properties API present in JavaFX today. Of the three approaches above, my personal preference is to follow the JGoodies approach as I think it is the most powerful and flexible. However, nothing is set in stone and I want to learn what others think. Note that at present this research does not extend to considering whether there should be API related to automatically generating a form from a (JavaFX) bean (and making use of the validation API to ensure the input is correct). However, I am not against discussing this topic as well, as long as it too integrates nicely with the rules above, as well as the validation API itself, obviously. This research may full into requirement three above. [1] http://www.jgoodies.com/freeware/libraries/validation/ [2] https://github.com/dooApp/FXForm2 [3] http://www.jarvana.com/jarvana/view/com/jgoodies/validation/2.0.1/validation -2.0.1-javadoc.jar!/com/jgoodies/validation/util/ValidationUtils.html Thanks, -- Jonathan From hang.vo at oracle.com Tue Jun 12 09:48:31 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Jun 2012 16:48:31 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-21735: Canvas Scale and Size do not sync Message-ID: <20120612164835.72D4D4789D@hg.openjdk.java.net> Changeset: 9def6759a1f2 Author: "Joseph Andresen" Date: 2012-06-12 09:33 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/9def6759a1f2 RT-21735: Canvas Scale and Size do not sync ! javafx-ui-common/src/javafx/scene/canvas/Canvas.java From hang.vo at oracle.com Tue Jun 12 10:18:40 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Jun 2012 17:18:40 +0000 Subject: hg: openjfx/2.2/graphics/rt: 43 new changesets Message-ID: <20120612171917.ACDDB4789E@hg.openjdk.java.net> Changeset: c43de60706fc Author: jgiles Date: 2012-06-02 09:27 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/c43de60706fc RT-21988: Controls CSS should not check screen resolution unless on an embedded device ! javafx-ui-controls/src/javafx/scene/control/UAStylesheetLoader.java Changeset: 222c53eada42 Author: jgiles Date: 2012-06-02 09:28 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/222c53eada42 [DOC ONLY] Improved ComboBox javadoc to talk about how to use the buttonCell API to custom the button appearance. ! javafx-ui-controls/src/javafx/scene/control/ComboBox.java Changeset: cf257b36b8d1 Author: jgiles Date: 2012-06-02 10:14 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/cf257b36b8d1 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 32f6a7948935 Author: jgiles Date: 2012-06-05 12:23 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/32f6a7948935 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: aa001f13bd63 Author: leifs Date: 2012-06-04 17:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/aa001f13bd63 Fixed RT-21806: NLS: Please keep non-translatable resource strings in a separate resource file ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/EmbeddedResources.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls.properties + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/embedded.properties Changeset: aa28336a1e58 Author: leifs Date: 2012-06-05 10:42 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/aa28336a1e58 Fixed RT-22054: TextInputControl default editing actions badly handled when TextInputControl is not editable ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java Changeset: 46dadf1d60fc Author: Kinsley Wong Date: 2012-06-05 14:44 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/46dadf1d60fc RT-20931: GridPaneDesignInfo.getCellBounds() is not consistent with GridPane.getLayoutBounds(). ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/test/unit/javafx/scene/layout/GridPaneTest.java Changeset: b855ec5afa28 Author: Kinsley Wong Date: 2012-06-05 16:49 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/b855ec5afa28 RT-22026: [Pagination] need strict specification of behavior on max page indicators count. ! javafx-ui-controls/src/javafx/scene/control/Pagination.java ! javafx-ui-controls/test/javafx/scene/control/PaginationTest.java Changeset: bbf040d2b20e Author: Kinsley Wong Date: 2012-06-05 16:54 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/bbf040d2b20e RT-21910: [DOC ONLY] Pagination callback property default value is not specified. ! javafx-ui-controls/src/javafx/scene/control/Pagination.java Changeset: 819d61e7effb Author: Paru Somashekar Date: 2012-06-05 23:39 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/819d61e7effb fix RT-20285 MemoryLeak in javafx.scene.controls.MenuBar ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java Changeset: a447a52d7abd Author: mickf Date: 2012-06-06 15:47 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a447a52d7abd RT-21090 : ListView ignores initial scrolling ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/VirtualFlowTest.java Changeset: 1f9d7d6bb729 Author: Kinsley Wong Date: 2012-06-06 10:19 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/1f9d7d6bb729 RT22012: Pagination AIOBE when size is set small. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: d82a7c6d2cac Author: Kinsley Wong Date: 2012-06-06 11:20 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/d82a7c6d2cac RT-22098: [Pagination] current page is not updated, when page count is reduced. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: c0039fe78883 Author: Kinsley Wong Date: 2012-06-06 11:23 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/c0039fe78883 Merge Changeset: a3977b2b77b5 Author: leifs Date: 2012-06-06 13:06 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a3977b2b77b5 Fixed RT-21788: Handles should be displayed in TextBox components, not outside. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/embedded.css Changeset: 0cbd6a3c74bb Author: leifs Date: 2012-06-06 13:26 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/0cbd6a3c74bb Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt Changeset: b14d29378d60 Author: leifs Date: 2012-06-06 13:44 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/b14d29378d60 Virtual keyboard: disable VK for non-editable text controls. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java Changeset: c03a7b34ec86 Author: Kinsley Wong Date: 2012-06-06 16:37 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/c03a7b34ec86 RT-22106: Cancel and Default buttons still receive onAction events triggered by ESC and Enter keys when they are removed from the scene. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ButtonSkin.java ! javafx-ui-controls/test/javafx/scene/control/ButtonTest.java Changeset: b2064c0c3ba3 Author: jgiles Date: 2012-06-05 14:56 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/b2064c0c3ba3 RT-22038: HelloTableView layout problem ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableCellSkin.java Changeset: 12c454b407e2 Author: jgiles Date: 2012-06-05 15:40 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/12c454b407e2 RT-21336: Not editable ComboBox does not paint value setting by code (setValue()) when it does not exist in the list. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 612f0c898954 Author: jgiles Date: 2012-06-06 10:59 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/612f0c898954 RT-21207: ComboBox list width doesn't fit its content when first displayed (if the content is dynamically generated onShowing) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java Changeset: 0f911a5c52bb Author: jgiles Date: 2012-06-06 13:09 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/0f911a5c52bb RT-22025: [ComboBox] initial size doesn't respond the size of the widest content ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 29dd9c8675ec Author: jgiles Date: 2012-06-07 11:13 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/29dd9c8675ec RT-21341: TableView: Moving column to the left of next column moves it to the right of the next column ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkin.java Changeset: 9897f5b8a23d Author: jgiles Date: 2012-06-07 12:51 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/9897f5b8a23d RT-22122: When reordering TableColumns in a TableView, sometimes the header area disappears ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableHeaderRow.java Changeset: 60301b7fd01f Author: jgiles Date: 2012-06-07 13:43 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/60301b7fd01f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: defcb2e3aa77 Author: mickf Date: 2012-06-07 18:03 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/defcb2e3aa77 RT-21952 : Click on button opens context menu ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ButtonSkin.java ! javafx-ui-controls/test/javafx/scene/control/ButtonTest.java Changeset: 966cbfed8d62 Author: mickf Date: 2012-06-07 19:50 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/966cbfed8d62 RT-21782 - Embedded : ScrollPane : ScrollBars need to account for corner when both are present. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java Changeset: dfa7572ff039 Author: Kinsley Wong Date: 2012-06-07 12:47 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/dfa7572ff039 RT-22027: Exception raised for a ComboBox in an Accordion. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/AccordionBehavior.java ! javafx-ui-controls/test/javafx/scene/control/AccordionTest.java Changeset: abbc696491cb Author: mickf Date: 2012-06-08 16:04 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/abbc696491cb RT-19754 - CSS: -fx-padding doesn't work properly on ProgressIndicator ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java Changeset: c7813fd4d4a0 Author: mickf Date: 2012-06-08 18:15 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/c7813fd4d4a0 RT-19738 : Invalid layout behavior with rotates applied ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java Changeset: e1200e6556ab Author: Paru Somashekar Date: 2012-06-08 11:23 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/e1200e6556ab RT-20285 memory leak in javafx.scene.controls.MenuBar ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java Changeset: 527e107cfec5 Author: Paru Somashekar Date: 2012-06-08 12:52 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/527e107cfec5 RT-21891 ChoiceBox popup looks strange after refilling. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ChoiceBoxSkin.java Changeset: 8bc39da3d194 Author: leifs Date: 2012-06-11 10:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/8bc39da3d194 Fixed RT-21658: Touch : TextArea : hard to differentiate between block selection and scrolling ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java Changeset: 85d4575070f8 Author: leifs Date: 2012-06-11 10:45 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/85d4575070f8 Fixed RT-22112: ComboBox : regression with editor selection ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java Changeset: 52cf4be61cfe Author: leifs Date: 2012-06-11 11:02 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/52cf4be61cfe Corrected fix for RT-21788: Adjust padding in TextArea and TextField for Embedded. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/embedded-qvga.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/embedded.css Changeset: 6809fcdc77f4 Author: leifs Date: 2012-06-11 13:04 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/6809fcdc77f4 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt Changeset: f848576e5df0 Author: jgiles Date: 2012-06-07 15:15 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/f848576e5df0 RT-20945: ComboBox, computing the items inside showing property handler fires unwanted onAction event ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java Changeset: d09cc9910784 Author: jgiles Date: 2012-06-08 13:56 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/d09cc9910784 RT-22079: No change event on selection when selected row is removed from TableView ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: 634e4bbb4cf5 Author: jgiles Date: 2012-06-08 15:15 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/634e4bbb4cf5 RT-22077: TableView updates not working when ValueFactory returns a new Binding ! javafx-ui-controls/src/javafx/scene/control/TableCell.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java Changeset: cc8d7f8bbab8 Author: jgiles Date: 2012-06-12 09:44 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/cc8d7f8bbab8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 388637d028f3 Author: jgiles Date: 2012-06-12 15:17 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/388637d028f3 Reinstating a commented out public method on TableColumn that was commented out by mistake in a previous changeset. Unit tests failed because of this, and now pass again. ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java Changeset: a636b9ba88ac Author: jgiles Date: 2012-06-12 16:55 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a636b9ba88ac Fix for second unit test failure, this time related to listview selection events not firing properly when the row index does not change, but the selected item does. ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java Changeset: 00a63ce77e97 Author: Yao Wang Date: 2012-06-12 10:07 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/00a63ce77e97 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt - javafx-ui-common/test/unit/javafx/scene/input/TouchPoint_builder_Test.java From lehmann at media-interactive.de Tue Jun 12 10:35:24 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Tue, 12 Jun 2012 19:35:24 +0200 Subject: JavaFX Form Validation In-Reply-To: <4fd76555.09d6e00a.463f.7a12@mx.google.com> References: <4FD5332A.5080608@oracle.com> <4fd76555.09d6e00a.463f.7a12@mx.google.com> Message-ID: <4FD77DDC.4080806@media-interactive.de> Hi Will, On 12.06.2012 17:50, Will Hoover wrote: > Although, IMHO, the use of validation that doesn't pertain to domain > models is more of an exception to the rule versus the rule itself... I suppose most people tend to think that other usecases are the special cases while the own usecase is the common one. There is probably no way to know for sure what the exception is and what it is not. In the end it makes sense to have a framework with as few limitations as possible. Your suggestion assumes that a domain bean backs most UIs (at least when validation is required). I don't think that is true, and I don't like to create a domain bean for the sake of validation. Furthermore, not every domain bean property translates to exactly one control. And typically, domain beans do not have JavaFX style properties. > The problem with this approach is that it's very redundant. If you > use the same entity/domain model fields in multiple controls (which > happens more frequently than one would think- different forms) then > the developer is left with the responsibility of ensuring the > consistency of the validations across different UI controls. Redundancy is bad but: if your validation patterns etc can be discovered automatically (e.g. with your pattern annotation) it should be possible to connect your validation with whatever JavaFX validation we will end up with. Sounds like a form of the mediator pattern. Surely this can be made in a generic way. Rgds Werner From tbee at tbee.org Tue Jun 12 10:44:56 2012 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 12 Jun 2012 19:44:56 +0200 Subject: JavaFX Form Validation In-Reply-To: <4FD77DDC.4080806@media-interactive.de> References: <4FD5332A.5080608@oracle.com> <4fd76555.09d6e00a.463f.7a12@mx.google.com> <4FD77DDC.4080806@media-interactive.de> Message-ID: <4FD78018.4090900@tbee.org> Point being that the validators should be pluggable and customizable, so use an annotation approach as the basis would be bad. The other way around, validators that take their cues from annotations, would be good. Tom On 2012-06-12 19:35, Werner Lehmann wrote: > Hi Will, > > On 12.06.2012 17:50, Will Hoover wrote: >> Although, IMHO, the use of validation that doesn't pertain to domain >> models is more of an exception to the rule versus the rule itself... > > I suppose most people tend to think that other usecases are the special > cases while the own usecase is the common one. There is probably no way > to know for sure what the exception is and what it is not. In the end it > makes sense to have a framework with as few limitations as possible. > > Your suggestion assumes that a domain bean backs most UIs (at least when > validation is required). I don't think that is true, and I don't like to > create a domain bean for the sake of validation. > > Furthermore, not every domain bean property translates to exactly one > control. And typically, domain beans do not have JavaFX style properties. > >> The problem with this approach is that it's very redundant. If you >> use the same entity/domain model fields in multiple controls (which >> happens more frequently than one would think- different forms) then >> the developer is left with the responsibility of ensuring the >> consistency of the validations across different UI controls. > > Redundancy is bad but: if your validation patterns etc can be discovered > automatically (e.g. with your pattern annotation) it should be possible > to connect your validation with whatever JavaFX validation we will end > up with. Sounds like a form of the mediator pattern. Surely this can be > made in a generic way. > > Rgds > Werner From hang.vo at oracle.com Tue Jun 12 10:48:16 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Jun 2012 17:48:16 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-20937 missing javadoc for some MenuItem properties Message-ID: <20120612174819.15FAC478A0@hg.openjdk.java.net> Changeset: 8192bc3aa019 Author: Paru Somashekar Date: 2012-06-12 10:39 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/8192bc3aa019 RT-20937 missing javadoc for some MenuItem properties RT-19747 piechart is not affected by -fx-pie-label-visible RT-13081 ChartSampler demo / set new data leads to NPE. ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java ! javafx-ui-charts/src/javafx/scene/chart/ScatterChart.java ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java From java.whoover at gmail.com Tue Jun 12 11:02:47 2012 From: java.whoover at gmail.com (Will Hoover) Date: Tue, 12 Jun 2012 14:02:47 -0400 Subject: JavaFX Form Validation In-Reply-To: <4FD77DDC.4080806@media-interactive.de> References: <4FD5332A.5080608@oracle.com> <4fd76555.09d6e00a.463f.7a12@mx.google.com> <4FD77DDC.4080806@media-interactive.de> Message-ID: <4fd78459.87b7e00a.0217.ffff908a@mx.google.com> Werner, Most enterprise level systems that I've experienced use domain models in their applications. Don't get me wrong I think it's a valid use case to use a control without them. I just think it's a minority of cases. I could be wrong :) I'm with you... I don't like to create domain beans for the sake of validation, but at some point you will have to create some kind of class to define validation. JavaFX providing implementation specific validation like the suggested new MandatoryValidator(), new UserNameValidator(), etc. may sound like a great idea, but I think that this will open the floodgates for other specific validation requests that will eventually cause unnecessary bloat to the framework. Maybe a generic regex version may be more appropriate? Your right, not every bean property would translate into one control. The suggested property approach would allow you to reuse the properties across multiple controls. Nothing prevents you from binding the same validation property to multiple controls. The validation/mediator pattern you are referring to seems to lend itself to my suggested approach, no? -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Werner Lehmann Sent: Tuesday, June 12, 2012 1:35 PM To: openjfx-dev at openjdk.java.net Subject: Re: JavaFX Form Validation Hi Will, On 12.06.2012 17:50, Will Hoover wrote: > Although, IMHO, the use of validation that doesn't pertain to domain > models is more of an exception to the rule versus the rule itself... I suppose most people tend to think that other usecases are the special cases while the own usecase is the common one. There is probably no way to know for sure what the exception is and what it is not. In the end it makes sense to have a framework with as few limitations as possible. Your suggestion assumes that a domain bean backs most UIs (at least when validation is required). I don't think that is true, and I don't like to create a domain bean for the sake of validation. Furthermore, not every domain bean property translates to exactly one control. And typically, domain beans do not have JavaFX style properties. > The problem with this approach is that it's very redundant. If you use > the same entity/domain model fields in multiple controls (which > happens more frequently than one would think- different forms) then > the developer is left with the responsibility of ensuring the > consistency of the validations across different UI controls. Redundancy is bad but: if your validation patterns etc can be discovered automatically (e.g. with your pattern annotation) it should be possible to connect your validation with whatever JavaFX validation we will end up with. Sounds like a form of the mediator pattern. Surely this can be made in a generic way. Rgds Werner From java.whoover at gmail.com Tue Jun 12 11:20:57 2012 From: java.whoover at gmail.com (Will Hoover) Date: Tue, 12 Jun 2012 14:20:57 -0400 Subject: JavaFX Form Validation In-Reply-To: <4FD78018.4090900@tbee.org> References: <4FD5332A.5080608@oracle.com> <4fd76555.09d6e00a.463f.7a12@mx.google.com> <4FD77DDC.4080806@media-interactive.de> <4FD78018.4090900@tbee.org> Message-ID: <4fd7889b.47d0e00a.2e05.ffff9515@mx.google.com> I agree. My proposal includes both. Option 1 would cause validators to get their cues from annotations and is pluggable from the viewpoint that they are using a generic javax.validation.constraints implementation. To accommodate the use case of a more fine-grain, but more invasive approach, there is Option 2 and 3. All of which are using the same internal plumbing to get the job done. As an added bonus that will introduce even more fluidity to the "customizable" concept you can use the javax.validation.Constraint that allows you to do something like: @Retention(RUNTIME) @Target({METHOD, FIELD, ANNOTATION_TYPE}) @Constraint(validatedBy=MyValidator.class) public @interface MyValidation { ... } @MyValidation public class Person { ... } or public class Person { @MyValidation private String phoneNumber; } -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Tom Eugelink Sent: Tuesday, June 12, 2012 1:45 PM To: openjfx-dev at openjdk.java.net Subject: Re: JavaFX Form Validation Point being that the validators should be pluggable and customizable, so use an annotation approach as the basis would be bad. The other way around, validators that take their cues from annotations, would be good. Tom On 2012-06-12 19:35, Werner Lehmann wrote: > Hi Will, > > On 12.06.2012 17:50, Will Hoover wrote: >> Although, IMHO, the use of validation that doesn't pertain to domain >> models is more of an exception to the rule versus the rule itself... > > I suppose most people tend to think that other usecases are the > special cases while the own usecase is the common one. There is > probably no way to know for sure what the exception is and what it is > not. In the end it makes sense to have a framework with as few limitations as possible. > > Your suggestion assumes that a domain bean backs most UIs (at least > when validation is required). I don't think that is true, and I don't > like to create a domain bean for the sake of validation. > > Furthermore, not every domain bean property translates to exactly one > control. And typically, domain beans do not have JavaFX style properties. > >> The problem with this approach is that it's very redundant. If you >> use the same entity/domain model fields in multiple controls (which >> happens more frequently than one would think- different forms) then >> the developer is left with the responsibility of ensuring the >> consistency of the validations across different UI controls. > > Redundancy is bad but: if your validation patterns etc can be > discovered automatically (e.g. with your pattern annotation) it should > be possible to connect your validation with whatever JavaFX validation > we will end up with. Sounds like a form of the mediator pattern. > Surely this can be made in a generic way. > > Rgds > Werner From jonathan.giles at oracle.com Tue Jun 12 12:46:44 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 13 Jun 2012 07:46:44 +1200 Subject: API REVIEW: Weak event handler In-Reply-To: <4FD72C57.1040609@oracle.com> References: <4FD72C57.1040609@oracle.com> Message-ID: <4FD79CA4.3070609@oracle.com> For what it is worth, the UI controls team have a WeakEventHandler class in com.sun.javafx.scene.control. It does not follow quite the same direction as you have outlined, but you may find it interesting nonetheless. It would be good to remove our implementation once the public API becomes available, but I can't imagine you'd be adding the WeakEventHandler as a feature into 2.2 now, would you? -- Jonathan On 12/06/2012 11:47 p.m., Lubomir Nerad wrote: > Hi All, > > there is a request to add a WeakEventHandler to the API > (http://javafx-jira.kenai.com/browse/RT-13706). This will be a simple > wrapper for the target event handler to which it will delegate the > handle calls. It will reference the target weakly and so it won't > prevent it from being garbage collected. > > My proposal for this class is: > > package javafx.event; > > public final class WeakEventHandler > extends WeakReference> > implements EventHandler { > > private WeakEventHandler(EventHandler eventHandler) { ... } > > @Override public void handle(final T event) { ... } > > public static WeakEventHandler > create(EventHandler eventHandler) { ... } > } > > I decided to make this class both an EventHandler (implements) and a > WeakReference (extends). Mainly I needed to have some way how to test > from event handler containers whether the target event handler for a > stored wrapper has been garbage collected and so the wrapper can be > removed as well. Extending WeakReference adds the required method > (WeakReference.get()) and saves some object instances. It also brings > the clear method, which can simplify testing of this feature. > > WeakEventHandler instances will be created through the create factory > method. This is to avoid repetition of the event type during event > handler registration. > > So instead of: > node.setOnMousePressed(new WeakEventHandler(new > EventHandler() { ... })); > > we can use: > node.setOnMousePressed(WeakEventHandler.create(new > EventHandler() { ... })); > > I also considered to define the WeakEventHandler as an interface which > extends EventHandler, but adds no additional methods. Then leave it to > event handler containers to reference such event handlers weakly. This > has very simple and direct usage, but also its own problems. We can > discuss it further if you find this solution preferred to the wrapper > approach. > > Thanks, > Lubo > From richard.bair at oracle.com Tue Jun 12 12:50:42 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 12 Jun 2012 12:50:42 -0700 Subject: JavaFX Task/Service thread checks In-Reply-To: <4FD65DD6.9050302@xs4all.nl> References: <4FD5B0F2.1080908@xs4all.nl> <057F3E46-C275-4337-9D94-17450D3ED7D3@oracle.com> <4FD65DD6.9050302@xs4all.nl> Message-ID: > Could you explain what the issues are when different Threads have listeners attached to a Task's stateProperty? AFAIK, all the listeners get fired (one by one) on the fx thread, not on the thread that attached the listener in the first place. I think that is the main thing. You end up adding a listener from some thread, but then that listener is called back on the FX thread, which may be surprising. Rather, we force you to face the fact that it is going to be on a different thread. > I can understand that a method like setState() (if it existed) must be called from the fx-thread, as that could cause listeners to fire (which must be on the fx thread afaik)... but attaching a listener should be possible from any thread (barring issues with managing and traversing the listener list itself -- those would need synchronization) ...... I guess that last one probably touches upon why this thread check is there as the other thread would be holding a lock preventing the fx-thread from proceeding -- although such a lock would never be held for long... That as well, that the code is simpler without it. But that isn't sufficient reason in and off itself (adding synchronized is easy enough). Thanks Richard From richard.bair at oracle.com Tue Jun 12 13:01:00 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 12 Jun 2012 13:01:00 -0700 Subject: API REVIEW: Weak event handler In-Reply-To: <4FD72C57.1040609@oracle.com> References: <4FD72C57.1040609@oracle.com> Message-ID: <934EC5B5-0318-4580-B000-AFCA69E62384@oracle.com> Hi Lubo, > I also considered to define the WeakEventHandler as an interface which extends EventHandler, but adds no additional methods. Then leave it to event handler containers to reference such event handlers weakly. This has very simple and direct usage, but also its own problems. We can discuss it further if you find this solution preferred to the wrapper approach. Extending WeakReference and lacking the public constructor did make me a little weak in the knees :-). What were the problems with WeakEventHandler being an interface? Thanks! Richard From sven.reimers at gmail.com Tue Jun 12 13:28:03 2012 From: sven.reimers at gmail.com (Sven Reimers) Date: Tue, 12 Jun 2012 22:28:03 +0200 Subject: API REVIEW: Weak event handler In-Reply-To: <934EC5B5-0318-4580-B000-AFCA69E62384@oracle.com> References: <4FD72C57.1040609@oracle.com> <934EC5B5-0318-4580-B000-AFCA69E62384@oracle.com> Message-ID: Ok. Here is a link to the JavaDoc how NetBeans handles this for PropertyChanges http://bits.netbeans.org/dev/javadoc/org-openide-util/org/openide/util/WeakListeners.html I still do not understand the necessity for creating a new interface, it contains no additional information (API) - for the user it can only be used as an EventListener (assuming there will be no API explicitly requiring WeakEventListener).. Regards Sven On Tue, Jun 12, 2012 at 10:01 PM, Richard Bair wrote: > Hi Lubo, > >> I also considered to define the WeakEventHandler as an interface which extends EventHandler, but adds no additional methods. Then leave it to event handler containers to reference such event handlers weakly. This has very simple and direct usage, but also its own problems. We can discuss it further if you find this solution preferred to the wrapper approach. > > Extending WeakReference and lacking the public constructor did make me a little weak in the knees :-). What were the problems with WeakEventHandler being an interface? > > Thanks! > Richard -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * Community Leader? NetBeans: http://community.java.net/netbeans ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 ? ? ? ? ? ? ? ? ?? http://www.linkedin.com/groups?gid=107402 ? ? ? ? ? ? ? ? ?? http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From hang.vo at oracle.com Tue Jun 12 14:49:27 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Jun 2012 21:49:27 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22326: TabPane: unable to select the following tab when a tab is closed. Message-ID: <20120612214929.8AFBC478AB@hg.openjdk.java.net> Changeset: 6e34b405d07e Author: Kinsley Wong Date: 2012-06-12 14:30 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/6e34b405d07e RT-22326: TabPane: unable to select the following tab when a tab is closed. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TabPaneBehavior.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java From hang.vo at oracle.com Tue Jun 12 16:48:31 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Jun 2012 23:48:31 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-20104 Tooltip missing textAlignment javadoc Message-ID: <20120612234833.137F7478AF@hg.openjdk.java.net> Changeset: 9d72813b0448 Author: Paru Somashekar Date: 2012-06-12 16:49 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/9d72813b0448 RT-20104 Tooltip missing textAlignment javadoc ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java From hang.vo at oracle.com Tue Jun 12 18:03:06 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Jun 2012 01:03:06 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22415: Adding an item to SplitPane may hang FX Message-ID: <20120613010306.E155F478B1@hg.openjdk.java.net> Changeset: 2f475847df17 Author: Kinsley Wong Date: 2012-06-12 17:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/2f475847df17 RT-22415: Adding an item to SplitPane may hang FX ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SplitPaneSkin.java From hjohn at xs4all.nl Tue Jun 12 20:59:06 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Wed, 13 Jun 2012 05:59:06 +0200 Subject: API REVIEW: Weak event handler In-Reply-To: <4FD72C57.1040609@oracle.com> References: <4FD72C57.1040609@oracle.com> Message-ID: <4FD8100A.6050707@xs4all.nl> This seems to be significantly different from how WeakInvalidationListener and WeakChangeListener are implemented, should they not be the same? On 12/06/2012 13:47, Lubomir Nerad wrote: > Hi All, > > there is a request to add a WeakEventHandler to the API > (http://javafx-jira.kenai.com/browse/RT-13706). This will be a simple > wrapper for the target event handler to which it will delegate the > handle calls. It will reference the target weakly and so it won't > prevent it from being garbage collected. > > My proposal for this class is: > > package javafx.event; > > public final class WeakEventHandler > extends WeakReference> > implements EventHandler { > > private WeakEventHandler(EventHandler eventHandler) { ... } > > @Override public void handle(final T event) { ... } > > public static WeakEventHandler > create(EventHandler eventHandler) { ... } > } > > I decided to make this class both an EventHandler (implements) and a > WeakReference (extends). Mainly I needed to have some way how to test > from event handler containers whether the target event handler for a > stored wrapper has been garbage collected and so the wrapper can be > removed as well. Extending WeakReference adds the required method > (WeakReference.get()) and saves some object instances. It also brings > the clear method, which can simplify testing of this feature. > > WeakEventHandler instances will be created through the create factory > method. This is to avoid repetition of the event type during event > handler registration. > > So instead of: > node.setOnMousePressed(new WeakEventHandler(new > EventHandler() { ... })); > > we can use: > node.setOnMousePressed(WeakEventHandler.create(new > EventHandler() { ... })); > > I also considered to define the WeakEventHandler as an interface which > extends EventHandler, but adds no additional methods. Then leave it to > event handler containers to reference such event handlers weakly. This > has very simple and direct usage, but also its own problems. We can > discuss it further if you find this solution preferred to the wrapper > approach. > > Thanks, > Lubo > From hjohn at xs4all.nl Tue Jun 12 21:16:48 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Wed, 13 Jun 2012 06:16:48 +0200 Subject: Debugging a UI refresh problem (not dirtyopts related it seems) Message-ID: <4FD81430.3070905@xs4all.nl> Hi List, I'm having a problem that started when I upgraded from JavaFX 2.1 to 2.2b11 -- I want to submit a bug report for it, but having trouble reproducing it outside my main code. Basically, what is happening is that during navigation between different parts of the application, sometimes the screen is not being redrawn properly (for some background info, the screen in my app consists of a screen filling background picture, with on top of this a big list with images/text). Basically, what I'm seeing is this: Step 1: StackPane with 2 children (background picture, and overlaid on top of that a List with names) Step 2: StackPane with same background picture, but no controls over laid... (the background picture is doing a 5 second fade out/in animation because every screen has its own picture, so redrawing is happening a lot) Now, if I press cursor up/down, then the list suddenly appears, which makes me think it is a redraw issue (this also means that the control had focus, but is not drawn). In between the two steps a lot of code happens in my app, but the crucial part is that at some point the old List is removed (from step 1) and then replaced (in the same StackPane) with a new, different, List. No exceptions or anything else out of the ordinary happens, the new child is simply not drawn (or perhaps sized incorrectly, rendering it invisible -- or perhaps drawn in the wrong order appearing behind the BG picture (although it is the last child in the StackPane)). As said, moving the cursor makes it appear -- and it did work with JavaFX 2.1. Note that my Lists donot have any kind of "hover" highlighting effects or any other animations (unlike the standard JavaFX lists), so there's a good chance that if JavaFX did not decide to draw my List the first time when it was added to the StackPane that nothing will trigger it to be drawn until the cursor up/down happens... Any ideas on how to best debug this? I've already tried setting dirtyopts to false... anything else I can try? It is fairly easy to reproduce in my app. From hang.vo at oracle.com Tue Jun 12 21:33:27 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Jun 2012 04:33:27 +0000 Subject: hg: openjfx/2.2/controls/rt: 7 new changesets Message-ID: <20120613043334.B0AE6478B9@hg.openjdk.java.net> Changeset: 35c426930d23 Author: jgiles Date: 2012-06-12 20:21 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/35c426930d23 RT-21586: ListView: Replacing all items does not clear selection ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: b6f81f47c4c8 Author: jgiles Date: 2012-06-13 09:44 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/b6f81f47c4c8 RT-22428: TableColumns are appearing collapsed by default ! javafx-ui-controls/src/javafx/scene/control/TableCell.java Changeset: 541a5c63514f Author: jgiles Date: 2012-06-13 13:19 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/541a5c63514f RT-22191: TableView: Performance degrades when resetting content ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: 06a917ba0bfa Author: jgiles Date: 2012-06-13 13:43 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/06a917ba0bfa RT-22385: TableView leaks memory ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkin.java ! javafx-ui-controls/src/javafx/scene/control/TableCell.java Changeset: 8dc0f0d957e0 Author: jgiles Date: 2012-06-13 14:20 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/8dc0f0d957e0 RT-20840: fx2.2-h17-b01: Adding new column to TableView results in creating new N columns instead of 1 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java Changeset: b618eb1ac127 Author: jgiles Date: 2012-06-13 15:36 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/b618eb1ac127 RT-22391: Removing a nested TableColumn from its parent column resets the tableView property of the parent to null ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java Changeset: e6d1c213886d Author: jgiles Date: 2012-06-13 16:18 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/e6d1c213886d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt From randahl at rockit.dk Wed Jun 13 03:00:27 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Wed, 13 Jun 2012 12:00:27 +0200 Subject: JavaFX Form Validation In-Reply-To: <4fd7889b.47d0e00a.2e05.ffff9515@mx.google.com> References: <4FD5332A.5080608@oracle.com> <4fd76555.09d6e00a.463f.7a12@mx.google.com> <4FD77DDC.4080806@media-interactive.de> <4FD78018.4090900@tbee.org> <4fd7889b.47d0e00a.2e05.ffff9515@mx.google.com> Message-ID: <4FD864BB.7080105@rockit.dk> Jonathan, I think there is an important aspect of form validation which we have not yet discussed. In traditional web-based UI's, validating data at the UI layer may be considered sufficient, since the organization has total control over the UI layer validators, as they are executed server side. With JavaFX this is quite different, as the UI layer is running outside the server on an end user's PC. So, if the validity of certain fields is critical to system data integrity, it would be wrong to only run the validators in the JavaFX client application, since the application could have been modified, the network communication could have been compromised, etc. Consequently, the JavaFX validation system must be one, which allows rerunning the validators server-side, to ensure that developers will not have to rewrite validation code in multiple layers of the same application. As an example, if my application has specific requirements for user passwords, I would like to be able to define some kind of PasswordValidator and have JavaFX run it before data is sent to the server side; but obviously, I would want to rerun this PasswordValidator on the server before updating a user's password, to ensure that a malicious person could not have circumvented the validation by, say, altering the JavaFX application Java code. I noticed this topic is also discussed in JSR-349, the specification for Bean Validation: Validating data is a common task that occurs throughout an application, from the presentation layer to the persistence layer. Often the same validation logic is implemented in each layer, proving to be time consuming and error- prone. [...] The validation API developed by this JSR is not intended for use in any one tier or programming model. It is specifically not tied to either the web tier or the persistence tier, and is available for both server-side application programming, as well as rich client Swing application developers. This API is seen as a general extension to the Java- Beans object model, and as such is expected to be used as a core component in other specifications. Ease of use and flexibility have influenced the design of this specification. Now, I believe we should think twice before ditching the years of work which has gone into developing first JSR-303 and then the follow-up JSR-349. Making JavaFX compatible with these standards would mean 1. JavaFX validation would be recognizable to those Java EE developers who are already familiar with the Bean Validation standard. 2. JavaFX would avoid fragmenting the Java platform once again by introducing yet another solution to the same problem. 3. JavaFX applications would be able to reuse validators written for other (non-JavaFX) Java systems. 4. The validators used in JavaFX would be rerunnable in any application layer. On our openjfx-dev mailing list the JSR-303 and JSR-349 have been critizised for requiring annotations in the domain model classes, as in the following example: public class Address { @NotNull(message="the city is mandatory", payload=Severity.Error.class) String getCity() {...} } Having thought about this for a while, I disagree with the critics. The domain model classes are part of the API contract which the server presents to clients, so what would be more natural than strengthening this contract by adding validation constraints to it? Ideally, The PasswordValidator I mention above should be delivered alongside my domain model User class so both the JavaFX client application layer as well as the server business logic layer of my application could run it and be certain that the password specified lives up to system requirements. As we all know, JavaFX is but a single piece in the large technology puzzle upon which our applications are built. It is crucial, that JavaFX fits with the other pieces. Yours Randahl From tbee at tbee.org Wed Jun 13 03:08:55 2012 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 13 Jun 2012 12:08:55 +0200 Subject: JavaFX Form Validation In-Reply-To: <4FD864BB.7080105@rockit.dk> References: <4FD5332A.5080608@oracle.com> <4fd76555.09d6e00a.463f.7a12@mx.google.com> <4FD77DDC.4080806@media-interactive.de> <4FD78018.4090900@tbee.org> <4fd7889b.47d0e00a.2e05.ffff9515@mx.google.com> <4FD864BB.7080105@rockit.dk> Message-ID: <4FD866B7.3000007@tbee.org> As I see it, if the validators in fact are separate classes that are applied to a data structure (BM, business process, client side backing bean), then it would be very well possible to have these validators in a separate project / artifact, that is both shared by the server and the client (given that the developers are smart enough to use identical data constructs on both sides). Then you would be able to reuse the validators. Tom On 13-6-2012 12:00, Randahl Fink Isaksen wrote: > Jonathan, I think there is an important aspect of form validation which we have not yet discussed. In traditional web-based UI's, validating data at the UI layer may be considered sufficient, since the organization has total control over the UI layer validators, as they are executed server side. With JavaFX this is quite different, as the UI layer is running outside the server on an end user's PC. > > So, if the validity of certain fields is critical to system data integrity, it would be wrong to only run the validators in the JavaFX client application, since the application could have been modified, the network communication could have been compromised, etc. Consequently, the JavaFX validation system must be one, which allows rerunning the validators server-side, to ensure that developers will not have to rewrite validation code in multiple layers of the same application. From lubomir.nerad at oracle.com Wed Jun 13 03:57:07 2012 From: lubomir.nerad at oracle.com (Lubomir Nerad) Date: Wed, 13 Jun 2012 12:57:07 +0200 Subject: API REVIEW: Weak event handler In-Reply-To: <934EC5B5-0318-4580-B000-AFCA69E62384@oracle.com> References: <4FD72C57.1040609@oracle.com> <934EC5B5-0318-4580-B000-AFCA69E62384@oracle.com> Message-ID: <4FD87203.70203@oracle.com> Hi Richard, On 6/12/2012 10:01 PM, Richard Bair wrote: > Hi Lubo, > >> I also considered to define the WeakEventHandler as an interface which extends EventHandler, but adds no additional methods. Then leave it to event handler containers to reference such event handlers weakly. This has very simple and direct usage, but also its own problems. We can discuss it further if you find this solution preferred to the wrapper approach. > Extending WeakReference and lacking the public constructor did make me a little weak in the knees :-). Well, we can of course remove WeakReference from extends and have it as an instance in WeakEventHandler. But then we need to add some method to test whether the target handler has been garbage collected and will have one more instance for each created WeakEventHandler. So extending WeakReference seemed to me worth considering. On the other hand having additional test method is more consistent with Weak*Listener from javafx-beans so we will probably end up with it. As to the public constructor, I don't like having both (the factory method and constructor) and in this case the factory method seems to be easier to use. > What were the problems with WeakEventHandler being an interface? > When somebody wants to register a single event handler weakly multiple times, in the case of WeakEventHandler as a wrapper (the first case), he needs only to create a single instance of it and register it multiple types. In the case of WeakEventHandler as a marker (the second case), each time he registers such event handler a new instance of weak reference needs to be created by the container for it. Also if such weak event handler is set to an event handler property (for example Node.setOnMousePressed), the property implementation needs to be ready for it and create a weak reference to it. Then when such event handler is finally garbage collected, the property needs to return null and ideally at the point of garbage collection it should notify its listeners (if any) about value change. > Thanks! > Richard Lubo From java.whoover at gmail.com Wed Jun 13 04:44:48 2012 From: java.whoover at gmail.com (Will Hoover) Date: Wed, 13 Jun 2012 07:44:48 -0400 Subject: JavaFX Form Validation In-Reply-To: <4FD864BB.7080105@rockit.dk> References: <4FD5332A.5080608@oracle.com> <4fd76555.09d6e00a.463f.7a12@mx.google.com> <4FD77DDC.4080806@media-interactive.de> <4FD78018.4090900@tbee.org> <4fd7889b.47d0e00a.2e05.ffff9515@mx.google.com> <4FD864BB.7080105@rockit.dk> Message-ID: <4fd87d44.0cb2e00a.5e0a.1cc4@mx.google.com> +1 for JSR-349 -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Randahl Fink Isaksen Sent: Wednesday, June 13, 2012 6:00 AM To: openjfx-dev at openjdk.java.net; jonathan.giles at oracle.com Subject: Re: JavaFX Form Validation Jonathan, I think there is an important aspect of form validation which we have not yet discussed. In traditional web-based UI's, validating data at the UI layer may be considered sufficient, since the organization has total control over the UI layer validators, as they are executed server side. With JavaFX this is quite different, as the UI layer is running outside the server on an end user's PC. So, if the validity of certain fields is critical to system data integrity, it would be wrong to only run the validators in the JavaFX client application, since the application could have been modified, the network communication could have been compromised, etc. Consequently, the JavaFX validation system must be one, which allows rerunning the validators server-side, to ensure that developers will not have to rewrite validation code in multiple layers of the same application. As an example, if my application has specific requirements for user passwords, I would like to be able to define some kind of PasswordValidator and have JavaFX run it before data is sent to the server side; but obviously, I would want to rerun this PasswordValidator on the server before updating a user's password, to ensure that a malicious person could not have circumvented the validation by, say, altering the JavaFX application Java code. I noticed this topic is also discussed in JSR-349, the specification for Bean Validation: Validating data is a common task that occurs throughout an application, from the presentation layer to the persistence layer. Often the same validation logic is implemented in each layer, proving to be time consuming and error- prone. [...] The validation API developed by this JSR is not intended for use in any one tier or programming model. It is specifically not tied to either the web tier or the persistence tier, and is available for both server-side application programming, as well as rich client Swing application developers. This API is seen as a general extension to the Java- Beans object model, and as such is expected to be used as a core component in other specifications. Ease of use and flexibility have influenced the design of this specification. Now, I believe we should think twice before ditching the years of work which has gone into developing first JSR-303 and then the follow-up JSR-349. Making JavaFX compatible with these standards would mean 1. JavaFX validation would be recognizable to those Java EE developers who are already familiar with the Bean Validation standard. 2. JavaFX would avoid fragmenting the Java platform once again by introducing yet another solution to the same problem. 3. JavaFX applications would be able to reuse validators written for other (non-JavaFX) Java systems. 4. The validators used in JavaFX would be rerunnable in any application layer. On our openjfx-dev mailing list the JSR-303 and JSR-349 have been critizised for requiring annotations in the domain model classes, as in the following example: public class Address { @NotNull(message="the city is mandatory", payload=Severity.Error.class) String getCity() {...} } Having thought about this for a while, I disagree with the critics. The domain model classes are part of the API contract which the server presents to clients, so what would be more natural than strengthening this contract by adding validation constraints to it? Ideally, The PasswordValidator I mention above should be delivered alongside my domain model User class so both the JavaFX client application layer as well as the server business logic layer of my application could run it and be certain that the password specified lives up to system requirements. As we all know, JavaFX is but a single piece in the large technology puzzle upon which our applications are built. It is crucial, that JavaFX fits with the other pieces. Yours Randahl From lubomir.nerad at oracle.com Wed Jun 13 05:27:46 2012 From: lubomir.nerad at oracle.com (Lubomir Nerad) Date: Wed, 13 Jun 2012 14:27:46 +0200 Subject: API REVIEW: Weak event handler In-Reply-To: References: <4FD72C57.1040609@oracle.com> <934EC5B5-0318-4580-B000-AFCA69E62384@oracle.com> Message-ID: <4FD88742.4090209@oracle.com> Hi Sven, in NetBeans they chose a different approach. Each weak event listener they create needs to hold a reference to the "source" on which it has been registered. First this requirement prevents it from being used with multiple sources and then it is prone to errors because the API allows to use different source during weak event handler creation and its registration. The nice thing is that their weak listeners handle everything internally and so their containers don't need to be aware about their existence. If we wanted to use this approach for weak event handlers, we would require to provide and store more information for each event handler (source, eventType, isHandlerOrFilter) which would complicate weak event handler construction even further and increase possibilities for incorrect usage. In my proposal I create only a simple weak event handler wrapper, which does very little work. It can be registered in the same way as any other event handler (even on multiple sources). But it requires its containers to be aware of its existence and handle it specially. Most use cases won't require do distinguish between EventHandler and WeakEventHandler, we need to have additional API for it only to provide possibility for adding (by external developers) new event handler containers (advanced use cases) which can handler weak event handlers correctly. Thanks, Lubo On 6/12/2012 10:28 PM, Sven Reimers wrote: > Ok. Here is a link to the JavaDoc how NetBeans handles this for PropertyChanges > > http://bits.netbeans.org/dev/javadoc/org-openide-util/org/openide/util/WeakListeners.html > > I still do not understand the necessity for creating a new interface, > it contains no additional information (API) - for the user it can only > be used as an EventListener (assuming there will be no API explicitly > requiring WeakEventListener).. > > Regards > > Sven > > On Tue, Jun 12, 2012 at 10:01 PM, Richard Bair wrote: >> Hi Lubo, >> >>> I also considered to define the WeakEventHandler as an interface which extends EventHandler, but adds no additional methods. Then leave it to event handler containers to reference such event handlers weakly. This has very simple and direct usage, but also its own problems. We can discuss it further if you find this solution preferred to the wrapper approach. >> Extending WeakReference and lacking the public constructor did make me a little weak in the knees :-). What were the problems with WeakEventHandler being an interface? >> >> Thanks! >> Richard > > From sven.reimers at gmail.com Wed Jun 13 05:29:56 2012 From: sven.reimers at gmail.com (Sven Reimers) Date: Wed, 13 Jun 2012 14:29:56 +0200 Subject: API REVIEW: Weak event handler In-Reply-To: <4FD88742.4090209@oracle.com> References: <4FD72C57.1040609@oracle.com> <934EC5B5-0318-4580-B000-AFCA69E62384@oracle.com> <4FD88742.4090209@oracle.com> Message-ID: Alright. Makes perfect sense for me. Thanks Sven On Wed, Jun 13, 2012 at 2:27 PM, Lubomir Nerad wrote: > Hi Sven, > > in NetBeans they chose a different approach. Each weak event listener they > create needs to hold a reference to the "source" on which it has been > registered. First this requirement prevents it from being used with multiple > sources and then it is prone to errors because the API allows to use > different source during weak event handler creation and its registration. > The nice thing is that their weak listeners handle everything internally and > so their containers don't need to be aware about their existence. > > If we wanted to use this approach for weak event handlers, we would require > to provide and store more information for each event handler (source, > eventType, isHandlerOrFilter) which would complicate weak event handler > construction even further and increase possibilities for incorrect usage. > > In my proposal I create only a simple weak event handler wrapper, which does > very little work. It can be registered in the same way as any other event > handler (even on multiple sources). But it requires its containers to be > aware of its existence and handle it specially. Most use cases won't require > do distinguish between EventHandler and WeakEventHandler, we need to have > additional API for it only to provide possibility for adding (by external > developers) new event handler containers (advanced use cases) which can > handler weak event handlers correctly. > > Thanks, > Lubo > > > On 6/12/2012 10:28 PM, Sven Reimers wrote: >> >> Ok. Here is a link to the JavaDoc how NetBeans handles this for >> PropertyChanges >> >> >> http://bits.netbeans.org/dev/javadoc/org-openide-util/org/openide/util/WeakListeners.html >> >> I still do not understand the necessity for creating a new interface, >> it contains no additional information (API) - for the user it can only >> be used as an EventListener (assuming there will be no API explicitly >> requiring WeakEventListener).. >> >> Regards >> >> Sven >> >> On Tue, Jun 12, 2012 at 10:01 PM, Richard Bair >> ?wrote: >>> >>> Hi Lubo, >>> >>>> I also considered to define the WeakEventHandler as an interface which >>>> extends EventHandler, but adds no additional methods. Then leave it to event >>>> handler containers to reference such event handlers weakly. This has very >>>> simple and direct usage, but also its own problems. We can discuss it >>>> further if you find this solution preferred to the wrapper approach. >>> >>> Extending WeakReference and lacking the public constructor did make me a >>> little weak in the knees :-). What were the problems with WeakEventHandler >>> being an interface? >>> >>> Thanks! >>> Richard >> >> >> > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * Community Leader? NetBeans: http://community.java.net/netbeans ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 ? ? ? ? ? ? ? ? ?? http://www.linkedin.com/groups?gid=107402 ? ? ? ? ? ? ? ? ?? http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From hang.vo at oracle.com Wed Jun 13 05:48:40 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Jun 2012 12:48:40 +0000 Subject: hg: openjfx/2.2/graphics/rt: 2 new changesets Message-ID: <20120613124845.48A65478D4@hg.openjdk.java.net> Changeset: 348163a34ede Author: Martin Sladecek Date: 2012-06-13 14:36 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/348163a34ede @treatAsPrivate cleanup. Reviewed by Pavel. - javafx-ui-common/src/com/sun/javafx/stage/PopupEventRedirector.java ! javafx-ui-common/src/javafx/scene/Camera.java ! javafx-ui-common/src/javafx/scene/Cursor.java ! javafx-ui-common/src/javafx/scene/Group.java ! javafx-ui-common/src/javafx/scene/ImageCursor.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/ParallelCamera.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/PerspectiveCamera.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java ! javafx-ui-common/src/javafx/scene/layout/ConstraintsBase.java ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/src/javafx/scene/layout/Region.java ! javafx-ui-common/src/javafx/stage/PopupWindow.java ! javafx-ui-common/src/javafx/stage/Window.java ! javafx-ui-common/test/unit/javafx/scene/ImageCursor_getCurrentFrame_Test.java ! javafx-ui-common/test/unit/javafx/scene/MouseTest.java ! javafx-ui-common/test/unit/javafx/scene/Scene_properties_Test.java ! javafx-ui-common/test/unit/javafx/scene/StructureTest.java Changeset: 0e0923db2a7c Author: Martin Sladecek Date: 2012-06-13 14:36 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/0e0923db2a7c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/graphics/jfx/rt - javafx-ui-common/src/com/sun/javafx/stage/PopupEventRedirector.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/test/unit/javafx/scene/MouseTest.java From alexandre.iline at oracle.com Wed Jun 13 05:56:47 2012 From: alexandre.iline at oracle.com (alexandre.iline at oracle.com) Date: Wed, 13 Jun 2012 12:56:47 +0000 Subject: hg: openjfx/2.1/master/tests: 14 new changesets Message-ID: <20120613125648.EBD0C478D5@hg.openjdk.java.net> Changeset: 0b15f52b9eec Author: Oleg Barbashov Date: 2012-03-20 22:11 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/0b15f52b9eec JemmyFX: MenuButtonWrap fix ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/MenuButtonWrap.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/Controls.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/MenuTest.java Changeset: caba4f3f9405 Author: Oleg Barbashov Date: 2012-03-21 17:04 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/caba4f3f9405 JemmyFX: ByText/ByID are extended to accept non-Node classes ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/ByID.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/ByText.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/MenuTest.java Changeset: 261e7315b11f Author: Oleg Barbashov Date: 2012-03-21 18:07 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/261e7315b11f JemmyFX: SceneWrap: no more need in workaround for JFXPanel ! tools/Jemmy/JemmyFX/build.xml ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/SceneWrap.java Changeset: c577fa32f8b2 Author: Oleg Barbashov Date: 2012-03-21 18:31 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/c577fa32f8b2 JemmyFX: focuser update ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ComboBoxWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/MenuBarWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ThemeDriverFactory.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/CaspianDriverFactory.java Changeset: 23b4e7c74bad Author: Oleg Barbashov Date: 2012-03-21 20:34 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/23b4e7c74bad JemmyFX: focuser update ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/CaspianDriverFactory.java Changeset: b633df938f33 Author: Andrey Nazarov Date: 2012-05-29 19:52 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/b633df938f33 Node hierarchy refactoring + tools/Jemmy/JemmyFX/src/org/jemmy/fx/AbstractNodeHierarchy.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeHierarchy.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeParentImpl.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/SceneNodeHierarchy.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/SceneWrap.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TabNodeHierarchy.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TabWrap.java Changeset: 308fb69640d7 Author: Shura Date: 2012-06-01 11:03 -0700 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/308fb69640d7 Glass robot. + tools/Jemmy/GlassImage/build.xml + tools/Jemmy/GlassImage/manifest.mf + tools/Jemmy/GlassImage/nbproject/build-impl.xml + tools/Jemmy/GlassImage/nbproject/genfiles.properties + tools/Jemmy/GlassImage/nbproject/project.properties + tools/Jemmy/GlassImage/nbproject/project.xml + tools/Jemmy/GlassImage/src/org/jemmy/image/ClasspathGlassImageLoader.java + tools/Jemmy/GlassImage/src/org/jemmy/image/FileGlassImageLoader.java + tools/Jemmy/GlassImage/src/org/jemmy/image/GlassImage.java + tools/Jemmy/GlassImage/src/org/jemmy/image/GlassImageCapturer.java + tools/Jemmy/GlassImage/src/org/jemmy/image/GlassImageLoader.java + tools/Jemmy/GlassImage/src/org/jemmy/image/GlassPixelImageComparator.java + tools/Jemmy/GlassImage/src/org/jemmy/image/PNGLoader.java + tools/Jemmy/GlassImage/src/org/jemmy/image/PNGSaver.java + tools/Jemmy/GlassImage/test/org/jemmy/image/EnvTest.java + tools/Jemmy/GlassImage/test/org/jemmy/image/InitTest.java + tools/Jemmy/GlassImage/test/org/jemmy/image/SaveLoadTest.java + tools/Jemmy/GlassImage/test/org/jemmy/image/Test1.java + tools/Jemmy/GlassImage/test/org/jemmy/image/TestApp.java + tools/Jemmy/GlassRobot/build.xml + tools/Jemmy/GlassRobot/nbproject/build-impl.xml + tools/Jemmy/GlassRobot/nbproject/genfiles.properties + tools/Jemmy/GlassRobot/nbproject/project.properties + tools/Jemmy/GlassRobot/nbproject/project.xml + tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/DefaultGlassInputMap.java + tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/GlassDrag.java + tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/GlassInputFactory.java + tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/GlassInputMap.java + tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/GlassKeyboard.java + tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/GlassMouse.java + tools/Jemmy/GlassRobot/test/org/jemmy/input/glass/KeyboardInputApp.java + tools/Jemmy/GlassRobot/test/org/jemmy/input/glass/KeyboardTest.java + tools/Jemmy/GlassRobot/test/org/jemmy/input/glass/Log.java + tools/Jemmy/GlassRobot/test/org/jemmy/input/glass/MouseInputApp.java + tools/Jemmy/GlassRobot/test/org/jemmy/input/glass/MouseTest.java ! tools/Jemmy/JemmyFX/nbproject/build-impl.xml ! tools/Jemmy/JemmyFX/nbproject/genfiles.properties ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFX/nbproject/project.xml ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/Root.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/TextWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/CheckBoxWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ChoiceBoxWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ToggleButtonWrap.java + tools/Jemmy/JemmyFX/test/org/jemmy/fx/ImageTest.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/LookupTest.java - tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TableViewCellsParentTest.java Changeset: ba5639ce9e47 Author: Shura Date: 2012-06-01 11:12 -0700 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/ba5639ce9e47 merge ! tools/Jemmy/JemmyFX/nbproject/project.properties Changeset: 5beef50b587b Author: Shura Date: 2012-06-01 11:34 -0700 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/5beef50b587b bumped dependency version ! tools/Jemmy/JemmyFX/depend.properties Changeset: 7a64ef29fde3 Author: Shura Date: 2012-06-01 11:50 -0700 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/7a64ef29fde3 bumped version H: Enter commit message. Lines beginning with 'HG:' are removed. ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/jemmy.properties Changeset: e2567caca409 Author: Alexandre (Shura) Iline Date: 2012-06-08 19:29 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/e2567caca409 fixed scripts and readme ! tools/Jemmy/GlassImage/nbproject/project.properties ! tools/Jemmy/JemmyFX/build.xml ! tools/Jemmy/README Changeset: 53d860f6503b Author: Alexandre (Shura) Iline Date: 2012-06-09 12:53 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/53d860f6503b Use AWT robot on unix Grab image on the event queue Reduce ImageTest ! tools/Jemmy/GlassImage/src/org/jemmy/image/GlassImageCapturer.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/Root.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/ImageTest.java Changeset: fe1f000b448d Author: Alexandre (Shura) Iline Date: 2012-06-09 13:20 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/fe1f000b448d iadded AWT input ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/ImageTest.java Changeset: 48ead642e7a4 Author: Alexandre (Shura) Iline Date: 2012-06-13 16:51 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/48ead642e7a4 merge ! tools/Jemmy/JemmyFX/nbproject/project.properties From zonski at googlemail.com Wed Jun 13 06:23:18 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Wed, 13 Jun 2012 23:23:18 +1000 Subject: JavaFX Form Validation In-Reply-To: <4fd87d44.0cb2e00a.5e0a.1cc4@mx.google.com> References: <4FD5332A.5080608@oracle.com> <4fd76555.09d6e00a.463f.7a12@mx.google.com> <4FD77DDC.4080806@media-interactive.de> <4FD78018.4090900@tbee.org> <4fd7889b.47d0e00a.2e05.ffff9515@mx.google.com> <4FD864BB.7080105@rockit.dk> <4fd87d44.0cb2e00a.5e0a.1cc4@mx.google.com> Message-ID: <196AC79A-C699-4183-95A2-C189EE0BEF81@gmail.com> I'm going to echo some previous comments (including my own) on this topic. My vote is for JFX to provide low level building blocks for developers to hook in to and then for open source tool kits (like Jfxtras) to provide the higher level tools. So JFX would have no validation framework but instead would provide ways to, for example, visually highlight nodes, and a community built toolkit would use this to provide a validation framework. The reason for this: there is no one-size-fits-all solution. Different platforms, GUI styles and application domains will want to do something different. Some people will want component validation, some domain, some want to highlight error cells, others show error messages on submit; annotations, external validators, kinetic feedback on mobile devices, etc, etc. The passionate, varied opinions we've seen on this thread have demonstrate well the diverse approaches out there already. Few of them are 'wrong', most have merit. When trying to put together my own little validation framework based on JSR303, the raw tools in JFX were nearly perfect. The only thing I was really in need of was a way to visually annotate a Node (eg add a layer on top such as a red X). It would also be useful to be able to access the 'value' of a control in a consistent way and to be able to remove CSS styles and have the corresponding attributes be removed. These were suggestions I raised in this forum when I first joined it. I imagine I could dig up the email if it helped (although I think someone might have linked to it already in this thread). I'd prefer to see effort by the core JFX team put into these sorts of low level enhancements than in high level toolkits. Only the JFX team can do the low level stuff, and if the low level stuff is there then the community can do the high level stuff. For super bonus points, it would be really cool if the JFX team then helped the community develop the third party toolkits. Ie Jonathon, instead of you building a validation framework, I'd love it if you could shepherd those on this forum who are keen to build an external toolkit(s). There might be one group wanting to build something based on the JSRs and another wanting to build something around the Controls themselves. If you were involved in these architectures then you would be able to evolve the core jfx base features in a way that supported these. With Oracle sanctioning these could become defacto standards, similar to what the SwingX stuff became. These would be as good as a 'built in' solution but with none of the limitations, such as not being able to use 3rd party jars, having to be only one official version, and having to be tied to the JFX/JRE release schedule. That's my two cents anyway. On 13/06/2012, at 9:44 PM, "Will Hoover" wrote: > +1 for JSR-349 > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net > [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Randahl Fink > Isaksen > Sent: Wednesday, June 13, 2012 6:00 AM > To: openjfx-dev at openjdk.java.net; jonathan.giles at oracle.com > Subject: Re: JavaFX Form Validation > > Jonathan, I think there is an important aspect of form validation which we > have not yet discussed. In traditional web-based UI's, validating data at > the UI layer may be considered sufficient, since the organization has total > control over the UI layer validators, as they are executed server side. With > JavaFX this is quite different, as the UI layer is running outside the > server on an end user's PC. > > So, if the validity of certain fields is critical to system data integrity, > it would be wrong to only run the validators in the JavaFX client > application, since the application could have been modified, the network > communication could have been compromised, etc. Consequently, the JavaFX > validation system must be one, which allows rerunning the validators > server-side, to ensure that developers will not have to rewrite validation > code in multiple layers of the same application. > > As an example, if my application has specific requirements for user > passwords, I would like to be able to define some kind of PasswordValidator > and have JavaFX run it before data is sent to the server side; but > obviously, I would want to rerun this PasswordValidator on the server before > updating a user's password, to ensure that a malicious person could not have > circumvented the validation by, say, altering the JavaFX application Java > code. > > I noticed this topic is also discussed in JSR-349, the specification for > Bean Validation: > > Validating data is a common task that occurs throughout an application, from > the presentation layer to the persistence layer. Often the same validation > logic is implemented in each layer, proving to be time consuming and error- > prone. [...] > > The validation API developed by this JSR is not intended for use in any one > tier or programming model. It is specifically not tied to either the web > tier or the persistence tier, and is available for both server-side > application programming, as well as rich client Swing application > developers. This API is seen as a general extension to the Java- Beans > object model, and as such is expected to be used as a core component in > other specifications. Ease of use and flexibility have influenced the design > of this specification. > > Now, I believe we should think twice before ditching the years of work which > has gone into developing first JSR-303 and then the follow-up JSR-349. > Making JavaFX compatible with these standards would mean > > 1. JavaFX validation would be recognizable to those Java EE developers who > are already familiar with the Bean Validation standard. > 2. JavaFX would avoid fragmenting the Java platform once again by > introducing yet another solution to the same problem. > 3. JavaFX applications would be able to reuse validators written for other > (non-JavaFX) Java systems. > 4. The validators used in JavaFX would be rerunnable in any application > layer. > > On our openjfx-dev mailing list the JSR-303 and JSR-349 have been critizised > for requiring annotations in the domain model classes, as in the following > example: > > public class Address { > @NotNull(message="the city is mandatory", payload=Severity.Error.class) > String getCity() {...} > } > > Having thought about this for a while, I disagree with the critics. The > domain model classes are part of the API contract which the server presents > to clients, so what would be more natural than strengthening this contract > by adding validation constraints to it? Ideally, The PasswordValidator I > mention above should be delivered alongside my domain model User class so > both the JavaFX client application layer as well as the server business > logic layer of my application could run it and be certain that the password > specified lives up to system requirements. > > As we all know, JavaFX is but a single piece in the large technology puzzle > upon which our applications are built. It is crucial, that JavaFX fits with > the other pieces. > > Yours > > Randahl > > From lubomir.nerad at oracle.com Wed Jun 13 06:32:26 2012 From: lubomir.nerad at oracle.com (Lubomir Nerad) Date: Wed, 13 Jun 2012 15:32:26 +0200 Subject: API REVIEW: Weak event handler In-Reply-To: <4FD8100A.6050707@xs4all.nl> References: <4FD72C57.1040609@oracle.com> <4FD8100A.6050707@xs4all.nl> Message-ID: <4FD8966A.5090907@oracle.com> Hi John, the usage of weak version of EventHandler and (Invalidation|Change)Listener will be very similar. With the current proposal they will differ only in the way they are created (constructor vs. factory method). And I think that the adoption of factory method would be beneficial also for the Weak*Listener-s. But you are right that we should try to align them more closely from the implementation point of view and from the way they will be identified and handled by their respective containers. Thanks, Lubo On 6/13/2012 5:59 AM, John Hendrikx wrote: > This seems to be significantly different from how > WeakInvalidationListener and WeakChangeListener are implemented, > should they not be the same? > > On 12/06/2012 13:47, Lubomir Nerad wrote: >> Hi All, >> >> there is a request to add a WeakEventHandler to the API >> (http://javafx-jira.kenai.com/browse/RT-13706). This will be a simple >> wrapper for the target event handler to which it will delegate the >> handle calls. It will reference the target weakly and so it won't >> prevent it from being garbage collected. >> >> My proposal for this class is: >> >> package javafx.event; >> >> public final class WeakEventHandler >> extends WeakReference> >> implements EventHandler { >> >> private WeakEventHandler(EventHandler eventHandler) { ... } >> >> @Override public void handle(final T event) { ... } >> >> public static WeakEventHandler >> create(EventHandler eventHandler) { ... } >> } >> >> I decided to make this class both an EventHandler (implements) and a >> WeakReference (extends). Mainly I needed to have some way how to test >> from event handler containers whether the target event handler for a >> stored wrapper has been garbage collected and so the wrapper can be >> removed as well. Extending WeakReference adds the required method >> (WeakReference.get()) and saves some object instances. It also brings >> the clear method, which can simplify testing of this feature. >> >> WeakEventHandler instances will be created through the create factory >> method. This is to avoid repetition of the event type during event >> handler registration. >> >> So instead of: >> node.setOnMousePressed(new WeakEventHandler(new >> EventHandler() { ... })); >> >> we can use: >> node.setOnMousePressed(WeakEventHandler.create(new >> EventHandler() { ... })); >> >> I also considered to define the WeakEventHandler as an interface >> which extends EventHandler, but adds no additional methods. Then >> leave it to event handler containers to reference such event handlers >> weakly. This has very simple and direct usage, but also its own >> problems. We can discuss it further if you find this solution >> preferred to the wrapper approach. >> >> Thanks, >> Lubo >> > From randahl at rockit.dk Wed Jun 13 06:33:36 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Wed, 13 Jun 2012 15:33:36 +0200 Subject: JavaFX Form Validation In-Reply-To: <4FD89660.8010207@rockit.dk> References: <4FD89660.8010207@rockit.dk> Message-ID: <4FD896B0.3010103@rockit.dk> Very well said, Daniel. I'd just like to add, that if JavaFX is made fully open to anyone writing a validation mechanism, providing a simple default validation mechanism which works out of the box does not hurt. It is the pluggability which is important - it matters less if the one size does not fit all, if that one size can easily be replaced. I am very much looking forward to the design review process Jonathan announced - the fact that so many developers have chipped in guarantees a thorough review. Randahl -------- Original Message -------- Subject: Re: JavaFX Form Validation Date: Wed, 13 Jun 2012 15:32:16 +0200 From: Randahl Fink Isaksen To: Daniel Zwolenski Very well said, Daniel. I'd just like to add, that if JavaFX is made fully open to anyone writing a validation mechanism, providing a simple default validation mechanism which works out of the box does not hurt. It is the pluggability which is important - it matters less if the one size does not fit all, if that one size can easily be replaced. I am very much looking forward to the design review process Jonathan announced - the fact that so many developers have chipped in guarantees a thorough review. Randahl On 13/06/12 15.23, Daniel Zwolenski wrote: > I'm going to echo some previous comments (including my own) on this topic. > > My vote is for JFX to provide low level building blocks for developers to hook in to and then for open source tool kits (like Jfxtras) to provide the higher level tools. So JFX would have no validation framework but instead would provide ways to, for example, visually highlight nodes, and a community built toolkit would use this to provide a validation framework. > > The reason for this: there is no one-size-fits-all solution. Different platforms, GUI styles and application domains will want to do something different. Some people will want component validation, some domain, some want to highlight error cells, others show error messages on submit; annotations, external validators, kinetic feedback on mobile devices, etc, etc. > > The passionate, varied opinions we've seen on this thread have demonstrate well the diverse approaches out there already. Few of them are 'wrong', most have merit. > > When trying to put together my own little validation framework based on JSR303, the raw tools in JFX were nearly perfect. The only thing I was really in need of was a way to visually annotate a Node (eg add a layer on top such as a red X). It would also be useful to be able to access the 'value' of a control in a consistent way and to be able to remove CSS styles and have the corresponding attributes be removed. These were suggestions I raised in this forum when I first joined it. > I imagine I could dig up the email if it helped (although I think someone might have linked to it already in this thread). > > I'd prefer to see effort by the core JFX team put into these sorts of low level enhancements than in high level toolkits. Only the JFX team can do the low level stuff, and if the low level stuff is there then the community can do the high level stuff. > > For super bonus points, it would be really cool if the JFX team then helped the community develop the third party toolkits. Ie Jonathon, instead of you building a validation framework, I'd love it if you could shepherd those on this forum who are keen to build an external toolkit(s). There might be one group wanting to build something based on the JSRs and another wanting to build something around the Controls themselves. If you were involved in these architectures then you would be able to evolve the core jfx base features in a way that supported these. > > With Oracle sanctioning these could become defacto standards, similar to what the SwingX stuff became. These would be as good as a 'built in' solution but with none of the limitations, such as not being able to use 3rd party jars, having to be only one official version, and having to be tied to the JFX/JRE release schedule. > > That's my two cents anyway. > > > > On 13/06/2012, at 9:44 PM, "Will Hoover" wrote: > >> +1 for JSR-349 >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net >> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Randahl Fink >> Isaksen >> Sent: Wednesday, June 13, 2012 6:00 AM >> To: openjfx-dev at openjdk.java.net; jonathan.giles at oracle.com >> Subject: Re: JavaFX Form Validation >> >> Jonathan, I think there is an important aspect of form validation which we >> have not yet discussed. In traditional web-based UI's, validating data at >> the UI layer may be considered sufficient, since the organization has total >> control over the UI layer validators, as they are executed server side. With >> JavaFX this is quite different, as the UI layer is running outside the >> server on an end user's PC. >> >> So, if the validity of certain fields is critical to system data integrity, >> it would be wrong to only run the validators in the JavaFX client >> application, since the application could have been modified, the network >> communication could have been compromised, etc. Consequently, the JavaFX >> validation system must be one, which allows rerunning the validators >> server-side, to ensure that developers will not have to rewrite validation >> code in multiple layers of the same application. >> >> As an example, if my application has specific requirements for user >> passwords, I would like to be able to define some kind of PasswordValidator >> and have JavaFX run it before data is sent to the server side; but >> obviously, I would want to rerun this PasswordValidator on the server before >> updating a user's password, to ensure that a malicious person could not have >> circumvented the validation by, say, altering the JavaFX application Java >> code. >> >> I noticed this topic is also discussed in JSR-349, the specification for >> Bean Validation: >> >> Validating data is a common task that occurs throughout an application, from >> the presentation layer to the persistence layer. Often the same validation >> logic is implemented in each layer, proving to be time consuming and error- >> prone. [...] >> >> The validation API developed by this JSR is not intended for use in any one >> tier or programming model. It is specifically not tied to either the web >> tier or the persistence tier, and is available for both server-side >> application programming, as well as rich client Swing application >> developers. This API is seen as a general extension to the Java- Beans >> object model, and as such is expected to be used as a core component in >> other specifications. Ease of use and flexibility have influenced the design >> of this specification. >> >> Now, I believe we should think twice before ditching the years of work which >> has gone into developing first JSR-303 and then the follow-up JSR-349. >> Making JavaFX compatible with these standards would mean >> >> 1. JavaFX validation would be recognizable to those Java EE developers who >> are already familiar with the Bean Validation standard. >> 2. JavaFX would avoid fragmenting the Java platform once again by >> introducing yet another solution to the same problem. >> 3. JavaFX applications would be able to reuse validators written for other >> (non-JavaFX) Java systems. >> 4. The validators used in JavaFX would be rerunnable in any application >> layer. >> >> On our openjfx-dev mailing list the JSR-303 and JSR-349 have been critizised >> for requiring annotations in the domain model classes, as in the following >> example: >> >> public class Address { >> @NotNull(message="the city is mandatory", payload=Severity.Error.class) >> String getCity() {...} >> } >> >> Having thought about this for a while, I disagree with the critics. The >> domain model classes are part of the API contract which the server presents >> to clients, so what would be more natural than strengthening this contract >> by adding validation constraints to it? Ideally, The PasswordValidator I >> mention above should be delivered alongside my domain model User class so >> both the JavaFX client application layer as well as the server business >> logic layer of my application could run it and be certain that the password >> specified lives up to system requirements. >> >> As we all know, JavaFX is but a single piece in the large technology puzzle >> upon which our applications are built. It is crucial, that JavaFX fits with >> the other pieces. >> >> Yours >> >> Randahl >> >> From lubomir.nerad at oracle.com Wed Jun 13 08:49:52 2012 From: lubomir.nerad at oracle.com (Lubomir Nerad) Date: Wed, 13 Jun 2012 17:49:52 +0200 Subject: API REVIEW: Weak event handler In-Reply-To: <4FD79CA4.3070609@oracle.com> References: <4FD72C57.1040609@oracle.com> <4FD79CA4.3070609@oracle.com> Message-ID: <4FD8B6A0.1030409@oracle.com> Hi Jonathan, On 6/12/2012 9:46 PM, Jonathan Giles wrote: > For what it is worth, the UI controls team have a WeakEventHandler > class in com.sun.javafx.scene.control. It does not follow quite the > same direction as you have outlined, but you may find it interesting > nonetheless. It would be good to remove our implementation once the > public API becomes available, but I can't imagine you'd be adding the > WeakEventHandler as a feature into 2.2 now, would you? > You are right, this is for 3.0. > -- Jonathan > Thanks, Lubo > > On 12/06/2012 11:47 p.m., Lubomir Nerad wrote: >> Hi All, >> >> there is a request to add a WeakEventHandler to the API >> (http://javafx-jira.kenai.com/browse/RT-13706). This will be a simple >> wrapper for the target event handler to which it will delegate the >> handle calls. It will reference the target weakly and so it won't >> prevent it from being garbage collected. >> >> My proposal for this class is: >> >> package javafx.event; >> >> public final class WeakEventHandler >> extends WeakReference> >> implements EventHandler { >> >> private WeakEventHandler(EventHandler eventHandler) { ... } >> >> @Override public void handle(final T event) { ... } >> >> public static WeakEventHandler >> create(EventHandler eventHandler) { ... } >> } >> >> I decided to make this class both an EventHandler (implements) and a >> WeakReference (extends). Mainly I needed to have some way how to test >> from event handler containers whether the target event handler for a >> stored wrapper has been garbage collected and so the wrapper can be >> removed as well. Extending WeakReference adds the required method >> (WeakReference.get()) and saves some object instances. It also brings >> the clear method, which can simplify testing of this feature. >> >> WeakEventHandler instances will be created through the create factory >> method. This is to avoid repetition of the event type during event >> handler registration. >> >> So instead of: >> node.setOnMousePressed(new WeakEventHandler(new >> EventHandler() { ... })); >> >> we can use: >> node.setOnMousePressed(WeakEventHandler.create(new >> EventHandler() { ... })); >> >> I also considered to define the WeakEventHandler as an interface >> which extends EventHandler, but adds no additional methods. Then >> leave it to event handler containers to reference such event handlers >> weakly. This has very simple and direct usage, but also its own >> problems. We can discuss it further if you find this solution >> preferred to the wrapper approach. >> >> Thanks, >> Lubo >> From lehmann at media-interactive.de Wed Jun 13 08:58:07 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Wed, 13 Jun 2012 17:58:07 +0200 Subject: JavaFX Form Validation In-Reply-To: <196AC79A-C699-4183-95A2-C189EE0BEF81@gmail.com> References: <4FD5332A.5080608@oracle.com> <4fd76555.09d6e00a.463f.7a12@mx.google.com> <4FD77DDC.4080806@media-interactive.de> <4FD78018.4090900@tbee.org> <4fd7889b.47d0e00a.2e05.ffff9515@mx.google.com> <4FD864BB.7080105@rockit.dk> <4fd87d44.0cb2e00a.5e0a.1cc4@mx.google.com> <196AC79A-C699-4183-95A2-C189EE0BEF81@gmail.com> Message-ID: <4FD8B88F.7070406@media-interactive.de> +1 I think it could be useful to have a css pseudoclass for controls with invalid state. Rgds Werner On 13.06.2012 15:23, Daniel Zwolenski wrote: > My vote is for JFX to provide low level building blocks for > developers to hook in to and then for open source tool kits (like > Jfxtras) to provide the higher level tools. So JFX would have no > validation framework but instead would provide ways to, for example, > visually highlight nodes, and a community built toolkit would use > this to provide a validation framework. From hang.vo at oracle.com Wed Jun 13 11:33:21 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Jun 2012 18:33:21 +0000 Subject: hg: openjfx/2.2/controls/rt: fix RT-22466 Adding, removing then adding the same MenuBar instance in the scenegraph Message-ID: <20120613183324.C0E3F478DD@hg.openjdk.java.net> Changeset: d014ba0c953c Author: Paru Somashekar Date: 2012-06-13 11:27 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/d014ba0c953c fix RT-22466 Adding, removing then adding the same MenuBar instance in the scenegraph triggers NPE. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java From hang.vo at oracle.com Wed Jun 13 12:18:04 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Jun 2012 19:18:04 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22232: Context menu is in the wrong place for non primary monitors. Message-ID: <20120613191804.E12C8478DE@hg.openjdk.java.net> Changeset: 2bad47ac2ab8 Author: Kinsley Wong Date: 2012-06-13 12:12 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/2bad47ac2ab8 RT-22232: Context menu is in the wrong place for non primary monitors. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java From hang.vo at oracle.com Wed Jun 13 14:03:18 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Jun 2012 21:03:18 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22467: Moving a Button located in an AnchorPane to a Tab content gets you NPE Message-ID: <20120613210320.38152478E2@hg.openjdk.java.net> Changeset: 1a2a50109e8e Author: Kinsley Wong Date: 2012-06-13 13:47 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/1a2a50109e8e RT-22467: Moving a Button located in an AnchorPane to a Tab content gets you NPE ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ButtonSkin.java From hang.vo at oracle.com Wed Jun 13 14:47:56 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Jun 2012 21:47:56 +0000 Subject: hg: openjfx/2.2/controls/rt: Fixed RT-22480: Add private method to set default system menu bar. Message-ID: <20120613214757.D5393478E3@hg.openjdk.java.net> Changeset: 14efe4fc1d6a Author: leifs Date: 2012-06-13 14:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/14efe4fc1d6a Fixed RT-22480: Add private method to set default system menu bar. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java From hang.vo at oracle.com Wed Jun 13 18:48:04 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Jun 2012 01:48:04 +0000 Subject: hg: openjfx/2.2/controls/rt: Fixed RT-21645: On Mac OS X call to GlassViewEventHandler.getInputMethodCandidatePos() provides strange coordinates Message-ID: <20120614014807.D7A50478F6@hg.openjdk.java.net> Changeset: dc1043f1fde4 Author: leifs Date: 2012-06-13 18:45 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/dc1043f1fde4 Fixed RT-21645: On Mac OS X call to GlassViewEventHandler.getInputMethodCandidatePos() provides strange coordinates ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java From hang.vo at oracle.com Wed Jun 13 20:33:36 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Jun 2012 03:33:36 +0000 Subject: hg: openjfx/2.2/controls/rt: 3 new changesets Message-ID: <20120614033338.D07C8478FF@hg.openjdk.java.net> Changeset: 4b5bf956320b Author: jgiles Date: 2012-06-14 11:05 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/4b5bf956320b RT-22386: ComboBox : cannot choose the same item multiple times ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/test/javafx/scene/control/ComboBoxTest.java Changeset: ebbc5b495c06 Author: jgiles Date: 2012-06-14 15:02 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/ebbc5b495c06 RT-21088: ComboBox: regression with focusedProperty ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 6f9959b35a9d Author: jgiles Date: 2012-06-14 15:28 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/6f9959b35a9d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt From Claus.Luethje at osys.ch Wed Jun 13 23:37:43 2012 From: Claus.Luethje at osys.ch (Claus Luethje) Date: Thu, 14 Jun 2012 06:37:43 +0000 Subject: JavaFX Form Validation In-Reply-To: <4FD8B88F.7070406@media-interactive.de> References: <4FD5332A.5080608@oracle.com> <4fd76555.09d6e00a.463f.7a12@mx.google.com> <4FD77DDC.4080806@media-interactive.de> <4FD78018.4090900@tbee.org> <4fd7889b.47d0e00a.2e05.ffff9515@mx.google.com> <4FD864BB.7080105@rockit.dk> <4fd87d44.0cb2e00a.5e0a.1cc4@mx.google.com> <196AC79A-C699-4183-95A2-C189EE0BEF81@gmail.com> <4FD8B88F.7070406@media-interactive.de> Message-ID: <193FF4ED343AF14F8CDC65B4792C954D131E8134@Jeri.osys.ch> +1 -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Werner Lehmann Sent: Mittwoch, 13. Juni 2012 17:58 To: Subject: Re: JavaFX Form Validation +1 I think it could be useful to have a css pseudoclass for controls with invalid state. Rgds Werner On 13.06.2012 15:23, Daniel Zwolenski wrote: > My vote is for JFX to provide low level building blocks for developers > to hook in to and then for open source tool kits (like > Jfxtras) to provide the higher level tools. So JFX would have no > validation framework but instead would provide ways to, for example, > visually highlight nodes, and a community built toolkit would use this > to provide a validation framework. From han.solo at muenster.de Thu Jun 14 00:19:51 2012 From: han.solo at muenster.de (Gerrit Grunwald) Date: Thu, 14 Jun 2012 09:19:51 +0200 Subject: JavaFX Form Validation In-Reply-To: <193FF4ED343AF14F8CDC65B4792C954D131E8134@Jeri.osys.ch> References: <4FD5332A.5080608@oracle.com> <4fd76555.09d6e00a.463f.7a12@mx.google.com> <4FD77DDC.4080806@media-interactive.de> <4FD78018.4090900@tbee.org> <4fd7889b.47d0e00a.2e05.ffff9515@mx.google.com> <4FD864BB.7080105@rockit.dk> <4fd87d44.0cb2e00a.5e0a.1cc4@mx.google.com> <196AC79A-C699-4183-95A2-C189EE0BEF81@gmail.com> <4FD8B88F.7070406@media-interactive.de> <193FF4ED343AF14F8CDC65B4792C954D131E8134@Jeri.osys.ch> Message-ID: <91192062-8690-43E6-9A9B-02FB8DA782F6@muenster.de> +1 Am 14.06.2012 um 08:37 schrieb Claus Luethje: > +1 > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Werner Lehmann > Sent: Mittwoch, 13. Juni 2012 17:58 > To: > Subject: Re: JavaFX Form Validation > > +1 > > I think it could be useful to have a css pseudoclass for controls with invalid state. > > Rgds > Werner > > On 13.06.2012 15:23, Daniel Zwolenski wrote: >> My vote is for JFX to provide low level building blocks for developers >> to hook in to and then for open source tool kits (like >> Jfxtras) to provide the higher level tools. So JFX would have no >> validation framework but instead would provide ways to, for example, >> visually highlight nodes, and a community built toolkit would use this >> to provide a validation framework. From hang.vo at oracle.com Thu Jun 14 00:33:26 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Jun 2012 07:33:26 +0000 Subject: hg: openjfx/2.2/controls/rt: 19 new changesets Message-ID: <20120614073343.B13EE47905@hg.openjdk.java.net> Changeset: a9419005d78b Author: flar Date: 2012-06-05 00:21 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/a9419005d78b Fix RT-21688: optimize PixelReader and PixelWriter implementations + javafx-ui-common/src/com/sun/javafx/image/AlphaType.java + javafx-ui-common/src/com/sun/javafx/image/BytePixelAccessor.java + javafx-ui-common/src/com/sun/javafx/image/BytePixelGetter.java + javafx-ui-common/src/com/sun/javafx/image/BytePixelSetter.java + javafx-ui-common/src/com/sun/javafx/image/ByteToBytePixelConverter.java + javafx-ui-common/src/com/sun/javafx/image/ByteToIntPixelConverter.java + javafx-ui-common/src/com/sun/javafx/image/IntPixelAccessor.java + javafx-ui-common/src/com/sun/javafx/image/IntPixelGetter.java + javafx-ui-common/src/com/sun/javafx/image/IntPixelSetter.java + javafx-ui-common/src/com/sun/javafx/image/IntToBytePixelConverter.java + javafx-ui-common/src/com/sun/javafx/image/IntToIntPixelConverter.java + javafx-ui-common/src/com/sun/javafx/image/PixelAccessor.java + javafx-ui-common/src/com/sun/javafx/image/PixelConverter.java + javafx-ui-common/src/com/sun/javafx/image/PixelGetter.java + javafx-ui-common/src/com/sun/javafx/image/PixelSetter.java + javafx-ui-common/src/com/sun/javafx/image/PixelUtils.java + javafx-ui-common/src/com/sun/javafx/image/impl/BaseByteToByteConverter.java + javafx-ui-common/src/com/sun/javafx/image/impl/BaseByteToIntConverter.java + javafx-ui-common/src/com/sun/javafx/image/impl/BaseIntToByteConverter.java + javafx-ui-common/src/com/sun/javafx/image/impl/BaseIntToIntConverter.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteArgb.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteBgra.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteBgraPre.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteGray.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteGrayAlpha.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteGrayAlphaPre.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteRgb.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteRgba.java + javafx-ui-common/src/com/sun/javafx/image/impl/General.java + javafx-ui-common/src/com/sun/javafx/image/impl/IntArgb.java + javafx-ui-common/src/com/sun/javafx/image/impl/IntArgbPre.java ! javafx-ui-common/src/com/sun/javafx/tk/PlatformImage.java ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java ! javafx-ui-common/src/javafx/scene/image/Image.java ! javafx-ui-common/src/javafx/scene/image/WritableImage.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubPlatformImage.java Changeset: 0498a5aa3193 Author: kcr Date: 2012-06-05 08:42 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/0498a5aa3193 RT-21777: Changes for snapshot completely break the NetBeans VisualDebugger feature ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 7eb62ef86e4f Author: flar Date: 2012-06-05 18:58 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/7eb62ef86e4f Fix RT-21831: Specify ranges for WritableImage constructor parameters. ! javafx-ui-common/src/javafx/scene/image/Image.java ! javafx-ui-common/src/javafx/scene/image/WritableImage.java Changeset: 188ee39990fe Author: Lubomir Nerad Date: 2012-06-06 12:14 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/188ee39990fe Fix for RT-22015: workaround for incorrect fullscreen visual bounds ! javafx-ui-common/src/com/sun/javafx/Utils.java ! javafx-ui-common/src/javafx/stage/PopupWindow.java ! javafx-ui-common/test/unit/javafx/stage/PopupTest.java Changeset: a4bd88439e22 Author: Pavel Safrata Date: 2012-06-06 18:00 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/a4bd88439e22 RT-22096: Fixed coordinates of touch points delivered to a transformed node. ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/TouchPoint.java ! javafx-ui-common/test/unit/javafx/scene/input/TouchEventTest.java Changeset: 6593c5847d5b Author: Yao Wang Date: 2012-06-06 09:51 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/6593c5847d5b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt ! javafx-ui-common/src/com/sun/javafx/Utils.java Changeset: 2bbfe01c80b3 Author: Morris Meyer Date: 2012-06-06 19:59 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/2bbfe01c80b3 RT-22083 - fix GlobalMenuAdapter so menu action doesn't fire during validation ! javafx-ui-controls/src/com/sun/javafx/scene/control/GlobalMenuAdapter.java Changeset: 2b45c041ff58 Author: Pavel Safrata Date: 2012-06-07 14:03 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/2b45c041ff58 RT-21888: fixed intial state of FocusedProperty. ! javafx-ui-common/src/javafx/scene/Node.java Changeset: dd0048db6e86 Author: Lubomir Nerad Date: 2012-06-07 16:59 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/dd0048db6e86 Fix for RT-22142: Intermittent unit test failures in javafx.stage.PopupTest with JDK7 ! javafx-ui-common/test/unit/javafx/stage/PopupTest.java Changeset: 4427dc34e097 Author: "Joseph Andresen" Date: 2012-06-07 11:26 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/4427dc34e097 RT-21006: unit test canvas update ! javafx-ui-common/test/unit/javafx/scene/canvas/CanvasTest.java Changeset: c9f8ab00f5be Author: Pavel Safrata Date: 2012-06-08 09:39 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/c9f8ab00f5be TouchPoint constructor removed from public API. ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/TouchPoint.java - javafx-ui-common/test/unit/javafx/scene/input/TouchPoint_builder_Test.java Changeset: d5146a3b928f Author: Pavel Safrata Date: 2012-06-08 13:16 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/d5146a3b928f RT-22150: fixed event delivery to nodes with non-invertible transformation. ! javafx-ui-common/src/com/sun/javafx/scene/input/InputEventUtils.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java ! javafx-ui-common/src/javafx/scene/input/DragEvent.java ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchPoint.java ! javafx-ui-common/test/unit/javafx/scene/MouseTest.java Changeset: 796a3a759c37 Author: Felipe Heidrich Date: 2012-06-08 12:23 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/796a3a759c37 [DOC-ONLY] fixing tag in the javadoc for Font#loadFont() ! javafx-ui-common/src/javafx/scene/text/Font.java Changeset: 261c8cd885ec Author: kcr Date: 2012-06-08 16:25 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/261c8cd885ec Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt - javafx-ui-common/test/unit/javafx/scene/input/TouchPoint_builder_Test.java Changeset: 62938da54121 Author: Pavel Safrata Date: 2012-06-11 09:56 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/62938da54121 Fixed mouse event copying problem introduced by fix for RT-22150. ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java Changeset: 97b7b1b4a358 Author: Thor johannesson Date: 2012-06-11 13:49 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/97b7b1b4a358 RT-21925: Canvas consistent handling of text alignment. When multiple lines of text. Doc only change. ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java Changeset: 9def6759a1f2 Author: "Joseph Andresen" Date: 2012-06-12 09:33 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/9def6759a1f2 RT-21735: Canvas Scale and Size do not sync ! javafx-ui-common/src/javafx/scene/canvas/Canvas.java Changeset: 00a63ce77e97 Author: Yao Wang Date: 2012-06-12 10:07 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/00a63ce77e97 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt - javafx-ui-common/test/unit/javafx/scene/input/TouchPoint_builder_Test.java Changeset: adcda42efa37 Author: leifs Date: 2012-06-14 00:20 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/adcda42efa37 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt From zonski at googlemail.com Thu Jun 14 00:45:38 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Thu, 14 Jun 2012 17:45:38 +1000 Subject: JavaFX Form Validation In-Reply-To: <91192062-8690-43E6-9A9B-02FB8DA782F6@muenster.de> References: <4FD5332A.5080608@oracle.com> <4fd76555.09d6e00a.463f.7a12@mx.google.com> <4FD77DDC.4080806@media-interactive.de> <4FD78018.4090900@tbee.org> <4fd7889b.47d0e00a.2e05.ffff9515@mx.google.com> <4FD864BB.7080105@rockit.dk> <4fd87d44.0cb2e00a.5e0a.1cc4@mx.google.com> <196AC79A-C699-4183-95A2-C189EE0BEF81@gmail.com> <4FD8B88F.7070406@media-interactive.de> <193FF4ED343AF14F8CDC65B4792C954D131E8134@Jeri.osys.ch> <91192062-8690-43E6-9A9B-02FB8DA782F6@muenster.de> Message-ID: <400BA4FE-3B71-4798-9480-7F62D2D1A38D@gmail.com> Would it be possible to attach our own arbitrary pseudo classes to controls via code? Eg. Button.setPseudoClass("highlighted") That would then cover the error case and much more. Eg I might have 'error', 'warning', 'required', 'highlighted', etc. I do not know if the CSS engine will be able to handle this. On 14/06/2012, at 5:19 PM, Gerrit Grunwald wrote: > +1 > Am 14.06.2012 um 08:37 schrieb Claus Luethje: > >> +1 >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Werner Lehmann >> Sent: Mittwoch, 13. Juni 2012 17:58 >> To: >> Subject: Re: JavaFX Form Validation >> >> +1 >> >> I think it could be useful to have a css pseudoclass for controls with invalid state. >> >> Rgds >> Werner >> >> On 13.06.2012 15:23, Daniel Zwolenski wrote: >>> My vote is for JFX to provide low level building blocks for developers >>> to hook in to and then for open source tool kits (like >>> Jfxtras) to provide the higher level tools. So JFX would have no >>> validation framework but instead would provide ways to, for example, >>> visually highlight nodes, and a community built toolkit would use this >>> to provide a validation framework. > From martin.sladecek at oracle.com Thu Jun 14 03:39:53 2012 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Thu, 14 Jun 2012 12:39:53 +0200 Subject: javafx.scene.input.*Event classes construction Message-ID: <4FD9BF79.2020105@oracle.com> Hello, I'd like to discuss possible solutions to the following issue: " Add proper constructors & factory methods to event classes, remove impl" ( http://javafx-jira.kenai.com/browse/RT-9383 ). Current situation is that we have many impl_*event and impl_copy factory methods on Event subclasses in javafx.scene.input package. These methods exists are called from Scene, which processes events from Quantum a creates new Event objects. These methods will be removed and replaced with public methods/constructors. There are 2 main issues that need to be discussed: #1 - possible ways to construct Event objects Currently, we have impl_*event methods that have all the possible event fields as parameters + impl_copy methods that copies the event with some of it's fields modified. The straightforward solution is to convert impl_*event methods to constructors (and possibly add some shorter constructors) and convert impl_copy methods to standard public (factory) methods. One drawback is that we'd have to add more (and bigger) constructors in the future, when some other properties are added to events, although this is going to happen only really occasionally. Another possibility is to use builders instead of constructors / factory methods and avoid the very long parameters lists. Or at least add them for convenience. #2 - possible use-cases for user-constructed events I think testing is the most obvious use-case. In the original JIRA issue, the use-case was to record the events and then "replay" them during the test. This is however not going to work with current API and Scene implementation. To replay the events, we would need to let the Scene process the events and there's not API for this. Event.fireEvent applied on a Scene will just send these events to the appropriate event handlers, but won't trigger Scene processing that is done before these events are normally created in the scene, e.g. drag & drop processing. To support this, Scene event processing would have to be rewritten and a new method for passing Event objects to Scene would have to be created. -Martin From richard.bair at oracle.com Thu Jun 14 07:34:05 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 14 Jun 2012 07:34:05 -0700 Subject: javafx.scene.input.*Event classes construction In-Reply-To: <4FD9BF79.2020105@oracle.com> References: <4FD9BF79.2020105@oracle.com> Message-ID: <4BF66087-0618-416D-9656-7C9BDFE5978E@oracle.com> Hi Martin, Another use here is that you may want to intercept an event in a filter and create a new synthetic event (possibly of a different type) and the dispatch the new event. As for the approach, I think you do the constructors with all params (since events are immutable you have no choice really -- static factory or constructor and I prefer in this case a constructor) + builder (auto generated). Cheers Richard On Jun 14, 2012, at 3:39 AM, Martin Sladecek wrote: > Hello, > I'd like to discuss possible solutions to the following issue: " Add proper constructors & factory methods to event classes, remove impl" ( http://javafx-jira.kenai.com/browse/RT-9383 ). > > Current situation is that we have many impl_*event and impl_copy factory methods on Event subclasses in javafx.scene.input package. These methods exists are called from Scene, which processes events from Quantum a creates new Event objects. These methods will be removed and replaced with public methods/constructors. > > There are 2 main issues that need to be discussed: > > #1 - possible ways to construct Event objects > Currently, we have impl_*event methods that have all the possible event fields as parameters + impl_copy methods that copies the event with some of it's fields modified. > > The straightforward solution is to convert impl_*event methods to constructors (and possibly add some shorter constructors) and convert impl_copy methods to standard public (factory) methods. > One drawback is that we'd have to add more (and bigger) constructors in the future, when some other properties are added to events, although this is going to happen only really occasionally. > > Another possibility is to use builders instead of constructors / factory methods and avoid the very long parameters lists. Or at least add them for convenience. > > #2 - possible use-cases for user-constructed events > I think testing is the most obvious use-case. In the original JIRA issue, the use-case was to record the events and then "replay" them during the test. This is however not going to work with current API and Scene implementation. To replay the events, we would need to let the Scene process the events and there's not API for this. > > Event.fireEvent applied on a Scene will just send these events to the appropriate event handlers, but won't trigger Scene processing that is done before these events are normally created in the scene, e.g. drag & drop processing. > To support this, Scene event processing would have to be rewritten and a new method for passing Event objects to Scene would have to be created. > > > -Martin From martin.sladecek at oracle.com Thu Jun 14 07:55:00 2012 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Thu, 14 Jun 2012 16:55:00 +0200 Subject: javafx.scene.input.*Event classes construction In-Reply-To: <4BF66087-0618-416D-9656-7C9BDFE5978E@oracle.com> References: <4FD9BF79.2020105@oracle.com> <4BF66087-0618-416D-9656-7C9BDFE5978E@oracle.com> Message-ID: <4FD9FB44.9030400@oracle.com> On 06/14/2012 04:34 PM, Richard Bair wrote: > Hi Martin, > > Another use here is that you may want to intercept an event in a filter and create a new synthetic event (possibly of a different type) and the dispatch the new event. Yes, this one should work without any changes to Scene. > > As for the approach, I think you do the constructors with all params (since events are immutable you have no choice really -- static factory or constructor and I prefer in this case a constructor) + builder (auto generated). And what do you think about impl_copy methods? Personally I think we should remove them completely and turn them to some internal utility methods. Also, some events are not 100% immutable, as they are modified during the Scene processing through some impl_methods, like MouseEvent.impl_setClickParam. We'd either need to make some/all of the Event fields protected and do this modifications through subclasses or create some "accessor" in javafx.scene.input package for calling these methods from javafx.scene package. > > Cheers > Richard > > > On Jun 14, 2012, at 3:39 AM, Martin Sladecek wrote: > >> Hello, >> I'd like to discuss possible solutions to the following issue: " Add proper constructors& factory methods to event classes, remove impl" ( http://javafx-jira.kenai.com/browse/RT-9383 ). >> >> Current situation is that we have many impl_*event and impl_copy factory methods on Event subclasses in javafx.scene.input package. These methods exists are called from Scene, which processes events from Quantum a creates new Event objects. These methods will be removed and replaced with public methods/constructors. >> >> There are 2 main issues that need to be discussed: >> >> #1 - possible ways to construct Event objects >> Currently, we have impl_*event methods that have all the possible event fields as parameters + impl_copy methods that copies the event with some of it's fields modified. >> >> The straightforward solution is to convert impl_*event methods to constructors (and possibly add some shorter constructors) and convert impl_copy methods to standard public (factory) methods. >> One drawback is that we'd have to add more (and bigger) constructors in the future, when some other properties are added to events, although this is going to happen only really occasionally. >> >> Another possibility is to use builders instead of constructors / factory methods and avoid the very long parameters lists. Or at least add them for convenience. >> >> #2 - possible use-cases for user-constructed events >> I think testing is the most obvious use-case. In the original JIRA issue, the use-case was to record the events and then "replay" them during the test. This is however not going to work with current API and Scene implementation. To replay the events, we would need to let the Scene process the events and there's not API for this. >> >> Event.fireEvent applied on a Scene will just send these events to the appropriate event handlers, but won't trigger Scene processing that is done before these events are normally created in the scene, e.g. drag& drop processing. >> To support this, Scene event processing would have to be rewritten and a new method for passing Event objects to Scene would have to be created. >> >> >> -Martin Thanks, -Martin From richard.bair at oracle.com Thu Jun 14 11:13:10 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 14 Jun 2012 11:13:10 -0700 Subject: Debugging a UI refresh problem (not dirtyopts related it seems) In-Reply-To: <4FD81430.3070905@xs4all.nl> References: <4FD81430.3070905@xs4all.nl> Message-ID: <9F66168A-4A50-4A3B-BEF1-CB8549A356A4@oracle.com> Hi John, I'm not sure. If you are confident you are running with dirty opts turned off and you're seeing the problem, then it isn't immediately obvious to me what the issue could be. I believe there is a prism.verbose flag or some such which if you set will repeat out all the settings you are currently using, and then you can check that dirty opts is actually being disabled correctly. Richard On Jun 12, 2012, at 9:16 PM, John Hendrikx wrote: > Hi List, > > I'm having a problem that started when I upgraded from JavaFX 2.1 to 2.2b11 -- I want to submit a bug report for it, but having trouble reproducing it outside my main code. > > Basically, what is happening is that during navigation between different parts of the application, sometimes the screen is not being redrawn properly (for some background info, the screen in my app consists of a screen filling background picture, with on top of this a big list with images/text). > > Basically, what I'm seeing is this: > > Step 1: StackPane with 2 children (background picture, and overlaid on top of that a List with names) > Step 2: StackPane with same background picture, but no controls over laid... (the background picture is doing a 5 second fade out/in animation because every screen has its own picture, so redrawing is happening a lot) > > Now, if I press cursor up/down, then the list suddenly appears, which makes me think it is a redraw issue (this also means that the control had focus, but is not drawn). > > In between the two steps a lot of code happens in my app, but the crucial part is that at some point the old List is removed (from step 1) and then replaced (in the same StackPane) with a new, different, List. No exceptions or anything else out of the ordinary happens, the new child is simply not drawn (or perhaps sized incorrectly, rendering it invisible -- or perhaps drawn in the wrong order appearing behind the BG picture (although it is the last child in the StackPane)). As said, moving the cursor makes it appear -- and it did work with JavaFX 2.1. > > Note that my Lists donot have any kind of "hover" highlighting effects or any other animations (unlike the standard JavaFX lists), so there's a good chance that if JavaFX did not decide to draw my List the first time when it was added to the StackPane that nothing will trigger it to be drawn until the cursor up/down happens... > > Any ideas on how to best debug this? > > I've already tried setting dirtyopts to false... anything else I can try? It is fairly easy to reproduce in my app. From hjohn at xs4all.nl Thu Jun 14 11:38:05 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Thu, 14 Jun 2012 20:38:05 +0200 Subject: Debugging a UI refresh problem (not dirtyopts related it seems) In-Reply-To: <9F66168A-4A50-4A3B-BEF1-CB8549A356A4@oracle.com> References: <4FD81430.3070905@xs4all.nl> <9F66168A-4A50-4A3B-BEF1-CB8549A356A4@oracle.com> Message-ID: <4FDA2F8D.2070908@xs4all.nl> Hi Richard, The verbose options works, below is the output, dirtyopts seems to be false (3rd line). I've noticed that it is definitely related to whether or not any "animation" action occurs after switching a Child of the StackPane... if there is any kind of action happening (like an image being loaded, or a scrollTo command triggering a slight bit of scrolling) then it redraws properly... and it was hard to reproduce it because of that. However, I've now noticed that when I go back and forth between the same screens, and the 2nd time I return to the same view (when all Images are cached and the UI can react even faster) then the chance of the bug happening is much much bigger (like 90%). Apparently because no changes in layout or node values are occuring after the initial one... thus if the initial drawing was somehow missed, I end up with an empty screen until I do something that triggers a change. I'm not convinced that it might not be my fault somehow, but it doesn't occur in 2.1. So, it seems that under certain conditions, removing a child from a StackPane and replacing it with a similar child (which is practically static) results in it not being drawn. I'll see if I can strip it down far enough to make it reproducable in a stand-alone program in the weekend -- it is easy enough to reproduce in the main program (not like my scroll wheel bug :)) --John 0.065 | Prism pipeline init order: d3d j2d -- com.sun.prism.impl.PrismSettings.checkSettings(PrismSettings.java:216) 0.066 | Using t2k for text rasterization -- com.sun.prism.impl.PrismSettings.checkSettings(PrismSettings.java:217) 0.066 | Not using dirty region optimizations -- com.sun.prism.impl.PrismSettings.checkSettings(PrismSettings.java:221) 0.066 | Prism pipeline name = com.sun.prism.d3d.D3DPipeline -- com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:148) 0.067 | Loading D3D native library ... -- com.sun.prism.d3d.D3DPipeline$1.run(D3DPipeline.java:29) 0.069 | succeeded. -- com.sun.prism.d3d.D3DPipeline$1.run(D3DPipeline.java:33) 0.134 | Direct3D initialization succeeded -- com.sun.prism.d3d.D3DPipeline.(D3DPipeline.java:40) 0.136 | (X) Got class = class com.sun.prism.d3d.D3DPipeline -- com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:152) 0.137 | Initialized prism pipeline: com.sun.prism.d3d.D3DPipeline -- com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:159) 0.185 | OS Information: -- com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:87) 0.185 | Windows 7 build 7601 -- com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:88) 0.185 | D3D Driver Information: -- com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:89) 0.185 | NVIDIA GeForce GTX 550 Ti -- com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:90) 0.185 | \\.\DISPLAY3 -- com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:91) 0.186 | Driver nvd3dum.dll, version 8.17.12.8562 -- com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:92) 0.186 | Pixel Shader version 3.0 -- com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:93) 0.187 | Device : ven_10DE, dev_1244, subsys_83C21043 -- com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:94) 0.220 | javafx.runtime.version: 2.2.0-beta-b11 -- hs.mediasystem.FrontEnd.start(FrontEnd.java:75) 1.401 | -> RESIZE: 2187154536045615 w: 1440 h: 860 -- com.sun.javafx.tk.quantum.GlassViewEventHandler.handleViewEvent(GlassViewEventHandler.java:444) 1.411 | ProgramController.registerService() - registering new service: hs.mediasystem.screens.SubtitleDownloadService at 8e4e40 -- hs.mediasystem.screens.ProgramController.registerWorker(ProgramController.java:430) 1.413 | ProgramController.registerService() - registering new service: hs.mediasystem.screens.GroupWorker at 2e9f9e -- hs.mediasystem.screens.ProgramController.registerWorker(ProgramController.java:430) 1.659 *| Database up to date at version 11 -- hs.mediasystem.db.DatabaseUpdater.updateDatabase(DatabaseUpdater.java:43) 1.663 *| Navigator.navigateTo() - Destination('Home'; modal=false) -- hs.mediasystem.screens.Navigator.navigateTo(Navigator.java:71) 1.702 | RESIZE: 2187154837492176 w: 1920 h: 1200 -- com.sun.javafx.tk.quantum.GlassViewEventHandler.handleViewEvent(GlassViewEventHandler.java:444) 1.915 | new alphas -- com.sun.prism.impl.shape.OpenPiscesRasterizer.getMaskData(OpenPiscesRasterizer.java:80) 2.201 | new alphas -- com.sun.prism.impl.shape.OpenPiscesRasterizer.getMaskData(OpenPiscesRasterizer.java:80) On 14/06/2012 20:13, Richard Bair wrote: > Hi John, > > I'm not sure. If you are confident you are running with dirty opts turned off and you're seeing the problem, then it isn't immediately obvious to me what the issue could be. I believe there is a prism.verbose flag or some such which if you set will repeat out all the settings you are currently using, and then you can check that dirty opts is actually being disabled correctly. > > Richard > > > On Jun 12, 2012, at 9:16 PM, John Hendrikx wrote: > >> Hi List, >> >> I'm having a problem that started when I upgraded from JavaFX 2.1 to 2.2b11 -- I want to submit a bug report for it, but having trouble reproducing it outside my main code. >> >> Basically, what is happening is that during navigation between different parts of the application, sometimes the screen is not being redrawn properly (for some background info, the screen in my app consists of a screen filling background picture, with on top of this a big list with images/text). >> >> Basically, what I'm seeing is this: >> >> Step 1: StackPane with 2 children (background picture, and overlaid on top of that a List with names) >> Step 2: StackPane with same background picture, but no controls over laid... (the background picture is doing a 5 second fade out/in animation because every screen has its own picture, so redrawing is happening a lot) >> >> Now, if I press cursor up/down, then the list suddenly appears, which makes me think it is a redraw issue (this also means that the control had focus, but is not drawn). >> >> In between the two steps a lot of code happens in my app, but the crucial part is that at some point the old List is removed (from step 1) and then replaced (in the same StackPane) with a new, different, List. No exceptions or anything else out of the ordinary happens, the new child is simply not drawn (or perhaps sized incorrectly, rendering it invisible -- or perhaps drawn in the wrong order appearing behind the BG picture (although it is the last child in the StackPane)). As said, moving the cursor makes it appear -- and it did work with JavaFX 2.1. >> >> Note that my Lists donot have any kind of "hover" highlighting effects or any other animations (unlike the standard JavaFX lists), so there's a good chance that if JavaFX did not decide to draw my List the first time when it was added to the StackPane that nothing will trigger it to be drawn until the cursor up/down happens... >> >> Any ideas on how to best debug this? >> >> I've already tried setting dirtyopts to false... anything else I can try? It is fairly easy to reproduce in my app. From hjohn at xs4all.nl Thu Jun 14 12:48:59 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Thu, 14 Jun 2012 21:48:59 +0200 Subject: Debugging a UI refresh problem (not dirtyopts related it seems) In-Reply-To: <4FDA2F8D.2070908@xs4all.nl> References: <4FD81430.3070905@xs4all.nl> <9F66168A-4A50-4A3B-BEF1-CB8549A356A4@oracle.com> <4FDA2F8D.2070908@xs4all.nl> Message-ID: <4FDA402B.3010907@xs4all.nl> I seem to have narrowed it down to the call to scrollTo()... when I remove it, I cannot make it fail anymore. So, the case is: 1) StackPane with two children, one of them being another StackPane that contains a TableView or TreeView (happens with either) -- the Views contain several pages worth of data. A KeyEvent occurs, which triggers the following chain: 2a) Find the current selected item in said TableView/TreeView, and make a note of it. 2b) Remove the StackPane with the View 2c) Add a new StackPane with a different View 2d) Reselect the item that was selected in the newly added View (basically, the code switches between a TreeView and TableView) Step 2d) does not do the selection (+scrolling) of the previously selected item in the same Event (as that has proven in the past to cause numerous issues...). As a work-around I found that it was better to defer those calls by simply wrapping them in a Platform.runLater()... So, after the KeyEvent fully completes, with maybe a few other events in between, our Platform.runLater() code should run, which does the actual selection (a focus() call) and the scrolling (a scrollTo() call). If I comment out the scrollTo(), it works flawlessly and the new StackPane is always redrawn correctly (but obviously, not in the correct scroll position) If I donot do the focus+scrollTo() in a Platform.runLater() then basically that part of the code rarely functions properly at all (the View classes simply donot seem to like it when you do these calls in the same event that created them and made them part of the Scene, see my comment in issue RT-18816)... despite that, the behaviour is slightly different -- not the entire display disappears anymore, but only the *View class is not drawn correctly (scrollbar visible, but nothing else). So, it seems the problem is concentrated in the View classes, and specifically how they deal with being created, filled, focused and scroll'ed'To() in the same KeyEvent :) --John On 14/06/2012 20:38, John Hendrikx wrote: > Hi Richard, > > The verbose options works, below is the output, dirtyopts seems to be > false (3rd line). > > I've noticed that it is definitely related to whether or not any > "animation" action occurs after switching a Child of the StackPane... > if there is any kind of action happening (like an image being loaded, > or a scrollTo command triggering a slight bit of scrolling) then it > redraws properly... and it was hard to reproduce it because of that. > > However, I've now noticed that when I go back and forth between the > same screens, and the 2nd time I return to the same view (when all > Images are cached and the UI can react even faster) then the chance of > the bug happening is much much bigger (like 90%). Apparently because > no changes in layout or node values are occuring after the initial > one... thus if the initial drawing was somehow missed, I end up with > an empty screen until I do something that triggers a change. I'm not > convinced that it might not be my fault somehow, but it doesn't occur > in 2.1. > > So, it seems that under certain conditions, removing a child from a > StackPane and replacing it with a similar child (which is practically > static) results in it not being drawn. I'll see if I can strip it > down far enough to make it reproducable in a stand-alone program in > the weekend -- it is easy enough to reproduce in the main program (not > like my scroll wheel bug :)) > > --John > > 0.065 | Prism pipeline init order: d3d > j2d > -- com.sun.prism.impl.PrismSettings.checkSettings(PrismSettings.java:216) > 0.066 | Using t2k for text > rasterization > -- com.sun.prism.impl.PrismSettings.checkSettings(PrismSettings.java:217) > 0.066 | Not using dirty region > optimizations > -- com.sun.prism.impl.PrismSettings.checkSettings(PrismSettings.java:221) > 0.066 | Prism pipeline name = > com.sun.prism.d3d.D3DPipeline > -- > com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:148) > 0.067 | Loading D3D native library > ... > -- com.sun.prism.d3d.D3DPipeline$1.run(D3DPipeline.java:29) > 0.069 | > succeeded. > -- com.sun.prism.d3d.D3DPipeline$1.run(D3DPipeline.java:33) > 0.134 | Direct3D initialization > succeeded > -- com.sun.prism.d3d.D3DPipeline.(D3DPipeline.java:40) > 0.136 | (X) Got class = class > com.sun.prism.d3d.D3DPipeline > -- > com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:152) > 0.137 | Initialized prism pipeline: > com.sun.prism.d3d.D3DPipeline > -- > com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:159) > 0.185 | OS > Information: > -- > com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:87) > 0.185 | Windows 7 build > 7601 > -- > com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:88) > 0.185 | D3D Driver > Information: > -- > com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:89) > 0.185 | NVIDIA GeForce GTX 550 > Ti > -- > com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:90) > 0.185 | > \\.\DISPLAY3 > -- > com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:91) > 0.186 | Driver nvd3dum.dll, version > 8.17.12.8562 > -- > com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:92) > 0.186 | Pixel Shader version > 3.0 > -- > com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:93) > 0.187 | Device : ven_10DE, dev_1244, > subsys_83C21043 > -- > com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:94) > 0.220 | javafx.runtime.version: > 2.2.0-beta-b11 > -- hs.mediasystem.FrontEnd.start(FrontEnd.java:75) > 1.401 | -> RESIZE: 2187154536045615 w: 1440 h: > 860 > -- > com.sun.javafx.tk.quantum.GlassViewEventHandler.handleViewEvent(GlassViewEventHandler.java:444) > 1.411 | ProgramController.registerService() - registering new > service: > hs.mediasystem.screens.SubtitleDownloadService at 8e4e40 > -- > hs.mediasystem.screens.ProgramController.registerWorker(ProgramController.java:430) > 1.413 | ProgramController.registerService() - registering new > service: hs.mediasystem.screens.GroupWorker at 2e9f9e -- > hs.mediasystem.screens.ProgramController.registerWorker(ProgramController.java:430) > 1.659 *| Database up to date at version > 11 > -- > hs.mediasystem.db.DatabaseUpdater.updateDatabase(DatabaseUpdater.java:43) > 1.663 *| Navigator.navigateTo() - Destination('Home'; > modal=false) -- > hs.mediasystem.screens.Navigator.navigateTo(Navigator.java:71) > 1.702 | RESIZE: 2187154837492176 w: 1920 h: 1200 From hjohn at xs4all.nl Thu Jun 14 13:28:00 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Thu, 14 Jun 2012 22:28:00 +0200 Subject: Debugging a UI refresh problem (not dirtyopts related it seems) In-Reply-To: <4FDA402B.3010907@xs4all.nl> References: <4FD81430.3070905@xs4all.nl> <9F66168A-4A50-4A3B-BEF1-CB8549A356A4@oracle.com> <4FDA2F8D.2070908@xs4all.nl> <4FDA402B.3010907@xs4all.nl> Message-ID: <4FDA4950.2040508@xs4all.nl> I created a test case, that reproduces something similar... good chance it is related. See http://javafx-jira.kenai.com/browse/RT-22555 --John On 14/06/2012 21:48, John Hendrikx wrote: > > I seem to have narrowed it down to the call to scrollTo()... when I > remove it, I cannot make it fail anymore. > > So, the case is: > > 1) StackPane with two children, one of them being another StackPane > that contains a TableView or TreeView (happens with either) -- the > Views contain several pages worth of data. > > A KeyEvent occurs, which triggers the following chain: > > 2a) Find the current selected item in said TableView/TreeView, and > make a note of it. > 2b) Remove the StackPane with the View > 2c) Add a new StackPane with a different View > 2d) Reselect the item that was selected in the newly added View > (basically, the code switches between a TreeView and TableView) > > Step 2d) does not do the selection (+scrolling) of the previously > selected item in the same Event (as that has proven in the past to > cause numerous issues...). As a work-around I found that it was > better to defer those calls by simply wrapping them in a > Platform.runLater()... > > So, after the KeyEvent fully completes, with maybe a few other events > in between, our Platform.runLater() code should run, which does the > actual selection (a focus() call) and the scrolling (a scrollTo() call). > > If I comment out the scrollTo(), it works flawlessly and the new > StackPane is always redrawn correctly (but obviously, not in the > correct scroll position) > > If I donot do the focus+scrollTo() in a Platform.runLater() then > basically that part of the code rarely functions properly at all (the > View classes simply donot seem to like it when you do these calls in > the same event that created them and made them part of the Scene, see > my comment in issue RT-18816)... despite that, the behaviour is > slightly different -- not the entire display disappears anymore, but > only the *View class is not drawn correctly (scrollbar visible, but > nothing else). > > So, it seems the problem is concentrated in the View classes, and > specifically how they deal with being created, filled, focused and > scroll'ed'To() in the same KeyEvent :) > > --John > > On 14/06/2012 20:38, John Hendrikx wrote: >> Hi Richard, >> >> The verbose options works, below is the output, dirtyopts seems to be >> false (3rd line). >> >> I've noticed that it is definitely related to whether or not any >> "animation" action occurs after switching a Child of the StackPane... >> if there is any kind of action happening (like an image being loaded, >> or a scrollTo command triggering a slight bit of scrolling) then it >> redraws properly... and it was hard to reproduce it because of that. >> >> However, I've now noticed that when I go back and forth between the >> same screens, and the 2nd time I return to the same view (when all >> Images are cached and the UI can react even faster) then the chance >> of the bug happening is much much bigger (like 90%). Apparently >> because no changes in layout or node values are occuring after the >> initial one... thus if the initial drawing was somehow missed, I end >> up with an empty screen until I do something that triggers a change. >> I'm not convinced that it might not be my fault somehow, but it >> doesn't occur in 2.1. >> >> So, it seems that under certain conditions, removing a child from a >> StackPane and replacing it with a similar child (which is practically >> static) results in it not being drawn. I'll see if I can strip it >> down far enough to make it reproducable in a stand-alone program in >> the weekend -- it is easy enough to reproduce in the main program >> (not like my scroll wheel bug :)) >> >> --John >> >> 0.065 | Prism pipeline init order: d3d >> j2d >> -- >> com.sun.prism.impl.PrismSettings.checkSettings(PrismSettings.java:216) >> 0.066 | Using t2k for text >> rasterization >> -- >> com.sun.prism.impl.PrismSettings.checkSettings(PrismSettings.java:217) >> 0.066 | Not using dirty region >> optimizations >> -- >> com.sun.prism.impl.PrismSettings.checkSettings(PrismSettings.java:221) >> 0.066 | Prism pipeline name = >> com.sun.prism.d3d.D3DPipeline >> -- >> com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:148) >> 0.067 | Loading D3D native library >> ... >> -- com.sun.prism.d3d.D3DPipeline$1.run(D3DPipeline.java:29) >> 0.069 | >> succeeded. >> -- com.sun.prism.d3d.D3DPipeline$1.run(D3DPipeline.java:33) >> 0.134 | Direct3D initialization >> succeeded >> -- com.sun.prism.d3d.D3DPipeline.(D3DPipeline.java:40) >> 0.136 | (X) Got class = class >> com.sun.prism.d3d.D3DPipeline >> -- >> com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:152) >> 0.137 | Initialized prism pipeline: >> com.sun.prism.d3d.D3DPipeline >> -- >> com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:159) >> 0.185 | OS >> Information: >> -- >> com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:87) >> >> 0.185 | Windows 7 build >> 7601 >> -- >> com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:88) >> >> 0.185 | D3D Driver >> Information: >> -- >> com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:89) >> >> 0.185 | NVIDIA GeForce GTX 550 >> Ti >> -- >> com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:90) >> >> 0.185 | >> \\.\DISPLAY3 >> -- >> com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:91) >> >> 0.186 | Driver nvd3dum.dll, version >> 8.17.12.8562 >> -- >> com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:92) >> >> 0.186 | Pixel Shader version >> 3.0 >> -- >> com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:93) >> >> 0.187 | Device : ven_10DE, dev_1244, >> subsys_83C21043 >> -- >> com.sun.prism.d3d.D3DPipeline.printDriverInformation(D3DPipeline.java:94) >> >> 0.220 | javafx.runtime.version: >> 2.2.0-beta-b11 >> -- hs.mediasystem.FrontEnd.start(FrontEnd.java:75) >> 1.401 | -> RESIZE: 2187154536045615 w: 1440 h: >> 860 -- >> com.sun.javafx.tk.quantum.GlassViewEventHandler.handleViewEvent(GlassViewEventHandler.java:444) >> >> 1.411 | ProgramController.registerService() - registering new >> service: >> hs.mediasystem.screens.SubtitleDownloadService at 8e4e40 -- >> hs.mediasystem.screens.ProgramController.registerWorker(ProgramController.java:430) >> >> 1.413 | ProgramController.registerService() - registering new >> service: hs.mediasystem.screens.GroupWorker at 2e9f9e -- >> hs.mediasystem.screens.ProgramController.registerWorker(ProgramController.java:430) >> 1.659 *| Database up to date at version >> 11 >> -- >> hs.mediasystem.db.DatabaseUpdater.updateDatabase(DatabaseUpdater.java:43) >> >> 1.663 *| Navigator.navigateTo() - Destination('Home'; >> modal=false) -- >> hs.mediasystem.screens.Navigator.navigateTo(Navigator.java:71) >> 1.702 | RESIZE: 2187154837492176 w: 1920 h: 1200 > From hang.vo at oracle.com Thu Jun 14 13:48:42 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Jun 2012 20:48:42 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22553 Adding a data item to a PieChart after removing the same item, Message-ID: <20120614204847.7632247921@hg.openjdk.java.net> Changeset: d26daf855de3 Author: Paru Somashekar Date: 2012-06-14 13:48 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/d26daf855de3 RT-22553 Adding a data item to a PieChart after removing the same item, causes NPE. ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java From hang.vo at oracle.com Thu Jun 14 14:22:45 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Jun 2012 21:22:45 +0000 Subject: hg: openjfx/2.2/master/rt: 61 new changesets Message-ID: <20120614212339.7844B47922@hg.openjdk.java.net> Changeset: c43de60706fc Author: jgiles Date: 2012-06-02 09:27 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/c43de60706fc RT-21988: Controls CSS should not check screen resolution unless on an embedded device ! javafx-ui-controls/src/javafx/scene/control/UAStylesheetLoader.java Changeset: 222c53eada42 Author: jgiles Date: 2012-06-02 09:28 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/222c53eada42 [DOC ONLY] Improved ComboBox javadoc to talk about how to use the buttonCell API to custom the button appearance. ! javafx-ui-controls/src/javafx/scene/control/ComboBox.java Changeset: cf257b36b8d1 Author: jgiles Date: 2012-06-02 10:14 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/cf257b36b8d1 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 32f6a7948935 Author: jgiles Date: 2012-06-05 12:23 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/32f6a7948935 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: aa001f13bd63 Author: leifs Date: 2012-06-04 17:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/aa001f13bd63 Fixed RT-21806: NLS: Please keep non-translatable resource strings in a separate resource file ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/EmbeddedResources.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls.properties + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/embedded.properties Changeset: aa28336a1e58 Author: leifs Date: 2012-06-05 10:42 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/aa28336a1e58 Fixed RT-22054: TextInputControl default editing actions badly handled when TextInputControl is not editable ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java Changeset: 46dadf1d60fc Author: Kinsley Wong Date: 2012-06-05 14:44 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/46dadf1d60fc RT-20931: GridPaneDesignInfo.getCellBounds() is not consistent with GridPane.getLayoutBounds(). ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/test/unit/javafx/scene/layout/GridPaneTest.java Changeset: b855ec5afa28 Author: Kinsley Wong Date: 2012-06-05 16:49 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/b855ec5afa28 RT-22026: [Pagination] need strict specification of behavior on max page indicators count. ! javafx-ui-controls/src/javafx/scene/control/Pagination.java ! javafx-ui-controls/test/javafx/scene/control/PaginationTest.java Changeset: bbf040d2b20e Author: Kinsley Wong Date: 2012-06-05 16:54 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/bbf040d2b20e RT-21910: [DOC ONLY] Pagination callback property default value is not specified. ! javafx-ui-controls/src/javafx/scene/control/Pagination.java Changeset: 819d61e7effb Author: Paru Somashekar Date: 2012-06-05 23:39 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/819d61e7effb fix RT-20285 MemoryLeak in javafx.scene.controls.MenuBar ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java Changeset: a447a52d7abd Author: mickf Date: 2012-06-06 15:47 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/a447a52d7abd RT-21090 : ListView ignores initial scrolling ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/VirtualFlowTest.java Changeset: 1f9d7d6bb729 Author: Kinsley Wong Date: 2012-06-06 10:19 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/1f9d7d6bb729 RT22012: Pagination AIOBE when size is set small. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: d82a7c6d2cac Author: Kinsley Wong Date: 2012-06-06 11:20 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/d82a7c6d2cac RT-22098: [Pagination] current page is not updated, when page count is reduced. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: c0039fe78883 Author: Kinsley Wong Date: 2012-06-06 11:23 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/c0039fe78883 Merge Changeset: a3977b2b77b5 Author: leifs Date: 2012-06-06 13:06 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/a3977b2b77b5 Fixed RT-21788: Handles should be displayed in TextBox components, not outside. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/embedded.css Changeset: 0cbd6a3c74bb Author: leifs Date: 2012-06-06 13:26 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/0cbd6a3c74bb Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt Changeset: b14d29378d60 Author: leifs Date: 2012-06-06 13:44 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/b14d29378d60 Virtual keyboard: disable VK for non-editable text controls. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java Changeset: c03a7b34ec86 Author: Kinsley Wong Date: 2012-06-06 16:37 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/c03a7b34ec86 RT-22106: Cancel and Default buttons still receive onAction events triggered by ESC and Enter keys when they are removed from the scene. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ButtonSkin.java ! javafx-ui-controls/test/javafx/scene/control/ButtonTest.java Changeset: b2064c0c3ba3 Author: jgiles Date: 2012-06-05 14:56 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/b2064c0c3ba3 RT-22038: HelloTableView layout problem ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableCellSkin.java Changeset: 12c454b407e2 Author: jgiles Date: 2012-06-05 15:40 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/12c454b407e2 RT-21336: Not editable ComboBox does not paint value setting by code (setValue()) when it does not exist in the list. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 612f0c898954 Author: jgiles Date: 2012-06-06 10:59 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/612f0c898954 RT-21207: ComboBox list width doesn't fit its content when first displayed (if the content is dynamically generated onShowing) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java Changeset: 0f911a5c52bb Author: jgiles Date: 2012-06-06 13:09 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/0f911a5c52bb RT-22025: [ComboBox] initial size doesn't respond the size of the widest content ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 29dd9c8675ec Author: jgiles Date: 2012-06-07 11:13 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/29dd9c8675ec RT-21341: TableView: Moving column to the left of next column moves it to the right of the next column ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkin.java Changeset: 9897f5b8a23d Author: jgiles Date: 2012-06-07 12:51 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/9897f5b8a23d RT-22122: When reordering TableColumns in a TableView, sometimes the header area disappears ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableHeaderRow.java Changeset: 60301b7fd01f Author: jgiles Date: 2012-06-07 13:43 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/60301b7fd01f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: defcb2e3aa77 Author: mickf Date: 2012-06-07 18:03 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/defcb2e3aa77 RT-21952 : Click on button opens context menu ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ButtonSkin.java ! javafx-ui-controls/test/javafx/scene/control/ButtonTest.java Changeset: 966cbfed8d62 Author: mickf Date: 2012-06-07 19:50 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/966cbfed8d62 RT-21782 - Embedded : ScrollPane : ScrollBars need to account for corner when both are present. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java Changeset: dfa7572ff039 Author: Kinsley Wong Date: 2012-06-07 12:47 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/dfa7572ff039 RT-22027: Exception raised for a ComboBox in an Accordion. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/AccordionBehavior.java ! javafx-ui-controls/test/javafx/scene/control/AccordionTest.java Changeset: abbc696491cb Author: mickf Date: 2012-06-08 16:04 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/abbc696491cb RT-19754 - CSS: -fx-padding doesn't work properly on ProgressIndicator ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java Changeset: c7813fd4d4a0 Author: mickf Date: 2012-06-08 18:15 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/c7813fd4d4a0 RT-19738 : Invalid layout behavior with rotates applied ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java Changeset: e1200e6556ab Author: Paru Somashekar Date: 2012-06-08 11:23 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/e1200e6556ab RT-20285 memory leak in javafx.scene.controls.MenuBar ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java Changeset: 527e107cfec5 Author: Paru Somashekar Date: 2012-06-08 12:52 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/527e107cfec5 RT-21891 ChoiceBox popup looks strange after refilling. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ChoiceBoxSkin.java Changeset: 8bc39da3d194 Author: leifs Date: 2012-06-11 10:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/8bc39da3d194 Fixed RT-21658: Touch : TextArea : hard to differentiate between block selection and scrolling ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java Changeset: 85d4575070f8 Author: leifs Date: 2012-06-11 10:45 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/85d4575070f8 Fixed RT-22112: ComboBox : regression with editor selection ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java Changeset: 52cf4be61cfe Author: leifs Date: 2012-06-11 11:02 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/52cf4be61cfe Corrected fix for RT-21788: Adjust padding in TextArea and TextField for Embedded. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/embedded-qvga.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/embedded.css Changeset: 6809fcdc77f4 Author: leifs Date: 2012-06-11 13:04 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/6809fcdc77f4 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt Changeset: f848576e5df0 Author: jgiles Date: 2012-06-07 15:15 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/f848576e5df0 RT-20945: ComboBox, computing the items inside showing property handler fires unwanted onAction event ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java Changeset: d09cc9910784 Author: jgiles Date: 2012-06-08 13:56 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/d09cc9910784 RT-22079: No change event on selection when selected row is removed from TableView ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: 634e4bbb4cf5 Author: jgiles Date: 2012-06-08 15:15 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/634e4bbb4cf5 RT-22077: TableView updates not working when ValueFactory returns a new Binding ! javafx-ui-controls/src/javafx/scene/control/TableCell.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java Changeset: cc8d7f8bbab8 Author: jgiles Date: 2012-06-12 09:44 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/cc8d7f8bbab8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 388637d028f3 Author: jgiles Date: 2012-06-12 15:17 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/388637d028f3 Reinstating a commented out public method on TableColumn that was commented out by mistake in a previous changeset. Unit tests failed because of this, and now pass again. ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java Changeset: a636b9ba88ac Author: jgiles Date: 2012-06-12 16:55 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/a636b9ba88ac Fix for second unit test failure, this time related to listview selection events not firing properly when the row index does not change, but the selected item does. ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java Changeset: a9419005d78b Author: flar Date: 2012-06-05 00:21 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/a9419005d78b Fix RT-21688: optimize PixelReader and PixelWriter implementations + javafx-ui-common/src/com/sun/javafx/image/AlphaType.java + javafx-ui-common/src/com/sun/javafx/image/BytePixelAccessor.java + javafx-ui-common/src/com/sun/javafx/image/BytePixelGetter.java + javafx-ui-common/src/com/sun/javafx/image/BytePixelSetter.java + javafx-ui-common/src/com/sun/javafx/image/ByteToBytePixelConverter.java + javafx-ui-common/src/com/sun/javafx/image/ByteToIntPixelConverter.java + javafx-ui-common/src/com/sun/javafx/image/IntPixelAccessor.java + javafx-ui-common/src/com/sun/javafx/image/IntPixelGetter.java + javafx-ui-common/src/com/sun/javafx/image/IntPixelSetter.java + javafx-ui-common/src/com/sun/javafx/image/IntToBytePixelConverter.java + javafx-ui-common/src/com/sun/javafx/image/IntToIntPixelConverter.java + javafx-ui-common/src/com/sun/javafx/image/PixelAccessor.java + javafx-ui-common/src/com/sun/javafx/image/PixelConverter.java + javafx-ui-common/src/com/sun/javafx/image/PixelGetter.java + javafx-ui-common/src/com/sun/javafx/image/PixelSetter.java + javafx-ui-common/src/com/sun/javafx/image/PixelUtils.java + javafx-ui-common/src/com/sun/javafx/image/impl/BaseByteToByteConverter.java + javafx-ui-common/src/com/sun/javafx/image/impl/BaseByteToIntConverter.java + javafx-ui-common/src/com/sun/javafx/image/impl/BaseIntToByteConverter.java + javafx-ui-common/src/com/sun/javafx/image/impl/BaseIntToIntConverter.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteArgb.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteBgra.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteBgraPre.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteGray.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteGrayAlpha.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteGrayAlphaPre.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteRgb.java + javafx-ui-common/src/com/sun/javafx/image/impl/ByteRgba.java + javafx-ui-common/src/com/sun/javafx/image/impl/General.java + javafx-ui-common/src/com/sun/javafx/image/impl/IntArgb.java + javafx-ui-common/src/com/sun/javafx/image/impl/IntArgbPre.java ! javafx-ui-common/src/com/sun/javafx/tk/PlatformImage.java ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java ! javafx-ui-common/src/javafx/scene/image/Image.java ! javafx-ui-common/src/javafx/scene/image/WritableImage.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubPlatformImage.java Changeset: 0498a5aa3193 Author: kcr Date: 2012-06-05 08:42 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/0498a5aa3193 RT-21777: Changes for snapshot completely break the NetBeans VisualDebugger feature ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 7eb62ef86e4f Author: flar Date: 2012-06-05 18:58 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/7eb62ef86e4f Fix RT-21831: Specify ranges for WritableImage constructor parameters. ! javafx-ui-common/src/javafx/scene/image/Image.java ! javafx-ui-common/src/javafx/scene/image/WritableImage.java Changeset: 188ee39990fe Author: Lubomir Nerad Date: 2012-06-06 12:14 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/188ee39990fe Fix for RT-22015: workaround for incorrect fullscreen visual bounds ! javafx-ui-common/src/com/sun/javafx/Utils.java ! javafx-ui-common/src/javafx/stage/PopupWindow.java ! javafx-ui-common/test/unit/javafx/stage/PopupTest.java Changeset: a4bd88439e22 Author: Pavel Safrata Date: 2012-06-06 18:00 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/a4bd88439e22 RT-22096: Fixed coordinates of touch points delivered to a transformed node. ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/TouchPoint.java ! javafx-ui-common/test/unit/javafx/scene/input/TouchEventTest.java Changeset: 6593c5847d5b Author: Yao Wang Date: 2012-06-06 09:51 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/6593c5847d5b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt ! javafx-ui-common/src/com/sun/javafx/Utils.java Changeset: 2bbfe01c80b3 Author: Morris Meyer Date: 2012-06-06 19:59 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/2bbfe01c80b3 RT-22083 - fix GlobalMenuAdapter so menu action doesn't fire during validation ! javafx-ui-controls/src/com/sun/javafx/scene/control/GlobalMenuAdapter.java Changeset: 2b45c041ff58 Author: Pavel Safrata Date: 2012-06-07 14:03 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/2b45c041ff58 RT-21888: fixed intial state of FocusedProperty. ! javafx-ui-common/src/javafx/scene/Node.java Changeset: dd0048db6e86 Author: Lubomir Nerad Date: 2012-06-07 16:59 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/dd0048db6e86 Fix for RT-22142: Intermittent unit test failures in javafx.stage.PopupTest with JDK7 ! javafx-ui-common/test/unit/javafx/stage/PopupTest.java Changeset: 4427dc34e097 Author: "Joseph Andresen" Date: 2012-06-07 11:26 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/4427dc34e097 RT-21006: unit test canvas update ! javafx-ui-common/test/unit/javafx/scene/canvas/CanvasTest.java Changeset: c9f8ab00f5be Author: Pavel Safrata Date: 2012-06-08 09:39 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/c9f8ab00f5be TouchPoint constructor removed from public API. ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/TouchPoint.java - javafx-ui-common/test/unit/javafx/scene/input/TouchPoint_builder_Test.java Changeset: d5146a3b928f Author: Pavel Safrata Date: 2012-06-08 13:16 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/d5146a3b928f RT-22150: fixed event delivery to nodes with non-invertible transformation. ! javafx-ui-common/src/com/sun/javafx/scene/input/InputEventUtils.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java ! javafx-ui-common/src/javafx/scene/input/DragEvent.java ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchPoint.java ! javafx-ui-common/test/unit/javafx/scene/MouseTest.java Changeset: 796a3a759c37 Author: Felipe Heidrich Date: 2012-06-08 12:23 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/796a3a759c37 [DOC-ONLY] fixing tag in the javadoc for Font#loadFont() ! javafx-ui-common/src/javafx/scene/text/Font.java Changeset: 261c8cd885ec Author: kcr Date: 2012-06-08 16:25 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/261c8cd885ec Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt - javafx-ui-common/test/unit/javafx/scene/input/TouchPoint_builder_Test.java Changeset: 62938da54121 Author: Pavel Safrata Date: 2012-06-11 09:56 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/62938da54121 Fixed mouse event copying problem introduced by fix for RT-22150. ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java Changeset: 97b7b1b4a358 Author: Thor johannesson Date: 2012-06-11 13:49 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/97b7b1b4a358 RT-21925: Canvas consistent handling of text alignment. When multiple lines of text. Doc only change. ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java Changeset: 9def6759a1f2 Author: "Joseph Andresen" Date: 2012-06-12 09:33 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/9def6759a1f2 RT-21735: Canvas Scale and Size do not sync ! javafx-ui-common/src/javafx/scene/canvas/Canvas.java Changeset: 00a63ce77e97 Author: Yao Wang Date: 2012-06-12 10:07 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/00a63ce77e97 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt - javafx-ui-common/test/unit/javafx/scene/input/TouchPoint_builder_Test.java Changeset: 6f2d238b4c8b Author: hudson Date: 2012-06-14 14:06 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/6f2d238b4c8b Added tag 2.2-b13 for changeset 00a63ce77e97 ! .hgtags From hang.vo at oracle.com Thu Jun 14 15:33:32 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Jun 2012 22:33:32 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-21906: must separate shared css calculated values from node-specific css calculated values if node has user set font. Message-ID: <20120614223333.61CB547924@hg.openjdk.java.net> Changeset: 59617134868f Author: David Grieve Date: 2012-06-14 18:26 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/59617134868f RT-21906: must separate shared css calculated values from node-specific css calculated values if node has user set font. ! javafx-ui-common/src/com/sun/javafx/css/CascadingStyle.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java From hang.vo at oracle.com Thu Jun 14 15:56:18 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Jun 2012 22:56:18 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-20643 (partial) Expose StyleManger getPseudoclassStrings for Scene Builder use. Message-ID: <20120614225618.EE7414792C@hg.openjdk.java.net> Changeset: 7c669f613b6c Author: David Grieve Date: 2012-06-14 18:40 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/7c669f613b6c RT-20643 (partial) Expose StyleManger getPseudoclassStrings for Scene Builder use. ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java From hang.vo at oracle.com Thu Jun 14 16:34:03 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Jun 2012 23:34:03 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22166 Axis tick labels are drawn outside chart and over top of axis name Message-ID: <20120614233404.8A0D04792E@hg.openjdk.java.net> Changeset: 217cede187d0 Author: Paru Somashekar Date: 2012-06-14 16:24 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/217cede187d0 RT-22166 Axis tick labels are drawn outside chart and over top of axis name ! javafx-ui-charts/test/javafx/scene/chart/ChartTestBase.java ! javafx-ui-charts/test/javafx/scene/chart/StackedAreaChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/StackedBarChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/XYChartTest.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/javafx/scene/chart/Axis.java ! javafx-ui-controls/src/javafx/scene/chart/ValueAxis.java From zonski at googlemail.com Thu Jun 14 17:13:07 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Fri, 15 Jun 2012 10:13:07 +1000 Subject: Backwards Compatability Message-ID: Below is a little bit of a reminder of the problems with auto-updating and backwards compatibility - I find this announcement from Oracle themselves on their own products to be rather poignant. I think we should feed this sort of historic lessons learned into any and all conversations on JFX installation, auto-updates and backwards compatability topics. Pinning to specific Java versions looks to be a necessity, but there is a contradictory requirement here: Applets need to be auto-updated to be secure in the browser, but updates are not backwards compatible (no matter how hard they try). Pure desktop apps can co-bundle the JRE to achieve version pinning, but applets are required to be installed, and installing multiple versions is not possible. Is it time to kill off Applets? There are still a lot of legacy applets around but really the real world moved on a long time ago - perhaps a mercy stroke would be the best thing for it? -----Original Message----- From: Oracle Applications Users Group [mailto:broadcast at oaug.com] Sent: Friday, 15 June 2012 1:10 AM Subject: Urgent Message from Oracle Corp: Disable JRE Auto-Update for All E-Business Suite End-Users**** ** ** Oracle Corporation has asked the OAUG to relay the following urgent message to our users community.**** ** ** All EBS desktop administrators must disable JRE Auto-Update for their end users immediately.**** ** ** URGENT BULLETIN: Disable JRE Auto-Update for All E-Business Suite End-Users.**** https://blogs.oracle.com/stevenChan/entry/bulletin_disable_jre_auto_update** ** ** ** Why is this required?**** If you have Auto-Update enabled, your JRE 1.6 version will be updated to JRE 7. This may happen as early as July 3, 2012. This will definitely happen after Sept. 7, 2012, after the release of 1.6.0_35 (6u35).**** ** ** Oracle Forms is not compatible with JRE 7 yet. JRE 7 has not been certified with Oracle E-Business Suite yet. Oracle E-Business Suite functionality based on Forms -- e.g. Financials -- will stop working if you upgrade to JRE 7.**** ** ** Related News**** Java JRE 1.6.0_33 is certified with Oracle E-Business Suite**** https://blogs.oracle.com/stevenChan/entry/jre_1_6_0_33**** ** From hang.vo at oracle.com Thu Jun 14 17:48:08 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 15 Jun 2012 00:48:08 +0000 Subject: hg: openjfx/2.2/graphics/rt: 2 new changesets Message-ID: <20120615004815.674D347931@hg.openjdk.java.net> Changeset: 6f2d238b4c8b Author: hudson Date: 2012-06-14 14:06 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/6f2d238b4c8b Added tag 2.2-b13 for changeset 00a63ce77e97 ! .hgtags Changeset: 2e470003ed13 Author: Yao Wang Date: 2012-06-14 17:36 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/2e470003ed13 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt - javafx-ui-common/src/com/sun/javafx/stage/PopupEventRedirector.java From hang.vo at oracle.com Thu Jun 14 20:18:13 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 15 Jun 2012 03:18:13 +0000 Subject: hg: openjfx/2.2/controls/rt: 4 new changesets Message-ID: <20120615031821.50E5D47934@hg.openjdk.java.net> Changeset: adb8d50d8799 Author: jgiles Date: 2012-06-15 13:48 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/adb8d50d8799 RT-20938: javafx.scene.control.Tab: field visible via public API should not be of non-public type ! javafx-ui-controls/src/javafx/scene/control/Tab.java Changeset: 0dc775249a62 Author: jgiles Date: 2012-06-15 14:13 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/0dc775249a62 RT-20582: MenuItem's styleable has a null Node ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java Changeset: 0f2fba17c263 Author: jgiles Date: 2012-06-15 14:37 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/0f2fba17c263 RT-21472: impl_getStyleable is needed on TableColumn ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableHeaderRow.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkin.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java Changeset: 49d2f59fb14e Author: jgiles Date: 2012-06-15 15:05 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/49d2f59fb14e Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt From hang.vo at oracle.com Thu Jun 14 22:17:44 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 15 Jun 2012 05:17:44 +0000 Subject: hg: openjfx/2.2/controls/rt: Fix build failure in MenuItem. Message-ID: <20120615051745.C39A047939@hg.openjdk.java.net> Changeset: 109bddc14dde Author: jgiles Date: 2012-06-15 17:05 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/109bddc14dde Fix build failure in MenuItem. ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java From igor.nekrestyanov at oracle.com Fri Jun 15 00:16:50 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Fri, 15 Jun 2012 00:16:50 -0700 Subject: Deployment: native application bundles Message-ID: <4FDAE162.6070802@oracle.com> Hi, One thing we are adding to JavaFX packaging tools in 2.2 is ability to produce native application bundles: https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx We are not seeing this as the only way to deploy JavaFX applications -- webstart, embedded applications and doubleclickable jars are first class citizens (and it would be great to explore other options). But we hope it might be good option for many deployment scenarios. Please give it a try and provide feedback (and report bugs of course), -igor From zonski at googlemail.com Fri Jun 15 01:16:17 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Fri, 15 Jun 2012 18:16:17 +1000 Subject: Deployment: native application bundles In-Reply-To: <4FDAE162.6070802@oracle.com> References: <4FDAE162.6070802@oracle.com> Message-ID: Very cool! The Ensemble MSI install worked for me on Windows 7 no problems. I haven't tried building my own app as yet though. It installed into 'C:\Users\zonski\AppData\Local\Ensemble2'. Installing into Program Files is probably more correct on windows. Is this 'appdata' the intended final location, or is this just for getting it all running for now? Is the source code available for this at all? If not, I'm very interested in how the 'exe' launcher code looks. Is this code you've written or part of one of the tools you've made use of? I'm particularly interested to see how it starts the app - does it just kick off another process on the executable jar via something like 'java -jar ensemble.jar' or does it try to run the Java app within it's own 'exe' process somehow (I'm assuming the later?). I notice also that the jfx DLLs have been copied straight into the 'jre/bin' directory. Is this how you see all native dependencies playing out, i.e. if my application uses other native libraries how do I package them into the build and where will they be installed to in the extracted directory? Very, very nice start to this all! Cheers, Dan On Fri, Jun 15, 2012 at 5:16 PM, Igor Nekrestyanov < igor.nekrestyanov at oracle.com> wrote: > Hi, > > One thing we are adding to JavaFX packaging tools in 2.2 is ability to > produce native application bundles: > https://blogs.oracle.com/**talkingjavadeployment/entry/** > native_packaging_for_javafx > > We are not seeing this as the only way to deploy JavaFX applications -- > webstart, embedded applications > and doubleclickable jars are first class citizens (and it would be great > to explore other options). > But we hope it might be good option for many deployment scenarios. > > Please give it a try and provide feedback (and report bugs of course), > > -igor > From zonski at googlemail.com Fri Jun 15 01:34:02 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Fri, 15 Jun 2012 18:34:02 +1000 Subject: Deployment: native application bundles In-Reply-To: References: <4FDAE162.6070802@oracle.com> Message-ID: One more question: when we say we have to build on the native platform to get the correct deployments, does that include 32bit vs 64bit? I'm guessing I could have a 32bit and 64bit JDK installation on the one machine and build a version of my app for each, but correct me if I'm wrong on this. I assume there's no way for a single JDK installation to produce both 32 and 64bit versions? On Fri, Jun 15, 2012 at 6:16 PM, Daniel Zwolenski wrote: > Very cool! > > The Ensemble MSI install worked for me on Windows 7 no problems. I haven't > tried building my own app as yet though. > > It installed into 'C:\Users\zonski\AppData\Local\Ensemble2'. Installing > into Program Files is probably more correct on windows. Is this 'appdata' > the intended final location, or is this just for getting it all running for > now? > > Is the source code available for this at all? If not, I'm very interested > in how the 'exe' launcher code looks. Is this code you've written or part > of one of the tools you've made use of? I'm particularly interested to see > how it starts the app - does it just kick off another process on the > executable jar via something like 'java -jar ensemble.jar' or does it try > to run the Java app within it's own 'exe' process somehow (I'm assuming the > later?). > > I notice also that the jfx DLLs have been copied straight into the > 'jre/bin' directory. Is this how you see all native dependencies playing > out, i.e. if my application uses other native libraries how do I package > them into the build and where will they be installed to in the extracted > directory? > > Very, very nice start to this all! > > Cheers, > Dan > > > On Fri, Jun 15, 2012 at 5:16 PM, Igor Nekrestyanov < > igor.nekrestyanov at oracle.com> wrote: > >> Hi, >> >> One thing we are adding to JavaFX packaging tools in 2.2 is ability to >> produce native application bundles: >> https://blogs.oracle.com/**talkingjavadeployment/entry/** >> native_packaging_for_javafx >> >> We are not seeing this as the only way to deploy JavaFX applications -- >> webstart, embedded applications >> and doubleclickable jars are first class citizens (and it would be great >> to explore other options). >> But we hope it might be good option for many deployment scenarios. >> >> Please give it a try and provide feedback (and report bugs of course), >> >> -igor >> > > From lubomir.nerad at oracle.com Fri Jun 15 03:38:43 2012 From: lubomir.nerad at oracle.com (Lubomir Nerad) Date: Fri, 15 Jun 2012 12:38:43 +0200 Subject: API REVIEW: Weak event handler In-Reply-To: <4FD87203.70203@oracle.com> References: <4FD72C57.1040609@oracle.com> <934EC5B5-0318-4580-B000-AFCA69E62384@oracle.com> <4FD87203.70203@oracle.com> Message-ID: <4FDB10B3.1080205@oracle.com> Hi Richard, haven't got any answer from you. I would like to make some progress with this, so here is an updated WeakEventHandler, which should be more to your liking: public final class WeakEventHandler implements EventHandler { public WeakEventHandler(EventHandler eventHandler) { ... } public boolean wasGarbageCollected() { ... } @Override public void handle(T event) { ... } } I removed WeakReference and the factory method, added the additional test method (as in WeakListener) and the public constructor. Is it OK now? Thanks, Lubo On 6/13/2012 12:57 PM, Lubomir Nerad wrote: > Hi Richard, > > On 6/12/2012 10:01 PM, Richard Bair wrote: >> Hi Lubo, >> >>> I also considered to define the WeakEventHandler as an interface >>> which extends EventHandler, but adds no additional methods. Then >>> leave it to event handler containers to reference such event >>> handlers weakly. This has very simple and direct usage, but also its >>> own problems. We can discuss it further if you find this solution >>> preferred to the wrapper approach. >> Extending WeakReference and lacking the public constructor did make >> me a little weak in the knees :-). > > Well, we can of course remove WeakReference from extends and have it > as an instance in WeakEventHandler. But then we need to add some > method to test whether the target handler has been garbage collected > and will have one more instance for each created WeakEventHandler. So > extending WeakReference seemed to me worth considering. On the other > hand having additional test method is more consistent with > Weak*Listener from javafx-beans so we will probably end up with it. As > to the public constructor, I don't like having both (the factory > method and constructor) and in this case the factory method seems to > be easier to use. > >> What were the problems with WeakEventHandler being an interface? >> > > When somebody wants to register a single event handler weakly multiple > times, in the case of WeakEventHandler as a wrapper (the first case), > he needs only to create a single instance of it and register it > multiple types. In the case of WeakEventHandler as a marker (the > second case), each time he registers such event handler a new instance > of weak reference needs to be created by the container for it. Also if > such weak event handler is set to an event handler property (for > example Node.setOnMousePressed), the property implementation needs to > be ready for it and create a weak reference to it. Then when such > event handler is finally garbage collected, the property needs to > return null and ideally at the point of garbage collection it should > notify its listeners (if any) about value change. > >> Thanks! >> Richard > > Lubo > From goddard at seznam.cz Fri Jun 15 05:04:38 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Fri, 15 Jun 2012 14:04:38 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Deployment=3A=20native=20application=20bundles?= In-Reply-To: <4FDAE162.6070802@oracle.com> Message-ID: <129578.6769.25930-20941-558512851-1339761878@seznam.cz> Great, thanks! :) Regards, Jiri ------------ P?vodn? zpr?va ------------ Od: Igor Nekrestyanov P?edm?t: Deployment: native application bundles Datum: 15.6.2012 09:21:55 ---------------------------------------- Hi, One thing we are adding to JavaFX packaging tools in 2.2 is ability to produce native application bundles: https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx We are not seeing this as the only way to deploy JavaFX applications -- webstart, embedded applications and doubleclickable jars are first class citizens (and it would be great to explore other options). But we hope it might be good option for many deployment scenarios. Please give it a try and provide feedback (and report bugs of course), -igor From hjohn at xs4all.nl Fri Jun 15 06:36:48 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Fri, 15 Jun 2012 15:36:48 +0200 Subject: API REVIEW: Weak event handler In-Reply-To: <4FDB10B3.1080205@oracle.com> References: <4FD72C57.1040609@oracle.com> <934EC5B5-0318-4580-B000-AFCA69E62384@oracle.com> <4FD87203.70203@oracle.com> <4FDB10B3.1080205@oracle.com> Message-ID: <4FDB3A70.6040703@xs4all.nl> I can't speak for Richard, but this looks very much in line with the existing WeakChangeListener and WeakInvalidationListener -- I think it's good to do this one in a similar fashion for consistency. --John On 15/06/2012 12:38, Lubomir Nerad wrote: > Hi Richard, > > haven't got any answer from you. I would like to make some progress > with this, so here is an updated WeakEventHandler, which should be > more to your liking: > > public final class WeakEventHandler > implements EventHandler { > public WeakEventHandler(EventHandler eventHandler) { ... } > > public boolean wasGarbageCollected() { ... } > > @Override public void handle(T event) { ... } > } > > I removed WeakReference and the factory method, added the additional > test method (as in WeakListener) and the public constructor. > > Is it OK now? > > Thanks, > Lubo > > On 6/13/2012 12:57 PM, Lubomir Nerad wrote: >> Hi Richard, >> >> On 6/12/2012 10:01 PM, Richard Bair wrote: >>> Hi Lubo, >>> >>>> I also considered to define the WeakEventHandler as an interface >>>> which extends EventHandler, but adds no additional methods. Then >>>> leave it to event handler containers to reference such event >>>> handlers weakly. This has very simple and direct usage, but also >>>> its own problems. We can discuss it further if you find this >>>> solution preferred to the wrapper approach. >>> Extending WeakReference and lacking the public constructor did make >>> me a little weak in the knees :-). >> >> Well, we can of course remove WeakReference from extends and have it >> as an instance in WeakEventHandler. But then we need to add some >> method to test whether the target handler has been garbage collected >> and will have one more instance for each created WeakEventHandler. So >> extending WeakReference seemed to me worth considering. On the other >> hand having additional test method is more consistent with >> Weak*Listener from javafx-beans so we will probably end up with it. >> As to the public constructor, I don't like having both (the factory >> method and constructor) and in this case the factory method seems to >> be easier to use. >> >>> What were the problems with WeakEventHandler being an interface? >>> >> >> When somebody wants to register a single event handler weakly >> multiple times, in the case of WeakEventHandler as a wrapper (the >> first case), he needs only to create a single instance of it and >> register it multiple types. In the case of WeakEventHandler as a >> marker (the second case), each time he registers such event handler a >> new instance of weak reference needs to be created by the container >> for it. Also if such weak event handler is set to an event handler >> property (for example Node.setOnMousePressed), the property >> implementation needs to be ready for it and create a weak reference >> to it. Then when such event handler is finally garbage collected, the >> property needs to return null and ideally at the point of garbage >> collection it should notify its listeners (if any) about value change. >> >>> Thanks! >>> Richard >> >> Lubo >> > From Claus.Luethje at osys.ch Fri Jun 15 06:37:24 2012 From: Claus.Luethje at osys.ch (Claus Luethje) Date: Fri, 15 Jun 2012 13:37:24 +0000 Subject: Deployment: native application bundles In-Reply-To: <129578.6769.25930-20941-558512851-1339761878@seznam.cz> References: <4FDAE162.6070802@oracle.com> <129578.6769.25930-20941-558512851-1339761878@seznam.cz> Message-ID: <193FF4ED343AF14F8CDC65B4792C954D131E9CF6@Jeri.osys.ch> This is really cool stuff! Claus -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of goddard at seznam.cz Sent: Freitag, 15. Juni 2012 14:05 To: Igor Nekrestyanov Cc: openjfx-dev at openjdk.java.net Subject: Re: Deployment: native application bundles Great, thanks! :) Regards, Jiri ------------ P?vodn? zpr?va ------------ Od: Igor Nekrestyanov P?edm?t: Deployment: native application bundles Datum: 15.6.2012 09:21:55 ---------------------------------------- Hi, One thing we are adding to JavaFX packaging tools in 2.2 is ability to produce native application bundles: https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx We are not seeing this as the only way to deploy JavaFX applications -- webstart, embedded applications and doubleclickable jars are first class citizens (and it would be great to explore other options). But we hope it might be good option for many deployment scenarios. Please give it a try and provide feedback (and report bugs of course), -igor From hang.vo at oracle.com Fri Jun 15 10:18:23 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 15 Jun 2012 17:18:23 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-22548 javadoc update for imagepattern Message-ID: <20120615171828.78D6D47965@hg.openjdk.java.net> Changeset: f7c21c251366 Author: "Joseph Andresen" Date: 2012-06-15 10:02 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/f7c21c251366 RT-22548 javadoc update for imagepattern ! javafx-ui-common/src/javafx/scene/paint/ImagePattern.java From randahl at rockit.dk Fri Jun 15 10:58:31 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Fri, 15 Jun 2012 19:58:31 +0200 Subject: The need for a FixedText control Message-ID: <4FDB77C7.4090903@rockit.dk> I think JavaFX is missing a text control for presenting uneditable, styled text - a FixedText control. As I am about to file a feature request, I thought it would be relevant to discuss it here first. In the following UI the left column shows three labels implemented using Label, and the the right column has a field showing the Customer ID, a CheckBox for editing the VIP status of the customer, and finally a TextField for adding some kind of note about the VIP status: Customer ID: 12345678 (non-editable text) VIP: [x] (editable CheckBox) VIP note: |_________| (editable TextField In this UI, the user is always able to edit the VIP CheckBox, and if it is checked, the previously uneditable VIP note TextField becomes editable. The customer ID is never editable. So what component do we choose when implementing the uneditable customer ID field? Our options are: 1. Implementing the customer ID field as a label. 2. Implementing the customer ID as a TextField which is marked uneditable. 3. Implementing the customer ID as a raw Text instance. None of these options are very pleasing: - 1. Using a label is semantically incorrect, since it does not label anything (the labelFor property would have no meaning). Also, it would at least require a special style class to distinguish it from real labels, and it would not be efficient to have to set this style class everywhere we have a non-editable text field. - 2. Using a TextField for which editable has been set to false is not that good an idea either - by default, TextFields are rendered as a box, which indicates that the user can input something here, at least at least in some situations (like the VIP status field above). Again, we would require special styling for it to look different from other real TextFields, and we would have to set a specific style class everywhere we had a non-editable text field. -3. Using a raw Text instance is a bad idea too, since it is not a real JavaFX Control, which means it does not automatically have a style class of "text", it is not skinnable, cannot be copied using mouse gestures, is not draggable, etc. So my thoughts are, that JavaFX could benefit from a FixedText control. This would work much like a TextField, only it would mean "a forever uneditable text control". It would by default have a style class of "fixed-text", the user would be able to mark and copy its contents, drag it, etc. - just like the contents of a TextField. Any thoughts? Randahl From anthony.vanelverdinghe at gmail.com Fri Jun 15 11:24:03 2012 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Fri, 15 Jun 2012 20:24:03 +0200 Subject: The need for a FixedText control In-Reply-To: <4FDB77C7.4090903@rockit.dk> References: <4FDB77C7.4090903@rockit.dk> Message-ID: <4FDB7DC3.4000601@gmail.com> Hi Randahl Personally, I don't see any added value over using a non-editable TextField (i.e. option 2). The way I understand your explanation, an implementation of such a control can easily be created by extending TextField & overriding a few methods (like setEditable & getStyleClass), so I don't see why this should be added to JavaFX. Kind regards Anthony Op 15/06/2012 19:58, Randahl Fink Isaksen schreef: > I think JavaFX is missing a text control for presenting uneditable, > styled text - a FixedText control. As I am about to file a feature > request, I thought it would be relevant to discuss it here first. > > In the following UI the left column shows three labels implemented > using Label, and the the right column has a field showing the Customer > ID, a CheckBox for editing the VIP status of the customer, and finally > a TextField for adding some kind of note about the VIP status: > > Customer ID: 12345678 (non-editable text) > VIP: [x] (editable CheckBox) > VIP note: |_________| (editable TextField > > In this UI, the user is always able to edit the VIP CheckBox, and if > it is checked, the previously uneditable VIP note TextField becomes > editable. The customer ID is never editable. So what component do we > choose when implementing the uneditable customer ID field? Our options > are: > > 1. Implementing the customer ID field as a label. > 2. Implementing the customer ID as a TextField which is marked > uneditable. > 3. Implementing the customer ID as a raw Text instance. > > None of these options are very pleasing: > > - 1. Using a label is semantically incorrect, since it does not label > anything (the labelFor property would have no meaning). Also, it would > at least require a special style class to distinguish it from real > labels, and it would not be efficient to have to set this style class > everywhere we have a non-editable text field. > > - 2. Using a TextField for which editable has been set to false is not > that good an idea either - by default, TextFields are rendered as a > box, which indicates that the user can input something here, at least > at least in some situations (like the VIP status field above). Again, > we would require special styling for it to look different from other > real TextFields, and we would have to set a specific style class > everywhere we had a non-editable text field. > > -3. Using a raw Text instance is a bad idea too, since it is not a > real JavaFX Control, which means it does not automatically have a > style class of "text", it is not skinnable, cannot be copied using > mouse gestures, is not draggable, etc. > > So my thoughts are, that JavaFX could benefit from a FixedText > control. This would work much like a TextField, only it would mean "a > forever uneditable text control". It would by default have a style > class of "fixed-text", the user would be able to mark and copy its > contents, drag it, etc. - just like the contents of a TextField. > > Any thoughts? > > Randahl From richard.bair at oracle.com Fri Jun 15 11:57:19 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 15 Jun 2012 11:57:19 -0700 Subject: The need for a FixedText control In-Reply-To: <4FDB77C7.4090903@rockit.dk> References: <4FDB77C7.4090903@rockit.dk> Message-ID: <692664FC-3291-4518-A7C1-C5883782DF96@oracle.com> I would just use a Label. The use of labelFor is optional, and without it, it is exactly what you're looking for (pending support for rich text, more in a second). I don't think adding a new class / control for the use case is justified when you can just use a Label for it. Now, what I've wanted (and hopefully will get in Lombard) is the ability to set rich text on any Labeled. So on a Label, Button, CheckBox, etc you would be able to set rich text. There have been two ideas, principally, around this. The first is to just semantically inspect the string, much like Swing, such that "Rich Text" ends up being handled properly. The second idea is to add a "contentType" property, such that you can set the contentType to TEXT_HTML (or whatever) and then we know what to interpret the String of characters as. The benefit of the first approach is that it requires less tinkering and we don't have to figure out what the "content type" is (do we just reuse javafx.scene.input.DataFormat? It has HTML, PLAIN_TEXT, RTF, etc. FILES and IMAGE don't make sense, but what the heck). We would just have built in support for HTML and that's it. The benefit for the second approach is that it is (a) clear how you intend for the string to be interpreted and (b) extensible. We could add new supported formats (such as, for example, bbcode or something) and it would still be as easy to set. Basically you just set the string and tell us how to interpret it, and for supported formats, this would just work. Richard On Jun 15, 2012, at 10:58 AM, Randahl Fink Isaksen wrote: > I think JavaFX is missing a text control for presenting uneditable, styled text - a FixedText control. As I am about to file a feature request, I thought it would be relevant to discuss it here first. > > In the following UI the left column shows three labels implemented using Label, and the the right column has a field showing the Customer ID, a CheckBox for editing the VIP status of the customer, and finally a TextField for adding some kind of note about the VIP status: > > Customer ID: 12345678 (non-editable text) > VIP: [x] (editable CheckBox) > VIP note: |_________| (editable TextField > > In this UI, the user is always able to edit the VIP CheckBox, and if it is checked, the previously uneditable VIP note TextField becomes editable. The customer ID is never editable. So what component do we choose when implementing the uneditable customer ID field? Our options are: > > 1. Implementing the customer ID field as a label. > 2. Implementing the customer ID as a TextField which is marked uneditable. > 3. Implementing the customer ID as a raw Text instance. > > None of these options are very pleasing: > > - 1. Using a label is semantically incorrect, since it does not label anything (the labelFor property would have no meaning). Also, it would at least require a special style class to distinguish it from real labels, and it would not be efficient to have to set this style class everywhere we have a non-editable text field. > > - 2. Using a TextField for which editable has been set to false is not that good an idea either - by default, TextFields are rendered as a box, which indicates that the user can input something here, at least at least in some situations (like the VIP status field above). Again, we would require special styling for it to look different from other real TextFields, and we would have to set a specific style class everywhere we had a non-editable text field. > > -3. Using a raw Text instance is a bad idea too, since it is not a real JavaFX Control, which means it does not automatically have a style class of "text", it is not skinnable, cannot be copied using mouse gestures, is not draggable, etc. > > So my thoughts are, that JavaFX could benefit from a FixedText control. This would work much like a TextField, only it would mean "a forever uneditable text control". It would by default have a style class of "fixed-text", the user would be able to mark and copy its contents, drag it, etc. - just like the contents of a TextField. > > Any thoughts? > > Randahl From igor.nekrestyanov at oracle.com Fri Jun 15 11:59:44 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Fri, 15 Jun 2012 11:59:44 -0700 Subject: Deployment: native application bundles In-Reply-To: References: <4FDAE162.6070802@oracle.com> Message-ID: <4FDB8620.9030105@oracle.com> hi, thanks for all questions. Please keep them coming (bugs and suggestions are very welcome too!), > The Ensemble MSI install worked for me on Windows 7 no problems. I > haven't tried building my own app as yet though. > > It installed into 'C:\Users\zonski\AppData\Local\Ensemble2'. > Installing into Program Files is probably more correct on windows. Is > this 'appdata' the intended final location, or is this just for > getting it all running for now? Original goal was to be able to install without requiring admin permissions. Both MSI and EXE installers are currently build to do this. It is possible to customize install location and make it system wide by tweaking WiX/Inno Setup template files. Clearly we want to expose better APIs for customization but it is not clear what are importnat config parameters and how to expose them in more or less cross platform way, hence we decided that for 2u2 we will provide an easy way to build basic package and do minimal customization as well as (very) advanced way for advanced users. Based on feedback we will figure out how to expand built-in configuration APIs for future releases. I am planning to post more about package customization options and other tricks&tips but i am amateur blogger and slow typer, so it will take me few days :) Perhaps we should reconsider and produce EXE to be user level installation and MSI to be system level by default. I believe it is also possible to pass parameters to msiexec to overwrite some of MSI settings (end this is not unusual in the enterprise deployments). However, i had not tried if it is possible to install this MSI system wide (and i am not sure if my MSI expertise is deep enough to craft MSI that can do both, suggestions are very welcome). > > Is the source code available for this at all? Sorry, it is part of deploy/packager module that is not open sourced yet. > If not, I'm very interested in how the 'exe' launcher code looks. Is > this code you've written or part of one of the tools you've made use > of? I'm particularly interested to see how it starts the app - does it > just kick off another process on the executable jar via something like > 'java -jar ensemble.jar' or does it try to run the Java app within > it's own 'exe' process somehow (I'm assuming the later?). yes, launcher will instantiate JVM in the launcher process. Check out list of processes when sample app is running. There is no java.exe but there is Ensemble.exe > > I notice also that the jfx DLLs have been copied straight into the > 'jre/bin' directory. Starting 7u6 JRE/JDK will include JavaFX as part of Java installation. So, nothing special here. It is just runtime image. > Is this how you see all native dependencies playing out, i.e. if my > application uses other native libraries how do I package them into the > build and where will they be installed to in the extracted directory? No, i do not think application resources will go into runtime. Application resources will stay in the "app" folder (native libs too). The approach here is to "bundle" app without requiring to rewrite it. During the development cycle your build output should have copy of application you can execute and debug (but it depends on environment, i.e. java+javafx runtime). Bundle is essentially copy of this application + java runtime + launcher Having said that i had not tried to craft example with native libraries myself. Will certainly try to do. > One more question: when we say we have to build on the native platform > to get the correct deployments, does that include 32bit vs 64bit? I'm > guessing I could have a 32bit and 64bit JDK installation on the one > machine and build a version of my app for each, but correct me if I'm > wrong on this. yes, two installations should do. Currently ant task will try to use RUNNING version of java as source for cobundle. If it is not appropriate (e.g. java 6 that is not javafx cobundle) then it bundled app will not be created. In the future we may add option to specify which JDK to use as import for bundle creation but for now we are taking shortcuts to avoid exposing too much (kind of late in release). > I assume there's no way for a single JDK installation to produce both > 32 and 64bit versions? No, as currently JDK installations do not include both 32 and 64 bit bits. After all we are copying them into bundle. -igor > Very, very nice start to this all! > > Cheers, > Dan > > > On Fri, Jun 15, 2012 at 5:16 PM, Igor Nekrestyanov > > > wrote: > > Hi, > > One thing we are adding to JavaFX packaging tools in 2.2 is > ability to produce native application bundles: > https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx > > We are not seeing this as the only way to deploy JavaFX > applications -- webstart, embedded applications > and doubleclickable jars are first class citizens (and it would be > great to explore other options). > But we hope it might be good option for many deployment scenarios. > > Please give it a try and provide feedback (and report bugs of course), > > -igor > > From lehmann at media-interactive.de Fri Jun 15 12:32:03 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Fri, 15 Jun 2012 21:32:03 +0200 Subject: Update JavaFX in JFXPanel while EDT is blocked Message-ID: <4FDB8DB3.9070206@media-interactive.de> Hi, is there a way to force a JFXPanel to update itself while the EDT is blocked? This is my situation: on startup the Swing application shows a login screen with a progress bar. This login screen is a JFXPanel and the progress bar is a JavaFX control. In the background lots of initializations are going on, and much of this should run on the EDT. Therefore it is executing within SwingUtilties.invokeAndWait - but that also seems to block updates to the JFXPanel and the progressbar is not updated. Maybe I can force an immediate repaint of the progressbar only? After all, I am running two GUI toolkits at the same time, both with their own GUI threads, so I'd like to take advantage of that... Thx. Werner From richard.bair at oracle.com Fri Jun 15 12:44:33 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 15 Jun 2012 12:44:33 -0700 Subject: Update JavaFX in JFXPanel while EDT is blocked In-Reply-To: <4FDB8DB3.9070206@media-interactive.de> References: <4FDB8DB3.9070206@media-interactive.de> Message-ID: <58E92C60-8586-4E4B-9A83-AA0B1BFF4356@oracle.com> Ya, there isn't a way to do this (because the drawing of the JFXPanel is actually in the Swing EDT). Further, we're looking at ways to combine the Swing EDT & FX Thread (the current idea is to have Swing use the FX thread as the EDT, rather than trying to get the FX thread to use the Swing EDT, but its a long story), so in the future you might actually not have two GUI toolkit threads at all (the upside of which would be no more SwingUtilities.invokeLater / Platform.runLater calls). Either show the JavaFX stage separate from the JFXPanel, such that it really is in its own thread, or break up the Swing init to occur over multiple events or force rendering at certain points. Probably showing JavaFX in its own stage is the best approach? Richard On Jun 15, 2012, at 12:32 PM, Werner Lehmann wrote: > Hi, > > is there a way to force a JFXPanel to update itself while the EDT is blocked? > > This is my situation: on startup the Swing application shows a login screen with a progress bar. This login screen is a JFXPanel and the progress bar is a JavaFX control. In the background lots of initializations are going on, and much of this should run on the EDT. Therefore it is executing within SwingUtilties.invokeAndWait - but that also seems to block updates to the JFXPanel and the progressbar is not updated. > > Maybe I can force an immediate repaint of the progressbar only? After all, I am running two GUI toolkits at the same time, both with their own GUI threads, so I'd like to take advantage of that... > > Thx. > > Werner From lehmann at media-interactive.de Fri Jun 15 12:51:12 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Fri, 15 Jun 2012 21:51:12 +0200 Subject: Update JavaFX in JFXPanel while EDT is blocked In-Reply-To: <58E92C60-8586-4E4B-9A83-AA0B1BFF4356@oracle.com> References: <4FDB8DB3.9070206@media-interactive.de> <58E92C60-8586-4E4B-9A83-AA0B1BFF4356@oracle.com> Message-ID: <4FDB9230.9000005@media-interactive.de> Hi Richard, On 15.06.2012 21:44, Richard Bair wrote: > in the future you might actually not have two GUI toolkit threads at > all (the upside of which would be no more SwingUtilities.invokeLater > / Platform.runLater calls). That will definitely simplify/remove some boilerplate. And I guess, it will also contribute to making the UI more responsive. > Probably showing JavaFX in its own stage is the best approach? Well, the stage is shown as part of a JFrame. So I can only think of a JavaFX Popup in just the right position. Which will be fun when users start to resize or move the window... Or did you have something else in mind? > break up the Swing init to occur over multiple events or force > rendering at certain points I'd recommend the former to myself but it is not going to happen soon. Legacy code. How can I force rendering? Rgds Werner From richard.bair at oracle.com Fri Jun 15 13:31:41 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 15 Jun 2012 13:31:41 -0700 Subject: Auto-update of native application bundles Message-ID: Hi, On my blog[1] I posted an article linking to Igor's blog about application deployment. I went on to describe scenarios where native app bundles do not require auto-update (primarily, when dealing with IT department's distributing MSI files or when using an app store), and conversely those that do require auto-update (just about everything else). I mentioned that I've been talking with Dan Zwolenski (aka Zonski) about Sparkle and auto-update requirements and he's been building a prototype. There are basically two ways we can take this. The first is that we can try to find some native auto-update system on each of the desktop operating systems, and then build a think Java API that sits on top of these. This approach would allow us to leverage existing code and get some robust auto-update in place much quicker. On mac for instance we would just use Sparkle and it would be rock solid from day one. I have concerns about this approach. First, the mechanism by which you communicate with the application that it is time to update is likely going to be different for different native auto-update frameworks. Sparkle for example uses "app casting" -- an RSS feed with a URL to the new version. Google's auto-update frameworks probably use some other mechanism. I think it is unacceptable to ask developers to use multiple different deployment mechanisms for telling the app that it is time to update. So that would then suggest we have to have some custom code + Java API + native auto-update frameworks -- now things are getting complicated. Plus, different frameworks have different feature sets, so we either have to use the intersection of APIs supported by all, or we have to modify frameworks with features that are missing. I don't think it should really be that complicated. I think that essentially doing an auto-update mechanism in nearly all Java (with a minor bit of native code) would reduce the numbers of bugs we have to deal with over all, and would also ensure the same API across all of the desktop operating systems (or embedded systems that don't force the use of an app store). Sparkle is very versatile and yet essentially maintained by one guy, so I think it should be feasible that we could support a similar feature set in Java. I've asked Dan if he wanted to spearhead this work and he's been enthusiastic about doing so. With that introduction, Dan, the rest is your's :-). I'm hoping we can put the auto-update mechanism into the lombard repositories (what we're calling 3.0) as soon as they open. In the meantime I know he has a prototype for Windows. Cheers Richard [1] http://fxexperience.com/2012/06/application-deployment-with-javafx/ From richard.bair at oracle.com Fri Jun 15 13:33:19 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 15 Jun 2012 13:33:19 -0700 Subject: Update JavaFX in JFXPanel while EDT is blocked In-Reply-To: <4FDB9230.9000005@media-interactive.de> References: <4FDB8DB3.9070206@media-interactive.de> <58E92C60-8586-4E4B-9A83-AA0B1BFF4356@oracle.com> <4FDB9230.9000005@media-interactive.de> Message-ID: <2C2E9507-6A66-40D0-9D12-D2396F90D18D@oracle.com> >> Probably showing JavaFX in its own stage is the best approach? > > Well, the stage is shown as part of a JFrame. So I can only think of a > JavaFX Popup in just the right position. Which will be fun when users > start to resize or move the window... Or did you have something else in mind? OK, I was thinking the entire login screen would be a separate window and all javaFX, and then it would launch the Swing app and then you could hide the JavaFX window when login completed. >> break up the Swing init to occur over multiple events or force >> rendering at certain points > > I'd recommend the former to myself but it is not going to happen soon. > Legacy code. How can I force rendering? I've forgotten the Swing magic to be honest, I bet Jasper remembers (but I'm sure the web remembers if you look for it). Richard From kimtopley at gmail.com Fri Jun 15 13:41:26 2012 From: kimtopley at gmail.com (kimtopley at gmail.com) Date: Fri, 15 Jun 2012 20:41:26 +0000 Subject: Update JavaFX in JFXPanel while EDT is blocked In-Reply-To: <2C2E9507-6A66-40D0-9D12-D2396F90D18D@oracle.com> References: <4FDB8DB3.9070206@media-interactive.de> <58E92C60-8586-4E4B-9A83-AA0B1BFF4356@oracle.com> <4FDB9230.9000005@media-interactive.de> <2C2E9507-6A66-40D0-9D12-D2396F90D18D@oracle.com> Message-ID: <1388936915-1339792887-cardhu_decombobulator_blackberry.rim.net-1821879909-@b2.c12.bise6.blackberry> The magic that you want is paintImmediately(). Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Richard Bair Sender: openjfx-dev-bounces at openjdk.java.net Date: Fri, 15 Jun 2012 13:33:19 To: Werner Lehmann Cc: openjfx-dev at openjdk.java.net Subject: Re: Update JavaFX in JFXPanel while EDT is blocked >> Probably showing JavaFX in its own stage is the best approach? > > Well, the stage is shown as part of a JFrame. So I can only think of a > JavaFX Popup in just the right position. Which will be fun when users > start to resize or move the window... Or did you have something else in mind? OK, I was thinking the entire login screen would be a separate window and all javaFX, and then it would launch the Swing app and then you could hide the JavaFX window when login completed. >> break up the Swing init to occur over multiple events or force >> rendering at certain points > > I'd recommend the former to myself but it is not going to happen soon. > Legacy code. How can I force rendering? I've forgotten the Swing magic to be honest, I bet Jasper remembers (but I'm sure the web remembers if you look for it). Richard From lehmann at media-interactive.de Fri Jun 15 13:46:59 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Fri, 15 Jun 2012 22:46:59 +0200 Subject: Update JavaFX in JFXPanel while EDT is blocked In-Reply-To: <1388936915-1339792887-cardhu_decombobulator_blackberry.rim.net-1821879909-@b2.c12.bise6.blackberry> References: <4FDB8DB3.9070206@media-interactive.de> <58E92C60-8586-4E4B-9A83-AA0B1BFF4356@oracle.com> <4FDB9230.9000005@media-interactive.de> <2C2E9507-6A66-40D0-9D12-D2396F90D18D@oracle.com> <1388936915-1339792887-cardhu_decombobulator_blackberry.rim.net-1821879909-@b2.c12.bise6.blackberry> Message-ID: <4FDB9F43.5090205@media-interactive.de> Thanks to both of you. I'll try that next week. On 15.06.2012 22:41, kimtopley at gmail.com wrote: > The magic that you want is paintImmediately(). > > > Sent from my Verizon Wireless BlackBerry > > -----Original Message----- > From: Richard Bair > Sender: openjfx-dev-bounces at openjdk.java.net > Date: Fri, 15 Jun 2012 13:33:19 > To: Werner Lehmann > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Update JavaFX in JFXPanel while EDT is blocked > >>> Probably showing JavaFX in its own stage is the best approach? >> >> Well, the stage is shown as part of a JFrame. So I can only think of a >> JavaFX Popup in just the right position. Which will be fun when users >> start to resize or move the window... Or did you have something else in mind? > > OK, I was thinking the entire login screen would be a separate window and all javaFX, and then it would launch the Swing app and then you could hide the JavaFX window when login completed. > >>> break up the Swing init to occur over multiple events or force >>> rendering at certain points >> >> I'd recommend the former to myself but it is not going to happen soon. >> Legacy code. How can I force rendering? > > I've forgotten the Swing magic to be honest, I bet Jasper remembers (but I'm sure the web remembers if you look for it). > > Richard From jonathan.giles at oracle.com Fri Jun 15 13:58:32 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Sat, 16 Jun 2012 08:58:32 +1200 Subject: Auto-update of native application bundles In-Reply-To: References: Message-ID: <4FDBA1F8.8080103@oracle.com> After much talking I'm very pleased to see code is being written. This is of the utmost importance in my opinion. I often tell the story of how impressed I am with other UI toolkits. I occassionally see that they need an update, and show a nice looking and succinct update interface that does everything painlessly and automatically. What blows me away further is that applications that are written in this UI toolkit are able to access exactly the same updating mechanism for their own application updates. The fact that an application developer can painlessly update their application is incredibly wonderful, coming from my background of having to write custom update preloaders for clients in the past. The complexity in these things is rather high - you have to have some form of script to contain the update instructions, and be a preloader for the application (so you need some way of starting up the application that works on most operating systems). Key words from the above paragraph: 'nice looking', 'succinct update interface', 'painlessly', and 'automatically'. I really hope we can pull something along these lines of - it would be great! In short, I am pleased that this is something we are now taking seriously, and something that I think end-developers will be pleased about to. This should be a simple, painless process that we provide, and I look forward to testing it out! Feel free to drag me into any form of feedback cycle and or end-user testing. -- Jonathan On 16/06/2012 8:31 a.m., Richard Bair wrote: > Hi, > > On my blog[1] I posted an article linking to Igor's blog about application deployment. I went on to describe scenarios where native app bundles do not require auto-update (primarily, when dealing with IT department's distributing MSI files or when using an app store), and conversely those that do require auto-update (just about everything else). I mentioned that I've been talking with Dan Zwolenski (aka Zonski) about Sparkle and auto-update requirements and he's been building a prototype. > > There are basically two ways we can take this. The first is that we can try to find some native auto-update system on each of the desktop operating systems, and then build a think Java API that sits on top of these. This approach would allow us to leverage existing code and get some robust auto-update in place much quicker. On mac for instance we would just use Sparkle and it would be rock solid from day one. > > I have concerns about this approach. First, the mechanism by which you communicate with the application that it is time to update is likely going to be different for different native auto-update frameworks. Sparkle for example uses "app casting" -- an RSS feed with a URL to the new version. Google's auto-update frameworks probably use some other mechanism. I think it is unacceptable to ask developers to use multiple different deployment mechanisms for telling the app that it is time to update. So that would then suggest we have to have some custom code + Java API + native auto-update frameworks -- now things are getting complicated. Plus, different frameworks have different feature sets, so we either have to use the intersection of APIs supported by all, or we have to modify frameworks with features that are missing. > > I don't think it should really be that complicated. I think that essentially doing an auto-update mechanism in nearly all Java (with a minor bit of native code) would reduce the numbers of bugs we have to deal with over all, and would also ensure the same API across all of the desktop operating systems (or embedded systems that don't force the use of an app store). Sparkle is very versatile and yet essentially maintained by one guy, so I think it should be feasible that we could support a similar feature set in Java. > > I've asked Dan if he wanted to spearhead this work and he's been enthusiastic about doing so. With that introduction, Dan, the rest is your's :-). > > I'm hoping we can put the auto-update mechanism into the lombard repositories (what we're calling 3.0) as soon as they open. In the meantime I know he has a prototype for Windows. > > Cheers > Richard > > [1] http://fxexperience.com/2012/06/application-deployment-with-javafx/ From hang.vo at oracle.com Fri Jun 15 14:05:06 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 15 Jun 2012 21:05:06 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-21745: Bad strange layout in VBox caused by Label.setWrapText(true). Message-ID: <20120615210507.F25964796B@hg.openjdk.java.net> Changeset: ba93ff7e1f24 Author: Kinsley Wong Date: 2012-06-15 13:58 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/ba93ff7e1f24 RT-21745: Bad strange layout in VBox caused by Label.setWrapText(true). ! javafx-ui-common/src/javafx/scene/layout/AnchorPane.java ! javafx-ui-common/test/unit/javafx/scene/layout/AnchorPaneTest.java From richard.bair at oracle.com Fri Jun 15 14:38:35 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 15 Jun 2012 14:38:35 -0700 Subject: Backwards Compatability In-Reply-To: References: Message-ID: As embarrassing as it is for an Oracle memo of this type, this does perfectly illustrate the problem with the present Applet / JNLP based deployment mechanism. Igor has been looking at another mechanism whereby the JRE that you need to run with is shipped along with the app over JNLP. This type of deployment would require full permissions all the time (ie: you couldn't be unsigned and target a specific JRE that is shipped with your app). But this would allow people invested in Applet / WebStart to pin to a version of the JRE without having multiple JRE's installed on the system, or exposing the machine to additional security risks beyond what downloading an app would give you. We might also require a valid cert rather than a self-signed cert for this case. Richard On Jun 14, 2012, at 5:13 PM, Daniel Zwolenski wrote: > Below is a little bit of a reminder of the problems with auto-updating and > backwards compatibility - I find this announcement from Oracle themselves > on their own products to be rather poignant. I think we should feed this > sort of historic lessons learned into any and all conversations on JFX > installation, auto-updates and backwards compatability topics. > > Pinning to specific Java versions looks to be a necessity, but there is a > contradictory requirement here: Applets need to be auto-updated to be > secure in the browser, but updates are not backwards compatible (no matter > how hard they try). Pure desktop apps can co-bundle the JRE to achieve > version pinning, but applets are required to be installed, and installing > multiple versions is not possible. > > Is it time to kill off Applets? There are still a lot of legacy applets > around but really the real world moved on a long time ago - perhaps a mercy > stroke would be the best thing for it? > > > -----Original Message----- > > From: Oracle Applications Users Group [mailto:broadcast at oaug.com] > Sent: Friday, 15 June 2012 1:10 AM > Subject: Urgent Message from Oracle Corp: Disable JRE Auto-Update for All > E-Business Suite End-Users**** > > ** ** > > Oracle Corporation has asked the OAUG to relay the following urgent message > to our users community.**** > > ** ** > > All EBS desktop administrators must disable JRE Auto-Update for their end > users immediately.**** > > ** ** > > URGENT BULLETIN: Disable JRE Auto-Update for All E-Business Suite > End-Users.**** > > https://blogs.oracle.com/stevenChan/entry/bulletin_disable_jre_auto_update** > ** > > ** ** > > Why is this required?**** > > If you have Auto-Update enabled, your JRE 1.6 version will be updated to > JRE 7. This may happen as early as July 3, 2012. This will definitely > happen after Sept. 7, 2012, after the release of 1.6.0_35 (6u35).**** > > ** ** > > Oracle Forms is not compatible with JRE 7 yet. JRE 7 has not been > certified with Oracle E-Business Suite yet. Oracle E-Business Suite > functionality based on Forms -- e.g. Financials -- will stop working if you > upgrade to JRE 7.**** > > ** ** > > Related News**** > > Java JRE 1.6.0_33 is certified with Oracle E-Business Suite**** > > https://blogs.oracle.com/stevenChan/entry/jre_1_6_0_33**** > > ** From richard.bair at oracle.com Fri Jun 15 14:44:23 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 15 Jun 2012 14:44:23 -0700 Subject: javafx.scene.input.*Event classes construction In-Reply-To: <4FD9FB44.9030400@oracle.com> References: <4FD9BF79.2020105@oracle.com> <4BF66087-0618-416D-9656-7C9BDFE5978E@oracle.com> <4FD9FB44.9030400@oracle.com> Message-ID: <417604B2-2908-447B-A799-487D9156F616@oracle.com> >> As for the approach, I think you do the constructors with all params (since events are immutable you have no choice really -- static factory or constructor and I prefer in this case a constructor) + builder (auto generated). > And what do you think about impl_copy methods? Personally I think we should remove them completely and turn them to some internal utility methods. My initial thought was a copy constructor. > Also, some events are not 100% immutable, as they are modified during the Scene processing through some impl_methods, like MouseEvent.impl_setClickParam. We'd either need to make some/all of the Event fields protected and do this modifications through subclasses or create some "accessor" in javafx.scene.input package for calling these methods from javafx.scene package. Good question, I guess we can revisit these in context of the other impl_ method removal things we're working on. Richard From richard.bair at oracle.com Fri Jun 15 14:53:46 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 15 Jun 2012 14:53:46 -0700 Subject: JavaFX Form Validation In-Reply-To: <400BA4FE-3B71-4798-9480-7F62D2D1A38D@gmail.com> References: <4FD5332A.5080608@oracle.com> <4fd76555.09d6e00a.463f.7a12@mx.google.com> <4FD77DDC.4080806@media-interactive.de> <4FD78018.4090900@tbee.org> <4fd7889b.47d0e00a.2e05.ffff9515@mx.google.com> <4FD864BB.7080105@rockit.dk> <4fd87d44.0cb2e00a.5e0a.1cc4@mx.google.com> <196AC79A-C699-4183-95A2-C189EE0BEF81@gmail.com> <4FD8B88F.7070406@media-interactive.de> <193FF4ED343AF14F8CDC65B4792C954D131E8134@Jeri.osys.ch> <91192062-8690-43E6-9A9B-02FB8DA782F6@muenster.de> <400BA4FE-3B71-4798-9480-7F62D2D1A38D@gmail.com> Message-ID: Presently we have the following impl_ methods for dealing with pseudo classes: protected void impl_pseudoClassStateChanged(String pseudoClass) public long impl_getPseudoClassState() private static final long HOVER_PSEUDOCLASS_STATE = StyleManager.getInstance().getPseudoclassMask("hover"); // and so forth So what happens is if a class has a custom pseudo class state, it has to fetch a mask for it such as in the HOVER_PSEUDOCLASS_STATE example. Whenever it detects that the pseudo class state has changed (for example, "hover" boolean changes) it invokes the impl_pseudoClassStateChanged method, which asks CSS whether this particular node has a style that depends on that pseudo class, so that it only requests CSS to be reapplied if there is a style change involved (avoids us having to recompute CSS when "hover" changes if no style for the node cares about "hover"). The CSS engine then, when applying CSS, asks the node for impl_getPseudoClassState which returns a long which is the mask of all pseudo class states that this node is in. This allows for a very fast match as to whether a style applies to this node or not. So the short answer is we cannot have dynamic pseudo classes without sacrificing performance. Either we use a BitSet instead of a long, or we have to go to using set.contains() (which would kill us). The longer answer is that we sort of need to support custom pseudo-classes at some point, but maybe I'm not sure how to do so without hurting performance. For those interested, all the CSS code is part of javafx-ui-common in the open source code and the code above is found in Node. Between Node, Parent, Region, and Control you should be able to know as much of how this works as anybody (StyleManager and StyleHelper are the other two guys really worth looking at. It isn't easy to read because of the amount of performance tuning / fast paths / caches that have gone into this). Now our goal was for Lombard to have public API so that UI control authors could add custom pseudo-classes. SO that basically means the impl_ methods will for sure be changed between now and then, but you can see how the mechanism works and supply patches if you like :-) Richard On Jun 14, 2012, at 12:45 AM, Daniel Zwolenski wrote: > Would it be possible to attach our own arbitrary pseudo classes to controls via code? > > Eg. Button.setPseudoClass("highlighted") > > That would then cover the error case and much more. Eg I might have 'error', 'warning', 'required', 'highlighted', etc. > > I do not know if the CSS engine will be able to handle this. > > > > On 14/06/2012, at 5:19 PM, Gerrit Grunwald wrote: > >> +1 >> Am 14.06.2012 um 08:37 schrieb Claus Luethje: >> >>> +1 >>> >>> -----Original Message----- >>> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Werner Lehmann >>> Sent: Mittwoch, 13. Juni 2012 17:58 >>> To: >>> Subject: Re: JavaFX Form Validation >>> >>> +1 >>> >>> I think it could be useful to have a css pseudoclass for controls with invalid state. >>> >>> Rgds >>> Werner >>> >>> On 13.06.2012 15:23, Daniel Zwolenski wrote: >>>> My vote is for JFX to provide low level building blocks for developers >>>> to hook in to and then for open source tool kits (like >>>> Jfxtras) to provide the higher level tools. So JFX would have no >>>> validation framework but instead would provide ways to, for example, >>>> visually highlight nodes, and a community built toolkit would use this >>>> to provide a validation framework. >> From richard.bair at oracle.com Fri Jun 15 15:05:20 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 15 Jun 2012 15:05:20 -0700 Subject: Patch: issue RT-14177 In-Reply-To: <201206061630.38210.fbrunner@gmx.ch> References: <201204051750.13667.fbrunnerlist@gmx.ch> <395446C7-1B53-4035-BA83-3AC263470D36@oracle.com> <201206061630.38210.fbrunner@gmx.ch> Message-ID: It should be there now as part of b12. Richard On Jun 6, 2012, at 7:30 AM, Florian Brunner wrote: > Hi Richard, > > Thanks for pushing the patch. What is the best way to test it? Will it be part of build b12 or b13? > > Regards, > Florian > > Am Montag 04 Juni 2012, 20:03:34 schrieb Richard Bair: >> I've pushed the latest patch we agreed to over the weekend: >> >> Changeset: ba58ca4a265f >> Author: rbair >> Date: 2012-06-04 10:40 -0700 >> URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/ba58ca4a265f >> >> >> Now I am having some difficulty devising a unit test for this. I need to replicate (in as simple a manner as possible) the test scenario. I created a custom ClassLoader which only loads the FakeSkin, FakeControl, or FakeControlBase classes as necessary (so that class loader A only loads the FakeSkin and FakeControlBase, class loader B loads the FakeControl and delegates to A if necessary, etc). However the problem is that the original Class.forName("...FakeSkin") call always succeeds because the system class loader knows how to find and load it. How do I hide the class from the system class loader? >> >> Richard >> >> >> On Jun 1, 2012, at 1:54 PM, Richard Bair wrote: >> >>> OK, now for the tricky part. Writing the tests! I figure I might also add a sample to Ensemble showing how to use -fx-skin (feeling a little ambitious for a Friday afternoon :-)). >>> >>> Richard >> >> > From ozemale at ozemail.com.au Fri Jun 15 16:05:01 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Sat, 16 Jun 2012 09:05:01 +1000 Subject: Deployment: native application bundles In-Reply-To: <4FDAE162.6070802@oracle.com> References: <4FDAE162.6070802@oracle.com> Message-ID: <009101cd4b4b$4b3ad670$e1b08350$@com.au> This is very promising but has a few problems at present. I downloaded both the JavaFX Ensemble EXE and MSI installers along with the JFXtras Ensemble MSI installer. They all install fine but the JavaFX Ensemble application doesn't work on my Windows 7 64-bit machine. It runs but selecting any of the demos does nothing. I am sure this is just a teething problem as the JFXtras app works fine. The main deficiencies are as follows: 1. There is no icon installed on the desktop. Putting an icon on the desktop is standard Windows application installer behaviour. 2. There is no notification that the install has completed successfully. 3. The EXE installer looks ancient and bland. When compared to something like the Flash installer and updater which are sleek and modern looking, the JavaFX app installer looks very poor. 4. When running the app, there is no icon set for when you use Alt-Tab to flip between running applications. It still feels like a Java app instead of a native Windows app. 5. The app does not get installed into an appropriate location such as Program Files. Again this feels like a non-native app and doesn't permit it being run my more than one Windows user on the same machine. 6. The download size is way too big. Having to download nearly 50MB for a basic app that just lets you select a few controls is a problem in this mobile platform centric world. I realise Project Jigsaw will address this but it is definitely a problem at the moment. I look forward to continued improvements in this technology. -jct -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Igor Nekrestyanov Sent: Friday, 15 June 2012 17:17 To: openjfx-dev at openjdk.java.net Subject: Deployment: native application bundles Hi, One thing we are adding to JavaFX packaging tools in 2.2 is ability to produce native application bundles: https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_ja vafx We are not seeing this as the only way to deploy JavaFX applications -- webstart, embedded applications and doubleclickable jars are first class citizens (and it would be great to explore other options). But we hope it might be good option for many deployment scenarios. Please give it a try and provide feedback (and report bugs of course), -igor From zonski at googlemail.com Fri Jun 15 17:02:06 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Sat, 16 Jun 2012 10:02:06 +1000 Subject: Auto-update of native application bundles In-Reply-To: <4FDBA1F8.8080103@oracle.com> References: <4FDBA1F8.8080103@oracle.com> Message-ID: Hey guys, Those of you who have been on this list for a while will know this topic of deployment is one I'm pretty passionate about: in my opinion JFX cannot succeed without a simple, effective deployment model. I've been pretty vocal on this in the past (probably to the point of irritating) and I'm extremely excited to see the developments in this area. As Richard mentioned, I've been talking to him about the direction this is heading for a little while now and decided to stop talking and throw my hat in the ring. Over the last couple of weeks I've been prototyping a solution based on these early discussions. This is really just a proof of concept - the code is rough and the features limited, but the idea is to demonstrate one way it could work. I stress "one way", as there are also many other possible solutions out there and the one I am putting forward should be seen as a starting point, not a final locked in solution. Currently my prototype works only on Windows (the platform I develop on, and am most comfortable with) but the solution is designed so that it can be extended to all desktop platforms - just the native components need to be replaced for each platform. At a code level, I've tried to section off these adaptation points to make it easy to extend the prototype to other platforms. I've also developed the UI in Swing at this stage as I wanted to put off the whole native/JFX versioning issue for now. This is high on my list to address. While I was developing this, Igor has been working on the native packaging tools that he introduced in his recent blog post. Igor's focus has been on native installing and launching and he's ignored auto-updating at this stage. My prototype focuses on auto-updating and as yet does not worry about the actual installer too much (I cheated and used a free, third-party MSI builder ), since I knew Igor was working in this area. The design is similar: we both co-bundle a JRE and use a native compiled launcher (e.g. 'exe') to setup the appropriate classpath and launch the Java process. However due to the fact that Igor is developing behind the closed doors of Oracle the solutions have been developed independently of each other and share no code. Although Igor focuses on installation, and I focus on auto-updating, the common 'launcher' functionality is duplicated between the two solutions. i.e. I've had to write my own C++ native launcher for Windows since I couldn't get access to Igor's (yet). The intent (or at least my intent) is to flesh out my POC, extend it to more OS's, add more features, and get feedback and input from you guys. Then eventually Igor can feed back whatever works well into his packaging tools as part of future official JFX releases. Both Igor and Richard are on board with this general idea, so treat my POC as a way to communicate and demonstrate what we want in JFX. Your feedback and comments will be critical in getting a great solution in place. Your code contributions will be even more valuable and anyone who wants to pitch in is very encourages to do so (you will need to sign the Oracle Contributors agreement, but this is pretty easy). So what follows is a an outline of the general approach used, a working example, and a more detailed look at the code and current implementation. I look forward to hearing from anyone and everyone who has an opinion on this topic. *The General Approach* The solution is designed entirely around co-bundled JREs - i.e. the JRE instance is included in the distribution and is used only for that application. It is not installed (it does not need to be), it is simply extracted into the application folder and runs directly from there. There is no use of a system-wide JRE in this approach. Richard made the case for this in his blog, but to reiterate the core drivers for going down this path are: - Ability to pin an app to a JRE version - each app has its own JRE so each can upgrade at their own pace and co-exist with each other - No need for a separate Java installation - a horrible experience for non-technical users, and one that requires admin access to the system - No need for browser plugin installations, etc - the applet deployment model and its peculiar requirements are now separated from desktop deployment - Better integration with the emerging Desktop 'app stores', where the app must be fully contained in the deployed app store bundle (installing a JRE will likely be nigh on impossible on Mac before long) A native package is developed for each platform, so on Windows an 'MSI', Mac a 'dmg' etc. This installer is actually fairly light-weight. It's main job is to extract the JRE and jars for the app to a directory and then include the 'launcher.exe' (or platform equivalent) to launch the app. On windows, the MSI I use simply extracts these files, adds a shortcut to the Start Bar and registers an uninstaller with the windows registry. This is about as lightweight as an installer gets - there are no additional registry entries or registered DLLs etc. So far, the approach described is much in line with what Igor has done. The main area where my POC diverges is in the area of auto-updates. That is, the ability to check for a newer version of the application (including the move to a higher JRE version), and then download and use that new version if it exists. Richard made reference to Sparkle and like him, I feel this is a nice reference point for the style of solution we want. The neat thing that Sparkle does is it provides an API that developers can use inside their code to completely control and customise the upgrade of their application. This is the approach I've gone for as well. My POC includes a Java API that you can call to check for updates and trigger downloads. It comes with it's own UI components for the most common workflows but if you want to override these and hook in your own UI or workflow components you can. Maybe you want to force the customer to accept new T&C's before upgrading, or maybe you just want to theme the upgrade dialogs to look more like your UI. It's all nice, clean Java so you are back in control. Unlike the current JNLP/Java way of doing updates there will be no more ugly, random 'You need to update Java' dialogs popping up to scare your users. The auto-updating is inside your app and only happens when your app is in use (and when you trigger it from your code). An XML deployment descriptor, called 'app-profile.xml' is used to describe the JARs, JRE versions and other launch details - it is semantically comparable to a traditional JNLP file. When an update is triggered via the API, the code checks the remote URL for an updated app-profile.xml. If it finds one it downloads this and checks this with its local app-profile.xml. Any jars that have different version numbers are downloaded, and if a new JRE version is defined in the app-profile then the zip for this is downloaded and extracted as well. Once all the downloading is complete, the local app-profile is then overwritten with the newer one and this newer one will be used by the native launcher to set the classpath next time the app is started. I think this approach is neat and powerful, but it's worth mentioning that there is still some debate amongst the JFX team about whether to go down this road or avoid the Java API and use off-the-shelf native updaters. Your input will very likely influence this decision so if you have a preference one way or the other (or have other suggestions), be vocal. *A Working Example* To test and demonstrate my POC, I've created a little test-app, assembled it as an MSI, deployed it to my server and then uploaded a patch update to my server as well so that when you check for updates, an upgrade will take place. Just for fun, I made the first MSI installed version use Java6 and the upgrade one use Java7, so when you do an upgrade it will also download a new JRE (from my site as well - distribution, licencing issues are still a little hazy and we're looking into this in more detail. Technically we are legally allowed to co-bundle for the initial install but this area of auto-updating and JRE redistribution is a bit loose in the T&C's). You can download the initial installer from here: http://zenjava.com/demo/update/testapp.msi Unlike Igor's installer, this will install in Program Files (and so will prompt a UAC security notice). It also installs an uninstaller so you can always go to "Control Panel -> Add/Remove Programs" to completely remove it. It adds a shortcut to the Start Menu (called "Zen Deploy Test Application"), and when it installs it unpacks a directory structure like so: installdir/ + launcher.exe + app-profile.xml + admin-exec.exe installdir/app + zen-deploy-api-1.0-SNAPSHOT.jar + zen-deploy-testapp-1.0-SNAPSHOT.jar + zen-deploy-win-impl-1.0-SNAPSHOT.jar installdir/jre + 1.6/ *(direct copy of a full JRE installation is under here)* When you run (by selecting the shortcut from the start menu, or you could double click launcher.exe) it will popup a little Swing GUI which is the test application. This could do anything, but I've made my app check for an update on startup. If an update is found it shows the details of the update and an option to upgrade. Click it and it will go through the motions of upgrading and finally restart itself. To make it clear what version you are on, the first installed version is a lovely yellow, the updated version is an even more attractive green. Note that the feedback of the installation process is poor. You only see a single, indeterminate progress bar for the whole time. I intend to address this pretty soon with more informative progress information and the ability to cancel the upgrade. Error handing is also very poor, so if something goes wrong you may not get great feedback at this stage of the POC. After installation you can see that a new JAR (version 2.0 of zen-deploy-testapp) has been included in the 'app' directory, and also a new JRE (1.7) has been downloaded to the 'jre' directory. Currently the old JAR and JRE do not get deleted so they are still hanging around in the directories but they are not used since they are not referenced in the app-profile.xml. Deleting these while the app is running proved difficult (as they are locked), so I need a more creative solution (probably delete them on next startup) - this is also in the todo list. *The Implementation* As I mentioned earlier the code is pretty rough. It's a rapid prototype, which means I haven't done any unit tests or pretty JavaDoc and I don't handle errors well. I have tried to be fairly clean in my code structure however and I hope it's not too hard to follow. If you need more direction, just ask. One disclaimer - my C++ is extremely rusty (it's been over 10 years since I last touched it), so don't judge me by this :) I would welcome any and all input from veteran C++ developers out there who want to substitute my clunky code for something a little more hard core and impressive. The full source code can be found at: http://code.google.com/p/zen-deploy/source/checkout I've called it 'Zen Deploy' and used my zenjava domain just to have something to reference it by. This is not intended to be a stand-alone, long term product (unless the JFX team want to go that way but I would prefer not), anything that works should eventually get rolled into JFX proper and Zen Deploy eventually decommissioned. I use 'zen' cause it's small and distinctive. It's a Maven project but don't let that scare you off if you are not a Maven user. There are pretty much no external dependencies on other libraries so just open the source code and build however you normally do. It's not overly automated anyway, due to the project consisting of native modules and MSI packagers, etc, and if you want to actually assemble it there's a few steps to go through. If anyone is actually keen to build and is having trouble let me know, and I'll talk you thought it. If you're just wanting to get your head around it and feedback, you can probably get away with just flicking through the code. Following Maven's convention I've split it into a bunch of sub-modules so it looks a little large at first, but there's not actually that much code in there. You can probably get away with just checking out a few choice classes if you're interested in how it works. Here's a little site map to help you out: Modules: 1. *zen-deploy*: top level parent module for everything else (open the pom.xml in intellij and you will have access to all the Java code in one project) 2. *zen-deploy-api **(creates zen-deploy-api.jar)*: the generic (i.e. OS independent) API and utility classes for auto-updating. I've also included the higher level gui/workflow components here but that was slightly lazy as these should probably be in a module of their own (one for Swing, one for JFX, one for HTML, etc). 3. *zen-deploy-win-impl ** (creates zen-deploy-win-impl.jar) *: this is the windows implementation of the zen-deploy-api. This implements the 'updateNow' methods defined in the API to do windows specific stuff (such as playing nice with the UAC). 4. *zen-deploy-win-launch **(creates launcher.exe) *: this is a Visual C++ project which generates the 'launch.exe' file that goes into the final bundle. This file is the main launching point for the app and it starts up a Java process based on the app-profile.xml file. 5. *zen-deploy-win-admin-exec **(creates admin-exec.exe) *: another little Visual C++ project. This one generates 'admin-exec.exe' which is included in the final bundle and is used by the windows AU Java implementation to move files into 'Program Files' by playing friendly with windows UAC/security. 6. *zen-deploy-testapp* *(creates zen-deploy-testapp.jar)* : this is a very small sample application that is used to demonstrate the auto-update API. This is what's deployed as an MSI at: http://zenjava.com/demo/update/testapp.msi There are two versions to this, a yellow one and a green one. I just build these two manually (i.e. I comment out some code, build then comment it back in, and build again). 7. *zen-deploy-win-msi **(creates testapp.msi)* : this is an 'Advanced Installer ' project used to create the MSI. You need to have Advanced Installer installed and then you need to manually copy the output files from all the other projects into the 'bundle' directory so it can be packaged up. This wouldn't exist in a more complete solution, the MSI would be generated off the project files of 'testapp' using built-in tools (i.e. similar to the installers Igor is putting together for jfx2.2). The main classes/files you might find interesting are: *in zen-deploy-testapp: * - *ZenDeployTestApp.java* : the example 'app' that uses the updater API. It's a normal, everyday (Swing) app that just embeds the 'wizard' component from the API into it's own panel but it could just as easily pop this up in a dialog, etc. - *app-profile.xml *: the XML deployment descriptor for launching the TestApp. This is just a PoC syntax, plenty of things missing and plenty of room to clean-up. *in zen-deploy-win-launch: * - *ZenLauncherWin32.cpp ** :* the C++ launcher file that reads the 'app-profile.xml' file and launches a Java process configured appropriately (e.g. sets the classpath). *in zen-deploy-api:* - *ZenDeployManager.java* : the main entry point into the lower level AU API. This provides the methods for updating and checking versions, some of which is implemented directly in this class and some is deferred to the OS specific sub-classes. - *ApplicationUpdateWizard.java* : a basic Wizard component (in Swing) that steps a user through the update process. This would obviously be a lot prettier and feature rich in a real implementation (and written in JFX!). in zen-deploy-win-impl: - *ZenDeployManagerWinImpl.java * : the windows specific implementation of the ZenDeployManager. This adds all the logic for downloading the files, unzipping them and copying in ways that Windows is happy with. - *WinUacFriendlyFileMover.java* : a class I'd prefer not to need, but this is here to support UAC on windows. This class re-launches itself in an 'elevated' process (i.e. run as admin) in order to copy files into the 'Program Files' directory. *Next Steps* This first POC works but there are still quite a lot of things to add before the POC can really be considered proof that the concept will work. In particular I want to look into the following (in rough order of priority): - Including native files in the app distribution, especially JFX - Updating the GUI components to use JFX instead of Swing (or rather in addition to - the framerwork is intended to be UI agnostic) - Extending the POC to other platforms, especially Mac and Linux - Providing better feedback on the upgrade progress and allowing the user to cancel - Cleaning up files after an upgrade (i.e. removing obsolete files) - Possibly looking at ANT and/or Maven tasks to assemble deployment bundles Additionally I'd like to start working more with Igor to make my launcher more inline with what he is doing. Ideally the auto-updating code should work with the packaging tool he has created, regardless of whether the code gets rolled back into JFX proper or not. As I've not-so-subtly hinted at a few times above, there's plenty of work for anyone who wants to stick their hand-up and all of this is in need of heavy review and feedback. I'd be particularly interested in hearing from anyone who wants to help port this to Mac and Linux as I don't have easy access to these environments to develop and test on. If you want an awesome deployment solution for Java, now's your chance to have your say. Cheers, Dan On Sat, Jun 16, 2012 at 6:58 AM, Jonathan Giles wrote: > After much talking I'm very pleased to see code is being written. This is > of the utmost importance in my opinion. > > I often tell the story of how impressed I am with other UI toolkits. I > occassionally see that they need an update, and show a nice looking and > succinct update interface that does everything painlessly and > automatically. What blows me away further is that applications that are > written in this UI toolkit are able to access exactly the same updating > mechanism for their own application updates. The fact that an application > developer can painlessly update their application is incredibly wonderful, > coming from my background of having to write custom update preloaders for > clients in the past. The complexity in these things is rather high - you > have to have some form of script to contain the update instructions, and be > a preloader for the application (so you need some way of starting up the > application that works on most operating systems). > > Key words from the above paragraph: 'nice looking', 'succinct update > interface', 'painlessly', and 'automatically'. I really hope we can pull > something along these lines of - it would be great! > > In short, I am pleased that this is something we are now taking seriously, > and something that I think end-developers will be pleased about to. This > should be a simple, painless process that we provide, and I look forward to > testing it out! Feel free to drag me into any form of feedback cycle and or > end-user testing. > > -- Jonathan > > > On 16/06/2012 8:31 a.m., Richard Bair wrote: > >> Hi, >> >> On my blog[1] I posted an article linking to Igor's blog about >> application deployment. I went on to describe scenarios where native app >> bundles do not require auto-update (primarily, when dealing with IT >> department's distributing MSI files or when using an app store), and >> conversely those that do require auto-update (just about everything else). >> I mentioned that I've been talking with Dan Zwolenski (aka Zonski) about >> Sparkle and auto-update requirements and he's been building a prototype. >> >> There are basically two ways we can take this. The first is that we can >> try to find some native auto-update system on each of the desktop operating >> systems, and then build a think Java API that sits on top of these. This >> approach would allow us to leverage existing code and get some robust >> auto-update in place much quicker. On mac for instance we would just use >> Sparkle and it would be rock solid from day one. >> >> I have concerns about this approach. First, the mechanism by which you >> communicate with the application that it is time to update is likely going >> to be different for different native auto-update frameworks. Sparkle for >> example uses "app casting" -- an RSS feed with a URL to the new version. >> Google's auto-update frameworks probably use some other mechanism. I think >> it is unacceptable to ask developers to use multiple different deployment >> mechanisms for telling the app that it is time to update. So that would >> then suggest we have to have some custom code + Java API + native >> auto-update frameworks -- now things are getting complicated. Plus, >> different frameworks have different feature sets, so we either have to use >> the intersection of APIs supported by all, or we have to modify frameworks >> with features that are missing. >> >> I don't think it should really be that complicated. I think that >> essentially doing an auto-update mechanism in nearly all Java (with a minor >> bit of native code) would reduce the numbers of bugs we have to deal with >> over all, and would also ensure the same API across all of the desktop >> operating systems (or embedded systems that don't force the use of an app >> store). Sparkle is very versatile and yet essentially maintained by one >> guy, so I think it should be feasible that we could support a similar >> feature set in Java. >> >> I've asked Dan if he wanted to spearhead this work and he's been >> enthusiastic about doing so. With that introduction, Dan, the rest is >> your's :-). >> >> I'm hoping we can put the auto-update mechanism into the lombard >> repositories (what we're calling 3.0) as soon as they open. In the meantime >> I know he has a prototype for Windows. >> >> Cheers >> Richard >> >> [1] http://fxexperience.com/2012/**06/application-deployment-** >> with-javafx/ >> > > > From zonski at googlemail.com Fri Jun 15 17:20:57 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Sat, 16 Jun 2012 10:20:57 +1000 Subject: Deployment: native application bundles In-Reply-To: <4FDB8620.9030105@oracle.com> References: <4FDAE162.6070802@oracle.com> <4FDB8620.9030105@oracle.com> Message-ID: Thanks for the responses Igor. I've sent a longer email detailing my auto-updating prototype (which you are already aware of) to the group so hopefully we can start looking at these two topics in conjunction with each other. Regarding the MSI installer, using WiX does make it easier but I'm wondering if there would be some merit in trying to write our own MSI creator using the Windows Installer SDK. I haven't used it myself yet but I believe it can be used to create MSI's. This would have the advantage of not needing extra software installed, and also would allow us to customise closely to what we need specifically for Java installations (e.g. provide our own configuration options in whatever syntax or format we want - e.g. an 'app-profile.xml'). The disadvantage of course is the extra work, but this may be something I could look at in my POC side of it. Something to think about anyway. Regarding natives, if you are using an executable JAR I don't think this will work (i.e. executable JARs don't support native included in them), unless the developer does the old extract and include on path trick. Better that the natives just get bundled into the installation directory and not into the jar, I reckon. It's a bit of a messy area (especially for auto-updates) so probably worth making sure we're covered in this area fairly early on. Regarding the launching of the process, the way I do it also seems to give it the process the name of the app the proper name (and not 'java.exe'), which is a pleasant surprise. Do you use the same sort of code as follows? string jrePath = JRE_INSTALL_DIR + jreVersion + JRE_EXE_PATH; string launchParams = CLASPPATH_SWITCH + classpath + " " + mainClass ; STARTUPINFO siStartupInfo; PROCESS_INFORMATION piProcessInfo; memset(&siStartupInfo, 0, sizeof(siStartupInfo)); memset(&piProcessInfo, 0, sizeof(piProcessInfo)); siStartupInfo.cb = sizeof(siStartupInfo); if(CreateProcess(jrePath.data(), // Application name (LPSTR)launchParams.data(), // Application arguments 0, 0, FALSE, CREATE_DEFAULT_ERROR_MODE, 0, 0, // Working directory &siStartupInfo, &piProcessInfo) == FALSE) { // Could not start application -> call 'GetLastError()' MessageBox(NULL, TEXT("There was an error while launching the application"), TEXT("Launch Failed"), MB_OK); return FALSE; } I'd be keen to keep what I do in line with what you are doing where possible. On Sat, Jun 16, 2012 at 4:59 AM, Igor Nekrestyanov < igor.nekrestyanov at oracle.com> wrote: > hi, thanks for all questions. > > Please keep them coming (bugs and suggestions are very welcome too!), > > > The Ensemble MSI install worked for me on Windows 7 no problems. I > haven't tried building my own app as yet though. > > It installed into 'C:\Users\zonski\AppData\Local\Ensemble2'. Installing > into Program Files is probably more correct on windows. Is this 'appdata' > the intended final location, or is this just for getting it all running for > now? > > Original goal was to be able to install without requiring admin > permissions. > Both MSI and EXE installers are currently build to do this. > > It is possible to customize install location and make it system wide by > tweaking WiX/Inno Setup template files. > Clearly we want to expose better APIs for customization but it is not > clear what are importnat config parameters and how to expose them > in more or less cross platform way, hence we decided that for 2u2 we will > provide an easy way to build basic package and do minimal customization > as well as (very) advanced way for advanced users. > > Based on feedback we will figure out how to expand built-in configuration > APIs for future releases. > > I am planning to post more about package customization options and other > tricks&tips but i am amateur blogger and slow typer, so it will take me few > days :) > > Perhaps we should reconsider and produce EXE to be user level installation > and MSI to be system level by default. > I believe it is also possible to pass parameters to msiexec to overwrite > some of MSI settings (end this is not unusual in the enterprise > deployments). > However, i had not tried if it is possible to install this MSI system wide > (and i am not sure if my MSI expertise is deep enough to craft MSI that can > do both, > suggestions are very welcome). > > > Is the source code available for this at all? > > Sorry, it is part of deploy/packager module that is not open sourced yet. > > If not, I'm very interested in how the 'exe' launcher code looks. Is > this code you've written or part of one of the tools you've made use of? > I'm particularly interested to see how it starts the app - does it just > kick off another process on the executable jar via something like 'java > -jar ensemble.jar' or does it try to run the Java app within it's own 'exe' > process somehow (I'm assuming the later?). > > yes, launcher will instantiate JVM in the launcher process. > Check out list of processes when sample app is running. There is no > java.exe but there is Ensemble.exe > > > I notice also that the jfx DLLs have been copied straight into the > 'jre/bin' directory. > > Starting 7u6 JRE/JDK will include JavaFX as part of Java installation. > So, nothing special here. It is just runtime image. > > Is this how you see all native dependencies playing out, i.e. if my > application uses other native libraries how do I package them into the > build and where will they be installed to in the extracted directory? > > No, i do not think application resources will go into runtime. > Application resources will stay in the "app" folder (native libs too). > > The approach here is to "bundle" app without requiring to rewrite it. > During the development cycle your build output should have copy of > application you can execute and debug (but it depends on environment, i.e. > java+javafx runtime). > Bundle is essentially > copy of this application + java runtime + launcher > > Having said that i had not tried to craft example with native libraries > myself. Will certainly try to do. > > One more question: when we say we have to build on the native platform to > get the correct deployments, does that include 32bit vs 64bit? I'm guessing > I could have a 32bit and 64bit JDK installation on the one machine and > build a version of my app for each, but correct me if I'm wrong on this. > > yes, two installations should do. > > Currently ant task will try to use RUNNING version of java as source for > cobundle. > If it is not appropriate (e.g. java 6 that is not javafx cobundle) then it > bundled app will not be created. > > In the future we may add option to specify which JDK to use as import for > bundle creation but for now we are taking shortcuts to avoid exposing too > much (kind of late in release). > > I assume there's no way for a single JDK installation to produce both 32 > and 64bit versions? > > No, as currently JDK installations do not include both 32 and 64 bit bits. > After all we are copying them into bundle. > > -igor > > Very, very nice start to this all! > > Cheers, > Dan > > > On Fri, Jun 15, 2012 at 5:16 PM, Igor Nekrestyanov < > igor.nekrestyanov at oracle.com> wrote: > >> Hi, >> >> One thing we are adding to JavaFX packaging tools in 2.2 is ability to >> produce native application bundles: >> >> https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx >> >> We are not seeing this as the only way to deploy JavaFX applications -- >> webstart, embedded applications >> and doubleclickable jars are first class citizens (and it would be great >> to explore other options). >> But we hope it might be good option for many deployment scenarios. >> >> Please give it a try and provide feedback (and report bugs of course), >> >> -igor >> > > > From igor.nekrestyanov at oracle.com Fri Jun 15 22:51:16 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Fri, 15 Jun 2012 22:51:16 -0700 Subject: Deployment: native application bundles In-Reply-To: <009101cd4b4b$4b3ad670$e1b08350$@com.au> References: <4FDAE162.6070802@oracle.com> <009101cd4b4b$4b3ad670$e1b08350$@com.au> Message-ID: <4FDC1ED4.1040509@oracle.com> John, thank you for trying it and your valuable feedback! On 6/15/12 4:05 PM, John C. Turnbull wrote: > This is very promising but has a few problems at present. > > I downloaded both the JavaFX Ensemble EXE and MSI installers along with the > JFXtras Ensemble MSI installer. They all install fine but the JavaFX > Ensemble application doesn't work on my Windows 7 64-bit machine. It runs > but selecting any of the demos does nothing. I am sure this is just a > teething problem as the JFXtras app works fine. Well, if application starts but misbehaves then this is probably sideeffect of using "private" copy of FX runtime. One used by JFXExtras is likely to be different from one used by my samples and one of them may have bugs. > The main deficiencies are as follows: > 1. There is no icon installed on the desktop. Putting an icon on the desktop is standard Windows application installer behaviour. Desktop shortcut as well as programs menu shortcut are options (at least one of them is required) and this specific sample was built with desktop shortcut disabled. I plan to blog about customization options next. > 2. There is no notification that the install has completed successfully. This default behavior is by design. One size does not fit all and we need to stick to something. Current thinking is that we can start with simple default UE and then add tweak in future releases if most of the users will need it tweaked. For exe we expect program to launch at the end of install. This will acknowledge it was installed ok. For MSI there are no dialogs but expectation is that most of the users of MSI will do some kind of automated install from scripts. And this is default behavior but not the only possible behavior. It is possible to customize it by customizing packaging scripts used to produce them. (this requires some understanding of these technologies but we hope people will be sharing customization steps for popular tweaks) > 3. The EXE installer looks ancient and bland. When compared to something > like the Flash installer and updater which are sleek and modern looking, the > JavaFX app installer looks very poor. True, it is not very fancy. Current goal was to get something simple, familiar to end users and robust. JavaFX bundlers for MSI and EXE rely on 3rd party tools and some customizations are possible by deeply tweaking config templates. Default configs may be improved and we may add additional "bundlers" in the future to support advanced but i only expect minor tweaks to default UE for JavaFX 2.2 at this point. We are way past feature freeze. > 4. When running the app, there is no icon set for when you use Alt-Tab to > flip between running applications. It still feels like a Java app instead of > a native Windows app. Bug, filed it as http://javafx-jira.kenai.com/browse/RT-22598 > 5. The app does not get installed into an appropriate location such as > Program Files. Again this feels like a non-native app and doesn't permit it > being run my more than one Windows user on the same machine. This is actually a feature :) Goal is to produce something that can be installed by user without admin permissions. Perhaps we should change it for MSI (needs more discussion). It is not new behavior. E.g. Chrome does this. > 6. The download size is way too big. Having to download nearly 50MB for a > basic app that just lets you select a few controls is a problem in this > mobile platform centric world. I realise Project Jigsaw will address this > but it is definitely a problem at the moment. Yes, bigger footprint is one of downsides of this approach. Exe file is about 25Mb (anything on top is application) and can be made a little smaller with more advanced compression techniques. Can not be much smaller than JRE though, i.e. we may reach 15Mb but not 5Mb without serious JRE subsetting (and this is subject to JRE license terms). -igor > > I look forward to continued improvements in this technology. > > -jct > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net > [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Igor Nekrestyanov > Sent: Friday, 15 June 2012 17:17 > To: openjfx-dev at openjdk.java.net > Subject: Deployment: native application bundles > > Hi, > > One thing we are adding to JavaFX packaging tools in 2.2 is ability to > produce native application bundles: > > https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_ja > vafx > > We are not seeing this as the only way to deploy JavaFX applications -- > webstart, embedded applications and doubleclickable jars are first class > citizens (and it would be great to explore other options). > But we hope it might be good option for many deployment scenarios. > > Please give it a try and provide feedback (and report bugs of course), > > -igor > From igor.nekrestyanov at oracle.com Fri Jun 15 23:07:06 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Fri, 15 Jun 2012 23:07:06 -0700 Subject: Deployment: native application bundles In-Reply-To: References: <4FDAE162.6070802@oracle.com> <4FDB8620.9030105@oracle.com> Message-ID: <4FDC228A.9090702@oracle.com> Hi, > > Regarding the MSI installer, using WiX does make it easier but I'm > wondering if there would be some merit in trying to write our own MSI > creator using the Windows Installer SDK. I haven't used it myself yet > but I believe it can be used to create MSI's. This would have the > advantage of not needing extra software installed, and also would > allow us to customise closely to what we need specifically for Java > installations (e.g. provide our own configuration options in whatever > syntax or format we want - e.g. an 'app-profile.xml'). The > disadvantage of course is the extra work, but this may be something I > could look at in my POC side of it. Something to think about anyway. Basic approach we are using is to adding support for "bundlers" to the toolchain. Bundler is something that can produce package out of set of app resources, JRE, etc. Bundler may or may not have additional requirements (like run only on specific platform or require WiX, etc.) When developer requests to "bundle" app we produce all bundles we can generate (by running all applicable bundlers). JavaFX 2.2 will provide some set of bundlers embedded into packaging tools. This approach allow to add new bundler or rewrite bundler later on if there will be better solution (e.g. WiX-less MSI bundler or cross platform deb bundler, etc). As for WiX-less bundler specifically i think it might be nice to have but i do not see it as critical issue right now. We are generating WiX config files based on templates and can expose any configuration parameters we need in whatever syntax we want. Once we understand what is limiting with this approach we can decide on how we can get something better. Using existing solution that works well for producing MSI allow us to focus on JavaFX specific problems and other bundlers. > Regarding natives, if you are using an executable JAR I don't think > this will work (i.e. executable JARs don't support native included in > them), unless the developer does the old extract and include on path > trick. Better that the natives just get bundled into the installation > directory and not into the jar, I reckon. It's a bit of a messy area > (especially for auto-updates) so probably worth making sure we're > covered in this area fairly early on. I think it do not understand the problem. In my model i assume that application image is something you can run using java.exe like cd app-image/ java -cp main.jar main.class (where app image is your dist of build folder). When you are running app from your IDE, debugger or command line it knows how to load native resources. I expect same copy of app-image to be kept under app/ folder in the installed image. Anyway, let me try to craft an example and we will see. > > Regarding the launching of the process, the way I do it also seems to > give it the process the name of the app the proper name (and not > 'java.exe'), which is a pleasant surprise. Do you use the same sort of > code as follows? My windows launcher is fairly simple now. Here is relevant part: >> // Dynamically load the JVM >> HMODULE jvmLibHandle = LoadLibrary(jvmPath); >> if (jvmLibHandle == NULL) { >> DWORD dwErr = GetLastError(); >> MessageBox(0, _T("Error loading jvm.dll"), jvmPath, >> MB_ICONERROR | MB_OK); >> return FALSE; >> } >> >> //convert argument to ASCII string as this is what CreateJVM needs >> wcstombs_s(&outlen, jarASCII, (size_t) wcslen(jar) + 1, jar, >> (size_t) wcslen(jar) + 1); >> strcpy_s(classpath, MAX_PATH*2, "-Djava.class.path="); >> strcat_s(classpath, MAX_PATH, jarASCII); >> >> // Set up the VM init args >> jvmArgs.version = JNI_VERSION_1_2; >> >> //TODO: add support for custom JVM parameters >> options[0].optionString = classpath; >> jvmArgs.version = 0x00010002; >> jvmArgs.options = options; >> jvmArgs.nOptions = 1; >> jvmArgs.ignoreUnrecognized = TRUE; >> >> // Create the JVM >> // NB: need to use ASCII string as UNICODE is not supported >> createProc = (JVM_CREATE) GetProcAddress(jvmLibHandle, >> "JNI_CreateJavaVM"); >> if (createProc == NULL) { >> MessageBox(0, _T("Failed to locate JNI_CreateJavaVM"), >> jvmPath, MB_ICONERROR | MB_OK); >> return FALSE; >> } >> >> if ((*createProc)(&jvm, &env, &jvmArgs) < 0) { >> // Should not happen >> // FIXME: report localized error >> return FALSE; >> } >> >> cls = env->FindClass("com/javafx/main/Main"); >> if (cls != NULL) { >> mid = env->GetStaticMethodID(cls, "main", >> "([Ljava/lang/String;)V"); >> if (mid != NULL) { >> jclass stringClass = env->FindClass("java/lang/String"); >> jobjectArray args = env->NewObjectArray(0, stringClass, >> NULL); >> env->CallStaticVoidMethod(cls, mid, args); >> } else { >> MessageBox(0, _T("no main method"), _T("Expected to find >> com.javafx.main.Main.main()"), MB_ICONERROR | MB_OK); >> } >> } else { >> MessageBox(0, _T("no main class"), _T("Expected to find >> com.javafx.main.Main"), MB_ICONERROR | MB_OK); >> } >> >> if (env->ExceptionOccurred()) { >> MessageBox(0, _T("Failed due to exception."), _T("Exception >> thrown from com.javafx.main.Main.main()"), MB_ICONERROR | MB_OK); >> env->ExceptionDescribe(); >> } > -igor > I'd be keen to keep what I do in line with what you are doing where > possible. > > > > > On Sat, Jun 16, 2012 at 4:59 AM, Igor Nekrestyanov > > > wrote: > > hi, thanks for all questions. > > Please keep them coming (bugs and suggestions are very welcome too!), > > >> The Ensemble MSI install worked for me on Windows 7 no problems. >> I haven't tried building my own app as yet though. >> >> It installed into 'C:\Users\zonski\AppData\Local\Ensemble2'. >> Installing into Program Files is probably more correct on >> windows. Is this 'appdata' the intended final location, or is >> this just for getting it all running for now? > Original goal was to be able to install without requiring admin > permissions. > Both MSI and EXE installers are currently build to do this. > > It is possible to customize install location and make it system > wide by tweaking WiX/Inno Setup template files. > Clearly we want to expose better APIs for customization but it is > not clear what are importnat config parameters and how to expose them > in more or less cross platform way, hence we decided that for 2u2 > we will provide an easy way to build basic package and do minimal > customization > as well as (very) advanced way for advanced users. > > Based on feedback we will figure out how to expand built-in > configuration APIs for future releases. > > I am planning to post more about package customization options and > other tricks&tips but i am amateur blogger and slow typer, so it > will take me few days :) > > Perhaps we should reconsider and produce EXE to be user level > installation and MSI to be system level by default. > I believe it is also possible to pass parameters to msiexec to > overwrite some of MSI settings (end this is not unusual in the > enterprise deployments). > However, i had not tried if it is possible to install this MSI > system wide (and i am not sure if my MSI expertise is deep enough > to craft MSI that can do both, > suggestions are very welcome). > >> >> Is the source code available for this at all? > Sorry, it is part of deploy/packager module that is not open > sourced yet. > >> If not, I'm very interested in how the 'exe' launcher code looks. >> Is this code you've written or part of one of the tools you've >> made use of? I'm particularly interested to see how it starts the >> app - does it just kick off another process on the executable jar >> via something like 'java -jar ensemble.jar' or does it try to run >> the Java app within it's own 'exe' process somehow (I'm assuming >> the later?). > yes, launcher will instantiate JVM in the launcher process. > Check out list of processes when sample app is running. There is > no java.exe but there is Ensemble.exe > >> >> I notice also that the jfx DLLs have been copied straight into >> the 'jre/bin' directory. > Starting 7u6 JRE/JDK will include JavaFX as part of Java > installation. > So, nothing special here. It is just runtime image. > >> Is this how you see all native dependencies playing out, i.e. if >> my application uses other native libraries how do I package them >> into the build and where will they be installed to in the >> extracted directory? > No, i do not think application resources will go into runtime. > Application resources will stay in the "app" folder (native libs too). > > The approach here is to "bundle" app without requiring to rewrite it. > During the development cycle your build output should have copy of > application you can execute and debug (but it depends on > environment, i.e. java+javafx runtime). > Bundle is essentially > copy of this application + java runtime + launcher > > Having said that i had not tried to craft example with native > libraries myself. Will certainly try to do. > >> One more question: when we say we have to build on the native >> platform to get the correct deployments, does that include 32bit >> vs 64bit? I'm guessing I could have a 32bit and 64bit JDK >> installation on the one machine and build a version of my app for >> each, but correct me if I'm wrong on this. > yes, two installations should do. > > Currently ant task will try to use RUNNING version of java as > source for cobundle. > If it is not appropriate (e.g. java 6 that is not javafx cobundle) > then it bundled app will not be created. > > In the future we may add option to specify which JDK to use as > import for bundle creation but for now we are taking shortcuts to > avoid exposing too much (kind of late in release). > >> I assume there's no way for a single JDK installation to produce >> both 32 and 64bit versions? > No, as currently JDK installations do not include both 32 and 64 > bit bits. After all we are copying them into bundle. > > -igor > >> Very, very nice start to this all! >> >> Cheers, >> Dan >> >> >> On Fri, Jun 15, 2012 at 5:16 PM, Igor Nekrestyanov >> > > wrote: >> >> Hi, >> >> One thing we are adding to JavaFX packaging tools in 2.2 is >> ability to produce native application bundles: >> https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx >> >> We are not seeing this as the only way to deploy JavaFX >> applications -- webstart, embedded applications >> and doubleclickable jars are first class citizens (and it >> would be great to explore other options). >> But we hope it might be good option for many deployment >> scenarios. >> >> Please give it a try and provide feedback (and report bugs of >> course), >> >> -igor >> >> > > From randahl at rockit.dk Sat Jun 16 01:15:08 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Sat, 16 Jun 2012 10:15:08 +0200 Subject: Why does this list not have a reply-to? Message-ID: <4FDC408C.1080002@rockit.dk> Sorry if this has been asked before, but why is this mailing list not configured with a reply-to header, so that e-mail programs can figure out that when we hit reply, the reply address should be openjfx and *not* the sender address? I keep accidentally writing replies directly to the sender, and I have noticed I am not the only one doing so. Randahl From tbee at tbee.org Sat Jun 16 01:19:41 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 16 Jun 2012 10:19:41 +0200 Subject: Why does this list not have a reply-to? In-Reply-To: <4FDC408C.1080002@rockit.dk> References: <4FDC408C.1080002@rockit.dk> Message-ID: <4FDC419D.6090706@tbee.org> Thunderbird does recognize that this is a list; I have the option to "reply" or "reply to list". Tom On 2012-06-16 10:15, Randahl Fink Isaksen wrote: > Sorry if this has been asked before, but why is this mailing list not configured with a reply-to header, so that e-mail programs can figure out that when we hit reply, the reply address should be openjfx and *not* the sender address? > > I keep accidentally writing replies directly to the sender, and I have noticed I am not the only one doing so. > > Randahl From randahl at rockit.dk Sat Jun 16 01:22:17 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Sat, 16 Jun 2012 10:22:17 +0200 Subject: Why does this list not have a reply-to? In-Reply-To: <4FDC419D.6090706@tbee.org> References: <4FDC408C.1080002@rockit.dk> <4FDC419D.6090706@tbee.org> Message-ID: <4FDC4239.1090607@rockit.dk> Yes - that is probably because of the List-... headers, but if a reply-to header was added to all outgoing mail from this list, the openjfx address would be the default reply to address when people hit reply. I think that would be helpful for all of us. Randahl On 16/06/12 10.19, Tom Eugelink wrote: > Thunderbird does recognize that this is a list; I have the option to > "reply" or "reply to list". > > Tom > > > > On 2012-06-16 10:15, Randahl Fink Isaksen wrote: >> Sorry if this has been asked before, but why is this mailing list not >> configured with a reply-to header, so that e-mail programs can figure >> out that when we hit reply, the reply address should be openjfx and >> *not* the sender address? >> >> I keep accidentally writing replies directly to the sender, and I >> have noticed I am not the only one doing so. >> >> Randahl > From tbee at tbee.org Sat Jun 16 01:26:37 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 16 Jun 2012 10:26:37 +0200 Subject: screen coordinate Message-ID: <4FDC433D.4030308@tbee.org> I'm trying to determine the screen coordinates of a node; apparently node.layoutX + node.scene.x + node.scene.window.x is not it. At least not all of the time. What am I missing? Tom From randahl at rockit.dk Sat Jun 16 01:29:12 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Sat, 16 Jun 2012 10:29:12 +0200 Subject: screen coordinate In-Reply-To: <4FDC433D.4030308@tbee.org> References: <4FDC433D.4030308@tbee.org> Message-ID: <4FDC43D8.4080400@rockit.dk> Since a node can have a parent which can have a parent, etc., I did this by adding the layoutX coordinates of the current node and all its parents (recursive method) and then adding the window position. R. On 16/06/12 10.26, Tom Eugelink wrote: > I'm trying to determine the screen coordinates of a node; apparently > node.layoutX + node.scene.x + node.scene.window.x is not it. At least > not all of the time. What am I missing? > > Tom From mp at jugs.org Sat Jun 16 02:16:24 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Sat, 16 Jun 2012 11:16:24 +0200 Subject: screen coordinate In-Reply-To: <4FDC433D.4030308@tbee.org> References: <4FDC433D.4030308@tbee.org> Message-ID: <4FDC4EE8.3080408@jugs.org> I haven't tried it myself but I think you will have to use the nodes localToScene transform to get its location in the scenes coordinate system first. Am 16.06.2012 10:26, schrieb Tom Eugelink: > I'm trying to determine the screen coordinates of a node; apparently > node.layoutX + node.scene.x + node.scene.window.x is not it. At least > not all of the time. What am I missing? > > Tom -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From zonski at googlemail.com Sat Jun 16 03:03:45 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Sat, 16 Jun 2012 20:03:45 +1000 Subject: Deployment: native application bundles In-Reply-To: <4FDC228A.9090702@oracle.com> References: <4FDAE162.6070802@oracle.com> <4FDB8620.9030105@oracle.com> <4FDC228A.9090702@oracle.com> Message-ID: I like the sound of the pluggable 'bundlers', and agree that having a WiX free implementation is very low priority if the customisation of WiX is fairly straight forward. Thanks for the code snippet - very interesting how you load the DLL and hook into it. You can ignore my comment about the executable jar, it's not applicable to the way you are doing things. I imagine native dependencies will work just fine in your approach. It all looks good! If we did want to make this work with the auto-update approach I've prototyped, the main challenge will be that your bundle assumes the local version is the only version (as you'd expect it to). It assumes everything in the app directory should be in the classpath, and the JRE is in the jre directory. My POC however uses an 'app-profile.xml' to explicitly define each JAR on the path and the version of the JRE to use. The reason this app-profile is needed in my POC is that when I download new versions I can't overwrite the current jars and JRE because they are locked by the process doing the download - so for some time at least both the new jars and old jars need to co-exist. My current solution is to append version numbers to everything, so when I download myapp-2.0.jar, the old myapp-1.0.jar is still there, same with jre6 and jre7. Then the app-profile.xml is used to decide which jars and jre are the correct ones to use and the old ones are ignored. Without an app-profile both the old 1.0 and the 2.0 jar would get loaded. The app-profile also doubles up as a record of the locally installed version and is used by the code to determine what needs updating. There would be plenty of other ways to do this (e.g. query the JVM for its version and look at the jar names) but the app-profile does make it pretty simple. All just stuff to look into as we explore the auto-updating functionality. Cheers, Dan On Sat, Jun 16, 2012 at 4:07 PM, Igor Nekrestyanov < igor.nekrestyanov at oracle.com> wrote: > Hi, > > > Regarding the MSI installer, using WiX does make it easier but I'm > wondering if there would be some merit in trying to write our own MSI > creator using the Windows Installer SDK. I haven't used it myself yet but I > believe it can be used to create MSI's. This would have the advantage of > not needing extra software installed, and also would allow us to customise > closely to what we need specifically for Java installations (e.g. provide > our own configuration options in whatever syntax or format we want - e.g. > an 'app-profile.xml'). The disadvantage of course is the extra work, but > this may be something I could look at in my POC side of it. Something to > think about anyway. > > Basic approach we are using is to adding support for "bundlers" to the > toolchain. Bundler is something that can produce package out of set of app > resources, JRE, etc. > Bundler may or may not have additional requirements (like run only on > specific platform or require WiX, etc.) > > When developer requests to "bundle" app we produce all bundles we can > generate (by running all applicable bundlers). > > JavaFX 2.2 will provide some set of bundlers embedded into packaging tools. > > This approach allow to add new bundler or rewrite bundler later on if > there will be better solution (e.g. WiX-less MSI bundler or cross platform > deb bundler, etc). > > As for WiX-less bundler specifically i think it might be nice to have but > i do not see it as critical issue right now. > We are generating WiX config files based on templates and can expose any > configuration parameters we need in whatever syntax we want. > Once we understand what is limiting with this approach we can decide on > how we can get something better. > Using existing solution that works well for producing MSI allow us to > focus on JavaFX specific problems and other bundlers. > > Regarding natives, if you are using an executable JAR I don't think this > will work (i.e. executable JARs don't support native included in them), > unless the developer does the old extract and include on path trick. Better > that the natives just get bundled into the installation directory and not > into the jar, I reckon. It's a bit of a messy area (especially for > auto-updates) so probably worth making sure we're covered in this area > fairly early on. > > I think it do not understand the problem. > In my model i assume that application image is something you can run using > java.exe like > cd app-image/ > java -cp main.jar main.class > (where app image is your dist of build folder). > > When you are running app from your IDE, debugger or command line it knows > how to load native resources. > I expect same copy of app-image to be kept under app/ folder in the > installed image. > > Anyway, let me try to craft an example and we will see. > > > > Regarding the launching of the process, the way I do it also seems to > give it the process the name of the app the proper name (and not > 'java.exe'), which is a pleasant surprise. Do you use the same sort of code > as follows? > > My windows launcher is fairly simple now. Here is relevant part: > > > // Dynamically load the JVM > HMODULE jvmLibHandle = LoadLibrary(jvmPath); > if (jvmLibHandle == NULL) { > DWORD dwErr = GetLastError(); > MessageBox(0, _T("Error loading jvm.dll"), jvmPath, MB_ICONERROR | > MB_OK); > return FALSE; > } > > //convert argument to ASCII string as this is what CreateJVM needs > wcstombs_s(&outlen, jarASCII, (size_t) wcslen(jar) + 1, jar, (size_t) > wcslen(jar) + 1); > strcpy_s(classpath, MAX_PATH*2, "-Djava.class.path="); > strcat_s(classpath, MAX_PATH, jarASCII); > > // Set up the VM init args > jvmArgs.version = JNI_VERSION_1_2; > > //TODO: add support for custom JVM parameters > options[0].optionString = classpath; > jvmArgs.version = 0x00010002; > jvmArgs.options = options; > jvmArgs.nOptions = 1; > jvmArgs.ignoreUnrecognized = TRUE; > > // Create the JVM > // NB: need to use ASCII string as UNICODE is not supported > createProc = (JVM_CREATE) GetProcAddress(jvmLibHandle, > "JNI_CreateJavaVM"); > if (createProc == NULL) { > MessageBox(0, _T("Failed to locate JNI_CreateJavaVM"), jvmPath, > MB_ICONERROR | MB_OK); > return FALSE; > } > > if ((*createProc)(&jvm, &env, &jvmArgs) < 0) { > // Should not happen > // FIXME: report localized error > return FALSE; > } > > cls = env->FindClass("com/javafx/main/Main"); > if (cls != NULL) { > mid = env->GetStaticMethodID(cls, "main", > "([Ljava/lang/String;)V"); > if (mid != NULL) { > jclass stringClass = env->FindClass("java/lang/String"); > jobjectArray args = env->NewObjectArray(0, stringClass, NULL); > env->CallStaticVoidMethod(cls, mid, args); > } else { > MessageBox(0, _T("no main method"), _T("Expected to find > com.javafx.main.Main.main()"), MB_ICONERROR | MB_OK); > } > } else { > MessageBox(0, _T("no main class"), _T("Expected to find > com.javafx.main.Main"), MB_ICONERROR | MB_OK); > } > > if (env->ExceptionOccurred()) { > MessageBox(0, _T("Failed due to exception."), _T("Exception thrown > from com.javafx.main.Main.main()"), MB_ICONERROR | MB_OK); > env->ExceptionDescribe(); > } > > > -igor > > I'd be keen to keep what I do in line with what you are doing where > possible. > > > > > On Sat, Jun 16, 2012 at 4:59 AM, Igor Nekrestyanov < > igor.nekrestyanov at oracle.com> wrote: > >> hi, thanks for all questions. >> >> Please keep them coming (bugs and suggestions are very welcome too!), >> >> >> The Ensemble MSI install worked for me on Windows 7 no problems. I >> haven't tried building my own app as yet though. >> >> It installed into 'C:\Users\zonski\AppData\Local\Ensemble2'. Installing >> into Program Files is probably more correct on windows. Is this 'appdata' >> the intended final location, or is this just for getting it all running for >> now? >> >> Original goal was to be able to install without requiring admin >> permissions. >> Both MSI and EXE installers are currently build to do this. >> >> It is possible to customize install location and make it system wide by >> tweaking WiX/Inno Setup template files. >> Clearly we want to expose better APIs for customization but it is not >> clear what are importnat config parameters and how to expose them >> in more or less cross platform way, hence we decided that for 2u2 we will >> provide an easy way to build basic package and do minimal customization >> as well as (very) advanced way for advanced users. >> >> Based on feedback we will figure out how to expand built-in configuration >> APIs for future releases. >> >> I am planning to post more about package customization options and other >> tricks&tips but i am amateur blogger and slow typer, so it will take me few >> days :) >> >> Perhaps we should reconsider and produce EXE to be user level >> installation and MSI to be system level by default. >> I believe it is also possible to pass parameters to msiexec to overwrite >> some of MSI settings (end this is not unusual in the enterprise >> deployments). >> However, i had not tried if it is possible to install this MSI system >> wide (and i am not sure if my MSI expertise is deep enough to craft MSI >> that can do both, >> suggestions are very welcome). >> >> >> Is the source code available for this at all? >> >> Sorry, it is part of deploy/packager module that is not open sourced >> yet. >> >> If not, I'm very interested in how the 'exe' launcher code looks. Is >> this code you've written or part of one of the tools you've made use of? >> I'm particularly interested to see how it starts the app - does it just >> kick off another process on the executable jar via something like 'java >> -jar ensemble.jar' or does it try to run the Java app within it's own 'exe' >> process somehow (I'm assuming the later?). >> >> yes, launcher will instantiate JVM in the launcher process. >> Check out list of processes when sample app is running. There is no >> java.exe but there is Ensemble.exe >> >> >> I notice also that the jfx DLLs have been copied straight into the >> 'jre/bin' directory. >> >> Starting 7u6 JRE/JDK will include JavaFX as part of Java installation. >> So, nothing special here. It is just runtime image. >> >> Is this how you see all native dependencies playing out, i.e. if my >> application uses other native libraries how do I package them into the >> build and where will they be installed to in the extracted directory? >> >> No, i do not think application resources will go into runtime. >> Application resources will stay in the "app" folder (native libs too). >> >> The approach here is to "bundle" app without requiring to rewrite it. >> During the development cycle your build output should have copy of >> application you can execute and debug (but it depends on environment, i.e. >> java+javafx runtime). >> Bundle is essentially >> copy of this application + java runtime + launcher >> >> Having said that i had not tried to craft example with native libraries >> myself. Will certainly try to do. >> >> One more question: when we say we have to build on the native platform to >> get the correct deployments, does that include 32bit vs 64bit? I'm guessing >> I could have a 32bit and 64bit JDK installation on the one machine and >> build a version of my app for each, but correct me if I'm wrong on this. >> >> yes, two installations should do. >> >> Currently ant task will try to use RUNNING version of java as source for >> cobundle. >> If it is not appropriate (e.g. java 6 that is not javafx cobundle) then >> it bundled app will not be created. >> >> In the future we may add option to specify which JDK to use as import for >> bundle creation but for now we are taking shortcuts to avoid exposing too >> much (kind of late in release). >> >> I assume there's no way for a single JDK installation to produce both 32 >> and 64bit versions? >> >> No, as currently JDK installations do not include both 32 and 64 bit >> bits. After all we are copying them into bundle. >> >> -igor >> >> Very, very nice start to this all! >> >> Cheers, >> Dan >> >> >> On Fri, Jun 15, 2012 at 5:16 PM, Igor Nekrestyanov < >> igor.nekrestyanov at oracle.com> wrote: >> >>> Hi, >>> >>> One thing we are adding to JavaFX packaging tools in 2.2 is ability to >>> produce native application bundles: >>> >>> https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx >>> >>> We are not seeing this as the only way to deploy JavaFX applications -- >>> webstart, embedded applications >>> and doubleclickable jars are first class citizens (and it would be great >>> to explore other options). >>> But we hope it might be good option for many deployment scenarios. >>> >>> Please give it a try and provide feedback (and report bugs of course), >>> >>> -igor >>> >> >> >> > > From tbee at tbee.org Sat Jun 16 03:17:07 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 16 Jun 2012 12:17:07 +0200 Subject: screen coordinate In-Reply-To: <4FDC43D8.4080400@rockit.dk> References: <4FDC433D.4030308@tbee.org> <4FDC43D8.4080400@rockit.dk> Message-ID: <4FDC5D23.6050503@tbee.org> I turns out I needed to do both; iterate layoutX + scene.x + scene.window.x Put this in a utility method in JFXtras. Tom On 2012-06-16 10:29, Randahl Fink Isaksen wrote: > Since a node can have a parent which can have a parent, etc., I did this by adding the layoutX coordinates of the current node and all its parents (recursive method) and then adding the window position. > > R. > > On 16/06/12 10.26, Tom Eugelink wrote: >> I'm trying to determine the screen coordinates of a node; apparently node.layoutX + node.scene.x + node.scene.window.x is not it. At least not all of the time. What am I missing? >> >> Tom From zonski at googlemail.com Sat Jun 16 03:45:50 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Sat, 16 Jun 2012 20:45:50 +1000 Subject: Auto-update of native application bundles In-Reply-To: References: <4FDBA1F8.8080103@oracle.com> <4FDC427F.9090308@jugs.org> <4FDC5923.8010608@jugs.org> Message-ID: Comments inline On Sat, Jun 16, 2012 at 8:00 PM, Dr. Michael Paus wrote: > Hi, > > this time it worked. Downloading, installing, updating and uninstalling. > Great! > There are however a few points I would complain about but as you > said that this is just a proof of concept I am not sure whether it is > worth the time to detail these issues. > I agree the workflow and user experience is very rough at the moment - the focus has been on proving the technical challenges can be overcome and getting just enough working to see whether it's worth us investing more into it and moving further along this path, or changing direction altogether. If there is general approval of the high-level direction then it is definitely worth putting the effort into making this all nice and slick. It's probably not worth picking out individual flaws in the flow though - it's all bad. If however, you were interested in defining what the perfect user flow would look like in terms of screens, messages, and even look and feel that would be awesome. In need of a UX designer! Even better if you wanted to just code it straight in. I'm looking at getting JFX onto the path as the next highest priority and then the intent is to completely rebuild the workflow screen in prettier, more user friendly JFX screens. Actually, perhaps it would be a good idea to make use of the wiki on the google code project and move some of the more static stuff from this conversation onto there and collaboratively define the workflow. I'd be happy to add you as a member if you're keen (have you signed the Oracle Contributors agreement yet?). A few examples: > > Why is the installer so big (> 30MB)? The windows JRE is only 20MB > and contains a lot of things which are not needed if it is bundled with > an application. (For example all the applet and webstart stuff) > The size is purely due to the size of the JRE I've bundled in there and for me the JRE is large. The size of my installed 1.6 JRE is 90MB - the "rt.jar" alone is 43MB. The 33MB is a result of Advanced Installer compressing the 90MB down to 33MB, so if we had a much smaller JRE size (e.g. 20MB) it should be significantly smaller again. Is your JRE really 20MB? If so that would be awesome, but I'm not sure how I managed to end up with such a massive one. I admit I have had about 50 different versions of JRE's + JDKs on this machine over the last 12 months (every client I have has different version requirements and half of them have legacy projects and require multiple JREs at the one site!). > The yellow app shows the same version number as the green one. > Why do I have to update then? > I think this is just my nasty hacked up UI leading you astray. When an update is available the content area shows the available update, when you have the latest update the content area shows the current version you have. So in both the yellow and the green you will see the details of version 2.0 in the content area (but in the yellow your current installed version is actually 1.0). Kind of stupid now that I think about it :) This should all get thrown away and redone as we move to JFX pretty screens. > When I already have the latest version the update button should > not be active anymore. > Yea, oversight on my behalf. I think I turned it on to test something and forgot to turn it back off. > There was a curious dialog when I update which asked whether > I wanted to update the JRE to U32. I was a bit afraid to say yes to > that because I was not sure what would happen. (I don't have JRE6 > installed on my machine anymore) Finally I did it and nothing obviously > bad happened. > The dialog is not actually asking whether you want to update the JRE to U32 but rather is asking whether you give "JRE U32" permission to make changes to your local system. JRE U32 is the JRE that is co-bundled into the MSI and it is trying to copy in JRE7. This dialog is required but the fact that it shows "JRE" as the app name is confusing. There should be a way to make it show "Do you want to allow Zen Test Application to make changes to your system" instead of saying "Java u32" as it does now. Basically the updater wants to copy the new, downloaded files into the installation directory but since this is in Program Files we need to get User Account Control (UAC) permission. To do this I have to launch another process with requested elevated windows privileges and this spawned process does the copy. To make my life easy I spawn a Java process to do this so that's why you see the dialog warning you that Java is asking for enhanced permissions. In order to change this we need to find a way to name the spawned process - there will surely be a way, just have to work it out. Something more for the todo list! Rest assured however it's not doing anything to any of your installed JREs - it's only messing with the files within the test app installation. > > and so on ... > > All good feedback, keep it coming! From kevin.rushforth at oracle.com Sat Jun 16 06:41:13 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 16 Jun 2012 06:41:13 -0700 Subject: screen coordinate In-Reply-To: <4FDC4EE8.3080408@jugs.org> References: <4FDC433D.4030308@tbee.org> <4FDC4EE8.3080408@jugs.org> Message-ID: <4FDC8CF9.7030605@oracle.com> Exactly. Just looking at the layout{X,Y} will miss any transforms on the node or its ancestors. -- Kevin Dr. Michael Paus wrote: > I haven't tried it myself but I think you will have to use the nodes > localToScene transform > to get its location in the scenes coordinate system first. > > Am 16.06.2012 10:26, schrieb Tom Eugelink: >> I'm trying to determine the screen coordinates of a node; apparently >> node.layoutX + node.scene.x + node.scene.window.x is not it. At least >> not all of the time. What am I missing? >> >> Tom > > From hang.vo at oracle.com Sat Jun 16 06:48:57 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 16 Jun 2012 13:48:57 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-21251 : [ListView] some space appeared between scrollbar and listview content. Message-ID: <20120616134900.6A9FC4797E@hg.openjdk.java.net> Changeset: acd0852a0a8e Author: mickf Date: 2012-06-16 14:42 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/acd0852a0a8e RT-21251 : [ListView] some space appeared between scrollbar and listview content. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java From david.grieve at oracle.com Sat Jun 16 06:51:52 2012 From: david.grieve at oracle.com (David Grieve) Date: Sat, 16 Jun 2012 09:51:52 -0400 Subject: JavaFX Form Validation In-Reply-To: References: <4FD5332A.5080608@oracle.com> <4fd76555.09d6e00a.463f.7a12@mx.google.com> <4FD77DDC.4080806@media-interactive.de> <4FD78018.4090900@tbee.org> <4fd7889b.47d0e00a.2e05.ffff9515@mx.google.com> <4FD864BB.7080105@rockit.dk> <4fd87d44.0cb2e00a.5e0a.1cc4@mx.google.com> <196AC79A-C699-4183-95A2-C189EE0BEF81@gmail.com> <4FD8B88F.7070406@media-interactive.de> <193FF4ED343AF14F8CDC65B4792C954D131E8134@Jeri.osys.ch> <91192062-8690-43E6-9A9B-02FB8DA782F6@muenster.de> <400BA4FE-3B71-4798-9480-7F62D2D1A38D@gmail.com> Message-ID: <0130DAFA-D94C-4C1F-9ACB-6E9F35D0DFBE@oracle.com> Perhaps attribute selectors would be an alternative, assuming we can add support for it. On Jun 15, 2012, at 5:53 PM, Richard Bair wrote: > Presently we have the following impl_ methods for dealing with pseudo classes: > > protected void impl_pseudoClassStateChanged(String pseudoClass) > public long impl_getPseudoClassState() > private static final long HOVER_PSEUDOCLASS_STATE = StyleManager.getInstance().getPseudoclassMask("hover"); // and so forth > > So what happens is if a class has a custom pseudo class state, it has to fetch a mask for it such as in the HOVER_PSEUDOCLASS_STATE example. Whenever it detects that the pseudo class state has changed (for example, "hover" boolean changes) it invokes the impl_pseudoClassStateChanged method, which asks CSS whether this particular node has a style that depends on that pseudo class, so that it only requests CSS to be reapplied if there is a style change involved (avoids us having to recompute CSS when "hover" changes if no style for the node cares about "hover"). > > The CSS engine then, when applying CSS, asks the node for impl_getPseudoClassState which returns a long which is the mask of all pseudo class states that this node is in. This allows for a very fast match as to whether a style applies to this node or not. > > So the short answer is we cannot have dynamic pseudo classes without sacrificing performance. Either we use a BitSet instead of a long, or we have to go to using set.contains() (which would kill us). > > The longer answer is that we sort of need to support custom pseudo-classes at some point, but maybe I'm not sure how to do so without hurting performance. > > For those interested, all the CSS code is part of javafx-ui-common in the open source code and the code above is found in Node. Between Node, Parent, Region, and Control you should be able to know as much of how this works as anybody (StyleManager and StyleHelper are the other two guys really worth looking at. It isn't easy to read because of the amount of performance tuning / fast paths / caches that have gone into this). > > Now our goal was for Lombard to have public API so that UI control authors could add custom pseudo-classes. SO that basically means the impl_ methods will for sure be changed between now and then, but you can see how the mechanism works and supply patches if you like :-) > > Richard > > On Jun 14, 2012, at 12:45 AM, Daniel Zwolenski wrote: > >> Would it be possible to attach our own arbitrary pseudo classes to controls via code? >> >> Eg. Button.setPseudoClass("highlighted") >> >> That would then cover the error case and much more. Eg I might have 'error', 'warning', 'required', 'highlighted', etc. >> >> I do not know if the CSS engine will be able to handle this. >> >> >> >> On 14/06/2012, at 5:19 PM, Gerrit Grunwald wrote: >> >>> +1 >>> Am 14.06.2012 um 08:37 schrieb Claus Luethje: >>> >>>> +1 >>>> >>>> -----Original Message----- >>>> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Werner Lehmann >>>> Sent: Mittwoch, 13. Juni 2012 17:58 >>>> To: >>>> Subject: Re: JavaFX Form Validation >>>> >>>> +1 >>>> >>>> I think it could be useful to have a css pseudoclass for controls with invalid state. >>>> >>>> Rgds >>>> Werner >>>> >>>> On 13.06.2012 15:23, Daniel Zwolenski wrote: >>>>> My vote is for JFX to provide low level building blocks for developers >>>>> to hook in to and then for open source tool kits (like >>>>> Jfxtras) to provide the higher level tools. So JFX would have no >>>>> validation framework but instead would provide ways to, for example, >>>>> visually highlight nodes, and a community built toolkit would use this >>>>> to provide a validation framework. >>> > David Grieve | Principal Member of Technical Staff Mobile: +16033121013 Oracle Java Client UI and Tools Durham, NH 03824 Oracle is committed to developing practices and products that help protect the environment From richard.bair at oracle.com Sat Jun 16 07:08:05 2012 From: richard.bair at oracle.com (Richard Bair) Date: Sat, 16 Jun 2012 07:08:05 -0700 Subject: Why does this list not have a reply-to? In-Reply-To: <4FDC419D.6090706@tbee.org> References: <4FDC408C.1080002@rockit.dk> <4FDC419D.6090706@tbee.org> Message-ID: No idea, cc'ing Mark Reinhold. On Jun 16, 2012, at 1:19 AM, Tom Eugelink wrote: > Thunderbird does recognize that this is a list; I have the option to "reply" or "reply to list". > > Tom > > > > On 2012-06-16 10:15, Randahl Fink Isaksen wrote: >> Sorry if this has been asked before, but why is this mailing list not configured with a reply-to header, so that e-mail programs can figure out that when we hit reply, the reply address should be openjfx and *not* the sender address? >> >> I keep accidentally writing replies directly to the sender, and I have noticed I am not the only one doing so. >> >> Randahl > From tbee at tbee.org Sat Jun 16 07:56:09 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 16 Jun 2012 16:56:09 +0200 Subject: screen coordinate In-Reply-To: <4FDC8CF9.7030605@oracle.com> References: <4FDC433D.4030308@tbee.org> <4FDC4EE8.3080408@jugs.org> <4FDC8CF9.7030605@oracle.com> Message-ID: <4FDC9E89.7030302@tbee.org> That indeed seems to have been the problem; I suspect JFXtras Ensemble does a transform somewhere, moving the node to the center, and that was exactly what was missing. The iteration over layoutX got the same result though. Tom On 2012-06-16 15:41, Kevin Rushforth wrote: > Exactly. Just looking at the layout{X,Y} will miss any transforms on the node or its ancestors. > > -- Kevin > > > Dr. Michael Paus wrote: >> I haven't tried it myself but I think you will have to use the nodes localToScene transform >> to get its location in the scenes coordinate system first. >> >> Am 16.06.2012 10:26, schrieb Tom Eugelink: >>> I'm trying to determine the screen coordinates of a node; apparently node.layoutX + node.scene.x + node.scene.window.x is not it. At least not all of the time. What am I missing? >>> >>> Tom >> >> From tbee at tbee.org Sat Jun 16 08:35:53 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 16 Jun 2012 17:35:53 +0200 Subject: mouse vs key Message-ID: <4FDCA7D9.8000108@tbee.org> Jonathan, Is there any reason why, when toggling a togglebutton, the mouse-released event is triggered AFTER the selected value of the togglebutton has changed, while the key-released is triggered BEFORE the selected value has changed? The reason I ask is this; I need to know if the shift key was pressed when toggling a day button in the CalendarPicker in order to select a range. I used work based on the selectedProperty, but it does not give me access to the actual event (and the shiftDown flag) that caused it. So now I'm binding to the on-mouse-release and on-key-release, but the on key release executes too early. Tom From tbee at tbee.org Sat Jun 16 09:09:56 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 16 Jun 2012 18:09:56 +0200 Subject: mouse vs key In-Reply-To: <4FDCA7D9.8000108@tbee.org> References: <4FDCA7D9.8000108@tbee.org> Message-ID: <4FDCAFD4.7010809@tbee.org> And I need to use the mouse and key events, because only registering the shift key state in the on-mouse or on-key but keep using the selectedProperty does not work, because the togglebutton doesn't toggle the state when shift is pressed. Tom On 2012-06-16 17:35, Tom Eugelink wrote: > Jonathan, > > Is there any reason why, when toggling a togglebutton, the mouse-released event is triggered AFTER the selected value of the togglebutton has changed, while the key-released is triggered BEFORE the selected value has changed? > > The reason I ask is this; I need to know if the shift key was pressed when toggling a day button in the CalendarPicker in order to select a range. I used work based on the selectedProperty, but it does not give me access to the actual event (and the shiftDown flag) that caused it. So now I'm binding to the on-mouse-release and on-key-release, but the on key release executes too early. > > Tom > From zonski at googlemail.com Sat Jun 16 15:40:04 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Sun, 17 Jun 2012 08:40:04 +1000 Subject: Auto-update of native application bundles In-Reply-To: <4FDC738D.1090006@jugs.org> References: <4FDBA1F8.8080103@oracle.com> <4FDC427F.9090308@jugs.org> <4FDC5923.8010608@jugs.org> <4FDC738D.1090006@jugs.org> Message-ID: On Sat, Jun 16, 2012 at 9:52 PM, Dr. Michael Paus wrote: > Am 16.06.2012 12:43, schrieb Daniel Zwolenski: > >> >> Is your JRE really 20MB? If so that would be awesome, but I'm not sure >> how I managed to end up with such a massive one. I admit I have had about >> 50 different versions of JRE's + JDKs on this machine over the last 12 >> months (every client I have has different version requirements and half of >> them have legacy projects and require multiple JREs at the one site!). >> > I just downloaded the latest JRE7 offline installer from this web page: > http://www.oracle.com/**technetwork/java/javase/** > downloads/jre7-downloads-**1637588.html > The windows offline installers are almost exactly 20MB and if I understood > it correctly the also already contain JavaFX. > And as I already said, the size of this should be further reducible if one > would kick out everything that is not needed for an embedded JRE > but the Oracle guys should know that much better than I do. > > LG, Michael > Ah, ok. The JRE install is 20MB compressed but when you install it, it extracts to 90MB. So the reason my MSI is 30MB is due to the fact that the tools I am using are not compressing the files as effectively as whatever is used to build the JRE installer. I currently use the third party tool Advanced Installer to assemble my MSI. It does have an option to use LZMA compression, which might result in a smaller installer but I have to upgrade to the paid version for that. Since the ultimate goal will be to use Igor's MSI assembler, it's probably more important what compression algorithm is used by his tools. I notice that the Ensemble MSI produced from the new packaging tools is around 50MB as well, so I'm guessing Igor is doing a similar method of compression. I'm guessing that this is all done by WiX however, rather than code he has written directly. There is a 'CompressionLevel' attribute in WiX from the look of it - but I'm not sure what level Igor uses by default? On the topic of stripping stuff out to make the install smaller, this is definitely an option and something to look at long term. I did have a little look at this but since the compression was already dropping the size from 90MB to 30MB, I would have to strip out some significant chunks to make much impact on the resulting MSI (even more if we manage to compress it down to 20MB). Since the Java rt.jar is already 50MB, stripping out the other bits and pieces I could find was having very meagre gains. Killing "classes.jsa" might shave a few MB though, assuming this doesn't break anything. It's something to look into but is probably more important on Igor's end. I suspect the best answer we'll be able to manage on this topic will be: just put up with the larger download sizes for jre7 and await the magical wonder of jre8 (let's hope it delivers on its promise in this area!). From zonski at googlemail.com Sat Jun 16 16:41:34 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Sun, 17 Jun 2012 09:41:34 +1000 Subject: Auto-update of native application bundles In-Reply-To: References: <4FDBA1F8.8080103@oracle.com> <4FDC427F.9090308@jugs.org> <4FDC5923.8010608@jugs.org> <4FDC738D.1090006@jugs.org> Message-ID: A question for the JFX guys on JRE+JFX co-bundling: Now that JFX is co-bundled in the JRE does that mean to upgrade to a newer version of JFX we will need to upgrade our JDK/JRE each time, or do you intend to have patch updates? I guess ultimately my question is will the developer be able to mix and match JRE and JFX versions or will it be a case of JREu6 is locked in to have JFXb2.2, and if you want JFX2.3 then you have to upgrade to JREu7 (for example, I'm just making up version numbers). On Sun, Jun 17, 2012 at 8:40 AM, Daniel Zwolenski wrote: > On Sat, Jun 16, 2012 at 9:52 PM, Dr. Michael Paus wrote: > >> Am 16.06.2012 12:43, schrieb Daniel Zwolenski: >> >>> >>> Is your JRE really 20MB? If so that would be awesome, but I'm not sure >>> how I managed to end up with such a massive one. I admit I have had about >>> 50 different versions of JRE's + JDKs on this machine over the last 12 >>> months (every client I have has different version requirements and half of >>> them have legacy projects and require multiple JREs at the one site!). >>> >> I just downloaded the latest JRE7 offline installer from this web page: >> http://www.oracle.com/**technetwork/java/javase/** >> downloads/jre7-downloads-**1637588.html >> The windows offline installers are almost exactly 20MB and if I >> understood it correctly the also already contain JavaFX. >> And as I already said, the size of this should be further reducible if >> one would kick out everything that is not needed for an embedded JRE >> but the Oracle guys should know that much better than I do. >> >> LG, Michael >> > > Ah, ok. The JRE install is 20MB compressed but when you install it, it > extracts to 90MB. So the reason my MSI is 30MB is due to the fact that the > tools I am using are not compressing the files as effectively as whatever > is used to build the JRE installer. I currently use the third party tool Advanced > Installer to assemble my MSI. It does > have an option to use LZMA compression, which might result in a smaller > installer but I have to upgrade to the paid version for that. > > Since the ultimate goal will be to use Igor's MSI assembler, it's probably > more important what compression algorithm is used by his tools. I notice > that the Ensemble MSI produced from the new packaging tools is around 50MB > as well, so I'm guessing Igor is doing a similar method of compression. I'm > guessing that this is all done by WiX however, rather than code he has > written directly. There is a 'CompressionLevel' attribute in WiX from the > look of it - but I'm not sure what level Igor uses by default? > > On the topic of stripping stuff out to make the install smaller, this is > definitely an option and something to look at long term. I did have a > little look at this but since the compression was already dropping the size > from 90MB to 30MB, I would have to strip out some significant chunks to > make much impact on the resulting MSI (even more if we manage to compress > it down to 20MB). Since the Java rt.jar is already 50MB, stripping out the > other bits and pieces I could find was having very meagre gains. Killing > "classes.jsa" might shave a few MB though, assuming this doesn't break > anything. It's something to look into but is probably more important on > Igor's end. > > I suspect the best answer we'll be able to manage on this topic will be: > just put up with the larger download sizes for jre7 and await the magical > wonder of jre8 (let's hope it delivers on its promise in this area!). > > > > > From richard.bair at oracle.com Sat Jun 16 18:47:30 2012 From: richard.bair at oracle.com (Richard Bair) Date: Sat, 16 Jun 2012 18:47:30 -0700 Subject: Auto-update of native application bundles In-Reply-To: References: <4FDBA1F8.8080103@oracle.com> <4FDC427F.9090308@jugs.org> <4FDC5923.8010608@jugs.org> <4FDC738D.1090006@jugs.org> Message-ID: <5ECD712F-3541-43BE-A4B7-51895CF84CAA@oracle.com> They'll be locked together. On Jun 16, 2012, at 4:41 PM, Daniel Zwolenski wrote: > A question for the JFX guys on JRE+JFX co-bundling: > > Now that JFX is co-bundled in the JRE does that mean to upgrade to a newer > version of JFX we will need to upgrade our JDK/JRE each time, or do you > intend to have patch updates? > > I guess ultimately my question is will the developer be able to mix and > match JRE and JFX versions or will it be a case of JREu6 is locked in to > have JFXb2.2, and if you want JFX2.3 then you have to upgrade to JREu7 (for > example, I'm just making up version numbers). > > > On Sun, Jun 17, 2012 at 8:40 AM, Daniel Zwolenski wrote: > >> On Sat, Jun 16, 2012 at 9:52 PM, Dr. Michael Paus wrote: >> >>> Am 16.06.2012 12:43, schrieb Daniel Zwolenski: >>> >>>> >>>> Is your JRE really 20MB? If so that would be awesome, but I'm not sure >>>> how I managed to end up with such a massive one. I admit I have had about >>>> 50 different versions of JRE's + JDKs on this machine over the last 12 >>>> months (every client I have has different version requirements and half of >>>> them have legacy projects and require multiple JREs at the one site!). >>>> >>> I just downloaded the latest JRE7 offline installer from this web page: >>> http://www.oracle.com/**technetwork/java/javase/** >>> downloads/jre7-downloads-**1637588.html >>> The windows offline installers are almost exactly 20MB and if I >>> understood it correctly the also already contain JavaFX. >>> And as I already said, the size of this should be further reducible if >>> one would kick out everything that is not needed for an embedded JRE >>> but the Oracle guys should know that much better than I do. >>> >>> LG, Michael >>> >> >> Ah, ok. The JRE install is 20MB compressed but when you install it, it >> extracts to 90MB. So the reason my MSI is 30MB is due to the fact that the >> tools I am using are not compressing the files as effectively as whatever >> is used to build the JRE installer. I currently use the third party tool Advanced >> Installer to assemble my MSI. It does >> have an option to use LZMA compression, which might result in a smaller >> installer but I have to upgrade to the paid version for that. >> >> Since the ultimate goal will be to use Igor's MSI assembler, it's probably >> more important what compression algorithm is used by his tools. I notice >> that the Ensemble MSI produced from the new packaging tools is around 50MB >> as well, so I'm guessing Igor is doing a similar method of compression. I'm >> guessing that this is all done by WiX however, rather than code he has >> written directly. There is a 'CompressionLevel' attribute in WiX from the >> look of it - but I'm not sure what level Igor uses by default? >> >> On the topic of stripping stuff out to make the install smaller, this is >> definitely an option and something to look at long term. I did have a >> little look at this but since the compression was already dropping the size >> from 90MB to 30MB, I would have to strip out some significant chunks to >> make much impact on the resulting MSI (even more if we manage to compress >> it down to 20MB). Since the Java rt.jar is already 50MB, stripping out the >> other bits and pieces I could find was having very meagre gains. Killing >> "classes.jsa" might shave a few MB though, assuming this doesn't break >> anything. It's something to look into but is probably more important on >> Igor's end. >> >> I suspect the best answer we'll be able to manage on this topic will be: >> just put up with the larger download sizes for jre7 and await the magical >> wonder of jre8 (let's hope it delivers on its promise in this area!). >> >> >> >> >> From igor.nekrestyanov at oracle.com Sun Jun 17 00:26:30 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Sun, 17 Jun 2012 00:26:30 -0700 Subject: Auto-update of native application bundles In-Reply-To: References: <4FDBA1F8.8080103@oracle.com> Message-ID: <4FDD86A6.1060708@oracle.com> Hi Dan, thanks for the great writeup (and pushing this ahead). I finally started to look into this more actively. Some questions/suggestions below. On 6/15/12 5:02 PM, Daniel Zwolenski wrote: > *The General Approach* > > Richard made reference to Sparkle and > like him, I feel this is a nice reference point for the style of solution > we want. The neat thing that Sparkle does is it provides an API that > developers can use inside their code to completely control and customise > the upgrade of their application. This is the approach I've gone for as > well. My POC includes a Java API that you can call to check for updates and > trigger downloads. IMHO, main great thing about Sparkle is that it is easy to add basic AU functionality to the application (see https://github.com/andymatuschak/Sparkle/wiki) You do not need to use API unless you want custom solution. Therefore i am not focusing here on the public API part (keeping this for later). > I think this approach is neat and powerful, but it's worth mentioning that > there is still some debate amongst the JFX team about whether to go down > this road or avoid the Java API and use off-the-shelf native updaters. Your > input will very likely influence this decision so if you have a preference > one way or the other (or have other suggestions), be vocal. I think there is no debate on that having some "all in java with minimal native code solution" is good idea. Debate is about whether it should be the only option or it also make sense to support other native update mechanisms (e.g. use Sparkle directly on Mac). As Dan said, thoughts on this are very welcome. > > > An XML deployment descriptor, called 'app-profile.xml' is used to describe > the JARs, JRE versions and other launch details - it is semantically > comparable to a traditional JNLP file. When an update is triggered via the > API, the code checks the remote URL for an updated app-profile.xml. If it > finds one it downloads this and checks this with its local app-profile.xml. > Any jars that have different version numbers are downloaded, and if a new > JRE version is defined in the app-profile then the zip for this is > downloaded and extracted as well. Where these files are placed after download? > Once all the downloading is complete, the > local app-profile is then overwritten with the newer one and this newer one > will be used by the native launcher to set the classpath next time the app > is started. > > IMHO, we can simplify this model following Sparkle ideas. Sparkle does not know anything about application structure, etc. and focus only on update process. This makes it easy to use, simple and robust as it focuses on solves one problem. Important points are: A. Sparkle uses "appcast" to describe what updates are available (https://github.com/andymatuschak/Sparkle/wiki/publishing-an-update) Appcast includes - version of updates available - meta info about each update (type of update (e.g. regular or mandatory security), release notes, system requirements (e.g. Windows version 7+), etc.) - set of available update packages (aka enclosures) (e.g. full app image, delta patches for several versions, etc.) B. Sparkle knows where to look for update meta info in the application package (on Mac it is part of Info.plist that is some kind of application manifest). However, it only needs to know: - URL of appcast - location of key to verify update signatures - application update settings/preferences The expectation is that once app is updated this info will be updated (as it is part of "update package") [Note: this is not so simple on Windows if we want to make sure we are good citizens and need to update registry] C. Update package is black box for Sparkle core. It is modeled as - file hosted at given URL - signed with given key (signature is part of appcast) - package type defines what "update driver" will be handling this update (this allows to add support for various update packages as plugins/modules) - for most type for packages (except running installers) Sparkle goal is to update set of application files only [Windows or linux require more work as we may need to update registry or package info] D. If admin permissions are needed they only asked before update is finally installed. Sparkle does not keep any internal state in the app folder as it may be only writable for admins. E. Application relaunch after update This is close to your approach but there are some important differences. Following Sparkle more closely may simplify things and at the same time add some desired features (e.g. ability to validate origin of autoupdate) My current thoughts on "ideal" basic experience are as follows. ======== Developer experience (no java coding needed): 1. At the package time developer requests autoupdate support in the native cobundle by providing: * http URL to appcast + public key/cert to validate update signatures * or https url and define application update mode (mandatory update, ask user and allow him to skip version, etc.) 2. Once update is needed developer creates "update package" (single file). For this he will need to run same packager utility/ant task but specify base image, certificate to sign package and and desired type of update (full or incremental) 3. Developer need to create an appcast xml file (default can be generated in step 2 but he may want to customize it) 4. Developer stages both appcast and package bundle ========= End user (background updates): * installs application with background update policy * every time application is launched it will check appcast (if online) * if update is detected it will be loaded silently while app is running * Once update is loaded and verified user will be prompted to install it (it may be notification if update is mandatory) * If he agrees then he may see UAC dialog (unless installation is on per user basis) * application relaunch after update * attempt to launch app being updated should fail with reasonable dialog and should not fail update process (it may need to wait will .exe is unlocked) ========= Implementation wise i was thinking along the lines of what you have (only glimpsed though your code it though) with following notable differences: * update package is single file and we only worry about it version. No need to worry about version of individual components as we do not want arbitrary mix&match. * updates are loaded to ~/.javafx/app-key (where app-key could be derivation from app install location) We also keep user answers for this app in that folder (e.g. had we offered him this version already? when was last time we checked for update, etc) * Update process is: - build temp full app image in the ~/.javafx/app-key/version - if update accepted then exit application and run helper app co copy image over - possibly run "post upgrade script" as part of helper app (this script is specific to "bundler" technology used. E.g. for EXE/MSI bundlers we may want to update few keys in registry - relaunch app - AU module running in the relaunched app could detect temp "image" that is the same as current version and erase it Note that there could be several alternative helper apps. E.g. one that pops UAC and one that does not for per user installs. Or helper up to install update packaged as MSI (by running msiexec silently and showing progress) I was even thinking that "helper" can be implemented in java with minimal native code (to elevate permissions and update registry if needed). * Integration with application bundle - details on whether AU is needed and what type is it may be embedded application manifest for main app jar - embedded jauncher will read them and use internal AU APIs accordingly (this is why no user code changes are needed) - current app version, update url and signature are part of package.cfg or manifest in the main app jar - AU support itself is part of jfxrt.jar, bundle also includes helper app to "move image into final location" and script to do "post update config" What do you think? -igor From kirill.prazdnikov at oracle.com Sun Jun 17 03:09:52 2012 From: kirill.prazdnikov at oracle.com (Kirill.Prazdnikov) Date: Sun, 17 Jun 2012 14:09:52 +0400 Subject: Why does this list not have a reply-to? In-Reply-To: <4FDC419D.6090706@tbee.org> References: <4FDC408C.1080002@rockit.dk> <4FDC419D.6090706@tbee.org> Message-ID: <4FDDACF0.1040201@oracle.com> Hi Tom, I have the "reply all" in my Thunderbird, it is very old though 3.1.20. -Kirill On 16.06.2012 12:19, Tom Eugelink wrote: > Thunderbird does recognize that this is a list; I have the option to > "reply" or "reply to list". > > Tom > > > > On 2012-06-16 10:15, Randahl Fink Isaksen wrote: >> Sorry if this has been asked before, but why is this mailing list not >> configured with a reply-to header, so that e-mail programs can figure >> out that when we hit reply, the reply address should be openjfx and >> *not* the sender address? >> >> I keep accidentally writing replies directly to the sender, and I >> have noticed I am not the only one doing so. >> >> Randahl > From zonski at googlemail.com Sun Jun 17 06:43:12 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Sun, 17 Jun 2012 23:43:12 +1000 Subject: Auto-update of native application bundles In-Reply-To: <4FDD86A6.1060708@oracle.com> References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> Message-ID: Hey Igor, Generally liking the discussion. It's a big topic with lots of twists and turns so for now I'm just going to pull out one of your key points to delve into further, as I think a lot of other things will be dependent on this. Currently we have two proposed styles of app updates: - In your proposal the "app-cast" system is used, where each update is released as a patch (i.e. the 'diff') to get from one version to the next. If an app was out in the wild running at version 2, and the latest release was actually version 5, then to upgrade we would download the v2->v3 patch, install it, then the v3->v4 patch install it, and then the v4->v5 patch and install that (correct me if I got this wrong). - In my POC I've gone for the "app-profile" approach, which basically defines the latest release of the system in it's entirety. It's up to each app out there to determine what has changed between it's version and the latest version and download what it needs (i.e. the 'diff'). To go from version 2 to version 5, the app would compare the version of the JARs in its own app-profile against the new one, and download the ones that have changed. There is no download of the 'in-between' versions of 3 and 4. I think both options have merit, each with its own advantages and disadvantages. I looked at the app-cast approach first and decided the app-profile worked better for the Java scenario than the app-cast one (primarily because we have JARs and these work well with app-profile), but I'm definitely good to look at this again. One thing it would be good to work out up front however is: what does the typical (80% case) upgrade look like? It would be great to get community input on this guys? For me, I will typically have one or two JARs that contain my code, then I will have another 20 or so jars making up all my third-party libraries. The one or two JARs containing my code will be the things that change most between releases of my product. I might occasionally add, remove, or upgrade a third-party dependency but this would be much less frequent. For example, my app might have monthly releases with my latest code, but it would be only once every year or two that I change the Hibernate or Spring versions I'm using. It was with this type of usage in mind that I ended up leaning towards the app-profile approach. I imagined my initial upload to my server would be all the JARs for my app, and then when I release subsequent versions I only upload the couple of JARs that have changed and upload the new app-profile.xml (and the build tools could potentially do the upload as well and they would know which jars had changed). So looking at the benefits of each approach in turn: The big benefit of the app-cast approach that I can see is the single file encapsulating the update. If lots of dependencies have changed then downloading one file will be quicker than downloading lots of individual JARs. Additionally, for the developer, uploading a single file with just the changes in it is quicker and easier than uploading the full updated application. The complexity around signing the update file looks a little easier too, but I think tools would mask the complexity in this area in either case so the developer won't be overly affected (?). Similarly, there is less complexity in checking new version numbers, but I think this complexity is all in our code so its not really a big win for end users/developers. Developers would still be maintaining versions in their local environment in order to produce the 'patch' file (I assume - or how do you see the contents of the patch file being determined?). Did I miss any major advantages of the app-cast approach, or am I off on any of my assessments here? With the app-profile approach I think the main benefit is that the latest, working code is available in full from the server. There is no need to store patch files for older versions. These would be fairly hard to regenerate if you ever lost them I imagine as you may not even have the source code to reproduce them (this would be my biggest concern with the app-cast approach)? In the app-profile approach the only thing you store on your server is the latest MSI and the latest extracted copy of your app - all of which can be easily pulled by doing a build out of your latest source code tree. You don't have to keep around old patches just in case someone out there is still using an old version. Another benefit is that the updating app would just jump straight to the latest version, and there would be no need of the "in-between" downloads and installs. In my typical deployment scenario it is the same few JARs that are being updated in each release, so the in-between downloads are redundant as they immediately get overwritten (e.g. myapp.jar is overwritten in v3, v4 and again in v5 so why not just jump straight to the v5 file). The flip side of this is that you couldn't choose to go to an in-between version if you wanted to, but I'm not sure that's an overly valid use case? With this approach we also have the option of providing a "repair" function. So a client could run a utility to just completely download the entire app and get fresh copies of all the JARs. This is not critical but it could be quite useful. With the app-cast approach, you have to uninstall and then reinstall with your original MSI and then patch (or install with the new MSI) - the uninstall may delete your 'appdata' though, whereas a "repair" could leave this intact. One other niggling thing for me is how to do things like system properties or VM settings (like -Xmx) without an app-profile. Currently you would be hard coding those into your 'exe' I imagine? So if an update wanted to change these things it would have to recompile the launcher exe and that would have to be part of the 'patch'? There'd be no easy (possible?) way for the user to change these settings on their machine, not sure if that's a good thing or a bad thing though? And finally one other edge use case I thought of today: it's not uncommon to have several 'apps' included in the one install. For example you might have a user UI and an admin UI. In Java-land, these would ideally share the same libraries but have different 'main' classes. I was thinking the app-profile approach could potentially be extended to cover this but it needs more thinking about, and may just be an unsupported use case. Not sure how/if the app-cast approach could handle this if we said it was a requirement. Cheers, Dan On Sun, Jun 17, 2012 at 5:26 PM, Igor Nekrestyanov < igor.nekrestyanov at oracle.com> wrote: > Hi Dan, > > thanks for the great writeup (and pushing this ahead). > I finally started to look into this more actively. Some > questions/suggestions below. > > On 6/15/12 5:02 PM, Daniel Zwolenski wrote: > >> *The General Approach* >> >> Richard made reference to Sparkle> >> and >> >> like him, I feel this is a nice reference point for the style of solution >> we want. The neat thing that Sparkle does is it provides an API that >> developers can use inside their code to completely control and customise >> the upgrade of their application. This is the approach I've gone for as >> well. My POC includes a Java API that you can call to check for updates >> and >> trigger downloads. >> > IMHO, main great thing about Sparkle is that it is easy to add basic AU > functionality to the application > (see https://github.com/**andymatuschak/Sparkle/wiki > ) > You do not need to use API unless you want custom solution. > > Therefore i am not focusing here on the public API part (keeping this for > later). > > > I think this approach is neat and powerful, but it's worth mentioning that >> there is still some debate amongst the JFX team about whether to go down >> this road or avoid the Java API and use off-the-shelf native updaters. >> Your >> input will very likely influence this decision so if you have a preference >> one way or the other (or have other suggestions), be vocal. >> > > I think there is no debate on that having some "all in java with minimal > native code solution" is good idea. > Debate is about whether it should be the only option or it also make sense > to support other native update mechanisms > (e.g. use Sparkle directly on Mac). > > As Dan said, thoughts on this are very welcome. > > >> >> An XML deployment descriptor, called 'app-profile.xml' is used to describe >> the JARs, JRE versions and other launch details - it is semantically >> comparable to a traditional JNLP file. When an update is triggered via the >> API, the code checks the remote URL for an updated app-profile.xml. If it >> finds one it downloads this and checks this with its local >> app-profile.xml. >> Any jars that have different version numbers are downloaded, and if a new >> JRE version is defined in the app-profile then the zip for this is >> downloaded and extracted as well. >> > Where these files are placed after download? > > Once all the downloading is complete, the >> local app-profile is then overwritten with the newer one and this newer >> one >> will be used by the native launcher to set the classpath next time the app >> is started. >> >> >> IMHO, we can simplify this model following Sparkle ideas. > Sparkle does not know anything about application structure, etc. and focus > only on update process. > This makes it easy to use, simple and robust as it focuses on solves one > problem. > > Important points are: > A. Sparkle uses "appcast" to describe what updates are available > (https://github.com/**andymatuschak/Sparkle/wiki/** > publishing-an-update > ) > Appcast includes > - version of updates available > - meta info about each update (type of update (e.g. regular or > mandatory security), release notes, system requirements (e.g. Windows > version 7+), etc.) > - set of available update packages (aka enclosures) (e.g. full > app image, delta patches for several versions, etc.) > > B. Sparkle knows where to look for update meta info in the application > package (on Mac it is part of Info.plist that is some kind of application > manifest). > However, it only needs to know: > - URL of appcast > - location of key to verify update signatures > - application update settings/preferences > The expectation is that once app is updated this info will be > updated (as it is part of "update package") > [Note: this is not so simple on Windows if we want to make sure we > are good citizens and need to update registry] > > C. Update package is black box for Sparkle core. > It is modeled as > - file hosted at given URL > - signed with given key (signature is part of appcast) > - package type defines what "update driver" will be handling this > update > (this allows to add support for various update packages as > plugins/modules) > - for most type for packages (except running installers) Sparkle > goal is to update set of application files only > [Windows or linux require more work as we may need to update > registry or package info] > > D. If admin permissions are needed they only asked before update is > finally installed. > Sparkle does not keep any internal state in the app folder as it may > be only writable for admins. > > E. Application relaunch after update > > This is close to your approach but there are some important differences. > Following Sparkle more closely may simplify things and at the same time > add some desired features > (e.g. ability to validate origin of autoupdate) > > My current thoughts on "ideal" basic experience are as follows. > > ======== > Developer experience (no java coding needed): > > 1. At the package time developer requests autoupdate support in the > native cobundle by providing: > * http URL to appcast + public key/cert to validate update > signatures > * or https url > and define application update mode (mandatory update, ask user and > allow him to skip version, etc.) > > 2. Once update is needed developer creates "update package" (single file). > For this he will need to run same packager utility/ant task but specify > base image, certificate to sign package and > and desired type of update (full or incremental) > > 3. Developer need to create an appcast xml file (default can be generated > in step 2 but he may want to customize it) > > 4. Developer stages both appcast and package bundle > ========= > > End user (background updates): > * installs application with background update policy > * every time application is launched it will check appcast (if online) > * if update is detected it will be loaded silently while app is running > * Once update is loaded and verified user will be prompted to install it > (it may be notification if update is mandatory) > * If he agrees then he may see UAC dialog (unless installation is on per > user basis) > * application relaunch after update > * attempt to launch app being updated should fail with reasonable dialog > and should not fail update process (it may need to wait will .exe is > unlocked) > ========= > > Implementation wise i was thinking along the lines of what you have (only > glimpsed though your code it though) with following > notable differences: > > * update package is single file and we only worry about it version. > No need to worry about version of individual components as we do not > want arbitrary mix&match. > > * updates are loaded to ~/.javafx/app-key (where app-key could be > derivation from app install location) > We also keep user answers for this app in that folder (e.g. had we > offered him this version already? when was last time we checked for update, > etc) > > * Update process is: > - build temp full app image in the ~/.javafx/app-key/version > - if update accepted then exit application and run helper app co > copy image over > - possibly run "post upgrade script" as part of helper app > (this script is specific to "bundler" technology used. E.g. for > EXE/MSI bundlers we may want to update few keys in registry > - relaunch app > - AU module running in the relaunched app could detect temp "image" > that is the same as current version and erase it > > Note that there could be several alternative helper apps. E.g. one > that pops UAC and one that does not for per user installs. > Or helper up to install update packaged as MSI (by running msiexec > silently and showing progress) > > I was even thinking that "helper" can be implemented in java with > minimal native code (to elevate permissions and update registry if needed). > > * Integration with application bundle > - details on whether AU is needed and what type is it may be > embedded application manifest for main app jar > - embedded jauncher will read them and use internal AU APIs > accordingly > (this is why no user code changes are needed) > - current app version, update url and signature are part of > package.cfg or manifest in the main app jar > - AU support itself is part of jfxrt.jar, bundle also includes > helper app to "move image into final location" and > script to do "post update config" > > What do you think? > > -igor > > From zonski at googlemail.com Sun Jun 17 06:56:18 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Sun, 17 Jun 2012 23:56:18 +1000 Subject: Auto-update of native application bundles In-Reply-To: <4FDD86A6.1060708@oracle.com> References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> Message-ID: Just a brief answer to this question (I know, I talk too much): > An XML deployment descriptor, called 'app-profile.xml' is used to describe >> the JARs, JRE versions and other launch details - it is semantically >> comparable to a traditional JNLP file. When an update is triggered via the >> API, the code checks the remote URL for an updated app-profile.xml. If it >> finds one it downloads this and checks this with its local >> app-profile.xml. >> Any jars that have different version numbers are downloaded, and if a new >> JRE version is defined in the app-profile then the zip for this is >> downloaded and extracted as well. >> > Where these files are placed after download? All files are downloaded to 'temp' (i.e. File.createTempFile()), this includes the JRE zip, which is also extracted in temp. At the end they are moved into "Program Files/my app" (using the UAC elevated admin process). Since all files are version tagged, no old files are lost (i.e. myapp-1.0.jar and myapp-2.0.jar are both in the 'app' directory), it's only when the app-profile is updated that the new jars get used. Since the app-profile is the last thing to be updated, if anything goes wrong the old app-profile will still be in place so the old app will still start. Finally, if everything succeeds the new app-profile is copied in over the old one so the next launch will use that. In a better solution, the obsolete old files (e.g. myapp-1.0.jar) would also be deleted now that we have managed to start successfully. All temp files are deleted on either success or failure. From tbee at tbee.org Sun Jun 17 07:42:21 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 17 Jun 2012 16:42:21 +0200 Subject: Why does this list not have a reply-to? In-Reply-To: <4FDDACF0.1040201@oracle.com> References: <4FDC408C.1080002@rockit.dk> <4FDC419D.6090706@tbee.org> <4FDDACF0.1040201@oracle.com> Message-ID: <4FDDECCD.9040109@tbee.org> Yes. Your email is treated differently by my Thunderbird as well. I'm running 13.0.1 Tom On 2012-06-17 12:09, Kirill.Prazdnikov wrote: > Hi Tom, > > I have the "reply all" in my Thunderbird, it is very old though 3.1.20. > > -Kirill > > On 16.06.2012 12:19, Tom Eugelink wrote: >> Thunderbird does recognize that this is a list; I have the option to "reply" or "reply to list". >> >> Tom >> >> >> >> On 2012-06-16 10:15, Randahl Fink Isaksen wrote: >>> Sorry if this has been asked before, but why is this mailing list not configured with a reply-to header, so that e-mail programs can figure out that when we hit reply, the reply address should be openjfx and *not* the sender address? >>> >>> I keep accidentally writing replies directly to the sender, and I have noticed I am not the only one doing so. >>> >>> Randahl >> > > From zonski at googlemail.com Sun Jun 17 21:32:17 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Mon, 18 Jun 2012 14:32:17 +1000 Subject: Auto-update of native application bundles In-Reply-To: <4FDE646D.3070102@oracle.com> References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> <4FDE5AB4.2040102@oracle.com> <4FDE646D.3070102@oracle.com> Message-ID: I think I understand but please clarify any of the below if I got it wrong. Would it be correct to say that the main difference is that in your proposal you are working out the 'delta' update at compile/packaging time, whereas in my solution the app works out the 'delta' at runtime when an upgrade is requested. Assuming this is right, then: Because you are working deltas out at compile time you can bundle the updates into a single image file and avoid having an app-profile. In my solution I need everything extracted on the server with an app-profile so the app can work out the diff in jar versions at runtime. Your solution is definitely nicer on this front. On the other hand, because I work deltas out on the fly I don't need 'delta' image files and any old version can always update to the latest without downloading the full bundle even though no 'delta' file exist. In your solution we have multiple deltas to maintain and the more versions you have the more deltas you have to maintain (or not use deltas, resulting in larger downloads). If a delta is not available for a specific older version, then the app will have to download the full update and install this. Advantages and disadvantages both ways, it would be good to get input from the community and other JFX'ers on this. Just as a point of reference and for extra clarity, I'll step through the process for a theoretical app. *Using your proposed approach (as I understand it, please clear up anything I got wrong):* Say we have an app called "MyApp" and we've just finished writing version 1, which contains myapp-1.0.jar and log4j-1.2.jar. Using your tools we then build "myapp.msi", "myapp.dmg" and "myapp.rpm" and upload these to our site. So for the release of version 1 we upload the following files: - myapp.msi (50MB) - myapp.rpm (50MB) - myapp.dmg (50MB) A month later we are ready to release version 2. The only jar that has changed is myapp.jar but we've also added the spring-3.0.jar as a dependency, adding 5MB compressed. We use your tools to build the new msi, dmg and rpm and we upload these over the top of the old ones so anyone who downloads our app will get the new version. We also create a 'full' update file and upload this to our server. Since this must contain the JRE, I assume it is one per platform? Additionally we want to create a 'delta' update for this release, so we point your delta building tools at ??? (did we have to create and store an old image file from version 1?) and it works out the binary diff and produces a 'delta' file (can this be one for all platforms or does it need to be one each?). So for the release of version 2 we upload the following files: - myapp.msi (55MB) - myapp.rpm (55MB) - myapp.dmg (55MB) - full-image-win.zip (55MB) - full-image-linux.zip (55MB) - full-image-osx.zip (55MB) - myapp-delta-v1-to-v2.zip (8MB) A few months later we are ready to release version 3. This time we only change the myapp.jar, nothing else. We use your tools again to build the new msi, dmg and rpm and we upload these over the top of the old ones so anyone who downloads our app will get the new version. Again, we also create 'full' update files (one per platform) and upload these to our server. Additionally we want to create a 'delta' update for this release. We need to create two delta files - one for moving from version 1 to version 3 and one for moving from version 2 to version 3. So we point your delta building tools firstly at the version 1 image, and then secondly at the version 2 image (which we've had to keep in our source control for this purpose, or we have to roll back to the old code to build these older images). So for the release of version 3 we upload the following files: - myapp.msi (55MB) - myapp.rpm (55MB) - myapp.dmg (55MB) - full-image-win.zip (55MB) - full-image-linux.zip (55MB) - full-image-osx.zip (55MB) - myapp-delta-v1-to-v3.zip (8MB) - myapp-delta-v2-to-v3.zip (4MB) If the delta is platform specific, either because it contains native files or a new JRE then we would need one delta per platform, and we would end up with x 3 zips of the deltas (or more if you have different versions for 32bit vs 64 bit, etc). For version 4 and beyond, the permutations of deltas continue to increases (i.e. v1-to-v4, v2-to-v4, v3-to-v4) assuming deltas are used. Alternatively, the developer stops maintaining deltas but then upgrades fall back to full downloads (i.e. 55MB instead of say 4MB) to move up versions. *Using my POC approach* * * We have our same app "MyApp" and we've just finished writing version 1, which contains myapp-1.0.jar and log4j-1.2.jar. We then build "myapp.msi", "myapp.dmg" and "myapp.rpm" and upload these to our site. For the release of version 1 we upload the following files: - myapp.msi (50MB) - myapp.rpm (50MB) - myapp.dmg (50MB) A month later we are ready to release version 2. The only jar that has changed is myapp.jar but we've also added the spring-3.0.jar as a dependency. As usual, we build the new msi, dmg and rpm and we upload these over the top of the old ones so anyone who downloads our app will get the new version. Additionally we now upload the new app-profile.xml (which can be generated) and the extracted bundle of our app. For the release of version 2 we upload the following files: - myapp.msi (55MB) - myapp.rpm (55MB) - myapp.dmg (55MB) - unextracted application bundle (15MB) - zip of the JRE for windows/linux/OSX (30MB each) // in a better world JRE zip is downloaded directly from Oracle and would not need to be uploaded by me! A few months later we are ready to release version 3. This time we only change the myapp.jar, nothing else. We build the new msi, dmg and rpm and we upload these over the top of the old ones so anyone who downloads our app will get the new version. Since the only JAR that has changed since the last release is myapp.jar, this (and the new app-profile.xml) is the only thing we need to upload to the server. So for the release of version 3 we upload the following files: - myapp.msi (55MB) - myapp.rpm (55MB) - myapp.dmg (55MB) - app-profile.xml (tiny) - myapp-2.0.jar (4MB) For version 4 and beyond the upload sizes are similar, the permutations do not grow as more version are released, etc. Just as an aside, in both my POC and your approach it would be possible to create an "on line" installer that meant the MSI, RPM, DMG, etc's were all tiny (a couple of MB) and they would then fetch the 'full' installation and install it. This would make uploading a lot simpler as you wouldn't have to upload the 150MB associated with the new msi, rpm, dmg everytime. I think this is a version 2 feature but I also think it's good that the options we are looking at leave the door open for this. From igor.nekrestyanov at oracle.com Sun Jun 17 21:54:27 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Sun, 17 Jun 2012 21:54:27 -0700 Subject: Auto-update of native application bundles In-Reply-To: References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> <4FDE5AB4.2040102@oracle.com> <4FDE646D.3070102@oracle.com> Message-ID: <4FDEB483.5020603@oracle.com> On 6/17/12 9:32 PM, Daniel Zwolenski wrote: > I think I understand but please clarify any of the below if I got it > wrong. > > Would it be correct to say that the main difference is that in your > proposal you are working out the 'delta' update at compile/packaging > time, whereas in my solution the app works out the 'delta' at runtime > when an upgrade is requested. Assuming this is right, then: > > Because you are working deltas out at compile time you can bundle the > updates into a single image file and avoid having an app-profile. In > my solution I need everything extracted on the server with an > app-profile so the app can work out the diff in jar versions at > runtime. Your solution is definitely nicer on this front. > > On the other hand, because I work deltas out on the fly I don't need > 'delta' image files and any old version can always update to the > latest without downloading the full bundle even though no 'delta' file > exist. In your solution we have multiple deltas to maintain and the > more versions you have the more deltas you have to maintain (or not > use deltas, resulting in larger downloads). If a delta is not > available for a specific older version, then the app will have to > download the full update and install this. Yes, process wise this is correct (there are other differences caused by above, e.g. single file, no way you may get components signed by different certs, etc.). Example is correct too, some size overhead is expected but if we can get bundle size down with better compression methods/etc then difference will be not that big. My expectation is that appropriate compression techniques can get size can be down to 25Mb for Ensemble. And once subsetting of JRE will be easier (technically and legaly) it could probably get down to 15Mb or so. Few clarifications on the example: 1. In step 2 and 3 if all of older versions of app use same JRE then we can use "reduced" version of ful update that updates everything but runtime folder This can cut download size if it is an issue 2. Full image for update may be the same as an app. E.g. we are currently installing same .dmg for JRE on Mac and you certainly can do silent installation with .msi 3. The way to get full app image to compare against is not fixed. For example, you can save .zip of 1.0 version when you built 1.0, or install and zip image before you are ready to ship new version, or even manually provide list of files to include into update. 4. Based on feedback i saw from Sparkle users and Oracle's use of AU for JRE keeping lots of delta's is not required. Interestingly delta's are often used not to improve user's time to update but to reduce server load. Another point to consider is that use of single "update package" seem to be the way many other native update systems are implemented (based on what i saw, clearly i am not familiar with all of them). -igor From lehmann at media-interactive.de Mon Jun 18 02:39:32 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 18 Jun 2012 11:39:32 +0200 Subject: Why does this list not have a reply-to? In-Reply-To: <4FDC408C.1080002@rockit.dk> References: <4FDC408C.1080002@rockit.dk> Message-ID: <4FDEF754.3040706@media-interactive.de> I would like this, too. Usually I don't send to incorrect recipients, but it would be nice not having to edit the recipients for each reply. And for some reason Thunderbird does not automatically reply to the list for me. Werner On 16.06.2012 10:15, Randahl Fink Isaksen wrote: > Sorry if this has been asked before, but why is this mailing list not > configured with a reply-to header, so that e-mail programs can figure > out that when we hit reply, the reply address should be openjfx and > *not* the sender address? > > I keep accidentally writing replies directly to the sender, and I have > noticed I am not the only one doing so. > > Randahl From alexandre.iline at oracle.com Mon Jun 18 02:52:53 2012 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Mon, 18 Jun 2012 13:52:53 +0400 Subject: screen coordinate In-Reply-To: <4FDC433D.4030308@tbee.org> References: <4FDC433D.4030308@tbee.org> Message-ID: <4FDEFA75.8030407@oracle.com> http://hg.openjdk.java.net/openjfx/2.1/master/tests/file/tip/tools/Jemmy/JemmyFX/src/org/jemmy/fx/SceneWrap.java : getScreenBounds + http://hg.openjdk.java.net/openjfx/2.1/master/tests/file/tip/tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrap.java : getScreenBounds On 06/16/2012 12:26 PM, Tom Eugelink wrote: > I'm trying to determine the screen coordinates of a node; apparently > node.layoutX + node.scene.x + node.scene.window.x is not it. At least > not all of the time. What am I missing? > > Tom From pavel.safrata at oracle.com Mon Jun 18 04:04:41 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 18 Jun 2012 13:04:41 +0200 Subject: screen coordinate In-Reply-To: <4FDEFA75.8030407@oracle.com> References: <4FDC433D.4030308@tbee.org> <4FDEFA75.8030407@oracle.com> Message-ID: <4FDF0B49.6000800@oracle.com> By the way, there is an old request for localToScreen and screenToLocal methods (hope that we'll finally find time to do that for 3.0): http://javafx-jira.kenai.com/browse/RT-3290 Regards, Pavel On 18.6.2012 11:52, Alexandre (Shura) Iline wrote: > http://hg.openjdk.java.net/openjfx/2.1/master/tests/file/tip/tools/Jemmy/JemmyFX/src/org/jemmy/fx/SceneWrap.java > : getScreenBounds > + > http://hg.openjdk.java.net/openjfx/2.1/master/tests/file/tip/tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrap.java > : getScreenBounds > > On 06/16/2012 12:26 PM, Tom Eugelink wrote: >> I'm trying to determine the screen coordinates of a node; apparently >> node.layoutX + node.scene.x + node.scene.window.x is not it. At least >> not all of the time. What am I missing? >> >> Tom From hang.vo at oracle.com Mon Jun 18 04:20:12 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Jun 2012 11:20:12 +0000 Subject: hg: openjfx/2.2/graphics/rt: 2 new changesets Message-ID: <20120618112017.DFC81479B1@hg.openjdk.java.net> Changeset: 9dc8b64682f6 Author: Pavel Safrata Date: 2012-06-14 15:39 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/9dc8b64682f6 RT-21746: scenegraph subtrees can be added during layout. ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/javafx/scene/ParentTest.java Changeset: 3525ca3b1439 Author: Pavel Safrata Date: 2012-06-18 10:30 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/3525ca3b1439 RT-21746: scenegraph subtrees can be added during layout (merge). ! javafx-ui-common/src/javafx/scene/Node.java From zonski at googlemail.com Mon Jun 18 04:37:20 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Mon, 18 Jun 2012 21:37:20 +1000 Subject: Auto-update of native application bundles In-Reply-To: <4FDEB483.5020603@oracle.com> References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> <4FDE5AB4.2040102@oracle.com> <4FDE646D.3070102@oracle.com> <4FDEB483.5020603@oracle.com> Message-ID: <59A93607-DA37-42D8-8F45-F72FCDF1BF36@gmail.com> Sounds good, and thanks for taking the time to clarify it all. I can see advantages to both approaches and could happily run with either. I think my POC is simpler for 'deltas' whereas yours is simpler for 'full' deploys. If bundles can be made small enough to make deltas generally not worth the hassle then I think your proposal is stronger. It would be good if we can get some input on this from the community and if Richard has any thoughts. One niggling thing for me: how will your solution update itself while it is running? In my POC the new and old versions coexist for a time to get around the file locking issue but in yours there can be only one version. Do you intend for the actual 'installation' to happen outside of the app using a native UI to show progress and success/error message or do you have some other trick in mind to update the jre while it is running? Also the 'full' updates could always exclude the JRE if Oracle released JRE zip files that the updater could download from (based on a version specified in the update bundle). I don't suppose there's any chance of legals letting this happen? On 18/06/2012, at 2:54 PM, Igor Nekrestyanov wrote: > On 6/17/12 9:32 PM, Daniel Zwolenski wrote: >> I think I understand but please clarify any of the below if I got it wrong. >> >> Would it be correct to say that the main difference is that in your proposal you are working out the 'delta' update at compile/packaging time, whereas in my solution the app works out the 'delta' at runtime when an upgrade is requested. Assuming this is right, then: >> >> Because you are working deltas out at compile time you can bundle the updates into a single image file and avoid having an app-profile. In my solution I need everything extracted on the server with an app-profile so the app can work out the diff in jar versions at runtime. Your solution is definitely nicer on this front. >> >> On the other hand, because I work deltas out on the fly I don't need 'delta' image files and any old version can always update to the latest without downloading the full bundle even though no 'delta' file exist. In your solution we have multiple deltas to maintain and the more versions you have the more deltas you have to maintain (or not use deltas, resulting in larger downloads). If a delta is not available for a specific older version, then the app will have to download the full update and install this. > Yes, process wise this is correct (there are other differences caused by above, e.g. single file, no way you may get components signed by different certs, etc.). > > Example is correct too, some size overhead is expected but if we can get bundle size down with better compression methods/etc then difference will be not that big. > My expectation is that appropriate compression techniques can get size can be down to 25Mb for Ensemble. And once subsetting of JRE will be easier > (technically and legaly) it could probably get down to 15Mb or so. > > Few clarifications on the example: > > 1. In step 2 and 3 if all of older versions of app use same JRE then we can use "reduced" version of ful update that updates everything but runtime folder > This can cut download size if it is an issue > > 2. Full image for update may be the same as an app. > E.g. we are currently installing same .dmg for JRE on Mac and you certainly can do silent installation with .msi > > 3. The way to get full app image to compare against is not fixed. > For example, you can save .zip of 1.0 version when you built 1.0, or install and zip image before you are ready to ship new version, > or even manually provide list of files to include into update. > > 4. Based on feedback i saw from Sparkle users and Oracle's use of AU for JRE keeping lots of delta's is not required. > Interestingly delta's are often used not to improve user's time to update but to reduce server load. > > Another point to consider is that use of single "update package" seem to be the way many other native update systems are implemented > (based on what i saw, clearly i am not familiar with all of them). > > -igor From artem.ananiev at oracle.com Mon Jun 18 05:49:47 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 18 Jun 2012 16:49:47 +0400 Subject: Update JavaFX in JFXPanel while EDT is blocked In-Reply-To: <4FDB8DB3.9070206@media-interactive.de> References: <4FDB8DB3.9070206@media-interactive.de> Message-ID: <4FDF23EB.6040408@oracle.com> Hi, Werner, your scenario doesn't look JFXPanel specific: you block EDT and at the same time request Swing to repaint. As expected, it doesn't work, as Swing repaints on EDT :) paintImmediately() may sometimes help, but be very careful: if you call Platform.runLatter() to update FX progress bar and then right after that call JFXPanel.paintImmediately(), you will likely get the old state of the progress bar. Ideally, you should move all the initialization code to background thread(s). When you need to update UI, e.g. update progress bar value, you need: 1. In pure Swing app: call invokeLater() and set JProgressBar's value from the Runnable. JProgressBar will then implicitly call repaint(). Some time later the progress bar will be painted by RepaintManager. 2. in FX/Swing app: call runLater() and set ProgressBar's value from the Runnable. ProgressBar will then invalidate FX scene, which will trigger FX repaint, which will automatically call JFXPanel.repaint(). Thanks, Artem On 6/15/2012 11:32 PM, Werner Lehmann wrote: > Hi, > > is there a way to force a JFXPanel to update itself while the EDT is > blocked? > > This is my situation: on startup the Swing application shows a login > screen with a progress bar. This login screen is a JFXPanel and the > progress bar is a JavaFX control. In the background lots of > initializations are going on, and much of this should run on the EDT. > Therefore it is executing within SwingUtilties.invokeAndWait - but that > also seems to block updates to the JFXPanel and the progressbar is not > updated. > > Maybe I can force an immediate repaint of the progressbar only? After > all, I am running two GUI toolkits at the same time, both with their own > GUI threads, so I'd like to take advantage of that... > > Thx. > > Werner From neugens.limasoftware at gmail.com Mon Jun 18 05:52:03 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 18 Jun 2012 14:52:03 +0200 Subject: Update JavaFX in JFXPanel while EDT is blocked In-Reply-To: <4FDB8DB3.9070206@media-interactive.de> References: <4FDB8DB3.9070206@media-interactive.de> Message-ID: Mantra for Swing programmers: never, never, ever do long running non ui related things in the EDT :) 2012/6/15 Werner Lehmann : > Hi, > > is there a way to force a JFXPanel to update itself while the EDT is > blocked? > > This is my situation: on startup the Swing application shows a login screen > with a progress bar. This login screen is a JFXPanel and the progress bar is > a JavaFX control. In the background lots of initializations are going on, > and much of this should run on the EDT. Therefore it is executing within > SwingUtilties.invokeAndWait - but that also seems to block updates to the > JFXPanel and the progressbar is not updated. > > Maybe I can force an immediate repaint of the progressbar only? After all, I > am running two GUI toolkits at the same time, both with their own GUI > threads, so I'd like to take advantage of that... > > Thx. > > Werner -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA? FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From lehmann at media-interactive.de Mon Jun 18 06:04:01 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 18 Jun 2012 15:04:01 +0200 Subject: Update JavaFX in JFXPanel while EDT is blocked In-Reply-To: <4FDF23EB.6040408@oracle.com> References: <4FDB8DB3.9070206@media-interactive.de> <4FDF23EB.6040408@oracle.com> Message-ID: <4FDF2741.4000707@media-interactive.de> Hi Artem, I was kinda hoping that the JFXPanel could repaint itself without depending on the EDT - but Richard already cleared that up. As to the steps below: I have implemented no 2 already but got big delays in updating the progressbar (on the JFXPanel), and also animations were stuttering or invisible (jumping to the last keyframe in one step). Actually, those initalizations are interspersed with lots of Swing code. It will take a while to divvy that up. Even more, this used to be done in a background thread and did not fail, at least there were no noticable problems. I am not trying to defend that style though. Wasn't me... :) Werner On 18.06.2012 14:49, Artem Ananiev wrote: > Hi, Werner, > > your scenario doesn't look JFXPanel specific: you block EDT and at the > same time request Swing to repaint. As expected, it doesn't work, as > Swing repaints on EDT :) paintImmediately() may sometimes help, but be > very careful: if you call Platform.runLatter() to update FX progress bar > and then right after that call JFXPanel.paintImmediately(), you will > likely get the old state of the progress bar. > > Ideally, you should move all the initialization code to background > thread(s). When you need to update UI, e.g. update progress bar value, > you need: > > 1. In pure Swing app: call invokeLater() and set JProgressBar's value > from the Runnable. JProgressBar will then implicitly call repaint(). > Some time later the progress bar will be painted by RepaintManager. > > 2. in FX/Swing app: call runLater() and set ProgressBar's value from the > Runnable. ProgressBar will then invalidate FX scene, which will trigger > FX repaint, which will automatically call JFXPanel.repaint(). > > Thanks, > > Artem From lehmann at media-interactive.de Mon Jun 18 06:05:17 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 18 Jun 2012 15:05:17 +0200 Subject: Update JavaFX in JFXPanel while EDT is blocked In-Reply-To: References: <4FDB8DB3.9070206@media-interactive.de> Message-ID: <4FDF278D.2080907@media-interactive.de> Well, is there also a Mantra about what to do when you inherit such a thing? :) On 18.06.2012 14:52, Mario Torre wrote: > Mantra for Swing programmers: never, never, ever do long running non > ui related things in the EDT :) From kimtopley at gmail.com Mon Jun 18 06:06:45 2012 From: kimtopley at gmail.com (kimtopley at gmail.com) Date: Mon, 18 Jun 2012 13:06:45 +0000 Subject: Update JavaFX in JFXPanel while EDT is blocked Message-ID: <18849439-1340024806-cardhu_decombobulator_blackberry.rim.net-600164071-@b2.c12.bise6.blackberry> A) run a mile or B) rewrite from scratch. ------Original Message------ From: Werner Lehmann Sender: openjfx-dev-bounces at openjdk.java.net To: openjfx-dev at openjdk.java.net Subject: Re: Update JavaFX in JFXPanel while EDT is blocked Sent: Jun 18, 2012 9:05 AM Well, is there also a Mantra about what to do when you inherit such a thing? :) On 18.06.2012 14:52, Mario Torre wrote: > Mantra for Swing programmers: never, never, ever do long running non > ui related things in the EDT :) Sent from my Verizon Wireless BlackBerry From artem.ananiev at oracle.com Mon Jun 18 07:22:53 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 18 Jun 2012 18:22:53 +0400 Subject: Update JavaFX in JFXPanel while EDT is blocked In-Reply-To: References: <4FDB8DB3.9070206@media-interactive.de> Message-ID: <4FDF39BD.6080406@oracle.com> On 6/18/2012 4:52 PM, Mario Torre wrote: > Mantra for Swing programmers: never, never, ever do long running non > ui related things in the EDT :) That's true for any UI toolkit, and for JavaFX as well :) Thanks, Artem > 2012/6/15 Werner Lehmann: >> Hi, >> >> is there a way to force a JFXPanel to update itself while the EDT is >> blocked? >> >> This is my situation: on startup the Swing application shows a login screen >> with a progress bar. This login screen is a JFXPanel and the progress bar is >> a JavaFX control. In the background lots of initializations are going on, >> and much of this should run on the EDT. Therefore it is executing within >> SwingUtilties.invokeAndWait - but that also seems to block updates to the >> JFXPanel and the progressbar is not updated. >> >> Maybe I can force an immediate repaint of the progressbar only? After all, I >> am running two GUI toolkits at the same time, both with their own GUI >> threads, so I'd like to take advantage of that... >> >> Thx. >> >> Werner > > > From hang.vo at oracle.com Mon Jun 18 07:19:47 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Jun 2012 14:19:47 +0000 Subject: hg: openjfx/2.2/graphics/rt: 2 new changesets Message-ID: <20120618141949.69893479B5@hg.openjdk.java.net> Changeset: a86b9a28478c Author: Pavel Safrata Date: 2012-06-18 16:06 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a86b9a28478c RT-22636: Fixed coordinates of keyboard-triggered ContextMenuEvent. RT-20936: Documented coordinates of ContextMenuEvent. ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java + javafx-ui-common/test/unit/javafx/scene/input/ContextMenuEventTest.java Changeset: c9fe13cb7935 Author: Pavel Safrata Date: 2012-06-18 16:15 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/c9fe13cb7935 RT-22636 part 2: handled scene without focus owner. ! javafx-ui-common/src/javafx/scene/Scene.java From hang.vo at oracle.com Mon Jun 18 08:34:13 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Jun 2012 15:34:13 +0000 Subject: hg: openjfx/2.2/controls/rt: [mq]: rt22054 Message-ID: <20120618153417.C77CB479B7@hg.openjdk.java.net> Changeset: 1e240f8f9fc5 Author: leifs Date: 2012-06-18 08:26 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/1e240f8f9fc5 [mq]: rt22054 ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java From hang.vo at oracle.com Mon Jun 18 09:04:20 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Jun 2012 16:04:20 +0000 Subject: hg: openjfx/2.2/controls/rt: Fixed RT-22644: [TextArea] Typing Tab or Enter breaks Undo chain Message-ID: <20120618160421.2FCE9479B8@hg.openjdk.java.net> Changeset: 38a9585cb2db Author: leifs Date: 2012-06-18 08:50 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/38a9585cb2db Fixed RT-22644: [TextArea] Typing Tab or Enter breaks Undo chain ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java From tom.schindl at bestsolution.at Mon Jun 18 09:46:16 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 18 Jun 2012 18:46:16 +0200 Subject: Releaseing opensourced sources with SDK? Message-ID: <4FDF5B58.7030905@bestsolution.at> Hi, The JDK release together with the binary the sources in an src.zip. Is there are reason JavaFx is not doing the same for the stuff already opensourced? I'd like to see getting the currently opensourced sourcecode being shipped with: * JDKu6 * JavaFX-SDK-Preview-Drops This would it a lot easier for developers to debug JavaFX sourcecode without cloning the hg-repo, ... . Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From tom.schindl at bestsolution.at Mon Jun 18 09:51:14 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 18 Jun 2012 18:51:14 +0200 Subject: Releaseing opensourced sources with SDK? In-Reply-To: <4FDF5B58.7030905@bestsolution.at> References: <4FDF5B58.7030905@bestsolution.at> Message-ID: <4FDF5C82.7030404@bestsolution.at> Am 18.06.12 18:46, schrieb Tom Schindl: > Hi, > > The JDK release together with the binary the sources in an src.zip. Is > there are reason JavaFx is not doing the same for the stuff already > opensourced? > > I'd like to see getting the currently opensourced sourcecode being > shipped with: > * JDKu6 > * JavaFX-SDK-Preview-Drops > > This would it a lot easier for developers to debug JavaFX sourcecode > without cloning the hg-repo, ... . Only applies the JDKu6 drops: ... and just as an addon to this. If you are not releaseing the sourcecode without your JDK builds you should at least ship the JavaDoc else without internet access IDEs will most likely have troubles providing autocompletion, Javadoc-hover, ... which destroys there development experience. Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From pedro.duquevieira at gmail.com Mon Jun 18 09:58:35 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 18 Jun 2012 17:58:35 +0100 Subject: Releaseing opensourced sources with SDK? Message-ID: +1 one on this Cheers, -- Pedro Duque Vieira From philip.race at oracle.com Mon Jun 18 10:21:35 2012 From: philip.race at oracle.com (Phil Race) Date: Mon, 18 Jun 2012 10:21:35 -0700 Subject: Releaseing opensourced sources with SDK? In-Reply-To: <4FDF5B58.7030905@bestsolution.at> References: <4FDF5B58.7030905@bestsolution.at> Message-ID: <4FDF639F.5030103@oracle.com> FWIW the JDK's src.zip has never had any connection to being "open sourced". Its was delivered starting back in 1995 and the JDK only became open source in 2007. Moreover its contents were limited and intended to be more of a help to developers using the public API classes to see how the classes were implemented at a time when the early docs were probably somewhat lacking in detail. -phil. On 6/18/2012 9:46 AM, Tom Schindl wrote: > Hi, > > The JDK release together with the binary the sources in an src.zip. Is > there are reason JavaFx is not doing the same for the stuff already > opensourced? > > I'd like to see getting the currently opensourced sourcecode being > shipped with: > * JDKu6 > * JavaFX-SDK-Preview-Drops > > This would it a lot easier for developers to debug JavaFX sourcecode > without cloning the hg-repo, ... . > > Tom > From richard.bair at oracle.com Mon Jun 18 10:31:15 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 18 Jun 2012 10:31:15 -0700 Subject: Auto-update of native application bundles In-Reply-To: References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> <4FDE5AB4.2040102@oracle.com> <4FDE646D.3070102@oracle.com> Message-ID: <079B7777-C785-4AAC-88E7-33B44120C366@oracle.com> > Advantages and disadvantages both ways, it would be good to get input from > the community and other JFX'ers on this. Some additional thoughts. If you have an application where you release updates infrequently, then having the diff approach works reasonably well, because you don't have to have diffs for everything. You could for example only maintain a diff for CURRENT-1 to CURRENT. But anybody on CURRENT -2+ would have to just download the full new app. For infrequent upgrades, that is reasonable. Potentially it could be configurable for any CURRENT - N. On the other and, if you are doing a lot of rapid prototyping or evolution of your application (think web-style development where you might update multiple times a day), then doing the versioned-file approach is way nicer. One could imagine supporting jmod files in this manner in Java 8 (check the module dependencies, grab the ones that have changed, etc). With jmod you might not even need the xml file? Another thing is that I don't like putting anything in ~/.javafx if we can avoid it, and certainly not application specific stuff. Having all application settings, configuration options, etc in the application directory itself is preferable, because it means we never end up with situations where somebody has deleted the application (just dragging the .app to the trash on mac) and then they download the app again and it gets confused with settings we've stored and were never cleared up. I don't know which way that argues, just that I think we should not store anything outside of the app directory. Richard From kevin.rushforth at oracle.com Mon Jun 18 10:31:36 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 18 Jun 2012 10:31:36 -0700 Subject: Releaseing opensourced sources with SDK? In-Reply-To: References: Message-ID: <4FDF65F8.7080004@oracle.com> This is filed as: http://javafx-jira.kenai.com/browse/RT-21415 and is targeted for 3.0. -- Kevin Pedro Duque Vieira wrote: > +1 one on this > > Cheers, > > From igor.nekrestyanov at oracle.com Sun Jun 17 15:31:16 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Sun, 17 Jun 2012 15:31:16 -0700 Subject: Auto-update of native application bundles In-Reply-To: References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> Message-ID: <4FDE5AB4.2040102@oracle.com> Hi, > > * In your proposal the "app-cast" system is used, where each update > is released as a patch (i.e. the 'diff') to get from one version > to the next. If an app was out in the wild running at version 2, > and the latest release was actually version 5, then to upgrade we > would download the v2->v3 patch, install it, then the v3->v4 patch > install it, and then the v4->v5 patch and install that (correct me > if I got this wrong). > Sparkle appcast is simply update descriptor (kind of RSS) wth news about update availability. It is unrelated to the way update is shipped. Moreover but default update is full image of application and can be installed on top of any version. Developer may choose to have delta updates if he wants to optimize but he is not required too. We are using Sparkle to AU JRE on Mac and it works fine. > > * In my POC I've gone for the "app-profile" approach, which > basically defines the latest release of the system in it's > entirety. It's up to each app out there to determine what has > changed between it's version and the latest version and download > what it needs (i.e. the 'diff'). To go from version 2 to version > 5, the app would compare the version of the JARs in its own > app-profile against the new one, and download the ones that have > changed. There is no download of the 'in-between' versions of 3 > and 4. > Sparkle approach does not assume this either. Update description must have full image. If there is (optional) delta image it is used but otherwise full image is used. IMHO, the biggest differences between appcast xml and app-profile.xml are: * appcast is strictly update descriptor and app-profile.xml is application descriptor + versioning info * app-profile.xml corresponds to subset of "item" element in the appcast * appcast xml may have multiple items - e.g. define application updates for different platforms or several apps * item in the appcast describes UPDATE, not application. Application is kind of blackbox and this is good. I.e. no knowledge of classpath or specific directory structure. Only what driver knows how to apply update. * item has update specific information, e.g. may include release notes that can be used to justify why to upgrade. It does not mean we can not use efficient compression (e.g. pack200 for jars) or update parts of app package (e.g. leave alone Java runtime). This is up for driver implementation. And another important difference is simplier model in Sparkle: * ONE version to check (whats available vs update version in appcast) [no need to check every jar, resource file, etc] * ONE file with update to sign and stage (less hassle for developer) [instead of every jar, fewer chance to have staging error (not all files are uploaded, etc)] * ONE file to download [less chance to have mixed state, e.g. developer may decide to restage/resign app with same version but some jars are already loaded] JNLP model is ok but it tries to solve "remote launch" problem and here we are solving other task. IMHO, if we separate launch descriptor and update descriptor we will have better model for this problem. > > It was with this type of usage in mind that I ended up leaning towards > the app-profile approach. I imagined my initial upload to my server > would be all the JARs for my app, and then when I release subsequent > versions I only upload the couple of JARs that have changed and upload > the new app-profile.xml (and the build tools could potentially do the > upload as well and they would know which jars had changed). Essentially you are implementing specific kind of "delta update". Except you can dynamically define what delta is needed for arbitrary initial state. In sparkle model specifics of delta update are up to the update driver that knows what to do with update package. We can support update packages that only update "important" subset of jars, etc. For background type of updates size is often not an issue at all (although there are scenarios where it needs to be optimized). Anyway, with "update driver" plugins we can extend set of delta updates supported as needed. > The flip side of this is that you couldn't choose to go to an > in-between version if you wanted to, but I'm not sure that's an overly > valid use case? Agree, this is not important use case. But you may have "different" latest versions - one for XP and another for Vista and another for Mac. > > With this approach we also have the option of providing a "repair" > function. So a client could run a utility to just completely download > the entire app and get fresh copies of all the JARs. This is not > critical but it could be quite useful. With the app-cast approach, you > have to uninstall and then reinstall with your original MSI and then > patch (or install with the new MSI) - the uninstall may delete your > 'appdata' though, whereas a "repair" could leave this intact. IMHO, repair by reinstalling still needs to be supported and existing mechanisms (like MSI or rpm) have means to do this. It does not seem as critical requirements for AU module. > > One other niggling thing for me is how to do things like system > properties or VM settings (like -Xmx) without an app-profile. > Currently you would be hard coding those into your 'exe' I imagine? So > if an update wanted to change these things it would have to recompile > the launcher exe and that would have to be part of the 'patch'? Bundled app has application descriptor/config file. It is called package.cfg and very simple now. It may and need to be improved to pass in things like JVM options. In fact launcher is fixed, it is not compiled per app. It is embedded into ant task and simply renamed when application bundle is generated. All variable parameters are coming from package.cfg > There'd be no easy (possible?) way for the user to change these > settings on their machine, not sure if that's a good thing or a bad > thing though? Well, if we need it (it is questionable) then user may tweak package.cfg directly (imho, bad idea. especially if it is system wide) or we could have some abstraction of "config" API and application may update its settings per user. But this is unrelated to AU. User settings should be left intact after AU. Default app settings are part of application descriptor. So i think we are good with this. > > And finally one other edge use case I thought of today: it's not > uncommon to have several 'apps' included in the one install. For > example you might have a user UI and an admin UI. In Java-land, these > would ideally share the same libraries but have different 'main' > classes. I was thinking the app-profile approach could potentially be > extended to cover this but it needs more thinking about, and may just > be an unsupported use case. Not sure how/if the app-cast approach > could handle this if we said it was a requirement. It does not seem hard to me. Key question here -- are they shipped as separate installs or one bundle with multiple launchers. If they are separate installs they are updated separately and there should be application specific means to ensure they are consistent (because user may simply install incompatible versions to start with). Application specific solution may use AU APIs to force autoupdate if user tries to launch app that is compatible with others. If they are shipped as one bundle then nothing special to be done by AU. AU will update folder with multiple launchers easily as they are just files for AU module. It is different story how to bundle msi/exe/dmg for this scenario but this is separate from AU discussion, -igor > > Cheers, > Dan > > > On Sun, Jun 17, 2012 at 5:26 PM, Igor Nekrestyanov > > > wrote: > > Hi Dan, > > thanks for the great writeup (and pushing this ahead). > I finally started to look into this more actively. Some > questions/suggestions below. > > On 6/15/12 5:02 PM, Daniel Zwolenski wrote: > > *The General Approach* > > Richard made reference to > Sparkle and > > like him, I feel this is a nice reference point for the style > of solution > we want. The neat thing that Sparkle does is it provides an > API that > developers can use inside their code to completely control and > customise > the upgrade of their application. This is the approach I've > gone for as > well. My POC includes a Java API that you can call to check > for updates and > trigger downloads. > > IMHO, main great thing about Sparkle is that it is easy to add > basic AU functionality to the application > (see https://github.com/andymatuschak/Sparkle/wiki) > You do not need to use API unless you want custom solution. > > Therefore i am not focusing here on the public API part (keeping > this for later). > > > I think this approach is neat and powerful, but it's worth > mentioning that > there is still some debate amongst the JFX team about whether > to go down > this road or avoid the Java API and use off-the-shelf native > updaters. Your > input will very likely influence this decision so if you have > a preference > one way or the other (or have other suggestions), be vocal. > > > I think there is no debate on that having some "all in java with > minimal native code solution" is good idea. > Debate is about whether it should be the only option or it also > make sense to support other native update mechanisms > (e.g. use Sparkle directly on Mac). > > As Dan said, thoughts on this are very welcome. > > > > An XML deployment descriptor, called 'app-profile.xml' is used > to describe > the JARs, JRE versions and other launch details - it is > semantically > comparable to a traditional JNLP file. When an update is > triggered via the > API, the code checks the remote URL for an updated > app-profile.xml. If it > finds one it downloads this and checks this with its local > app-profile.xml. > Any jars that have different version numbers are downloaded, > and if a new > JRE version is defined in the app-profile then the zip for this is > downloaded and extracted as well. > > Where these files are placed after download? > > Once all the downloading is complete, the > local app-profile is then overwritten with the newer one and > this newer one > will be used by the native launcher to set the classpath next > time the app > is started. > > > IMHO, we can simplify this model following Sparkle ideas. > Sparkle does not know anything about application structure, etc. > and focus only on update process. > This makes it easy to use, simple and robust as it focuses on > solves one problem. > > Important points are: > A. Sparkle uses "appcast" to describe what updates are available > > (https://github.com/andymatuschak/Sparkle/wiki/publishing-an-update) > Appcast includes > - version of updates available > - meta info about each update (type of update (e.g. > regular or mandatory security), release notes, system requirements > (e.g. Windows version 7+), etc.) > - set of available update packages (aka enclosures) (e.g. > full app image, delta patches for several versions, etc.) > > B. Sparkle knows where to look for update meta info in the > application package (on Mac it is part of Info.plist that is some > kind of application manifest). > However, it only needs to know: > - URL of appcast > - location of key to verify update signatures > - application update settings/preferences > The expectation is that once app is updated this info will > be updated (as it is part of "update package") > [Note: this is not so simple on Windows if we want to make > sure we are good citizens and need to update registry] > > C. Update package is black box for Sparkle core. > It is modeled as > - file hosted at given URL > - signed with given key (signature is part of appcast) > - package type defines what "update driver" will be > handling this update > (this allows to add support for various update > packages as plugins/modules) > - for most type for packages (except running installers) > Sparkle goal is to update set of application files only > [Windows or linux require more work as we may need to > update registry or package info] > > D. If admin permissions are needed they only asked before update > is finally installed. > Sparkle does not keep any internal state in the app folder > as it may be only writable for admins. > > E. Application relaunch after update > > This is close to your approach but there are some important > differences. > Following Sparkle more closely may simplify things and at the same > time add some desired features > (e.g. ability to validate origin of autoupdate) > > My current thoughts on "ideal" basic experience are as follows. > > ======== > Developer experience (no java coding needed): > > 1. At the package time developer requests autoupdate support in > the native cobundle by providing: > * http URL to appcast + public key/cert to validate update > signatures > * or https url > and define application update mode (mandatory update, ask user > and allow him to skip version, etc.) > > 2. Once update is needed developer creates "update package" > (single file). > For this he will need to run same packager utility/ant task but > specify base image, certificate to sign package and > and desired type of update (full or incremental) > > 3. Developer need to create an appcast xml file (default can be > generated in step 2 but he may want to customize it) > > 4. Developer stages both appcast and package bundle > ========= > > End user (background updates): > * installs application with background update policy > * every time application is launched it will check appcast (if > online) > * if update is detected it will be loaded silently while app is > running > * Once update is loaded and verified user will be prompted to > install it (it may be notification if update is mandatory) > * If he agrees then he may see UAC dialog (unless installation > is on per user basis) > * application relaunch after update > * attempt to launch app being updated should fail with > reasonable dialog and should not fail update process (it may need > to wait will .exe is unlocked) > ========= > > Implementation wise i was thinking along the lines of what you > have (only glimpsed though your code it though) with following > notable differences: > > * update package is single file and we only worry about it version. > No need to worry about version of individual components as we > do not want arbitrary mix&match. > > * updates are loaded to ~/.javafx/app-key (where app-key could > be derivation from app install location) > We also keep user answers for this app in that folder (e.g. > had we offered him this version already? when was last time we > checked for update, etc) > > * Update process is: > - build temp full app image in the ~/.javafx/app-key/version > - if update accepted then exit application and run helper > app co copy image over > - possibly run "post upgrade script" as part of helper app > (this script is specific to "bundler" technology used. > E.g. for EXE/MSI bundlers we may want to update few keys in registry > - relaunch app > - AU module running in the relaunched app could detect temp > "image" that is the same as current version and erase it > > Note that there could be several alternative helper apps. > E.g. one that pops UAC and one that does not for per user installs. > Or helper up to install update packaged as MSI (by running > msiexec silently and showing progress) > > I was even thinking that "helper" can be implemented in java > with minimal native code (to elevate permissions and update > registry if needed). > > * Integration with application bundle > - details on whether AU is needed and what type is it may be > embedded application manifest for main app jar > - embedded jauncher will read them and use internal AU APIs > accordingly > (this is why no user code changes are needed) > - current app version, update url and signature are part of > package.cfg or manifest in the main app jar > - AU support itself is part of jfxrt.jar, bundle also > includes helper app to "move image into final location" and > script to do "post update config" > > What do you think? > > -igor > > From igor.nekrestyanov at oracle.com Sun Jun 17 16:12:45 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Sun, 17 Jun 2012 16:12:45 -0700 Subject: Auto-update of native application bundles In-Reply-To: References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> <4FDE5AB4.2040102@oracle.com> Message-ID: <4FDE646D.3070102@oracle.com> On 6/17/12 4:00 PM, Daniel Zwolenski wrote: > Hi Igor, > > I think I'm missing some part of the puzzle. From what you are saying > for an upgrade you would push up the entire new app (as an MSI or some > custom format?). This new file will contain all the JARs and the JRE > regardless of whether it's changed or not - i.e. this is similar to my > approach except in my approach it's all extracted but in yours it's > all packed into one file. Is this understanding correct? Update packages might have different formats and which one to use may depend on specific use case. (think about it as what image format to use for image file) It is required to be one file but does not require to have everything in it. It may have everything. "Full bundle" in the file should be supported for sure (and it could be simply zip file or something more advanced). We can also support some "delta bundle" formats that will be only applicable for upgrade from specific version. E.g. i can imaging appcast that says something like: - if you are running previous version of my app (1.4.5) then you only need this package with one resource file updated - if you are running version 1.3 or later then use this package (for simplicity zip) with application files only - if you are running older version then you need full bundle as JRE was updated > How then does the system work out what needs to be downloaded and > updated? It has a locally extracted version of the app and a remote > file (effectively a zip), how does it determine what's changed? It is defined at the package time. When developer packages his application he needs to decide if he wants delta updates. If not, he simply refer to "full bundle"in the appcast. If he wants delta updates he need to point to images to be used as baselines and then packager will figure out what is updated based on binary comparison. Let me know if this is still confusing, -igor > > I think I missed something in your description. > > > > On Mon, Jun 18, 2012 at 8:31 AM, Igor Nekrestyanov > > > wrote: > > Hi, >> >> * In your proposal the "app-cast" system is used, where each >> update is released as a patch (i.e. the 'diff') to get from >> one version to the next. If an app was out in the wild >> running at version 2, and the latest release was actually >> version 5, then to upgrade we would download the v2->v3 >> patch, install it, then the v3->v4 patch install it, and then >> the v4->v5 patch and install that (correct me if I got this >> wrong). >> > Sparkle appcast is simply update descriptor (kind of RSS) wth news > about update availability. > It is unrelated to the way update is shipped. > > Moreover but default update is full image of application and can > be installed on top of any version. > Developer may choose to have delta updates if he wants to optimize > but he is not required too. > We are using Sparkle to AU JRE on Mac and it works fine. >> >> * In my POC I've gone for the "app-profile" approach, which >> basically defines the latest release of the system in it's >> entirety. It's up to each app out there to determine what has >> changed between it's version and the latest version and >> download what it needs (i.e. the 'diff'). To go from version >> 2 to version 5, the app would compare the version of the JARs >> in its own app-profile against the new one, and download the >> ones that have changed. There is no download of the >> 'in-between' versions of 3 and 4. >> > Sparkle approach does not assume this either. > Update description must have full image. If there is (optional) > delta image it is used but otherwise full image is used. > > IMHO, the biggest differences between appcast xml and > app-profile.xml are: > * appcast is strictly update descriptor and app-profile.xml is > application descriptor + versioning info > * app-profile.xml corresponds to subset of "item" element in > the appcast > * appcast xml may have multiple items - e.g. define application > updates for different platforms or several apps > * item in the appcast describes UPDATE, not application. > Application is kind of blackbox and this is good. > I.e. no knowledge of classpath or specific directory > structure. Only what driver knows how to apply update. > * item has update specific information, e.g. may include > release notes that can be used to justify why to upgrade. > > It does not mean we can not use efficient compression (e.g. > pack200 for jars) or update parts of app package (e.g. leave alone > Java runtime). > This is up for driver implementation. > > And another important difference is simplier model in Sparkle: > * ONE version to check (whats available vs update version in > appcast) > [no need to check every jar, resource file, etc] > * ONE file with update to sign and stage (less hassle for > developer) > [instead of every jar, fewer chance to have staging error > (not all files are uploaded, etc)] > * ONE file to download > [less chance to have mixed state, e.g. developer may > decide to restage/resign app with same version but some jars are > already loaded] > > JNLP model is ok but it tries to solve "remote launch" problem and > here we are solving other task. > > IMHO, if we separate launch descriptor and update descriptor we > will have better model for this problem. > >> >> It was with this type of usage in mind that I ended up leaning >> towards the app-profile approach. I imagined my initial upload to >> my server would be all the JARs for my app, and then when I >> release subsequent versions I only upload the couple of JARs that >> have changed and upload the new app-profile.xml (and the build >> tools could potentially do the upload as well and they would know >> which jars had changed). > Essentially you are implementing specific kind of "delta update". > Except you can dynamically define what delta is needed for > arbitrary initial state. > > In sparkle model specifics of delta update are up to the update > driver that knows what to do with update package. > We can support update packages that only update "important" subset > of jars, etc. > > For background type of updates size is often not an issue at all > (although there are scenarios where it needs to be optimized). > > Anyway, with "update driver" plugins we can extend set of delta > updates supported as needed. > > >> The flip side of this is that you couldn't choose to go to an >> in-between version if you wanted to, but I'm not sure that's an >> overly valid use case? > Agree, this is not important use case. > But you may have "different" latest versions - one for XP and > another for Vista and another for Mac. > >> >> With this approach we also have the option of providing a >> "repair" function. So a client could run a utility to just >> completely download the entire app and get fresh copies of all >> the JARs. This is not critical but it could be quite useful. With >> the app-cast approach, you have to uninstall and then reinstall >> with your original MSI and then patch (or install with the new >> MSI) - the uninstall may delete your 'appdata' though, whereas a >> "repair" could leave this intact. > IMHO, repair by reinstalling still needs to be supported and > existing mechanisms (like MSI or rpm) have means to do this. > It does not seem as critical requirements for AU module. > >> >> One other niggling thing for me is how to do things like system >> properties or VM settings (like -Xmx) without an app-profile. >> Currently you would be hard coding those into your 'exe' I >> imagine? So if an update wanted to change these things it would >> have to recompile the launcher exe and that would have to be part >> of the 'patch'? > Bundled app has application descriptor/config file. It is called > package.cfg and very simple now. > It may and need to be improved to pass in things like JVM options. > > In fact launcher is fixed, it is not compiled per app. > It is embedded into ant task and simply renamed when application > bundle is generated. > All variable parameters are coming from package.cfg > >> There'd be no easy (possible?) way for the user to change these >> settings on their machine, not sure if that's a good thing or a >> bad thing though? > Well, if we need it (it is questionable) then user may tweak > package.cfg directly (imho, bad idea. especially if it is system > wide) or we could have > some abstraction of "config" API and application may update its > settings per user. But this is unrelated to AU. > User settings should be left intact after AU. Default app settings > are part of application descriptor. So i think we are good with this. > >> >> And finally one other edge use case I thought of today: it's not >> uncommon to have several 'apps' included in the one install. For >> example you might have a user UI and an admin UI. In Java-land, >> these would ideally share the same libraries but have different >> 'main' classes. I was thinking the app-profile approach could >> potentially be extended to cover this but it needs more thinking >> about, and may just be an unsupported use case. Not sure how/if >> the app-cast approach could handle this if we said it was a >> requirement. > It does not seem hard to me. > > Key question here -- are they shipped as separate installs or one > bundle with multiple launchers. > If they are separate installs they are updated separately and > there should be application specific means to ensure they are > consistent > (because user may simply install incompatible versions to start > with). Application specific solution may use AU APIs to force > autoupdate > if user tries to launch app that is compatible with others. > > If they are shipped as one bundle then nothing special to be done > by AU. AU will update folder with multiple launchers easily as > they are just files for AU module. > It is different story how to bundle msi/exe/dmg for this scenario > but this is separate from AU discussion, > > -igor > >> >> Cheers, >> Dan >> >> >> On Sun, Jun 17, 2012 at 5:26 PM, Igor Nekrestyanov >> > > wrote: >> >> Hi Dan, >> >> thanks for the great writeup (and pushing this ahead). >> I finally started to look into this more actively. Some >> questions/suggestions below. >> >> On 6/15/12 5:02 PM, Daniel Zwolenski wrote: >> >> *The General Approach* >> >> Richard made reference to >> Sparkle and >> >> like him, I feel this is a nice reference point for the >> style of solution >> we want. The neat thing that Sparkle does is it provides >> an API that >> developers can use inside their code to completely >> control and customise >> the upgrade of their application. This is the approach >> I've gone for as >> well. My POC includes a Java API that you can call to >> check for updates and >> trigger downloads. >> >> IMHO, main great thing about Sparkle is that it is easy to >> add basic AU functionality to the application >> (see https://github.com/andymatuschak/Sparkle/wiki) >> You do not need to use API unless you want custom solution. >> >> Therefore i am not focusing here on the public API part >> (keeping this for later). >> >> >> I think this approach is neat and powerful, but it's >> worth mentioning that >> there is still some debate amongst the JFX team about >> whether to go down >> this road or avoid the Java API and use off-the-shelf >> native updaters. Your >> input will very likely influence this decision so if you >> have a preference >> one way or the other (or have other suggestions), be vocal. >> >> >> I think there is no debate on that having some "all in java >> with minimal native code solution" is good idea. >> Debate is about whether it should be the only option or it >> also make sense to support other native update mechanisms >> (e.g. use Sparkle directly on Mac). >> >> As Dan said, thoughts on this are very welcome. >> >> >> >> An XML deployment descriptor, called 'app-profile.xml' is >> used to describe >> the JARs, JRE versions and other launch details - it is >> semantically >> comparable to a traditional JNLP file. When an update is >> triggered via the >> API, the code checks the remote URL for an updated >> app-profile.xml. If it >> finds one it downloads this and checks this with its >> local app-profile.xml. >> Any jars that have different version numbers are >> downloaded, and if a new >> JRE version is defined in the app-profile then the zip >> for this is >> downloaded and extracted as well. >> >> Where these files are placed after download? >> >> Once all the downloading is complete, the >> local app-profile is then overwritten with the newer one >> and this newer one >> will be used by the native launcher to set the classpath >> next time the app >> is started. >> >> >> IMHO, we can simplify this model following Sparkle ideas. >> Sparkle does not know anything about application structure, >> etc. and focus only on update process. >> This makes it easy to use, simple and robust as it focuses >> on solves one problem. >> >> Important points are: >> A. Sparkle uses "appcast" to describe what updates are >> available >> >> (https://github.com/andymatuschak/Sparkle/wiki/publishing-an-update) >> Appcast includes >> - version of updates available >> - meta info about each update (type of update (e.g. >> regular or mandatory security), release notes, system >> requirements (e.g. Windows version 7+), etc.) >> - set of available update packages (aka enclosures) >> (e.g. full app image, delta patches for several versions, etc.) >> >> B. Sparkle knows where to look for update meta info in the >> application package (on Mac it is part of Info.plist that is >> some kind of application manifest). >> However, it only needs to know: >> - URL of appcast >> - location of key to verify update signatures >> - application update settings/preferences >> The expectation is that once app is updated this info >> will be updated (as it is part of "update package") >> [Note: this is not so simple on Windows if we want to >> make sure we are good citizens and need to update registry] >> >> C. Update package is black box for Sparkle core. >> It is modeled as >> - file hosted at given URL >> - signed with given key (signature is part of appcast) >> - package type defines what "update driver" will be >> handling this update >> (this allows to add support for various update >> packages as plugins/modules) >> - for most type for packages (except running >> installers) Sparkle goal is to update set of application >> files only >> [Windows or linux require more work as we may >> need to update registry or package info] >> >> D. If admin permissions are needed they only asked before >> update is finally installed. >> Sparkle does not keep any internal state in the app >> folder as it may be only writable for admins. >> >> E. Application relaunch after update >> >> This is close to your approach but there are some important >> differences. >> Following Sparkle more closely may simplify things and at the >> same time add some desired features >> (e.g. ability to validate origin of autoupdate) >> >> My current thoughts on "ideal" basic experience are as follows. >> >> ======== >> Developer experience (no java coding needed): >> >> 1. At the package time developer requests autoupdate support >> in the native cobundle by providing: >> * http URL to appcast + public key/cert to validate >> update signatures >> * or https url >> and define application update mode (mandatory update, ask >> user and allow him to skip version, etc.) >> >> 2. Once update is needed developer creates "update package" >> (single file). >> For this he will need to run same packager utility/ant >> task but specify base image, certificate to sign package and >> and desired type of update (full or incremental) >> >> 3. Developer need to create an appcast xml file (default can >> be generated in step 2 but he may want to customize it) >> >> 4. Developer stages both appcast and package bundle >> ========= >> >> End user (background updates): >> * installs application with background update policy >> * every time application is launched it will check appcast >> (if online) >> * if update is detected it will be loaded silently while >> app is running >> * Once update is loaded and verified user will be prompted >> to install it (it may be notification if update is mandatory) >> * If he agrees then he may see UAC dialog (unless >> installation is on per user basis) >> * application relaunch after update >> * attempt to launch app being updated should fail with >> reasonable dialog and should not fail update process (it may >> need to wait will .exe is unlocked) >> ========= >> >> Implementation wise i was thinking along the lines of what >> you have (only glimpsed though your code it though) with >> following >> notable differences: >> >> * update package is single file and we only worry about it >> version. >> No need to worry about version of individual components >> as we do not want arbitrary mix&match. >> >> * updates are loaded to ~/.javafx/app-key (where app-key >> could be derivation from app install location) >> We also keep user answers for this app in that folder >> (e.g. had we offered him this version already? when was last >> time we checked for update, etc) >> >> * Update process is: >> - build temp full app image in the >> ~/.javafx/app-key/version >> - if update accepted then exit application and run >> helper app co copy image over >> - possibly run "post upgrade script" as part of helper app >> (this script is specific to "bundler" technology >> used. E.g. for EXE/MSI bundlers we may want to update few >> keys in registry >> - relaunch app >> - AU module running in the relaunched app could detect >> temp "image" that is the same as current version and erase it >> >> Note that there could be several alternative helper >> apps. E.g. one that pops UAC and one that does not for per >> user installs. >> Or helper up to install update packaged as MSI (by >> running msiexec silently and showing progress) >> >> I was even thinking that "helper" can be implemented in >> java with minimal native code (to elevate permissions and >> update registry if needed). >> >> * Integration with application bundle >> - details on whether AU is needed and what type is it >> may be embedded application manifest for main app jar >> - embedded jauncher will read them and use internal AU >> APIs accordingly >> (this is why no user code changes are needed) >> - current app version, update url and signature are >> part of package.cfg or manifest in the main app jar >> - AU support itself is part of jfxrt.jar, bundle also >> includes helper app to "move image into final location" and >> script to do "post update config" >> >> What do you think? >> >> -igor >> >> > > From james.graham at oracle.com Mon Jun 18 12:30:12 2012 From: james.graham at oracle.com (Jim Graham) Date: Mon, 18 Jun 2012 12:30:12 -0700 Subject: Why does this list not have a reply-to? In-Reply-To: <4FDC408C.1080002@rockit.dk> References: <4FDC408C.1080002@rockit.dk> Message-ID: <4FDF81C4.4060206@oracle.com> Personally, I prefer lists that are configured this way. I found the following and skimmed through it and it seems to reflect my opinions on the matter: http://marc.merlins.org/netrants/listreplyto.html In my mind, catering to users who do not have a habit of choosing reply to sender vs. reply to list when they create a reply is not as important as preventing "I was writing a private reply to the sender containing sensitive information or opinions and I chose "Reply to Sender" specifically for that purpose and the email server decided it would tell my email client to send that private reply to the list". "Reply to list" lists make me shudder... :( ...jim On 6/16/2012 1:15 AM, Randahl Fink Isaksen wrote: > Sorry if this has been asked before, but why is this mailing list not > configured with a reply-to header, so that e-mail programs can figure > out that when we hit reply, the reply address should be openjfx and > *not* the sender address? > > I keep accidentally writing replies directly to the sender, and I have > noticed I am not the only one doing so. > > Randahl From lehmann at media-interactive.de Mon Jun 18 12:44:30 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 18 Jun 2012 21:44:30 +0200 Subject: Why does this list not have a reply-to? In-Reply-To: <4FDF81C4.4060206@oracle.com> References: <4FDC408C.1080002@rockit.dk> <4FDF81C4.4060206@oracle.com> Message-ID: <4FDF851E.9070905@media-interactive.de> I would disagree to that but I guess there is no point in discussing it (here). Fortunately it helped me discovering the "Reply to List" button in Thunderbird. All it took was some toolbar customization. According to the manual the button is enabled based on the presence or absence of the "List-Post" header. Maybe this helps one or two fellow thunderbirders... Werner On 18.06.2012 21:30, Jim Graham wrote: > Personally, I prefer lists that are configured this way. From hang.vo at oracle.com Mon Jun 18 13:04:36 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Jun 2012 20:04:36 +0000 Subject: hg: openjfx/2.2/controls/rt: Rollback fix for RT-21906: must separate shared css calculated values from node-specific css calculated values if node has user set font. Message-ID: <20120618200440.91D33479C4@hg.openjdk.java.net> Changeset: 104dff9f4ebc Author: Kinsley Wong Date: 2012-06-18 12:49 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/104dff9f4ebc Rollback fix for RT-21906: must separate shared css calculated values from node-specific css calculated values if node has user set font. ! javafx-ui-common/src/com/sun/javafx/css/CascadingStyle.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java From hang.vo at oracle.com Mon Jun 18 13:19:46 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Jun 2012 20:19:46 +0000 Subject: hg: openjfx/2.2/controls/rt: 2 new changesets Message-ID: <20120618201948.AB11A479C5@hg.openjdk.java.net> Changeset: 6f2d238b4c8b Author: hudson Date: 2012-06-14 14:06 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/6f2d238b4c8b Added tag 2.2-b13 for changeset 00a63ce77e97 ! .hgtags Changeset: 6144c0bee0f9 Author: Kinsley Wong Date: 2012-06-18 13:12 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/6144c0bee0f9 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt From hang.vo at oracle.com Mon Jun 18 14:04:30 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Jun 2012 21:04:30 +0000 Subject: hg: openjfx/2.2/graphics/rt: Fix RT-22129: PixelReader/Writer javadoc refer to nonexistant pixel format. Message-ID: <20120618210434.DD5AE479C6@hg.openjdk.java.net> Changeset: bc5b8880d1db Author: flar Date: 2012-06-18 13:57 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/bc5b8880d1db Fix RT-22129: PixelReader/Writer javadoc refer to nonexistant pixel format. ! javafx-ui-common/src/javafx/scene/image/PixelFormat.java ! javafx-ui-common/src/javafx/scene/image/PixelReader.java ! javafx-ui-common/src/javafx/scene/image/PixelWriter.java From igor.nekrestyanov at oracle.com Mon Jun 18 14:55:21 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Mon, 18 Jun 2012 14:55:21 -0700 Subject: Auto-update of native application bundles In-Reply-To: <079B7777-C785-4AAC-88E7-33B44120C366@oracle.com> References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> <4FDE5AB4.2040102@oracle.com> <4FDE646D.3070102@oracle.com> <079B7777-C785-4AAC-88E7-33B44120C366@oracle.com> Message-ID: <4FDFA3C9.4010009@oracle.com> > Another thing is that I don't like putting anything in ~/.javafx if we can avoid it, and certainly not application specific stuff. > Having all application settings, configuration options, etc in the application directory itself is preferable, because it means we never end up with situations where somebody has deleted the application (just dragging the .app to the trash on mac) and then they download the app again and it gets confused with settings we've stored and were never cleared up. > I don't know which way that argues, just that I think we should not store anything outside of the app directory. IMHO, assuming everything is kept in the app folder is too much. Do you know any apps that do this? I believe Sparkle keeps state in the user files but do not remember all details (.plst for preferences?). One problem with it is that saving to /Applications require permission elevation prompt (or running code as admin that does not seem to be justified). We do not should not keep anything confusing there of course. What we need to keep is simple things like - time we checked for update last time, what version was offered to the user last time, etc. We can use current application version as "validity" mark, if what is currently installed is not the same as what we have saved then it means our data are outdated and we need to throw them away. -igor From igor.nekrestyanov at oracle.com Mon Jun 18 15:03:37 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Mon, 18 Jun 2012 15:03:37 -0700 Subject: Auto-update of native application bundles In-Reply-To: <59A93607-DA37-42D8-8F45-F72FCDF1BF36@gmail.com> References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> <4FDE5AB4.2040102@oracle.com> <4FDE646D.3070102@oracle.com> <4FDEB483.5020603@oracle.com> <59A93607-DA37-42D8-8F45-F72FCDF1BF36@gmail.com> Message-ID: <4FDFA5B9.10005@oracle.com> On 6/18/12 4:37 AM, Daniel Zwolenski wrote: > > > One niggling thing for me: how will your solution update itself while it is running? In my POC the new and old versions coexist for a time to get around the file locking issue but in yours there can be only one version. I think to large extent it is the same approach. If we deal with patch or .zip-like archive we build app image elsewhere and then run "swap" utility from new image. "Image" may be cleaned right the way or next time application is launched and AU code will detect image is the same as one we have installed. It update package is actual installer (like msi) then i expect update driver should request application to exit and fork "msiexec" process. Or fork "install utility" that needs to be copied outside of installation folder and can present custom progress dialogs whilst update is installed. > Do you intend for the actual 'installation' to happen outside of the app using a native UI to show progress and success/error message or do you have some other trick in mind to update the jre while it is running? > > Also the 'full' updates could always exclude the JRE if Oracle released JRE zip files that the updater could download from (based on a version specified in the update bundle). I don't suppose there's any chance of legals letting this happen? I do not know answer to this but it seems safer to not depend on something unknown. If we will encounter opportunity to take shortcut in the future we can always take it. -igor > > > On 18/06/2012, at 2:54 PM, Igor Nekrestyanov wrote: > >> On 6/17/12 9:32 PM, Daniel Zwolenski wrote: >>> I think I understand but please clarify any of the below if I got it wrong. >>> >>> Would it be correct to say that the main difference is that in your proposal you are working out the 'delta' update at compile/packaging time, whereas in my solution the app works out the 'delta' at runtime when an upgrade is requested. Assuming this is right, then: >>> >>> Because you are working deltas out at compile time you can bundle the updates into a single image file and avoid having an app-profile. In my solution I need everything extracted on the server with an app-profile so the app can work out the diff in jar versions at runtime. Your solution is definitely nicer on this front. >>> >>> On the other hand, because I work deltas out on the fly I don't need 'delta' image files and any old version can always update to the latest without downloading the full bundle even though no 'delta' file exist. In your solution we have multiple deltas to maintain and the more versions you have the more deltas you have to maintain (or not use deltas, resulting in larger downloads). If a delta is not available for a specific older version, then the app will have to download the full update and install this. >> Yes, process wise this is correct (there are other differences caused by above, e.g. single file, no way you may get components signed by different certs, etc.). >> >> Example is correct too, some size overhead is expected but if we can get bundle size down with better compression methods/etc then difference will be not that big. >> My expectation is that appropriate compression techniques can get size can be down to 25Mb for Ensemble. And once subsetting of JRE will be easier >> (technically and legaly) it could probably get down to 15Mb or so. >> >> Few clarifications on the example: >> >> 1. In step 2 and 3 if all of older versions of app use same JRE then we can use "reduced" version of ful update that updates everything but runtime folder >> This can cut download size if it is an issue >> >> 2. Full image for update may be the same as an app. >> E.g. we are currently installing same .dmg for JRE on Mac and you certainly can do silent installation with .msi >> >> 3. The way to get full app image to compare against is not fixed. >> For example, you can save .zip of 1.0 version when you built 1.0, or install and zip image before you are ready to ship new version, >> or even manually provide list of files to include into update. >> >> 4. Based on feedback i saw from Sparkle users and Oracle's use of AU for JRE keeping lots of delta's is not required. >> Interestingly delta's are often used not to improve user's time to update but to reduce server load. >> >> Another point to consider is that use of single "update package" seem to be the way many other native update systems are implemented >> (based on what i saw, clearly i am not familiar with all of them). >> >> -igor From zonski at googlemail.com Mon Jun 18 15:31:28 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Tue, 19 Jun 2012 08:31:28 +1000 Subject: Auto-update of native application bundles In-Reply-To: <4FDFA5B9.10005@oracle.com> References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> <4FDE5AB4.2040102@oracle.com> <4FDE646D.3070102@oracle.com> <4FDEB483.5020603@oracle.com> <59A93607-DA37-42D8-8F45-F72FCDF1BF36@gmail.com> <4FDFA5B9.10005@oracle.com> Message-ID: On 19/06/2012, at 8:03 AM, Igor Nekrestyanov wrote: > On 6/18/12 4:37 AM, Daniel Zwolenski wrote: >> >> One niggling thing for me: how will your solution update itself while it is running? In my POC the new and old versions coexist for a time to get around the file locking issue but in yours there can be only one version. > I think to large extent it is the same approach. I think not quite as there is a subtle difference. In my POC the new jars are always named differently to the old ones because version number is appended. It's the app-profile that defines the classpath and this can be overridden by the running java (since app-profile is not locked). In your proposal the classpath is based on what is in the 'app' directory, so if v1 and v2 were there at the same time they would both get included on the classpath. The result is that in my POC the new jars can be copied in while the old app is running, whereas in yours it can't. So in my POC the java GUI can show progress and success/error, whereas in yours the java GUI will have to be killed before the copy starts so the progress and success/error will have to be shown in a hard coded native UI. It would be nicer to allow the developer to customize in Java (eg for web page upgrade the native dialog would not work). Your solution could be extended to work like mine with coexisting versions if we wanted - but I think there would have to be some local file defining the jre path and classpath (eg extend the .pkg file and make it more like the app-profile) so that both versions could coexist at the same time. Of course this does open up the problem I have of when to clean the old version (on next start seems the logical choice but then it will need elevated UAC). It's an area I think needs further exploration in both proposals. From igor.nekrestyanov at oracle.com Mon Jun 18 15:58:22 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Mon, 18 Jun 2012 15:58:22 -0700 Subject: Auto-update of native application bundles In-Reply-To: References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> <4FDE5AB4.2040102@oracle.com> <4FDE646D.3070102@oracle.com> <4FDEB483.5020603@oracle.com> <59A93607-DA37-42D8-8F45-F72FCDF1BF36@gmail.com> <4FDFA5B9.10005@oracle.com> Message-ID: <4FDFB28E.9090103@oracle.com> On 6/18/12 3:31 PM, Daniel Zwolenski wrote: > In your proposal the classpath is based on what is in the 'app' directory, so if v1 and v2 were there at the same time they would both get included on the classpath. It is embedded java launcher that is part of main jar that decides what needs to be taken. Not everything in the app folder is used. Anyway, here is one possible scenario (it may be somewhat different depending on update type): 1. Application is running, update detected 2. Update is loaded in background, no UI is shown 3. Full application image is built in the temp folder (including runtime, etc.) 4. User is prompted to update and relaunch 5. If he agrees: - application exits - (optionally) UAC is shown for "swap" program - "swap" program renames existing app folder - moves new image in place of old app - launches new version of application - then cleanup old image "move" is fast operation as long as we are on the same drive. No or little UI is needed ("rename" will take 1-2 seconds at most?). And if it is needed then in most of cases default UI should suffice. It is possible to make it more complex and allow to customize this part of UI but would be good to see if there is a need to do this. E.g. we can put another app folder in the application directory and have package.cfg to mention which one is active. > The result is that in my POC the new jars can be copied in while the old app is running, whereas in yours it can't. So in my POC the java GUI can show progress and success/error, whereas in yours the java GUI will have to be killed before the copy starts so the progress and success/error will have to be shown in a hard coded native UI. So, what if update need to update java.exe or and of dlls or Application.exe? Have a different UI? How do you elevate permissions to be able to copy files to Program Files? Does it mean user application will run with full admin permissions? -igor From zonski at googlemail.com Mon Jun 18 16:54:28 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Tue, 19 Jun 2012 09:54:28 +1000 Subject: Auto-update of native application bundles In-Reply-To: <4FDFB28E.9090103@oracle.com> References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> <4FDE5AB4.2040102@oracle.com> <4FDE646D.3070102@oracle.com> <4FDEB483.5020603@oracle.com> <59A93607-DA37-42D8-8F45-F72FCDF1BF36@gmail.com> <4FDFA5B9.10005@oracle.com> <4FDFB28E.9090103@oracle.com> Message-ID: <13AA97A7-300B-4AA8-94D1-1D99EC143FE7@gmail.com> Yes, the scenario you described is how I imagined it. The drawback is that the 'swap' progress and success/failure dialogs are native, whereas in mine it's java. As you say if it is just a move then it is relatively quick and can be trivial (although there might also be need to update registry with latest version and uninstall info, and delete old files, especially for delta updates, so error possibilities increase). I'm not necessarily sold on one solution on this front, just making sure we're aware of trade offs when we choose. Agree that we need feedback on whether we care about native dialogs here or not. Note in mine I also version jre, so jre is in 'jre/jre6' and upgraded jre is in 'jre/jre7'. So they coexist too. Similar approach would be used for native libs. One side benefit of my approach is that if the launcher fails to start after upgrade it could give the user the option to launch using previous app-profile. More a side benefit than intended feature and I reckon your solution could be extended to have something similar if we thought it necessary. Regarding how I elevate permissions, I have already something like your 'swap' program. It is launched from Java as a new process requesting elevated privileges (but the java can stay alive and monitor it for results). Only the swap process is elevated, normal app stays at normal user level. Note that this program could be smarter and only try to elevate if needed, so if, for example the user chose to install outside of Program Files they wouldn't get UAC prompt to upgrade, it would just work. Your swap program can be coded the same way - I found code on the web for all this, and will dig it up when we need it. Definitely can be done though. On 19/06/2012, at 8:58 AM, Igor Nekrestyanov wrote: > On 6/18/12 3:31 PM, Daniel Zwolenski wrote: > > > In your proposal the classpath is based on what is in the 'app' directory, so if v1 and v2 were there at the same time they would both get included on the classpath. > > It is embedded java launcher that is part of main jar that decides what needs to be taken. > Not everything in the app folder is used. > > Anyway, here is one possible scenario (it may be somewhat different depending on update type): > > 1. Application is running, update detected > 2. Update is loaded in background, no UI is shown > 3. Full application image is built in the temp folder (including runtime, etc.) > 4. User is prompted to update and relaunch > 5. If he agrees: > - application exits > - (optionally) UAC is shown for "swap" program > - "swap" program renames existing app folder > - moves new image in place of old app > - launches new version of application > - then cleanup old image > > "move" is fast operation as long as we are on the same drive. No or little UI is needed ("rename" will take 1-2 seconds at most?). > And if it is needed then in most of cases default UI should suffice. > > It is possible to make it more complex and allow to customize this part of UI but would be good to see if there is a need to do this. > E.g. we can put another app folder in the application directory and have package.cfg to mention which one is active. > > > The result is that in my POC the new jars can be copied in while the old app is running, whereas in yours it can't. So in my POC the java GUI can show progress and success/error, whereas in yours the java GUI will have to be killed before the copy starts so the progress and success/error will have to be shown in a hard coded native UI. > > So, what if update need to update java.exe or and of dlls or Application.exe? > Have a different UI? > > How do you elevate permissions to be able to copy files to Program Files? > Does it mean user application will run with full admin permissions? > > -igor > From hang.vo at oracle.com Mon Jun 18 17:04:49 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Jun 2012 00:04:49 +0000 Subject: hg: openjfx/2.2/controls/rt: Ignore broken charts units tests. Message-ID: <20120619000453.CC1E5479D1@hg.openjdk.java.net> Changeset: bdbc42e5a633 Author: Kinsley Wong Date: 2012-06-18 16:54 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/bdbc42e5a633 Ignore broken charts units tests. ! javafx-ui-charts/test/javafx/scene/chart/StackedAreaChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/StackedBarChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/XYChartTest.java From hang.vo at oracle.com Mon Jun 18 17:34:45 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Jun 2012 00:34:45 +0000 Subject: hg: openjfx/2.2/controls/rt: Reapply fix for RT-21906 so we can further debug this issue. Message-ID: <20120619003446.64EDE479D2@hg.openjdk.java.net> Changeset: 55cb5954521b Author: Kinsley Wong Date: 2012-06-18 17:26 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/55cb5954521b Reapply fix for RT-21906 so we can further debug this issue. ! javafx-ui-common/src/com/sun/javafx/css/CascadingStyle.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java From hang.vo at oracle.com Mon Jun 18 18:34:00 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Jun 2012 01:34:00 +0000 Subject: hg: openjfx/2.2/controls/rt: 2 new changesets Message-ID: <20120619013406.4A837479D9@hg.openjdk.java.net> Changeset: d5d7c3a4b94d Author: jgiles Date: 2012-06-19 11:02 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/d5d7c3a4b94d RT-22645: ClassCastException (Controls Regression) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 4849a03007c5 Author: jgiles Date: 2012-06-19 13:24 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/4849a03007c5 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt From zonski at googlemail.com Mon Jun 18 22:02:38 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Tue, 19 Jun 2012 15:02:38 +1000 Subject: Confused about status of JFX+JRE cobundling Message-ID: Hey guys, I'm a little confused about the status of JRE+JFX co-bundling at the moment. In an earlier mail Michael Paus implied that he tentatively believed JFX was now co-bundled in the JRE but I thought this wasn't happening until Java8? Richard also confirmed that releases are now in synch, which I assume a result of co-bundling as well. When I install JDK-7u5 it installs JFX-2.1 but separate to the main JRE install. i.e. the installer contains both packages but they are not installed as a single runtime (which is what I would expect with 'co-bundling'). When I download and install JRE-7u5 it doesn't seem to contain any JFX classes at all? In the JRE that was extracted via Igor's Ensemble installer the JRE does seem to include JFX in exactly the way I would expect it if it were co-bundled (i.e. the jfxrt.jar and DLLs are all inside the JRE directory). Can you guys clear up for me where we are officially at with the co-bundling? Am I just being dumb and not seeing the JARs in my JRE install, or has co-bundling not happened yet - if not, why not: can't the JRE just have the JRE files in it the way Igor has done? Why would our local development versions not have it combined when our deployed versions do? Cheers, Dan From igor.nekrestyanov at oracle.com Mon Jun 18 22:14:00 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Mon, 18 Jun 2012 22:14:00 -0700 Subject: Confused about status of JFX+JRE cobundling In-Reply-To: References: Message-ID: <4FE00A98.1070307@oracle.com> short answer - try 7u6 (http://jdk7.java.net/download.html) longer version: * Staring 7u4 JDK for Mac included JavaFX SDK as "true" cobundle (i.e. one where JavaFX files are part of same bundle and there is no separate installer) * Starting JRE/JDK 7u6 JavaFX will be shipped as true cobundle on all platforms (JavaFX platforms, i.e. no Solaris). And "true" cobundle means: * there is one installer to install JRE * it will installs set of core JRE and JavaFX files into the same folder * There will be one entry in the Program Files for JRE * JavaFX files are subject to autoupdate as part of JRE installation (same is true for JDK and JavaFX SDK) Caveats: * JavaFX is not official part of the Java platform yet (i.e. JavaFX APIs are not part of Java specification). This is what was planned to happen for Java 8 * In 7u6 JavaFX will not be automatically added to classpath (neither for javac not java launcher). * There still will be standalone JavaFX installer for JavaFX 2.2 - it is only intended to be used with JRE 6 and only for windows. No cobundle for Java 6. hope this helps, -igor On 6/18/12 10:02 PM, Daniel Zwolenski wrote: > Hey guys, > > I'm a little confused about the status of JRE+JFX co-bundling at the > moment. In an earlier mail Michael Paus implied that > he tentatively believed JFX was now co-bundled in the JRE but I thought > this wasn't happening until Java8? Richard also confirmed that releases are > now in synch, which I assume a result of co-bundling as well. > > When I install JDK-7u5 it installs JFX-2.1 but separate to the main JRE > install. i.e. the installer contains both packages but they are not > installed as a single runtime (which is what I would expect with > 'co-bundling'). > > When I download and install JRE-7u5 it doesn't seem to contain any JFX > classes at all? > > In the JRE that was extracted via Igor's Ensemble installer the JRE does > seem to include JFX in exactly the way I would expect it if it were > co-bundled (i.e. the jfxrt.jar and DLLs are all inside the JRE directory). > > Can you guys clear up for me where we are officially at with the > co-bundling? Am I just being dumb and not seeing the JARs in my JRE > install, or has co-bundling not happened yet - if not, why not: can't the > JRE just have the JRE files in it the way Igor has done? Why would our > local development versions not have it combined when our deployed versions > do? > > Cheers, > Dan From zonski at googlemail.com Mon Jun 18 22:23:33 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Tue, 19 Jun 2012 15:23:33 +1000 Subject: Confused about status of JFX+JRE cobundling In-Reply-To: <4FE00A98.1070307@oracle.com> References: <4FE00A98.1070307@oracle.com> Message-ID: Yep, that clears things up, thanks! * In 7u6 JavaFX will not be automatically added to classpath (neither for > javac not java launcher). > I don't understand this though. Why is it not added, and what advantage is there at all to co-bundling if JFX is not on the classpath? From igor.nekrestyanov at oracle.com Mon Jun 18 22:30:41 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Mon, 18 Jun 2012 22:30:41 -0700 Subject: Confused about status of JFX+JRE cobundling In-Reply-To: References: <4FE00A98.1070307@oracle.com> Message-ID: <4FE00E81.60201@oracle.com> On 6/18/12 10:23 PM, Daniel Zwolenski wrote: > Yep, that clears things up, thanks! > > * In 7u6 JavaFX will not be automatically added to classpath > (neither for javac not java launcher). > > > I don't understand this though. Why is it not added, and what > advantage is there at all to co-bundling if JFX is not on the classpath? This is current limitation. It had been discussed for a while and various concerns had been raised as this impacts all existing apps and not just javafx apps (security, compatibility, etc.). Hopefully this will be addressed in one of future releases. This is not the only jar in the JRE that is not on the bootclasspath. E.g. none of deployment jars are ... To me biggest benefits are: * JavaFX effectively be preinstalled on most of the systems that have Java * No separate installation => fewer problems due to installer bugs && issues caused by Java/JavaFX mix&match * SDK is bundled => much easier for IDEs to support JavaFX development * Easier to build native bundles -- in the current implementation runtime is defined by JDK being used * no need in separate Maven module for JavaFX :) List is not complete, these are just few top of my head and seems important to me, -igor From jmartine_1026 at yahoo.com Mon Jun 18 22:52:57 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Mon, 18 Jun 2012 22:52:57 -0700 (PDT) Subject: Confused about status of JFX+JRE cobundling In-Reply-To: <4FE00E81.60201@oracle.com> References: <4FE00A98.1070307@oracle.com> <4FE00E81.60201@oracle.com> Message-ID: <1340085177.39485.YahooMailNeo@web160902.mail.bf1.yahoo.com> Igor, Yes I think there are more benefits with cobundle. ?It was great how the JFX 1.3 version of my app worked on everyone's computer because they had Java 6. ?Looking forward to same for JFX 2.2. 2 questions about dates... Do you know when Java 7 will be released to all the Java Updaters (specifically the the Java 6 versions, as I noticed that my Java Update was pulling down Java 7 updates but my friends was still pulling down Java 6)? Same question for JFX 2.2? I want to get a feel for when I can expect JFX 2.2 to be installed on the majority of my potential customers. thanks jose ________________________________ From: Igor Nekrestyanov To: Daniel Zwolenski Cc: openjfx-dev at openjdk.java.net Sent: Tuesday, June 19, 2012 1:30 AM Subject: Re: Confused about status of JFX+JRE cobundling On 6/18/12 10:23 PM, Daniel Zwolenski wrote: > Yep, that clears things up, thanks! > >? ? ? * In 7u6 JavaFX will not be automatically added to classpath >? ? (neither for javac not java launcher). > > > I don't understand this though. Why is it not added, and what advantage is there at all to co-bundling if JFX is not on the classpath? This is current limitation. It had been discussed for a while and various concerns had been raised as this impacts all existing apps and not just javafx apps (security, compatibility, etc.). Hopefully this will be addressed in one of future releases. This is not the only jar in the JRE that is not on the bootclasspath. E.g. none of deployment jars are ... To me biggest benefits are: ? * JavaFX effectively be preinstalled on most of the systems that have Java ? * No separate installation => fewer problems due to installer bugs && issues caused by Java/JavaFX mix&match ? * SDK is bundled => much easier for IDEs to support JavaFX development ? * Easier to build native bundles -- in the current implementation runtime is defined by JDK being used ? * no need in separate Maven module for JavaFX :) List is not complete, these are just few top of my head and seems important to me, -igor From tobi at ultramixer.com Tue Jun 19 00:06:48 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Tue, 19 Jun 2012 09:06:48 +0200 Subject: Auto-update of native application bundles In-Reply-To: <4FDE5AB4.2040102@oracle.com> References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> <4FDE5AB4.2040102@oracle.com> Message-ID: <761E36A5-CB27-417F-9218-E61DE4B1FF97@ultramixer.com> From Apples point of view it's only allowed to save any app specific preferences in ~/Library/Application Support/ Best regards, Tobi Am 18.06.2012 um 00:31 schrieb Igor Nekrestyanov : > Hi, >> >> * In your proposal the "app-cast" system is used, where each update >> is released as a patch (i.e. the 'diff') to get from one version >> to the next. If an app was out in the wild running at version 2, >> and the latest release was actually version 5, then to upgrade we >> would download the v2->v3 patch, install it, then the v3->v4 patch >> install it, and then the v4->v5 patch and install that (correct me >> if I got this wrong). >> > Sparkle appcast is simply update descriptor (kind of RSS) wth news about update availability. > It is unrelated to the way update is shipped. > > Moreover but default update is full image of application and can be installed on top of any version. > Developer may choose to have delta updates if he wants to optimize but he is not required too. > We are using Sparkle to AU JRE on Mac and it works fine. >> >> * In my POC I've gone for the "app-profile" approach, which >> basically defines the latest release of the system in it's >> entirety. It's up to each app out there to determine what has >> changed between it's version and the latest version and download >> what it needs (i.e. the 'diff'). To go from version 2 to version >> 5, the app would compare the version of the JARs in its own >> app-profile against the new one, and download the ones that have >> changed. There is no download of the 'in-between' versions of 3 >> and 4. >> > Sparkle approach does not assume this either. > Update description must have full image. If there is (optional) delta image it is used but otherwise full image is used. > > IMHO, the biggest differences between appcast xml and app-profile.xml are: > * appcast is strictly update descriptor and app-profile.xml is application descriptor + versioning info > * app-profile.xml corresponds to subset of "item" element in the appcast > * appcast xml may have multiple items - e.g. define application updates for different platforms or several apps > * item in the appcast describes UPDATE, not application. Application is kind of blackbox and this is good. > I.e. no knowledge of classpath or specific directory structure. Only what driver knows how to apply update. > * item has update specific information, e.g. may include release notes that can be used to justify why to upgrade. > > It does not mean we can not use efficient compression (e.g. pack200 for jars) or update parts of app package (e.g. leave alone Java runtime). > This is up for driver implementation. > > And another important difference is simplier model in Sparkle: > * ONE version to check (whats available vs update version in appcast) > [no need to check every jar, resource file, etc] > * ONE file with update to sign and stage (less hassle for developer) > [instead of every jar, fewer chance to have staging error (not all files are uploaded, etc)] > * ONE file to download > [less chance to have mixed state, e.g. developer may decide to restage/resign app with same version but some jars are already loaded] > > JNLP model is ok but it tries to solve "remote launch" problem and here we are solving other task. > > IMHO, if we separate launch descriptor and update descriptor we will have better model for this problem. >> >> It was with this type of usage in mind that I ended up leaning towards the app-profile approach. I imagined my initial upload to my server would be all the JARs for my app, and then when I release subsequent versions I only upload the couple of JARs that have changed and upload the new app-profile.xml (and the build tools could potentially do the upload as well and they would know which jars had changed). > Essentially you are implementing specific kind of "delta update". > Except you can dynamically define what delta is needed for arbitrary initial state. > > In sparkle model specifics of delta update are up to the update driver that knows what to do with update package. > We can support update packages that only update "important" subset of jars, etc. > > For background type of updates size is often not an issue at all (although there are scenarios where it needs to be optimized). > > Anyway, with "update driver" plugins we can extend set of delta updates supported as needed. > >> The flip side of this is that you couldn't choose to go to an in-between version if you wanted to, but I'm not sure that's an overly valid use case? > Agree, this is not important use case. > But you may have "different" latest versions - one for XP and another for Vista and another for Mac. >> >> With this approach we also have the option of providing a "repair" function. So a client could run a utility to just completely download the entire app and get fresh copies of all the JARs. This is not critical but it could be quite useful. With the app-cast approach, you have to uninstall and then reinstall with your original MSI and then patch (or install with the new MSI) - the uninstall may delete your 'appdata' though, whereas a "repair" could leave this intact. > IMHO, repair by reinstalling still needs to be supported and existing mechanisms (like MSI or rpm) have means to do this. > It does not seem as critical requirements for AU module. >> >> One other niggling thing for me is how to do things like system properties or VM settings (like -Xmx) without an app-profile. Currently you would be hard coding those into your 'exe' I imagine? So if an update wanted to change these things it would have to recompile the launcher exe and that would have to be part of the 'patch'? > Bundled app has application descriptor/config file. It is called package.cfg and very simple now. > It may and need to be improved to pass in things like JVM options. > > In fact launcher is fixed, it is not compiled per app. > It is embedded into ant task and simply renamed when application bundle is generated. > All variable parameters are coming from package.cfg >> There'd be no easy (possible?) way for the user to change these settings on their machine, not sure if that's a good thing or a bad thing though? > Well, if we need it (it is questionable) then user may tweak package.cfg directly (imho, bad idea. especially if it is system wide) or we could have > some abstraction of "config" API and application may update its settings per user. But this is unrelated to AU. > User settings should be left intact after AU. Default app settings are part of application descriptor. So i think we are good with this. >> >> And finally one other edge use case I thought of today: it's not uncommon to have several 'apps' included in the one install. For example you might have a user UI and an admin UI. In Java-land, these would ideally share the same libraries but have different 'main' classes. I was thinking the app-profile approach could potentially be extended to cover this but it needs more thinking about, and may just be an unsupported use case. Not sure how/if the app-cast approach could handle this if we said it was a requirement. > It does not seem hard to me. > > Key question here -- are they shipped as separate installs or one bundle with multiple launchers. > If they are separate installs they are updated separately and there should be application specific means to ensure they are consistent > (because user may simply install incompatible versions to start with). Application specific solution may use AU APIs to force autoupdate > if user tries to launch app that is compatible with others. > > If they are shipped as one bundle then nothing special to be done by AU. AU will update folder with multiple launchers easily as they are just files for AU module. > It is different story how to bundle msi/exe/dmg for this scenario but this is separate from AU discussion, > > -igor >> >> Cheers, >> Dan >> >> >> On Sun, Jun 17, 2012 at 5:26 PM, Igor Nekrestyanov > wrote: >> >> Hi Dan, >> >> thanks for the great writeup (and pushing this ahead). >> I finally started to look into this more actively. Some >> questions/suggestions below. >> >> On 6/15/12 5:02 PM, Daniel Zwolenski wrote: >> >> *The General Approach* >> >> Richard made reference to >> Sparkle and >> >> like him, I feel this is a nice reference point for the style >> of solution >> we want. The neat thing that Sparkle does is it provides an >> API that >> developers can use inside their code to completely control and >> customise >> the upgrade of their application. This is the approach I've >> gone for as >> well. My POC includes a Java API that you can call to check >> for updates and >> trigger downloads. >> >> IMHO, main great thing about Sparkle is that it is easy to add >> basic AU functionality to the application >> (see https://github.com/andymatuschak/Sparkle/wiki) >> You do not need to use API unless you want custom solution. >> >> Therefore i am not focusing here on the public API part (keeping >> this for later). >> >> >> I think this approach is neat and powerful, but it's worth >> mentioning that >> there is still some debate amongst the JFX team about whether >> to go down >> this road or avoid the Java API and use off-the-shelf native >> updaters. Your >> input will very likely influence this decision so if you have >> a preference >> one way or the other (or have other suggestions), be vocal. >> >> >> I think there is no debate on that having some "all in java with >> minimal native code solution" is good idea. >> Debate is about whether it should be the only option or it also >> make sense to support other native update mechanisms >> (e.g. use Sparkle directly on Mac). >> >> As Dan said, thoughts on this are very welcome. >> >> >> >> An XML deployment descriptor, called 'app-profile.xml' is used >> to describe >> the JARs, JRE versions and other launch details - it is >> semantically >> comparable to a traditional JNLP file. When an update is >> triggered via the >> API, the code checks the remote URL for an updated >> app-profile.xml. If it >> finds one it downloads this and checks this with its local >> app-profile.xml. >> Any jars that have different version numbers are downloaded, >> and if a new >> JRE version is defined in the app-profile then the zip for this is >> downloaded and extracted as well. >> >> Where these files are placed after download? >> >> Once all the downloading is complete, the >> local app-profile is then overwritten with the newer one and >> this newer one >> will be used by the native launcher to set the classpath next >> time the app >> is started. >> >> >> IMHO, we can simplify this model following Sparkle ideas. >> Sparkle does not know anything about application structure, etc. >> and focus only on update process. >> This makes it easy to use, simple and robust as it focuses on >> solves one problem. >> >> Important points are: >> A. Sparkle uses "appcast" to describe what updates are available >> (https://github.com/andymatuschak/Sparkle/wiki/publishing-an-update) >> Appcast includes >> - version of updates available >> - meta info about each update (type of update (e.g. >> regular or mandatory security), release notes, system requirements >> (e.g. Windows version 7+), etc.) >> - set of available update packages (aka enclosures) (e.g. >> full app image, delta patches for several versions, etc.) >> >> B. Sparkle knows where to look for update meta info in the >> application package (on Mac it is part of Info.plist that is some >> kind of application manifest). >> However, it only needs to know: >> - URL of appcast >> - location of key to verify update signatures >> - application update settings/preferences >> The expectation is that once app is updated this info will >> be updated (as it is part of "update package") >> [Note: this is not so simple on Windows if we want to make >> sure we are good citizens and need to update registry] >> >> C. Update package is black box for Sparkle core. >> It is modeled as >> - file hosted at given URL >> - signed with given key (signature is part of appcast) >> - package type defines what "update driver" will be >> handling this update >> (this allows to add support for various update >> packages as plugins/modules) >> - for most type for packages (except running installers) >> Sparkle goal is to update set of application files only >> [Windows or linux require more work as we may need to >> update registry or package info] >> >> D. If admin permissions are needed they only asked before update >> is finally installed. >> Sparkle does not keep any internal state in the app folder >> as it may be only writable for admins. >> >> E. Application relaunch after update >> >> This is close to your approach but there are some important >> differences. >> Following Sparkle more closely may simplify things and at the same >> time add some desired features >> (e.g. ability to validate origin of autoupdate) >> >> My current thoughts on "ideal" basic experience are as follows. >> >> ======== >> Developer experience (no java coding needed): >> >> 1. At the package time developer requests autoupdate support in >> the native cobundle by providing: >> * http URL to appcast + public key/cert to validate update >> signatures >> * or https url >> and define application update mode (mandatory update, ask user >> and allow him to skip version, etc.) >> >> 2. Once update is needed developer creates "update package" >> (single file). >> For this he will need to run same packager utility/ant task but >> specify base image, certificate to sign package and >> and desired type of update (full or incremental) >> >> 3. Developer need to create an appcast xml file (default can be >> generated in step 2 but he may want to customize it) >> >> 4. Developer stages both appcast and package bundle >> ========= >> >> End user (background updates): >> * installs application with background update policy >> * every time application is launched it will check appcast (if >> online) >> * if update is detected it will be loaded silently while app is >> running >> * Once update is loaded and verified user will be prompted to >> install it (it may be notification if update is mandatory) >> * If he agrees then he may see UAC dialog (unless installation >> is on per user basis) >> * application relaunch after update >> * attempt to launch app being updated should fail with >> reasonable dialog and should not fail update process (it may need >> to wait will .exe is unlocked) >> ========= >> >> Implementation wise i was thinking along the lines of what you >> have (only glimpsed though your code it though) with following >> notable differences: >> >> * update package is single file and we only worry about it version. >> No need to worry about version of individual components as we >> do not want arbitrary mix&match. >> >> * updates are loaded to ~/.javafx/app-key (where app-key could >> be derivation from app install location) >> We also keep user answers for this app in that folder (e.g. >> had we offered him this version already? when was last time we >> checked for update, etc) >> >> * Update process is: >> - build temp full app image in the ~/.javafx/app-key/version >> - if update accepted then exit application and run helper >> app co copy image over >> - possibly run "post upgrade script" as part of helper app >> (this script is specific to "bundler" technology used. >> E.g. for EXE/MSI bundlers we may want to update few keys in registry >> - relaunch app >> - AU module running in the relaunched app could detect temp >> "image" that is the same as current version and erase it >> >> Note that there could be several alternative helper apps. >> E.g. one that pops UAC and one that does not for per user installs. >> Or helper up to install update packaged as MSI (by running >> msiexec silently and showing progress) >> >> I was even thinking that "helper" can be implemented in java >> with minimal native code (to elevate permissions and update >> registry if needed). >> >> * Integration with application bundle >> - details on whether AU is needed and what type is it may be >> embedded application manifest for main app jar >> - embedded jauncher will read them and use internal AU APIs >> accordingly >> (this is why no user code changes are needed) >> - current app version, update url and signature are part of >> package.cfg or manifest in the main app jar >> - AU support itself is part of jfxrt.jar, bundle also >> includes helper app to "move image into final location" and >> script to do "post update config" >> >> What do you think? >> >> -igor >> >> > From tom.schindl at bestsolution.at Tue Jun 19 00:15:58 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 19 Jun 2012 09:15:58 +0200 Subject: Confused about status of JFX+JRE cobundling In-Reply-To: <4FE00E81.60201@oracle.com> References: <4FE00A98.1070307@oracle.com> <4FE00E81.60201@oracle.com> Message-ID: <4FE0272E.4000301@bestsolution.at> While there are benefits there are also drawbacks: * JavaFX release schedule has to be tightly aligned with JDK which means JavaFX has not much freedom anymore * the unbalanced decision to not provide SDK-Drops as zips makes repackaging for different platforms complex * the not shipping of sources nor javadoc with JDK cobundle is an even bigger problem than locating javafx in dedicated locations or give the IDE user a configuration option to locate it on the filesystem => don't develop JavaFX applications if you are behind a firewall, proxy, train ride... which doesn't give you webaccess oracle.com have a "fun time" developing JavaFX apps and will blame their freaking IDE does not give them appropriate proposals => will be fixed with JDK-8 / JavaFX 3.0 (see other thread I started yesterday) but seriously do we really think this is a wise decision? * there is now a missmatch between those not wanting to install a JDK update and use the JavaFX-SDK because native packaging with fx:deploy task is not working for them. Is it really such a big problem to find out java.home for the ant-task and packaging this up? Just asking Most of those drawbacks are a result of this co-bundle is the future but somehow people forget about the present. You are trading your current developer experience against the one of the future. Tom Am 19.06.12 07:30, schrieb Igor Nekrestyanov: > On 6/18/12 10:23 PM, Daniel Zwolenski wrote: >> Yep, that clears things up, thanks! >> >> * In 7u6 JavaFX will not be automatically added to classpath >> (neither for javac not java launcher). >> >> >> I don't understand this though. Why is it not added, and what >> advantage is there at all to co-bundling if JFX is not on the classpath? > This is current limitation. > It had been discussed for a while and various concerns had been raised > as this impacts all existing apps and not just javafx apps > (security, compatibility, etc.). Hopefully this will be addressed in one > of future releases. > > This is not the only jar in the JRE that is not on the bootclasspath. > E.g. none of deployment jars are ... > > To me biggest benefits are: > * JavaFX effectively be preinstalled on most of the systems that have > Java > * No separate installation => fewer problems due to installer bugs && > issues caused by Java/JavaFX mix&match > * SDK is bundled => much easier for IDEs to support JavaFX development > * Easier to build native bundles -- in the current implementation > runtime is defined by JDK being used > * no need in separate Maven module for JavaFX :) > > List is not complete, these are just few top of my head and seems > important to me, > > -igor > > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From igor.nekrestyanov at oracle.com Tue Jun 19 00:37:25 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Tue, 19 Jun 2012 00:37:25 -0700 Subject: Confused about status of JFX+JRE cobundling In-Reply-To: <4FE0272E.4000301@bestsolution.at> References: <4FE00A98.1070307@oracle.com> <4FE00E81.60201@oracle.com> <4FE0272E.4000301@bestsolution.at> Message-ID: <4FE02C35.3040203@oracle.com> On 6/19/12 12:15 AM, Tom Schindl wrote: > * the unbalanced decision to not provide SDK-Drops as zips makes > repackaging for different platforms complex What other platforms you are referring to? Other Linux distros? > there is now a missmatch between those not wanting to install a JDK update and use the JavaFX-SDK because native packaging with fx:deploy task is not working for them. What is the problem with having multiple versions of JDK on the system? Unlike runtime these are fully independent ... > Is it really such a big problem to find out java.home for the ant-task and packaging this up? Just asking Current native packaging support makes a lot of simplifying assumptions on bundle configuration as we do not want to expose too many APIs in a rush (and we likely will provide more flexible APIs in a future for use cases that will be popular). Decision to use current JDK cobundle as a source for native bundle is one of these simplifications. It was not motivation for cobundling Java and JavaFX in JDK, it is another way - because JDK is true cobundle we had option to simplify things. -igor From omurata at ga2.so-net.ne.jp Tue Jun 19 00:43:12 2012 From: omurata at ga2.so-net.ne.jp (Tadashi Ohmura) Date: Tue, 19 Jun 2012 16:43:12 +0900 Subject: Confused about status of JFX+JRE cobundling In-Reply-To: <4FE00A98.1070307@oracle.com> References: <4FE00A98.1070307@oracle.com> Message-ID: <4FE02D90.6020702@ga2.so-net.ne.jp> Thank you, Igor Nekrestyanov I get helps for your comment. I wondered that why not jfxrt.jar is out of classpath while JFX's DLLs are installed in jre/bin I can get answer from you. Thanks Tadashi Ohmura (2012/06/19 14:14), Igor Nekrestyanov wrote: > short answer - try 7u6 (http://jdk7.java.net/download.html) > > longer version: > * Staring 7u4 JDK for Mac included JavaFX SDK as "true" cobundle > (i.e. one where JavaFX files are part of same bundle and there > is no separate installer) > * Starting JRE/JDK 7u6 JavaFX will be shipped as true cobundle on > all platforms > (JavaFX platforms, i.e. no Solaris). > > And "true" cobundle means: > * there is one installer to install JRE > * it will installs set of core JRE and JavaFX files into the same > folder > * There will be one entry in the Program Files for JRE > * JavaFX files are subject to autoupdate as part of JRE installation > (same is true for JDK and JavaFX SDK) > > Caveats: > * JavaFX is not official part of the Java platform yet (i.e. JavaFX > APIs are not part of Java specification). > This is what was planned to happen for Java 8 > * In 7u6 JavaFX will not be automatically added to classpath > (neither for javac not java launcher). > * There still will be standalone JavaFX installer for JavaFX 2.2 - > it is only intended to be used with JRE 6 and only for windows. > No cobundle for Java 6. > > hope this helps, > From tom.schindl at bestsolution.at Tue Jun 19 00:49:32 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 19 Jun 2012 09:49:32 +0200 Subject: Confused about status of JFX+JRE cobundling In-Reply-To: <4FE02C35.3040203@oracle.com> References: <4FE00A98.1070307@oracle.com> <4FE00E81.60201@oracle.com> <4FE0272E.4000301@bestsolution.at> <4FE02C35.3040203@oracle.com> Message-ID: <4FE02F0C.1080402@bestsolution.at> Am 19.06.12 09:37, schrieb Igor Nekrestyanov: > On 6/19/12 12:15 AM, Tom Schindl wrote: >> * the unbalanced decision to not provide SDK-Drops as zips makes >> repackaging for different platforms complex > What other platforms you are referring to? Other Linux distros? No I'm talking about windows and mac. Say I'm a win32 user and want to package an application for users on mac and win32. How would you advise to do so? Answer: Buy a Mac because you don't get access to JavaFX jar and native libs without out it! > >> there is now a missmatch between those not wanting to install a JDK > update and use the JavaFX-SDK because native packaging with fx:deploy > task is not working for them. > > What is the problem with having multiple versions of JDK on the system? > Unlike runtime these are fully independent ... > JavaFX previews are shipped on a very regular base so now with the co-bundleing I'm downloading the whole JDK all the time although I'm only interested in the latest JavaFX. >> Is it really such a big problem to find out java.home for the ant-task > and packaging this up? Just asking > > Current native packaging support makes a lot of simplifying assumptions > on bundle configuration as we do not want to expose too many APIs in a rush > (and we likely will provide more flexible APIs in a future for use cases > that will be popular). > Decision to use current JDK cobundle as a source for native bundle is > one of these simplifications. It was not motivation for cobundling Java > and JavaFX in JDK, > it is another way - because JDK is true cobundle we had option to > simplify things. > > -igor Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From tom.schindl at bestsolution.at Tue Jun 19 01:38:24 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 19 Jun 2012 10:38:24 +0200 Subject: CSS-Documentation for IDE-Usage Message-ID: <4FE03A80.4040700@bestsolution.at> Hi, Is there some structured text document one can use to teach IDEs hover documentation of CSS-Attribute, or do I need to extract those information from the published HTML-CSS-Documentation? My hope is that this document is generated from some more structured resource I can use in my Eclipse integration. If there's no such document, I'd like to contribute in creating such a meta-format and generate the HTML-Document from it. Any netbeans people here who'd like to work with me on this? Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From artem.ananiev at oracle.com Tue Jun 19 01:54:49 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 19 Jun 2012 12:54:49 +0400 Subject: Confused about status of JFX+JRE cobundling In-Reply-To: <4FE00A98.1070307@oracle.com> References: <4FE00A98.1070307@oracle.com> Message-ID: <4FE03E59.20507@oracle.com> On 6/19/2012 9:14 AM, Igor Nekrestyanov wrote: > short answer - try 7u6 (http://jdk7.java.net/download.html) > > longer version: > * Staring 7u4 JDK for Mac included JavaFX SDK as "true" cobundle > (i.e. one where JavaFX files are part of same bundle and there is no > separate installer) > * Starting JRE/JDK 7u6 JavaFX will be shipped as true cobundle on all > platforms > (JavaFX platforms, i.e. no Solaris). > > And "true" cobundle means: > * there is one installer to install JRE > * it will installs set of core JRE and JavaFX files into the same folder > * There will be one entry in the Program Files for JRE > * JavaFX files are subject to autoupdate as part of JRE installation > (same is true for JDK and JavaFX SDK) > > Caveats: > * JavaFX is not official part of the Java platform yet (i.e. JavaFX APIs > are not part of Java specification). > This is what was planned to happen for Java 8 > * In 7u6 JavaFX will not be automatically added to classpath (neither > for javac not java launcher). It effectively makes it impossible to distribute JavaFX apps as executable jars. Not a big deal, but it's something that works for Swing apps, so it would be quite expected to have the same model for FX... Thanks, Artem > * There still will be standalone JavaFX installer for JavaFX 2.2 - it is > only intended to be used with JRE 6 and only for windows. > No cobundle for Java 6. > > hope this helps, > > -igor > > On 6/18/12 10:02 PM, Daniel Zwolenski wrote: >> Hey guys, >> >> I'm a little confused about the status of JRE+JFX co-bundling at the >> moment. In an earlier mail Michael Paus implied that >> he tentatively believed JFX was now co-bundled in the JRE but I thought >> this wasn't happening until Java8? Richard also confirmed that >> releases are >> now in synch, which I assume a result of co-bundling as well. >> >> When I install JDK-7u5 it installs JFX-2.1 but separate to the main JRE >> install. i.e. the installer contains both packages but they are not >> installed as a single runtime (which is what I would expect with >> 'co-bundling'). >> >> When I download and install JRE-7u5 it doesn't seem to contain any JFX >> classes at all? >> >> In the JRE that was extracted via Igor's Ensemble installer the JRE does >> seem to include JFX in exactly the way I would expect it if it were >> co-bundled (i.e. the jfxrt.jar and DLLs are all inside the JRE >> directory). >> >> Can you guys clear up for me where we are officially at with the >> co-bundling? Am I just being dumb and not seeing the JARs in my JRE >> install, or has co-bundling not happened yet - if not, why not: can't the >> JRE just have the JRE files in it the way Igor has done? Why would our >> local development versions not have it combined when our deployed >> versions >> do? >> >> Cheers, >> Dan > From joe.mcglynn at oracle.com Tue Jun 19 05:40:01 2012 From: joe.mcglynn at oracle.com (Joe McGlynn) Date: Tue, 19 Jun 2012 05:40:01 -0700 Subject: Confused about status of JFX+JRE cobundling In-Reply-To: <4FE03E59.20507@oracle.com> References: <4FE00A98.1070307@oracle.com> <4FE03E59.20507@oracle.com> Message-ID: <1E960750-3EC1-417C-9E8D-ED66C6DE7F97@oracle.com> If you use the supplied ant task or packager tool you can produce double-clickable jars. > > It effectively makes it impossible to distribute JavaFX apps as executable jars. Not a big deal, but it's something that works for Swing apps, so it would be quite expected to have the same model for FX... > From kevin.rushforth at oracle.com Tue Jun 19 05:51:33 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 19 Jun 2012 05:51:33 -0700 Subject: Confused about status of JFX+JRE cobundling In-Reply-To: <1E960750-3EC1-417C-9E8D-ED66C6DE7F97@oracle.com> References: <4FE00A98.1070307@oracle.com> <4FE03E59.20507@oracle.com> <1E960750-3EC1-417C-9E8D-ED66C6DE7F97@oracle.com> Message-ID: <4FE075D5.9050503@oracle.com> Right. This is no different from the workflow you would use today. Starting with 7u6 you can count on JavaFX being there on Windows, Linux, and Mac, but you still need to use the ant tasks in jdk7u6/lib/ant-javafx.jar or the pacakger in jdk7u6/bin/javafxpackager. Netbeans 7.2 is configured to use the ant tasks for JavaFX projects. You can set up Eclipse and other IDEs to do this as well. -- Kevin Joe McGlynn wrote: > If you use the supplied ant task or packager tool you can produce double-clickable jars. > > >> It effectively makes it impossible to distribute JavaFX apps as executable jars. Not a big deal, but it's something that works for Swing apps, so it would be quite expected to have the same model for FX... >> >> > > From joe.mcglynn at oracle.com Tue Jun 19 05:58:15 2012 From: joe.mcglynn at oracle.com (Joe McGlynn) Date: Tue, 19 Jun 2012 05:58:15 -0700 Subject: Confused about status of JFX+JRE cobundling In-Reply-To: <4FE02F0C.1080402@bestsolution.at> References: <4FE00A98.1070307@oracle.com> <4FE00E81.60201@oracle.com> <4FE0272E.4000301@bestsolution.at> <4FE02C35.3040203@oracle.com> <4FE02F0C.1080402@bestsolution.at> Message-ID: -- > Am 19.06.12 09:37, schrieb Igor Nekrestyanov: >> On 6/19/12 12:15 AM, Tom Schindl wrote: >>> * the unbalanced decision to not provide SDK-Drops as zips makes >>> repackaging for different platforms complex >> What other platforms you are referring to? Other Linux distros? > > No I'm talking about windows and mac. Say I'm a win32 user and want to > package an application for users on mac and win32. How would you advise > to do so? > > Answer: Buy a Mac because you don't get access to JavaFX jar and native > libs without out it! We understand this limitation, and it will be addressed as part of how JDKs are released in the future. It's a problem for anyone building Java apps, not just FX apps. There are two aspects to it I think: First, being able to grab native or other platform specific bits to package with your app. Second, being able to create platform-specific artifacts from another platform (eg. a .app bundle for Mac when building on Windows). This spans not just operating systems, but chip architectures. If you just need to grab the native libs for other platforms I suspect you could still do that from a single platform (.dmg readers, virtual machine, etc), although not having them as a zip download makes it a pain in the neck -- I get that. Personally I'm looking for an excuse to buy the new 15" macbook with the retina display :) >> >>> there is now a missmatch between those not wanting to install a JDK >> update and use the JavaFX-SDK because native packaging with fx:deploy >> task is not working for them. >> >> What is the problem with having multiple versions of JDK on the system? >> Unlike runtime these are fully independent ... >> > > JavaFX previews are shipped on a very regular base so now with the > co-bundleing I'm downloading the whole JDK all the time although I'm > only interested in the latest JavaFX. FX preview releases are still available as zip files (http://www.oracle.com/technetwork/java/javafx/downloads/devpreview-1429449.html). These won't be available for the GA product until we can resolve this as a general issue for the JDK. From igor.nekrestyanov at oracle.com Tue Jun 19 06:35:12 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Tue, 19 Jun 2012 06:35:12 -0700 Subject: Confused about status of JFX+JRE cobundling In-Reply-To: <4FE02F0C.1080402@bestsolution.at> References: <4FE00A98.1070307@oracle.com> <4FE00E81.60201@oracle.com> <4FE0272E.4000301@bestsolution.at> <4FE02C35.3040203@oracle.com> <4FE02F0C.1080402@bestsolution.at> Message-ID: <4FE08010.4080006@oracle.com> On 6/19/12 12:49 AM, Tom Schindl wrote: > Am 19.06.12 09:37, schrieb Igor Nekrestyanov: >> On 6/19/12 12:15 AM, Tom Schindl wrote: >>> * the unbalanced decision to not provide SDK-Drops as zips makes >>> repackaging for different platforms complex >> What other platforms you are referring to? Other Linux distros? > No I'm talking about windows and mac. Say I'm a win32 user and want to > package an application for users on mac and win32. How would you advise > to do so? ok, this is valid use case and these is a feature request for cross platform packaging. We are looking for ideas how to implement it (and contributions too), please comment in JIRA if you know how to approach it. It does not directly related to JRE/JDK cobundling though. If JDK will be available as .zip download it will solve it for you? (not sure if this will be happening) >>> there is now a missmatch between those not wanting to install a JDK >> update and use the JavaFX-SDK because native packaging with fx:deploy >> task is not working for them. >> >> What is the problem with having multiple versions of JDK on the system? >> Unlike runtime these are fully independent ... >> > JavaFX previews are shipped on a very regular base so now with the > co-bundleing I'm downloading the whole JDK all the time although I'm > only interested in the latest JavaFX. i see. It does not seem to be too severe to me though. Loading extra 50Mb a week to get latest SDK is not much these days. And i see beta builds are still available as standalone archives here: http://www.oracle.com/technetwork/java/javafx/downloads/devpreview-1429449.html Some changes on Java side are prompted by JavaFX requests. Tight coupling helps with this. Also, no need to install duplicate deployment stack makes web deployment more robust. -igor > >>> Is it really such a big problem to find out java.home for the ant-task >> and packaging this up? Just asking >> >> Current native packaging support makes a lot of simplifying assumptions >> on bundle configuration as we do not want to expose too many APIs in a rush >> (and we likely will provide more flexible APIs in a future for use cases >> that will be popular). >> Decision to use current JDK cobundle as a source for native bundle is >> one of these simplifications. It was not motivation for cobundling Java >> and JavaFX in JDK, >> it is another way - because JDK is true cobundle we had option to >> simplify things. >> >> -igor > Tom > From igor.nekrestyanov at oracle.com Tue Jun 19 06:41:14 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Tue, 19 Jun 2012 06:41:14 -0700 Subject: Confused about status of JFX+JRE cobundling In-Reply-To: <4FE075D5.9050503@oracle.com> References: <4FE00A98.1070307@oracle.com> <4FE03E59.20507@oracle.com> <1E960750-3EC1-417C-9E8D-ED66C6DE7F97@oracle.com> <4FE075D5.9050503@oracle.com> Message-ID: <4FE0817A.7000109@oracle.com> And this is not much different what you do for Swing apps - these also need to be packaged specially to be doubleclickable. For Swing you need manifest entry, for JavaFX few manifest entries + embedded java launcher (default launcher comes with bonus features - helps to notify user if Java does not have JavaFX support and sets up a proxy if needed). BTW, I am not arguing for not having JavaFX on classpath (in fact quite opposite :) ). But at his point of time it seems unlikely this may happen in 7u6. -igor On 6/19/12 5:51 AM, Kevin Rushforth wrote: > Right. This is no different from the workflow you would use today. > Starting with 7u6 you can count on JavaFX being there on Windows, > Linux, and Mac, but you still need to use the ant tasks in > jdk7u6/lib/ant-javafx.jar or the pacakger in > jdk7u6/bin/javafxpackager. Netbeans 7.2 is configured to use the ant > tasks for JavaFX projects. You can set up Eclipse and other IDEs to do > this as well. > > -- Kevin > > > Joe McGlynn wrote: >> If you use the supplied ant task or packager tool you can produce >> double-clickable jars. >> >>> It effectively makes it impossible to distribute JavaFX apps as >>> executable jars. Not a big deal, but it's something that works for >>> Swing apps, so it would be quite expected to have the same model for >>> FX... >>> >> From hang.vo at oracle.com Tue Jun 19 07:04:18 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Jun 2012 14:04:18 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-16812 - close QuantumClipboard security vulnerability reading images from untrusted applets Message-ID: <20120619140422.B055B479EE@hg.openjdk.java.net> Changeset: af08c7baa21a Author: Morris Meyer Date: 2012-06-19 09:51 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/af08c7baa21a RT-16812 - close QuantumClipboard security vulnerability reading images from untrusted applets ! javafx-ui-common/src/com/sun/javafx/tk/TKClipboard.java ! javafx-ui-common/src/javafx/scene/input/Clipboard.java From hang.vo at oracle.com Tue Jun 19 07:20:01 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Jun 2012 14:20:01 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-16812 - add initSecurityContext to StubTookit Message-ID: <20120619142002.3E40F479EF@hg.openjdk.java.net> Changeset: 1afaf1867c5d Author: Morris Meyer Date: 2012-06-19 10:10 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/1afaf1867c5d RT-16812 - add initSecurityContext to StubTookit ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java From hang.vo at oracle.com Tue Jun 19 07:49:46 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Jun 2012 14:49:46 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-16812 - add initSecurityContext to DragAndDropTest Message-ID: <20120619144947.05D2E479F0@hg.openjdk.java.net> Changeset: 0af7b6ab244f Author: Morris Meyer Date: 2012-06-19 10:35 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/0af7b6ab244f RT-16812 - add initSecurityContext to DragAndDropTest ! javafx-ui-common/test/unit/javafx/scene/input/DragAndDropTest.java From richard.bair at oracle.com Tue Jun 19 08:59:49 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 19 Jun 2012 08:59:49 -0700 Subject: CSS-Documentation for IDE-Usage In-Reply-To: <4FE03A80.4040700@bestsolution.at> References: <4FE03A80.4040700@bestsolution.at> Message-ID: Hi Tom, I don't think we have a structured document with this information, but it sounds useful! David is on Vacation but he should be involved when he gets back hopefully later this week or next week. Cheers Richard On Jun 19, 2012, at 1:38 AM, Tom Schindl wrote: > Hi, > > Is there some structured text document one can use to teach IDEs hover > documentation of CSS-Attribute, or do I need to extract those > information from the published HTML-CSS-Documentation? > > My hope is that this document is generated from some more structured > resource I can use in my Eclipse integration. If there's no such > document, I'd like to contribute in creating such a meta-format and > generate the HTML-Document from it. Any netbeans people here who'd like > to work with me on this? > > Tom > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From hang.vo at oracle.com Tue Jun 19 09:04:03 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Jun 2012 16:04:03 +0000 Subject: hg: openjfx/2.2/controls/rt: 2 new changesets Message-ID: <20120619160410.175E8479F9@hg.openjdk.java.net> Changeset: 2522280029a7 Author: mickf Date: 2012-06-19 16:58 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/2522280029a7 RT-22653 : ScrollBar with -fx-border styles is drawn wrong in 2.2 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java Changeset: 1de4b14f0aa9 Author: mickf Date: 2012-06-19 17:00 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/1de4b14f0aa9 RT-22652 : ScrollBar -fx-background-color behavior changed in 2.2 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css From richard.bair at oracle.com Tue Jun 19 09:08:07 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 19 Jun 2012 09:08:07 -0700 Subject: Confused about status of JFX+JRE cobundling In-Reply-To: <4FE0272E.4000301@bestsolution.at> References: <4FE00A98.1070307@oracle.com> <4FE00E81.60201@oracle.com> <4FE0272E.4000301@bestsolution.at> Message-ID: > While there are benefits there are also drawbacks: > > * JavaFX release schedule has to be tightly aligned with JDK which > means JavaFX has not much freedom anymore Yes and no. JavaFX is already part of the Java support offerings from Oracle, and the sustaining team has to therefore support JavaFX in addition to Java itself, and aligning releases and cobundling makes this much, much easier (ie: there probably wouldn't be an enterprise support offering for FX if we didn't align it with SE, and for FX this is pretty important). There is also the fact that there is an SE release every 3 months or so, so we have plenty of opportunities to get new features out there. Unlike the JDK, our code doesn't yet require JSR or JCP approvals. That is why we were aiming for making JavaFX a part of standard Java in Java 9 timeframe so that by the time we got there FX would be mature enough to be able to handle 18month release cycles between new features (for anything that is part of JavaSE, you can only add new API on major releases, whereas since FX is not yet part of the Java specification, we can make updates any time). We also get to share the same SQE (quality/test) cycles, documentation cycles, etc. Since we hope to be part of JavaSE at some point in the next couple of years, it makes sense to cobundle and reap the logistical benefits. The downsides to cobundling are the same as they would be when we are part of SE itself -- compatibility vs. security tradeoffs (which we hope to address partly by application bundles as discussed on the other thread), etc. Richard From scott.kovatch at oracle.com Tue Jun 19 09:52:24 2012 From: scott.kovatch at oracle.com (Scott Kovatch) Date: Tue, 19 Jun 2012 09:52:24 -0700 Subject: Confused about status of JFX+JRE cobundling In-Reply-To: References: <4FE00A98.1070307@oracle.com> <4FE00E81.60201@oracle.com> <4FE0272E.4000301@bestsolution.at> <4FE02C35.3040203@oracle.com> <4FE02F0C.1080402@bestsolution.at> Message-ID: <588161B0-5830-4F08-8E16-9EBBEA4A5428@oracle.com> On Jun 19, 2012, at 5:58 AM, Joe McGlynn wrote: > > > -- >> Am 19.06.12 09:37, schrieb Igor Nekrestyanov: >>> On 6/19/12 12:15 AM, Tom Schindl wrote: >>>> * the unbalanced decision to not provide SDK-Drops as zips makes >>>> repackaging for different platforms complex >>> What other platforms you are referring to? Other Linux distros? >> >> No I'm talking about windows and mac. Say I'm a win32 user and want to >> package an application for users on mac and win32. How would you advise >> to do so? >> >> Answer: Buy a Mac because you don't get access to JavaFX jar and native >> libs without out it! > > We understand this limitation, and it will be addressed as part of how JDKs are released in the future. It's a problem for anyone building Java apps, not just FX apps. There are two aspects to it I think: First, being able to grab native or other platform specific bits to package with your app. Second, being able to create platform-specific artifacts from another platform (eg. a .app bundle for Mac when building on Windows). This spans not just operating systems, but chip architectures. Jumping in here? We aren't doing it yet, but there are plans to make a download available with JREs that both FxPackager and the appbundler project can use to create an application on any platform. As both of these tools expand to support other platforms, that JRE archive will expand to include additional redistributable JREs. Tom, I'm sure you are familiar with the Eclipse platform packs that contain things like SWTs for all platforms, Equinox launchers, and so on. It's the same idea applied to JREs. -- Scott K. ---------------------------------------- Scott Kovatch scott.kovatch at oracle.com Santa Clara/Pleasanton, CA From hang.vo at oracle.com Tue Jun 19 10:19:18 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Jun 2012 17:19:18 +0000 Subject: hg: openjfx/2.2/graphics/rt: 37 new changesets Message-ID: <20120619171955.ACE06479FE@hg.openjdk.java.net> Changeset: 8192bc3aa019 Author: Paru Somashekar Date: 2012-06-12 10:39 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/8192bc3aa019 RT-20937 missing javadoc for some MenuItem properties RT-19747 piechart is not affected by -fx-pie-label-visible RT-13081 ChartSampler demo / set new data leads to NPE. ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java ! javafx-ui-charts/src/javafx/scene/chart/ScatterChart.java ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java Changeset: 6e34b405d07e Author: Kinsley Wong Date: 2012-06-12 14:30 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/6e34b405d07e RT-22326: TabPane: unable to select the following tab when a tab is closed. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TabPaneBehavior.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java Changeset: 9d72813b0448 Author: Paru Somashekar Date: 2012-06-12 16:49 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/9d72813b0448 RT-20104 Tooltip missing textAlignment javadoc ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java Changeset: 2f475847df17 Author: Kinsley Wong Date: 2012-06-12 17:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/2f475847df17 RT-22415: Adding an item to SplitPane may hang FX ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SplitPaneSkin.java Changeset: 35c426930d23 Author: jgiles Date: 2012-06-12 20:21 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/35c426930d23 RT-21586: ListView: Replacing all items does not clear selection ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: b6f81f47c4c8 Author: jgiles Date: 2012-06-13 09:44 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/b6f81f47c4c8 RT-22428: TableColumns are appearing collapsed by default ! javafx-ui-controls/src/javafx/scene/control/TableCell.java Changeset: 541a5c63514f Author: jgiles Date: 2012-06-13 13:19 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/541a5c63514f RT-22191: TableView: Performance degrades when resetting content ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: 06a917ba0bfa Author: jgiles Date: 2012-06-13 13:43 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/06a917ba0bfa RT-22385: TableView leaks memory ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkin.java ! javafx-ui-controls/src/javafx/scene/control/TableCell.java Changeset: 8dc0f0d957e0 Author: jgiles Date: 2012-06-13 14:20 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/8dc0f0d957e0 RT-20840: fx2.2-h17-b01: Adding new column to TableView results in creating new N columns instead of 1 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java Changeset: b618eb1ac127 Author: jgiles Date: 2012-06-13 15:36 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/b618eb1ac127 RT-22391: Removing a nested TableColumn from its parent column resets the tableView property of the parent to null ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java Changeset: e6d1c213886d Author: jgiles Date: 2012-06-13 16:18 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/e6d1c213886d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: d014ba0c953c Author: Paru Somashekar Date: 2012-06-13 11:27 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/d014ba0c953c fix RT-22466 Adding, removing then adding the same MenuBar instance in the scenegraph triggers NPE. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java Changeset: 2bad47ac2ab8 Author: Kinsley Wong Date: 2012-06-13 12:12 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/2bad47ac2ab8 RT-22232: Context menu is in the wrong place for non primary monitors. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java Changeset: 1a2a50109e8e Author: Kinsley Wong Date: 2012-06-13 13:47 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/1a2a50109e8e RT-22467: Moving a Button located in an AnchorPane to a Tab content gets you NPE ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ButtonSkin.java Changeset: 14efe4fc1d6a Author: leifs Date: 2012-06-13 14:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/14efe4fc1d6a Fixed RT-22480: Add private method to set default system menu bar. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java Changeset: dc1043f1fde4 Author: leifs Date: 2012-06-13 18:45 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/dc1043f1fde4 Fixed RT-21645: On Mac OS X call to GlassViewEventHandler.getInputMethodCandidatePos() provides strange coordinates ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java Changeset: 4b5bf956320b Author: jgiles Date: 2012-06-14 11:05 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/4b5bf956320b RT-22386: ComboBox : cannot choose the same item multiple times ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/test/javafx/scene/control/ComboBoxTest.java Changeset: ebbc5b495c06 Author: jgiles Date: 2012-06-14 15:02 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/ebbc5b495c06 RT-21088: ComboBox: regression with focusedProperty ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 6f9959b35a9d Author: jgiles Date: 2012-06-14 15:28 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/6f9959b35a9d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: adcda42efa37 Author: leifs Date: 2012-06-14 00:20 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/adcda42efa37 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt Changeset: d26daf855de3 Author: Paru Somashekar Date: 2012-06-14 13:48 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/d26daf855de3 RT-22553 Adding a data item to a PieChart after removing the same item, causes NPE. ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java Changeset: 59617134868f Author: David Grieve Date: 2012-06-14 18:26 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/59617134868f RT-21906: must separate shared css calculated values from node-specific css calculated values if node has user set font. ! javafx-ui-common/src/com/sun/javafx/css/CascadingStyle.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java Changeset: 7c669f613b6c Author: David Grieve Date: 2012-06-14 18:40 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/7c669f613b6c RT-20643 (partial) Expose StyleManger getPseudoclassStrings for Scene Builder use. ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: 217cede187d0 Author: Paru Somashekar Date: 2012-06-14 16:24 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/217cede187d0 RT-22166 Axis tick labels are drawn outside chart and over top of axis name ! javafx-ui-charts/test/javafx/scene/chart/ChartTestBase.java ! javafx-ui-charts/test/javafx/scene/chart/StackedAreaChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/StackedBarChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/XYChartTest.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/javafx/scene/chart/Axis.java ! javafx-ui-controls/src/javafx/scene/chart/ValueAxis.java Changeset: adb8d50d8799 Author: jgiles Date: 2012-06-15 13:48 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/adb8d50d8799 RT-20938: javafx.scene.control.Tab: field visible via public API should not be of non-public type ! javafx-ui-controls/src/javafx/scene/control/Tab.java Changeset: 0dc775249a62 Author: jgiles Date: 2012-06-15 14:13 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/0dc775249a62 RT-20582: MenuItem's styleable has a null Node ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java Changeset: 0f2fba17c263 Author: jgiles Date: 2012-06-15 14:37 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/0f2fba17c263 RT-21472: impl_getStyleable is needed on TableColumn ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableHeaderRow.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkin.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java Changeset: 49d2f59fb14e Author: jgiles Date: 2012-06-15 15:05 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/49d2f59fb14e Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 109bddc14dde Author: jgiles Date: 2012-06-15 17:05 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/109bddc14dde Fix build failure in MenuItem. ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java Changeset: ba93ff7e1f24 Author: Kinsley Wong Date: 2012-06-15 13:58 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/ba93ff7e1f24 RT-21745: Bad strange layout in VBox caused by Label.setWrapText(true). ! javafx-ui-common/src/javafx/scene/layout/AnchorPane.java ! javafx-ui-common/test/unit/javafx/scene/layout/AnchorPaneTest.java Changeset: acd0852a0a8e Author: mickf Date: 2012-06-16 14:42 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/acd0852a0a8e RT-21251 : [ListView] some space appeared between scrollbar and listview content. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 1e240f8f9fc5 Author: leifs Date: 2012-06-18 08:26 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/1e240f8f9fc5 [mq]: rt22054 ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java Changeset: 38a9585cb2db Author: leifs Date: 2012-06-18 08:50 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/38a9585cb2db Fixed RT-22644: [TextArea] Typing Tab or Enter breaks Undo chain ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java Changeset: 104dff9f4ebc Author: Kinsley Wong Date: 2012-06-18 12:49 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/104dff9f4ebc Rollback fix for RT-21906: must separate shared css calculated values from node-specific css calculated values if node has user set font. ! javafx-ui-common/src/com/sun/javafx/css/CascadingStyle.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java Changeset: 6144c0bee0f9 Author: Kinsley Wong Date: 2012-06-18 13:12 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/6144c0bee0f9 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt Changeset: bdbc42e5a633 Author: Kinsley Wong Date: 2012-06-18 16:54 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/bdbc42e5a633 Ignore broken charts units tests. ! javafx-ui-charts/test/javafx/scene/chart/StackedAreaChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/StackedBarChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/XYChartTest.java Changeset: f026710b45cb Author: Yao Wang Date: 2012-06-19 10:12 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/f026710b45cb Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt - javafx-ui-common/src/com/sun/javafx/stage/PopupEventRedirector.java ! javafx-ui-common/src/javafx/scene/Node.java From hang.vo at oracle.com Tue Jun 19 11:04:26 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Jun 2012 18:04:26 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22455: Clip doesn't work. Message-ID: <20120619180427.B0E7E479FF@hg.openjdk.java.net> Changeset: 123426be1adf Author: Kinsley Wong Date: 2012-06-19 10:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/123426be1adf RT-22455: Clip doesn't work. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/Utils.java From richard.bair at oracle.com Tue Jun 19 11:49:02 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 19 Jun 2012 11:49:02 -0700 Subject: API REVIEW: Weak event handler In-Reply-To: <4FDB3A70.6040703@xs4all.nl> References: <4FD72C57.1040609@oracle.com> <934EC5B5-0318-4580-B000-AFCA69E62384@oracle.com> <4FD87203.70203@oracle.com> <4FDB10B3.1080205@oracle.com> <4FDB3A70.6040703@xs4all.nl> Message-ID: So I talked to Jasper, and I like this later approach. Thanks Richard PS> Possibly it could implement WeakListener as well, though that forms a new relation between javafx-common and javafx-beans, though for all practical purposes no JavaFX app can exist without javafx-beans anyway. On Jun 15, 2012, at 6:36 AM, John Hendrikx wrote: > I can't speak for Richard, but this looks very much in line with the existing WeakChangeListener and WeakInvalidationListener -- I think it's good to do this one in a similar fashion for consistency. > > --John > > On 15/06/2012 12:38, Lubomir Nerad wrote: >> Hi Richard, >> >> haven't got any answer from you. I would like to make some progress with this, so here is an updated WeakEventHandler, which should be more to your liking: >> >> public final class WeakEventHandler >> implements EventHandler { >> public WeakEventHandler(EventHandler eventHandler) { ... } >> >> public boolean wasGarbageCollected() { ... } >> >> @Override public void handle(T event) { ... } >> } >> >> I removed WeakReference and the factory method, added the additional test method (as in WeakListener) and the public constructor. >> >> Is it OK now? >> >> Thanks, >> Lubo >> >> On 6/13/2012 12:57 PM, Lubomir Nerad wrote: >>> Hi Richard, >>> >>> On 6/12/2012 10:01 PM, Richard Bair wrote: >>>> Hi Lubo, >>>> >>>>> I also considered to define the WeakEventHandler as an interface which extends EventHandler, but adds no additional methods. Then leave it to event handler containers to reference such event handlers weakly. This has very simple and direct usage, but also its own problems. We can discuss it further if you find this solution preferred to the wrapper approach. >>>> Extending WeakReference and lacking the public constructor did make me a little weak in the knees :-). >>> >>> Well, we can of course remove WeakReference from extends and have it as an instance in WeakEventHandler. But then we need to add some method to test whether the target handler has been garbage collected and will have one more instance for each created WeakEventHandler. So extending WeakReference seemed to me worth considering. On the other hand having additional test method is more consistent with Weak*Listener from javafx-beans so we will probably end up with it. As to the public constructor, I don't like having both (the factory method and constructor) and in this case the factory method seems to be easier to use. >>> >>>> What were the problems with WeakEventHandler being an interface? >>>> >>> >>> When somebody wants to register a single event handler weakly multiple times, in the case of WeakEventHandler as a wrapper (the first case), he needs only to create a single instance of it and register it multiple types. In the case of WeakEventHandler as a marker (the second case), each time he registers such event handler a new instance of weak reference needs to be created by the container for it. Also if such weak event handler is set to an event handler property (for example Node.setOnMousePressed), the property implementation needs to be ready for it and create a weak reference to it. Then when such event handler is finally garbage collected, the property needs to return null and ideally at the point of garbage collection it should notify its listeners (if any) about value change. >>> >>>> Thanks! >>>> Richard >>> >>> Lubo >>> >> > From hang.vo at oracle.com Tue Jun 19 12:34:18 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Jun 2012 19:34:18 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22687: Pagination Before click next - "ArithmeticException / by zero" for small size pane. Message-ID: <20120619193419.A0A7A47A02@hg.openjdk.java.net> Changeset: 238594fe9cab Author: Kinsley Wong Date: 2012-06-19 12:13 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/238594fe9cab RT-22687: Pagination Before click next - "ArithmeticException / by zero" for small size pane. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/test/javafx/scene/control/PaginationTest.java From michael.heinrichs at oracle.com Tue Jun 19 12:37:38 2012 From: michael.heinrichs at oracle.com (Michael Heinrichs) Date: Tue, 19 Jun 2012 21:37:38 +0200 Subject: API REVIEW: Weak event handler In-Reply-To: References: <4FD72C57.1040609@oracle.com> <934EC5B5-0318-4580-B000-AFCA69E62384@oracle.com> <4FD87203.70203@oracle.com> <4FDB10B3.1080205@oracle.com> <4FDB3A70.6040703@xs4all.nl> Message-ID: <0C519692-43E7-4934-BCBA-0B768F4D4952@oracle.com> On 19.06.2012, at 20:49, Richard Bair wrote: > [...] though for all practical purposes no JavaFX app can exist without javafx-beans anyway. > Yeah, one to rule them all. Hehe! - Michael > On Jun 15, 2012, at 6:36 AM, John Hendrikx wrote: > >> I can't speak for Richard, but this looks very much in line with the existing WeakChangeListener and WeakInvalidationListener -- I think it's good to do this one in a similar fashion for consistency. >> >> --John >> >> On 15/06/2012 12:38, Lubomir Nerad wrote: >>> Hi Richard, >>> >>> haven't got any answer from you. I would like to make some progress with this, so here is an updated WeakEventHandler, which should be more to your liking: >>> >>> public final class WeakEventHandler >>> implements EventHandler { >>> public WeakEventHandler(EventHandler eventHandler) { ... } >>> >>> public boolean wasGarbageCollected() { ... } >>> >>> @Override public void handle(T event) { ... } >>> } >>> >>> I removed WeakReference and the factory method, added the additional test method (as in WeakListener) and the public constructor. >>> >>> Is it OK now? >>> >>> Thanks, >>> Lubo >>> >>> On 6/13/2012 12:57 PM, Lubomir Nerad wrote: >>>> Hi Richard, >>>> >>>> On 6/12/2012 10:01 PM, Richard Bair wrote: >>>>> Hi Lubo, >>>>> >>>>>> I also considered to define the WeakEventHandler as an interface which extends EventHandler, but adds no additional methods. Then leave it to event handler containers to reference such event handlers weakly. This has very simple and direct usage, but also its own problems. We can discuss it further if you find this solution preferred to the wrapper approach. >>>>> Extending WeakReference and lacking the public constructor did make me a little weak in the knees :-). >>>> >>>> Well, we can of course remove WeakReference from extends and have it as an instance in WeakEventHandler. But then we need to add some method to test whether the target handler has been garbage collected and will have one more instance for each created WeakEventHandler. So extending WeakReference seemed to me worth considering. On the other hand having additional test method is more consistent with Weak*Listener from javafx-beans so we will probably end up with it. As to the public constructor, I don't like having both (the factory method and constructor) and in this case the factory method seems to be easier to use. >>>> >>>>> What were the problems with WeakEventHandler being an interface? >>>>> >>>> >>>> When somebody wants to register a single event handler weakly multiple times, in the case of WeakEventHandler as a wrapper (the first case), he needs only to create a single instance of it and register it multiple types. In the case of WeakEventHandler as a marker (the second case), each time he registers such event handler a new instance of weak reference needs to be created by the container for it. Also if such weak event handler is set to an event handler property (for example Node.setOnMousePressed), the property implementation needs to be ready for it and create a weak reference to it. Then when such event handler is finally garbage collected, the property needs to return null and ideally at the point of garbage collection it should notify its listeners (if any) about value change. >>>> >>>>> Thanks! >>>>> Richard >>>> >>>> Lubo >>>> >>> >> > From richard.bair at oracle.com Tue Jun 19 12:41:26 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 19 Jun 2012 12:41:26 -0700 Subject: Region PickOnBounds default setting Message-ID: Hi folks, We have an issue which has been in the platform from before 2.0: http://javafx-jira.kenai.com/browse/RT-17024. A better explanation of the issue can be found on http://javafx-jira.kenai.com/browse/RT-12258. From 12258: > Region behaves counter-intuitively regarding mouse event delivering. It reacts on mouse events everywhere in its bounds and people are often confused by it. Here are two simple examples: > > 1) You create let's say HBox just because you want it to layout its children. The HBox catches all mouse events in the whole area given by its bounds. Often it's hard to understand what area it is (with children of different size or with some other layout stretches taking place). > > 2) You create a small Pane in top-left corner of the scene with a child in bottom-right corner of the scene. Pane's bounds will then cover whole sceen and you won't be able to click on anything else than the pane and its child. Users don't understand why, because both visually and in source code there is nothing in between the pane and the child. > > Moreover, region may have a shape associated and the behavior here is also strange. If you create a region with a shape inside its bounds, it's just ignored. You can also create a shape somewhere else, then it extends region's bounds and it reacts on mouse click everywhere between the shape and the region. This issue has to do with the semantics of picking on a Region. For Region we have had pickOnBounds set to true by default, which yields the above behaviors. We can change it to false by default, but then need to update a bunch of skins (for example the up/down arrows of scroll bar, the thumb of a slider, the down arrow of a combo box button, etc) so that they switch back to having pickOnBounds set to true by default so that the target area for clicks is larger. We could just change the default for Pane and not for Region, although we use StackPane in Skins and would have to update them anyhow. It seems that for a normal layout container the behavior really should be pickOnBounds=false by default, but for UI controls usages and such you generally want it true. I'm not certain making this change is worth being backwards incompatible (semantically, binary compatibility would remain). But what do you think? Richard From hang.vo at oracle.com Tue Jun 19 13:34:50 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Jun 2012 20:34:50 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-22434: Canvas Defaults should be same as FX Message-ID: <20120619203451.9275C47A07@hg.openjdk.java.net> Changeset: 605a2c2253e5 Author: "Joseph Andresen" Date: 2012-06-19 12:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/605a2c2253e5 RT-22434: Canvas Defaults should be same as FX ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java From zonski at googlemail.com Tue Jun 19 14:04:00 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Wed, 20 Jun 2012 07:04:00 +1000 Subject: Region PickOnBounds default setting In-Reply-To: References: Message-ID: I've always wondered what the behavior when pickOnBounds is false ie. what does it then pick on if not the bounds? Its not intuitive to me from the method name what should happen. Assuming I understand the problem then I've hit this sort of layout problem and my instinct was to look for setMouseTransparent(true) on the region as that's basically what I wanted. Problem was it set all its children transparent too. Perhaps another way out of this problem would be some form of non-inherited mouse transparency attribute. Might be more efficient too. I'm not sure I agree with the bug description when it says that "both visually and in source code there is nothing in between the pane and the child". In code there is a pane. Visually there would be a pane if you set styles on it. Wouldn't you be just as confused if you were trying to add a pane and it bizarrely wasn't getting mouse events? I'm guessing, for example, if this fix went in it would break all my 'glasspanes'? As such, I don't think it needs to be a default attribute now that it's in place the other way round but I do think it needs to be clear and intuitive how to deal with it. On 20/06/2012, at 5:41 AM, Richard Bair wrote: > Hi folks, > > We have an issue which has been in the platform from before 2.0: http://javafx-jira.kenai.com/browse/RT-17024. A better explanation of the issue can be found on http://javafx-jira.kenai.com/browse/RT-12258. From 12258: > >> Region behaves counter-intuitively regarding mouse event delivering. It reacts on mouse events everywhere in its bounds and people are often confused by it. Here are two simple examples: >> >> 1) You create let's say HBox just because you want it to layout its children. The HBox catches all mouse events in the whole area given by its bounds. Often it's hard to understand what area it is (with children of different size or with some other layout stretches taking place). >> >> 2) You create a small Pane in top-left corner of the scene with a child in bottom-right corner of the scene. Pane's bounds will then cover whole sceen and you won't be able to click on anything else than the pane and its child. Users don't understand why, because both visually and in source code there is nothing in between the pane and the child. >> >> Moreover, region may have a shape associated and the behavior here is also strange. If you create a region with a shape inside its bounds, it's just ignored. You can also create a shape somewhere else, then it extends region's bounds and it reacts on mouse click everywhere between the shape and the region. > > > This issue has to do with the semantics of picking on a Region. For Region we have had pickOnBounds set to true by default, which yields the above behaviors. We can change it to false by default, but then need to update a bunch of skins (for example the up/down arrows of scroll bar, the thumb of a slider, the down arrow of a combo box button, etc) so that they switch back to having pickOnBounds set to true by default so that the target area for clicks is larger. We could just change the default for Pane and not for Region, although we use StackPane in Skins and would have to update them anyhow. It seems that for a normal layout container the behavior really should be pickOnBounds=false by default, but for UI controls usages and such you generally want it true. > > I'm not certain making this change is worth being backwards incompatible (semantically, binary compatibility would remain). But what do you think? > > Richard From zonski at googlemail.com Tue Jun 19 17:23:53 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Wed, 20 Jun 2012 10:23:53 +1000 Subject: Confused about status of JFX+JRE cobundling In-Reply-To: <588161B0-5830-4F08-8E16-9EBBEA4A5428@oracle.com> References: <4FE00A98.1070307@oracle.com> <4FE00E81.60201@oracle.com> <4FE0272E.4000301@bestsolution.at> <4FE02C35.3040203@oracle.com> <4FE02F0C.1080402@bestsolution.at> <588161B0-5830-4F08-8E16-9EBBEA4A5428@oracle.com> Message-ID: Just to confirm that what I'm doing it what you expect: I'm using IntelliJ IDEA and I want to do a maven build with jdk7u6 and use the co-bundled javafx. 1. I download and install the new jre7u6 which includes javafx. 2. I tell IntelliJ to use this build and it picks up JavaFX automatically (i.e. it adds jfxrt.jar to the classpath for the jre instance because it is in the lib directory). 3. I write my JFX GUI code 4. I use the 'maven' panel in IDEA to attempt to build ('clean install'). 5. My build fails with error because jfxrt.jar is not on the maven path Adding 'jfxrt.jar' to the %CLASSPATH% doesn't help as Maven builds it's own classpath based on what is in the pom.xml (that's kind of the point of it). So I have a couple of options: 1. Add a 'system dependency' (these are generally bad in Maven) to the jfxrt.jar in my pom.xml so it gets added to the classpath. I then also have to exclude it from my final assembly using extra pom config so it doesn't end up in the MSI. 2. Move the jfxrt.jar in the JRE install into the 'ext' directory so it gets included in the classpath I am currently using option 2 but I feel a little dirty hacking directly with the JRE install and obviously need to do it manually each time I upgrade. I also assume your build tools will pick up this JRE, so the fact that I've messed with it will flow into the MSI, etc? Is this how you guys seeing it being used? i.e. is the current nastiness just a side effect of this not-on-classpath requirement thing that I should just live with and hack around, or am I missing some step that would make this nicer? Cheers, Dan On Wed, Jun 20, 2012 at 2:52 AM, Scott Kovatch wrote: > On Jun 19, 2012, at 5:58 AM, Joe McGlynn wrote: > > > > > > > -- > >> Am 19.06.12 09:37, schrieb Igor Nekrestyanov: > >>> On 6/19/12 12:15 AM, Tom Schindl wrote: > >>>> * the unbalanced decision to not provide SDK-Drops as zips makes > >>>> repackaging for different platforms complex > >>> What other platforms you are referring to? Other Linux distros? > >> > >> No I'm talking about windows and mac. Say I'm a win32 user and want to > >> package an application for users on mac and win32. How would you advise > >> to do so? > >> > >> Answer: Buy a Mac because you don't get access to JavaFX jar and native > >> libs without out it! > > > > We understand this limitation, and it will be addressed as part of how > JDKs are released in the future. It's a problem for anyone building Java > apps, not just FX apps. There are two aspects to it I think: First, being > able to grab native or other platform specific bits to package with your > app. Second, being able to create platform-specific artifacts from another > platform (eg. a .app bundle for Mac when building on Windows). This spans > not just operating systems, but chip architectures. > > Jumping in here? We aren't doing it yet, but there are plans to make a > download available with JREs that both FxPackager and the appbundler > project can use to create an application on any platform. As both of these > tools expand to support other platforms, that JRE archive will expand to > include additional redistributable JREs. > > Tom, I'm sure you are familiar with the Eclipse platform packs that > contain things like SWTs for all platforms, Equinox launchers, and so on. > It's the same idea applied to JREs. > > -- Scott K. > > ---------------------------------------- > Scott Kovatch > scott.kovatch at oracle.com > Santa Clara/Pleasanton, CA > > From zonski at googlemail.com Tue Jun 19 18:59:08 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Wed, 20 Jun 2012 11:59:08 +1000 Subject: Auto-update of native application bundles In-Reply-To: References: <4FDBA1F8.8080103@oracle.com> <4FDD86A6.1060708@oracle.com> <4FDE5AB4.2040102@oracle.com> <761E36A5-CB27-417F-9218-E61DE4B1FF97@ultramixer.com> Message-ID: I've uploaded a new MSI to: http://zenjava.com/demo/update/testapp.msi This is version 3 and it is blue. If you install and check for updates, you will see that version 4 is available for download. If you upgrade you will see that it's red. Note the upgrade is now quite quick as they both use the same Java version. This is now all in JavaFX instead of Swing. It is a nicer UI and user experience but it is still very raw and would need a lot of work. It should give you more of an idea though, and, of course, if anyone wants to look at making it nicer please let me know. *Note: If you have the older version you can auto update to this newer version but because the whole point is to demonstrate the new auto-update code, you would be better served by uninstalling, downloading the new one, installing and then upgrading. * I'm hoping (perhaps optimistically) for feedback on the two proposed approaches from the community regarding "deltas assembled at compile time" vs "deltas determined at runtime" (where a 'delta' is the same thing as a 'patch'). The floor is open, but if there isn't any feedback in the next few days I will focus on just one approach - in the absence of any other input it will likely be Igor's "deltas assembled at compile time" approach. Speak now or forever hold your peace (or at least apologise later when you make me change to another way). Just to re-cap, here are the main pros/cons of each solution: - with *compile-time deltas* we can assemble all the changes into one, easy to deploy file (per delta/OS). - with *runtime deltas* the app has to be uploaded to the server unzipped (i.e. as it would appear on your local system) so the apps can work out diffs on the fly - with *compile-time deltas* you have to create and maintain all deltas you want to be available (e.g. v1-to-v2, v2-to-v3 and v1-to-v3). If you don't provide a delta, the system reverts to 'full' update (i.e. downloads everything). Currently this could mean a 50MB download (instead of say a 4MB delta), but Igor has indicated this might be reduced considerably. Deltas also require some extra steps at compile time to define/detect what has changed. - with *runtime deltas* you only maintain/upload the latest code - the apps all work out the delta's on the fly and only download what they need (e.g. the 4MB of jars that have changed). You do not need to create or maintain any deltas. You do need to maintain an 'app-profile' but this could be mostly generated (easily from Maven, I imagine ant could automate it if you used versioned jars). - the single file of the *compile-time deltas* make life easier/quicker for signing. - with *runtime deltas* the tool has to sign every jar individually (although tooling would hide this - and signing requirements are not yet fully explored) There are likely other smaller benefits as well (Igor, did I miss any big ones?) but these major ones are what I would be weighing up. There is another possible usage of *runtime deltas* that I've not brought up before because I still can't decide if it is a positive or a negative. With this approach the JARs don't have to come from the same URL source, so for example you could download the third party JARs (like hibernate, spring, etc) directly from centralised servers - and the Maven repos provide exactly this already. This would be useful for corporate, intranet style apps where they could maintain their own Maven repo, but for public apps it might be a little risky? It also opens up lots of questions regarding JAR signing, but I personally feel signing is not as necessary in all cases as might be the current thinking (but that's probably another debate). Any and all feedback on all the above will be useful for determining a solution. From hang.vo at oracle.com Tue Jun 19 19:34:27 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Jun 2012 02:34:27 +0000 Subject: hg: openjfx/2.2/controls/rt: 2 new changesets Message-ID: <20120620023431.52EDB47A13@hg.openjdk.java.net> Changeset: f12ab84e2a1e Author: jgiles Date: 2012-06-20 14:19 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/f12ab84e2a1e RT-22565: Once set, setting stylesheets on a Parent has no effect. Patch supplied by David Grieve. ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Parent.java Changeset: 9cd4f06a4d7c Author: jgiles Date: 2012-06-20 14:20 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/9cd4f06a4d7c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt From hang.vo at oracle.com Tue Jun 19 23:19:26 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Jun 2012 06:19:26 +0000 Subject: hg: openjfx/2.2/graphics/rt: Fix RT-19711 Color.web() should allow floating point values for percents and angles. Message-ID: <20120620061928.D5D1147A21@hg.openjdk.java.net> Changeset: cce23876f3c4 Author: flar Date: 2012-06-19 23:13 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/cce23876f3c4 Fix RT-19711 Color.web() should allow floating point values for percents and angles. ! javafx-ui-common/src/javafx/scene/paint/Color.java ! javafx-ui-common/test/unit/javafx/scene/paint/ColorTest.java From tom.schindl at bestsolution.at Tue Jun 19 23:40:15 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 20 Jun 2012 08:40:15 +0200 Subject: Confused about status of JFX+JRE cobundling In-Reply-To: References: <4FE00A98.1070307@oracle.com> <4FE00E81.60201@oracle.com> <4FE0272E.4000301@bestsolution.at> <4FE02C35.3040203@oracle.com> <4FE02F0C.1080402@bestsolution.at> <588161B0-5830-4F08-8E16-9EBBEA4A5428@oracle.com> Message-ID: <4FE1704F.6060409@bestsolution.at> [...] > So I have a couple of options: > > 1. Add a 'system dependency' (these are generally bad in Maven) to the > jfxrt.jar in my pom.xml so it gets added to the classpath. I then also have > to exclude it from my final assembly using extra pom config so it doesn't > end up in the MSI. > > 2. Move the jfxrt.jar in the JRE install into the 'ext' directory so it > gets included in the classpath > I put it on the bootclasspath when configuring the compiler: > > UTF-8 > 1.6 > 1.6 > -verbose -bootclasspath /Users/tomschindl/Applications/javafx-sdk2.2.0-beta/rt/lib/jfxrt.jar > I'm not a maven guru and this was the first solution I thought of and it works. I have not tried yet replacing this hard coded path through something I can pass from the outside but once I set up my hudson/jenkins I'll have to figure that our because it runs on linux. Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From pavel.safrata at oracle.com Wed Jun 20 01:12:36 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Wed, 20 Jun 2012 10:12:36 +0200 Subject: Region PickOnBounds default setting In-Reply-To: References: Message-ID: <4FE185F4.9020407@oracle.com> Hello Daniel, On 19.6.2012 23:04, Daniel Zwolenski wrote: > I've always wondered what the behavior when pickOnBounds is false ie. what does it then pick on if not the bounds? Its not intuitive to me from the method name what should happen. It should pick the node only where the node is physically present. The simplest example is a rectangular region with rounded corners. When you click just next to the rounded corner, you are inside the (always rectangular) bounds, but not inside the region. > > Assuming I understand the problem then I've hit this sort of layout problem and my instinct was to look for setMouseTransparent(true) on the region as that's basically what I wanted. Problem was it set all its children transparent too. Perhaps another way out of this problem would be some form of non-inherited mouse transparency attribute. Might be more efficient too. To achieve the desired behavior, you can set pickOnBounds to false. Making the whole region mouse transparent doesn't solve the problem of picking it only in the area covered by it. Finally, it still doesn't make the platform behave intuitively but introduces another workaround that needs to be used manually. > > I'm not sure I agree with the bug description when it says that "both visually and in source code there is nothing in between the pane and the child". In code there is a pane. Visually there would be a pane if you set styles on it. The pane from the description is small and is in a top-left corner. It can be styled, and you can see it there. There is no code that would make the pane big to cover the whole scene, there is no way to make it visible in the whole area, because it's just not there. > Wouldn't you be just as confused if you were trying to add a pane and it bizarrely wasn't getting mouse events? I think we should be consistent with other nodes. If you create a node that is not filled, it is not picked. If it is filled with a transparent color, it is picked. And if you click outside of the node, it is not picked - this rule in particular sounds really intuitive to me and region doesn't follow it if there is a child or shape somewhere else. > > I'm guessing, for example, if this fix went in it would break all my 'glasspanes'? I cannot say unless I know how your glasspanes are implemented... > > As such, I don't think it needs to be a default attribute now that it's in place the other way round but I do think it needs to be clear and intuitive how to deal with it. I'm really sad that we've let this go that far, it could have been fixed before our first release. If the decision comes that it's too late by now, the way how to deal with it will be clear (setPickOnBounds(false)), but I doubt it is (and could be) intuitive. Thanks, Pavel > > > On 20/06/2012, at 5:41 AM, Richard Bair wrote: > >> Hi folks, >> >> We have an issue which has been in the platform from before 2.0: http://javafx-jira.kenai.com/browse/RT-17024. A better explanation of the issue can be found on http://javafx-jira.kenai.com/browse/RT-12258. From 12258: >> >>> Region behaves counter-intuitively regarding mouse event delivering. It reacts on mouse events everywhere in its bounds and people are often confused by it. Here are two simple examples: >>> >>> 1) You create let's say HBox just because you want it to layout its children. The HBox catches all mouse events in the whole area given by its bounds. Often it's hard to understand what area it is (with children of different size or with some other layout stretches taking place). >>> >>> 2) You create a small Pane in top-left corner of the scene with a child in bottom-right corner of the scene. Pane's bounds will then cover whole sceen and you won't be able to click on anything else than the pane and its child. Users don't understand why, because both visually and in source code there is nothing in between the pane and the child. >>> >>> Moreover, region may have a shape associated and the behavior here is also strange. If you create a region with a shape inside its bounds, it's just ignored. You can also create a shape somewhere else, then it extends region's bounds and it reacts on mouse click everywhere between the shape and the region. >> >> This issue has to do with the semantics of picking on a Region. For Region we have had pickOnBounds set to true by default, which yields the above behaviors. We can change it to false by default, but then need to update a bunch of skins (for example the up/down arrows of scroll bar, the thumb of a slider, the down arrow of a combo box button, etc) so that they switch back to having pickOnBounds set to true by default so that the target area for clicks is larger. We could just change the default for Pane and not for Region, although we use StackPane in Skins and would have to update them anyhow. It seems that for a normal layout container the behavior really should be pickOnBounds=false by default, but for UI controls usages and such you generally want it true. >> >> I'm not certain making this change is worth being backwards incompatible (semantically, binary compatibility would remain). But what do you think? >> >> Richard From lubomir.nerad at oracle.com Wed Jun 20 02:26:00 2012 From: lubomir.nerad at oracle.com (Lubomir Nerad) Date: Wed, 20 Jun 2012 11:26:00 +0200 Subject: API REVIEW: Weak event handler In-Reply-To: References: <4FD72C57.1040609@oracle.com> <934EC5B5-0318-4580-B000-AFCA69E62384@oracle.com> <4FD87203.70203@oracle.com> <4FDB10B3.1080205@oracle.com> <4FDB3A70.6040703@xs4all.nl> Message-ID: <4FE19728.4050201@oracle.com> On 6/19/2012 8:49 PM, Richard Bair wrote: > So I talked to Jasper, and I like this later approach. > > Thanks > Richard > > PS> Possibly it could implement WeakListener as well, though that forms a new relation between javafx-common and javafx-beans, though for all practical purposes no JavaFX app can exist without javafx-beans anyway. > Currently that would create bidirectional dependency between javafx-common and javafx-beans (javafx-beans uses some classes/interfaces from javafx-common in its public API). I'd rather leave it as it is for now. Thanks, Lubo > On Jun 15, 2012, at 6:36 AM, John Hendrikx wrote: > >> I can't speak for Richard, but this looks very much in line with the existing WeakChangeListener and WeakInvalidationListener -- I think it's good to do this one in a similar fashion for consistency. >> >> --John >> >> On 15/06/2012 12:38, Lubomir Nerad wrote: >>> Hi Richard, >>> >>> haven't got any answer from you. I would like to make some progress with this, so here is an updated WeakEventHandler, which should be more to your liking: >>> >>> public final class WeakEventHandler >>> implements EventHandler { >>> public WeakEventHandler(EventHandler eventHandler) { ... } >>> >>> public boolean wasGarbageCollected() { ... } >>> >>> @Override public void handle(T event) { ... } >>> } >>> >>> I removed WeakReference and the factory method, added the additional test method (as in WeakListener) and the public constructor. >>> >>> Is it OK now? >>> >>> Thanks, >>> Lubo >>> >>> On 6/13/2012 12:57 PM, Lubomir Nerad wrote: >>>> Hi Richard, >>>> >>>> On 6/12/2012 10:01 PM, Richard Bair wrote: >>>>> Hi Lubo, >>>>> >>>>>> I also considered to define the WeakEventHandler as an interface which extends EventHandler, but adds no additional methods. Then leave it to event handler containers to reference such event handlers weakly. This has very simple and direct usage, but also its own problems. We can discuss it further if you find this solution preferred to the wrapper approach. >>>>> Extending WeakReference and lacking the public constructor did make me a little weak in the knees :-). >>>> Well, we can of course remove WeakReference from extends and have it as an instance in WeakEventHandler. But then we need to add some method to test whether the target handler has been garbage collected and will have one more instance for each created WeakEventHandler. So extending WeakReference seemed to me worth considering. On the other hand having additional test method is more consistent with Weak*Listener from javafx-beans so we will probably end up with it. As to the public constructor, I don't like having both (the factory method and constructor) and in this case the factory method seems to be easier to use. >>>> >>>>> What were the problems with WeakEventHandler being an interface? >>>>> >>>> When somebody wants to register a single event handler weakly multiple times, in the case of WeakEventHandler as a wrapper (the first case), he needs only to create a single instance of it and register it multiple types. In the case of WeakEventHandler as a marker (the second case), each time he registers such event handler a new instance of weak reference needs to be created by the container for it. Also if such weak event handler is set to an event handler property (for example Node.setOnMousePressed), the property implementation needs to be ready for it and create a weak reference to it. Then when such event handler is finally garbage collected, the property needs to return null and ideally at the point of garbage collection it should notify its listeners (if any) about value change. >>>> >>>>> Thanks! >>>>> Richard >>>> Lubo >>>> From goddard at seznam.cz Wed Jun 20 04:59:49 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Wed, 20 Jun 2012 13:59:49 +0200 (CEST) Subject: =?us-ascii?Q?Path=20from=20a=20Stroke?= Message-ID: <129901.5482.25209-14925-386715944-1340193589@seznam.cz> Hello, how to get a Path from a Stroke? Let's say I have a Rectangle with Stroke around it, and I would like to get a Path from it. Regards, Jiri From pedro.duquevieira at gmail.com Wed Jun 20 08:20:42 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 20 Jun 2012 16:20:42 +0100 Subject: 18 month release cycle.. Message-ID: > > ...Unlike the JDK, our code doesn't yet require JSR or JCP approvals. That > is why we were aiming for making JavaFX a part of standard Java in Java 9 > timeframe so that by the time we got there FX would be mature enough to be > able to handle 18month release cycles between new features (for anything > that is part of JavaSE, you can only add new API on major releases, whereas > since FX is not yet part of the Java specification, we can make updates any > time)... > Hi Richard, Sorry to meddle in the conversation.. 18 month for a release cycle? That sounds like too much, even for something that is mature. I think one of the big advantages of javafx is it's short release cycle. Thanks, best regards, -- Pedro Duque Vieira From hang.vo at oracle.com Wed Jun 20 09:33:34 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Jun 2012 16:33:34 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22653 : ScrollBar with -fx-border styles is drawn wrong in 2.2 Message-ID: <20120620163338.11C2247A33@hg.openjdk.java.net> Changeset: 40920694bc2a Author: mickf Date: 2012-06-20 17:23 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/40920694bc2a RT-22653 : ScrollBar with -fx-border styles is drawn wrong in 2.2 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java From steve.x.northover at oracle.com Wed Jun 20 09:42:41 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Wed, 20 Jun 2012 12:42:41 -0400 Subject: The need for a FixedText control In-Reply-To: <692664FC-3291-4518-A7C1-C5883782DF96@oracle.com> References: <4FDB77C7.4090903@rockit.dk> <692664FC-3291-4518-A7C1-C5883782DF96@oracle.com> Message-ID: <4FE1FD81.5090703@oracle.com> Even if you take the first approach, you will still need a way to turn off the default behavior in the (rare) case where you actually want to show the markup. Steve On 15/06/2012 2:57 PM, Richard Bair wrote: > I would just use a Label. The use of labelFor is optional, and without it, it is exactly what you're looking for (pending support for rich text, more in a second). I don't think adding a new class / control for the use case is justified when you can just use a Label for it. > > Now, what I've wanted (and hopefully will get in Lombard) is the ability to set rich text on any Labeled. So on a Label, Button, CheckBox, etc you would be able to set rich text. There have been two ideas, principally, around this. The first is to just semantically inspect the string, much like Swing, such that "RichText" ends up being handled properly. The second idea is to add a "contentType" property, such that you can set the contentType to TEXT_HTML (or whatever) and then we know what to interpret the String of characters as. > > The benefit of the first approach is that it requires less tinkering and we don't have to figure out what the "content type" is (do we just reuse javafx.scene.input.DataFormat? It has HTML, PLAIN_TEXT, RTF, etc. FILES and IMAGE don't make sense, but what the heck). We would just have built in support for HTML and that's it. > > The benefit for the second approach is that it is (a) clear how you intend for the string to be interpreted and (b) extensible. We could add new supported formats (such as, for example, bbcode or something) and it would still be as easy to set. Basically you just set the string and tell us how to interpret it, and for supported formats, this would just work. > > Richard > > > > On Jun 15, 2012, at 10:58 AM, Randahl Fink Isaksen wrote: > >> I think JavaFX is missing a text control for presenting uneditable, styled text - a FixedText control. As I am about to file a feature request, I thought it would be relevant to discuss it here first. >> >> In the following UI the left column shows three labels implemented using Label, and the the right column has a field showing the Customer ID, a CheckBox for editing the VIP status of the customer, and finally a TextField for adding some kind of note about the VIP status: >> >> Customer ID: 12345678 (non-editable text) >> VIP: [x] (editable CheckBox) >> VIP note: |_________| (editable TextField >> >> In this UI, the user is always able to edit the VIP CheckBox, and if it is checked, the previously uneditable VIP note TextField becomes editable. The customer ID is never editable. So what component do we choose when implementing the uneditable customer ID field? Our options are: >> >> 1. Implementing the customer ID field as a label. >> 2. Implementing the customer ID as a TextField which is marked uneditable. >> 3. Implementing the customer ID as a raw Text instance. >> >> None of these options are very pleasing: >> >> - 1. Using a label is semantically incorrect, since it does not label anything (the labelFor property would have no meaning). Also, it would at least require a special style class to distinguish it from real labels, and it would not be efficient to have to set this style class everywhere we have a non-editable text field. >> >> - 2. Using a TextField for which editable has been set to false is not that good an idea either - by default, TextFields are rendered as a box, which indicates that the user can input something here, at least at least in some situations (like the VIP status field above). Again, we would require special styling for it to look different from other real TextFields, and we would have to set a specific style class everywhere we had a non-editable text field. >> >> -3. Using a raw Text instance is a bad idea too, since it is not a real JavaFX Control, which means it does not automatically have a style class of "text", it is not skinnable, cannot be copied using mouse gestures, is not draggable, etc. >> >> So my thoughts are, that JavaFX could benefit from a FixedText control. This would work much like a TextField, only it would mean "a forever uneditable text control". It would by default have a style class of "fixed-text", the user would be able to mark and copy its contents, drag it, etc. - just like the contents of a TextField. >> >> Any thoughts? >> >> Randahl From hang.vo at oracle.com Wed Jun 20 11:03:31 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Jun 2012 18:03:31 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22650 : ListView hides -fx-border in 2.2 Message-ID: <20120620180334.47D8347A35@hg.openjdk.java.net> Changeset: bd662b49adec Author: mickf Date: 2012-06-20 18:57 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/bd662b49adec RT-22650 : ListView hides -fx-border in 2.2 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java From steve.x.northover at oracle.com Wed Jun 20 12:03:21 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Wed, 20 Jun 2012 15:03:21 -0400 Subject: Region PickOnBounds default setting In-Reply-To: References: Message-ID: <4FE21E79.8070505@oracle.com> It's a shame but at this point, people are relying on the current value of the resource. The fact that we would need to change our skins highlights this. Steve On 19/06/2012 3:41 PM, Richard Bair wrote: > Hi folks, > > We have an issue which has been in the platform from before 2.0: http://javafx-jira.kenai.com/browse/RT-17024. A better explanation of the issue can be found on http://javafx-jira.kenai.com/browse/RT-12258. From 12258: > >> Region behaves counter-intuitively regarding mouse event delivering. It reacts on mouse events everywhere in its bounds and people are often confused by it. Here are two simple examples: >> >> 1) You create let's say HBox just because you want it to layout its children. The HBox catches all mouse events in the whole area given by its bounds. Often it's hard to understand what area it is (with children of different size or with some other layout stretches taking place). >> >> 2) You create a small Pane in top-left corner of the scene with a child in bottom-right corner of the scene. Pane's bounds will then cover whole sceen and you won't be able to click on anything else than the pane and its child. Users don't understand why, because both visually and in source code there is nothing in between the pane and the child. >> >> Moreover, region may have a shape associated and the behavior here is also strange. If you create a region with a shape inside its bounds, it's just ignored. You can also create a shape somewhere else, then it extends region's bounds and it reacts on mouse click everywhere between the shape and the region. > > This issue has to do with the semantics of picking on a Region. For Region we have had pickOnBounds set to true by default, which yields the above behaviors. We can change it to false by default, but then need to update a bunch of skins (for example the up/down arrows of scroll bar, the thumb of a slider, the down arrow of a combo box button, etc) so that they switch back to having pickOnBounds set to true by default so that the target area for clicks is larger. We could just change the default for Pane and not for Region, although we use StackPane in Skins and would have to update them anyhow. It seems that for a normal layout container the behavior really should be pickOnBounds=false by default, but for UI controls usages and such you generally want it true. > > I'm not certain making this change is worth being backwards incompatible (semantically, binary compatibility would remain). But what do you think? > > Richard From tbee at tbee.org Wed Jun 20 12:23:00 2012 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 20 Jun 2012 21:23:00 +0200 Subject: Region PickOnBounds default setting In-Reply-To: <4FE21E79.8070505@oracle.com> References: <4FE21E79.8070505@oracle.com> Message-ID: <4FE22314.9040500@tbee.org> OTOH there still aren't too many JFX apps yet. The pain is bearable? Tom On 2012-06-20 21:03, steve.x.northover at oracle.com wrote: > It's a shame but at this point, people are relying on the current value of the resource. The fact that we would need to change our skins highlights this. > > Steve > > On 19/06/2012 3:41 PM, Richard Bair wrote: >> Hi folks, >> >> We have an issue which has been in the platform from before 2.0: http://javafx-jira.kenai.com/browse/RT-17024. A better explanation of the issue can be found on http://javafx-jira.kenai.com/browse/RT-12258. From 12258: >> >>> Region behaves counter-intuitively regarding mouse event delivering. It reacts on mouse events everywhere in its bounds and people are often confused by it. Here are two simple examples: >>> >>> 1) You create let's say HBox just because you want it to layout its children. The HBox catches all mouse events in the whole area given by its bounds. Often it's hard to understand what area it is (with children of different size or with some other layout stretches taking place). >>> >>> 2) You create a small Pane in top-left corner of the scene with a child in bottom-right corner of the scene. Pane's bounds will then cover whole sceen and you won't be able to click on anything else than the pane and its child. Users don't understand why, because both visually and in source code there is nothing in between the pane and the child. >>> >>> Moreover, region may have a shape associated and the behavior here is also strange. If you create a region with a shape inside its bounds, it's just ignored. You can also create a shape somewhere else, then it extends region's bounds and it reacts on mouse click everywhere between the shape and the region. >> >> This issue has to do with the semantics of picking on a Region. For Region we have had pickOnBounds set to true by default, which yields the above behaviors. We can change it to false by default, but then need to update a bunch of skins (for example the up/down arrows of scroll bar, the thumb of a slider, the down arrow of a combo box button, etc) so that they switch back to having pickOnBounds set to true by default so that the target area for clicks is larger. We could just change the default for Pane and not for Region, although we use StackPane in Skins and would have to update them anyhow. It seems that for a normal layout container the behavior really should be pickOnBounds=false by default, but for UI controls usages and such you generally want it true. >> >> I'm not certain making this change is worth being backwards incompatible (semantically, binary compatibility would remain). But what do you think? >> >> Richard From richard.bair at oracle.com Wed Jun 20 12:48:16 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 20 Jun 2012 12:48:16 -0700 Subject: The need for a FixedText control In-Reply-To: <4FE1FD81.5090703@oracle.com> References: <4FDB77C7.4090903@rockit.dk> <692664FC-3291-4518-A7C1-C5883782DF96@oracle.com> <4FE1FD81.5090703@oracle.com> Message-ID: That's correct, it just gets more cumbersome (having to escape the tag or something for example). Or I guess it could be some API, I hadn't thought of that. disableHTMLParsing. But for compatibility it would have to be set to true, so maybe have enableHTML and then having to specify the HTML string. Personally I liked having setContentType and making it more open ended. Richard On Jun 20, 2012, at 9:42 AM, steve.x.northover at oracle.com wrote: > Even if you take the first approach, you will still need a way to turn off the default behavior in the (rare) case where you actually want to show the markup. > > Steve > > On 15/06/2012 2:57 PM, Richard Bair wrote: >> I would just use a Label. The use of labelFor is optional, and without it, it is exactly what you're looking for (pending support for rich text, more in a second). I don't think adding a new class / control for the use case is justified when you can just use a Label for it. >> >> Now, what I've wanted (and hopefully will get in Lombard) is the ability to set rich text on any Labeled. So on a Label, Button, CheckBox, etc you would be able to set rich text. There have been two ideas, principally, around this. The first is to just semantically inspect the string, much like Swing, such that "RichText" ends up being handled properly. The second idea is to add a "contentType" property, such that you can set the contentType to TEXT_HTML (or whatever) and then we know what to interpret the String of characters as. >> >> The benefit of the first approach is that it requires less tinkering and we don't have to figure out what the "content type" is (do we just reuse javafx.scene.input.DataFormat? It has HTML, PLAIN_TEXT, RTF, etc. FILES and IMAGE don't make sense, but what the heck). We would just have built in support for HTML and that's it. >> >> The benefit for the second approach is that it is (a) clear how you intend for the string to be interpreted and (b) extensible. We could add new supported formats (such as, for example, bbcode or something) and it would still be as easy to set. Basically you just set the string and tell us how to interpret it, and for supported formats, this would just work. >> >> Richard >> >> >> >> On Jun 15, 2012, at 10:58 AM, Randahl Fink Isaksen wrote: >> >>> I think JavaFX is missing a text control for presenting uneditable, styled text - a FixedText control. As I am about to file a feature request, I thought it would be relevant to discuss it here first. >>> >>> In the following UI the left column shows three labels implemented using Label, and the the right column has a field showing the Customer ID, a CheckBox for editing the VIP status of the customer, and finally a TextField for adding some kind of note about the VIP status: >>> >>> Customer ID: 12345678 (non-editable text) >>> VIP: [x] (editable CheckBox) >>> VIP note: |_________| (editable TextField >>> >>> In this UI, the user is always able to edit the VIP CheckBox, and if it is checked, the previously uneditable VIP note TextField becomes editable. The customer ID is never editable. So what component do we choose when implementing the uneditable customer ID field? Our options are: >>> >>> 1. Implementing the customer ID field as a label. >>> 2. Implementing the customer ID as a TextField which is marked uneditable. >>> 3. Implementing the customer ID as a raw Text instance. >>> >>> None of these options are very pleasing: >>> >>> - 1. Using a label is semantically incorrect, since it does not label anything (the labelFor property would have no meaning). Also, it would at least require a special style class to distinguish it from real labels, and it would not be efficient to have to set this style class everywhere we have a non-editable text field. >>> >>> - 2. Using a TextField for which editable has been set to false is not that good an idea either - by default, TextFields are rendered as a box, which indicates that the user can input something here, at least at least in some situations (like the VIP status field above). Again, we would require special styling for it to look different from other real TextFields, and we would have to set a specific style class everywhere we had a non-editable text field. >>> >>> -3. Using a raw Text instance is a bad idea too, since it is not a real JavaFX Control, which means it does not automatically have a style class of "text", it is not skinnable, cannot be copied using mouse gestures, is not draggable, etc. >>> >>> So my thoughts are, that JavaFX could benefit from a FixedText control. This would work much like a TextField, only it would mean "a forever uneditable text control". It would by default have a style class of "fixed-text", the user would be able to mark and copy its contents, drag it, etc. - just like the contents of a TextField. >>> >>> Any thoughts? >>> >>> Randahl From richard.bair at oracle.com Wed Jun 20 12:54:09 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 20 Jun 2012 12:54:09 -0700 Subject: 18 month release cycle.. In-Reply-To: References: Message-ID: <4160F1B3-AE57-43E6-8C4D-51CF629BE662@oracle.com> That is a JCP issue. If JavaFX never becomes part of the standard, then we limit reach, but can have quicker release cycles. If JavaFX becomes part of the standard, we get better reach but longer release cycles (for features). Of course bug fixes can go into update releases. We are aiming for something like Java 9 for standardization so that by the time we get there we'll be able to handle the longer cycles. Short of "fixing" the JCP, I'm not sure there are any good alternatives. On Jun 20, 2012, at 8:20 AM, Pedro Duque Vieira wrote: >> >> ...Unlike the JDK, our code doesn't yet require JSR or JCP approvals. That >> is why we were aiming for making JavaFX a part of standard Java in Java 9 >> timeframe so that by the time we got there FX would be mature enough to be >> able to handle 18month release cycles between new features (for anything >> that is part of JavaSE, you can only add new API on major releases, whereas >> since FX is not yet part of the Java specification, we can make updates any >> time)... >> > > > Hi Richard, > > Sorry to meddle in the conversation.. > 18 month for a release cycle? That sounds like too much, even for something > that is mature. I think one of the big advantages of javafx is it's short > release cycle. > > Thanks, best regards, > > -- > Pedro Duque Vieira From zonski at googlemail.com Wed Jun 20 12:55:20 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Thu, 21 Jun 2012 05:55:20 +1000 Subject: Region PickOnBounds default setting In-Reply-To: <4FE185F4.9020407@oracle.com> References: <4FE185F4.9020407@oracle.com> Message-ID: >> Assuming I understand the problem then I've hit this sort of layout problem and my instinct was to look >> I'm not sure I agree with the bug description when it says that "both visually and in source code there is nothing in between the pane and the child". In code there is a pane. Visually there would be a pane if you set styles on it. > > The pane from the description is small and is in a top-left corner. It can be styled, and you can see it there. There is no code that would make the pane big to cover the whole scene, there is no way to make it visible in the whole area, because it's just not there. I am perhaps missing something, but "Pane's bounds will then cover whole sceen" implies to me the pane is stretched, so if I styled it I would see it stretched. The description of #2 is a bit vague to me though. I guess a code example would clear this up but it probably doesn't matter that I dont understand. >> I'm guessing, for example, if this fix went in it would break all my 'glasspanes'? > > I cannot say unless I know how your glasspanes are implemented... I use glass panes to block the screen in two cases: when loading and behind a light box (ie embedded dialog). In both cases my glass pane is just a pane (eg BorderPane) added to the top of a StackPane with the rest of the app added to a lower layer of the stack. In the loading case it has no children, in the dialog case it's child is the dialog. The loading one is transparent but has an in-progress cursor when you mouse over. In the dialog case, the pane is a translucent grey, though you could style it differently and transparent would be a valid style (making the fill color define if it is clickable would not be nice for me and is a little scary). In both cases the point of it is that it blocks mouse input to the scene. I'd prefer this didn't break in a future release (sorry!). If auto updating (my nemesis) wasn't on then I'd be ok for it to change and then I fix my apps before moving to a higher version but it magically working one day and not the next would be pretty nasty for me. >> As such, I don't think it needs to be a default attribute now that it's in place the other way round but I do think it needs to be clear and intuitive how to deal with it. > > I'm really sad that we've let this go that far, it could have been fixed before our first release. If the decision comes that it's too late by now, the way how to deal with it will be clear (setPickOnBounds(false)), but I doubt it is (and could be) intuitive. For me the current default behavior seems intuitive: the pane is clickable for whatever area it takes up. I get the feeling I might be missing something here though as it is obviously a concern for some people. Sorry if I have misunderstood. For me the only problem with the current approach is that in some cases I'd like a pane used purely for layout (anchor pane as top layer of a StackPane is a prime candidate) to not catch mouse clicks but the children on it still should. Calling setPickOnBounds(false) and setShape(null) to do this is not intuitive to me but I'm glad I now know its possible as I've struggled with this before (and possibly raised a bug, will have to check). > > Thanks, > Pavel > >> >> >> On 20/06/2012, at 5:41 AM, Richard Bair wrote: >> >>> Hi folks, >>> >>> We have an issue which has been in the platform from before 2.0: http://javafx-jira.kenai.com/browse/RT-17024. A better explanation of the issue can be found on http://javafx-jira.kenai.com/browse/RT-12258. From 12258: >>> >>>> Region behaves counter-intuitively regarding mouse event delivering. It reacts on mouse events everywhere in its bounds and people are often confused by it. Here are two simple examples: >>>> >>>> 1) You create let's say HBox just because you want it to layout its children. The HBox catches all mouse events in the whole area given by its bounds. Often it's hard to understand what area it is (with children of different size or with some other layout stretches taking place). >>>> >>>> 2) You create a small Pane in top-left corner of the scene with a child in bottom-right corner of the scene. Pane's bounds will then cover whole sceen and you won't be able to click on anything else than the pane and its child. Users don't understand why, because both visually and in source code there is nothing in between the pane and the child. >>>> >>>> Moreover, region may have a shape associated and the behavior here is also strange. If you create a region with a shape inside its bounds, it's just ignored. You can also create a shape somewhere else, then it extends region's bounds and it reacts on mouse click everywhere between the shape and the region. >>> >>> This issue has to do with the semantics of picking on a Region. For Region we have had pickOnBounds set to true by default, which yields the above behaviors. We can change it to false by default, but then need to update a bunch of skins (for example the up/down arrows of scroll bar, the thumb of a slider, the down arrow of a combo box button, etc) so that they switch back to having pickOnBounds set to true by default so that the target area for clicks is larger. We could just change the default for Pane and not for Region, although we use StackPane in Skins and would have to update them anyhow. It seems that for a normal layout container the behavior really should be pickOnBounds=false by default, but for UI controls usages and such you generally want it true. >>> >>> I'm not certain making this change is worth being backwards incompatible (semantically, binary compatibility would remain). But what do you think? >>> >>> Richard From richard.bair at oracle.com Wed Jun 20 12:57:29 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 20 Jun 2012 12:57:29 -0700 Subject: Path from a Stroke In-Reply-To: <129901.5482.25209-14925-386715944-1340193589@seznam.cz> References: <129901.5482.25209-14925-386715944-1340193589@seznam.cz> Message-ID: <821C1AEF-E84E-426E-8E9F-0124A3332775@oracle.com> Hi, Presently I don't know of any way to do that with our current API directly. You'd have to construct a new path with the equivalent properties, I would guess. Richard On Jun 20, 2012, at 4:59 AM, goddard at seznam.cz wrote: > Hello, > > how to get a Path from a Stroke? > Let's say I have a Rectangle with Stroke around it, and I would like to get a Path from it. > > Regards, Jiri From pedro.duquevieira at gmail.com Wed Jun 20 12:59:17 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 20 Jun 2012 20:59:17 +0100 Subject: 18 month release cycle.. In-Reply-To: <4160F1B3-AE57-43E6-8C4D-51CF629BE662@oracle.com> References: <4160F1B3-AE57-43E6-8C4D-51CF629BE662@oracle.com> Message-ID: Ok, I understand the trade off. Hope Oracle fixes the JCP than :) Best regards, On Wed, Jun 20, 2012 at 8:54 PM, Richard Bair wrote: > That is a JCP issue. If JavaFX never becomes part of the standard, then we > limit reach, but can have quicker release cycles. If JavaFX becomes part of > the standard, we get better reach but longer release cycles (for features). > Of course bug fixes can go into update releases. We are aiming for > something like Java 9 for standardization so that by the time we get there > we'll be able to handle the longer cycles. Short of "fixing" the JCP, I'm > not sure there are any good alternatives. > > On Jun 20, 2012, at 8:20 AM, Pedro Duque Vieira wrote: > > >> > >> ...Unlike the JDK, our code doesn't yet require JSR or JCP approvals. > That > >> is why we were aiming for making JavaFX a part of standard Java in Java > 9 > >> timeframe so that by the time we got there FX would be mature enough to > be > >> able to handle 18month release cycles between new features (for anything > >> that is part of JavaSE, you can only add new API on major releases, > whereas > >> since FX is not yet part of the Java specification, we can make updates > any > >> time)... > >> > > > > > > Hi Richard, > > > > Sorry to meddle in the conversation.. > > 18 month for a release cycle? That sounds like too much, even for > something > > that is mature. I think one of the big advantages of javafx is it's short > > release cycle. > > > > Thanks, best regards, > > > > -- > > Pedro Duque Vieira > > -- Pedro Duque Vieira From richard.bair at oracle.com Wed Jun 20 12:59:54 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 20 Jun 2012 12:59:54 -0700 Subject: API REVIEW: Weak event handler In-Reply-To: <4FE19728.4050201@oracle.com> References: <4FD72C57.1040609@oracle.com> <934EC5B5-0318-4580-B000-AFCA69E62384@oracle.com> <4FD87203.70203@oracle.com> <4FDB10B3.1080205@oracle.com> <4FDB3A70.6040703@xs4all.nl> <4FE19728.4050201@oracle.com> Message-ID: That's fine. We may want to reconfigure things -- although beans may need something in javafx-common, it seems it doesn't require events. People may want to use beans in another project (ie: server side) that doesn't need events at all. Richard On Jun 20, 2012, at 2:26 AM, Lubomir Nerad wrote: > > > On 6/19/2012 8:49 PM, Richard Bair wrote: >> So I talked to Jasper, and I like this later approach. >> >> Thanks >> Richard >> >> PS> Possibly it could implement WeakListener as well, though that forms a new relation between javafx-common and javafx-beans, though for all practical purposes no JavaFX app can exist without javafx-beans anyway. >> > > Currently that would create bidirectional dependency between javafx-common and javafx-beans (javafx-beans uses some classes/interfaces from javafx-common in its public API). I'd rather leave it as it is for now. > > Thanks, > Lubo > > >> On Jun 15, 2012, at 6:36 AM, John Hendrikx wrote: >> >>> I can't speak for Richard, but this looks very much in line with the existing WeakChangeListener and WeakInvalidationListener -- I think it's good to do this one in a similar fashion for consistency. >>> >>> --John >>> >>> On 15/06/2012 12:38, Lubomir Nerad wrote: >>>> Hi Richard, >>>> >>>> haven't got any answer from you. I would like to make some progress with this, so here is an updated WeakEventHandler, which should be more to your liking: >>>> >>>> public final class WeakEventHandler >>>> implements EventHandler { >>>> public WeakEventHandler(EventHandler eventHandler) { ... } >>>> >>>> public boolean wasGarbageCollected() { ... } >>>> >>>> @Override public void handle(T event) { ... } >>>> } >>>> >>>> I removed WeakReference and the factory method, added the additional test method (as in WeakListener) and the public constructor. >>>> >>>> Is it OK now? >>>> >>>> Thanks, >>>> Lubo >>>> >>>> On 6/13/2012 12:57 PM, Lubomir Nerad wrote: >>>>> Hi Richard, >>>>> >>>>> On 6/12/2012 10:01 PM, Richard Bair wrote: >>>>>> Hi Lubo, >>>>>> >>>>>>> I also considered to define the WeakEventHandler as an interface which extends EventHandler, but adds no additional methods. Then leave it to event handler containers to reference such event handlers weakly. This has very simple and direct usage, but also its own problems. We can discuss it further if you find this solution preferred to the wrapper approach. >>>>>> Extending WeakReference and lacking the public constructor did make me a little weak in the knees :-). >>>>> Well, we can of course remove WeakReference from extends and have it as an instance in WeakEventHandler. But then we need to add some method to test whether the target handler has been garbage collected and will have one more instance for each created WeakEventHandler. So extending WeakReference seemed to me worth considering. On the other hand having additional test method is more consistent with Weak*Listener from javafx-beans so we will probably end up with it. As to the public constructor, I don't like having both (the factory method and constructor) and in this case the factory method seems to be easier to use. >>>>> >>>>>> What were the problems with WeakEventHandler being an interface? >>>>>> >>>>> When somebody wants to register a single event handler weakly multiple times, in the case of WeakEventHandler as a wrapper (the first case), he needs only to create a single instance of it and register it multiple types. In the case of WeakEventHandler as a marker (the second case), each time he registers such event handler a new instance of weak reference needs to be created by the container for it. Also if such weak event handler is set to an event handler property (for example Node.setOnMousePressed), the property implementation needs to be ready for it and create a weak reference to it. Then when such event handler is finally garbage collected, the property needs to return null and ideally at the point of garbage collection it should notify its listeners (if any) about value change. >>>>> >>>>>> Thanks! >>>>>> Richard >>>>> Lubo >>>>> From richard.bair at oracle.com Wed Jun 20 13:08:26 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 20 Jun 2012 13:08:26 -0700 Subject: Region PickOnBounds default setting In-Reply-To: References: <4FE185F4.9020407@oracle.com> Message-ID: <9E95EA53-3FE1-403F-AF37-C2A88054AA41@oracle.com> >>> As such, I don't think it needs to be a default attribute now that it's in place the other way round but I do think it needs to be clear and intuitive how to deal with it. >> >> I'm really sad that we've let this go that far, it could have been fixed before our first release. If the decision comes that it's too late by now, the way how to deal with it will be clear (setPickOnBounds(false)), but I doubt it is (and could be) intuitive. > > For me the current default behavior seems intuitive: the pane is clickable for whatever area it takes up. I get the feeling I might be missing something here though as it is obviously a concern for some people. Sorry if I have misunderstood. > > For me the only problem with the current approach is that in some cases I'd like a pane used purely for layout (anchor pane as top layer of a StackPane is a prime candidate) to not catch mouse clicks but the children on it still should. Calling setPickOnBounds(false) and setShape(null) to do this is not intuitive to me but I'm glad I now know its possible as I've struggled with this before (and possibly raised a bug, will have to check). You shouldn't have to setShape(null), just setPickOnBounds(false)? Richard From zonski at googlemail.com Wed Jun 20 13:12:56 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Thu, 21 Jun 2012 06:12:56 +1000 Subject: 18 month release cycle.. In-Reply-To: <4160F1B3-AE57-43E6-8C4D-51CF629BE662@oracle.com> References: <4160F1B3-AE57-43E6-8C4D-51CF629BE662@oracle.com> Message-ID: <346DF77F-AFB3-4F15-AB25-695DD1C8C89D@gmail.com> I've raised this idea a few times before and the silence was deafening, but: I don't believe jfx should be part of the JRE. I think some minimal core components could be, eg prism and base media stuff (ie anything that is 'OS' level - since that's what the JRE is, a virtual OS) but everything else should just be a nice normal, external library. Still built by you guys, still owned by Oracle, still 'official' - just not hard wired in. Spring, hibernate, struts, GWT, etc, have no problems of 'reach' despite not being part of the jre. They achieve reach by being awesome, as would jfx. I understand there are political advantages but the technical advantages of co-bundling are close to none (the only one: I don't have to include a jar on my path). The disadvantages however are significant: slave to auto-updating, hampered release cycle, limitations on external libraries that can be used, etc, etc. Anyway, I'm fully expecting for this rant to have no real impact, and I'm ok with that. Just feel the need to say my piece and now I can go back to my rocking chair and mutter to myself ;) On 21/06/2012, at 5:54 AM, Richard Bair wrote: > That is a JCP issue. If JavaFX never becomes part of the standard, then we limit reach, but can have quicker release cycles. If JavaFX becomes part of the standard, we get better reach but longer release cycles (for features). Of course bug fixes can go into update releases. We are aiming for something like Java 9 for standardization so that by the time we get there we'll be able to handle the longer cycles. Short of "fixing" the JCP, I'm not sure there are any good alternatives. > > On Jun 20, 2012, at 8:20 AM, Pedro Duque Vieira wrote: > >>> >>> ...Unlike the JDK, our code doesn't yet require JSR or JCP approvals. That >>> is why we were aiming for making JavaFX a part of standard Java in Java 9 >>> timeframe so that by the time we got there FX would be mature enough to be >>> able to handle 18month release cycles between new features (for anything >>> that is part of JavaSE, you can only add new API on major releases, whereas >>> since FX is not yet part of the Java specification, we can make updates any >>> time)... >>> >> >> >> Hi Richard, >> >> Sorry to meddle in the conversation.. >> 18 month for a release cycle? That sounds like too much, even for something >> that is mature. I think one of the big advantages of javafx is it's short >> release cycle. >> >> Thanks, best regards, >> >> -- >> Pedro Duque Vieira > From steve.x.northover at oracle.com Wed Jun 20 13:13:20 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Wed, 20 Jun 2012 16:13:20 -0400 Subject: The need for a FixedText control In-Reply-To: References: <4FDB77C7.4090903@rockit.dk> <692664FC-3291-4518-A7C1-C5883782DF96@oracle.com> <4FE1FD81.5090703@oracle.com> Message-ID: <4FE22EE0.5060801@oracle.com> setContentType (the second approach) is good in that it allows HTML parsing to be controlled. If the default is "true" (or "content type html"), then you get the first approach and the ability to turn it off. Steve On 20/06/2012 3:48 PM, Richard Bair wrote: > That's correct, it just gets more cumbersome (having to escape the tag or something for example). Or I guess it could be some API, I hadn't thought of that. disableHTMLParsing. But for compatibility it would have to be set to true, so maybe have enableHTML and then having to specify the HTML string. > > Personally I liked having setContentType and making it more open ended. > > Richard > > On Jun 20, 2012, at 9:42 AM, steve.x.northover at oracle.com wrote: > >> Even if you take the first approach, you will still need a way to turn off the default behavior in the (rare) case where you actually want to show the markup. >> >> Steve >> >> On 15/06/2012 2:57 PM, Richard Bair wrote: >>> I would just use a Label. The use of labelFor is optional, and without it, it is exactly what you're looking for (pending support for rich text, more in a second). I don't think adding a new class / control for the use case is justified when you can just use a Label for it. >>> >>> Now, what I've wanted (and hopefully will get in Lombard) is the ability to set rich text on any Labeled. So on a Label, Button, CheckBox, etc you would be able to set rich text. There have been two ideas, principally, around this. The first is to just semantically inspect the string, much like Swing, such that "RichText" ends up being handled properly. The second idea is to add a "contentType" property, such that you can set the contentType to TEXT_HTML (or whatever) and then we know what to interpret the String of characters as. >>> >>> The benefit of the first approach is that it requires less tinkering and we don't have to figure out what the "content type" is (do we just reuse javafx.scene.input.DataFormat? It has HTML, PLAIN_TEXT, RTF, etc. FILES and IMAGE don't make sense, but what the heck). We would just have built in support for HTML and that's it. >>> >>> The benefit for the second approach is that it is (a) clear how you intend for the string to be interpreted and (b) extensible. We could add new supported formats (such as, for example, bbcode or something) and it would still be as easy to set. Basically you just set the string and tell us how to interpret it, and for supported formats, this would just work. >>> >>> Richard >>> >>> >>> >>> On Jun 15, 2012, at 10:58 AM, Randahl Fink Isaksen wrote: >>> >>>> I think JavaFX is missing a text control for presenting uneditable, styled text - a FixedText control. As I am about to file a feature request, I thought it would be relevant to discuss it here first. >>>> >>>> In the following UI the left column shows three labels implemented using Label, and the the right column has a field showing the Customer ID, a CheckBox for editing the VIP status of the customer, and finally a TextField for adding some kind of note about the VIP status: >>>> >>>> Customer ID: 12345678 (non-editable text) >>>> VIP: [x] (editable CheckBox) >>>> VIP note: |_________| (editable TextField >>>> >>>> In this UI, the user is always able to edit the VIP CheckBox, and if it is checked, the previously uneditable VIP note TextField becomes editable. The customer ID is never editable. So what component do we choose when implementing the uneditable customer ID field? Our options are: >>>> >>>> 1. Implementing the customer ID field as a label. >>>> 2. Implementing the customer ID as a TextField which is marked uneditable. >>>> 3. Implementing the customer ID as a raw Text instance. >>>> >>>> None of these options are very pleasing: >>>> >>>> - 1. Using a label is semantically incorrect, since it does not label anything (the labelFor property would have no meaning). Also, it would at least require a special style class to distinguish it from real labels, and it would not be efficient to have to set this style class everywhere we have a non-editable text field. >>>> >>>> - 2. Using a TextField for which editable has been set to false is not that good an idea either - by default, TextFields are rendered as a box, which indicates that the user can input something here, at least at least in some situations (like the VIP status field above). Again, we would require special styling for it to look different from other real TextFields, and we would have to set a specific style class everywhere we had a non-editable text field. >>>> >>>> -3. Using a raw Text instance is a bad idea too, since it is not a real JavaFX Control, which means it does not automatically have a style class of "text", it is not skinnable, cannot be copied using mouse gestures, is not draggable, etc. >>>> >>>> So my thoughts are, that JavaFX could benefit from a FixedText control. This would work much like a TextField, only it would mean "a forever uneditable text control". It would by default have a style class of "fixed-text", the user would be able to mark and copy its contents, drag it, etc. - just like the contents of a TextField. >>>> >>>> Any thoughts? >>>> >>>> Randahl From joe.mcglynn at oracle.com Wed Jun 20 13:41:37 2012 From: joe.mcglynn at oracle.com (Joe Mcglynn) Date: Wed, 20 Jun 2012 13:41:37 -0700 (PDT) Subject: 18 month release cycle.. In-Reply-To: References: <4160F1B3-AE57-43E6-8C4D-51CF629BE662@oracle.com> Message-ID: <02778529-9235-4697-b115-5af130fdfbd5@default> I want to chime in here. Being part of the JDK and having 18 month release cycles for major releases doesn't mean that it's 18 months between features. New features can be added in "limited update" releases (think JDK 7 update 6, for example). -Joe -----Original Message----- From: Pedro Duque Vieira [mailto:pedro.duquevieira at gmail.com] Sent: Wednesday, June 20, 2012 12:59 PM To: Richard Bair Cc: OpenJFX Mailing List Subject: Re: 18 month release cycle.. Ok, I understand the trade off. Hope Oracle fixes the JCP than :) Best regards, On Wed, Jun 20, 2012 at 8:54 PM, Richard Bair wrote: > That is a JCP issue. If JavaFX never becomes part of the standard, > then we limit reach, but can have quicker release cycles. If JavaFX > becomes part of the standard, we get better reach but longer release cycles (for features). > Of course bug fixes can go into update releases. We are aiming for > something like Java 9 for standardization so that by the time we get > there we'll be able to handle the longer cycles. Short of "fixing" the > JCP, I'm not sure there are any good alternatives. > > On Jun 20, 2012, at 8:20 AM, Pedro Duque Vieira wrote: > > >> > >> ...Unlike the JDK, our code doesn't yet require JSR or JCP approvals. > That > >> is why we were aiming for making JavaFX a part of standard Java in > >> Java > 9 > >> timeframe so that by the time we got there FX would be mature > >> enough to > be > >> able to handle 18month release cycles between new features (for > >> anything that is part of JavaSE, you can only add new API on major > >> releases, > whereas > >> since FX is not yet part of the Java specification, we can make > >> updates > any > >> time)... > >> > > > > > > Hi Richard, > > > > Sorry to meddle in the conversation.. > > 18 month for a release cycle? That sounds like too much, even for > something > > that is mature. I think one of the big advantages of javafx is it's > > short release cycle. > > > > Thanks, best regards, > > > > -- > > Pedro Duque Vieira > > -- Pedro Duque Vieira From igor.nekrestyanov at oracle.com Wed Jun 20 13:59:04 2012 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Wed, 20 Jun 2012 13:59:04 -0700 Subject: 18 month release cycle.. In-Reply-To: <02778529-9235-4697-b115-5af130fdfbd5@default> References: <4160F1B3-AE57-43E6-8C4D-51CF629BE662@oracle.com> <02778529-9235-4697-b115-5af130fdfbd5@default> Message-ID: <4FE23998.4010707@oracle.com> On 6/20/12 1:41 PM, Joe Mcglynn wrote: > I want to chime in here. Being part of the JDK and having 18 month release cycles for major releases doesn't mean that it's 18 months between features. New features can be added in "limited update" releases (think JDK 7 update 6, for example). But not new public APIs in the areas covered by Java spec? -igor > > -Joe > > -----Original Message----- > From: Pedro Duque Vieira [mailto:pedro.duquevieira at gmail.com] > Sent: Wednesday, June 20, 2012 12:59 PM > To: Richard Bair > Cc: OpenJFX Mailing List > Subject: Re: 18 month release cycle.. > > Ok, I understand the trade off. Hope Oracle fixes the JCP than :) > > Best regards, > > On Wed, Jun 20, 2012 at 8:54 PM, Richard Bairwrote: > >> That is a JCP issue. If JavaFX never becomes part of the standard, >> then we limit reach, but can have quicker release cycles. If JavaFX >> becomes part of the standard, we get better reach but longer release cycles (for features). >> Of course bug fixes can go into update releases. We are aiming for >> something like Java 9 for standardization so that by the time we get >> there we'll be able to handle the longer cycles. Short of "fixing" the >> JCP, I'm not sure there are any good alternatives. >> >> On Jun 20, 2012, at 8:20 AM, Pedro Duque Vieira wrote: >> >>>> ...Unlike the JDK, our code doesn't yet require JSR or JCP approvals. >> That >>>> is why we were aiming for making JavaFX a part of standard Java in >>>> Java >> 9 >>>> timeframe so that by the time we got there FX would be mature >>>> enough to >> be >>>> able to handle 18month release cycles between new features (for >>>> anything that is part of JavaSE, you can only add new API on major >>>> releases, >> whereas >>>> since FX is not yet part of the Java specification, we can make >>>> updates >> any >>>> time)... >>>> >>> >>> Hi Richard, >>> >>> Sorry to meddle in the conversation.. >>> 18 month for a release cycle? That sounds like too much, even for >> something >>> that is mature. I think one of the big advantages of javafx is it's >>> short release cycle. >>> >>> Thanks, best regards, >>> >>> -- >>> Pedro Duque Vieira >> > > -- > Pedro Duque Vieira From hang.vo at oracle.com Wed Jun 20 14:33:30 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Jun 2012 21:33:30 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22717: TabPane does not update its selection model after removing the selected Tab. Message-ID: <20120620213332.B1CCF47A41@hg.openjdk.java.net> Changeset: 88f62d205d2a Author: Kinsley Wong Date: 2012-06-20 14:18 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/88f62d205d2a RT-22717: TabPane does not update its selection model after removing the selected Tab. ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java From joe.mcglynn at oracle.com Wed Jun 20 14:58:02 2012 From: joe.mcglynn at oracle.com (Joe Mcglynn) Date: Wed, 20 Jun 2012 14:58:02 -0700 (PDT) Subject: 18 month release cycle.. In-Reply-To: <4FE23998.4010707@oracle.com> References: <4160F1B3-AE57-43E6-8C4D-51CF629BE662@oracle.com> <02778529-9235-4697-b115-5af130fdfbd5@default> <4FE23998.4010707@oracle.com> Message-ID: <4beadd40-f41b-44be-bba7-06b0408286e0@default> Correct, thanks for the clarification. -----Original Message----- But not new public APIs in the areas covered by Java spec? -igor From james.graham at oracle.com Wed Jun 20 15:17:55 2012 From: james.graham at oracle.com (Jim Graham) Date: Wed, 20 Jun 2012 15:17:55 -0700 Subject: Path from a Stroke In-Reply-To: <129901.5482.25209-14925-386715944-1340193589@seznam.cz> References: <129901.5482.25209-14925-386715944-1340193589@seznam.cz> Message-ID: <4FE24C13.1010609@oracle.com> Please file a Jira issue so we can track this. I don't believe there is one currently... ...jim On 6/20/2012 4:59 AM, goddard at seznam.cz wrote: > Hello, > > how to get a Path from a Stroke? > Let's say I have a Rectangle with Stroke around it, and I would like to get a Path from it. > > Regards, Jiri From hang.vo at oracle.com Wed Jun 20 16:48:51 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 20 Jun 2012 23:48:51 +0000 Subject: hg: openjfx/2.2/controls/rt: 5 new changesets Message-ID: <20120620234856.E9A0F47A52@hg.openjdk.java.net> Changeset: 1aa7c6fcca3e Author: jgiles Date: 2012-06-20 16:39 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/1aa7c6fcca3e RT-22630: ComboBox : exception when promptText is set ! javafx-ui-controls/src/javafx/scene/control/ComboBox.java Changeset: afda3a34df03 Author: jgiles Date: 2012-06-21 06:06 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/afda3a34df03 RT-21913: [CustomCellFactory] it's very hard to call custom cell editing state to appear. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java Changeset: 5ba7cfdaf636 Author: jgiles Date: 2012-06-21 06:20 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/5ba7cfdaf636 RT-20582: MenuItem's styleable has a null Node (fix for NPE) ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java Changeset: 6fc666adebea Author: jgiles Date: 2012-06-21 11:28 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/6fc666adebea RT-22572: ComboBox : value is removed when the popup is opened ! javafx-ui-controls/src/javafx/scene/control/ComboBox.java Changeset: 84acdf2dda4b Author: jgiles Date: 2012-06-21 11:35 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/84acdf2dda4b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt From hang.vo at oracle.com Wed Jun 20 23:18:39 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 21 Jun 2012 06:18:39 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-20300: TableView is not refreshed when TableColumn are added dynamically Message-ID: <20120621061841.1C4D547A5C@hg.openjdk.java.net> Changeset: c390ada3dfd5 Author: jgiles Date: 2012-06-21 18:07 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/c390ada3dfd5 RT-20300: TableView is not refreshed when TableColumn are added dynamically ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableHeaderRow.java From goddard at seznam.cz Thu Jun 21 01:42:13 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Thu, 21 Jun 2012 10:42:13 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Re=3A=20Path=20from=20a=20Stroke?= In-Reply-To: <4FE24C13.1010609@oracle.com> Message-ID: <129960.5116.25064-1010-328274584-1340268133@seznam.cz> Thanks for the replies. I filed http://javafx-jira.kenai.com/browse/RT-22745 In the meantime, I'll construct the Path from properties. Sounds like a good idea for JFXtras :) Regards, Jiri ------------ P?vodn? zpr?va ------------ Od: Jim Graham P?edm?t: Re: Path from a Stroke Datum: 21.6.2012 00:18:02 ---------------------------------------- Please file a Jira issue so we can track this. I don't believe there is one currently... ...jim On 6/20/2012 4:59 AM, goddard at seznam.cz wrote: > Hello, > > how to get a Path from a Stroke? > Let's say I have a Rectangle with Stroke around it, and I would like to get a Path from it. > > Regards, Jiri From pavel.safrata at oracle.com Thu Jun 21 01:44:37 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 21 Jun 2012 10:44:37 +0200 Subject: Region PickOnBounds default setting In-Reply-To: References: <4FE185F4.9020407@oracle.com> Message-ID: <4FE2DEF5.8080209@oracle.com> Hi Daniel, On 20.6.2012 21:55, Daniel Zwolenski wrote: >>> Assuming I understand the problem then I've hit this sort of layout problem and my instinct was to look >>> I'm not sure I agree with the bug description when it says that "both visually and in source code there is nothing in between the pane and the child". In code there is a pane. Visually there would be a pane if you set styles on it. >> The pane from the description is small and is in a top-left corner. It can be styled, and you can see it there. There is no code that would make the pane big to cover the whole scene, there is no way to make it visible in the whole area, because it's just not there. > I am perhaps missing something, but "Pane's bounds will then cover whole sceen" implies to me the pane is stretched, so if I styled it I would see it stretched. The description of #2 is a bit vague to me though. I guess a code example would clear this up but it probably doesn't matter that I dont understand. The pane is not necessarily stretched to embrace all its children. I've attached a code example that shows the problem. > >>> I'm guessing, for example, if this fix went in it would break all my 'glasspanes'? >> I cannot say unless I know how your glasspanes are implemented... > I use glass panes to block the screen in two cases: when loading and behind a light box (ie embedded dialog). > > In both cases my glass pane is just a pane (eg BorderPane) added to the top of a StackPane with the rest of the app added to a lower layer of the stack. In the loading case it has no children, in the dialog case it's child is the dialog. > > The loading one is transparent but has an in-progress cursor when you mouse over. In the dialog case, the pane is a translucent grey, though you could style it differently and transparent would be a valid style (making the fill color define if it is clickable would not be nice for me and is a little scary). > > In both cases the point of it is that it blocks mouse input to the scene. I'd prefer this didn't break in a future release (sorry!). If auto updating (my nemesis) wasn't on then I'd be ok for it to change and then I fix my apps before moving to a higher version but it magically working one day and not the next would be pretty nasty for me. It would break your glass panes only if they have no fill (which I agree is bad enough). Pane with transparent fill would still block mouse events. I'm not sure why this is scary, this approach is used everywhere in FX except of Region. > > >>> As such, I don't think it needs to be a default attribute now that it's in place the other way round but I do think it needs to be clear and intuitive how to deal with it. >> I'm really sad that we've let this go that far, it could have been fixed before our first release. If the decision comes that it's too late by now, the way how to deal with it will be clear (setPickOnBounds(false)), but I doubt it is (and could be) intuitive. > For me the current default behavior seems intuitive: the pane is clickable for whatever area it takes up. I get the feeling I might be missing something here though as it is obviously a concern for some people. Sorry if I have misunderstood. I think the attached example shows pane that is clickable in area that it doesn't take up. > > For me the only problem with the current approach is that in some cases I'd like a pane used purely for layout (anchor pane as top layer of a StackPane is a prime candidate) to not catch mouse clicks but the children on it still should. Calling setPickOnBounds(false) and setShape(null) to do this is not intuitive to me but I'm glad I now know its possible as I've struggled with this before (and possibly raised a bug, will have to check). This is exactly the most common problem that would be solved. You see you're glad that you now know how to solve it, but other users will keep bumping into this issue.. Thanks, Pavel > > >> Thanks, >> Pavel >> >>> >>> On 20/06/2012, at 5:41 AM, Richard Bair wrote: >>> >>>> Hi folks, >>>> >>>> We have an issue which has been in the platform from before 2.0: http://javafx-jira.kenai.com/browse/RT-17024. A better explanation of the issue can be found on http://javafx-jira.kenai.com/browse/RT-12258. From 12258: >>>> >>>>> Region behaves counter-intuitively regarding mouse event delivering. It reacts on mouse events everywhere in its bounds and people are often confused by it. Here are two simple examples: >>>>> >>>>> 1) You create let's say HBox just because you want it to layout its children. The HBox catches all mouse events in the whole area given by its bounds. Often it's hard to understand what area it is (with children of different size or with some other layout stretches taking place). >>>>> >>>>> 2) You create a small Pane in top-left corner of the scene with a child in bottom-right corner of the scene. Pane's bounds will then cover whole sceen and you won't be able to click on anything else than the pane and its child. Users don't understand why, because both visually and in source code there is nothing in between the pane and the child. >>>>> >>>>> Moreover, region may have a shape associated and the behavior here is also strange. If you create a region with a shape inside its bounds, it's just ignored. You can also create a shape somewhere else, then it extends region's bounds and it reacts on mouse click everywhere between the shape and the region. >>>> This issue has to do with the semantics of picking on a Region. For Region we have had pickOnBounds set to true by default, which yields the above behaviors. We can change it to false by default, but then need to update a bunch of skins (for example the up/down arrows of scroll bar, the thumb of a slider, the down arrow of a combo box button, etc) so that they switch back to having pickOnBounds set to true by default so that the target area for clicks is larger. We could just change the default for Pane and not for Region, although we use StackPane in Skins and would have to update them anyhow. It seems that for a normal layout container the behavior really should be pickOnBounds=false by default, but for UI controls usages and such you generally want it true. >>>> >>>> I'm not certain making this change is worth being backwards incompatible (semantically, binary compatibility would remain). But what do you think? >>>> >>>> Richard -------------- next part -------------- package test; import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.layout.Pane; import javafx.stage.Stage; public class EvilPane extends Application { @Override public void start(Stage stage) { stage.setTitle("Evil Pane"); Pane root = new Pane(); Pane evilPane = new Pane(); evilPane.setStyle("-fx-background-color: BLUE"); evilPane.setMaxSize(50, 50); // evilPane.setPickOnBounds(false); Button childButton = new Button("Child of the blue pane"); childButton.setLayoutX(300); childButton.setLayoutY(300); Button deadButton = new Button( "Cannot click this because blue pane covers it"); deadButton.setLayoutX(150); deadButton.setLayoutY(150); evilPane.getChildren().add(childButton); root.getChildren().addAll(deadButton, evilPane); Scene s = new Scene(root, 500, 500); stage.setScene(s); stage.show(); childButton.requestFocus(); } public static void main(String[] args) { launch(args); } } From martin.sladecek at oracle.com Thu Jun 21 01:58:26 2012 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Thu, 21 Jun 2012 10:58:26 +0200 Subject: javafx.scene.input.*Event classes construction In-Reply-To: <417604B2-2908-447B-A799-487D9156F616@oracle.com> References: <4FD9BF79.2020105@oracle.com> <4BF66087-0618-416D-9656-7C9BDFE5978E@oracle.com> <4FD9FB44.9030400@oracle.com> <417604B2-2908-447B-A799-487D9156F616@oracle.com> Message-ID: <4FE2E232.8090405@oracle.com> Hi, here's my proposal for new constructors and methods for events in javafx.scene.input package (for 3.0) I changed all impl_*event factory methods to constructors and added a variant with (Object source, EventTarget target, ...), as Event, InputEvent, GestureEvent already had such constructors as part of public API. Usually, these constructors are used only when the target (or source) is known, so no copies must be made during the event dispatch process. Because Event has a "copyFor" method that returns a copy of the current object, changing some properties to the values passed in, I used the same pattern for all the impl_copy methods. I also added copyFor(Object source, EvenTarget target, EventType type) to events that have multiple types. Regarding the rest of @treatAsPrivate methods, I think all of them may be part of public API, as they don't expose any internal information or structures. I also made most of the classes final. *ContextMenuEvent*: * public ContextMenuEvent(Object source, EventTarget target, EventType eventType, double x, double y, double screenX, double screenY, boolean keyboardTrigger) * public ContextMenuEvent(EventType eventType, double x, double y, double screenX, double screenY, boolean keyboardTrigger) *DragEvent*: * public DragEvent(Object source, EventTarget target, EventType eventType, Dragboard dragboard, double x, double y, double screenX, double screenY, TransferMode transferMode, Object gestureSource, Object gestureTarget) * public DragEvent(EventType eventType, Dragboard dragboard,double x, double y, double screenX, double screenY, TransferMode transferMode, Object gestureSource, Object gestureTarget) * public DragEvent copyFor(Object source, EventTarget target, Object gestureSource, Object gestureTarget, Dragboard dragboard) * public DragEvent copyFor(Object source, EventTarget target, Object gestureSource, Object gestureTarget, EventType eventType) * public DragEvent copyFor(Object source, EventTarget target, Object gestureSource, Object gestureTarget, TransferMode transferMode, EventType eventType) * public DragEvent copyFor(Object newSource, EventTarget newTarget, EventType type) * public Object getAcceptingObject() // source that accepted the drag *GestureEvent*: (there were 2 protected constructors that were creating empty events, I'd like to make them deprecated) * protected GestureEvent(Object source, EventTarget target, EventType eventType, double x, double y, double screenX, double screenY, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct, boolean inertia) * protected GestureEvent(EventType eventType, double x, double y, double screenX, double screenY, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct, boolean inertia) *InputMethodEvent*: * public InputMethodEvent(Object source, EventTarget target, EventType eventType, List composed, String committed, int caretPosition) *InputMethodTextRun*: * public InputMethodTextRun(String text, InputMethodHighlight highlight) *KeyEvent*: * public KeyEvent(Object source, EventTarget target, EventType eventType, String character, String text, int code, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown) * public KeyEvent(EventType eventType, String character, String text, int code, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown) * public KeyEvent(EventType eventType, String character, String text, KeyCode code, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown) * public KeyEvent copyFor(Object newSource, EventTarget newTarget, EventType type) *MouseEvent*: * public MouseEvent(EventType eventType, double x, double y, double screenX, double screenY, MouseButton button,int clickCount, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean primaryButtonDown, boolean middleButtonDown, boolean secondaryButtonDown, boolean synthesized, boolean popupTrigger) * public MouseEvent(EventType eventType, double x, double y, double screenX, double screenY, MouseButton button,int clickCount, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean primaryButtonDown, boolean middleButtonDown, boolean secondaryButtonDown, boolean synthesized, boolean popupTrigger, boolean stillSincePress) * public MouseEvent(Object source, EventTarget target, EventType eventType, double x, double y, double screenX, double screenY, MouseButton button,int clickCount, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean primaryButtonDown, boolean middleButtonDown, boolean secondaryButtonDown, boolean synthesized, boolean popupTrigger, boolean stillSincePress) * public MouseEvent copyFor(Object newSource, EventTarget newTarget, EventType type) * public boolean isPopupTrigger() //This was impl_ before, but it's used in some controls, so it might be useful * public static MouseDragEvent copyForMouseDragEvent(MouseEvent e, Object newSource, EventTarget newTarget, EventType type, Object gestureSource) // this will do a copy of mouse event, creating a mouseDragEvent from it. It's used internally and it's just a convenience, so can it doesn't have to be added at all to the public API *MouseDragEvent*: * public MouseDragEvent(Object source, EventTarget target, EventType eventType, double x, double y, double screenX, double screenY, MouseButton button, int clickCount, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean primaryButtonDown, boolean middleButtonDown, boolean secondaryButtonDown, boolean synthesized, boolean popupTrigger, Object gestureSource) * public MouseDragEvent( EventType eventType, double x, double y, double screenX, double screenY, MouseButton button, int clickCount, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean primaryButtonDown, boolean middleButtonDown, boolean secondaryButtonDown, boolean synthesized, boolean popupTrigger, Object gestureSource) *RotateEvent*: * public RotateEvent(Object source, EventTarget target, EventType eventType, double x, double y, double screenX, double screenY, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct, boolean inertia, double angle, double totalAngle) * public RotateEvent(EventType eventType, double x, double y, double screenX, double screenY, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct, boolean inertia, double angle, double totalAngle) * public RotateEvent copyFor(Object newSource, EventTarget newTarget, EventType type) *ScrollEvent*: * public ScrollEvent(Object source, EventTarget target, EventType eventType, double x, double y, double screenX, double screenY, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct, boolean inertia, double deltaX, double deltaY, double gestureDeltaX, double gestureDeltaY, HorizontalTextScrollUnits textDeltaXUnits, double textDeltaX, VerticalTextScrollUnits textDeltaYUnits, double textDeltaY, int touchCount) * public ScrollEvent(EventType eventType, double x, double y, double screenX, double screenY, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct, boolean inertia, double deltaX, double deltaY, double gestureDeltaX, double gestureDeltaY, HorizontalTextScrollUnits textDeltaXUnits, double textDeltaX, VerticalTextScrollUnits textDeltaYUnits, double textDeltaY, int touchCount) * public ScrollEvent copyFor(Object newSource, EventTarget newTarget, EventType type) *SwipeEvent*: * public SwipeEvent(Object source, EventTarget target, EventType eventType, double x, double y, double screenX, double screenY, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct, int touchCount) * public SwipeEvent(EventType eventType, double x, double y, double screenX, double screenY, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct, int touchCount) * public SwipeEvent copyFor(Object newSource, EventTarget newTarget, EventType type) *ZoomEvent*: * public ZoomEvent(Object source, EventTarget target, EventType eventType, double x, double y, double screenX, double screenY, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct, boolean inertia, double zoomFactor, double totalZoomFactor) * public ZoomEvent(EventType eventType, double x, double y, double screenX, double screenY, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct, boolean inertia, double zoomFactor, double totalZoomFactor) * public ZoomEvent copyFor(Object newSource, EventTarget newTarget, EventType type) *TouchEvent*: * public TouchEvent(Object source, EventTarget target, EventType eventType, TouchPoint touchPoint, List touchPoints, int eventSetId, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct) * public TouchEvent(EventType eventType, TouchPoint touchPoint, List touchPoints, int eventSetId, boolean shiftDown, boolean controlDown, boolean altDown, boolean metaDown, boolean direct) * public TouchEvent copyFor(Object newSource, EventTarget newTarget, EventType type) * public boolean isDirect() // was impl_ because (according to a comment in code) there are no indirect events yet, but GestureEvent already has this public. *javafx.stage.WindowEvent*: * public WindowEvent copyFor(Object newSource, EventTarget newTarget, EventType type) -Martin On 06/15/2012 11:44 PM, Richard Bair wrote: >>> As for the approach, I think you do the constructors with all params (since events are immutable you have no choice really -- static factory or constructor and I prefer in this case a constructor) + builder (auto generated). >> And what do you think about impl_copy methods? Personally I think we should remove them completely and turn them to some internal utility methods. > My initial thought was a copy constructor. > >> Also, some events are not 100% immutable, as they are modified during the Scene processing through some impl_methods, like MouseEvent.impl_setClickParam. We'd either need to make some/all of the Event fields protected and do this modifications through subclasses or create some "accessor" in javafx.scene.input package for calling these methods from javafx.scene package. > Good question, I guess we can revisit these in context of the other impl_ method removal things we're working on. > > Richard From alexandre.iline at oracle.com Thu Jun 21 03:27:32 2012 From: alexandre.iline at oracle.com (alexandre.iline at oracle.com) Date: Thu, 21 Jun 2012 10:27:32 +0000 Subject: hg: openjfx/2.1/master/tests: 11 new changesets Message-ID: <20120621102733.CADA147A63@hg.openjdk.java.net> Changeset: 9bbfdff21137 Author: Alexandre (Shura) Iline Date: 2012-06-13 21:01 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/9bbfdff21137 fixed tests ! tools/Jemmy/GlassImage/nbproject/project.properties ! tools/Jemmy/JemmyFX/nbproject/build-impl.xml ! tools/Jemmy/JemmyFX/nbproject/genfiles.properties ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFX/nbproject/project.xml ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/ByText.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TextInputControlWrap.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TreeApp.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TreeTest.java Changeset: 6ec444f9f17d Author: Alexandre (Shura) Iline Date: 2012-06-14 23:49 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/6ec444f9f17d uncommented tests ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TreeTest.java Changeset: 47f7c93c8605 Author: Alexandre (Shura) Iline Date: 2012-06-14 23:47 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/47f7c93c8605 Samples. Fixed a bug in ByText ! tools/Jemmy/GlassImage/nbproject/project.properties ! tools/Jemmy/JemmyFX/build.xml ! tools/Jemmy/JemmyFX/nbproject/build-impl.xml ! tools/Jemmy/JemmyFX/nbproject/genfiles.properties ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFX/nbproject/project.xml + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/buttons/ButtonsApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/buttons/ButtonsSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/environment/EnvironmentSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/environment/TimeoutsSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/input/InputApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/input/InputSampleBase.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/input/KeyboardSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/input/MouseClickSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/input/MouseDNDSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/input/MouseMoveSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/lookup/CompoundLookupSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/lookup/CoorinateLookupSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/lookup/LookupApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/lookup/LookupSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/lookup/LookupSampleBase.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/ByText.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TreeApp.java Changeset: e424915d876f Author: Alexandre (Shura) Iline Date: 2012-06-14 23:58 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/e424915d876f merge ! tools/Jemmy/JemmyFX/nbproject/build-impl.xml ! tools/Jemmy/JemmyFX/nbproject/genfiles.properties ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFX/nbproject/project.xml ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TreeApp.java Changeset: fe969660ac2e Author: Alexandre (Shura) Iline Date: 2012-06-15 19:15 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/fe969660ac2e Text sample SampleList + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/index.html ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/lookup/LookupApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/text/TextApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/text/TextSample.java Changeset: e37f6f5cb0cd Author: Alexandre (Shura) Iline Date: 2012-06-15 19:20 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/e37f6f5cb0cd License ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/text/TextApp.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/text/TextSample.java Changeset: 9db2cf30aeb5 Author: Oleg Barbashov Date: 2012-06-20 02:31 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/9db2cf30aeb5 JemmyFX: Accordion wrap + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/accordion/AccordionApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/accordion/AccordionTest.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrapper.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/AccordionWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TabPaneWrap.java Changeset: f592be068a8e Author: Oleg Barbashov Date: 2012-06-20 15:07 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/f592be068a8e JemmyFX: AccordionWrap modifications ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/accordion/AccordionApp.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/accordion/AccordionTest.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/AccordionWrap.java Changeset: 1a668f909aca Author: Oleg Barbashov Date: 2012-06-20 17:11 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/1a668f909aca JemmyFX: Accordion minor fixes ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/AccordionWrap.java Changeset: 12755a7f1135 Author: Oleg Barbashov Date: 2012-06-20 18:17 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/12755a7f1135 JemmyFX: accordion minor fixes ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/accordion/AccordionApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/accordion/AccordionSample.java - tools/Jemmy/JemmyFX/samples/org/jemmy/samples/accordion/AccordionTest.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/input/MouseDNDSample.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/AccordionWrap.java Changeset: 10bce7582356 Author: Oleg Barbashov Date: 2012-06-21 14:14 +0400 URL: http://hg.openjdk.java.net/openjfx/2.1/master/tests/rev/10bce7582356 JemmyFX: minor fixes ! tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/DefaultGlassInputMap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/AccordionWrap.java From alexandre.iline at oracle.com Thu Jun 21 03:31:14 2012 From: alexandre.iline at oracle.com (alexandre.iline at oracle.com) Date: Thu, 21 Jun 2012 10:31:14 +0000 Subject: hg: openjfx/2.2/master/tests: 28 new changesets Message-ID: <20120621103117.5EEC447A64@hg.openjdk.java.net> Changeset: f7eef9e8f198 Author: shurailine Date: 2012-03-16 17:47 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/f7eef9e8f198 Added TitledPane Wrap ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrapper.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TitledPaneWrap.java + tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TitledPaneApp.java + tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TitledPaneTest.java Changeset: 17c26920f2ab Author: shurailine Date: 2012-03-16 18:01 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/17c26920f2ab merge Changeset: 0b15f52b9eec Author: Oleg Barbashov Date: 2012-03-20 22:11 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/0b15f52b9eec JemmyFX: MenuButtonWrap fix ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/MenuButtonWrap.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/Controls.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/MenuTest.java Changeset: caba4f3f9405 Author: Oleg Barbashov Date: 2012-03-21 17:04 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/caba4f3f9405 JemmyFX: ByText/ByID are extended to accept non-Node classes ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/ByID.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/ByText.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/MenuTest.java Changeset: 261e7315b11f Author: Oleg Barbashov Date: 2012-03-21 18:07 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/261e7315b11f JemmyFX: SceneWrap: no more need in workaround for JFXPanel ! tools/Jemmy/JemmyFX/build.xml ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/SceneWrap.java Changeset: c577fa32f8b2 Author: Oleg Barbashov Date: 2012-03-21 18:31 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/c577fa32f8b2 JemmyFX: focuser update ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ComboBoxWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/MenuBarWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ThemeDriverFactory.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/CaspianDriverFactory.java Changeset: 23b4e7c74bad Author: Oleg Barbashov Date: 2012-03-21 20:34 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/23b4e7c74bad JemmyFX: focuser update ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/CaspianDriverFactory.java Changeset: b633df938f33 Author: Andrey Nazarov Date: 2012-05-29 19:52 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/b633df938f33 Node hierarchy refactoring + tools/Jemmy/JemmyFX/src/org/jemmy/fx/AbstractNodeHierarchy.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeHierarchy.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeParentImpl.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/SceneNodeHierarchy.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/SceneWrap.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TabNodeHierarchy.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TabWrap.java Changeset: 308fb69640d7 Author: Shura Date: 2012-06-01 11:03 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/308fb69640d7 Glass robot. + tools/Jemmy/GlassImage/build.xml + tools/Jemmy/GlassImage/manifest.mf + tools/Jemmy/GlassImage/nbproject/build-impl.xml + tools/Jemmy/GlassImage/nbproject/genfiles.properties + tools/Jemmy/GlassImage/nbproject/project.properties + tools/Jemmy/GlassImage/nbproject/project.xml + tools/Jemmy/GlassImage/src/org/jemmy/image/ClasspathGlassImageLoader.java + tools/Jemmy/GlassImage/src/org/jemmy/image/FileGlassImageLoader.java + tools/Jemmy/GlassImage/src/org/jemmy/image/GlassImage.java + tools/Jemmy/GlassImage/src/org/jemmy/image/GlassImageCapturer.java + tools/Jemmy/GlassImage/src/org/jemmy/image/GlassImageLoader.java + tools/Jemmy/GlassImage/src/org/jemmy/image/GlassPixelImageComparator.java + tools/Jemmy/GlassImage/src/org/jemmy/image/PNGLoader.java + tools/Jemmy/GlassImage/src/org/jemmy/image/PNGSaver.java + tools/Jemmy/GlassImage/test/org/jemmy/image/EnvTest.java + tools/Jemmy/GlassImage/test/org/jemmy/image/InitTest.java + tools/Jemmy/GlassImage/test/org/jemmy/image/SaveLoadTest.java + tools/Jemmy/GlassImage/test/org/jemmy/image/Test1.java + tools/Jemmy/GlassImage/test/org/jemmy/image/TestApp.java + tools/Jemmy/GlassRobot/build.xml + tools/Jemmy/GlassRobot/nbproject/build-impl.xml + tools/Jemmy/GlassRobot/nbproject/genfiles.properties + tools/Jemmy/GlassRobot/nbproject/project.properties + tools/Jemmy/GlassRobot/nbproject/project.xml + tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/DefaultGlassInputMap.java + tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/GlassDrag.java + tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/GlassInputFactory.java + tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/GlassInputMap.java + tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/GlassKeyboard.java + tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/GlassMouse.java + tools/Jemmy/GlassRobot/test/org/jemmy/input/glass/KeyboardInputApp.java + tools/Jemmy/GlassRobot/test/org/jemmy/input/glass/KeyboardTest.java + tools/Jemmy/GlassRobot/test/org/jemmy/input/glass/Log.java + tools/Jemmy/GlassRobot/test/org/jemmy/input/glass/MouseInputApp.java + tools/Jemmy/GlassRobot/test/org/jemmy/input/glass/MouseTest.java ! tools/Jemmy/JemmyFX/nbproject/build-impl.xml ! tools/Jemmy/JemmyFX/nbproject/genfiles.properties ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFX/nbproject/project.xml ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/Root.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/TextWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/CheckBoxWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ChoiceBoxWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ToggleButtonWrap.java + tools/Jemmy/JemmyFX/test/org/jemmy/fx/ImageTest.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/LookupTest.java - tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TableViewCellsParentTest.java Changeset: ba5639ce9e47 Author: Shura Date: 2012-06-01 11:12 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/ba5639ce9e47 merge ! tools/Jemmy/JemmyFX/nbproject/project.properties Changeset: 5beef50b587b Author: Shura Date: 2012-06-01 11:34 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/5beef50b587b bumped dependency version ! tools/Jemmy/JemmyFX/depend.properties Changeset: 7a64ef29fde3 Author: Shura Date: 2012-06-01 11:50 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/7a64ef29fde3 bumped version H: Enter commit message. Lines beginning with 'HG:' are removed. ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/jemmy.properties Changeset: e2567caca409 Author: Alexandre (Shura) Iline Date: 2012-06-08 19:29 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/e2567caca409 fixed scripts and readme ! tools/Jemmy/GlassImage/nbproject/project.properties ! tools/Jemmy/JemmyFX/build.xml ! tools/Jemmy/README Changeset: 53d860f6503b Author: Alexandre (Shura) Iline Date: 2012-06-09 12:53 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/53d860f6503b Use AWT robot on unix Grab image on the event queue Reduce ImageTest ! tools/Jemmy/GlassImage/src/org/jemmy/image/GlassImageCapturer.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/Root.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/ImageTest.java Changeset: fe1f000b448d Author: Alexandre (Shura) Iline Date: 2012-06-09 13:20 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/fe1f000b448d iadded AWT input ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/ImageTest.java Changeset: 152819c744b4 Author: Alexandre (Shura) Iline Date: 2012-04-20 17:41 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/152819c744b4 Allow to add custom wraps. ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrapper.java ! tools/Jemmy/JemmyFXBrowser/nbproject/project.properties Changeset: 48ead642e7a4 Author: Alexandre (Shura) Iline Date: 2012-06-13 16:51 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/48ead642e7a4 merge ! tools/Jemmy/JemmyFX/nbproject/project.properties Changeset: 9bbfdff21137 Author: Alexandre (Shura) Iline Date: 2012-06-13 21:01 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/9bbfdff21137 fixed tests ! tools/Jemmy/GlassImage/nbproject/project.properties ! tools/Jemmy/JemmyFX/nbproject/build-impl.xml ! tools/Jemmy/JemmyFX/nbproject/genfiles.properties ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFX/nbproject/project.xml ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/ByText.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TextInputControlWrap.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TreeApp.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TreeTest.java Changeset: 6ec444f9f17d Author: Alexandre (Shura) Iline Date: 2012-06-14 23:49 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/6ec444f9f17d uncommented tests ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TreeTest.java Changeset: 47f7c93c8605 Author: Alexandre (Shura) Iline Date: 2012-06-14 23:47 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/47f7c93c8605 Samples. Fixed a bug in ByText ! tools/Jemmy/GlassImage/nbproject/project.properties ! tools/Jemmy/JemmyFX/build.xml ! tools/Jemmy/JemmyFX/nbproject/build-impl.xml ! tools/Jemmy/JemmyFX/nbproject/genfiles.properties ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFX/nbproject/project.xml + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/buttons/ButtonsApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/buttons/ButtonsSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/environment/EnvironmentSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/environment/TimeoutsSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/input/InputApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/input/InputSampleBase.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/input/KeyboardSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/input/MouseClickSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/input/MouseDNDSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/input/MouseMoveSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/lookup/CompoundLookupSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/lookup/CoorinateLookupSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/lookup/LookupApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/lookup/LookupSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/lookup/LookupSampleBase.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/ByText.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TreeApp.java Changeset: e424915d876f Author: Alexandre (Shura) Iline Date: 2012-06-14 23:58 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/e424915d876f merge ! tools/Jemmy/JemmyFX/nbproject/build-impl.xml ! tools/Jemmy/JemmyFX/nbproject/genfiles.properties ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFX/nbproject/project.xml ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TreeApp.java Changeset: fe969660ac2e Author: Alexandre (Shura) Iline Date: 2012-06-15 19:15 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/fe969660ac2e Text sample SampleList + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/index.html ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/lookup/LookupApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/text/TextApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/text/TextSample.java Changeset: e37f6f5cb0cd Author: Alexandre (Shura) Iline Date: 2012-06-15 19:20 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/e37f6f5cb0cd License ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/text/TextApp.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/text/TextSample.java Changeset: 9db2cf30aeb5 Author: Oleg Barbashov Date: 2012-06-20 02:31 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/9db2cf30aeb5 JemmyFX: Accordion wrap + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/accordion/AccordionApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/accordion/AccordionTest.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrapper.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/AccordionWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TabPaneWrap.java Changeset: f592be068a8e Author: Oleg Barbashov Date: 2012-06-20 15:07 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/f592be068a8e JemmyFX: AccordionWrap modifications ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/accordion/AccordionApp.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/accordion/AccordionTest.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/AccordionWrap.java Changeset: 1a668f909aca Author: Oleg Barbashov Date: 2012-06-20 17:11 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/1a668f909aca JemmyFX: Accordion minor fixes ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/AccordionWrap.java Changeset: 12755a7f1135 Author: Oleg Barbashov Date: 2012-06-20 18:17 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/12755a7f1135 JemmyFX: accordion minor fixes ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/accordion/AccordionApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/accordion/AccordionSample.java - tools/Jemmy/JemmyFX/samples/org/jemmy/samples/accordion/AccordionTest.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/input/MouseDNDSample.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/AccordionWrap.java Changeset: 10bce7582356 Author: Oleg Barbashov Date: 2012-06-21 14:14 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/10bce7582356 JemmyFX: minor fixes ! tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/DefaultGlassInputMap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/AccordionWrap.java From hjohn at xs4all.nl Thu Jun 21 04:39:23 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Thu, 21 Jun 2012 13:39:23 +0200 Subject: Region PickOnBounds default setting In-Reply-To: <4FE2DEF5.8080209@oracle.com> References: <4FE185F4.9020407@oracle.com> <4FE2DEF5.8080209@oracle.com> Message-ID: <4FE307EB.6020202@xs4all.nl> Not sure if interested, but coming from someone who has never seen this before... I must say it certainly looks counter-intuitive. Why does the evilPane have such big bounds? It is restricted in layout to a max size of (50,50)... and thus I would expect the blue child to be clipped and the pane Bounds to be reduced to no more than (50,50). But I guess that is because of the tree style rendering that JavaFX does, where nodes can exceed their layout bounds when effects/translations are applied... as I said, it certainly looks counter-intuitive, in more ways than one coming from someone who is used to Container/Groups strictly sized to fit their children, and clipping the children that will not fit. --John On 21/06/2012 10:44, Pavel Safrata wrote: > Hi Daniel, > > On 20.6.2012 21:55, Daniel Zwolenski wrote: >>>> Assuming I understand the problem then I've hit this sort of layout >>>> problem and my instinct was to look >>>> I'm not sure I agree with the bug description when it says that >>>> "both visually and in source code there is nothing in between the >>>> pane and the child". In code there is a pane. Visually there would >>>> be a pane if you set styles on it. >>> The pane from the description is small and is in a top-left corner. >>> It can be styled, and you can see it there. There is no code that >>> would make the pane big to cover the whole scene, there is no way to >>> make it visible in the whole area, because it's just not there. >> I am perhaps missing something, but "Pane's bounds will then cover >> whole sceen" implies to me the pane is stretched, so if I styled it I >> would see it stretched. The description of #2 is a bit vague to me >> though. I guess a code example would clear this up but it probably >> doesn't matter that I dont understand. > > The pane is not necessarily stretched to embrace all its children. > I've attached a code example that shows the problem. > >> >>>> I'm guessing, for example, if this fix went in it would break all >>>> my 'glasspanes'? >>> I cannot say unless I know how your glasspanes are implemented... >> I use glass panes to block the screen in two cases: when loading and >> behind a light box (ie embedded dialog). >> >> In both cases my glass pane is just a pane (eg BorderPane) added to >> the top of a StackPane with the rest of the app added to a lower >> layer of the stack. In the loading case it has no children, in the >> dialog case it's child is the dialog. >> >> The loading one is transparent but has an in-progress cursor when you >> mouse over. In the dialog case, the pane is a translucent grey, >> though you could style it differently and transparent would be a >> valid style (making the fill color define if it is clickable would >> not be nice for me and is a little scary). >> >> In both cases the point of it is that it blocks mouse input to the >> scene. I'd prefer this didn't break in a future release (sorry!). If >> auto updating (my nemesis) wasn't on then I'd be ok for it to change >> and then I fix my apps before moving to a higher version but it >> magically working one day and not the next would be pretty nasty for me. > > It would break your glass panes only if they have no fill (which I > agree is bad enough). Pane with transparent fill would still block > mouse events. I'm not sure why this is scary, this approach is used > everywhere in FX except of Region. > >> >> >>>> As such, I don't think it needs to be a default attribute now that >>>> it's in place the other way round but I do think it needs to be >>>> clear and intuitive how to deal with it. >>> I'm really sad that we've let this go that far, it could have been >>> fixed before our first release. If the decision comes that it's too >>> late by now, the way how to deal with it will be clear >>> (setPickOnBounds(false)), but I doubt it is (and could be) intuitive. >> For me the current default behavior seems intuitive: the pane is >> clickable for whatever area it takes up. I get the feeling I might be >> missing something here though as it is obviously a concern for some >> people. Sorry if I have misunderstood. > > I think the attached example shows pane that is clickable in area that > it doesn't take up. > >> >> For me the only problem with the current approach is that in some >> cases I'd like a pane used purely for layout (anchor pane as top >> layer of a StackPane is a prime candidate) to not catch mouse clicks >> but the children on it still should. Calling setPickOnBounds(false) >> and setShape(null) to do this is not intuitive to me but I'm glad I >> now know its possible as I've struggled with this before (and >> possibly raised a bug, will have to check). > > This is exactly the most common problem that would be solved. You see > you're glad that you now know how to solve it, but other users will > keep bumping into this issue.. > > Thanks, > Pavel > >> >> >>> Thanks, >>> Pavel >>> >>>> >>>> On 20/06/2012, at 5:41 AM, Richard Bair >>>> wrote: >>>> >>>>> Hi folks, >>>>> >>>>> We have an issue which has been in the platform from before 2.0: >>>>> http://javafx-jira.kenai.com/browse/RT-17024. A better >>>>> explanation of the issue can be found on >>>>> http://javafx-jira.kenai.com/browse/RT-12258. From 12258: >>>>> >>>>>> Region behaves counter-intuitively regarding mouse event >>>>>> delivering. It reacts on mouse events everywhere in its bounds >>>>>> and people are often confused by it. Here are two simple examples: >>>>>> >>>>>> 1) You create let's say HBox just because you want it to layout >>>>>> its children. The HBox catches all mouse events in the whole area >>>>>> given by its bounds. Often it's hard to understand what area it >>>>>> is (with children of different size or with some other layout >>>>>> stretches taking place). >>>>>> >>>>>> 2) You create a small Pane in top-left corner of the scene with a >>>>>> child in bottom-right corner of the scene. Pane's bounds will >>>>>> then cover whole sceen and you won't be able to click on anything >>>>>> else than the pane and its child. Users don't understand why, >>>>>> because both visually and in source code there is nothing in >>>>>> between the pane and the child. >>>>>> >>>>>> Moreover, region may have a shape associated and the behavior >>>>>> here is also strange. If you create a region with a shape inside >>>>>> its bounds, it's just ignored. You can also create a shape >>>>>> somewhere else, then it extends region's bounds and it reacts on >>>>>> mouse click everywhere between the shape and the region. >>>>> This issue has to do with the semantics of picking on a Region. >>>>> For Region we have had pickOnBounds set to true by default, which >>>>> yields the above behaviors. We can change it to false by default, >>>>> but then need to update a bunch of skins (for example the up/down >>>>> arrows of scroll bar, the thumb of a slider, the down arrow of a >>>>> combo box button, etc) so that they switch back to having >>>>> pickOnBounds set to true by default so that the target area for >>>>> clicks is larger. We could just change the default for Pane and >>>>> not for Region, although we use StackPane in Skins and would have >>>>> to update them anyhow. It seems that for a normal layout container >>>>> the behavior really should be pickOnBounds=false by default, but >>>>> for UI controls usages and such you generally want it true. >>>>> >>>>> I'm not certain making this change is worth being backwards >>>>> incompatible (semantically, binary compatibility would remain). >>>>> But what do you think? >>>>> >>>>> Richard From zonski at googlemail.com Thu Jun 21 04:48:29 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Thu, 21 Jun 2012 21:48:29 +1000 Subject: Region PickOnBounds default setting In-Reply-To: <4FE307EB.6020202@xs4all.nl> References: <4FE185F4.9020407@oracle.com> <4FE2DEF5.8080209@oracle.com> <4FE307EB.6020202@xs4all.nl> Message-ID: I just ran the code (thanks Pavel!) and I agree. While I see the problem with the picking, a bigger problem in my mind is that the max bounds are not being honoured. The picking to me is just a side effect of some odd layout sizing behaviour. My expectation with this code is it should either honour the max bounds and clip the child nodes (my preference) or, if it's really not going to honour the max bounds, then it should stretch the region to the bounds that it is actually covering. The hybrid thing it is doing is just weird in my opinion. On Thu, Jun 21, 2012 at 9:39 PM, John Hendrikx wrote: > Not sure if interested, but coming from someone who has never seen this > before... I must say it certainly looks counter-intuitive. Why does the > evilPane have such big bounds? It is restricted in layout to a max size of > (50,50)... and thus I would expect the blue child to be clipped and the > pane Bounds to be reduced to no more than (50,50). > > But I guess that is because of the tree style rendering that JavaFX does, > where nodes can exceed their layout bounds when effects/translations are > applied... as I said, it certainly looks counter-intuitive, in more ways > than one coming from someone who is used to Container/Groups strictly sized > to fit their children, and clipping the children that will not fit. > > --John > > > On 21/06/2012 10:44, Pavel Safrata wrote: > >> Hi Daniel, >> >> On 20.6.2012 21:55, Daniel Zwolenski wrote: >> >>> Assuming I understand the problem then I've hit this sort of layout >>>>> problem and my instinct was to look >>>>> I'm not sure I agree with the bug description when it says that "both >>>>> visually and in source code there is nothing in between the pane and the >>>>> child". In code there is a pane. Visually there would be a pane if you set >>>>> styles on it. >>>>> >>>> The pane from the description is small and is in a top-left corner. It >>>> can be styled, and you can see it there. There is no code that would make >>>> the pane big to cover the whole scene, there is no way to make it visible >>>> in the whole area, because it's just not there. >>>> >>> I am perhaps missing something, but "Pane's bounds will then cover whole >>> sceen" implies to me the pane is stretched, so if I styled it I would see >>> it stretched. The description of #2 is a bit vague to me though. I guess a >>> code example would clear this up but it probably doesn't matter that I dont >>> understand. >>> >> >> The pane is not necessarily stretched to embrace all its children. I've >> attached a code example that shows the problem. >> >> >>> I'm guessing, for example, if this fix went in it would break all my >>>>> 'glasspanes'? >>>>> >>>> I cannot say unless I know how your glasspanes are implemented... >>>> >>> I use glass panes to block the screen in two cases: when loading and >>> behind a light box (ie embedded dialog). >>> >>> In both cases my glass pane is just a pane (eg BorderPane) added to the >>> top of a StackPane with the rest of the app added to a lower layer of the >>> stack. In the loading case it has no children, in the dialog case it's >>> child is the dialog. >>> >>> The loading one is transparent but has an in-progress cursor when you >>> mouse over. In the dialog case, the pane is a translucent grey, though you >>> could style it differently and transparent would be a valid style (making >>> the fill color define if it is clickable would not be nice for me and is a >>> little scary). >>> >>> In both cases the point of it is that it blocks mouse input to the >>> scene. I'd prefer this didn't break in a future release (sorry!). If auto >>> updating (my nemesis) wasn't on then I'd be ok for it to change and then I >>> fix my apps before moving to a higher version but it magically working one >>> day and not the next would be pretty nasty for me. >>> >> >> It would break your glass panes only if they have no fill (which I agree >> is bad enough). Pane with transparent fill would still block mouse events. >> I'm not sure why this is scary, this approach is used everywhere in FX >> except of Region. >> >> >>> >>> As such, I don't think it needs to be a default attribute now that it's >>>>> in place the other way round but I do think it needs to be clear and >>>>> intuitive how to deal with it. >>>>> >>>> I'm really sad that we've let this go that far, it could have been >>>> fixed before our first release. If the decision comes that it's too late by >>>> now, the way how to deal with it will be clear (setPickOnBounds(false)), >>>> but I doubt it is (and could be) intuitive. >>>> >>> For me the current default behavior seems intuitive: the pane is >>> clickable for whatever area it takes up. I get the feeling I might be >>> missing something here though as it is obviously a concern for some people. >>> Sorry if I have misunderstood. >>> >> >> I think the attached example shows pane that is clickable in area that it >> doesn't take up. >> >> >>> For me the only problem with the current approach is that in some cases >>> I'd like a pane used purely for layout (anchor pane as top layer of a >>> StackPane is a prime candidate) to not catch mouse clicks but the children >>> on it still should. Calling setPickOnBounds(false) and setShape(null) to do >>> this is not intuitive to me but I'm glad I now know its possible as I've >>> struggled with this before (and possibly raised a bug, will have to check). >>> >> >> This is exactly the most common problem that would be solved. You see >> you're glad that you now know how to solve it, but other users will keep >> bumping into this issue.. >> >> Thanks, >> Pavel >> >> >>> >>> Thanks, >>>> Pavel >>>> >>>> >>>>> On 20/06/2012, at 5:41 AM, Richard Bair >>>>> wrote: >>>>> >>>>> Hi folks, >>>>>> >>>>>> We have an issue which has been in the platform from before 2.0: >>>>>> http://javafx-jira.kenai.com/**browse/RT-17024. >>>>>> A better explanation of the issue can be found on >>>>>> http://javafx-jira.kenai.com/**browse/RT-12258. >>>>>> From 12258: >>>>>> >>>>>> Region behaves counter-intuitively regarding mouse event delivering. >>>>>>> It reacts on mouse events everywhere in its bounds and people are often >>>>>>> confused by it. Here are two simple examples: >>>>>>> >>>>>>> 1) You create let's say HBox just because you want it to layout its >>>>>>> children. The HBox catches all mouse events in the whole area given by its >>>>>>> bounds. Often it's hard to understand what area it is (with children of >>>>>>> different size or with some other layout stretches taking place). >>>>>>> >>>>>>> 2) You create a small Pane in top-left corner of the scene with a >>>>>>> child in bottom-right corner of the scene. Pane's bounds will then cover >>>>>>> whole sceen and you won't be able to click on anything else than the pane >>>>>>> and its child. Users don't understand why, because both visually and in >>>>>>> source code there is nothing in between the pane and the child. >>>>>>> >>>>>>> Moreover, region may have a shape associated and the behavior here >>>>>>> is also strange. If you create a region with a shape inside its bounds, >>>>>>> it's just ignored. You can also create a shape somewhere else, then it >>>>>>> extends region's bounds and it reacts on mouse click everywhere between the >>>>>>> shape and the region. >>>>>>> >>>>>> This issue has to do with the semantics of picking on a Region. For >>>>>> Region we have had pickOnBounds set to true by default, which yields the >>>>>> above behaviors. We can change it to false by default, but then need to >>>>>> update a bunch of skins (for example the up/down arrows of scroll bar, the >>>>>> thumb of a slider, the down arrow of a combo box button, etc) so that they >>>>>> switch back to having pickOnBounds set to true by default so that the >>>>>> target area for clicks is larger. We could just change the default for Pane >>>>>> and not for Region, although we use StackPane in Skins and would have to >>>>>> update them anyhow. It seems that for a normal layout container the >>>>>> behavior really should be pickOnBounds=false by default, but for UI >>>>>> controls usages and such you generally want it true. >>>>>> >>>>>> I'm not certain making this change is worth being backwards >>>>>> incompatible (semantically, binary compatibility would remain). But what do >>>>>> you think? >>>>>> >>>>>> Richard >>>>>> >>>>> > From richard.bair at oracle.com Thu Jun 21 08:37:17 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 21 Jun 2012 08:37:17 -0700 Subject: Region PickOnBounds default setting In-Reply-To: References: <4FE185F4.9020407@oracle.com> <4FE2DEF5.8080209@oracle.com> <4FE307EB.6020202@xs4all.nl> Message-ID: Ah I see the problem. Pavel can we make sure there is some text in the issue describing the problem (ie bounds != region width/height, and thus pick on bounds is undeniably wrong in that case). Dan -- the bounds always must include the bounds of all stuff, without putting a clip on every region you have to be prepared for layout bounds != bounds in parent / bounds in local. Note that putting a clip on regions by default would be a huge mistake. You wouldn't be able to do a number of common effects where you are translating children outside the bounds of the container. It is the difference between basic form like apps and more graphical ones. On Jun 21, 2012, at 4:48 AM, Daniel Zwolenski wrote: > I just ran the code (thanks Pavel!) and I agree. While I see the problem > with the picking, a bigger problem in my mind is that the max bounds are > not being honoured. The picking to me is just a side effect of some odd > layout sizing behaviour. > > My expectation with this code is it should either honour the max bounds and > clip the child nodes (my preference) or, if it's really not going to honour > the max bounds, then it should stretch the region to the bounds that it is > actually covering. The hybrid thing it is doing is just weird in my > opinion. > > > On Thu, Jun 21, 2012 at 9:39 PM, John Hendrikx wrote: > >> Not sure if interested, but coming from someone who has never seen this >> before... I must say it certainly looks counter-intuitive. Why does the >> evilPane have such big bounds? It is restricted in layout to a max size of >> (50,50)... and thus I would expect the blue child to be clipped and the >> pane Bounds to be reduced to no more than (50,50). >> >> But I guess that is because of the tree style rendering that JavaFX does, >> where nodes can exceed their layout bounds when effects/translations are >> applied... as I said, it certainly looks counter-intuitive, in more ways >> than one coming from someone who is used to Container/Groups strictly sized >> to fit their children, and clipping the children that will not fit. >> >> --John >> >> >> On 21/06/2012 10:44, Pavel Safrata wrote: >> >>> Hi Daniel, >>> >>> On 20.6.2012 21:55, Daniel Zwolenski wrote: >>> >>>> Assuming I understand the problem then I've hit this sort of layout >>>>>> problem and my instinct was to look >>>>>> I'm not sure I agree with the bug description when it says that "both >>>>>> visually and in source code there is nothing in between the pane and the >>>>>> child". In code there is a pane. Visually there would be a pane if you set >>>>>> styles on it. >>>>>> >>>>> The pane from the description is small and is in a top-left corner. It >>>>> can be styled, and you can see it there. There is no code that would make >>>>> the pane big to cover the whole scene, there is no way to make it visible >>>>> in the whole area, because it's just not there. >>>>> >>>> I am perhaps missing something, but "Pane's bounds will then cover whole >>>> sceen" implies to me the pane is stretched, so if I styled it I would see >>>> it stretched. The description of #2 is a bit vague to me though. I guess a >>>> code example would clear this up but it probably doesn't matter that I dont >>>> understand. >>>> >>> >>> The pane is not necessarily stretched to embrace all its children. I've >>> attached a code example that shows the problem. >>> >>> >>>> I'm guessing, for example, if this fix went in it would break all my >>>>>> 'glasspanes'? >>>>>> >>>>> I cannot say unless I know how your glasspanes are implemented... >>>>> >>>> I use glass panes to block the screen in two cases: when loading and >>>> behind a light box (ie embedded dialog). >>>> >>>> In both cases my glass pane is just a pane (eg BorderPane) added to the >>>> top of a StackPane with the rest of the app added to a lower layer of the >>>> stack. In the loading case it has no children, in the dialog case it's >>>> child is the dialog. >>>> >>>> The loading one is transparent but has an in-progress cursor when you >>>> mouse over. In the dialog case, the pane is a translucent grey, though you >>>> could style it differently and transparent would be a valid style (making >>>> the fill color define if it is clickable would not be nice for me and is a >>>> little scary). >>>> >>>> In both cases the point of it is that it blocks mouse input to the >>>> scene. I'd prefer this didn't break in a future release (sorry!). If auto >>>> updating (my nemesis) wasn't on then I'd be ok for it to change and then I >>>> fix my apps before moving to a higher version but it magically working one >>>> day and not the next would be pretty nasty for me. >>>> >>> >>> It would break your glass panes only if they have no fill (which I agree >>> is bad enough). Pane with transparent fill would still block mouse events. >>> I'm not sure why this is scary, this approach is used everywhere in FX >>> except of Region. >>> >>> >>>> >>>> As such, I don't think it needs to be a default attribute now that it's >>>>>> in place the other way round but I do think it needs to be clear and >>>>>> intuitive how to deal with it. >>>>>> >>>>> I'm really sad that we've let this go that far, it could have been >>>>> fixed before our first release. If the decision comes that it's too late by >>>>> now, the way how to deal with it will be clear (setPickOnBounds(false)), >>>>> but I doubt it is (and could be) intuitive. >>>>> >>>> For me the current default behavior seems intuitive: the pane is >>>> clickable for whatever area it takes up. I get the feeling I might be >>>> missing something here though as it is obviously a concern for some people. >>>> Sorry if I have misunderstood. >>>> >>> >>> I think the attached example shows pane that is clickable in area that it >>> doesn't take up. >>> >>> >>>> For me the only problem with the current approach is that in some cases >>>> I'd like a pane used purely for layout (anchor pane as top layer of a >>>> StackPane is a prime candidate) to not catch mouse clicks but the children >>>> on it still should. Calling setPickOnBounds(false) and setShape(null) to do >>>> this is not intuitive to me but I'm glad I now know its possible as I've >>>> struggled with this before (and possibly raised a bug, will have to check). >>>> >>> >>> This is exactly the most common problem that would be solved. You see >>> you're glad that you now know how to solve it, but other users will keep >>> bumping into this issue.. >>> >>> Thanks, >>> Pavel >>> >>> >>>> >>>> Thanks, >>>>> Pavel >>>>> >>>>> >>>>>> On 20/06/2012, at 5:41 AM, Richard Bair >>>>>> wrote: >>>>>> >>>>>> Hi folks, >>>>>>> >>>>>>> We have an issue which has been in the platform from before 2.0: >>>>>>> http://javafx-jira.kenai.com/**browse/RT-17024. >>>>>>> A better explanation of the issue can be found on >>>>>>> http://javafx-jira.kenai.com/**browse/RT-12258. >>>>>>> From 12258: >>>>>>> >>>>>>> Region behaves counter-intuitively regarding mouse event delivering. >>>>>>>> It reacts on mouse events everywhere in its bounds and people are often >>>>>>>> confused by it. Here are two simple examples: >>>>>>>> >>>>>>>> 1) You create let's say HBox just because you want it to layout its >>>>>>>> children. The HBox catches all mouse events in the whole area given by its >>>>>>>> bounds. Often it's hard to understand what area it is (with children of >>>>>>>> different size or with some other layout stretches taking place). >>>>>>>> >>>>>>>> 2) You create a small Pane in top-left corner of the scene with a >>>>>>>> child in bottom-right corner of the scene. Pane's bounds will then cover >>>>>>>> whole sceen and you won't be able to click on anything else than the pane >>>>>>>> and its child. Users don't understand why, because both visually and in >>>>>>>> source code there is nothing in between the pane and the child. >>>>>>>> >>>>>>>> Moreover, region may have a shape associated and the behavior here >>>>>>>> is also strange. If you create a region with a shape inside its bounds, >>>>>>>> it's just ignored. You can also create a shape somewhere else, then it >>>>>>>> extends region's bounds and it reacts on mouse click everywhere between the >>>>>>>> shape and the region. >>>>>>>> >>>>>>> This issue has to do with the semantics of picking on a Region. For >>>>>>> Region we have had pickOnBounds set to true by default, which yields the >>>>>>> above behaviors. We can change it to false by default, but then need to >>>>>>> update a bunch of skins (for example the up/down arrows of scroll bar, the >>>>>>> thumb of a slider, the down arrow of a combo box button, etc) so that they >>>>>>> switch back to having pickOnBounds set to true by default so that the >>>>>>> target area for clicks is larger. We could just change the default for Pane >>>>>>> and not for Region, although we use StackPane in Skins and would have to >>>>>>> update them anyhow. It seems that for a normal layout container the >>>>>>> behavior really should be pickOnBounds=false by default, but for UI >>>>>>> controls usages and such you generally want it true. >>>>>>> >>>>>>> I'm not certain making this change is worth being backwards >>>>>>> incompatible (semantically, binary compatibility would remain). But what do >>>>>>> you think? >>>>>>> >>>>>>> Richard >>>>>>> >>>>>> >> From hang.vo at oracle.com Thu Jun 21 11:34:59 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 21 Jun 2012 18:34:59 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22635: Pagination PageCount property changing leads to exception when unidirectionally binded. Message-ID: <20120621183506.7F6D147A6E@hg.openjdk.java.net> Changeset: 8f69ae6bb9f4 Author: Kinsley Wong Date: 2012-06-21 11:28 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/8f69ae6bb9f4 RT-22635: Pagination PageCount property changing leads to exception when unidirectionally binded. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java From jonathan.giles at oracle.com Thu Jun 21 15:20:18 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 22 Jun 2012 10:20:18 +1200 Subject: Dealing with nested events for a single property in JavaFX Message-ID: <4FE39E22.9000205@oracle.com> Hi all, I'm going to keep this brief as I'm fairly comprehensively underwater on the bug count. Recently I've found a pattern of bug that, well, I'm fairly sure is due to user error, but is not obvious at all (and as such it leads to bug reports). In the last week, I've encountered this issue twice. The basic issue is that of listening to an event (for example, a focus change event), and reacting in such a way as to modify the state of this property (which results in another event being fired). The end result is non-deterministic (but often broken behavior). Interestingly, it has in both my cases manifested itself as something that works once, and then fails after that forever more. In both cases, after much code digging and debugging (although today was made much easier by the same issue last week), I believe the issue can be worked around simply by wrapping the change to the property state (in the event callback) with a Platform.runLater(new Runnable() { ...}). This forces the second property update to happen after the first event has finished firing (at some point in the future). However, this isn't a great solution - we're forcing the event to fire at a later date where the state may have already changed. The better solution, in my opinion, is to improve the event system such that it knows whether an event is already firing, and if so it will queue up the event to run after the current one has finished. I would be interested in hearing whether anyone else has encountered this kind of bug, or whether they have better suggestions. You can see two examples of this bug in the code attached here (where the first example is for ComboBox where the value is updated in the onAction callback....which is called when value changes): http://javafx-jira.kenai.com/browse/RT-22478 http://javafx-jira.kenai.com/browse/RT-17772 -- Jonathan From zonski at googlemail.com Thu Jun 21 15:31:12 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Fri, 22 Jun 2012 08:31:12 +1000 Subject: Dealing with nested events for a single property in JavaFX In-Reply-To: <4FE39E22.9000205@oracle.com> References: <4FE39E22.9000205@oracle.com> Message-ID: Similar to the ConcurrentModification thing you get with Collections right? Could it be handled in a similar way, i.e. throw an error if someone tries to update the property they are modifying while in the update callback for that property? As you say, it's user error, so slapping them on the wrists is ok. The runLater one feels like it could cause its own problems to me. The 'single' threadedness of JFX is part of it's design. It gives me deterministic behaviour, this feels like it could open up small cracks in that. Obviously we wouldn't get concurrency/deadlock issues but I suspect we could get things in a non-deterministic order as a result of this (e.g. if another thread does a runLater somewhere else in the code at the same time this runLater is being added). Could end up that my property change is overwritten sometimes but not others, etc (I'm going more off gut feel here though than concrete examples). On Fri, Jun 22, 2012 at 8:20 AM, Jonathan Giles wrote: > Hi all, > > I'm going to keep this brief as I'm fairly comprehensively underwater on > the bug count. > > Recently I've found a pattern of bug that, well, I'm fairly sure is due to > user error, but is not obvious at all (and as such it leads to bug > reports). In the last week, I've encountered this issue twice. The basic > issue is that of listening to an event (for example, a focus change event), > and reacting in such a way as to modify the state of this property (which > results in another event being fired). The end result is non-deterministic > (but often broken behavior). Interestingly, it has in both my cases > manifested itself as something that works once, and then fails after that > forever more. > > In both cases, after much code digging and debugging (although today was > made much easier by the same issue last week), I believe the issue can be > worked around simply by wrapping the change to the property state (in the > event callback) with a Platform.runLater(new Runnable() { ...}). This > forces the second property update to happen after the first event has > finished firing (at some point in the future). > > However, this isn't a great solution - we're forcing the event to fire at > a later date where the state may have already changed. The better solution, > in my opinion, is to improve the event system such that it knows whether an > event is already firing, and if so it will queue up the event to run after > the current one has finished. I would be interested in hearing whether > anyone else has encountered this kind of bug, or whether they have better > suggestions. > > You can see two examples of this bug in the code attached here (where the > first example is for ComboBox where the value is updated in the onAction > callback....which is called when value changes): > > http://javafx-jira.kenai.com/**browse/RT-22478 > http://javafx-jira.kenai.com/**browse/RT-17772 > > -- Jonathan > From jonathan.giles at oracle.com Thu Jun 21 15:39:30 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 22 Jun 2012 10:39:30 +1200 Subject: Dealing with nested events for a single property in JavaFX In-Reply-To: References: <4FE39E22.9000205@oracle.com> Message-ID: <4FE3A2A2.5040406@oracle.com> runLater is wrong more often than it is right - so you're right - I don't think we should consider that approach (or requiring people to have to know to do this) Saying that you should error out when someone tries to update a property in the event callback is also wrong, I think. There are legitimate use cases, for example as a last ditch form of validation: if the value is outside the allowable range, change it back to something that is valid. Alternatively, when focus is given to a node, request a focus change on another node. I imagine our own code would blow up if we took this approach :-) -- Jonathan On 22/06/2012 10:31 a.m., Daniel Zwolenski wrote: > Similar to the ConcurrentModification thing you get with Collections > right? Could it be handled in a similar way, i.e. throw an error if > someone tries to update the property they are modifying while in the > update callback for that property? As you say, it's user error, so > slapping them on the wrists is ok. > > The runLater one feels like it could cause its own problems to me. The > 'single' threadedness of JFX is part of it's design. It gives me > deterministic behaviour, this feels like it could open up small cracks > in that. Obviously we wouldn't get concurrency/deadlock issues but I > suspect we could get things in a non-deterministic order as a result > of this (e.g. if another thread does a runLater somewhere else in the > code at the same time this runLater is being added). Could end up that > my property change is overwritten sometimes but not others, etc (I'm > going more off gut feel here though than concrete examples). > > > On Fri, Jun 22, 2012 at 8:20 AM, Jonathan Giles > > wrote: > > Hi all, > > I'm going to keep this brief as I'm fairly comprehensively > underwater on the bug count. > > Recently I've found a pattern of bug that, well, I'm fairly sure > is due to user error, but is not obvious at all (and as such it > leads to bug reports). In the last week, I've encountered this > issue twice. The basic issue is that of listening to an event (for > example, a focus change event), and reacting in such a way as to > modify the state of this property (which results in another event > being fired). The end result is non-deterministic (but often > broken behavior). Interestingly, it has in both my cases > manifested itself as something that works once, and then fails > after that forever more. > > In both cases, after much code digging and debugging (although > today was made much easier by the same issue last week), I believe > the issue can be worked around simply by wrapping the change to > the property state (in the event callback) with a > Platform.runLater(new Runnable() { ...}). This forces the second > property update to happen after the first event has finished > firing (at some point in the future). > > However, this isn't a great solution - we're forcing the event to > fire at a later date where the state may have already changed. The > better solution, in my opinion, is to improve the event system > such that it knows whether an event is already firing, and if so > it will queue up the event to run after the current one has > finished. I would be interested in hearing whether anyone else has > encountered this kind of bug, or whether they have better suggestions. > > You can see two examples of this bug in the code attached here > (where the first example is for ComboBox where the value is > updated in the onAction callback....which is called when value > changes): > > http://javafx-jira.kenai.com/browse/RT-22478 > http://javafx-jira.kenai.com/browse/RT-17772 > > -- Jonathan > > From scekics at gmail.com Thu Jun 21 15:46:47 2012 From: scekics at gmail.com (Slavko Scekic) Date: Fri, 22 Jun 2012 00:46:47 +0200 Subject: Dealing with nested events for a single property in JavaFX In-Reply-To: <4FE3A2A2.5040406@oracle.com> References: <4FE39E22.9000205@oracle.com> <4FE3A2A2.5040406@oracle.com> Message-ID: So, the point is: be careful? :) On Fri, Jun 22, 2012 at 12:39 AM, Jonathan Giles wrote: > runLater is wrong more often than it is right - so you're right - I don't > think we should consider that approach (or requiring people to have to know > to do this) > > Saying that you should error out when someone tries to update a property > in the event callback is also wrong, I think. There are legitimate use > cases, for example as a last ditch form of validation: if the value is > outside the allowable range, change it back to something that is valid. > Alternatively, when focus is given to a node, request a focus change on > another node. I imagine our own code would blow up if we took this approach > :-) > > -- Jonathan > > > On 22/06/2012 10:31 a.m., Daniel Zwolenski wrote: > >> Similar to the ConcurrentModification thing you get with Collections >> right? Could it be handled in a similar way, i.e. throw an error if someone >> tries to update the property they are modifying while in the update >> callback for that property? As you say, it's user error, so slapping them >> on the wrists is ok. >> >> The runLater one feels like it could cause its own problems to me. The >> 'single' threadedness of JFX is part of it's design. It gives me >> deterministic behaviour, this feels like it could open up small cracks in >> that. Obviously we wouldn't get concurrency/deadlock issues but I suspect >> we could get things in a non-deterministic order as a result of this (e.g. >> if another thread does a runLater somewhere else in the code at the same >> time this runLater is being added). Could end up that my property change is >> overwritten sometimes but not others, etc (I'm going more off gut feel here >> though than concrete examples). >> >> >> On Fri, Jun 22, 2012 at 8:20 AM, Jonathan Giles < >> jonathan.giles at oracle.com >> >> wrote: >> >> Hi all, >> >> I'm going to keep this brief as I'm fairly comprehensively >> underwater on the bug count. >> >> Recently I've found a pattern of bug that, well, I'm fairly sure >> is due to user error, but is not obvious at all (and as such it >> leads to bug reports). In the last week, I've encountered this >> issue twice. The basic issue is that of listening to an event (for >> example, a focus change event), and reacting in such a way as to >> modify the state of this property (which results in another event >> being fired). The end result is non-deterministic (but often >> broken behavior). Interestingly, it has in both my cases >> manifested itself as something that works once, and then fails >> after that forever more. >> >> In both cases, after much code digging and debugging (although >> today was made much easier by the same issue last week), I believe >> the issue can be worked around simply by wrapping the change to >> the property state (in the event callback) with a >> Platform.runLater(new Runnable() { ...}). This forces the second >> property update to happen after the first event has finished >> firing (at some point in the future). >> >> However, this isn't a great solution - we're forcing the event to >> fire at a later date where the state may have already changed. The >> better solution, in my opinion, is to improve the event system >> such that it knows whether an event is already firing, and if so >> it will queue up the event to run after the current one has >> finished. I would be interested in hearing whether anyone else has >> encountered this kind of bug, or whether they have better suggestions. >> >> You can see two examples of this bug in the code attached here >> (where the first example is for ComboBox where the value is >> updated in the onAction callback....which is called when value >> changes): >> >> http://javafx-jira.kenai.com/**browse/RT-22478 >> http://javafx-jira.kenai.com/**browse/RT-17772 >> >> -- Jonathan >> >> >> > > From jonathan.giles at oracle.com Thu Jun 21 15:47:43 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 22 Jun 2012 10:47:43 +1200 Subject: Dealing with nested events for a single property in JavaFX In-Reply-To: References: <4FE39E22.9000205@oracle.com> <4FE3A2A2.5040406@oracle.com> Message-ID: <4FE3A48F.5030505@oracle.com> The point is: can we have a better solution by considering changing the event API such that it queues events, rather than do them immediately as they are fired. -- Jonathan On 22/06/2012 10:46 a.m., Slavko Scekic wrote: > So, the point is: be careful? :) > > On Fri, Jun 22, 2012 at 12:39 AM, Jonathan Giles > > wrote: > > runLater is wrong more often than it is right - so you're right - > I don't think we should consider that approach (or requiring > people to have to know to do this) > > Saying that you should error out when someone tries to update a > property in the event callback is also wrong, I think. There are > legitimate use cases, for example as a last ditch form of > validation: if the value is outside the allowable range, change it > back to something that is valid. Alternatively, when focus is > given to a node, request a focus change on another node. I imagine > our own code would blow up if we took this approach :-) > > -- Jonathan > > > On 22/06/2012 10:31 a.m., Daniel Zwolenski wrote: > > Similar to the ConcurrentModification thing you get with > Collections right? Could it be handled in a similar way, i.e. > throw an error if someone tries to update the property they > are modifying while in the update callback for that property? > As you say, it's user error, so slapping them on the wrists is ok. > > The runLater one feels like it could cause its own problems to > me. The 'single' threadedness of JFX is part of it's design. > It gives me deterministic behaviour, this feels like it could > open up small cracks in that. Obviously we wouldn't get > concurrency/deadlock issues but I suspect we could get things > in a non-deterministic order as a result of this (e.g. if > another thread does a runLater somewhere else in the code at > the same time this runLater is being added). Could end up that > my property change is overwritten sometimes but not others, > etc (I'm going more off gut feel here though than concrete > examples). > > > On Fri, Jun 22, 2012 at 8:20 AM, Jonathan Giles > > >> wrote: > > Hi all, > > I'm going to keep this brief as I'm fairly comprehensively > underwater on the bug count. > > Recently I've found a pattern of bug that, well, I'm fairly > sure > is due to user error, but is not obvious at all (and as such it > leads to bug reports). In the last week, I've encountered this > issue twice. The basic issue is that of listening to an > event (for > example, a focus change event), and reacting in such a way > as to > modify the state of this property (which results in another > event > being fired). The end result is non-deterministic (but often > broken behavior). Interestingly, it has in both my cases > manifested itself as something that works once, and then fails > after that forever more. > > In both cases, after much code digging and debugging (although > today was made much easier by the same issue last week), I > believe > the issue can be worked around simply by wrapping the change to > the property state (in the event callback) with a > Platform.runLater(new Runnable() { ...}). This forces the > second > property update to happen after the first event has finished > firing (at some point in the future). > > However, this isn't a great solution - we're forcing the > event to > fire at a later date where the state may have already > changed. The > better solution, in my opinion, is to improve the event system > such that it knows whether an event is already firing, and > if so > it will queue up the event to run after the current one has > finished. I would be interested in hearing whether anyone > else has > encountered this kind of bug, or whether they have better > suggestions. > > You can see two examples of this bug in the code attached here > (where the first example is for ComboBox where the value is > updated in the onAction callback....which is called when value > changes): > > http://javafx-jira.kenai.com/browse/RT-22478 > http://javafx-jira.kenai.com/browse/RT-17772 > > -- Jonathan > > > > > From richard.bair at oracle.com Thu Jun 21 15:54:34 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 21 Jun 2012 15:54:34 -0700 Subject: Dealing with nested events for a single property in JavaFX In-Reply-To: <4FE3A48F.5030505@oracle.com> References: <4FE39E22.9000205@oracle.com> <4FE3A2A2.5040406@oracle.com> <4FE3A48F.5030505@oracle.com> Message-ID: <3FBE4B72-986C-4446-883B-C1B6E854C69D@oracle.com> Right, so what it comes down to is: do we layer events, or queue events? RunLater is wrong because we might insert a pulse between events on the queue so you will render things incorrectly for some brief period of time. It seems like handling events sequentially as they occur is the right semantic, rather than the "onion" approach where partway through handling event 1 we issue event 2. The problem here is that event 2 is handled, and then the rest of event 1 is handled, which now has the wrong state (if it was carrying state related to that first event. Of course by queuing events it is possible people will end up with handling so many events that the app thread is always busy and not processing the queue -- but then they can get into infinite recursion and all kinds of other issues, so I don't see that as a problem but just the nature of the beast. Richard On Jun 21, 2012, at 3:47 PM, Jonathan Giles wrote: > The point is: can we have a better solution by considering changing the event API such that it queues events, rather than do them immediately as they are fired. > > -- Jonathan > > On 22/06/2012 10:46 a.m., Slavko Scekic wrote: >> So, the point is: be careful? :) >> >> On Fri, Jun 22, 2012 at 12:39 AM, Jonathan Giles > wrote: >> >> runLater is wrong more often than it is right - so you're right - >> I don't think we should consider that approach (or requiring >> people to have to know to do this) >> >> Saying that you should error out when someone tries to update a >> property in the event callback is also wrong, I think. There are >> legitimate use cases, for example as a last ditch form of >> validation: if the value is outside the allowable range, change it >> back to something that is valid. Alternatively, when focus is >> given to a node, request a focus change on another node. I imagine >> our own code would blow up if we took this approach :-) >> >> -- Jonathan >> >> >> On 22/06/2012 10:31 a.m., Daniel Zwolenski wrote: >> >> Similar to the ConcurrentModification thing you get with >> Collections right? Could it be handled in a similar way, i.e. >> throw an error if someone tries to update the property they >> are modifying while in the update callback for that property? >> As you say, it's user error, so slapping them on the wrists is ok. >> >> The runLater one feels like it could cause its own problems to >> me. The 'single' threadedness of JFX is part of it's design. >> It gives me deterministic behaviour, this feels like it could >> open up small cracks in that. Obviously we wouldn't get >> concurrency/deadlock issues but I suspect we could get things >> in a non-deterministic order as a result of this (e.g. if >> another thread does a runLater somewhere else in the code at >> the same time this runLater is being added). Could end up that >> my property change is overwritten sometimes but not others, >> etc (I'm going more off gut feel here though than concrete >> examples). >> >> >> On Fri, Jun 22, 2012 at 8:20 AM, Jonathan Giles >> >> > >> wrote: >> >> Hi all, >> >> I'm going to keep this brief as I'm fairly comprehensively >> underwater on the bug count. >> >> Recently I've found a pattern of bug that, well, I'm fairly >> sure >> is due to user error, but is not obvious at all (and as such it >> leads to bug reports). In the last week, I've encountered this >> issue twice. The basic issue is that of listening to an >> event (for >> example, a focus change event), and reacting in such a way >> as to >> modify the state of this property (which results in another >> event >> being fired). The end result is non-deterministic (but often >> broken behavior). Interestingly, it has in both my cases >> manifested itself as something that works once, and then fails >> after that forever more. >> >> In both cases, after much code digging and debugging (although >> today was made much easier by the same issue last week), I >> believe >> the issue can be worked around simply by wrapping the change to >> the property state (in the event callback) with a >> Platform.runLater(new Runnable() { ...}). This forces the >> second >> property update to happen after the first event has finished >> firing (at some point in the future). >> >> However, this isn't a great solution - we're forcing the >> event to >> fire at a later date where the state may have already >> changed. The >> better solution, in my opinion, is to improve the event system >> such that it knows whether an event is already firing, and >> if so >> it will queue up the event to run after the current one has >> finished. I would be interested in hearing whether anyone >> else has >> encountered this kind of bug, or whether they have better >> suggestions. >> >> You can see two examples of this bug in the code attached here >> (where the first example is for ComboBox where the value is >> updated in the onAction callback....which is called when value >> changes): >> >> http://javafx-jira.kenai.com/browse/RT-22478 >> http://javafx-jira.kenai.com/browse/RT-17772 >> >> -- Jonathan >> >> >> >> >> > > From zonski at googlemail.com Thu Jun 21 16:18:39 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Fri, 22 Jun 2012 09:18:39 +1000 Subject: Dealing with nested events for a single property in JavaFX In-Reply-To: <3FBE4B72-986C-4446-883B-C1B6E854C69D@oracle.com> References: <4FE39E22.9000205@oracle.com> <4FE3A2A2.5040406@oracle.com> <4FE3A48F.5030505@oracle.com> <3FBE4B72-986C-4446-883B-C1B6E854C69D@oracle.com> Message-ID: It's not totally clear: I assume you are talking about a queue per property? Or do you mean one big queue for all properties? In either case I think we introduce a potential problem with this. Let's say we have: BooleanProperty one; BooleanProperty two; two.bind(one); Then in normal code we do this: one.set(true); two.get(); // value is 'true' as a result of binding But if we do the exact same code in a callback it has a different result: one.onValueChanged() { one.set(true); two.get(); // value is 'false' as event hasn't been processed yet } With a queue per property the problem is limited to only when you are listening on your own value and just maybe we could get away with that (I'm not convinced though, 'feels' dangerous). With one big queue it is really nasty as it would totally change the semantics of code depending on whether it was being called from within a property callback or not. On Fri, Jun 22, 2012 at 8:54 AM, Richard Bair wrote: > Right, so what it comes down to is: do we layer events, or queue events? > RunLater is wrong because we might insert a pulse between events on the > queue so you will render things incorrectly for some brief period of time. > > It seems like handling events sequentially as they occur is the right > semantic, rather than the "onion" approach where partway through handling > event 1 we issue event 2. The problem here is that event 2 is handled, and > then the rest of event 1 is handled, which now has the wrong state (if it > was carrying state related to that first event. > > Of course by queuing events it is possible people will end up with > handling so many events that the app thread is always busy and not > processing the queue -- but then they can get into infinite recursion and > all kinds of other issues, so I don't see that as a problem but just the > nature of the beast. > > Richard > > On Jun 21, 2012, at 3:47 PM, Jonathan Giles wrote: > > > The point is: can we have a better solution by considering changing the > event API such that it queues events, rather than do them immediately as > they are fired. > > > > -- Jonathan > > > > On 22/06/2012 10:46 a.m., Slavko Scekic wrote: > >> So, the point is: be careful? :) > >> > >> On Fri, Jun 22, 2012 at 12:39 AM, Jonathan Giles < > jonathan.giles at oracle.com > wrote: > >> > >> runLater is wrong more often than it is right - so you're right - > >> I don't think we should consider that approach (or requiring > >> people to have to know to do this) > >> > >> Saying that you should error out when someone tries to update a > >> property in the event callback is also wrong, I think. There are > >> legitimate use cases, for example as a last ditch form of > >> validation: if the value is outside the allowable range, change it > >> back to something that is valid. Alternatively, when focus is > >> given to a node, request a focus change on another node. I imagine > >> our own code would blow up if we took this approach :-) > >> > >> -- Jonathan > >> > >> > >> On 22/06/2012 10:31 a.m., Daniel Zwolenski wrote: > >> > >> Similar to the ConcurrentModification thing you get with > >> Collections right? Could it be handled in a similar way, i.e. > >> throw an error if someone tries to update the property they > >> are modifying while in the update callback for that property? > >> As you say, it's user error, so slapping them on the wrists is > ok. > >> > >> The runLater one feels like it could cause its own problems to > >> me. The 'single' threadedness of JFX is part of it's design. > >> It gives me deterministic behaviour, this feels like it could > >> open up small cracks in that. Obviously we wouldn't get > >> concurrency/deadlock issues but I suspect we could get things > >> in a non-deterministic order as a result of this (e.g. if > >> another thread does a runLater somewhere else in the code at > >> the same time this runLater is being added). Could end up that > >> my property change is overwritten sometimes but not others, > >> etc (I'm going more off gut feel here though than concrete > >> examples). > >> > >> > >> On Fri, Jun 22, 2012 at 8:20 AM, Jonathan Giles > >> > >> >> >> wrote: > >> > >> Hi all, > >> > >> I'm going to keep this brief as I'm fairly comprehensively > >> underwater on the bug count. > >> > >> Recently I've found a pattern of bug that, well, I'm fairly > >> sure > >> is due to user error, but is not obvious at all (and as such > it > >> leads to bug reports). In the last week, I've encountered this > >> issue twice. The basic issue is that of listening to an > >> event (for > >> example, a focus change event), and reacting in such a way > >> as to > >> modify the state of this property (which results in another > >> event > >> being fired). The end result is non-deterministic (but often > >> broken behavior). Interestingly, it has in both my cases > >> manifested itself as something that works once, and then fails > >> after that forever more. > >> > >> In both cases, after much code digging and debugging (although > >> today was made much easier by the same issue last week), I > >> believe > >> the issue can be worked around simply by wrapping the change > to > >> the property state (in the event callback) with a > >> Platform.runLater(new Runnable() { ...}). This forces the > >> second > >> property update to happen after the first event has finished > >> firing (at some point in the future). > >> > >> However, this isn't a great solution - we're forcing the > >> event to > >> fire at a later date where the state may have already > >> changed. The > >> better solution, in my opinion, is to improve the event system > >> such that it knows whether an event is already firing, and > >> if so > >> it will queue up the event to run after the current one has > >> finished. I would be interested in hearing whether anyone > >> else has > >> encountered this kind of bug, or whether they have better > >> suggestions. > >> > >> You can see two examples of this bug in the code attached here > >> (where the first example is for ComboBox where the value is > >> updated in the onAction callback....which is called when value > >> changes): > >> > >> http://javafx-jira.kenai.com/browse/RT-22478 > >> http://javafx-jira.kenai.com/browse/RT-17772 > >> > >> -- Jonathan > >> > >> > >> > >> > >> > > > > > > From richard.bair at oracle.com Thu Jun 21 16:30:48 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 21 Jun 2012 16:30:48 -0700 Subject: Dealing with nested events for a single property in JavaFX In-Reply-To: References: <4FE39E22.9000205@oracle.com> <4FE3A2A2.5040406@oracle.com> <4FE3A48F.5030505@oracle.com> <3FBE4B72-986C-4446-883B-C1B6E854C69D@oracle.com> Message-ID: <64D3E053-B778-4483-9B2E-FA85ACDEB329@oracle.com> No I believe the value would still be "true" immediately. And to be clear I'm talking about Event events here, not change notification listeners. So ActionEvent, MouseEvent, etc. But that does give pause to consider listeners as well. I don't think you can queue those up. So specifically I think this issue is about whether: node.fireEvent(newEvent) is layered or queued, without having to be placed on the actual EventQueue (ie: runLater). Richard On Jun 21, 2012, at 4:18 PM, Daniel Zwolenski wrote: > It's not totally clear: I assume you are talking about a queue per property? Or do you mean one big queue for all properties? > > In either case I think we introduce a potential problem with this. Let's say we have: > > BooleanProperty one; > BooleanProperty two; > two.bind(one); > > Then in normal code we do this: > > one.set(true); > two.get(); // value is 'true' as a result of binding > > But if we do the exact same code in a callback it has a different result: > > one.onValueChanged() { > one.set(true); > two.get(); // value is 'false' as event hasn't been processed yet > } > > With a queue per property the problem is limited to only when you are listening on your own value and just maybe we could get away with that (I'm not convinced though, 'feels' dangerous). With one big queue it is really nasty as it would totally change the semantics of code depending on whether it was being called from within a property callback or not. > > > > On Fri, Jun 22, 2012 at 8:54 AM, Richard Bair wrote: > Right, so what it comes down to is: do we layer events, or queue events? RunLater is wrong because we might insert a pulse between events on the queue so you will render things incorrectly for some brief period of time. > > It seems like handling events sequentially as they occur is the right semantic, rather than the "onion" approach where partway through handling event 1 we issue event 2. The problem here is that event 2 is handled, and then the rest of event 1 is handled, which now has the wrong state (if it was carrying state related to that first event. > > Of course by queuing events it is possible people will end up with handling so many events that the app thread is always busy and not processing the queue -- but then they can get into infinite recursion and all kinds of other issues, so I don't see that as a problem but just the nature of the beast. > > Richard > > On Jun 21, 2012, at 3:47 PM, Jonathan Giles wrote: > > > The point is: can we have a better solution by considering changing the event API such that it queues events, rather than do them immediately as they are fired. > > > > -- Jonathan > > > > On 22/06/2012 10:46 a.m., Slavko Scekic wrote: > >> So, the point is: be careful? :) > >> > >> On Fri, Jun 22, 2012 at 12:39 AM, Jonathan Giles > wrote: > >> > >> runLater is wrong more often than it is right - so you're right - > >> I don't think we should consider that approach (or requiring > >> people to have to know to do this) > >> > >> Saying that you should error out when someone tries to update a > >> property in the event callback is also wrong, I think. There are > >> legitimate use cases, for example as a last ditch form of > >> validation: if the value is outside the allowable range, change it > >> back to something that is valid. Alternatively, when focus is > >> given to a node, request a focus change on another node. I imagine > >> our own code would blow up if we took this approach :-) > >> > >> -- Jonathan > >> > >> > >> On 22/06/2012 10:31 a.m., Daniel Zwolenski wrote: > >> > >> Similar to the ConcurrentModification thing you get with > >> Collections right? Could it be handled in a similar way, i.e. > >> throw an error if someone tries to update the property they > >> are modifying while in the update callback for that property? > >> As you say, it's user error, so slapping them on the wrists is ok. > >> > >> The runLater one feels like it could cause its own problems to > >> me. The 'single' threadedness of JFX is part of it's design. > >> It gives me deterministic behaviour, this feels like it could > >> open up small cracks in that. Obviously we wouldn't get > >> concurrency/deadlock issues but I suspect we could get things > >> in a non-deterministic order as a result of this (e.g. if > >> another thread does a runLater somewhere else in the code at > >> the same time this runLater is being added). Could end up that > >> my property change is overwritten sometimes but not others, > >> etc (I'm going more off gut feel here though than concrete > >> examples). > >> > >> > >> On Fri, Jun 22, 2012 at 8:20 AM, Jonathan Giles > >> > >> >> >> wrote: > >> > >> Hi all, > >> > >> I'm going to keep this brief as I'm fairly comprehensively > >> underwater on the bug count. > >> > >> Recently I've found a pattern of bug that, well, I'm fairly > >> sure > >> is due to user error, but is not obvious at all (and as such it > >> leads to bug reports). In the last week, I've encountered this > >> issue twice. The basic issue is that of listening to an > >> event (for > >> example, a focus change event), and reacting in such a way > >> as to > >> modify the state of this property (which results in another > >> event > >> being fired). The end result is non-deterministic (but often > >> broken behavior). Interestingly, it has in both my cases > >> manifested itself as something that works once, and then fails > >> after that forever more. > >> > >> In both cases, after much code digging and debugging (although > >> today was made much easier by the same issue last week), I > >> believe > >> the issue can be worked around simply by wrapping the change to > >> the property state (in the event callback) with a > >> Platform.runLater(new Runnable() { ...}). This forces the > >> second > >> property update to happen after the first event has finished > >> firing (at some point in the future). > >> > >> However, this isn't a great solution - we're forcing the > >> event to > >> fire at a later date where the state may have already > >> changed. The > >> better solution, in my opinion, is to improve the event system > >> such that it knows whether an event is already firing, and > >> if so > >> it will queue up the event to run after the current one has > >> finished. I would be interested in hearing whether anyone > >> else has > >> encountered this kind of bug, or whether they have better > >> suggestions. > >> > >> You can see two examples of this bug in the code attached here > >> (where the first example is for ComboBox where the value is > >> updated in the onAction callback....which is called when value > >> changes): > >> > >> http://javafx-jira.kenai.com/browse/RT-22478 > >> http://javafx-jira.kenai.com/browse/RT-17772 > >> > >> -- Jonathan > >> > >> > >> > >> > >> > > > > > > From zonski at googlemail.com Thu Jun 21 16:38:27 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Fri, 22 Jun 2012 09:38:27 +1000 Subject: Dealing with nested events for a single property in JavaFX In-Reply-To: <64D3E053-B778-4483-9B2E-FA85ACDEB329@oracle.com> References: <4FE39E22.9000205@oracle.com> <4FE3A2A2.5040406@oracle.com> <4FE3A48F.5030505@oracle.com> <3FBE4B72-986C-4446-883B-C1B6E854C69D@oracle.com> <64D3E053-B778-4483-9B2E-FA85ACDEB329@oracle.com> Message-ID: Jonathan's second JIRA (http://javafx-jira.kenai.com/browse/RT-17772) uses a TextProperty with a ChangeListener, i.e. it is not limited to 'Event events'. On Fri, Jun 22, 2012 at 9:30 AM, Richard Bair wrote: > No I believe the value would still be "true" immediately. And to be clear > I'm talking about Event events here, not change notification listeners. So > ActionEvent, MouseEvent, etc. > > But that does give pause to consider listeners as well. I don't think you > can queue those up. So specifically I think this issue is about whether: > > node.fireEvent(newEvent) > > is layered or queued, without having to be placed on the actual EventQueue > (ie: runLater). > > Richard > > On Jun 21, 2012, at 4:18 PM, Daniel Zwolenski wrote: > > It's not totally clear: I assume you are talking about a queue per > property? Or do you mean one big queue for all properties? > > In either case I think we introduce a potential problem with this. Let's > say we have: > > BooleanProperty one; > BooleanProperty two; > two.bind(one); > > Then in normal code we do this: > > one.set(true); > two.get(); // value is 'true' as a result of binding > > But if we do the exact same code in a callback it has a different result: > > one.onValueChanged() { > one.set(true); > two.get(); // value is 'false' as event hasn't been processed yet > } > > With a queue per property the problem is limited to only when you are > listening on your own value and just maybe we could get away with that (I'm > not convinced though, 'feels' dangerous). With one big queue it is really > nasty as it would totally change the semantics of code depending on whether > it was being called from within a property callback or not. > > > > On Fri, Jun 22, 2012 at 8:54 AM, Richard Bair wrote: > >> Right, so what it comes down to is: do we layer events, or queue events? >> RunLater is wrong because we might insert a pulse between events on the >> queue so you will render things incorrectly for some brief period of time. >> >> It seems like handling events sequentially as they occur is the right >> semantic, rather than the "onion" approach where partway through handling >> event 1 we issue event 2. The problem here is that event 2 is handled, and >> then the rest of event 1 is handled, which now has the wrong state (if it >> was carrying state related to that first event. >> >> Of course by queuing events it is possible people will end up with >> handling so many events that the app thread is always busy and not >> processing the queue -- but then they can get into infinite recursion and >> all kinds of other issues, so I don't see that as a problem but just the >> nature of the beast. >> >> Richard >> >> On Jun 21, 2012, at 3:47 PM, Jonathan Giles wrote: >> >> > The point is: can we have a better solution by considering changing the >> event API such that it queues events, rather than do them immediately as >> they are fired. >> > >> > -- Jonathan >> > >> > On 22/06/2012 10:46 a.m., Slavko Scekic wrote: >> >> So, the point is: be careful? :) >> >> >> >> On Fri, Jun 22, 2012 at 12:39 AM, Jonathan Giles < >> jonathan.giles at oracle.com > wrote: >> >> >> >> runLater is wrong more often than it is right - so you're right - >> >> I don't think we should consider that approach (or requiring >> >> people to have to know to do this) >> >> >> >> Saying that you should error out when someone tries to update a >> >> property in the event callback is also wrong, I think. There are >> >> legitimate use cases, for example as a last ditch form of >> >> validation: if the value is outside the allowable range, change it >> >> back to something that is valid. Alternatively, when focus is >> >> given to a node, request a focus change on another node. I imagine >> >> our own code would blow up if we took this approach :-) >> >> >> >> -- Jonathan >> >> >> >> >> >> On 22/06/2012 10:31 a.m., Daniel Zwolenski wrote: >> >> >> >> Similar to the ConcurrentModification thing you get with >> >> Collections right? Could it be handled in a similar way, i.e. >> >> throw an error if someone tries to update the property they >> >> are modifying while in the update callback for that property? >> >> As you say, it's user error, so slapping them on the wrists is >> ok. >> >> >> >> The runLater one feels like it could cause its own problems to >> >> me. The 'single' threadedness of JFX is part of it's design. >> >> It gives me deterministic behaviour, this feels like it could >> >> open up small cracks in that. Obviously we wouldn't get >> >> concurrency/deadlock issues but I suspect we could get things >> >> in a non-deterministic order as a result of this (e.g. if >> >> another thread does a runLater somewhere else in the code at >> >> the same time this runLater is being added). Could end up that >> >> my property change is overwritten sometimes but not others, >> >> etc (I'm going more off gut feel here though than concrete >> >> examples). >> >> >> >> >> >> On Fri, Jun 22, 2012 at 8:20 AM, Jonathan Giles >> >> >> >> > >> >> wrote: >> >> >> >> Hi all, >> >> >> >> I'm going to keep this brief as I'm fairly comprehensively >> >> underwater on the bug count. >> >> >> >> Recently I've found a pattern of bug that, well, I'm fairly >> >> sure >> >> is due to user error, but is not obvious at all (and as such >> it >> >> leads to bug reports). In the last week, I've encountered >> this >> >> issue twice. The basic issue is that of listening to an >> >> event (for >> >> example, a focus change event), and reacting in such a way >> >> as to >> >> modify the state of this property (which results in another >> >> event >> >> being fired). The end result is non-deterministic (but often >> >> broken behavior). Interestingly, it has in both my cases >> >> manifested itself as something that works once, and then >> fails >> >> after that forever more. >> >> >> >> In both cases, after much code digging and debugging >> (although >> >> today was made much easier by the same issue last week), I >> >> believe >> >> the issue can be worked around simply by wrapping the change >> to >> >> the property state (in the event callback) with a >> >> Platform.runLater(new Runnable() { ...}). This forces the >> >> second >> >> property update to happen after the first event has finished >> >> firing (at some point in the future). >> >> >> >> However, this isn't a great solution - we're forcing the >> >> event to >> >> fire at a later date where the state may have already >> >> changed. The >> >> better solution, in my opinion, is to improve the event >> system >> >> such that it knows whether an event is already firing, and >> >> if so >> >> it will queue up the event to run after the current one has >> >> finished. I would be interested in hearing whether anyone >> >> else has >> >> encountered this kind of bug, or whether they have better >> >> suggestions. >> >> >> >> You can see two examples of this bug in the code attached >> here >> >> (where the first example is for ComboBox where the value is >> >> updated in the onAction callback....which is called when >> value >> >> changes): >> >> >> >> http://javafx-jira.kenai.com/browse/RT-22478 >> >> http://javafx-jira.kenai.com/browse/RT-17772 >> >> >> >> -- Jonathan >> >> >> >> >> >> >> >> >> >> >> > >> > >> >> > > From steve.x.northover at oracle.com Thu Jun 21 17:17:28 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Thu, 21 Jun 2012 20:17:28 -0400 Subject: Dealing with nested events for a single property in JavaFX In-Reply-To: References: <4FE39E22.9000205@oracle.com> <4FE3A2A2.5040406@oracle.com> <4FE3A48F.5030505@oracle.com> <3FBE4B72-986C-4446-883B-C1B6E854C69D@oracle.com> <64D3E053-B778-4483-9B2E-FA85ACDEB329@oracle.com> Message-ID: <4FE3B998.2000302@oracle.com> Exactly what is happening now? Are we recursing ? If so, although normally unwanted, I believe this is *correct*. It allows very smart people to make a change, ignore the event caused by it and keep going by stacking a boolean state within a listener. If we queue, then how do they do this? Steve On 21/06/2012 7:38 PM, Daniel Zwolenski wrote: > Jonathan's second JIRA (http://javafx-jira.kenai.com/browse/RT-17772) uses > a TextProperty with a ChangeListener, i.e. it is not limited to 'Event > events'. > > > On Fri, Jun 22, 2012 at 9:30 AM, Richard Bairwrote: > >> No I believe the value would still be "true" immediately. And to be clear >> I'm talking about Event events here, not change notification listeners. So >> ActionEvent, MouseEvent, etc. >> >> But that does give pause to consider listeners as well. I don't think you >> can queue those up. So specifically I think this issue is about whether: >> >> node.fireEvent(newEvent) >> >> is layered or queued, without having to be placed on the actual EventQueue >> (ie: runLater). >> >> Richard >> >> On Jun 21, 2012, at 4:18 PM, Daniel Zwolenski wrote: >> >> It's not totally clear: I assume you are talking about a queue per >> property? Or do you mean one big queue for all properties? >> >> In either case I think we introduce a potential problem with this. Let's >> say we have: >> >> BooleanProperty one; >> BooleanProperty two; >> two.bind(one); >> >> Then in normal code we do this: >> >> one.set(true); >> two.get(); // value is 'true' as a result of binding >> >> But if we do the exact same code in a callback it has a different result: >> >> one.onValueChanged() { >> one.set(true); >> two.get(); // value is 'false' as event hasn't been processed yet >> } >> >> With a queue per property the problem is limited to only when you are >> listening on your own value and just maybe we could get away with that (I'm >> not convinced though, 'feels' dangerous). With one big queue it is really >> nasty as it would totally change the semantics of code depending on whether >> it was being called from within a property callback or not. >> >> >> >> On Fri, Jun 22, 2012 at 8:54 AM, Richard Bairwrote: >> >>> Right, so what it comes down to is: do we layer events, or queue events? >>> RunLater is wrong because we might insert a pulse between events on the >>> queue so you will render things incorrectly for some brief period of time. >>> >>> It seems like handling events sequentially as they occur is the right >>> semantic, rather than the "onion" approach where partway through handling >>> event 1 we issue event 2. The problem here is that event 2 is handled, and >>> then the rest of event 1 is handled, which now has the wrong state (if it >>> was carrying state related to that first event. >>> >>> Of course by queuing events it is possible people will end up with >>> handling so many events that the app thread is always busy and not >>> processing the queue -- but then they can get into infinite recursion and >>> all kinds of other issues, so I don't see that as a problem but just the >>> nature of the beast. >>> >>> Richard >>> >>> On Jun 21, 2012, at 3:47 PM, Jonathan Giles wrote: >>> >>>> The point is: can we have a better solution by considering changing the >>> event API such that it queues events, rather than do them immediately as >>> they are fired. >>>> -- Jonathan >>>> >>>> On 22/06/2012 10:46 a.m., Slavko Scekic wrote: >>>>> So, the point is: be careful? :) >>>>> >>>>> On Fri, Jun 22, 2012 at 12:39 AM, Jonathan Giles< >>> jonathan.giles at oracle.com> wrote: >>>>> runLater is wrong more often than it is right - so you're right - >>>>> I don't think we should consider that approach (or requiring >>>>> people to have to know to do this) >>>>> >>>>> Saying that you should error out when someone tries to update a >>>>> property in the event callback is also wrong, I think. There are >>>>> legitimate use cases, for example as a last ditch form of >>>>> validation: if the value is outside the allowable range, change it >>>>> back to something that is valid. Alternatively, when focus is >>>>> given to a node, request a focus change on another node. I imagine >>>>> our own code would blow up if we took this approach :-) >>>>> >>>>> -- Jonathan >>>>> >>>>> >>>>> On 22/06/2012 10:31 a.m., Daniel Zwolenski wrote: >>>>> >>>>> Similar to the ConcurrentModification thing you get with >>>>> Collections right? Could it be handled in a similar way, i.e. >>>>> throw an error if someone tries to update the property they >>>>> are modifying while in the update callback for that property? >>>>> As you say, it's user error, so slapping them on the wrists is >>> ok. >>>>> The runLater one feels like it could cause its own problems to >>>>> me. The 'single' threadedness of JFX is part of it's design. >>>>> It gives me deterministic behaviour, this feels like it could >>>>> open up small cracks in that. Obviously we wouldn't get >>>>> concurrency/deadlock issues but I suspect we could get things >>>>> in a non-deterministic order as a result of this (e.g. if >>>>> another thread does a runLater somewhere else in the code at >>>>> the same time this runLater is being added). Could end up that >>>>> my property change is overwritten sometimes but not others, >>>>> etc (I'm going more off gut feel here though than concrete >>>>> examples). >>>>> >>>>> >>>>> On Fri, Jun 22, 2012 at 8:20 AM, Jonathan Giles >>>>> >>>>> >>>> >> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I'm going to keep this brief as I'm fairly comprehensively >>>>> underwater on the bug count. >>>>> >>>>> Recently I've found a pattern of bug that, well, I'm fairly >>>>> sure >>>>> is due to user error, but is not obvious at all (and as such >>> it >>>>> leads to bug reports). In the last week, I've encountered >>> this >>>>> issue twice. The basic issue is that of listening to an >>>>> event (for >>>>> example, a focus change event), and reacting in such a way >>>>> as to >>>>> modify the state of this property (which results in another >>>>> event >>>>> being fired). The end result is non-deterministic (but often >>>>> broken behavior). Interestingly, it has in both my cases >>>>> manifested itself as something that works once, and then >>> fails >>>>> after that forever more. >>>>> >>>>> In both cases, after much code digging and debugging >>> (although >>>>> today was made much easier by the same issue last week), I >>>>> believe >>>>> the issue can be worked around simply by wrapping the change >>> to >>>>> the property state (in the event callback) with a >>>>> Platform.runLater(new Runnable() { ...}). This forces the >>>>> second >>>>> property update to happen after the first event has finished >>>>> firing (at some point in the future). >>>>> >>>>> However, this isn't a great solution - we're forcing the >>>>> event to >>>>> fire at a later date where the state may have already >>>>> changed. The >>>>> better solution, in my opinion, is to improve the event >>> system >>>>> such that it knows whether an event is already firing, and >>>>> if so >>>>> it will queue up the event to run after the current one has >>>>> finished. I would be interested in hearing whether anyone >>>>> else has >>>>> encountered this kind of bug, or whether they have better >>>>> suggestions. >>>>> >>>>> You can see two examples of this bug in the code attached >>> here >>>>> (where the first example is for ComboBox where the value is >>>>> updated in the onAction callback....which is called when >>> value >>>>> changes): >>>>> >>>>> http://javafx-jira.kenai.com/browse/RT-22478 >>>>> http://javafx-jira.kenai.com/browse/RT-17772 >>>>> >>>>> -- Jonathan >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> From richard.bair at oracle.com Thu Jun 21 17:36:11 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 21 Jun 2012 17:36:11 -0700 Subject: Dealing with nested events for a single property in JavaFX In-Reply-To: <4FE3B998.2000302@oracle.com> References: <4FE39E22.9000205@oracle.com> <4FE3A2A2.5040406@oracle.com> <4FE3A48F.5030505@oracle.com> <3FBE4B72-986C-4446-883B-C1B6E854C69D@oracle.com> <64D3E053-B778-4483-9B2E-FA85ACDEB329@oracle.com> <4FE3B998.2000302@oracle.com> Message-ID: <401017DC-449B-4A58-9251-4FBE89AE3123@oracle.com> I don't recursion is the right phrase, but we fire the new event immediately. The problem with this is that two guys might be listening to the same event. The first guy is notified and changes the state of the thing, causing a new event to fire. The second guy gets this new event first, and reacts to it. The second guy then gets the first event and reacts to it. From his point of view, the second event happened first, and the first second. So we end up with a hopeless situation for the poor guy in a loosely coupled app. He doesn't know that he handled events out of ordered, and without violating encapsulation, he can't know. Unless of course we have a timestamp on the event object and throw away events that occurred after the one he most recently handled. Richard On Jun 21, 2012, at 5:17 PM, steve.x.northover at oracle.com wrote: > Exactly what is happening now? Are we recursing ? If so, although normally unwanted, I believe this is *correct*. It allows very smart people to make a change, ignore the event caused by it and keep going by stacking a boolean state within a listener. If we queue, then how do they do this? > > Steve > > On 21/06/2012 7:38 PM, Daniel Zwolenski wrote: >> Jonathan's second JIRA (http://javafx-jira.kenai.com/browse/RT-17772) uses >> a TextProperty with a ChangeListener, i.e. it is not limited to 'Event >> events'. >> >> >> On Fri, Jun 22, 2012 at 9:30 AM, Richard Bairwrote: >> >>> No I believe the value would still be "true" immediately. And to be clear >>> I'm talking about Event events here, not change notification listeners. So >>> ActionEvent, MouseEvent, etc. >>> >>> But that does give pause to consider listeners as well. I don't think you >>> can queue those up. So specifically I think this issue is about whether: >>> >>> node.fireEvent(newEvent) >>> >>> is layered or queued, without having to be placed on the actual EventQueue >>> (ie: runLater). >>> >>> Richard >>> >>> On Jun 21, 2012, at 4:18 PM, Daniel Zwolenski wrote: >>> >>> It's not totally clear: I assume you are talking about a queue per >>> property? Or do you mean one big queue for all properties? >>> >>> In either case I think we introduce a potential problem with this. Let's >>> say we have: >>> >>> BooleanProperty one; >>> BooleanProperty two; >>> two.bind(one); >>> >>> Then in normal code we do this: >>> >>> one.set(true); >>> two.get(); // value is 'true' as a result of binding >>> >>> But if we do the exact same code in a callback it has a different result: >>> >>> one.onValueChanged() { >>> one.set(true); >>> two.get(); // value is 'false' as event hasn't been processed yet >>> } >>> >>> With a queue per property the problem is limited to only when you are >>> listening on your own value and just maybe we could get away with that (I'm >>> not convinced though, 'feels' dangerous). With one big queue it is really >>> nasty as it would totally change the semantics of code depending on whether >>> it was being called from within a property callback or not. >>> >>> >>> >>> On Fri, Jun 22, 2012 at 8:54 AM, Richard Bairwrote: >>> >>>> Right, so what it comes down to is: do we layer events, or queue events? >>>> RunLater is wrong because we might insert a pulse between events on the >>>> queue so you will render things incorrectly for some brief period of time. >>>> >>>> It seems like handling events sequentially as they occur is the right >>>> semantic, rather than the "onion" approach where partway through handling >>>> event 1 we issue event 2. The problem here is that event 2 is handled, and >>>> then the rest of event 1 is handled, which now has the wrong state (if it >>>> was carrying state related to that first event. >>>> >>>> Of course by queuing events it is possible people will end up with >>>> handling so many events that the app thread is always busy and not >>>> processing the queue -- but then they can get into infinite recursion and >>>> all kinds of other issues, so I don't see that as a problem but just the >>>> nature of the beast. >>>> >>>> Richard >>>> >>>> On Jun 21, 2012, at 3:47 PM, Jonathan Giles wrote: >>>> >>>>> The point is: can we have a better solution by considering changing the >>>> event API such that it queues events, rather than do them immediately as >>>> they are fired. >>>>> -- Jonathan >>>>> >>>>> On 22/06/2012 10:46 a.m., Slavko Scekic wrote: >>>>>> So, the point is: be careful? :) >>>>>> >>>>>> On Fri, Jun 22, 2012 at 12:39 AM, Jonathan Giles< >>>> jonathan.giles at oracle.com> wrote: >>>>>> runLater is wrong more often than it is right - so you're right - >>>>>> I don't think we should consider that approach (or requiring >>>>>> people to have to know to do this) >>>>>> >>>>>> Saying that you should error out when someone tries to update a >>>>>> property in the event callback is also wrong, I think. There are >>>>>> legitimate use cases, for example as a last ditch form of >>>>>> validation: if the value is outside the allowable range, change it >>>>>> back to something that is valid. Alternatively, when focus is >>>>>> given to a node, request a focus change on another node. I imagine >>>>>> our own code would blow up if we took this approach :-) >>>>>> >>>>>> -- Jonathan >>>>>> >>>>>> >>>>>> On 22/06/2012 10:31 a.m., Daniel Zwolenski wrote: >>>>>> >>>>>> Similar to the ConcurrentModification thing you get with >>>>>> Collections right? Could it be handled in a similar way, i.e. >>>>>> throw an error if someone tries to update the property they >>>>>> are modifying while in the update callback for that property? >>>>>> As you say, it's user error, so slapping them on the wrists is >>>> ok. >>>>>> The runLater one feels like it could cause its own problems to >>>>>> me. The 'single' threadedness of JFX is part of it's design. >>>>>> It gives me deterministic behaviour, this feels like it could >>>>>> open up small cracks in that. Obviously we wouldn't get >>>>>> concurrency/deadlock issues but I suspect we could get things >>>>>> in a non-deterministic order as a result of this (e.g. if >>>>>> another thread does a runLater somewhere else in the code at >>>>>> the same time this runLater is being added). Could end up that >>>>>> my property change is overwritten sometimes but not others, >>>>>> etc (I'm going more off gut feel here though than concrete >>>>>> examples). >>>>>> >>>>>> >>>>>> On Fri, Jun 22, 2012 at 8:20 AM, Jonathan Giles >>>>>> >>>>>> >>>>> >> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I'm going to keep this brief as I'm fairly comprehensively >>>>>> underwater on the bug count. >>>>>> >>>>>> Recently I've found a pattern of bug that, well, I'm fairly >>>>>> sure >>>>>> is due to user error, but is not obvious at all (and as such >>>> it >>>>>> leads to bug reports). In the last week, I've encountered >>>> this >>>>>> issue twice. The basic issue is that of listening to an >>>>>> event (for >>>>>> example, a focus change event), and reacting in such a way >>>>>> as to >>>>>> modify the state of this property (which results in another >>>>>> event >>>>>> being fired). The end result is non-deterministic (but often >>>>>> broken behavior). Interestingly, it has in both my cases >>>>>> manifested itself as something that works once, and then >>>> fails >>>>>> after that forever more. >>>>>> >>>>>> In both cases, after much code digging and debugging >>>> (although >>>>>> today was made much easier by the same issue last week), I >>>>>> believe >>>>>> the issue can be worked around simply by wrapping the change >>>> to >>>>>> the property state (in the event callback) with a >>>>>> Platform.runLater(new Runnable() { ...}). This forces the >>>>>> second >>>>>> property update to happen after the first event has finished >>>>>> firing (at some point in the future). >>>>>> >>>>>> However, this isn't a great solution - we're forcing the >>>>>> event to >>>>>> fire at a later date where the state may have already >>>>>> changed. The >>>>>> better solution, in my opinion, is to improve the event >>>> system >>>>>> such that it knows whether an event is already firing, and >>>>>> if so >>>>>> it will queue up the event to run after the current one has >>>>>> finished. I would be interested in hearing whether anyone >>>>>> else has >>>>>> encountered this kind of bug, or whether they have better >>>>>> suggestions. >>>>>> >>>>>> You can see two examples of this bug in the code attached >>>> here >>>>>> (where the first example is for ComboBox where the value is >>>>>> updated in the onAction callback....which is called when >>>> value >>>>>> changes): >>>>>> >>>>>> http://javafx-jira.kenai.com/browse/RT-22478 >>>>>> http://javafx-jira.kenai.com/browse/RT-17772 >>>>>> >>>>>> -- Jonathan >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> From steve.x.northover at oracle.com Thu Jun 21 18:37:43 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Thu, 21 Jun 2012 21:37:43 -0400 Subject: Dealing with nested events for a single property in JavaFX In-Reply-To: <401017DC-449B-4A58-9251-4FBE89AE3123@oracle.com> References: <4FE39E22.9000205@oracle.com> <4FE3A2A2.5040406@oracle.com> <4FE3A48F.5030505@oracle.com> <3FBE4B72-986C-4446-883B-C1B6E854C69D@oracle.com> <64D3E053-B778-4483-9B2E-FA85ACDEB329@oracle.com> <4FE3B998.2000302@oracle.com> <401017DC-449B-4A58-9251-4FBE89AE3123@oracle.com> Message-ID: <4FE3CC67.1030104@oracle.com> If the event is queue rather than stacked, then the first guy gets called with A and changes A to B (it queues), the next guy gets called with A, then the first guy gets called with B, then the next guy gets called with B. This would have to happen for every guy that might change the value from A to B to C etc. so we would need to keep all the outstanding values somewhere. Steve On 21/06/2012 8:36 PM, Richard Bair wrote: > I don't recursion is the right phrase, but we fire the new event immediately. The problem with this is that two guys might be listening to the same event. The first guy is notified and changes the state of the thing, causing a new event to fire. The second guy gets this new event first, and reacts to it. The second guy then gets the first event and reacts to it. From his point of view, the second event happened first, and the first second. So we end up with a hopeless situation for the poor guy in a loosely coupled app. He doesn't know that he handled events out of ordered, and without violating encapsulation, he can't know. > > Unless of course we have a timestamp on the event object and throw away events that occurred after the one he most recently handled. > > Richard > > On Jun 21, 2012, at 5:17 PM, steve.x.northover at oracle.com wrote: > >> Exactly what is happening now? Are we recursing ? If so, although normally unwanted, I believe this is *correct*. It allows very smart people to make a change, ignore the event caused by it and keep going by stacking a boolean state within a listener. If we queue, then how do they do this? >> >> Steve >> >> On 21/06/2012 7:38 PM, Daniel Zwolenski wrote: >>> Jonathan's second JIRA (http://javafx-jira.kenai.com/browse/RT-17772) uses >>> a TextProperty with a ChangeListener, i.e. it is not limited to 'Event >>> events'. >>> >>> >>> On Fri, Jun 22, 2012 at 9:30 AM, Richard Bairwrote: >>> >>>> No I believe the value would still be "true" immediately. And to be clear >>>> I'm talking about Event events here, not change notification listeners. So >>>> ActionEvent, MouseEvent, etc. >>>> >>>> But that does give pause to consider listeners as well. I don't think you >>>> can queue those up. So specifically I think this issue is about whether: >>>> >>>> node.fireEvent(newEvent) >>>> >>>> is layered or queued, without having to be placed on the actual EventQueue >>>> (ie: runLater). >>>> >>>> Richard >>>> >>>> On Jun 21, 2012, at 4:18 PM, Daniel Zwolenski wrote: >>>> >>>> It's not totally clear: I assume you are talking about a queue per >>>> property? Or do you mean one big queue for all properties? >>>> >>>> In either case I think we introduce a potential problem with this. Let's >>>> say we have: >>>> >>>> BooleanProperty one; >>>> BooleanProperty two; >>>> two.bind(one); >>>> >>>> Then in normal code we do this: >>>> >>>> one.set(true); >>>> two.get(); // value is 'true' as a result of binding >>>> >>>> But if we do the exact same code in a callback it has a different result: >>>> >>>> one.onValueChanged() { >>>> one.set(true); >>>> two.get(); // value is 'false' as event hasn't been processed yet >>>> } >>>> >>>> With a queue per property the problem is limited to only when you are >>>> listening on your own value and just maybe we could get away with that (I'm >>>> not convinced though, 'feels' dangerous). With one big queue it is really >>>> nasty as it would totally change the semantics of code depending on whether >>>> it was being called from within a property callback or not. >>>> >>>> >>>> >>>> On Fri, Jun 22, 2012 at 8:54 AM, Richard Bairwrote: >>>> >>>>> Right, so what it comes down to is: do we layer events, or queue events? >>>>> RunLater is wrong because we might insert a pulse between events on the >>>>> queue so you will render things incorrectly for some brief period of time. >>>>> >>>>> It seems like handling events sequentially as they occur is the right >>>>> semantic, rather than the "onion" approach where partway through handling >>>>> event 1 we issue event 2. The problem here is that event 2 is handled, and >>>>> then the rest of event 1 is handled, which now has the wrong state (if it >>>>> was carrying state related to that first event. >>>>> >>>>> Of course by queuing events it is possible people will end up with >>>>> handling so many events that the app thread is always busy and not >>>>> processing the queue -- but then they can get into infinite recursion and >>>>> all kinds of other issues, so I don't see that as a problem but just the >>>>> nature of the beast. >>>>> >>>>> Richard >>>>> >>>>> On Jun 21, 2012, at 3:47 PM, Jonathan Giles wrote: >>>>> >>>>>> The point is: can we have a better solution by considering changing the >>>>> event API such that it queues events, rather than do them immediately as >>>>> they are fired. >>>>>> -- Jonathan >>>>>> >>>>>> On 22/06/2012 10:46 a.m., Slavko Scekic wrote: >>>>>>> So, the point is: be careful? :) >>>>>>> >>>>>>> On Fri, Jun 22, 2012 at 12:39 AM, Jonathan Giles< >>>>> jonathan.giles at oracle.com> wrote: >>>>>>> runLater is wrong more often than it is right - so you're right - >>>>>>> I don't think we should consider that approach (or requiring >>>>>>> people to have to know to do this) >>>>>>> >>>>>>> Saying that you should error out when someone tries to update a >>>>>>> property in the event callback is also wrong, I think. There are >>>>>>> legitimate use cases, for example as a last ditch form of >>>>>>> validation: if the value is outside the allowable range, change it >>>>>>> back to something that is valid. Alternatively, when focus is >>>>>>> given to a node, request a focus change on another node. I imagine >>>>>>> our own code would blow up if we took this approach :-) >>>>>>> >>>>>>> -- Jonathan >>>>>>> >>>>>>> >>>>>>> On 22/06/2012 10:31 a.m., Daniel Zwolenski wrote: >>>>>>> >>>>>>> Similar to the ConcurrentModification thing you get with >>>>>>> Collections right? Could it be handled in a similar way, i.e. >>>>>>> throw an error if someone tries to update the property they >>>>>>> are modifying while in the update callback for that property? >>>>>>> As you say, it's user error, so slapping them on the wrists is >>>>> ok. >>>>>>> The runLater one feels like it could cause its own problems to >>>>>>> me. The 'single' threadedness of JFX is part of it's design. >>>>>>> It gives me deterministic behaviour, this feels like it could >>>>>>> open up small cracks in that. Obviously we wouldn't get >>>>>>> concurrency/deadlock issues but I suspect we could get things >>>>>>> in a non-deterministic order as a result of this (e.g. if >>>>>>> another thread does a runLater somewhere else in the code at >>>>>>> the same time this runLater is being added). Could end up that >>>>>>> my property change is overwritten sometimes but not others, >>>>>>> etc (I'm going more off gut feel here though than concrete >>>>>>> examples). >>>>>>> >>>>>>> >>>>>>> On Fri, Jun 22, 2012 at 8:20 AM, Jonathan Giles >>>>>>> >>>>>>> >>>>>> >> wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I'm going to keep this brief as I'm fairly comprehensively >>>>>>> underwater on the bug count. >>>>>>> >>>>>>> Recently I've found a pattern of bug that, well, I'm fairly >>>>>>> sure >>>>>>> is due to user error, but is not obvious at all (and as such >>>>> it >>>>>>> leads to bug reports). In the last week, I've encountered >>>>> this >>>>>>> issue twice. The basic issue is that of listening to an >>>>>>> event (for >>>>>>> example, a focus change event), and reacting in such a way >>>>>>> as to >>>>>>> modify the state of this property (which results in another >>>>>>> event >>>>>>> being fired). The end result is non-deterministic (but often >>>>>>> broken behavior). Interestingly, it has in both my cases >>>>>>> manifested itself as something that works once, and then >>>>> fails >>>>>>> after that forever more. >>>>>>> >>>>>>> In both cases, after much code digging and debugging >>>>> (although >>>>>>> today was made much easier by the same issue last week), I >>>>>>> believe >>>>>>> the issue can be worked around simply by wrapping the change >>>>> to >>>>>>> the property state (in the event callback) with a >>>>>>> Platform.runLater(new Runnable() { ...}). This forces the >>>>>>> second >>>>>>> property update to happen after the first event has finished >>>>>>> firing (at some point in the future). >>>>>>> >>>>>>> However, this isn't a great solution - we're forcing the >>>>>>> event to >>>>>>> fire at a later date where the state may have already >>>>>>> changed. The >>>>>>> better solution, in my opinion, is to improve the event >>>>> system >>>>>>> such that it knows whether an event is already firing, and >>>>>>> if so >>>>>>> it will queue up the event to run after the current one has >>>>>>> finished. I would be interested in hearing whether anyone >>>>>>> else has >>>>>>> encountered this kind of bug, or whether they have better >>>>>>> suggestions. >>>>>>> >>>>>>> You can see two examples of this bug in the code attached >>>>> here >>>>>>> (where the first example is for ComboBox where the value is >>>>>>> updated in the onAction callback....which is called when >>>>> value >>>>>>> changes): >>>>>>> >>>>>>> http://javafx-jira.kenai.com/browse/RT-22478 >>>>>>> http://javafx-jira.kenai.com/browse/RT-17772 >>>>>>> >>>>>>> -- Jonathan >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> From zonski at googlemail.com Thu Jun 21 18:49:43 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Fri, 22 Jun 2012 11:49:43 +1000 Subject: Dealing with nested events for a single property in JavaFX In-Reply-To: <401017DC-449B-4A58-9251-4FBE89AE3123@oracle.com> References: <4FE39E22.9000205@oracle.com> <4FE3A2A2.5040406@oracle.com> <4FE3A48F.5030505@oracle.com> <3FBE4B72-986C-4446-883B-C1B6E854C69D@oracle.com> <64D3E053-B778-4483-9B2E-FA85ACDEB329@oracle.com> <4FE3B998.2000302@oracle.com> <401017DC-449B-4A58-9251-4FBE89AE3123@oracle.com> Message-ID: Just to add to my previous comment, I don't think this is really about 'Event events' but more about property changes and it just so happens that some Event events are triggered via property changes. I think the JIRA issue alludes to this too: The ComboBox onAction event is called only when the value changes, so what you say in your first paragraph [i.e. <>] is still valid for onAction. I think this is pretty important to take note of, but Jonathan might correct me on this if I am wrong. Interestingly, I just had a look at what Swing does, because surely it's faced with similar problems. With raw PropertyChangeListeners, it works exactly like we have it in JFX now. i.e. nested event handling (aka the "onion" approach) where you can change the Property from within the propertyChangeListener and it will immediately change it and handle all listeners for the new change before finishing off the original change. Meanwhile with the Document of a JTextField, if I try to change the text field's value from within a 'update' event, it throws a "java.lang.IllegalStateException: Attempt to mutate in notification". i.e. the "wrist-slap" approach. Funnily enough focus handling is different again. It uses the requestFocus() method which I guess defers it, kind of like platform.runLater(). i.e. the "queue" approach. Not that Swing is the template for success here but I thought it would give a reference point. Turns out it gives us a reference point for lots of options, which is probably even more confusing. How did Swing get away with this then? My guess: I think this sort of nesting is not a huge problem in traditional apps because the events are not so interwoven. It's the new Properties and all the interconnected listeners that have made this far more noticeable in JFX. You can't really move too far in JFX without triggering a property update which may then ripple on to any number of listeners. On Fri, Jun 22, 2012 at 10:36 AM, Richard Bair wrote: > I don't recursion is the right phrase, but we fire the new event > immediately. The problem with this is that two guys might be listening to > the same event. The first guy is notified and changes the state of the > thing, causing a new event to fire. The second guy gets this new event > first, and reacts to it. The second guy then gets the first event and > reacts to it. From his point of view, the second event happened first, and > the first second. So we end up with a hopeless situation for the poor guy > in a loosely coupled app. He doesn't know that he handled events out of > ordered, and without violating encapsulation, he can't know. > > Unless of course we have a timestamp on the event object and throw away > events that occurred after the one he most recently handled. > > Richard > > On Jun 21, 2012, at 5:17 PM, steve.x.northover at oracle.com wrote: > > > Exactly what is happening now? Are we recursing ? If so, although > normally unwanted, I believe this is *correct*. It allows very smart > people to make a change, ignore the event caused by it and keep going by > stacking a boolean state within a listener. If we queue, then how do they > do this? > > > > Steve > > > > On 21/06/2012 7:38 PM, Daniel Zwolenski wrote: > >> Jonathan's second JIRA (http://javafx-jira.kenai.com/browse/RT-17772) > uses > >> a TextProperty with a ChangeListener, i.e. it is not limited to 'Event > >> events'. > >> > >> > >> On Fri, Jun 22, 2012 at 9:30 AM, Richard Bair >wrote: > >> > >>> No I believe the value would still be "true" immediately. And to be > clear > >>> I'm talking about Event events here, not change notification > listeners. So > >>> ActionEvent, MouseEvent, etc. > >>> > >>> But that does give pause to consider listeners as well. I don't think > you > >>> can queue those up. So specifically I think this issue is about > whether: > >>> > >>> node.fireEvent(newEvent) > >>> > >>> is layered or queued, without having to be placed on the actual > EventQueue > >>> (ie: runLater). > >>> > >>> Richard > >>> > >>> On Jun 21, 2012, at 4:18 PM, Daniel Zwolenski wrote: > >>> > >>> It's not totally clear: I assume you are talking about a queue per > >>> property? Or do you mean one big queue for all properties? > >>> > >>> In either case I think we introduce a potential problem with this. > Let's > >>> say we have: > >>> > >>> BooleanProperty one; > >>> BooleanProperty two; > >>> two.bind(one); > >>> > >>> Then in normal code we do this: > >>> > >>> one.set(true); > >>> two.get(); // value is 'true' as a result of binding > >>> > >>> But if we do the exact same code in a callback it has a different > result: > >>> > >>> one.onValueChanged() { > >>> one.set(true); > >>> two.get(); // value is 'false' as event hasn't been processed yet > >>> } > >>> > >>> With a queue per property the problem is limited to only when you are > >>> listening on your own value and just maybe we could get away with that > (I'm > >>> not convinced though, 'feels' dangerous). With one big queue it is > really > >>> nasty as it would totally change the semantics of code depending on > whether > >>> it was being called from within a property callback or not. > >>> > >>> > >>> > >>> On Fri, Jun 22, 2012 at 8:54 AM, Richard Bair >wrote: > >>> > >>>> Right, so what it comes down to is: do we layer events, or queue > events? > >>>> RunLater is wrong because we might insert a pulse between events on > the > >>>> queue so you will render things incorrectly for some brief period of > time. > >>>> > >>>> It seems like handling events sequentially as they occur is the right > >>>> semantic, rather than the "onion" approach where partway through > handling > >>>> event 1 we issue event 2. The problem here is that event 2 is > handled, and > >>>> then the rest of event 1 is handled, which now has the wrong state > (if it > >>>> was carrying state related to that first event. > >>>> > >>>> Of course by queuing events it is possible people will end up with > >>>> handling so many events that the app thread is always busy and not > >>>> processing the queue -- but then they can get into infinite recursion > and > >>>> all kinds of other issues, so I don't see that as a problem but just > the > >>>> nature of the beast. > >>>> > >>>> Richard > >>>> > >>>> On Jun 21, 2012, at 3:47 PM, Jonathan Giles wrote: > >>>> > >>>>> The point is: can we have a better solution by considering changing > the > >>>> event API such that it queues events, rather than do them immediately > as > >>>> they are fired. > >>>>> -- Jonathan > >>>>> > >>>>> On 22/06/2012 10:46 a.m., Slavko Scekic wrote: > >>>>>> So, the point is: be careful? :) > >>>>>> > >>>>>> On Fri, Jun 22, 2012 at 12:39 AM, Jonathan Giles< > >>>> jonathan.giles at oracle.com> wrote: > >>>>>> runLater is wrong more often than it is right - so you're right - > >>>>>> I don't think we should consider that approach (or requiring > >>>>>> people to have to know to do this) > >>>>>> > >>>>>> Saying that you should error out when someone tries to update a > >>>>>> property in the event callback is also wrong, I think. There are > >>>>>> legitimate use cases, for example as a last ditch form of > >>>>>> validation: if the value is outside the allowable range, change > it > >>>>>> back to something that is valid. Alternatively, when focus is > >>>>>> given to a node, request a focus change on another node. I > imagine > >>>>>> our own code would blow up if we took this approach :-) > >>>>>> > >>>>>> -- Jonathan > >>>>>> > >>>>>> > >>>>>> On 22/06/2012 10:31 a.m., Daniel Zwolenski wrote: > >>>>>> > >>>>>> Similar to the ConcurrentModification thing you get with > >>>>>> Collections right? Could it be handled in a similar way, i.e. > >>>>>> throw an error if someone tries to update the property they > >>>>>> are modifying while in the update callback for that property? > >>>>>> As you say, it's user error, so slapping them on the wrists > is > >>>> ok. > >>>>>> The runLater one feels like it could cause its own problems > to > >>>>>> me. The 'single' threadedness of JFX is part of it's design. > >>>>>> It gives me deterministic behaviour, this feels like it could > >>>>>> open up small cracks in that. Obviously we wouldn't get > >>>>>> concurrency/deadlock issues but I suspect we could get things > >>>>>> in a non-deterministic order as a result of this (e.g. if > >>>>>> another thread does a runLater somewhere else in the code at > >>>>>> the same time this runLater is being added). Could end up > that > >>>>>> my property change is overwritten sometimes but not others, > >>>>>> etc (I'm going more off gut feel here though than concrete > >>>>>> examples). > >>>>>> > >>>>>> > >>>>>> On Fri, Jun 22, 2012 at 8:20 AM, Jonathan Giles > >>>>>> > >>>>>> >>>>>> >> wrote: > >>>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> I'm going to keep this brief as I'm fairly comprehensively > >>>>>> underwater on the bug count. > >>>>>> > >>>>>> Recently I've found a pattern of bug that, well, I'm > fairly > >>>>>> sure > >>>>>> is due to user error, but is not obvious at all (and as > such > >>>> it > >>>>>> leads to bug reports). In the last week, I've encountered > >>>> this > >>>>>> issue twice. The basic issue is that of listening to an > >>>>>> event (for > >>>>>> example, a focus change event), and reacting in such a way > >>>>>> as to > >>>>>> modify the state of this property (which results in > another > >>>>>> event > >>>>>> being fired). The end result is non-deterministic (but > often > >>>>>> broken behavior). Interestingly, it has in both my cases > >>>>>> manifested itself as something that works once, and then > >>>> fails > >>>>>> after that forever more. > >>>>>> > >>>>>> In both cases, after much code digging and debugging > >>>> (although > >>>>>> today was made much easier by the same issue last week), I > >>>>>> believe > >>>>>> the issue can be worked around simply by wrapping the > change > >>>> to > >>>>>> the property state (in the event callback) with a > >>>>>> Platform.runLater(new Runnable() { ...}). This forces the > >>>>>> second > >>>>>> property update to happen after the first event has > finished > >>>>>> firing (at some point in the future). > >>>>>> > >>>>>> However, this isn't a great solution - we're forcing the > >>>>>> event to > >>>>>> fire at a later date where the state may have already > >>>>>> changed. The > >>>>>> better solution, in my opinion, is to improve the event > >>>> system > >>>>>> such that it knows whether an event is already firing, and > >>>>>> if so > >>>>>> it will queue up the event to run after the current one > has > >>>>>> finished. I would be interested in hearing whether anyone > >>>>>> else has > >>>>>> encountered this kind of bug, or whether they have better > >>>>>> suggestions. > >>>>>> > >>>>>> You can see two examples of this bug in the code attached > >>>> here > >>>>>> (where the first example is for ComboBox where the value > is > >>>>>> updated in the onAction callback....which is called when > >>>> value > >>>>>> changes): > >>>>>> > >>>>>> http://javafx-jira.kenai.com/browse/RT-22478 > >>>>>> http://javafx-jira.kenai.com/browse/RT-17772 > >>>>>> > >>>>>> -- Jonathan > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > > From tbee at tbee.org Thu Jun 21 23:01:36 2012 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 22 Jun 2012 08:01:36 +0200 Subject: Dealing with nested events for a single property in JavaFX In-Reply-To: <4FE3A2A2.5040406@oracle.com> References: <4FE39E22.9000205@oracle.com> <4FE3A2A2.5040406@oracle.com> Message-ID: <4FE40A40.1050300@tbee.org> Are we maybe barking up the wrong tree? Isn't the problem at hand better solved by not having the event in the first place? The "change it back to something that is valid" to me sounds like a very wrong approach; shouldn't it have been checked before hand? Or maybe the focus should have never left the old node? Tom On 2012-06-22 00:39, Jonathan Giles wrote: > > Saying that you should error out when someone tries to update a property in the event callback is also wrong, I think. There are legitimate use cases, for example as a last ditch form of validation: if the value is outside the allowable range, change it back to something that is valid. Alternatively, when focus is given to a node, request a focus change on another node. I imagine our own code would blow up if we took this approach :-) From eric.le.ponner at oracle.com Fri Jun 22 03:32:36 2012 From: eric.le.ponner at oracle.com (Eric Le Ponner) Date: Fri, 22 Jun 2012 12:32:36 +0200 Subject: Dealing with nested events for a single property in JavaFX Message-ID: <40FDCB60-D5D6-41F2-90F0-6004C0DCC53D@oracle.com> Hi All, Some comments from the application developer point of view: 1) I don't see RT-22478 and RT-17772 exactly in the same way. I fully agree that RT-17772 can be considered as "user error". FX API is legitimate to refuse that a <> . A "ConcurrentModification" like exception would be nice but not mandatory in my opinion. It is up to the developer to take care. However RT-22478 refers to the onAction() event listener. Although the FX implementation invokes it from a value change listener, from an API spec point of view, this relation does not look like something implicit to me. Calling setValue() from onAction() is something that I would be quickly tempted to do. In fact, RT-22478 does not reveal a "user error" but more a lack of specification in ComboBox API spec. 2) So are we allowed to call setValue() from onAction() ? It's your call guys. However this decision must be carefully taken and very well documented. Especially if Platform.runLater() is the sole answer that is given the application developer to solve her problem. In my own experience invokeLater / runLater / performSelectorOnMainThread tend to transform the "beauty of event management" into a "big nightmare" whether it is Swing, FX or MacOSX? My two cents. Eric On Fri, Jun 22, 2012 at 8:20 AM, Jonathan Giles wrote: > Hi all, > > I'm going to keep this brief as I'm fairly comprehensively underwater on > the bug count. > > Recently I've found a pattern of bug that, well, I'm fairly sure is due > to user error, but is not obvious at all (and as such it leads to bug > reports). In the last week, I've encountered this issue twice. The basic > issue is that of listening to an event (for example, a focus change > event), and reacting in such a way as to modify the state of this > property (which results in another event being fired). The end result is > non-deterministic (but often broken behavior). Interestingly, it has in > both my cases manifested itself as something that works once, and then > fails after that forever more. > > In both cases, after much code digging and debugging (although today was > made much easier by the same issue last week), I believe the issue can > be worked around simply by wrapping the change to the property state (in > the event callback) with a Platform.runLater(new Runnable() { ...}). > This forces the second property update to happen after the first event > has finished firing (at some point in the future). > > However, this isn't a great solution - we're forcing the event to fire > at a later date where the state may have already changed. The better > solution, in my opinion, is to improve the event system such that it > knows whether an event is already firing, and if so it will queue up the > event to run after the current one has finished. I would be interested > in hearing whether anyone else has encountered this kind of bug, or > whether they have better suggestions. > > You can see two examples of this bug in the code attached here (where > the first example is for ComboBox where the value is updated in the > onAction callback....which is called when value changes): > > http://javafx-jira.kenai.com/browse/RT-22478 > http://javafx-jira.kenai.com/browse/RT-17772 > > -- Jonathan From goddard at seznam.cz Fri Jun 22 04:14:18 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Fri, 22 Jun 2012 13:14:18 +0200 (CEST) Subject: =?us-ascii?Q?How=20does=20getProperties=28=29=20method=20work=3F?= Message-ID: <130036.4725.24877-4274-2049084081-1340363658@seznam.cz> Hi, I wanted to query a Rectangle for its properties with getProperties() method, but it always returns empty Map (no elements, zero size). For example, I've got a Rectangle defined like this: Rectangle red = RectangleBuilder.create() .x(100).y(100) .width(100).height(100) .fill(Color.RED) //.stroke(Color.BLACK).strokeWidth(3).strokeType(StrokeType.OUTSIDE) .rotate(45) .build(); Regards, Jiri From eva.krejcirova at oracle.com Fri Jun 22 05:03:41 2012 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Fri, 22 Jun 2012 14:03:41 +0200 Subject: How does getProperties() method work? In-Reply-To: <130036.4725.24877-4274-2049084081-1340363658@seznam.cz> References: <130036.4725.24877-4274-2049084081-1340363658@seznam.cz> Message-ID: <4FE45F1D.9030604@oracle.com> Hi, Node.getProperties returns an ObservableMap which you then can use to store any information you want. It is similar to getUserData/setUserData which actually store the user data in the same map. It has nothing to do with JavaFX properties of a node. We should probably improve the documentation of this method, the current javadoc doesn't seem to clarify this. Eva On 6/22/2012 1:14 PM, goddard at seznam.cz wrote: > Hi, > > I wanted to query a Rectangle for its properties with getProperties() method, but it always returns empty Map (no elements, zero size). > For example, I've got a Rectangle defined like this: > > Rectangle red = RectangleBuilder.create() > .x(100).y(100) > .width(100).height(100) > .fill(Color.RED) > //.stroke(Color.BLACK).strokeWidth(3).strokeType(StrokeType.OUTSIDE) > .rotate(45) > .build(); > > Regards, Jiri From goddard at seznam.cz Fri Jun 22 05:08:16 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Fri, 22 Jun 2012 14:08:16 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Re=3A=20How=20does=20getProperties=28=29=20method=20work=3F?= In-Reply-To: <4FE45F1D.9030604@oracle.com> Message-ID: <130046.4713.24870-6772-19320187-1340366896@seznam.cz> I see. Is there a way how to query a Node for its set of JavaFX properties then? Thanks, Jiri ------------ P?vodn? zpr?va ------------ Od: Eva Krejcirova P?edm?t: Re: How does getProperties() method work? Datum: 22.6.2012 14:02:42 ---------------------------------------- Hi, Node.getProperties returns an ObservableMap which you then can use to store any information you want. It is similar to getUserData/setUserData which actually store the user data in the same map. It has nothing to do with JavaFX properties of a node. We should probably improve the documentation of this method, the current javadoc doesn't seem to clarify this. Eva On 6/22/2012 1:14 PM, goddard at seznam.cz wrote: > Hi, > > I wanted to query a Rectangle for its properties with getProperties() method, but it always returns empty Map (no elements, zero size). > For example, I've got a Rectangle defined like this: > > Rectangle red = RectangleBuilder.create() > .x(100).y(100) > .width(100).height(100) > .fill(Color.RED) > //.stroke(Color.BLACK).strokeWidth(3).strokeType(StrokeType.OUTSIDE) > .rotate(45) > .build(); > > Regards, Jiri From richard.bair at oracle.com Fri Jun 22 07:58:52 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 22 Jun 2012 07:58:52 -0700 Subject: How does getProperties() method work? In-Reply-To: <130046.4713.24870-6772-19320187-1340366896@seznam.cz> References: <130046.4713.24870-6772-19320187-1340366896@seznam.cz> Message-ID: <98DFDE73-B5A4-4538-9237-124301CC69FA@oracle.com> Reflection is the only way. Thanks Richard On Jun 22, 2012, at 5:08 AM, goddard at seznam.cz wrote: > I see. > Is there a way how to query a Node for its set of JavaFX properties then? > > Thanks, Jiri > > ------------ P?vodn? zpr?va ------------ > Od: Eva Krejcirova > P?edm?t: Re: How does getProperties() method work? > Datum: 22.6.2012 14:02:42 > ---------------------------------------- > Hi, > > Node.getProperties returns an ObservableMap which you then can use to > store any information you want. It is similar to > getUserData/setUserData which actually store the user data in the same map. > It has nothing to do with JavaFX properties of a node. > > We should probably improve the documentation of this method, the current > javadoc doesn't seem to clarify this. > > Eva > > On 6/22/2012 1:14 PM, goddard at seznam.cz wrote: >> Hi, >> >> I wanted to query a Rectangle for its properties with getProperties() method, > but it always returns empty Map (no elements, zero size). >> For example, I've got a Rectangle defined like this: >> >> Rectangle red = RectangleBuilder.create() >> .x(100).y(100) >> .width(100).height(100) >> .fill(Color.RED) >> > //.stroke(Color.BLACK).strokeWidth(3).strokeType(StrokeType.OUTSIDE) >> .rotate(45) >> .build(); >> >> Regards, Jiri > > > From jeff at reportmill.com Fri Jun 22 06:59:34 2012 From: jeff at reportmill.com (Jeff Martin) Date: Fri, 22 Jun 2012 08:59:34 -0500 Subject: How does getProperties() method work? In-Reply-To: <130046.4713.24870-6772-19320187-1340366896@seznam.cz> References: <130046.4713.24870-6772-19320187-1340366896@seznam.cz> Message-ID: Something like this should work: /** * Returns properties for JavaFX object. */ public List getProperties(Object anObj) { // Create list and get class methods List properties = new ArrayList(); Method methods[] = anObj.getClass().getMethods(); // Iterate over methods, if method returns property, get it for(Method method : methods) { if(Property.class.isAssignableFrom(method.getReturnType())) try { properties.add((Property)method.invoke(anObj, new Object[0])); } catch(Exception e) { System.err.println("Error: " + e); continue; } } // Return properties return properties; } jeff On Jun 22, 2012, at 7:08 AM, goddard at seznam.cz wrote: > I see. > Is there a way how to query a Node for its set of JavaFX properties then? > > Thanks, Jiri > > ------------ P?vodn? zpr?va ------------ > Od: Eva Krejcirova > P?edm?t: Re: How does getProperties() method work? > Datum: 22.6.2012 14:02:42 > ---------------------------------------- > Hi, > > Node.getProperties returns an ObservableMap which you then can use to > store any information you want. It is similar to > getUserData/setUserData which actually store the user data in the same map. > It has nothing to do with JavaFX properties of a node. > > We should probably improve the documentation of this method, the current > javadoc doesn't seem to clarify this. > > Eva > > On 6/22/2012 1:14 PM, goddard at seznam.cz wrote: >> Hi, >> >> I wanted to query a Rectangle for its properties with getProperties() method, > but it always returns empty Map (no elements, zero size). >> For example, I've got a Rectangle defined like this: >> >> Rectangle red = RectangleBuilder.create() >> .x(100).y(100) >> .width(100).height(100) >> .fill(Color.RED) >> > //.stroke(Color.BLACK).strokeWidth(3).strokeType(StrokeType.OUTSIDE) >> .rotate(45) >> .build(); >> >> Regards, Jiri > > > From greg.x.brown at oracle.com Fri Jun 22 08:43:15 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Fri, 22 Jun 2012 11:43:15 -0400 Subject: How does getProperties() method work? In-Reply-To: References: <130046.4713.24870-6772-19320187-1340366896@seznam.cz> Message-ID: com.sun.javafx.fxml.BeanAdapter can also be used for this. It exposes an object's bean properties via the Map interface. On Jun 22, 2012, at 9:59 AM, Jeff Martin wrote: > Something like this should work: > > /** > * Returns properties for JavaFX object. > */ > public List getProperties(Object anObj) > { > // Create list and get class methods > List properties = new ArrayList(); > Method methods[] = anObj.getClass().getMethods(); > > // Iterate over methods, if method returns property, get it > for(Method method : methods) { > if(Property.class.isAssignableFrom(method.getReturnType())) > try { properties.add((Property)method.invoke(anObj, new Object[0])); } > catch(Exception e) { System.err.println("Error: " + e); continue; } > } > > // Return properties > return properties; > } > > jeff > > > On Jun 22, 2012, at 7:08 AM, goddard at seznam.cz wrote: > >> I see. >> Is there a way how to query a Node for its set of JavaFX properties then? >> >> Thanks, Jiri >> >> ------------ P?vodn? zpr?va ------------ >> Od: Eva Krejcirova >> P?edm?t: Re: How does getProperties() method work? >> Datum: 22.6.2012 14:02:42 >> ---------------------------------------- >> Hi, >> >> Node.getProperties returns an ObservableMap which you then can use to >> store any information you want. It is similar to >> getUserData/setUserData which actually store the user data in the same map. >> It has nothing to do with JavaFX properties of a node. >> >> We should probably improve the documentation of this method, the current >> javadoc doesn't seem to clarify this. >> >> Eva >> >> On 6/22/2012 1:14 PM, goddard at seznam.cz wrote: >>> Hi, >>> >>> I wanted to query a Rectangle for its properties with getProperties() method, >> but it always returns empty Map (no elements, zero size). >>> For example, I've got a Rectangle defined like this: >>> >>> Rectangle red = RectangleBuilder.create() >>> .x(100).y(100) >>> .width(100).height(100) >>> .fill(Color.RED) >>> >> //.stroke(Color.BLACK).strokeWidth(3).strokeType(StrokeType.OUTSIDE) >>> .rotate(45) >>> .build(); >>> >>> Regards, Jiri >> >> >> > From hang.vo at oracle.com Fri Jun 22 13:18:49 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 22 Jun 2012 20:18:49 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22884 - ScrollPane : Corner doesn't always fill the space to the edge properly. Message-ID: <20120622201852.7C4AD47ABA@hg.openjdk.java.net> Changeset: 4a5a0e2d02e9 Author: mickf Date: 2012-06-22 21:15 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/4a5a0e2d02e9 RT-22884 - ScrollPane : Corner doesn't always fill the space to the edge properly. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java From hang.vo at oracle.com Fri Jun 22 21:25:38 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 23 Jun 2012 04:25:38 +0000 Subject: hg: openjfx/2.2/master/rt: 50 new changesets Message-ID: <20120623042623.1A77947AC5@hg.openjdk.java.net> Changeset: 8192bc3aa019 Author: Paru Somashekar Date: 2012-06-12 10:39 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/8192bc3aa019 RT-20937 missing javadoc for some MenuItem properties RT-19747 piechart is not affected by -fx-pie-label-visible RT-13081 ChartSampler demo / set new data leads to NPE. ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java ! javafx-ui-charts/src/javafx/scene/chart/ScatterChart.java ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java Changeset: 6e34b405d07e Author: Kinsley Wong Date: 2012-06-12 14:30 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/6e34b405d07e RT-22326: TabPane: unable to select the following tab when a tab is closed. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TabPaneBehavior.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java Changeset: 9d72813b0448 Author: Paru Somashekar Date: 2012-06-12 16:49 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/9d72813b0448 RT-20104 Tooltip missing textAlignment javadoc ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java Changeset: 2f475847df17 Author: Kinsley Wong Date: 2012-06-12 17:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/2f475847df17 RT-22415: Adding an item to SplitPane may hang FX ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SplitPaneSkin.java Changeset: 35c426930d23 Author: jgiles Date: 2012-06-12 20:21 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/35c426930d23 RT-21586: ListView: Replacing all items does not clear selection ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: b6f81f47c4c8 Author: jgiles Date: 2012-06-13 09:44 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/b6f81f47c4c8 RT-22428: TableColumns are appearing collapsed by default ! javafx-ui-controls/src/javafx/scene/control/TableCell.java Changeset: 541a5c63514f Author: jgiles Date: 2012-06-13 13:19 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/541a5c63514f RT-22191: TableView: Performance degrades when resetting content ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: 06a917ba0bfa Author: jgiles Date: 2012-06-13 13:43 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/06a917ba0bfa RT-22385: TableView leaks memory ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkin.java ! javafx-ui-controls/src/javafx/scene/control/TableCell.java Changeset: 8dc0f0d957e0 Author: jgiles Date: 2012-06-13 14:20 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/8dc0f0d957e0 RT-20840: fx2.2-h17-b01: Adding new column to TableView results in creating new N columns instead of 1 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java Changeset: b618eb1ac127 Author: jgiles Date: 2012-06-13 15:36 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/b618eb1ac127 RT-22391: Removing a nested TableColumn from its parent column resets the tableView property of the parent to null ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java Changeset: e6d1c213886d Author: jgiles Date: 2012-06-13 16:18 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/e6d1c213886d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: d014ba0c953c Author: Paru Somashekar Date: 2012-06-13 11:27 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/d014ba0c953c fix RT-22466 Adding, removing then adding the same MenuBar instance in the scenegraph triggers NPE. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java Changeset: 2bad47ac2ab8 Author: Kinsley Wong Date: 2012-06-13 12:12 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/2bad47ac2ab8 RT-22232: Context menu is in the wrong place for non primary monitors. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java Changeset: 1a2a50109e8e Author: Kinsley Wong Date: 2012-06-13 13:47 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/1a2a50109e8e RT-22467: Moving a Button located in an AnchorPane to a Tab content gets you NPE ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ButtonSkin.java Changeset: 14efe4fc1d6a Author: leifs Date: 2012-06-13 14:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/14efe4fc1d6a Fixed RT-22480: Add private method to set default system menu bar. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java Changeset: dc1043f1fde4 Author: leifs Date: 2012-06-13 18:45 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/dc1043f1fde4 Fixed RT-21645: On Mac OS X call to GlassViewEventHandler.getInputMethodCandidatePos() provides strange coordinates ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java Changeset: 4b5bf956320b Author: jgiles Date: 2012-06-14 11:05 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/4b5bf956320b RT-22386: ComboBox : cannot choose the same item multiple times ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/test/javafx/scene/control/ComboBoxTest.java Changeset: ebbc5b495c06 Author: jgiles Date: 2012-06-14 15:02 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/ebbc5b495c06 RT-21088: ComboBox: regression with focusedProperty ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 6f9959b35a9d Author: jgiles Date: 2012-06-14 15:28 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/6f9959b35a9d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: adcda42efa37 Author: leifs Date: 2012-06-14 00:20 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/adcda42efa37 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt Changeset: d26daf855de3 Author: Paru Somashekar Date: 2012-06-14 13:48 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/d26daf855de3 RT-22553 Adding a data item to a PieChart after removing the same item, causes NPE. ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java Changeset: 59617134868f Author: David Grieve Date: 2012-06-14 18:26 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/59617134868f RT-21906: must separate shared css calculated values from node-specific css calculated values if node has user set font. ! javafx-ui-common/src/com/sun/javafx/css/CascadingStyle.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java Changeset: 7c669f613b6c Author: David Grieve Date: 2012-06-14 18:40 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/7c669f613b6c RT-20643 (partial) Expose StyleManger getPseudoclassStrings for Scene Builder use. ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: 217cede187d0 Author: Paru Somashekar Date: 2012-06-14 16:24 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/217cede187d0 RT-22166 Axis tick labels are drawn outside chart and over top of axis name ! javafx-ui-charts/test/javafx/scene/chart/ChartTestBase.java ! javafx-ui-charts/test/javafx/scene/chart/StackedAreaChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/StackedBarChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/XYChartTest.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/javafx/scene/chart/Axis.java ! javafx-ui-controls/src/javafx/scene/chart/ValueAxis.java Changeset: adb8d50d8799 Author: jgiles Date: 2012-06-15 13:48 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/adb8d50d8799 RT-20938: javafx.scene.control.Tab: field visible via public API should not be of non-public type ! javafx-ui-controls/src/javafx/scene/control/Tab.java Changeset: 0dc775249a62 Author: jgiles Date: 2012-06-15 14:13 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/0dc775249a62 RT-20582: MenuItem's styleable has a null Node ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java Changeset: 0f2fba17c263 Author: jgiles Date: 2012-06-15 14:37 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/0f2fba17c263 RT-21472: impl_getStyleable is needed on TableColumn ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableHeaderRow.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkin.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java Changeset: 49d2f59fb14e Author: jgiles Date: 2012-06-15 15:05 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/49d2f59fb14e Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 109bddc14dde Author: jgiles Date: 2012-06-15 17:05 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/109bddc14dde Fix build failure in MenuItem. ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java Changeset: ba93ff7e1f24 Author: Kinsley Wong Date: 2012-06-15 13:58 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/ba93ff7e1f24 RT-21745: Bad strange layout in VBox caused by Label.setWrapText(true). ! javafx-ui-common/src/javafx/scene/layout/AnchorPane.java ! javafx-ui-common/test/unit/javafx/scene/layout/AnchorPaneTest.java Changeset: acd0852a0a8e Author: mickf Date: 2012-06-16 14:42 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/acd0852a0a8e RT-21251 : [ListView] some space appeared between scrollbar and listview content. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 1e240f8f9fc5 Author: leifs Date: 2012-06-18 08:26 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/1e240f8f9fc5 [mq]: rt22054 ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java Changeset: 38a9585cb2db Author: leifs Date: 2012-06-18 08:50 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/38a9585cb2db Fixed RT-22644: [TextArea] Typing Tab or Enter breaks Undo chain ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java Changeset: 104dff9f4ebc Author: Kinsley Wong Date: 2012-06-18 12:49 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/104dff9f4ebc Rollback fix for RT-21906: must separate shared css calculated values from node-specific css calculated values if node has user set font. ! javafx-ui-common/src/com/sun/javafx/css/CascadingStyle.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java Changeset: 6144c0bee0f9 Author: Kinsley Wong Date: 2012-06-18 13:12 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/6144c0bee0f9 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt Changeset: bdbc42e5a633 Author: Kinsley Wong Date: 2012-06-18 16:54 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/bdbc42e5a633 Ignore broken charts units tests. ! javafx-ui-charts/test/javafx/scene/chart/StackedAreaChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/StackedBarChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/XYChartTest.java Changeset: 348163a34ede Author: Martin Sladecek Date: 2012-06-13 14:36 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/348163a34ede @treatAsPrivate cleanup. Reviewed by Pavel. - javafx-ui-common/src/com/sun/javafx/stage/PopupEventRedirector.java ! javafx-ui-common/src/javafx/scene/Camera.java ! javafx-ui-common/src/javafx/scene/Cursor.java ! javafx-ui-common/src/javafx/scene/Group.java ! javafx-ui-common/src/javafx/scene/ImageCursor.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/ParallelCamera.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/PerspectiveCamera.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java ! javafx-ui-common/src/javafx/scene/layout/ConstraintsBase.java ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/src/javafx/scene/layout/Region.java ! javafx-ui-common/src/javafx/stage/PopupWindow.java ! javafx-ui-common/src/javafx/stage/Window.java ! javafx-ui-common/test/unit/javafx/scene/ImageCursor_getCurrentFrame_Test.java ! javafx-ui-common/test/unit/javafx/scene/MouseTest.java ! javafx-ui-common/test/unit/javafx/scene/Scene_properties_Test.java ! javafx-ui-common/test/unit/javafx/scene/StructureTest.java Changeset: 0e0923db2a7c Author: Martin Sladecek Date: 2012-06-13 14:36 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/0e0923db2a7c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/graphics/jfx/rt - javafx-ui-common/src/com/sun/javafx/stage/PopupEventRedirector.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/test/unit/javafx/scene/MouseTest.java Changeset: 2e470003ed13 Author: Yao Wang Date: 2012-06-14 17:36 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/2e470003ed13 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt - javafx-ui-common/src/com/sun/javafx/stage/PopupEventRedirector.java Changeset: f7c21c251366 Author: "Joseph Andresen" Date: 2012-06-15 10:02 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/f7c21c251366 RT-22548 javadoc update for imagepattern ! javafx-ui-common/src/javafx/scene/paint/ImagePattern.java Changeset: 9dc8b64682f6 Author: Pavel Safrata Date: 2012-06-14 15:39 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/9dc8b64682f6 RT-21746: scenegraph subtrees can be added during layout. ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/javafx/scene/ParentTest.java Changeset: 3525ca3b1439 Author: Pavel Safrata Date: 2012-06-18 10:30 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/3525ca3b1439 RT-21746: scenegraph subtrees can be added during layout (merge). ! javafx-ui-common/src/javafx/scene/Node.java Changeset: a86b9a28478c Author: Pavel Safrata Date: 2012-06-18 16:06 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/a86b9a28478c RT-22636: Fixed coordinates of keyboard-triggered ContextMenuEvent. RT-20936: Documented coordinates of ContextMenuEvent. ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java + javafx-ui-common/test/unit/javafx/scene/input/ContextMenuEventTest.java Changeset: c9fe13cb7935 Author: Pavel Safrata Date: 2012-06-18 16:15 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/c9fe13cb7935 RT-22636 part 2: handled scene without focus owner. ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: bc5b8880d1db Author: flar Date: 2012-06-18 13:57 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/bc5b8880d1db Fix RT-22129: PixelReader/Writer javadoc refer to nonexistant pixel format. ! javafx-ui-common/src/javafx/scene/image/PixelFormat.java ! javafx-ui-common/src/javafx/scene/image/PixelReader.java ! javafx-ui-common/src/javafx/scene/image/PixelWriter.java Changeset: af08c7baa21a Author: Morris Meyer Date: 2012-06-19 09:51 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/af08c7baa21a RT-16812 - close QuantumClipboard security vulnerability reading images from untrusted applets ! javafx-ui-common/src/com/sun/javafx/tk/TKClipboard.java ! javafx-ui-common/src/javafx/scene/input/Clipboard.java Changeset: 1afaf1867c5d Author: Morris Meyer Date: 2012-06-19 10:10 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/1afaf1867c5d RT-16812 - add initSecurityContext to StubTookit ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: 0af7b6ab244f Author: Morris Meyer Date: 2012-06-19 10:35 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/0af7b6ab244f RT-16812 - add initSecurityContext to DragAndDropTest ! javafx-ui-common/test/unit/javafx/scene/input/DragAndDropTest.java Changeset: f026710b45cb Author: Yao Wang Date: 2012-06-19 10:12 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/f026710b45cb Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt - javafx-ui-common/src/com/sun/javafx/stage/PopupEventRedirector.java ! javafx-ui-common/src/javafx/scene/Node.java Changeset: 00bc2ee17e47 Author: hudson Date: 2012-06-22 21:21 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/00bc2ee17e47 Added tag 2.2-b14 for changeset f026710b45cb ! .hgtags From goddard at seznam.cz Sat Jun 23 02:12:20 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Sat, 23 Jun 2012 11:12:20 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Re=3A=20How=20does=20getProperties=28=29=20method=20work=3F?= In-Reply-To: Message-ID: <130084.4557.24772-22585-951954502-1340442740@seznam.cz> Thanks for the replies, I'll get into it. Regards, Jiri ------------ P?vodn? zpr?va ------------ Od: Jeff Martin P?edm?t: Re: How does getProperties() method work? Datum: 22.6.2012 18:04:39 ---------------------------------------- Something like this should work: /** * Returns properties for JavaFX object. */ public List getProperties(Object anObj) { // Create list and get class methods List properties = new ArrayList(); Method methods[] = anObj.getClass().getMethods(); // Iterate over methods, if method returns property, get it for(Method method : methods) { if(Property.class.isAssignableFrom(method.getReturnType())) try { properties.add((Property)method.invoke(anObj, new Object[0])); } catch(Exception e) { System.err.println("Error: " + e); continue; } } // Return properties return properties; } jeff On Jun 22, 2012, at 7:08 AM, goddard at seznam.cz wrote: > I see. > Is there a way how to query a Node for its set of JavaFX properties then? > > Thanks, Jiri > > ------------ P?vodn? zpr?va ------------ > Od: Eva Krejcirova > P?edm?t: Re: How does getProperties() method work? > Datum: 22.6.2012 14:02:42 > ---------------------------------------- > Hi, > > Node.getProperties returns an ObservableMap which you then can use to > store any information you want. It is similar to > getUserData/setUserData which actually store the user data in the same map. > It has nothing to do with JavaFX properties of a node. > > We should probably improve the documentation of this method, the current > javadoc doesn't seem to clarify this. > > Eva > > On 6/22/2012 1:14 PM, goddard at seznam.cz wrote: >> Hi, >> >> I wanted to query a Rectangle for its properties with getProperties() method, > but it always returns empty Map (no elements, zero size). >> For example, I've got a Rectangle defined like this: >> >> Rectangle red = RectangleBuilder.create() >> .x(100).y(100) >> .width(100).height(100) >> .fill(Color.RED) >> > //.stroke(Color.BLACK).strokeWidth(3).strokeType(StrokeType.OUTSIDE) >> .rotate(45) >> .build(); >> >> Regards, Jiri > > > From hang.vo at oracle.com Sat Jun 23 20:03:37 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sun, 24 Jun 2012 03:03:37 +0000 Subject: hg: openjfx/2.2/graphics/rt: Fix RT-22885: PixelFormat.get/setArgb() methods have errors. Message-ID: <20120624030341.B482047AD9@hg.openjdk.java.net> Changeset: ab81c2cf3cca Author: flar Date: 2012-06-23 19:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/ab81c2cf3cca Fix RT-22885: PixelFormat.get/setArgb() methods have errors. ! javafx-ui-common/src/javafx/scene/image/PixelFormat.java ! javafx-ui-common/src/javafx/scene/image/WritablePixelFormat.java + javafx-ui-common/test/unit/javafx/scene/image/PixelFormatTest.java From hang.vo at oracle.com Sun Jun 24 11:03:46 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sun, 24 Jun 2012 18:03:46 +0000 Subject: hg: openjfx/2.2/controls/rt: 3 new changesets Message-ID: <20120624180354.06B6A47AE0@hg.openjdk.java.net> Changeset: 19ed1479a504 Author: Paru Somashekar Date: 2012-06-24 10:15 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/19ed1479a504 fix RT-21530 new color of web and that of gradient rectangle color does not always correspond. HG: changed javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java Changeset: 8334e452ecf5 Author: Paru Somashekar Date: 2012-06-24 10:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/8334e452ecf5 fix RT-21556 color picker can be broken by typing big numbers in integer field. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/IntegerField.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/IntegerFieldSkin.java Changeset: 918bee86c2d3 Author: Paru Somashekar Date: 2012-06-24 10:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/918bee86c2d3 RT-21112 web color field accept different symbols. Entering the # at the beginging of web color string is now optional. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/WebColorFieldSkin.java From hang.vo at oracle.com Sun Jun 24 14:48:33 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sun, 24 Jun 2012 21:48:33 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22721 : Progress indicator circle position moved in 2.2 Message-ID: <20120624214838.D2DD447AE3@hg.openjdk.java.net> Changeset: 3f5d7303f073 Author: mickf Date: 2012-06-24 22:40 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/3f5d7303f073 RT-22721 : Progress indicator circle position moved in 2.2 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java From jonathan.giles at oracle.com Sun Jun 24 19:37:18 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 25 Jun 2012 14:37:18 +1200 Subject: Defaulting a comboBox's buttonCell to the cellFactory In-Reply-To: <4FC93503.7010209@oracle.com> References: <4FC93503.7010209@oracle.com> Message-ID: <4FE7CEDE.6080707@oracle.com> Due to a lot of high-priority work that came in recently, I've just returned to this topic now. The issue that I see with taking option A is that the logic in the code would go something like this: buttonCell = comboBox.getButtonCell() != null ? comboBox.getButtonCell() : comboBox.getCellFactory() != null ? comboBox.getCellFactory().call(listView) : getDefaultCellFactory().call(listView); With option A, when the user wants to have the button area use the cell factory, the buttonCell will be null, and the cell factory will be non-null. This is fine - the display will be populated with a node from the cell factory. However, if the user wants the button area to be the default look, and they have a cell factory, they presently have no way of specifying that they do not want to use the cell factory. Conversely, with the current approach, if a user wants a custom buttonCell - they set it in ComboBox.buttonCell. If they want a custom cell factory for the popup ListView, they set ComboBox.cellFactory. If they want both, they set both (and create a cell from the cell factory to set in the buttonCell, if they want the same look in both places). Given how close we are cutting it to high resistance development (tomorrow for my team), I am not about to make any major changes to restructure this. I am at peace with the current design, and plan to leave things as-is. Urs, I'm sorry I could not meet your desired approach. -- Jonathan On 2/06/2012 9:32 a.m., Jonathan Giles wrote: > So, in summary, Urs and I would appreciate votes on option A or option B: > > Option A: the ComboBox buttonCell by default uses a cell from the > provided cell factory. > > Option B: The ComboBox buttonCell DOES NOT use a cell from the > provided cell factory, and instead requires the user to manually > create a cell and set it in the buttonCell property. > > Option A is consistent with the approach used in JavaFX 2.1, whereas > Option B is the current approach used in JavaFX 2.2. > > The answer to this question largely comes down to the more common use > case when using the cell factory: do we expect users to want to use > the same cell in the button and the list, or do we expect them to want > to have different cells (and perhaps the default cell in the button > area). > > I'm totally not against changing this, so I welcome your votes on this > matter. > > -- Jonathan > > > On 1/06/2012 5:39 p.m., Urs Reupke wrote: >> Hi all, >> back in April, Jonathan proposed a change to comboBoxes that allowed >> to separate the button's rendering from the list's rendering.[1] >> >> In the JIRA issue accompanying that discussion [2], he also mentioned >> ways to render the button when the new buttonCell property is not set: >> "If this is not set, there are two options: >> 1) Use a cell from the ComboBox.cellFactory >> 2) Not style the button at all, and use a default cell from the skin" >> >> Now, in FX2.2b10, the buttonCell is rendered as toString if the >> property is not set. >> I believe that his option 1) would be a great improvement to the >> behaviour, and Jonathan asked me to make that proposal public. >> My reasoning is that those who need the buttonCell to be rendered >> differently can do it, whereas those whose buttons and listcells look >> alike don't need to think about it. From my experience, the latter >> should be the majority. >> >> I appreciate your feedback on the matter. >> >> Thank you >> -Urs >> >> [1] >> http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-April/001209.html >> [2] http://javafx-jira.kenai.com/browse/RT-21023 From hang.vo at oracle.com Sun Jun 24 23:18:50 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 25 Jun 2012 06:18:50 +0000 Subject: hg: openjfx/2.2/controls/rt: 5 new changesets Message-ID: <20120625061858.011F647AE8@hg.openjdk.java.net> Changeset: 96d95ad7e603 Author: jgiles Date: 2012-06-25 14:06 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/96d95ad7e603 RT-22668: HelloListView hangs ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: 00b1f42f76da Author: jgiles Date: 2012-06-25 14:07 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/00b1f42f76da [DOC ONLY] Clarifying purpose of promptText property in ComboBoxBase. ! javafx-ui-controls/src/javafx/scene/control/ComboBoxBase.java Changeset: a7050a4850da Author: jgiles Date: 2012-06-25 14:12 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/a7050a4850da RT-22900: Cell selected property fires too frequently when selection changes ! javafx-ui-controls/src/javafx/scene/control/Cell.java ! javafx-ui-controls/src/javafx/scene/control/ListCell.java ! javafx-ui-controls/src/javafx/scene/control/TableCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeCell.java Changeset: 561c62db83f9 Author: jgiles Date: 2012-06-25 18:05 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/561c62db83f9 RT-22677: ComboBox : items list has a wrong width at first display ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxBaseSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java Changeset: 3ef6b29199f2 Author: jgiles Date: 2012-06-25 18:06 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/3ef6b29199f2 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt From alexandre.iline at oracle.com Mon Jun 25 07:34:36 2012 From: alexandre.iline at oracle.com (alexandre.iline at oracle.com) Date: Mon, 25 Jun 2012 14:34:36 +0000 Subject: hg: openjfx/2.2/master/tests: 5 new changesets Message-ID: <20120625143437.6293C47AF6@hg.openjdk.java.net> Changeset: 43e2bec19fcc Author: Alexandre (Shura) Iline Date: 2012-06-25 16:14 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/43e2bec19fcc Auto show scene ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/SceneWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/TextWrap.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TreeApp.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/TreeTest.java Changeset: 7dd8841dfe7c Author: Oleg Barbashov Date: 2012-06-21 20:22 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/7dd8841dfe7c JemmyFX: TableCellWrap minor fix ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TableCellItemWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/KnobTrackScrollerImpl.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/ScrollBarScroller.java Changeset: 10de7a207c51 Author: Oleg Barbashov Date: 2012-06-21 22:22 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/10de7a207c51 JemmyFX: TableCellWrap minor fix ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TableCellItemWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/KnobTrackScrollerImpl.java Changeset: 548e2027fcf8 Author: Alexandre (Shura) Iline Date: 2012-06-25 16:39 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/548e2027fcf8 merge Changeset: 8310175a35ce Author: Oleg Barbashov Date: 2012-06-25 17:24 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/8310175a35ce JemmyFX: ListItemWrap minor fix ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ListItemWrap.java From hang.vo at oracle.com Mon Jun 25 08:18:41 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 25 Jun 2012 15:18:41 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22565: follow on patch to resolve IllegalStateException when running HelloHTMLEditor Message-ID: <20120625151844.3E81C47AF7@hg.openjdk.java.net> Changeset: ba0ed1315785 Author: David Grieve Date: 2012-06-25 10:22 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/ba0ed1315785 RT-22565: follow on patch to resolve IllegalStateException when running HelloHTMLEditor ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java From pedro.duquevieira at gmail.com Mon Jun 25 11:40:43 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 25 Jun 2012 19:40:43 +0100 Subject: Reporting javafx bugs while working on commercial app Message-ID: Hi, I have a problem reporting javafx bugs, the problem is I'm working on a commercial app so I can't post the code out to the public on Jira. Is there a way for me to post my code to the javafx team and be certain it will remain private and won't be re-used by anyone? Recently I posted a bug on jira but the small code snipped I posted didn't seem to trigger the bug. I suggested to the javafx developer that I could send him the jar file and he could remote debug the app, I also asked what else could I do, but after that I got no answer back and the bug was simply closed. The point is, is there some other way/procedure to report a bug when dealing with commercial apps? Thanks, best regards, -- Pedro Duque Vieira From christian.schudt at gmx.de Mon Jun 25 12:09:36 2012 From: christian.schudt at gmx.de (Christian Schudt) Date: Mon, 25 Jun 2012 21:09:36 +0200 Subject: Reporting javafx bugs while working on commercial app In-Reply-To: References: Message-ID: <0FFB97C9-3C22-4953-B141-44CB14159D6F@gmx.de> Hi all, I always try to minimize the code I post in Jira and bring the bug down to a simple test program, if only for the easy processing for the JavaFX developer. I never had a problem doing so and I posted like >30 bugs already. And if I were a JavaFX developer, I'd rather deal with a simple test case than with a large jar? Maybe your code snippet has already been fixed, if it didn't trigger the bug. Have you tried the newest beta build? Regards, Christian Am 25.06.2012 um 20:40 schrieb Pedro Duque Vieira: > Hi, > > I have a problem reporting javafx bugs, the problem is I'm working on a > commercial app so I can't post the code out to the public on Jira. Is there > a way for me to post my code to the javafx team and be certain it will > remain private and won't be re-used by anyone? > > Recently I posted a bug on jira but the small code snipped I posted didn't > seem to trigger the bug. I suggested to the javafx developer that I could > send him the jar file and he could remote debug the app, I also asked what > else could I do, but after that I got no answer back and the bug was simply > closed. The point is, is there some other way/procedure to report a bug > when dealing with commercial apps? > > Thanks, best regards, > > -- > Pedro Duque Vieira From hang.vo at oracle.com Mon Jun 25 12:33:48 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 25 Jun 2012 19:33:48 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22638: for calculating css values, only use a node font property if it was set by the user and there is not an inline or author style Message-ID: <20120625193350.8A30647B01@hg.openjdk.java.net> Changeset: 83d4d7d610c4 Author: David Grieve Date: 2012-06-25 15:22 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/83d4d7d610c4 RT-22638: for calculating css values, only use a node font property if it was set by the user and there is not an inline or author style ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java From hjohn at xs4all.nl Mon Jun 25 12:43:52 2012 From: hjohn at xs4all.nl (John Hendrikx) Date: Mon, 25 Jun 2012 21:43:52 +0200 Subject: Reporting javafx bugs while working on commercial app In-Reply-To: References: Message-ID: <4FE8BF78.8080105@xs4all.nl> I think you expect too much. Reduce your bug to a simple test program like everybody else is doing, and post that. This saves time for the JFX developers which they'll need to actually get bugs fixed. Remote debugging some big commercial app should be a last resort -- chances are it is not even a JFX bug. On 25/06/2012 20:40, Pedro Duque Vieira wrote: > Hi, > > I have a problem reporting javafx bugs, the problem is I'm working on a > commercial app so I can't post the code out to the public on Jira. Is there > a way for me to post my code to the javafx team and be certain it will > remain private and won't be re-used by anyone? > > Recently I posted a bug on jira but the small code snipped I posted didn't > seem to trigger the bug. I suggested to the javafx developer that I could > send him the jar file and he could remote debug the app, I also asked what > else could I do, but after that I got no answer back and the bug was simply > closed. The point is, is there some other way/procedure to report a bug > when dealing with commercial apps? > > Thanks, best regards, > From hang.vo at oracle.com Mon Jun 25 13:20:11 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 25 Jun 2012 20:20:11 +0000 Subject: hg: openjfx/2.2/controls/rt: 15 new changesets Message-ID: <20120625202023.C2F3A47B05@hg.openjdk.java.net> Changeset: 348163a34ede Author: Martin Sladecek Date: 2012-06-13 14:36 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/348163a34ede @treatAsPrivate cleanup. Reviewed by Pavel. - javafx-ui-common/src/com/sun/javafx/stage/PopupEventRedirector.java ! javafx-ui-common/src/javafx/scene/Camera.java ! javafx-ui-common/src/javafx/scene/Cursor.java ! javafx-ui-common/src/javafx/scene/Group.java ! javafx-ui-common/src/javafx/scene/ImageCursor.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/ParallelCamera.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/PerspectiveCamera.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java ! javafx-ui-common/src/javafx/scene/layout/ConstraintsBase.java ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/src/javafx/scene/layout/Region.java ! javafx-ui-common/src/javafx/stage/PopupWindow.java ! javafx-ui-common/src/javafx/stage/Window.java ! javafx-ui-common/test/unit/javafx/scene/ImageCursor_getCurrentFrame_Test.java ! javafx-ui-common/test/unit/javafx/scene/MouseTest.java ! javafx-ui-common/test/unit/javafx/scene/Scene_properties_Test.java ! javafx-ui-common/test/unit/javafx/scene/StructureTest.java Changeset: 0e0923db2a7c Author: Martin Sladecek Date: 2012-06-13 14:36 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/0e0923db2a7c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/graphics/jfx/rt - javafx-ui-common/src/com/sun/javafx/stage/PopupEventRedirector.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/test/unit/javafx/scene/MouseTest.java Changeset: 2e470003ed13 Author: Yao Wang Date: 2012-06-14 17:36 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/2e470003ed13 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt - javafx-ui-common/src/com/sun/javafx/stage/PopupEventRedirector.java Changeset: f7c21c251366 Author: "Joseph Andresen" Date: 2012-06-15 10:02 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/f7c21c251366 RT-22548 javadoc update for imagepattern ! javafx-ui-common/src/javafx/scene/paint/ImagePattern.java Changeset: 9dc8b64682f6 Author: Pavel Safrata Date: 2012-06-14 15:39 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/9dc8b64682f6 RT-21746: scenegraph subtrees can be added during layout. ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/javafx/scene/ParentTest.java Changeset: 3525ca3b1439 Author: Pavel Safrata Date: 2012-06-18 10:30 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/3525ca3b1439 RT-21746: scenegraph subtrees can be added during layout (merge). ! javafx-ui-common/src/javafx/scene/Node.java Changeset: a86b9a28478c Author: Pavel Safrata Date: 2012-06-18 16:06 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/a86b9a28478c RT-22636: Fixed coordinates of keyboard-triggered ContextMenuEvent. RT-20936: Documented coordinates of ContextMenuEvent. ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java + javafx-ui-common/test/unit/javafx/scene/input/ContextMenuEventTest.java Changeset: c9fe13cb7935 Author: Pavel Safrata Date: 2012-06-18 16:15 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/c9fe13cb7935 RT-22636 part 2: handled scene without focus owner. ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: bc5b8880d1db Author: flar Date: 2012-06-18 13:57 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/bc5b8880d1db Fix RT-22129: PixelReader/Writer javadoc refer to nonexistant pixel format. ! javafx-ui-common/src/javafx/scene/image/PixelFormat.java ! javafx-ui-common/src/javafx/scene/image/PixelReader.java ! javafx-ui-common/src/javafx/scene/image/PixelWriter.java Changeset: af08c7baa21a Author: Morris Meyer Date: 2012-06-19 09:51 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/af08c7baa21a RT-16812 - close QuantumClipboard security vulnerability reading images from untrusted applets ! javafx-ui-common/src/com/sun/javafx/tk/TKClipboard.java ! javafx-ui-common/src/javafx/scene/input/Clipboard.java Changeset: 1afaf1867c5d Author: Morris Meyer Date: 2012-06-19 10:10 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/1afaf1867c5d RT-16812 - add initSecurityContext to StubTookit ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: 0af7b6ab244f Author: Morris Meyer Date: 2012-06-19 10:35 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/0af7b6ab244f RT-16812 - add initSecurityContext to DragAndDropTest ! javafx-ui-common/test/unit/javafx/scene/input/DragAndDropTest.java Changeset: f026710b45cb Author: Yao Wang Date: 2012-06-19 10:12 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/f026710b45cb Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt - javafx-ui-common/src/com/sun/javafx/stage/PopupEventRedirector.java ! javafx-ui-common/src/javafx/scene/Node.java Changeset: 00bc2ee17e47 Author: hudson Date: 2012-06-22 21:21 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/00bc2ee17e47 Added tag 2.2-b14 for changeset f026710b45cb ! .hgtags Changeset: 5b984ca53761 Author: Kinsley Wong Date: 2012-06-25 13:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/5b984ca53761 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java From steve.x.northover at oracle.com Mon Jun 25 14:15:13 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Mon, 25 Jun 2012 17:15:13 -0400 Subject: Reporting javafx bugs while working on commercial app In-Reply-To: <4FE8BF78.8080105@xs4all.nl> References: <4FE8BF78.8080105@xs4all.nl> Message-ID: <4FE8D4E1.4010707@oracle.com> This is common practice. A simpler case will often find the bug for you when it happen to be in your code. Steve On 25/06/2012 3:43 PM, John Hendrikx wrote: > I think you expect too much. Reduce your bug to a simple test program > like everybody else is doing, and post that. This saves time for the > JFX developers which they'll need to actually get bugs fixed. Remote > debugging some big commercial app should be a last resort -- chances > are it is not even a JFX bug. > > On 25/06/2012 20:40, Pedro Duque Vieira wrote: >> Hi, >> >> I have a problem reporting javafx bugs, the problem is I'm working on a >> commercial app so I can't post the code out to the public on Jira. Is >> there >> a way for me to post my code to the javafx team and be certain it will >> remain private and won't be re-used by anyone? >> >> Recently I posted a bug on jira but the small code snipped I posted >> didn't >> seem to trigger the bug. I suggested to the javafx developer that I >> could >> send him the jar file and he could remote debug the app, I also asked >> what >> else could I do, but after that I got no answer back and the bug was >> simply >> closed. The point is, is there some other way/procedure to report a bug >> when dealing with commercial apps? >> >> Thanks, best regards, >> > From lubomir.nerad at oracle.com Tue Jun 26 08:18:08 2012 From: lubomir.nerad at oracle.com (Lubomir Nerad) Date: Tue, 26 Jun 2012 17:18:08 +0200 Subject: Image loading error reporting / handling Message-ID: <4FE9D2B0.90609@oracle.com> Hi all, I have two feature requests which ask for better error reporting / handling of image loading. The issues are: Make Image class support exceptions for both asynchronous and synchronous loading (http://javafx-jira.kenai.com/browse/RT-17645) Image/Media need consistent error reporting (http://javafx-jira.kenai.com/browse/RT-976) Currently my idea of fixing them is through a new ImageLoader class. This class will have two sets of instance methods for image loading: Image load(...) - Used for foreground image loading. The difference between them and the Image constructors would be that by default (!) they will throw an exception if image loading fails [RT-17645] (instead of returning an Image with error set to true). Image loadAsync(...) - Used for background image loading. Will throw only when input arguments are null or invalid. Then there will be methods for registering image loading event handlers [RT-976]. I can think of the following basic set of events: loading started (setOnLoadingStarted) loading progress (setOnLoadingProgress) loading finished loading succeeded (setOnLoadingSucceeded) loading failed (setOnLoadingFailed) They will use a new ImageLoadingEvent and possibly ImageLoadingFailedEvent (with an added exception field). The ImageLoadingEvent will report the image for which the event has been generated (null for foreground images?). Image loading errors will be reported as runtime (!) ImageLoadingException-s. ImageLoader instances will be created through constructor(s) with possibility to pass some configuration parameters (for example the maximum number of images being loaded at the same time). For "logging only" image loaders we might want to allow to configure (constructor parameter? loadingFailedEvent.consume()?) whether the load methods will throw ImageLoadingException or merely create Images with error flags set (as is the case of Image constructors). This is just a basic outline of my proposal. We can focus on details when/if this approach is accepted. Alternatively the issues could be fixed by additional properties / methods on Image class. I didn't like it, because the added properties would be useful only during short period of the whole image lifetime and absolutely unusable for some images (images created from scratch). I also think that the ImageLoader approach makes uniform error handling of image loading easier (one handler for several images instead of one handler per image). What is your preference / opinion about this? Thanks, Lubo From steve.x.northover at oracle.com Tue Jun 26 09:03:09 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Tue, 26 Jun 2012 12:03:09 -0400 Subject: Image loading error reporting / handling In-Reply-To: <4FE9D2B0.90609@oracle.com> References: <4FE9D2B0.90609@oracle.com> Message-ID: <4FE9DD3D.9070508@oracle.com> Very quickly I like the idea of an ImageLoader rather than adding new methods to Image. The methods on Image that load now should be reimplemented to use the new class when it becomes available (but that will be a hidden implementation detail). Steve On 26/06/2012 11:18 AM, Lubomir Nerad wrote: > Hi all, > > I have two feature requests which ask for better error reporting / > handling of image loading. > > The issues are: > > Make Image class support exceptions for both asynchronous and > synchronous loading > (http://javafx-jira.kenai.com/browse/RT-17645) > Image/Media need consistent error reporting > (http://javafx-jira.kenai.com/browse/RT-976) > > Currently my idea of fixing them is through a new ImageLoader class. > > This class will have two sets of instance methods for image loading: > > Image load(...) - Used for foreground image loading. The difference > between them and the Image constructors would be that by default (!) > they will throw an exception if image loading fails [RT-17645] > (instead of returning an Image with error set to true). > > Image loadAsync(...) - Used for background image loading. Will throw > only when input arguments are null or invalid. > > Then there will be methods for registering image loading event > handlers [RT-976]. I can think of the following basic set of events: > > loading started (setOnLoadingStarted) > loading progress (setOnLoadingProgress) > loading finished > loading succeeded (setOnLoadingSucceeded) > loading failed (setOnLoadingFailed) > > They will use a new ImageLoadingEvent and possibly > ImageLoadingFailedEvent (with an added exception field). The > ImageLoadingEvent will report the image for which the event has been > generated (null for foreground images?). > > Image loading errors will be reported as runtime (!) > ImageLoadingException-s. > > ImageLoader instances will be created through constructor(s) with > possibility to pass some configuration parameters (for example the > maximum number of images being loaded at the same time). > > For "logging only" image loaders we might want to allow to configure > (constructor parameter? loadingFailedEvent.consume()?) whether the > load methods will throw ImageLoadingException or merely create Images > with error flags set (as is the case of Image constructors). > > This is just a basic outline of my proposal. We can focus on details > when/if this approach is accepted. Alternatively the issues could be > fixed by additional properties / methods on Image class. I didn't like > it, because the added properties would be useful only during short > period of the whole image lifetime and absolutely unusable for some > images (images created from scratch). I also think that the > ImageLoader approach makes uniform error handling of image loading > easier (one handler for several images instead of one handler per image). > > What is your preference / opinion about this? > > Thanks, > Lubo > From David.Hill at Oracle.com Tue Jun 26 09:07:58 2012 From: David.Hill at Oracle.com (David Hill) Date: Tue, 26 Jun 2012 12:07:58 -0400 Subject: Image loading error reporting / handling In-Reply-To: <4FE9D2B0.90609@oracle.com> References: <4FE9D2B0.90609@oracle.com> Message-ID: <4FE9DE5E.3080807@Oracle.com> Lubo, > Image/Media need consistent error reporting > (http://javafx-jira.kenai.com/browse/RT-976) Wow, I remember filing that one in 2008 ! :-) While I understand the attraction of an exception being thrown, I think it is reasonable just to set an error indicator as well. When I filed the jira in '08, I could know that a image load failed but not why, and the why is often the important bit. Was it memory, broken image, no connection to host ..... At the time I was thinking we could just enumerate the known causes. Hanging an exception off of the image class would have some memory issues if the user does not discard the object. Be careful how you define setOnLoadingProgress - I have seen cases with JavaIIO where we spent more time updating on progress on a small image than decoding. Imagine on a small gif image updating progress every 10% for a 64x64. Dave > > > -- David Hill Java Embedded Development America's greatest strength, and its greatest weakness, is our belief in second chances, our belief that we can always start over, that things can be made better. -- Anthony Walton From hang.vo at oracle.com Tue Jun 26 09:33:39 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 26 Jun 2012 16:33:39 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22565: parent stylesheets may be in the default stylesheet container Message-ID: <20120626163341.B88E847B26@hg.openjdk.java.net> Changeset: 9a2b4524a317 Author: David Grieve Date: 2012-06-26 12:20 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/9a2b4524a317 RT-22565: parent stylesheets may be in the default stylesheet container ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java From hang.vo at oracle.com Tue Jun 26 10:19:31 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 26 Jun 2012 17:19:31 +0000 Subject: hg: openjfx/2.2/graphics/rt: 34 new changesets Message-ID: <20120626172003.BF04847B2B@hg.openjdk.java.net> Changeset: 00bc2ee17e47 Author: hudson Date: 2012-06-22 21:21 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/00bc2ee17e47 Added tag 2.2-b14 for changeset f026710b45cb ! .hgtags Changeset: 55cb5954521b Author: Kinsley Wong Date: 2012-06-18 17:26 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/55cb5954521b Reapply fix for RT-21906 so we can further debug this issue. ! javafx-ui-common/src/com/sun/javafx/css/CascadingStyle.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java Changeset: d5d7c3a4b94d Author: jgiles Date: 2012-06-19 11:02 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/d5d7c3a4b94d RT-22645: ClassCastException (Controls Regression) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 4849a03007c5 Author: jgiles Date: 2012-06-19 13:24 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/4849a03007c5 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 2522280029a7 Author: mickf Date: 2012-06-19 16:58 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/2522280029a7 RT-22653 : ScrollBar with -fx-border styles is drawn wrong in 2.2 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java Changeset: 1de4b14f0aa9 Author: mickf Date: 2012-06-19 17:00 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/1de4b14f0aa9 RT-22652 : ScrollBar -fx-background-color behavior changed in 2.2 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: 123426be1adf Author: Kinsley Wong Date: 2012-06-19 10:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/123426be1adf RT-22455: Clip doesn't work. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/Utils.java Changeset: 238594fe9cab Author: Kinsley Wong Date: 2012-06-19 12:13 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/238594fe9cab RT-22687: Pagination Before click next - "ArithmeticException / by zero" for small size pane. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/test/javafx/scene/control/PaginationTest.java Changeset: f12ab84e2a1e Author: jgiles Date: 2012-06-20 14:19 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/f12ab84e2a1e RT-22565: Once set, setting stylesheets on a Parent has no effect. Patch supplied by David Grieve. ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Parent.java Changeset: 9cd4f06a4d7c Author: jgiles Date: 2012-06-20 14:20 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/9cd4f06a4d7c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 40920694bc2a Author: mickf Date: 2012-06-20 17:23 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/40920694bc2a RT-22653 : ScrollBar with -fx-border styles is drawn wrong in 2.2 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java Changeset: bd662b49adec Author: mickf Date: 2012-06-20 18:57 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/bd662b49adec RT-22650 : ListView hides -fx-border in 2.2 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 88f62d205d2a Author: Kinsley Wong Date: 2012-06-20 14:18 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/88f62d205d2a RT-22717: TabPane does not update its selection model after removing the selected Tab. ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java Changeset: 1aa7c6fcca3e Author: jgiles Date: 2012-06-20 16:39 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/1aa7c6fcca3e RT-22630: ComboBox : exception when promptText is set ! javafx-ui-controls/src/javafx/scene/control/ComboBox.java Changeset: afda3a34df03 Author: jgiles Date: 2012-06-21 06:06 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/afda3a34df03 RT-21913: [CustomCellFactory] it's very hard to call custom cell editing state to appear. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java Changeset: 5ba7cfdaf636 Author: jgiles Date: 2012-06-21 06:20 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/5ba7cfdaf636 RT-20582: MenuItem's styleable has a null Node (fix for NPE) ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java Changeset: 6fc666adebea Author: jgiles Date: 2012-06-21 11:28 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/6fc666adebea RT-22572: ComboBox : value is removed when the popup is opened ! javafx-ui-controls/src/javafx/scene/control/ComboBox.java Changeset: 84acdf2dda4b Author: jgiles Date: 2012-06-21 11:35 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/84acdf2dda4b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: c390ada3dfd5 Author: jgiles Date: 2012-06-21 18:07 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/c390ada3dfd5 RT-20300: TableView is not refreshed when TableColumn are added dynamically ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableHeaderRow.java Changeset: 8f69ae6bb9f4 Author: Kinsley Wong Date: 2012-06-21 11:28 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/8f69ae6bb9f4 RT-22635: Pagination PageCount property changing leads to exception when unidirectionally binded. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java Changeset: 4a5a0e2d02e9 Author: mickf Date: 2012-06-22 21:15 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/4a5a0e2d02e9 RT-22884 - ScrollPane : Corner doesn't always fill the space to the edge properly. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java Changeset: 19ed1479a504 Author: Paru Somashekar Date: 2012-06-24 10:15 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/19ed1479a504 fix RT-21530 new color of web and that of gradient rectangle color does not always correspond. HG: changed javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java Changeset: 8334e452ecf5 Author: Paru Somashekar Date: 2012-06-24 10:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/8334e452ecf5 fix RT-21556 color picker can be broken by typing big numbers in integer field. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/IntegerField.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/IntegerFieldSkin.java Changeset: 918bee86c2d3 Author: Paru Somashekar Date: 2012-06-24 10:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/918bee86c2d3 RT-21112 web color field accept different symbols. Entering the # at the beginging of web color string is now optional. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/WebColorFieldSkin.java Changeset: 3f5d7303f073 Author: mickf Date: 2012-06-24 22:40 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/3f5d7303f073 RT-22721 : Progress indicator circle position moved in 2.2 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java Changeset: 96d95ad7e603 Author: jgiles Date: 2012-06-25 14:06 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/96d95ad7e603 RT-22668: HelloListView hangs ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: 00b1f42f76da Author: jgiles Date: 2012-06-25 14:07 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/00b1f42f76da [DOC ONLY] Clarifying purpose of promptText property in ComboBoxBase. ! javafx-ui-controls/src/javafx/scene/control/ComboBoxBase.java Changeset: a7050a4850da Author: jgiles Date: 2012-06-25 14:12 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a7050a4850da RT-22900: Cell selected property fires too frequently when selection changes ! javafx-ui-controls/src/javafx/scene/control/Cell.java ! javafx-ui-controls/src/javafx/scene/control/ListCell.java ! javafx-ui-controls/src/javafx/scene/control/TableCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeCell.java Changeset: 561c62db83f9 Author: jgiles Date: 2012-06-25 18:05 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/561c62db83f9 RT-22677: ComboBox : items list has a wrong width at first display ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxBaseSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java Changeset: 3ef6b29199f2 Author: jgiles Date: 2012-06-25 18:06 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/3ef6b29199f2 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: ba0ed1315785 Author: David Grieve Date: 2012-06-25 10:22 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/ba0ed1315785 RT-22565: follow on patch to resolve IllegalStateException when running HelloHTMLEditor ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: 83d4d7d610c4 Author: David Grieve Date: 2012-06-25 15:22 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/83d4d7d610c4 RT-22638: for calculating css values, only use a node font property if it was set by the user and there is not an inline or author style ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: 5b984ca53761 Author: Kinsley Wong Date: 2012-06-25 13:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/5b984ca53761 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java Changeset: 8dc3a4c1f7fb Author: Yao Wang Date: 2012-06-26 10:11 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/8dc3a4c1f7fb Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt From martin.desruisseaux at geomatys.fr Tue Jun 26 10:31:51 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Tue, 26 Jun 2012 19:31:51 +0200 Subject: Image loading error reporting / handling In-Reply-To: <4FE9D2B0.90609@oracle.com> References: <4FE9D2B0.90609@oracle.com> Message-ID: <4FE9F207.6050006@geomatys.fr> One advantage that I see with the proposed ImageLoader class would be its similarity with javax.imageio.ImageWriter, which may make easier to write adapters for interoperability between the two frameworks. Martin Le 26/06/12 17:18, Lubomir Nerad a ?crit : > Hi all, > > I have two feature requests which ask for better error reporting / > handling of image loading. > > The issues are: > > Make Image class support exceptions for both asynchronous and > synchronous loading > (http://javafx-jira.kenai.com/browse/RT-17645) > Image/Media need consistent error reporting > (http://javafx-jira.kenai.com/browse/RT-976) > > Currently my idea of fixing them is through a new ImageLoader class. > > This class will have two sets of instance methods for image loading: > > Image load(...) - Used for foreground image loading. The difference > between them and the Image constructors would be that by default (!) > they will throw an exception if image loading fails [RT-17645] > (instead of returning an Image with error set to true). > > Image loadAsync(...) - Used for background image loading. Will throw > only when input arguments are null or invalid. > > Then there will be methods for registering image loading event > handlers [RT-976]. I can think of the following basic set of events: > > loading started (setOnLoadingStarted) > loading progress (setOnLoadingProgress) > loading finished > loading succeeded (setOnLoadingSucceeded) > loading failed (setOnLoadingFailed) > > They will use a new ImageLoadingEvent and possibly > ImageLoadingFailedEvent (with an added exception field). The > ImageLoadingEvent will report the image for which the event has been > generated (null for foreground images?). > > Image loading errors will be reported as runtime (!) > ImageLoadingException-s. > > ImageLoader instances will be created through constructor(s) with > possibility to pass some configuration parameters (for example the > maximum number of images being loaded at the same time). > > For "logging only" image loaders we might want to allow to configure > (constructor parameter? loadingFailedEvent.consume()?) whether the > load methods will throw ImageLoadingException or merely create Images > with error flags set (as is the case of Image constructors). > > This is just a basic outline of my proposal. We can focus on details > when/if this approach is accepted. Alternatively the issues could be > fixed by additional properties / methods on Image class. I didn't like > it, because the added properties would be useful only during short > period of the whole image lifetime and absolutely unusable for some > images (images created from scratch). I also think that the > ImageLoader approach makes uniform error handling of image loading > easier (one handler for several images instead of one handler per image). > > What is your preference / opinion about this? > > Thanks, > Lubo > From John_Smith at symantec.com Tue Jun 26 17:19:15 2012 From: John_Smith at symantec.com (John Smith) Date: Tue, 26 Jun 2012 17:19:15 -0700 Subject: Image loading error reporting / handling In-Reply-To: <4FE9F207.6050006@geomatys.fr> References: <4FE9D2B0.90609@oracle.com> <4FE9F207.6050006@geomatys.fr> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D2215FCA51236@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Could (or should) a Worker interface be used as the API to monitor and control Image loading - similar to how webEngine.getLoadWorker() can be used to monitor and control web page loading? -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Martin Desruisseaux Sent: Tuesday, June 26, 2012 10:32 AM To: openjfx-dev at openjdk.java.net Subject: Re: Image loading error reporting / handling One advantage that I see with the proposed ImageLoader class would be its similarity with javax.imageio.ImageWriter, which may make easier to write adapters for interoperability between the two frameworks. Martin Le 26/06/12 17:18, Lubomir Nerad a ?crit : > Hi all, > > I have two feature requests which ask for better error reporting / > handling of image loading. > > The issues are: > > Make Image class support exceptions for both asynchronous and > synchronous loading > (http://javafx-jira.kenai.com/browse/RT-17645) > Image/Media need consistent error reporting > (http://javafx-jira.kenai.com/browse/RT-976) > > Currently my idea of fixing them is through a new ImageLoader class. > > This class will have two sets of instance methods for image loading: > > Image load(...) - Used for foreground image loading. The difference > between them and the Image constructors would be that by default (!) > they will throw an exception if image loading fails [RT-17645] > (instead of returning an Image with error set to true). > > Image loadAsync(...) - Used for background image loading. Will throw > only when input arguments are null or invalid. > > Then there will be methods for registering image loading event > handlers [RT-976]. I can think of the following basic set of events: > > loading started (setOnLoadingStarted) > loading progress (setOnLoadingProgress) > loading finished > loading succeeded (setOnLoadingSucceeded) > loading failed (setOnLoadingFailed) > > They will use a new ImageLoadingEvent and possibly > ImageLoadingFailedEvent (with an added exception field). The > ImageLoadingEvent will report the image for which the event has been > generated (null for foreground images?). > > Image loading errors will be reported as runtime (!) > ImageLoadingException-s. > > ImageLoader instances will be created through constructor(s) with > possibility to pass some configuration parameters (for example the > maximum number of images being loaded at the same time). > > For "logging only" image loaders we might want to allow to configure > (constructor parameter? loadingFailedEvent.consume()?) whether the > load methods will throw ImageLoadingException or merely create Images > with error flags set (as is the case of Image constructors). > > This is just a basic outline of my proposal. We can focus on details > when/if this approach is accepted. Alternatively the issues could be > fixed by additional properties / methods on Image class. I didn't like > it, because the added properties would be useful only during short > period of the whole image lifetime and absolutely unusable for some > images (images created from scratch). I also think that the > ImageLoader approach makes uniform error handling of image loading > easier (one handler for several images instead of one handler per image). > > What is your preference / opinion about this? > > Thanks, > Lubo > From jmartine_1026 at yahoo.com Tue Jun 26 18:15:25 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Tue, 26 Jun 2012 18:15:25 -0700 (PDT) Subject: resizing of window Message-ID: <1340759725.38015.YahooMailNeo@web160903.mail.bf1.yahoo.com> hello, I would like to support resizing of my app. ?I imagine there are two ways this could be done. 1) ?Free flow resizing. ?Users just change the window to their desired size. ?The app's root Parent will scale?accordingly to fill in the new window size. ?To support this I would need to be notified that the window size has changed and have access to the new window dimensions. ?From looking at the Stage and Window classes I do not see any way to register a call back on window resize. ?Is there a way to accomplish this? 2) ?From within the app user selects the window size they want. ?This is less ideal but acceptable. ?I did some tests and was happy with the performance of the scaled root Parent, but did see flickering and objects disappear (I am not too concerned about this yet because I was doing live scaling changes, versus through an options section from the title screen). ?The problem that I did have was that I was not able to change the window size. ?I tried using Stage.setHeight/setWidth and Stage.sizeToScene, but the window remained unchanged. ?I would first create a new Scene that matched the new dimensions, update my Stage with the new Scene, then change the?dimensions?of Stage. ?Is there a way to change the window size from within the app? ? ? ? private static void resize() { ? ? ? ? if (scaleFactor > 0) { ? ? ? ? ? ? Scale scale = ScaleBuilder.create().pivotX(0).pivotY(0).x(1 + .1 * scaleFactor).y(1 + .1 * scaleFactor).build(); ? ? ? ? ? ? root.getTransforms().setAll(scale); ? ? ? ? } else { ? ? ? ? ? ? root.getTransforms().clear(); ? ? ? ? } ? ? ? ? scene = new Scene(root, WIDTH * (1 + scaleFactor * 100), HEIGHT * (1 + scaleFactor * 64)); ? ? ? ? stage.setScene(scene); ? ? ? ? stage.sizeToScene(); //state.setHeight(scene.getHeight()); //state.setWidth(scene.getWidth()); ? ? ? ? stage.show(); ? ? } thanks jose From jmartine_1026 at yahoo.com Tue Jun 26 20:47:14 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Tue, 26 Jun 2012 20:47:14 -0700 (PDT) Subject: resizing of window In-Reply-To: <1340759725.38015.YahooMailNeo@web160903.mail.bf1.yahoo.com> References: <1340759725.38015.YahooMailNeo@web160903.mail.bf1.yahoo.com> Message-ID: <1340768834.87007.YahooMailNeo@web160902.mail.bf1.yahoo.com> Noticed a bug in how the scene's dimensions were being calculated... ? ? ? ? scene = new Scene(root, WIDTH * (1 + scaleFactor * .1), HEIGHT * ( 1 + scaleFactor * .1));//...where scaleFactor is an integer vs.? ? ? ? ? scene = new Scene(root, WIDTH * (1 + scaleFactor * 100), HEIGHT * (1 + scaleFactor * 64));//...very wrong way ....either way the window still does not change size when I apply the scene to the Stage and change the Stage's dimensions. thanks jose ________________________________ From: Jose Martinez To: openjfx mailing list Sent: Tuesday, June 26, 2012 9:15 PM Subject: resizing of window hello, I would like to support resizing of my app. ?I imagine there are two ways this could be done. 1) ?Free flow resizing. ?Users just change the window to their desired size. ?The app's root Parent will scale?accordingly to fill in the new window size. ?To support this I would need to be notified that the window size has changed and have access to the new window dimensions. ?From looking at the Stage and Window classes I do not see any way to register a call back on window resize. ?Is there a way to accomplish this? 2) ?From within the app user selects the window size they want. ?This is less ideal but acceptable. ?I did some tests and was happy with the performance of the scaled root Parent, but did see flickering and objects disappear (I am not too concerned about this yet because I was doing live scaling changes, versus through an options section from the title screen). ?The problem that I did have was that I was not able to change the window size. ?I tried using Stage.setHeight/setWidth and Stage.sizeToScene, but the window remained unchanged. ?I would first create a new Scene that matched the new dimensions, update my Stage with the new Scene, then change the?dimensions?of Stage. ?Is there a way to change the window size from within the app? ? ? ? private static void resize() { ? ? ? ? if (scaleFactor > 0) { ? ? ? ? ? ? Scale scale = ScaleBuilder.create().pivotX(0).pivotY(0).x(1 + .1 * scaleFactor).y(1 + .1 * scaleFactor).build(); ? ? ? ? ? ? root.getTransforms().setAll(scale); ? ? ? ? } else { ? ? ? ? ? ? root.getTransforms().clear(); ? ? ? ? } ? ? ? ? scene = new Scene(root, WIDTH * (1 + scaleFactor * 100), HEIGHT * (1 + scaleFactor * 64)); ? ? ? ? stage.setScene(scene); ? ? ? ? stage.sizeToScene(); //state.setHeight(scene.getHeight()); //state.setWidth(scene.getWidth()); ? ? ? ? stage.show(); ? ? } thanks jose From pavel.safrata at oracle.com Wed Jun 27 02:08:43 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Wed, 27 Jun 2012 11:08:43 +0200 Subject: resizing of window In-Reply-To: <1340759725.38015.YahooMailNeo@web160903.mail.bf1.yahoo.com> References: <1340759725.38015.YahooMailNeo@web160903.mail.bf1.yahoo.com> Message-ID: <4FEACD9B.4090804@oracle.com> Hello, Window has width and height properties, you can register listeners to them. With regards, Pavel On 27.6.2012 3:15, Jose Martinez wrote: > hello, > > I would like to support resizing of my app. I imagine there are two ways this could be done. > > 1) Free flow resizing. Users just change the window to their desired size. The app's root Parent will scale accordingly to fill in the new window size. To support this I would need to be notified that the window size has changed and have access to the new window dimensions. From looking at the Stage and Window classes I do not see any way to register a call back on window resize. Is there a way to accomplish this? > > 2) From within the app user selects the window size they want. This is less ideal but acceptable. I did some tests and was happy with the performance of the scaled root Parent, but did see flickering and objects disappear (I am not too concerned about this yet because I was doing live scaling changes, versus through an options section from the title screen). The problem that I did have was that I was not able to change the window size. I tried using Stage.setHeight/setWidth and Stage.sizeToScene, but the window remained unchanged. I would first create a new Scene that matched the new dimensions, update my Stage with the new Scene, then change the dimensions of Stage. Is there a way to change the window size from within the app? > > private static void resize() { > if (scaleFactor > 0) { > Scale scale = ScaleBuilder.create().pivotX(0).pivotY(0).x(1 + .1 * scaleFactor).y(1 + .1 * scaleFactor).build(); > root.getTransforms().setAll(scale); > } else { > root.getTransforms().clear(); > } > scene = new Scene(root, WIDTH * (1 + scaleFactor * 100), HEIGHT * (1 + scaleFactor * 64)); > stage.setScene(scene); > stage.sizeToScene(); > //state.setHeight(scene.getHeight()); > //state.setWidth(scene.getWidth()); > stage.show(); > } > > > thanks > jose From jmartine_1026 at yahoo.com Wed Jun 27 04:48:29 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Wed, 27 Jun 2012 04:48:29 -0700 (PDT) Subject: resizing of window In-Reply-To: <4FEACD9B.4090804@oracle.com> References: <1340759725.38015.YahooMailNeo@web160903.mail.bf1.yahoo.com> <4FEACD9B.4090804@oracle.com> Message-ID: <1340797709.6211.YahooMailNeo@web160904.mail.bf1.yahoo.com> Pavel, That worked great! ?Thanks a lot. Is there are a way to change the window size from within the app? ? thanks jose ________________________________ From: Pavel Safrata To: openjfx-dev at openjdk.java.net Sent: Wednesday, June 27, 2012 5:08 AM Subject: Re: resizing of window Hello, Window has width and height properties, you can register listeners to them. With regards, Pavel On 27.6.2012 3:15, Jose Martinez wrote: > hello, > > I would like to support resizing of my app.? I imagine there are two ways this could be done. > > 1)? Free flow resizing.? Users just change the window to their desired size.? The app's root Parent will scale accordingly to fill in the new window size.? To support this I would need to be notified that the window size has changed and have access to the new window dimensions.? From looking at the Stage and Window classes I do not see any way to register a call back on window resize.? Is there a way to accomplish this? > > 2)? From within the app user selects the window size they want.? This is less ideal but acceptable.? I did some tests and was happy with the performance of the scaled root Parent, but did see flickering and objects disappear (I am not too concerned about this yet because I was doing live scaling changes, versus through an options section from the title screen).? The problem that I did have was that I was not able to change the window size.? I tried using Stage.setHeight/setWidth and Stage.sizeToScene, but the window remained unchanged.? I would first create a new Scene that matched the new dimensions, update my Stage with the new Scene, then change the dimensions of Stage.? Is there a way to change the window size from within the app? >? >? ? ? private static void resize() { >? ? ? ? ? if (scaleFactor > 0) { >? ? ? ? ? ? ? Scale scale = ScaleBuilder.create().pivotX(0).pivotY(0).x(1 + .1 * scaleFactor).y(1 + .1 * scaleFactor).build(); >? ? ? ? ? ? ? root.getTransforms().setAll(scale); >? ? ? ? ? } else { >? ? ? ? ? ? ? root.getTransforms().clear(); >? ? ? ? ? } >? ? ? ? ? scene = new Scene(root, WIDTH * (1 + scaleFactor * 100), HEIGHT * (1 + scaleFactor * 64)); >? ? ? ? ? stage.setScene(scene); >? ? ? ? ? stage.sizeToScene(); > //state.setHeight(scene.getHeight()); > //state.setWidth(scene.getWidth()); >? ? ? ? ? stage.show(); >? ? ? } > > > thanks > jose From zonski at gmail.com Wed Jun 27 06:10:22 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Wed, 27 Jun 2012 23:10:22 +1000 Subject: FXML backwards compatibility issue Message-ID: In my FXML Controllers I have the following member variable: private ResourceBundle resources; After loading my Controller via FXML, I would then set this manually so my Controllers could access the resources needed. In version JFX 2.1 and lower this works fine but in version 2.2 it looks like JFX has decided it has control over this variable now? As a result JFX attempts to inject the resources, but it fails because the variable is private and not marked with @FXML. My application is very broken and won't start without me going back and changing this everywhere. I also have another problem with imports. Since there was no ComboBox in JFX, I created my own. Now one exists in JFX and has the same name as mine. In code my imports have been added via my IDE and by luck my ComboBox is imported explicitly (i.e. not using the * wildcard). In my FXML however, I have added these by hand and my imports are using wildcard imports for both my 'control' package and the JFX 'control' package. End result: the JFX ComboBox is now the one being referenced and so I get class cast and no such method errors at runtime. I'm pretty much cactus here right? Auto-update is going to mean the users will get 2.2 when it is released (do we have a date for this?). I have to go back and "fix" all this "broken" code, on a project I no longer work on for a client no longer paying me? From greg.x.brown at oracle.com Wed Jun 27 06:15:26 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Wed, 27 Jun 2012 09:15:26 -0400 Subject: FXML backwards compatibility issue In-Reply-To: References: Message-ID: <79E0BF42-8556-4073-A4F3-2D307FA6D189@oracle.com> > In my FXML Controllers I have the following member variable: > > private ResourceBundle resources; > > After loading my Controller via FXML, I would then set this manually so my > Controllers could access the resources needed. > > In version JFX 2.1 and lower this works fine but in version 2.2 it looks > like JFX has decided it has control over this variable now? As a result JFX > attempts to inject the resources, but it fails because the variable is > private and not marked with @FXML. This is a bug. I'll start looking into a fix, but I'd appreciate it if you would submit a JIRA ticket. Thanks. From greg.x.brown at oracle.com Wed Jun 27 06:26:43 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Wed, 27 Jun 2012 09:26:43 -0400 Subject: FXML backwards compatibility issue In-Reply-To: References: Message-ID: > In my FXML Controllers I have the following member variable: > > private ResourceBundle resources; > > In version JFX 2.1 and lower this works fine but in version 2.2 it looks > like JFX has decided it has control over this variable now? OK, I see the problem. In 2.2, we added support for automatic injection of the "resources" and "location" fields. We only do this if the controller does not implement Initializable - the thinking being that, if the controller does implement Initializable, it will get the location and resources via the initialize() method. Otherwise, we assume that the controller wants to get these values via injection. I'm guessing your controller does not implement Initializable, but also does not want these fields injected. The fix is simple - FXMLLoader can just ignore the IllegalAccessException when attempting to inject these fields. If we ever deprecate/remove Initializable, we can go back to throwing in this case. Make sense? Greg From pavel.safrata at oracle.com Wed Jun 27 06:28:07 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Wed, 27 Jun 2012 15:28:07 +0200 Subject: resizing of window In-Reply-To: <1340797709.6211.YahooMailNeo@web160904.mail.bf1.yahoo.com> References: <1340759725.38015.YahooMailNeo@web160903.mail.bf1.yahoo.com> <4FEACD9B.4090804@oracle.com> <1340797709.6211.YahooMailNeo@web160904.mail.bf1.yahoo.com> Message-ID: <4FEB0A67.3070809@oracle.com> Setting those properties should work. Pavel On 27.6.2012 13:48, Jose Martinez wrote: > Pavel, > > That worked great! Thanks a lot. > > Is there are a way to change the window size from within the app? > thanks > jose > ------------------------------------------------------------------------ > *From:* Pavel Safrata > *To:* openjfx-dev at openjdk.java.net > *Sent:* Wednesday, June 27, 2012 5:08 AM > *Subject:* Re: resizing of window > > Hello, > Window has width and height properties, you can register listeners to > them. > With regards, > Pavel > > On 27.6.2012 3:15, Jose Martinez wrote: > > hello, > > > > I would like to support resizing of my app. I imagine there are two > ways this could be done. > > > > 1) Free flow resizing. Users just change the window to their > desired size. The app's root Parent will scale accordingly to fill in > the new window size. To support this I would need to be notified that > the window size has changed and have access to the new window > dimensions. From looking at the Stage and Window classes I do not see > any way to register a call back on window resize. Is there a way to > accomplish this? > > > > 2) From within the app user selects the window size they want. > This is less ideal but acceptable. I did some tests and was happy > with the performance of the scaled root Parent, but did see flickering > and objects disappear (I am not too concerned about this yet because I > was doing live scaling changes, versus through an options section from > the title screen). The problem that I did have was that I was not > able to change the window size. I tried using > Stage.setHeight/setWidth and Stage.sizeToScene, but the window > remained unchanged. I would first create a new Scene that matched the > new dimensions, update my Stage with the new Scene, then change the > dimensions of Stage. Is there a way to change the window size from > within the app? > > > > private static void resize() { > > if (scaleFactor > 0) { > > Scale scale = > ScaleBuilder.create().pivotX(0).pivotY(0).x(1 + .1 * scaleFactor).y(1 > + .1 * scaleFactor).build(); > > root.getTransforms().setAll(scale); > > } else { > > root.getTransforms().clear(); > > } > > scene = new Scene(root, WIDTH * (1 + scaleFactor * 100), > HEIGHT * (1 + scaleFactor * 64)); > > stage.setScene(scene); > > stage.sizeToScene(); > > //state.setHeight(scene.getHeight()); > > //state.setWidth(scene.getWidth()); > > stage.show(); > > } > > > > > > thanks > > jose > > > > From alexandre.iline at oracle.com Wed Jun 27 06:29:41 2012 From: alexandre.iline at oracle.com (alexandre.iline at oracle.com) Date: Wed, 27 Jun 2012 13:29:41 +0000 Subject: hg: openjfx/2.2/master/tests: 3 new changesets Message-ID: <20120627132942.007F647B52@hg.openjdk.java.net> Changeset: a8fbe90bc84e Author: Alexandre (Shura) Iline Date: 2012-06-27 12:34 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/a8fbe90bc84e Some javadoc. Missed tests Fixed dependencies in browser and test ! bigapps/EnsembleTest/nbproject/build-impl.xml ! bigapps/EnsembleTest/nbproject/genfiles.properties ! bigapps/EnsembleTest/nbproject/project.properties ! bigapps/EnsembleTest/nbproject/project.xml ! tools/Jemmy/JemmyFX/build.xml ! tools/Jemmy/JemmyFX/depend.properties ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/index.html ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/AbstractNodeHierarchy.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/AppExecutor.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/ByID.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/ByObject.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/ByStyleClass.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/ByText.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/ByTitleSceneLookup.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/ByWindowType.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/CriteriaList.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/FXClickFocus.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/FXRelativeCoordinateLookup.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/Lookups.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeHierarchy.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeParent.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeParentImpl.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrapper.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/QueueExecutor.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/RelativeMouse.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/Root.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/SceneList.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/SceneNodeHierarchy.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/SceneWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/SceneWrapper.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/TextWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/WindowElement.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/AbstractItemsParent.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TabWrap.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/package.html + tools/Jemmy/JemmyFX/test/org/jemmy/fx/MultiSceneTest.java + tools/Jemmy/JemmyFX/test/org/jemmy/fx/TwoSceneApp.java ! tools/Jemmy/JemmyFXBrowser/nbproject/build-impl.xml ! tools/Jemmy/JemmyFXBrowser/nbproject/genfiles.properties ! tools/Jemmy/JemmyFXBrowser/nbproject/project.properties ! tools/Jemmy/JemmyFXBrowser/nbproject/project.xml ! tools/Jemmy/README Changeset: be861684d20d Author: Alexandre (Shura) Iline Date: 2012-06-27 16:57 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/be861684d20d Mac fix ! tools/Jemmy/JemmyFX/build.xml ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/accordion/AccordionSample.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/buttons/ButtonsSample.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/environment/EnvironmentSample.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/environment/TimeoutsSample.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/input/InputSampleBase.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/lookup/LookupSampleBase.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/text/TextSample.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/Root.java Changeset: 6a2624036241 Author: Alexandre (Shura) Iline Date: 2012-06-27 17:07 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/6a2624036241 missed class + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/SampleBase.java From greg.x.brown at oracle.com Wed Jun 27 06:32:41 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Wed, 27 Jun 2012 09:32:41 -0400 Subject: FXML backwards compatibility issue In-Reply-To: References: Message-ID: I have filed a bug for this: http://javafx-jira.kenai.com/browse/RT-22971 From zonski at gmail.com Wed Jun 27 06:52:53 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Wed, 27 Jun 2012 23:52:53 +1000 Subject: FXML backwards compatibility issue In-Reply-To: References: Message-ID: <2F622BC0-BB3F-4F5A-9FC5-0B39B6F40BA5@gmail.com> Sounds good and this should avoid the worst of my two problems. Might it just be best not to try and inject it if it's not annotated with @FXML, private or otherwise? I'm not fussed though, so long as it works. I don't think I'm going to get out of my ComboBox problem so easily. I'm a little scared of what other less obvious side effects there may be from other fixes. The problem is really the auto updating rather than the fixes. And I guess I'm in for fun all over again in 2.3, 2.4, and on to infinity unless I get them off the jnlp deployment model. Thanks for the prompt reply on the resource issue. I appreciate it. Just for your info my resources get injected into the controller via a custom loader that wrappers the FXMLloader. This loader gets passed the resources to set on the loader and then if the controller implements HasResources it get set on that. Looks like in 2.2 I'll be able to ditch this code for future projects now that yours does the same job. On 27/06/2012, at 11:26 PM, Greg Brown wrote: >> In my FXML Controllers I have the following member variable: >> >> private ResourceBundle resources; >> >> In version JFX 2.1 and lower this works fine but in version 2.2 it looks >> like JFX has decided it has control over this variable now? > > OK, I see the problem. In 2.2, we added support for automatic injection of the "resources" and "location" fields. We only do this if the controller does not implement Initializable - the thinking being that, if the controller does implement Initializable, it will get the location and resources via the initialize() method. Otherwise, we assume that the controller wants to get these values via injection. > > I'm guessing your controller does not implement Initializable, but also does not want these fields injected. The fix is simple - FXMLLoader can just ignore the IllegalAccessException when attempting to inject these fields. If we ever deprecate/remove Initializable, we can go back to throwing in this case. Make sense? > > Greg > From greg.x.brown at oracle.com Wed Jun 27 07:15:54 2012 From: greg.x.brown at oracle.com (Greg Brown) Date: Wed, 27 Jun 2012 10:15:54 -0400 Subject: FXML backwards compatibility issue In-Reply-To: <2F622BC0-BB3F-4F5A-9FC5-0B39B6F40BA5@gmail.com> References: <2F622BC0-BB3F-4F5A-9FC5-0B39B6F40BA5@gmail.com> Message-ID: <9CD5674A-D730-4472-95E2-D1112D842A06@oracle.com> > Thanks for the prompt reply on the resource issue. I appreciate it. No problem - thanks for identifying the issue. I just committed the fix. From pavel.safrata at oracle.com Wed Jun 27 07:19:25 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Wed, 27 Jun 2012 16:19:25 +0200 Subject: resizing of window In-Reply-To: <1340806527.42042.YahooMailNeo@web160903.mail.bf1.yahoo.com> References: <1340759725.38015.YahooMailNeo@web160903.mail.bf1.yahoo.com> <4FEACD9B.4090804@oracle.com> <1340797709.6211.YahooMailNeo@web160904.mail.bf1.yahoo.com> <4FEB0A67.3070809@oracle.com> <1340806527.42042.YahooMailNeo@web160903.mail.bf1.yahoo.com> Message-ID: <4FEB166D.5050103@oracle.com> Oh right, I've forgotten. They are read only to prevent bindings. But there are public setWidth and setHeight methods. Regards, Pavel On 27.6.2012 16:15, Jose Martinez wrote: > The height and width properties on Stage and Window are read only. > > thanks > jose > ------------------------------------------------------------------------ > *From:* Pavel Safrata > *To:* Jose Martinez > *Cc:* "openjfx-dev at openjdk.java.net" > *Sent:* Wednesday, June 27, 2012 9:28 AM > *Subject:* Re: resizing of window > > Setting those properties should work. > Pavel > > On 27.6.2012 13:48, Jose Martinez wrote: >> Pavel, >> >> That worked great! Thanks a lot. >> >> Is there are a way to change the window size from within the app? >> thanks >> jose >> ------------------------------------------------------------------------ >> *From:* Pavel Safrata >> >> *To:* openjfx-dev at openjdk.java.net >> *Sent:* Wednesday, June 27, 2012 5:08 AM >> *Subject:* Re: resizing of window >> >> Hello, >> Window has width and height properties, you can register listeners to >> them. >> With regards, >> Pavel >> >> On 27.6.2012 3:15, Jose Martinez wrote: >> > hello, >> > >> > I would like to support resizing of my app. I imagine there are >> two ways this could be done. >> > >> > 1) Free flow resizing. Users just change the window to their >> desired size. The app's root Parent will scale accordingly to fill >> in the new window size. To support this I would need to be notified >> that the window size has changed and have access to the new window >> dimensions. From looking at the Stage and Window classes I do not >> see any way to register a call back on window resize. Is there a way >> to accomplish this? >> > >> > 2) From within the app user selects the window size they want. >> This is less ideal but acceptable. I did some tests and was happy >> with the performance of the scaled root Parent, but did see >> flickering and objects disappear (I am not too concerned about this >> yet because I was doing live scaling changes, versus through an >> options section from the title screen). The problem that I did have >> was that I was not able to change the window size. I tried using >> Stage.setHeight/setWidth and Stage.sizeToScene, but the window >> remained unchanged. I would first create a new Scene that matched >> the new dimensions, update my Stage with the new Scene, then change >> the dimensions of Stage. Is there a way to change the window size >> from within the app? >> > >> > private static void resize() { >> > if (scaleFactor > 0) { >> > Scale scale = >> ScaleBuilder.create().pivotX(0).pivotY(0).x(1 + .1 * scaleFactor).y(1 >> + .1 * scaleFactor).build(); >> > root.getTransforms().setAll(scale); >> > } else { >> > root.getTransforms().clear(); >> > } >> > scene = new Scene(root, WIDTH * (1 + scaleFactor * 100), >> HEIGHT * (1 + scaleFactor * 64)); >> > stage.setScene(scene); >> > stage.sizeToScene(); >> > //state.setHeight(scene.getHeight()); >> > //state.setWidth(scene.getWidth()); >> > stage.show(); >> > } >> > >> > >> > thanks >> > jose >> >> >> >> > > > > From jmartine_1026 at yahoo.com Wed Jun 27 07:15:27 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Wed, 27 Jun 2012 07:15:27 -0700 (PDT) Subject: resizing of window In-Reply-To: <4FEB0A67.3070809@oracle.com> References: <1340759725.38015.YahooMailNeo@web160903.mail.bf1.yahoo.com> <4FEACD9B.4090804@oracle.com> <1340797709.6211.YahooMailNeo@web160904.mail.bf1.yahoo.com> <4FEB0A67.3070809@oracle.com> Message-ID: <1340806527.42042.YahooMailNeo@web160903.mail.bf1.yahoo.com> The height and width properties on Stage and Window are read only. thanks jose ________________________________ From: Pavel Safrata To: Jose Martinez Cc: "openjfx-dev at openjdk.java.net" Sent: Wednesday, June 27, 2012 9:28 AM Subject: Re: resizing of window Setting those properties should work. Pavel On 27.6.2012 13:48, Jose Martinez wrote: Pavel, > > >That worked great! ?Thanks a lot. > > >Is there are a way to change the window size from within the app? >? >thanks >jose > > >________________________________ > From: Pavel Safrata >To: openjfx-dev at openjdk.java.net >Sent: Wednesday, June 27, 2012 5:08 AM >Subject: Re: resizing of window > >Hello, >Window has width and height properties, you can register listeners to them. >With regards, >Pavel > >On 27.6.2012 3:15, Jose Martinez wrote: >> hello, >> >> I would like to support resizing of my app.? I imagine there are two ways this could be done. >> >> 1)? Free flow resizing.? Users just change the window to their desired size.? The app's root Parent will scale accordingly to fill in the new window size.? To support this I would need to be notified that the window size has changed and have access to the new window dimensions.? From looking at the Stage and Window classes I do not see any way to register a call back on window resize.? Is there a way to accomplish this? >> >> 2)? From within the app user selects the window size they want.? This is less ideal but acceptable.? I did some tests and was happy with the performance of the scaled root Parent, but did see flickering and objects disappear (I am not too concerned about this yet because I was doing live scaling changes, versus through an options section from the title screen).? The problem that I did have was that I was not able to change the window size.? I tried using Stage.setHeight/setWidth and Stage.sizeToScene, but the window remained unchanged.? I would first create a new Scene that matched the new dimensions, update my Stage with the new Scene, then change the dimensions of Stage.? Is there a way to change the window size from within the app? >>? >>? ? ? private static void resize() { >>? ? ? ? ? if (scaleFactor > 0) { >>? ? ? ? ? ? ? Scale scale = ScaleBuilder.create().pivotX(0).pivotY(0).x(1 + .1 * scaleFactor).y(1 + .1 * scaleFactor).build(); >>? ? ? ? ? ? ? root.getTransforms().setAll(scale); >>? ? ? ? ? } else { >>? ? ? ? ? ? ? root.getTransforms().clear(); >>? ? ? ? ? } >>? ? ? ? ? scene = new Scene(root, WIDTH * (1 + scaleFactor * 100), HEIGHT * (1 + scaleFactor * 64)); >>? ? ? ? ? stage.setScene(scene); >>? ? ? ? ? stage.sizeToScene(); >> //state.setHeight(scene.getHeight()); >> //state.setWidth(scene.getWidth()); >>? ? ? ? ? stage.show(); >>? ? ? } >> >> >> thanks >> jose > > > > > From kevin.rushforth at oracle.com Wed Jun 27 07:26:13 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 27 Jun 2012 07:26:13 -0700 Subject: resizing of window In-Reply-To: <1340806527.42042.YahooMailNeo@web160903.mail.bf1.yahoo.com> References: <1340759725.38015.YahooMailNeo@web160903.mail.bf1.yahoo.com> <4FEACD9B.4090804@oracle.com> <1340797709.6211.YahooMailNeo@web160904.mail.bf1.yahoo.com> <4FEB0A67.3070809@oracle.com> <1340806527.42042.YahooMailNeo@web160903.mail.bf1.yahoo.com> Message-ID: <4FEB1805.1090700@oracle.com> But there are set methods that you can use on the Window. -- Kevin Jose Martinez wrote: > The height and width properties on Stage and Window are read only. > > thanks > jose > > > ________________________________ > From: Pavel Safrata > To: Jose Martinez > Cc: "openjfx-dev at openjdk.java.net" > Sent: Wednesday, June 27, 2012 9:28 AM > Subject: Re: resizing of window > > > Setting those properties should work. > Pavel > > > On 27.6.2012 13:48, Jose Martinez wrote: > > Pavel, > >> That worked great! Thanks a lot. >> >> >> Is there are a way to change the window size from within the app? >> >> thanks >> jose >> >> >> ________________________________ >> From: Pavel Safrata >> To: openjfx-dev at openjdk.java.net >> Sent: Wednesday, June 27, 2012 5:08 AM >> Subject: Re: resizing of window >> >> Hello, >> Window has width and height properties, you can register >> > listeners to them. > >> With regards, >> Pavel >> >> On 27.6.2012 3:15, Jose Martinez wrote: >> >>> hello, >>> >>> I would like to support resizing of my app. I imagine >>> > there are two ways this could be done. > >>> 1) Free flow resizing. Users just change the window >>> > to their desired size. The app's root Parent will scale > accordingly to fill in the new window size. To support this > I would need to be notified that the window size has changed > and have access to the new window dimensions. From looking > at the Stage and Window classes I do not see any way to > register a call back on window resize. Is there a way to > accomplish this? > >>> 2) From within the app user selects the window size >>> > they want. This is less ideal but acceptable. I did some > tests and was happy with the performance of the scaled root > Parent, but did see flickering and objects disappear (I am > not too concerned about this yet because I was doing live > scaling changes, versus through an options section from the > title screen). The problem that I did have was that I was > not able to change the window size. I tried using > Stage.setHeight/setWidth and Stage.sizeToScene, but the > window remained unchanged. I would first create a new Scene > that matched the new dimensions, update my Stage with the > new Scene, then change the dimensions of Stage. Is there a > way to change the window size from within the app? > >>> >>> private static void resize() { >>> if (scaleFactor > 0) { >>> Scale scale = >>> > ScaleBuilder.create().pivotX(0).pivotY(0).x(1 + .1 * > scaleFactor).y(1 + .1 * scaleFactor).build(); > >>> root.getTransforms().setAll(scale); >>> } else { >>> root.getTransforms().clear(); >>> } >>> scene = new Scene(root, WIDTH * (1 + >>> > scaleFactor * 100), HEIGHT * (1 + scaleFactor * 64)); > >>> stage.setScene(scene); >>> stage.sizeToScene(); >>> //state.setHeight(scene.getHeight()); >>> //state.setWidth(scene.getWidth()); >>> stage.show(); >>> } >>> >>> >>> thanks >>> jose >>> >> >> >> >> From jmartine_1026 at yahoo.com Wed Jun 27 07:40:24 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Wed, 27 Jun 2012 07:40:24 -0700 (PDT) Subject: resizing of window In-Reply-To: <4FEB1805.1090700@oracle.com> References: <1340759725.38015.YahooMailNeo@web160903.mail.bf1.yahoo.com> <4FEACD9B.4090804@oracle.com> <1340797709.6211.YahooMailNeo@web160904.mail.bf1.yahoo.com> <4FEB0A67.3070809@oracle.com> <1340806527.42042.YahooMailNeo@web160903.mail.bf1.yahoo.com> <4FEB1805.1090700@oracle.com> Message-ID: <1340808024.52445.YahooMailNeo@web160906.mail.bf1.yahoo.com> Kevin, Pavel, That is what I was doing originally (and it was not working) but now I see that I was doing something wrong and it is working now. ?Thank you for your responses! ? jose ________________________________ From: Kevin Rushforth To: Jose Martinez Cc: Pavel Safrata ; "openjfx-dev at openjdk.java.net" Sent: Wednesday, June 27, 2012 10:26 AM Subject: Re: resizing of window But there are set methods that you can use on the Window. -- Kevin Jose Martinez wrote: The height and width properties on Stage and Window are read only. thanks jose ________________________________ From: Pavel Safrata To: Jose Martinez Cc: "openjfx-dev at openjdk.java.net" Sent: Wednesday, June 27, 2012 9:28 AM Subject: Re: resizing of window Setting those properties should work. Pavel On 27.6.2012 13:48, Jose Martinez wrote: Pavel, >That worked great! ?Thanks a lot. Is there are a way to change the window size from within the app? ? thanks jose ________________________________ From: Pavel Safrata To: openjfx-dev at openjdk.java.net Sent: Wednesday, June 27, 2012 5:08 AM Subject: Re: resizing of window Hello, Window has width and height properties, you can register >listeners to them. >With regards, Pavel On 27.6.2012 3:15, Jose Martinez wrote: >>hello, I would like to support resizing of my app.? I imagine >there are two ways this could be done. >1)? Free flow resizing.? Users just change the window >to their desired size.? The app's root Parent will scale accordingly to fill in the new window size.? To support this I would need to be notified that the window size has changed and have access to the new window dimensions.? From looking at the Stage and Window classes I do not see any way to register a call back on window resize.? Is there a way to accomplish this? >2)? From within the app user selects the window size >they want.? This is less ideal but acceptable.? I did some tests and was happy with the performance of the scaled root Parent, but did see flickering and objects disappear (I am not too concerned about this yet because I was doing live scaling changes, versus through an options section from the title screen).? The problem that I did have was that I was not able to change the window size.? I tried using Stage.setHeight/setWidth and Stage.sizeToScene, but the window remained unchanged.? I would first create a new Scene that matched the new dimensions, update my Stage with the new Scene, then change the dimensions of Stage.? Is there a way to change the window size from within the app? >? ? ? ? private static void resize() { ? ? ? ? ? if (scaleFactor > 0) { ? ? ? ? ? ? ? Scale scale = >ScaleBuilder.create().pivotX(0).pivotY(0).x(1 + .1 * scaleFactor).y(1 + .1 * scaleFactor).build(); >? ? ? ? ? ? ? root.getTransforms().setAll(scale); ? ? ? ? ? } else { ? ? ? ? ? ? ? root.getTransforms().clear(); ? ? ? ? ? } ? ? ? ? ? scene = new Scene(root, WIDTH * (1 + >scaleFactor * 100), HEIGHT * (1 + scaleFactor * 64)); >? ? ? ? ? stage.setScene(scene); ? ? ? ? ? stage.sizeToScene(); //state.setHeight(scene.getHeight()); //state.setWidth(scene.getWidth()); ? ? ? ? ? stage.show(); ? ? ? } thanks jose From goddard at seznam.cz Wed Jun 27 08:28:56 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Wed, 27 Jun 2012 17:28:56 +0200 (CEST) Subject: =?us-ascii?Q?Best=20way=20to=20block=20KeyEvent?= Message-ID: <130273.3832.24258-11189-87267586-1340810936@seznam.cz> Hello, what's the best way to block KeyEvent? Let's say I want to have "enabled" only one key at a time in a set of keys. Regards, Jiri From eva.krejcirova at oracle.com Wed Jun 27 08:50:14 2012 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Wed, 27 Jun 2012 17:50:14 +0200 Subject: Extending Builders with custom code Message-ID: <4FEB2BB6.1080101@oracle.com> Hi All, I am currently working on a system for extending our automatically generated Builder classes with custom code and I would like to ask for your help. Are you missing some convenience methods in existing builders? I would be happy to hear it! (preferably in a form of Jira issue ;-)) Currently we have these Jira issues: * RT-19266 which talks about PathBuilder (adding moveTo(), lineTo() methods to PathBuilder) * RT-16569 mentions the need for convenience methods in builders of layout classes (but doesn't specify it more) Thanks, Eva From lubomir.nerad at oracle.com Wed Jun 27 08:50:55 2012 From: lubomir.nerad at oracle.com (Lubomir Nerad) Date: Wed, 27 Jun 2012 17:50:55 +0200 Subject: Image loading error reporting / handling In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D2215FCA51236@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <4FE9D2B0.90609@oracle.com> <4FE9F207.6050006@geomatys.fr> <411E73D23DEC4C46BA48F2B6D8BF3D2215FCA51236@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <4FEB2BDF.50009@oracle.com> Hi John, good question, but I don't think it will be useful in this case. Worker interface is more suitable to track loading of a single Image and most of the information available through that interface is already provided by the Image class. Or we can try to define ImageLoader as a javafx.concurrent.Service, but in that case we would inherit some unwanted methods and loose the possibility to attach some additional information to the reported events. Thanks, Lubo On 6/27/2012 2:19 AM, John Smith wrote: > Could (or should) a Worker interface be used as the API to monitor and control Image loading - similar to how webEngine.getLoadWorker() can be used to monitor and control web page loading? > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Martin Desruisseaux > Sent: Tuesday, June 26, 2012 10:32 AM > To: openjfx-dev at openjdk.java.net > Subject: Re: Image loading error reporting / handling > > One advantage that I see with the proposed ImageLoader class would be > its similarity with javax.imageio.ImageWriter, which may make easier to > write adapters for interoperability between the two frameworks. > > Martin > > > Le 26/06/12 17:18, Lubomir Nerad a ?crit : >> Hi all, >> >> I have two feature requests which ask for better error reporting / >> handling of image loading. >> >> The issues are: >> >> Make Image class support exceptions for both asynchronous and >> synchronous loading >> (http://javafx-jira.kenai.com/browse/RT-17645) >> Image/Media need consistent error reporting >> (http://javafx-jira.kenai.com/browse/RT-976) >> >> Currently my idea of fixing them is through a new ImageLoader class. >> >> This class will have two sets of instance methods for image loading: >> >> Image load(...) - Used for foreground image loading. The difference >> between them and the Image constructors would be that by default (!) >> they will throw an exception if image loading fails [RT-17645] >> (instead of returning an Image with error set to true). >> >> Image loadAsync(...) - Used for background image loading. Will throw >> only when input arguments are null or invalid. >> >> Then there will be methods for registering image loading event >> handlers [RT-976]. I can think of the following basic set of events: >> >> loading started (setOnLoadingStarted) >> loading progress (setOnLoadingProgress) >> loading finished >> loading succeeded (setOnLoadingSucceeded) >> loading failed (setOnLoadingFailed) >> >> They will use a new ImageLoadingEvent and possibly >> ImageLoadingFailedEvent (with an added exception field). The >> ImageLoadingEvent will report the image for which the event has been >> generated (null for foreground images?). >> >> Image loading errors will be reported as runtime (!) >> ImageLoadingException-s. >> >> ImageLoader instances will be created through constructor(s) with >> possibility to pass some configuration parameters (for example the >> maximum number of images being loaded at the same time). >> >> For "logging only" image loaders we might want to allow to configure >> (constructor parameter? loadingFailedEvent.consume()?) whether the >> load methods will throw ImageLoadingException or merely create Images >> with error flags set (as is the case of Image constructors). >> >> This is just a basic outline of my proposal. We can focus on details >> when/if this approach is accepted. Alternatively the issues could be >> fixed by additional properties / methods on Image class. I didn't like >> it, because the added properties would be useful only during short >> period of the whole image lifetime and absolutely unusable for some >> images (images created from scratch). I also think that the >> ImageLoader approach makes uniform error handling of image loading >> easier (one handler for several images instead of one handler per image). >> >> What is your preference / opinion about this? >> >> Thanks, >> Lubo >> > From lubomir.nerad at oracle.com Wed Jun 27 09:12:47 2012 From: lubomir.nerad at oracle.com (Lubomir Nerad) Date: Wed, 27 Jun 2012 18:12:47 +0200 Subject: Best way to block KeyEvent In-Reply-To: <130273.3832.24258-11189-87267586-1340810936@seznam.cz> References: <130273.3832.24258-11189-87267586-1340810936@seznam.cz> Message-ID: <4FEB30FF.5080702@oracle.com> Hi Jiri, you can consume key events for blocked keys in an event filter. Event filter is an EventHandler registered through addEventFilter method. It can be registered directly on the focused node or on any of its parent nodes, scene or stage. Example: node.addEventFilter(KeyEvent.KEY_PRESSED, new EventHandler() { public void handle(KeyEvent keyEvent) { if () { keyEvent.consume(); } } }); For you can use the KeyCombination.match method. Regards, Lubo On 6/27/2012 5:28 PM, goddard at seznam.cz wrote: > Hello, > > what's the best way to block KeyEvent? Let's say I want to have "enabled" only one key at a time in a set of keys. > > Regards, Jiri From alexandre.iline at oracle.com Wed Jun 27 09:33:26 2012 From: alexandre.iline at oracle.com (alexandre.iline at oracle.com) Date: Wed, 27 Jun 2012 16:33:26 +0000 Subject: hg: openjfx/2.2/master/tests: fixed compilation error Message-ID: <20120627163326.C6FDC47B56@hg.openjdk.java.net> Changeset: 4023a2c07664 Author: Alexandre (Shura) Iline Date: 2012-06-27 20:33 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/4023a2c07664 fixed compilation error ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/ByObject.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/ByStyleClass.java From pedro.duquevieira at gmail.com Wed Jun 27 09:55:31 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 27 Jun 2012 17:55:31 +0100 Subject: Extending Builders with custom code Message-ID: Hi, There is also this one - add bind support to builders: http://javafx-jira.kenai.com/browse/RT-15662 Best regards, -- Pedro Duque Vieira From mp at jugs.org Wed Jun 27 10:31:29 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Wed, 27 Jun 2012 19:31:29 +0200 Subject: Extending Builders with custom code In-Reply-To: <4FEB2BB6.1080101@oracle.com> References: <4FEB2BB6.1080101@oracle.com> Message-ID: <4FEB4371.4080704@jugs.org> Hi, I thought I was quite explicit in RT-16569 but anyway - here is an example. The whole purpose of the Builders is to be able to define a whole scene graph fluently in one statement but with the current Builders this is not directly possible because we cannot use convenience methods like these. (Example from the documentation of GridPane) Applications may also use convenience methods which combine the steps of setting the constraints and adding the children: GridPane gridpane = new GridPane(); gridpane.add(new Button(), 2, 1); // column=2 row=1 gridpane.add(new Label(), 3, 1); // column=3 row=1 Just try to do the same using the GridPaneBuilder. You can't because the GridPaneBuilder does not have this special 'add' method which GridPane provides. There are more classes where such a situation occurs. Someone would have to go over all classes for which there is a Builder and look whether it has any convenience methods which are relevant for the building process. LG, Michael Am 27.06.2012 17:50, schrieb Eva Krejcirova: > Hi All, > > I am currently working on a system for extending our automatically > generated Builder classes with custom code and I would like to ask for > your help. Are you missing some convenience methods in existing > builders? I would be happy to hear it! (preferably in a form of Jira > issue ;-)) > > Currently we have these Jira issues: > * RT-19266 which talks about PathBuilder (adding moveTo(), lineTo() > methods to PathBuilder) > * RT-16569 mentions the need for convenience methods in builders of > layout classes (but doesn't specify it more) > > Thanks, > Eva -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From gunnar at hibernate.org Wed Jun 27 13:59:35 2012 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 27 Jun 2012 22:59:35 +0200 Subject: JavaFX Form Validation Message-ID: Hi all, first off, sorry for arriving that late to the party, I just stumbled upon this thread by a post in the Bean Validation feedback forum [1]. I'm member of the JSR 349 (BV 1.1) expert group and also committing to the BV reference implementation, Hibernate Validator. Therefore I'm very interested in the topic of integrating JavaFX with BV and just wanted to add some thoughts from my side :) Reading through this thread, I saw the question whether BV might be somehow dead or inactive. Please rest assured that this is absolutely not the case. BV 1.0 is part of JEE 6 and as such is widely used in enterprise applications. Currently we're working on BV 1.1 which is intended to be part of JEE 7. See [2] for the roadmap. One general theme is the integration with other specs (CDI, JAX-RS etc.), and I feel Bean Validation would also be very valuable to be used together with JavaFX. As someone already pointed out, BV is explicitly not targeting a single application layer but is intended to be used in all places where validation is required (persistence, service, frontend layer etc.). It is also not restricted to the server side or Java EE, it runs perfectly on the client and Java SE (and in fact is used in GUI technologies such as JSF or GWT etc). So personally, I'd be a strong proponent for making use of BV for validation purposes in JavaFX. IMO using the same validation facility throughout all application layers makes developer life easier, avoids redundancies and inconsistencies etc. That said, I've actually played around a bit with integrating JavaFX and BV a while ago, the result can be found at [3] (have a look at the readme and the contained example application [4]). Back then, I didn't pursue the idea any further, but the project shows that BV can easily be used for validation with JavaFX. In case there are any questions around Bean Validation, please don't hesitate to contact the BV EG [5]. The Hibernate Validator reference guide [6] can serve as good introduction to the API and its possibilities. Also let us know if there are certain things missing, which would be beneficial for the JavaFX use case. I'll also point the BV EG and its spec lead, Emmanuel Bernard, to this thread. With best regards, --Gunnar [1] https://forum.hibernate.org/viewtopic.php?f=26&t=1015972 [2] http://beanvalidation.org/roadmap/ [3] https://github.com/gunnarmorling/jx-binding [4] https://github.com/gunnarmorling/jx-binding/blob/master/src/test/java/de/gmorling/jxbinding/example/JxBindingExample.java [5] https://lists.jboss.org/mailman/listinfo/beanvalidation-dev [6] http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html/ From hang.vo at oracle.com Wed Jun 27 14:05:41 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 27 Jun 2012 21:05:41 +0000 Subject: hg: openjfx/2.2/master/rt: 37 new changesets Message-ID: <20120627210617.E5F2B47B5F@hg.openjdk.java.net> Changeset: 55cb5954521b Author: Kinsley Wong Date: 2012-06-18 17:26 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/55cb5954521b Reapply fix for RT-21906 so we can further debug this issue. ! javafx-ui-common/src/com/sun/javafx/css/CascadingStyle.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java Changeset: d5d7c3a4b94d Author: jgiles Date: 2012-06-19 11:02 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/d5d7c3a4b94d RT-22645: ClassCastException (Controls Regression) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 4849a03007c5 Author: jgiles Date: 2012-06-19 13:24 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/4849a03007c5 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 2522280029a7 Author: mickf Date: 2012-06-19 16:58 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/2522280029a7 RT-22653 : ScrollBar with -fx-border styles is drawn wrong in 2.2 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java Changeset: 1de4b14f0aa9 Author: mickf Date: 2012-06-19 17:00 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/1de4b14f0aa9 RT-22652 : ScrollBar -fx-background-color behavior changed in 2.2 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: 123426be1adf Author: Kinsley Wong Date: 2012-06-19 10:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/123426be1adf RT-22455: Clip doesn't work. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/Utils.java Changeset: 238594fe9cab Author: Kinsley Wong Date: 2012-06-19 12:13 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/238594fe9cab RT-22687: Pagination Before click next - "ArithmeticException / by zero" for small size pane. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/test/javafx/scene/control/PaginationTest.java Changeset: f12ab84e2a1e Author: jgiles Date: 2012-06-20 14:19 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/f12ab84e2a1e RT-22565: Once set, setting stylesheets on a Parent has no effect. Patch supplied by David Grieve. ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Parent.java Changeset: 9cd4f06a4d7c Author: jgiles Date: 2012-06-20 14:20 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/9cd4f06a4d7c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 40920694bc2a Author: mickf Date: 2012-06-20 17:23 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/40920694bc2a RT-22653 : ScrollBar with -fx-border styles is drawn wrong in 2.2 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java Changeset: bd662b49adec Author: mickf Date: 2012-06-20 18:57 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/bd662b49adec RT-22650 : ListView hides -fx-border in 2.2 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 88f62d205d2a Author: Kinsley Wong Date: 2012-06-20 14:18 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/88f62d205d2a RT-22717: TabPane does not update its selection model after removing the selected Tab. ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java Changeset: 1aa7c6fcca3e Author: jgiles Date: 2012-06-20 16:39 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/1aa7c6fcca3e RT-22630: ComboBox : exception when promptText is set ! javafx-ui-controls/src/javafx/scene/control/ComboBox.java Changeset: afda3a34df03 Author: jgiles Date: 2012-06-21 06:06 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/afda3a34df03 RT-21913: [CustomCellFactory] it's very hard to call custom cell editing state to appear. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java Changeset: 5ba7cfdaf636 Author: jgiles Date: 2012-06-21 06:20 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/5ba7cfdaf636 RT-20582: MenuItem's styleable has a null Node (fix for NPE) ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java Changeset: 6fc666adebea Author: jgiles Date: 2012-06-21 11:28 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/6fc666adebea RT-22572: ComboBox : value is removed when the popup is opened ! javafx-ui-controls/src/javafx/scene/control/ComboBox.java Changeset: 84acdf2dda4b Author: jgiles Date: 2012-06-21 11:35 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/84acdf2dda4b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: c390ada3dfd5 Author: jgiles Date: 2012-06-21 18:07 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/c390ada3dfd5 RT-20300: TableView is not refreshed when TableColumn are added dynamically ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableHeaderRow.java Changeset: 8f69ae6bb9f4 Author: Kinsley Wong Date: 2012-06-21 11:28 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/8f69ae6bb9f4 RT-22635: Pagination PageCount property changing leads to exception when unidirectionally binded. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java Changeset: 4a5a0e2d02e9 Author: mickf Date: 2012-06-22 21:15 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/4a5a0e2d02e9 RT-22884 - ScrollPane : Corner doesn't always fill the space to the edge properly. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java Changeset: 19ed1479a504 Author: Paru Somashekar Date: 2012-06-24 10:15 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/19ed1479a504 fix RT-21530 new color of web and that of gradient rectangle color does not always correspond. HG: changed javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java Changeset: 8334e452ecf5 Author: Paru Somashekar Date: 2012-06-24 10:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/8334e452ecf5 fix RT-21556 color picker can be broken by typing big numbers in integer field. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/IntegerField.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/IntegerFieldSkin.java Changeset: 918bee86c2d3 Author: Paru Somashekar Date: 2012-06-24 10:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/918bee86c2d3 RT-21112 web color field accept different symbols. Entering the # at the beginging of web color string is now optional. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/WebColorFieldSkin.java Changeset: 3f5d7303f073 Author: mickf Date: 2012-06-24 22:40 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/3f5d7303f073 RT-22721 : Progress indicator circle position moved in 2.2 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java Changeset: 96d95ad7e603 Author: jgiles Date: 2012-06-25 14:06 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/96d95ad7e603 RT-22668: HelloListView hangs ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: 00b1f42f76da Author: jgiles Date: 2012-06-25 14:07 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/00b1f42f76da [DOC ONLY] Clarifying purpose of promptText property in ComboBoxBase. ! javafx-ui-controls/src/javafx/scene/control/ComboBoxBase.java Changeset: a7050a4850da Author: jgiles Date: 2012-06-25 14:12 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/a7050a4850da RT-22900: Cell selected property fires too frequently when selection changes ! javafx-ui-controls/src/javafx/scene/control/Cell.java ! javafx-ui-controls/src/javafx/scene/control/ListCell.java ! javafx-ui-controls/src/javafx/scene/control/TableCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeCell.java Changeset: 561c62db83f9 Author: jgiles Date: 2012-06-25 18:05 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/561c62db83f9 RT-22677: ComboBox : items list has a wrong width at first display ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxBaseSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java Changeset: 3ef6b29199f2 Author: jgiles Date: 2012-06-25 18:06 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/3ef6b29199f2 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: ba0ed1315785 Author: David Grieve Date: 2012-06-25 10:22 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/ba0ed1315785 RT-22565: follow on patch to resolve IllegalStateException when running HelloHTMLEditor ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: 83d4d7d610c4 Author: David Grieve Date: 2012-06-25 15:22 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/83d4d7d610c4 RT-22638: for calculating css values, only use a node font property if it was set by the user and there is not an inline or author style ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: 5b984ca53761 Author: Kinsley Wong Date: 2012-06-25 13:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/5b984ca53761 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java Changeset: 605a2c2253e5 Author: "Joseph Andresen" Date: 2012-06-19 12:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/605a2c2253e5 RT-22434: Canvas Defaults should be same as FX ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java Changeset: cce23876f3c4 Author: flar Date: 2012-06-19 23:13 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/cce23876f3c4 Fix RT-19711 Color.web() should allow floating point values for percents and angles. ! javafx-ui-common/src/javafx/scene/paint/Color.java ! javafx-ui-common/test/unit/javafx/scene/paint/ColorTest.java Changeset: ab81c2cf3cca Author: flar Date: 2012-06-23 19:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/ab81c2cf3cca Fix RT-22885: PixelFormat.get/setArgb() methods have errors. ! javafx-ui-common/src/javafx/scene/image/PixelFormat.java ! javafx-ui-common/src/javafx/scene/image/WritablePixelFormat.java + javafx-ui-common/test/unit/javafx/scene/image/PixelFormatTest.java Changeset: 8dc3a4c1f7fb Author: Yao Wang Date: 2012-06-26 10:11 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/8dc3a4c1f7fb Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt Changeset: 5f3d913cf4e3 Author: hudson Date: 2012-06-27 14:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/5f3d913cf4e3 Added tag 2.2-b15 for changeset 8dc3a4c1f7fb ! .hgtags From hang.vo at oracle.com Wed Jun 27 16:04:14 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 27 Jun 2012 23:04:14 +0000 Subject: hg: openjfx/2.2/controls/rt: Backed out changeset 9a2b4524a317 Message-ID: <20120627230421.A439947B66@hg.openjdk.java.net> Changeset: 385a5b779565 Author: David Grieve Date: 2012-06-27 18:52 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/385a5b779565 Backed out changeset 9a2b4524a317 ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java From hang.vo at oracle.com Wed Jun 27 16:18:38 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 27 Jun 2012 23:18:38 +0000 Subject: hg: openjfx/2.2/graphics/rt: Added tag 2.2-b15 for changeset 8dc3a4c1f7fb Message-ID: <20120627231843.CD54B47B68@hg.openjdk.java.net> Changeset: 5f3d913cf4e3 Author: hudson Date: 2012-06-27 14:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/5f3d913cf4e3 Added tag 2.2-b15 for changeset 8dc3a4c1f7fb ! .hgtags From pavel.safrata at oracle.com Thu Jun 28 00:17:05 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 28 Jun 2012 09:17:05 +0200 Subject: Best way to block KeyEvent In-Reply-To: <130273.3832.24258-11189-87267586-1340810936@seznam.cz> References: <130273.3832.24258-11189-87267586-1340810936@seznam.cz> Message-ID: <4FEC04F1.9000606@oracle.com> Hello, you can register an event filter on scene and consume the events you want to block. By the way, I think this kind of questions should be placed rather on forums for more users to benefit from the answers. This mailing list is meant rather for discussions related to development of JFX itself. https://forums.oracle.com/forums/category.jspa?categoryID=298 Regards, Pavel On 27.6.2012 17:28, goddard at seznam.cz wrote: > Hello, > > what's the best way to block KeyEvent? Let's say I want to have "enabled" only one key at a time in a set of keys. > > Regards, Jiri From michael.heinrichs at oracle.com Thu Jun 28 00:42:48 2012 From: michael.heinrichs at oracle.com (Michael Heinrichs) Date: Thu, 28 Jun 2012 09:42:48 +0200 Subject: Extending Builders with custom code In-Reply-To: <4FEB2BB6.1080101@oracle.com> References: <4FEB2BB6.1080101@oracle.com> Message-ID: <8D609681-1FDD-4D7E-919B-E4F6F9AC5973@oracle.com> Hi Evo, there was an interesting comment after one of my blog posts about reusing builders. Basically the commentator pointed out that making builders immutable would make them much better suited for reuse. The obvious solution, changing our builders, would break backward compatibility. But maybe you (or somebody on this alias) has a good idea how this can be achieved without breaking backward compatibility. Below is the full comment. Cheers, Michael Thanks for the post. I can clearly see the benefits of using builders and we have been using them in some areas in our code. Your post made me realize that reusing builders can be really powerful. Our application has a number of TableViews and each view has a number of columns. The builders are a perfect fit for the scenario where you want to create a number of columns that have many properties in common. You can use a TableColumnBuilder to create partial specification for the column and then stamp out the columns by setting the unique properties for each column and build() them (Similar to your text1, text2, text3 example above). The only problem is builders are not immutable. Every time you set a property on the builder it affects all future build events. In you example above, if you only want text2 to be green it would be nice if you were able to call it as follows: final Text text1 = builder.text(?Hello World!?).y(50).build(); final Text text2 = builder.text(?Goodbye World!?).y(100).fill(Color.GREEN).build(); final Text text3 = builder.text(?JavaFX is fun!?).y(150).build(); But this results in both text2 and text3 turning green. I think making builders immutable will significantly improve the ability to reuse them. Consider the following example: TableColumnBuilder standardColumnBuilder = TableColumnBuilder.create() .prefWidth(50.0) .sortable(false) .editable(false); TableColumnBuilder narrowColumnBuilder = standardColumnBuilder .prefWidth(40.0) .resizable(false); TableColumnBuilder narrowColumnBuilder = narrowColumnBuilder .prefWidth(80.0); If builders were immutable I would now have three templates that I could reuse to build all the table columns but because they are not immutable I now have a ?standardColumnBuilder? that is not resizable and has a width of 80. Cheers, Ab On 27.06.2012, at 17:50, Eva Krejcirova wrote: > Hi All, > > I am currently working on a system for extending our automatically generated Builder classes with custom code and I would like to ask for your help. Are you missing some convenience methods in existing builders? I would be happy to hear it! (preferably in a form of Jira issue ;-)) > > Currently we have these Jira issues: > * RT-19266 which talks about PathBuilder (adding moveTo(), lineTo() methods to PathBuilder) > * RT-16569 mentions the need for convenience methods in builders of layout classes (but doesn't specify it more) > > Thanks, > Eva From pavel.safrata at oracle.com Thu Jun 28 01:00:42 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 28 Jun 2012 10:00:42 +0200 Subject: Region PickOnBounds default setting In-Reply-To: References: <4FE185F4.9020407@oracle.com> <4FE2DEF5.8080209@oracle.com> <4FE307EB.6020202@xs4all.nl> Message-ID: <4FEC0F2A.6060406@oracle.com> I'm sorry for the delay. I commented on the issue and attached the EvilPane there. I also described another problem I just noticed: Another example is picking slices in a pie chart. Right now it by default picks completely wrong slices because each slice is a region and is picked on bounds that cover large portions of neighboring slices. You have to do a "data.getNode().setPickOnBounds(false);" exercise for each slice to make it behave reasonably. Thanks, Pavel On 21.6.2012 17:37, Richard Bair wrote: > Ah I see the problem. Pavel can we make sure there is some text in the issue describing the problem (ie bounds != region width/height, and thus pick on bounds is undeniably wrong in that case). > > Dan -- the bounds always must include the bounds of all stuff, without putting a clip on every region you have to be prepared for layout bounds != bounds in parent / bounds in local. > > Note that putting a clip on regions by default would be a huge mistake. You wouldn't be able to do a number of common effects where you are translating children outside the bounds of the container. It is the difference between basic form like apps and more graphical ones. > > On Jun 21, 2012, at 4:48 AM, Daniel Zwolenski wrote: > >> I just ran the code (thanks Pavel!) and I agree. While I see the problem >> with the picking, a bigger problem in my mind is that the max bounds are >> not being honoured. The picking to me is just a side effect of some odd >> layout sizing behaviour. >> >> My expectation with this code is it should either honour the max bounds and >> clip the child nodes (my preference) or, if it's really not going to honour >> the max bounds, then it should stretch the region to the bounds that it is >> actually covering. The hybrid thing it is doing is just weird in my >> opinion. >> >> >> On Thu, Jun 21, 2012 at 9:39 PM, John Hendrikx wrote: >> >>> Not sure if interested, but coming from someone who has never seen this >>> before... I must say it certainly looks counter-intuitive. Why does the >>> evilPane have such big bounds? It is restricted in layout to a max size of >>> (50,50)... and thus I would expect the blue child to be clipped and the >>> pane Bounds to be reduced to no more than (50,50). >>> >>> But I guess that is because of the tree style rendering that JavaFX does, >>> where nodes can exceed their layout bounds when effects/translations are >>> applied... as I said, it certainly looks counter-intuitive, in more ways >>> than one coming from someone who is used to Container/Groups strictly sized >>> to fit their children, and clipping the children that will not fit. >>> >>> --John >>> >>> >>> On 21/06/2012 10:44, Pavel Safrata wrote: >>> >>>> Hi Daniel, >>>> >>>> On 20.6.2012 21:55, Daniel Zwolenski wrote: >>>> >>>>> Assuming I understand the problem then I've hit this sort of layout >>>>>>> problem and my instinct was to look >>>>>>> I'm not sure I agree with the bug description when it says that "both >>>>>>> visually and in source code there is nothing in between the pane and the >>>>>>> child". In code there is a pane. Visually there would be a pane if you set >>>>>>> styles on it. >>>>>>> >>>>>> The pane from the description is small and is in a top-left corner. It >>>>>> can be styled, and you can see it there. There is no code that would make >>>>>> the pane big to cover the whole scene, there is no way to make it visible >>>>>> in the whole area, because it's just not there. >>>>>> >>>>> I am perhaps missing something, but "Pane's bounds will then cover whole >>>>> sceen" implies to me the pane is stretched, so if I styled it I would see >>>>> it stretched. The description of #2 is a bit vague to me though. I guess a >>>>> code example would clear this up but it probably doesn't matter that I dont >>>>> understand. >>>>> >>>> The pane is not necessarily stretched to embrace all its children. I've >>>> attached a code example that shows the problem. >>>> >>>> >>>>> I'm guessing, for example, if this fix went in it would break all my >>>>>>> 'glasspanes'? >>>>>>> >>>>>> I cannot say unless I know how your glasspanes are implemented... >>>>>> >>>>> I use glass panes to block the screen in two cases: when loading and >>>>> behind a light box (ie embedded dialog). >>>>> >>>>> In both cases my glass pane is just a pane (eg BorderPane) added to the >>>>> top of a StackPane with the rest of the app added to a lower layer of the >>>>> stack. In the loading case it has no children, in the dialog case it's >>>>> child is the dialog. >>>>> >>>>> The loading one is transparent but has an in-progress cursor when you >>>>> mouse over. In the dialog case, the pane is a translucent grey, though you >>>>> could style it differently and transparent would be a valid style (making >>>>> the fill color define if it is clickable would not be nice for me and is a >>>>> little scary). >>>>> >>>>> In both cases the point of it is that it blocks mouse input to the >>>>> scene. I'd prefer this didn't break in a future release (sorry!). If auto >>>>> updating (my nemesis) wasn't on then I'd be ok for it to change and then I >>>>> fix my apps before moving to a higher version but it magically working one >>>>> day and not the next would be pretty nasty for me. >>>>> >>>> It would break your glass panes only if they have no fill (which I agree >>>> is bad enough). Pane with transparent fill would still block mouse events. >>>> I'm not sure why this is scary, this approach is used everywhere in FX >>>> except of Region. >>>> >>>> >>>>> As such, I don't think it needs to be a default attribute now that it's >>>>>>> in place the other way round but I do think it needs to be clear and >>>>>>> intuitive how to deal with it. >>>>>>> >>>>>> I'm really sad that we've let this go that far, it could have been >>>>>> fixed before our first release. If the decision comes that it's too late by >>>>>> now, the way how to deal with it will be clear (setPickOnBounds(false)), >>>>>> but I doubt it is (and could be) intuitive. >>>>>> >>>>> For me the current default behavior seems intuitive: the pane is >>>>> clickable for whatever area it takes up. I get the feeling I might be >>>>> missing something here though as it is obviously a concern for some people. >>>>> Sorry if I have misunderstood. >>>>> >>>> I think the attached example shows pane that is clickable in area that it >>>> doesn't take up. >>>> >>>> >>>>> For me the only problem with the current approach is that in some cases >>>>> I'd like a pane used purely for layout (anchor pane as top layer of a >>>>> StackPane is a prime candidate) to not catch mouse clicks but the children >>>>> on it still should. Calling setPickOnBounds(false) and setShape(null) to do >>>>> this is not intuitive to me but I'm glad I now know its possible as I've >>>>> struggled with this before (and possibly raised a bug, will have to check). >>>>> >>>> This is exactly the most common problem that would be solved. You see >>>> you're glad that you now know how to solve it, but other users will keep >>>> bumping into this issue.. >>>> >>>> Thanks, >>>> Pavel >>>> >>>> >>>>> Thanks, >>>>>> Pavel >>>>>> >>>>>> >>>>>>> On 20/06/2012, at 5:41 AM, Richard Bair >>>>>>> wrote: >>>>>>> >>>>>>> Hi folks, >>>>>>>> We have an issue which has been in the platform from before 2.0: >>>>>>>> http://javafx-jira.kenai.com/**browse/RT-17024. >>>>>>>> A better explanation of the issue can be found on >>>>>>>> http://javafx-jira.kenai.com/**browse/RT-12258. >>>>>>>> From 12258: >>>>>>>> >>>>>>>> Region behaves counter-intuitively regarding mouse event delivering. >>>>>>>>> It reacts on mouse events everywhere in its bounds and people are often >>>>>>>>> confused by it. Here are two simple examples: >>>>>>>>> >>>>>>>>> 1) You create let's say HBox just because you want it to layout its >>>>>>>>> children. The HBox catches all mouse events in the whole area given by its >>>>>>>>> bounds. Often it's hard to understand what area it is (with children of >>>>>>>>> different size or with some other layout stretches taking place). >>>>>>>>> >>>>>>>>> 2) You create a small Pane in top-left corner of the scene with a >>>>>>>>> child in bottom-right corner of the scene. Pane's bounds will then cover >>>>>>>>> whole sceen and you won't be able to click on anything else than the pane >>>>>>>>> and its child. Users don't understand why, because both visually and in >>>>>>>>> source code there is nothing in between the pane and the child. >>>>>>>>> >>>>>>>>> Moreover, region may have a shape associated and the behavior here >>>>>>>>> is also strange. If you create a region with a shape inside its bounds, >>>>>>>>> it's just ignored. You can also create a shape somewhere else, then it >>>>>>>>> extends region's bounds and it reacts on mouse click everywhere between the >>>>>>>>> shape and the region. >>>>>>>>> >>>>>>>> This issue has to do with the semantics of picking on a Region. For >>>>>>>> Region we have had pickOnBounds set to true by default, which yields the >>>>>>>> above behaviors. We can change it to false by default, but then need to >>>>>>>> update a bunch of skins (for example the up/down arrows of scroll bar, the >>>>>>>> thumb of a slider, the down arrow of a combo box button, etc) so that they >>>>>>>> switch back to having pickOnBounds set to true by default so that the >>>>>>>> target area for clicks is larger. We could just change the default for Pane >>>>>>>> and not for Region, although we use StackPane in Skins and would have to >>>>>>>> update them anyhow. It seems that for a normal layout container the >>>>>>>> behavior really should be pickOnBounds=false by default, but for UI >>>>>>>> controls usages and such you generally want it true. >>>>>>>> >>>>>>>> I'm not certain making this change is worth being backwards >>>>>>>> incompatible (semantically, binary compatibility would remain). But what do >>>>>>>> you think? >>>>>>>> >>>>>>>> Richard >>>>>>>> From martin.sladecek at oracle.com Thu Jun 28 01:16:35 2012 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Thu, 28 Jun 2012 10:16:35 +0200 Subject: API REVIEW: BaseObservableList Message-ID: <4FEC12E3.3020708@oracle.com> Hello, BaseObservableList was already discussed for 2.1, but we decided to defer it to some later release at the end. Full discussion here: http://mail.openjdk.java.net/pipermail/openjfx-dev/2011-December/000224.html. Based on the discussion, I reworked it into two new classes: BaseObservableList (for simple observable lists that are not necessarily modifiable) and it's subclass BaseModifiableObservableList. *public abstract class BaseObservableList extends AbstractList implements ObservableList:* First of all, it will implement following ObservableList methods: public final void addListener(InvalidationListener listener) public final void removeListener(InvalidationListener listener) public final void addListener(ListChangeListener listener) public final void removeListener(ListChangeListener listener) ... and will contain these new methods: // calls all the listeners of this ObservableList protected final void callListeners(ListChangeListener.Change change) // true if there are some registered listeners protected final boolean hasListeners() Following methods were part of IterableChangeBuilder in the original discussion. Now they will be part of BaseObservableList and can be used for creating a Change and firing it, so you don't need to create subclasses of ListChangeListener.Change yourself. protected final void nextUpdate(int pos) protected final void nextSet(int idx, E old) protected final void nextReplace(int from, int to, ArrayList removed) protected final void nextRemove(int idx, List removed) protected final void nextRemove(int idx, E removed) protected final void nextPermutation(int from, int to, int[] perm) protected final void nextAdd(int from, int to) protected final void endChange() protected final void beginChange() All next* methods need to be enclosed in beginChange() / endChange() pair. The calls can be also nested and after the outermost endChange() call, callListeners() will be called with the newly created Change. *public abstract class BaseModifiableObservableList extends BaseObservableList: * This class introduces three new abstract methods: protected abstract void doAdd(int index, E element); protected abstract E doSet(int index, E element); protected abstract E doRemove(int index); These methods are meant to contain simple list manipulations. The BaseModifiableObservableList implementation takes care of Change construction (using BaseObservableList methods), but subclasses can override this behaviour. Any comments? Thanks, -Martin From pavel.safrata at oracle.com Thu Jun 28 01:20:24 2012 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Thu, 28 Jun 2012 10:20:24 +0200 Subject: Extending Builders with custom code In-Reply-To: <8D609681-1FDD-4D7E-919B-E4F6F9AC5973@oracle.com> References: <4FEB2BB6.1080101@oracle.com> <8D609681-1FDD-4D7E-919B-E4F6F9AC5973@oracle.com> Message-ID: <4FEC13C8.2090908@oracle.com> How about a copy() method that would return a new builder with all the set values copied? Then users could do TableColumnBuilder narrowColumnBuilder = standardColumnBuilder.copy() .prefWidth(40.0) .resizable(false); Regards, Pavel On 28.6.2012 9:42, Michael Heinrichs wrote: > Hi Evo, > > there was an interesting comment after one of my blog posts about reusing builders. Basically the commentator pointed out that making builders immutable would make them much better suited for reuse. The obvious solution, changing our builders, would break backward compatibility. But maybe you (or somebody on this alias) has a good idea how this can be achieved without breaking backward compatibility. Below is the full comment. > > Cheers, > Michael > > > > Thanks for the post. I can clearly see the benefits of using builders and we have been using them in some areas in our code. Your post made me realize that reusing builders can be really powerful. Our application has a number of TableViews and each view has a number of columns. The builders are a perfect fit for the scenario where you want to create a number of columns that have many properties in common. You can use a TableColumnBuilder to create partial specification for the column and then stamp out the columns by setting the unique properties for each column and build() them (Similar to your text1, text2, text3 example above). The only problem is builders are not immutable. Every time you set a property on the builder it affects all future build events. In you example above, if you only want text2 to be green it would be nice if you were able to call it as follows: > > final Text text1 = builder.text(?Hello World!?).y(50).build(); > final Text text2 = builder.text(?Goodbye World!?).y(100).fill(Color.GREEN).build(); > final Text text3 = builder.text(?JavaFX is fun!?).y(150).build(); > > But this results in both text2 and text3 turning green. > > I think making builders immutable will significantly improve the ability to reuse them. Consider the following example: > > TableColumnBuilder standardColumnBuilder = TableColumnBuilder.create() > .prefWidth(50.0) > .sortable(false) > .editable(false); > TableColumnBuilder narrowColumnBuilder = standardColumnBuilder > .prefWidth(40.0) > .resizable(false); > TableColumnBuilder narrowColumnBuilder = narrowColumnBuilder > .prefWidth(80.0); > > If builders were immutable I would now have three templates that I could reuse to build all the table columns but because they are not immutable I now have a ?standardColumnBuilder? that is not resizable and has a width of 80. > > Cheers, > Ab > > > > On 27.06.2012, at 17:50, Eva Krejcirova wrote: > >> Hi All, >> >> I am currently working on a system for extending our automatically generated Builder classes with custom code and I would like to ask for your help. Are you missing some convenience methods in existing builders? I would be happy to hear it! (preferably in a form of Jira issue ;-)) >> >> Currently we have these Jira issues: >> * RT-19266 which talks about PathBuilder (adding moveTo(), lineTo() methods to PathBuilder) >> * RT-16569 mentions the need for convenience methods in builders of layout classes (but doesn't specify it more) >> >> Thanks, >> Eva From eva.krejcirova at oracle.com Thu Jun 28 01:51:26 2012 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Thu, 28 Jun 2012 10:51:26 +0200 Subject: Extending Builders with custom code In-Reply-To: References: Message-ID: <4FEC1B0E.6050206@oracle.com> Hi Pedro, thanks for mentioning this, I plan to work bind support too (but as a separate task because it is something which can be generated automatically and doesn't require custom code). Regards, Eva On 6/27/2012 6:55 PM, Pedro Duque Vieira wrote: > Hi, > > There is also this one - add bind support to builders: > http://javafx-jira.kenai.com/browse/RT-15662 > > Best regards, From daniel.fuchs at oracle.com Thu Jun 28 02:03:08 2012 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 28 Jun 2012 11:03:08 +0200 Subject: Extending Builders with custom code In-Reply-To: References: Message-ID: <4FEC1DCC.7030207@oracle.com> Hi Michael, As you noted making Builders immutable would break backward compatibility. Another interesting alternative could be to generate an applyTo() method that takes another builder as parameter. I am wondering whether the following would be doable: For instance - today TextBuilder has a method: public void applyTo(Text x) If it add an additional public (or even protected) void applyTo(TextBuilder otherBuilder) then we could possibly also generate a: public static TextBuilder create(TextBuilder initialConfiguration) { final TextBuilder newBuilder = create(); initialConfiguration.applyTo(newBuilder); return newBuilder; } Your example would then become: final Text text1 = TextBuilder.create(builder).text("Hello World!").y(50).build(); final Text text2 = TextBuilder.create(builder).text("Goodbye World!").y(100).fill(Color.GREEN).build(); final Text text3 = TextBuilder.create(builder).text("JavaFX is fun!").y(150).build(); I believe it would address your requirement without introducing any backward compatibility issue. Just thinking out loud... -- daniel On 6/28/12 9:43 AM, openjfx-dev-request at openjdk.java.net wrote: > From: Michael Heinrichs > Subject: Re: Extending Builders with custom code > > Hi Evo, > > there was an interesting comment after one of my blog posts about reusing builders. Basically the commentator pointed out that making builders immutable would make them much better suited for reuse. The obvious solution, changing our builders, would break backward compatibility. But maybe you (or somebody on this alias) has a good idea how this can be achieved without breaking backward compatibility. Below is the full comment. > > Cheers, > Michael > > > > Thanks for the post. I can clearly see the benefits of using builders and we have been using them in some areas in our code. Your post made me realize that reusing builders can be really powerful. Our application has a number of TableViews and each view has a number of columns. The builders are a perfect fit for the scenario where you want to create a number of columns that have many properties in common. You can use a TableColumnBuilder to create partial specification for the column and then stamp out the columns by setting the unique properties for each column and build() them (Similar to your text1, text2, text3 example above). The only problem is builders are not immutable. Every time you set a property on the builder it affects all future build events. In you example above, if you only want text2 to be green it would be nice if you were able to call it as follows: > > final Text text1 = builder.text(?Hello World!?).y(50).build(); > final Text text2 = builder.text(?Goodbye World!?).y(100).fill(Color.GREEN).build(); > final Text text3 = builder.text(?JavaFX is fun!?).y(150).build(); > > But this results in both text2 and text3 turning green. > > I think making builders immutable will significantly improve the ability to reuse them. Consider the following example: > > TableColumnBuilder standardColumnBuilder = TableColumnBuilder.create() > .prefWidth(50.0) > .sortable(false) > .editable(false); > TableColumnBuilder narrowColumnBuilder = standardColumnBuilder > .prefWidth(40.0) > .resizable(false); > TableColumnBuilder narrowColumnBuilder = narrowColumnBuilder > .prefWidth(80.0); > > If builders were immutable I would now have three templates that I could reuse to build all the table columns but because they are not immutable I now have a ?standardColumnBuilder? that is not resizable and has a width of 80. > > Cheers, > Ab > > > > On 27.06.2012, at 17:50, Eva Krejcirova wrote: > >> >Hi All, >> > >> >I am currently working on a system for extending our automatically generated Builder classes with custom code and I would like to ask for your help. Are you missing some convenience methods in existing builders? I would be happy to hear it! (preferably in a form of Jira issue ;-)) >> > >> >Currently we have these Jira issues: >> >* RT-19266 which talks about PathBuilder (adding moveTo(), lineTo() methods to PathBuilder) >> >* RT-16569 mentions the need for convenience methods in builders of layout classes (but doesn't specify it more) >> > >> >Thanks, >> >Eva From goddard at seznam.cz Thu Jun 28 02:36:10 2012 From: goddard at seznam.cz (goddard at seznam.cz) Date: Thu, 28 Jun 2012 11:36:10 +0200 (CEST) Subject: =?us-ascii?Q?Re=3A=20Re=3A=20Best=20way=20to=20block=20KeyEvent?= In-Reply-To: <4FEB30FF.5080702@oracle.com> Message-ID: <130315.3629.24190-24689-118515658-1340876170@seznam.cz> Thanks, and happy name day :) http://www.slate.com/blogs/future_tense/2012/06/27/_back_to_the_future_future_day_hoax_today_not_the_date_shown_on_doc_s_delorean.html Jiri ------------ P?vodn? zpr?va ------------ Od: Lubomir Nerad P?edm?t: Re: Best way to block KeyEvent Datum: 27.6.2012 18:12:55 ---------------------------------------- Hi Jiri, you can consume key events for blocked keys in an event filter. Event filter is an EventHandler registered through addEventFilter method. It can be registered directly on the focused node or on any of its parent nodes, scene or stage. Example: node.addEventFilter(KeyEvent.KEY_PRESSED, new EventHandler() { public void handle(KeyEvent keyEvent) { if () { keyEvent.consume(); } } }); For you can use the KeyCombination.match method. Regards, Lubo On 6/27/2012 5:28 PM, goddard at seznam.cz wrote: > Hello, > > what's the best way to block KeyEvent? Let's say I want to have "enabled" only one key at a time in a set of keys. > > Regards, Jiri From lubomir.nerad at oracle.com Thu Jun 28 04:08:35 2012 From: lubomir.nerad at oracle.com (Lubomir Nerad) Date: Thu, 28 Jun 2012 13:08:35 +0200 Subject: Best way to block KeyEvent In-Reply-To: <130315.3629.24190-24689-118515658-1340876170@seznam.cz> References: <130315.3629.24190-24689-118515658-1340876170@seznam.cz> Message-ID: <4FEC3B33.7060808@oracle.com> Ahoj Jiri :-), I am Slovak, so it's not my name day quite yet. But thanks anyway. Lubo On 6/28/2012 11:36 AM, goddard at seznam.cz wrote: > Thanks, and happy name day :) > http://www.slate.com/blogs/future_tense/2012/06/27/_back_to_the_future_future_day_hoax_today_not_the_date_shown_on_doc_s_delorean.html > > > Jiri > > ------------ P?vodn? zpr?va ------------ > Od: Lubomir Nerad > P?edm?t: Re: Best way to block KeyEvent > Datum: 27.6.2012 18:12:55 > ---------------------------------------- > Hi Jiri, > > you can consume key events for blocked keys in an event filter. Event > filter is an EventHandler registered through addEventFilter method. It > can be registered directly on the focused node or on any of its parent > nodes, scene or stage. > > Example: > > node.addEventFilter(KeyEvent.KEY_PRESSED, > new EventHandler() { > public void handle(KeyEvent keyEvent) { > if () { > keyEvent.consume(); > } > } > }); > > For you can use the KeyCombination.match method. > > Regards, > Lubo > > On 6/27/2012 5:28 PM, goddard at seznam.cz wrote: >> Hello, >> >> what's the best way to block KeyEvent? Let's say I want to have >> "enabled" only > one key at a time in a set of keys. >> >> Regards, Jiri > > From alexandre.iline at oracle.com Thu Jun 28 05:44:27 2012 From: alexandre.iline at oracle.com (alexandre.iline at oracle.com) Date: Thu, 28 Jun 2012 12:44:27 +0000 Subject: hg: openjfx/2.2/master/tests: 4 new changesets Message-ID: <20120628124428.56EF747B92@hg.openjdk.java.net> Changeset: a38035938aad Author: Shura Date: 2012-06-28 01:06 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/a38035938aad JMY-136 ! tools/Jemmy/JemmyFX/build.xml ! tools/Jemmy/JemmyFX/nbproject/build-impl.xml ! tools/Jemmy/JemmyFX/nbproject/genfiles.properties ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFX/nbproject/project.xml Changeset: f9748e0eb3a4 Author: Shura Date: 2012-06-28 04:31 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/f9748e0eb3a4 merge Changeset: c130999fcb79 Author: Alexandre (Shura) Iline Date: 2012-06-28 16:14 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/c130999fcb79 New doclet generator and a few fixes http://javafx-jira.kenai.com/browse/JMY-139 http://javafx-jira.kenai.com/browse/JMY-140 http://javafx-jira.kenai.com/browse/JMY-141 ! tools/Jemmy/JemmyFX/build.xml ! tools/Jemmy/JemmyFX/depend.properties ! tools/Jemmy/JemmyFX/nbproject/genfiles.properties ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFX/nbproject/project.xml ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/accordion/AccordionSample.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/AccordionWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ComboBoxWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TextInputControlWrap.java ! tools/Jemmy/README Changeset: 66d7b2152ee5 Author: Alexandre (Shura) Iline Date: 2012-06-28 16:16 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/66d7b2152ee5 merge ! tools/Jemmy/JemmyFX/build.xml ! tools/Jemmy/JemmyFX/nbproject/genfiles.properties ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFX/nbproject/project.xml From hang.vo at oracle.com Thu Jun 28 10:49:58 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 28 Jun 2012 17:49:58 +0000 Subject: hg: openjfx/2.2/controls/rt: [TEST ONLY] remove @ignore for some chart tests - they pass now. Message-ID: <20120628175003.2041647B96@hg.openjdk.java.net> Changeset: d20976d5d10f Author: Paru Somashekar Date: 2012-06-28 10:34 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/d20976d5d10f [TEST ONLY] remove @ignore for some chart tests - they pass now. ! javafx-ui-charts/test/javafx/scene/chart/StackedAreaChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/StackedBarChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/XYChartTest.java From hang.vo at oracle.com Thu Jun 28 14:48:22 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 28 Jun 2012 21:48:22 +0000 Subject: hg: openjfx/2.2/controls/rt: 8 new changesets Message-ID: <20120628214830.8C1B147BAD@hg.openjdk.java.net> Changeset: 9ed69f9a93bb Author: jgiles Date: 2012-06-27 16:03 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/9ed69f9a93bb [DOC ONLY] Update to cells package documentation. ! javafx-ui-controls/src/javafx/scene/control/cell/package.html Changeset: a42d594cef37 Author: jgiles Date: 2012-06-29 09:37 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/a42d594cef37 RT-22676: Embedded: Ensemble sample throws an exception ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java Changeset: 4484722efef7 Author: jgiles Date: 2012-06-29 09:39 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/4484722efef7 RT-2295: Non-editable ComboBox does not show prompt text when it should ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 0d6d4249cce9 Author: jgiles Date: 2012-06-29 09:40 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/0d6d4249cce9 RT-22908: Column width of data rows does not align with header column width ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java Changeset: d17e7e409769 Author: jgiles Date: 2012-06-29 09:40 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/d17e7e409769 RT-22875: CheckBoxTreeItem: indeterminate state does not affect rendering ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeCell.java Changeset: 480b6f9324a7 Author: jgiles Date: 2012-06-29 09:43 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/480b6f9324a7 RT-22954: PieChart with rollover has picking issues ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java Changeset: a81a3544722e Author: jgiles Date: 2012-06-29 09:43 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/a81a3544722e Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 29a0e209d81f Author: jgiles Date: 2012-06-29 09:43 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/29a0e209d81f RT-22937: Selection issue on editors based on ComboBox with dynamic item list ! javafx-ui-controls/src/javafx/scene/control/ComboBox.java From hang.vo at oracle.com Thu Jun 28 15:03:31 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 28 Jun 2012 22:03:31 +0000 Subject: hg: openjfx/2.2/controls/rt: 4 new changesets Message-ID: <20120628220335.2412347BAF@hg.openjdk.java.net> Changeset: 2d7d2be9cdb7 Author: Kinsley Wong Date: 2012-06-28 14:45 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/2d7d2be9cdb7 RT-22928: ClassCastException in TilePane while using the CSS style -fx-pref-columns ! javafx-ui-common/src/javafx/scene/layout/TilePane.java ! javafx-ui-common/test/unit/javafx/scene/layout/TilePaneTest.java Changeset: feb33f9ce89b Author: Kinsley Wong Date: 2012-06-28 14:48 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/feb33f9ce89b RT-22925: When closing a Tab inside a TabPane, the selection model does not return the correct Tab. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TabPaneBehavior.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java Changeset: f90f6b0e27a4 Author: jgiles Date: 2012-06-29 09:47 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/f90f6b0e27a4 RT-22076: CSS: Treat style class as a bit mask in Selector for better performance on selector matching. ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java Changeset: 90b96294241a Author: jgiles Date: 2012-06-29 09:49 +1200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/90b96294241a Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt From hang.vo at oracle.com Thu Jun 28 17:04:12 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 29 Jun 2012 00:04:12 +0000 Subject: hg: openjfx/2.2/controls/rt: 2 new changesets Message-ID: <20120629000414.53CC447BB2@hg.openjdk.java.net> Changeset: 68f2523b8433 Author: David Grieve Date: 2012-06-28 18:21 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/68f2523b8433 RT-22076: backout patch pushed by jgiles in favor of updated patch ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java Changeset: 29a95b63c732 Author: David Grieve Date: 2012-06-28 18:21 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/29a95b63c732 RT-22076: create a bitmask from style class strings to speed up SimpleSelector.isSubsetOf method. ! javafx-ui-common/src/com/sun/javafx/css/CompoundSelector.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Selector.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/com/sun/javafx/css/RuleTest.java From hang.vo at oracle.com Fri Jun 29 10:34:14 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 29 Jun 2012 17:34:14 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-22565: parent stylesheets may be in the default stylesheet container Message-ID: <20120629173417.5487247BEF@hg.openjdk.java.net> Changeset: ad5af91935ff Author: David Grieve Date: 2012-06-29 13:18 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/ad5af91935ff RT-22565: parent stylesheets may be in the default stylesheet container ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/scene/Parent.java