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 i