From artem.ananiev at oracle.com Mon Apr 2 04:03:10 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 02 Apr 2012 15:03:10 +0400 Subject: Thoughts on Dialogs and Lightboxes In-Reply-To: <23FAF474-5275-499E-9763-89C4DFDB84B5@gmail.com> References: <23FAF474-5275-499E-9763-89C4DFDB84B5@gmail.com> Message-ID: <4F79876E.3020509@oracle.com> Hi, Daniel, On 3/31/2012 7:50 AM, Daniel Zwolenski wrote: > I'm curious what the plans are for Dialogs in JavaFX. I assume they are on the roadmap? both dialogs (owned windows) and modality are already there: javafx.stage.Stage#initOwner() javafx.stage.Stage#initModality() > I notice hints of this from Jonathon here: http://javafx-jira.kenai.com/browse/RT-12643 This issue is about having the Alert class, which is similar to Swing's JOptionPane, Windows' MessageBox and similar dialogs in other UI toolkits. You can implement it yourself, however this functionality is common enough to be a standard JFX class. > But I see the request is as yet unresolved. > > The reason I ask is because I've had to implement my own 'Lightbox' framework for my last project and I'm wondering if some part of this or something similar should be in JFX. I know a lot of people on the forums have been looking for classic dialog support from JFX. > > If you don't know already, a Lightbox is the web's answer to Dialogs, where a dialog-like pane is layered on top of the main content with a semi-transparent glass pane making it basically modal. The dialog is still within the main browser window, so it's not a true Popup but to the user is much the same. > > The end result looks like this: > > http://okonet.ru/projects/modalbox/images/screenshot.jpg This is a screenshot with Mac OS X "sheet", which is not what is usually referred to as "Dialog". It's not a separate top-level window. Other platforms don't have built-in support for such UI elements. > It is quite easy to implement this in JFX using a StackPane as the base. The simple API is just to have some kind of LightboxPane (or RootPane, etc) that extends StackPane and includes a method like: > > showInLightbox(Node node) > > This then adds a 'glass pane' to the top of the Stack to dim out the content, and then adds the node to this glass pane. The node's visibility could be tracked to determine when to remove the glass pane, etc. > > The API can be extended beyond this simple setup quite drastically to include things like decorated boxes (title bar, close button, resize edges, etc), animated entry/exit, and 'dialog options' such as ok, cancel (ie JOptionPane like functions). > > My stuff needs cleaning up but I was planning to eventually roll my framework into JFX Flow. If it's on the JFX roadmap anyway, better not to, or at least I'd like the API to mirror JFX Dialogs if possible. > > Thoughts and comments? If you're asking about support for Mac OS X "sheets", please, file a separate JIRA issue about this (I don't know if we already have this request in FX bug database), as it is completely separate from RT-12643. Thanks, Artem From steve at winnall.ch Mon Apr 2 04:55:59 2012 From: steve at winnall.ch (Stephen Winnall) Date: Mon, 2 Apr 2012 13:55:59 +0200 Subject: Thoughts on Dialogs and Lightboxes In-Reply-To: <4F79876E.3020509@oracle.com> References: <23FAF474-5275-499E-9763-89C4DFDB84B5@gmail.com> <4F79876E.3020509@oracle.com> Message-ID: <55C010F5-787F-4C70-9EAC-BD2E97B943D2@winnall.ch> Hi Artem I'm concerned that dialogues should be possible with sheets on the Mac, so I've submitted a JIRA issue as you suggest (RT-20744). Cheers Steve On 2 Apr 2012, at 13:03, Artem Ananiev wrote: > Hi, Daniel, > > On 3/31/2012 7:50 AM, Daniel Zwolenski wrote: >> I'm curious what the plans are for Dialogs in JavaFX. I assume they are on the roadmap? > > both dialogs (owned windows) and modality are already there: > > javafx.stage.Stage#initOwner() > javafx.stage.Stage#initModality() > >> I notice hints of this from Jonathon here: http://javafx-jira.kenai.com/browse/RT-12643 > > This issue is about having the Alert class, which is similar to Swing's JOptionPane, Windows' MessageBox and similar dialogs in other UI toolkits. You can implement it yourself, however this functionality is common enough to be a standard JFX class. > >> But I see the request is as yet unresolved. >> >> The reason I ask is because I've had to implement my own 'Lightbox' framework for my last project and I'm wondering if some part of this or something similar should be in JFX. I know a lot of people on the forums have been looking for classic dialog support from JFX. >> >> If you don't know already, a Lightbox is the web's answer to Dialogs, where a dialog-like pane is layered on top of the main content with a semi-transparent glass pane making it basically modal. The dialog is still within the main browser window, so it's not a true Popup but to the user is much the same. >> >> The end result looks like this: >> >> http://okonet.ru/projects/modalbox/images/screenshot.jpg > > This is a screenshot with Mac OS X "sheet", which is not what is usually referred to as "Dialog". It's not a separate top-level window. Other platforms don't have built-in support for such UI elements. > >> It is quite easy to implement this in JFX using a StackPane as the base. The simple API is just to have some kind of LightboxPane (or RootPane, etc) that extends StackPane and includes a method like: >> >> showInLightbox(Node node) >> >> This then adds a 'glass pane' to the top of the Stack to dim out the content, and then adds the node to this glass pane. The node's visibility could be tracked to determine when to remove the glass pane, etc. >> >> The API can be extended beyond this simple setup quite drastically to include things like decorated boxes (title bar, close button, resize edges, etc), animated entry/exit, and 'dialog options' such as ok, cancel (ie JOptionPane like functions). >> >> My stuff needs cleaning up but I was planning to eventually roll my framework into JFX Flow. If it's on the JFX roadmap anyway, better not to, or at least I'd like the API to mirror JFX Dialogs if possible. >> >> Thoughts and comments? > > If you're asking about support for Mac OS X "sheets", please, file a separate JIRA issue about this (I don't know if we already have this request in FX bug database), as it is completely separate from RT-12643. > > Thanks, > > Artem From hang.vo at oracle.com Mon Apr 2 07:03:22 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 02 Apr 2012 14:03:22 +0000 Subject: hg: openjfx/2.2/graphics/rt: Removed unused import. Message-ID: <20120402140324.E8CCB47C8F@hg.openjdk.java.net> Changeset: 94e9b5588ae7 Author: Pavel Safrata Date: 2012-04-02 15:50 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/94e9b5588ae7 Removed unused import. ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java From hang.vo at oracle.com Mon Apr 2 10:32:11 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 02 Apr 2012 17:32:11 +0000 Subject: hg: openjfx/2.2/controls/rt: 18 new changesets Message-ID: <20120402173226.BD81447C9F@hg.openjdk.java.net> Changeset: 4d1d81b2c178 Author: hudson Date: 2012-03-28 12:38 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/4d1d81b2c178 Added tag 2.1-b20 for changeset b07470e9d56e ! .hgtags Changeset: 2e013bdbf6b9 Author: kcr Date: 2012-03-29 15:10 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/2e013bdbf6b9 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.1/MASTER/jfx/rt ! .hgtags Changeset: 06d28cb315ef Author: Martin Sladecek Date: 2012-03-27 11:22 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/06d28cb315ef RT-19173: TODO cleanup ! javafx-ui-common/src/javafx/scene/shape/Path.java ! javafx-ui-common/src/javafx/scene/shape/Rectangle.java ! javafx-ui-common/src/javafx/scene/shape/Shape.java Changeset: 503177e32885 Author: Martin Sladecek Date: 2012-03-27 13:11 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/503177e32885 RT-19169: TODO evaluation & cleanup ! javafx-ui-common/src/javafx/scene/Parent.java Changeset: 761f5394140f Author: Martin Sladecek Date: 2012-03-27 14:14 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/761f5394140f RT-19166: TODOs evaluation & cleanup. ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/DragEvent.java ! javafx-ui-common/src/javafx/scene/input/Dragboard.java Changeset: dd7676637b7f Author: Martin Sladecek Date: 2012-03-27 14:23 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/dd7676637b7f RT-19170: TODOs evaluation & cleanup ! javafx-ui-common/src/javafx/stage/PopupWindow.java ! javafx-ui-common/src/javafx/stage/Stage.java Changeset: 0cca9d649695 Author: Martin Sladecek Date: 2012-03-27 14:57 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/0cca9d649695 RT-19167: TODOs evaluation & cleanup. ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 484062ad6dda Author: Martin Sladecek Date: 2012-03-27 14:59 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/484062ad6dda Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/graphics/jfx/rt ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/stage/Stage.java Changeset: c4b198f66b4c Author: Lubomir Nerad Date: 2012-03-27 17:37 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/c4b198f66b4c Partial RT-19320: removed obsolete code ! javafx-ui-common/src/com/sun/javafx/stage/PopupWindowPeerListener.java Changeset: ba369f618738 Author: prr Date: 2012-03-28 09:14 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/ba369f618738 Fixed RT-13735: Render tree is modified during Text bounds calculation ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java - javafx-ui-common/src/com/sun/javafx/tk/TextHelper.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/test/unit/com/sun/javafx/pgstub/StubToolkit.java ! javafx-ui-common/test/unit/javafx/scene/text/TextTest.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubText.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextHelper.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: 085fcfbba269 Author: kcr Date: 2012-03-28 11:51 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/085fcfbba269 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt - javafx-ui-common/src/com/sun/javafx/tk/TextHelper.java ! javafx-ui-common/src/javafx/scene/Parent.java Changeset: edba48bc0a1c Author: prr Date: 2012-03-28 12:32 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/edba48bc0a1c Fixed RT-20617: Reformat very long lines in Text.java ! javafx-ui-common/src/javafx/scene/text/Text.java Changeset: 8076e4db0d6a Author: Pavel Safrata Date: 2012-03-29 08:33 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/8076e4db0d6a RT-20696: fixed code sample in documentation. ! javafx-ui-common/src/javafx/scene/package.html Changeset: d0b8ead187d2 Author: Lubomir Nerad Date: 2012-03-29 16:41 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/d0b8ead187d2 Fix for RT-20179: Gtk: Window.centerOnScreen synchronization problems ! javafx-ui-common/src/com/sun/javafx/tk/TKStage.java ! javafx-ui-common/src/javafx/stage/Window.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubStage.java Changeset: 412f8e73634c Author: kcr Date: 2012-03-29 16:04 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/412f8e73634c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt - javafx-ui-common/src/com/sun/javafx/tk/TextHelper.java Changeset: 0616970d62e6 Author: kcr Date: 2012-03-29 18:28 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/0616970d62e6 RT-19825: Contribution of Working Maven 3.0 Build For openjfx hg Source Contributed-By: Adam Bien Reviewed-By: kcr ! .hgignore ! .idea/misc.xml + javafx-beans-dt/pom.xml + javafx-concurrent/pom.xml + javafx-designtime/pom.xml + javafx-ueber-jar/pom.xml + javafx-ui-common/pom.xml + javafx-ui-controls/pom.xml + nbactions-javafx.xml + pom.xml + test-stub-toolkit/pom.xml Changeset: 474801a028b9 Author: Pavel Safrata Date: 2012-03-30 10:06 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/474801a028b9 RT-20648: removed impl_syncPGNodeDirect(). ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/javafx/scene/Parent_structure_sync_Test.java Changeset: 1ba55d2ecc03 Author: leifs Date: 2012-04-02 10:10 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/1ba55d2ecc03 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/Scene.java From jonathan.giles at oracle.com Mon Apr 2 13:24:24 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 03 Apr 2012 05:24:24 +0900 Subject: Thoughts on Dialogs and Lightboxes In-Reply-To: <4F79876E.3020509@oracle.com> References: <23FAF474-5275-499E-9763-89C4DFDB84B5@gmail.com> <4F79876E.3020509@oracle.com> Message-ID: <4F7A0AF8.7030005@oracle.com> I'm coming to this discussion late as I've been travelling - sorry about that. As Dan mentions, I have a JOptionPane-esque API already. For those with access to rt-closed, it is in toys/dialogs. It is basically a fork of the JavaFX security dialog you may have seen elsewhere, with API similar to what you'd see in JOptionPane, and a whole lot of unnecessary code ripped out. It is fairly well developed and quite a long way along, and certainly usable. I have been pushing the relevant people to include this in a release, or at least the same concept of this, but as of yet I have not had success. This is most probably just due to the fact that there are more important fish to fry, and as Artem notes, the API is all there to make a modal window, and there is impl_ API (which you should never use!) to make a stage blocking. I have not done any work along the sheet approach, as this requires further support in the glass API, and this is where Artem would step in. -- Jonathan On 2/04/2012 8:03 p.m., Artem Ananiev wrote: > Hi, Daniel, > > On 3/31/2012 7:50 AM, Daniel Zwolenski wrote: >> I'm curious what the plans are for Dialogs in JavaFX. I assume they >> are on the roadmap? > > both dialogs (owned windows) and modality are already there: > > javafx.stage.Stage#initOwner() > javafx.stage.Stage#initModality() > >> I notice hints of this from Jonathon here: >> http://javafx-jira.kenai.com/browse/RT-12643 > > This issue is about having the Alert class, which is similar to > Swing's JOptionPane, Windows' MessageBox and similar dialogs in other > UI toolkits. You can implement it yourself, however this functionality > is common enough to be a standard JFX class. > >> But I see the request is as yet unresolved. >> >> The reason I ask is because I've had to implement my own 'Lightbox' >> framework for my last project and I'm wondering if some part of this >> or something similar should be in JFX. I know a lot of people on the >> forums have been looking for classic dialog support from JFX. >> >> If you don't know already, a Lightbox is the web's answer to Dialogs, >> where a dialog-like pane is layered on top of the main content with a >> semi-transparent glass pane making it basically modal. The dialog is >> still within the main browser window, so it's not a true Popup but to >> the user is much the same. >> >> The end result looks like this: >> >> http://okonet.ru/projects/modalbox/images/screenshot.jpg > > This is a screenshot with Mac OS X "sheet", which is not what is > usually referred to as "Dialog". It's not a separate top-level window. > Other platforms don't have built-in support for such UI elements. > >> It is quite easy to implement this in JFX using a StackPane as the >> base. The simple API is just to have some kind of LightboxPane (or >> RootPane, etc) that extends StackPane and includes a method like: >> >> showInLightbox(Node node) >> >> This then adds a 'glass pane' to the top of the Stack to dim out the >> content, and then adds the node to this glass pane. The node's >> visibility could be tracked to determine when to remove the glass >> pane, etc. >> >> The API can be extended beyond this simple setup quite drastically to >> include things like decorated boxes (title bar, close button, resize >> edges, etc), animated entry/exit, and 'dialog options' such as ok, >> cancel (ie JOptionPane like functions). >> >> My stuff needs cleaning up but I was planning to eventually roll my >> framework into JFX Flow. If it's on the JFX roadmap anyway, better >> not to, or at least I'd like the API to mirror JFX Dialogs if possible. >> >> Thoughts and comments? > > If you're asking about support for Mac OS X "sheets", please, file a > separate JIRA issue about this (I don't know if we already have this > request in FX bug database), as it is completely separate from RT-12643. > > Thanks, > > Artem From kevin.rushforth at oracle.com Mon Apr 2 13:55:56 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 02 Apr 2012 13:55:56 -0700 Subject: Thoughts on Dialogs and Lightboxes In-Reply-To: <4F7A0AF8.7030005@oracle.com> References: <23FAF474-5275-499E-9763-89C4DFDB84B5@gmail.com> <4F79876E.3020509@oracle.com> <4F7A0AF8.7030005@oracle.com> Message-ID: <4F7A125C.2070208@oracle.com> Note that a public method to allow a blocking modal dialog is planned for 2.2: http://javafx-jira.kenai.com/browse/RT-19783 -- Kevin Jonathan Giles wrote: > I'm coming to this discussion late as I've been travelling - sorry > about that. As Dan mentions, I have a JOptionPane-esque API already. > For those with access to rt-closed, it is in toys/dialogs. It is > basically a fork of the JavaFX security dialog you may have seen > elsewhere, with API similar to what you'd see in JOptionPane, and a > whole lot of unnecessary code ripped out. It is fairly well developed > and quite a long way along, and certainly usable. I have been pushing > the relevant people to include this in a release, or at least the same > concept of this, but as of yet I have not had success. This is most > probably just due to the fact that there are more important fish to > fry, and as Artem notes, the API is all there to make a modal window, > and there is impl_ API (which you should never use!) to make a stage > blocking. > > I have not done any work along the sheet approach, as this requires > further support in the glass API, and this is where Artem would step in. > > -- Jonathan > > > On 2/04/2012 8:03 p.m., Artem Ananiev wrote: >> Hi, Daniel, >> >> On 3/31/2012 7:50 AM, Daniel Zwolenski wrote: >>> I'm curious what the plans are for Dialogs in JavaFX. I assume they >>> are on the roadmap? >> >> both dialogs (owned windows) and modality are already there: >> >> javafx.stage.Stage#initOwner() >> javafx.stage.Stage#initModality() >> >>> I notice hints of this from Jonathon here: >>> http://javafx-jira.kenai.com/browse/RT-12643 >> >> This issue is about having the Alert class, which is similar to >> Swing's JOptionPane, Windows' MessageBox and similar dialogs in other >> UI toolkits. You can implement it yourself, however this >> functionality is common enough to be a standard JFX class. >> >>> But I see the request is as yet unresolved. >>> >>> The reason I ask is because I've had to implement my own 'Lightbox' >>> framework for my last project and I'm wondering if some part of this >>> or something similar should be in JFX. I know a lot of people on the >>> forums have been looking for classic dialog support from JFX. >>> >>> If you don't know already, a Lightbox is the web's answer to >>> Dialogs, where a dialog-like pane is layered on top of the main >>> content with a semi-transparent glass pane making it basically >>> modal. The dialog is still within the main browser window, so it's >>> not a true Popup but to the user is much the same. >>> >>> The end result looks like this: >>> >>> http://okonet.ru/projects/modalbox/images/screenshot.jpg >> >> This is a screenshot with Mac OS X "sheet", which is not what is >> usually referred to as "Dialog". It's not a separate top-level >> window. Other platforms don't have built-in support for such UI >> elements. >> >>> It is quite easy to implement this in JFX using a StackPane as the >>> base. The simple API is just to have some kind of LightboxPane (or >>> RootPane, etc) that extends StackPane and includes a method like: >>> >>> showInLightbox(Node node) >>> >>> This then adds a 'glass pane' to the top of the Stack to dim out the >>> content, and then adds the node to this glass pane. The node's >>> visibility could be tracked to determine when to remove the glass >>> pane, etc. >>> >>> The API can be extended beyond this simple setup quite drastically >>> to include things like decorated boxes (title bar, close button, >>> resize edges, etc), animated entry/exit, and 'dialog options' such >>> as ok, cancel (ie JOptionPane like functions). >>> >>> My stuff needs cleaning up but I was planning to eventually roll my >>> framework into JFX Flow. If it's on the JFX roadmap anyway, better >>> not to, or at least I'd like the API to mirror JFX Dialogs if possible. >>> >>> Thoughts and comments? >> >> If you're asking about support for Mac OS X "sheets", please, file a >> separate JIRA issue about this (I don't know if we already have this >> request in FX bug database), as it is completely separate from RT-12643. >> >> Thanks, >> >> Artem From hang.vo at oracle.com Mon Apr 2 15:47:26 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 02 Apr 2012 22:47:26 +0000 Subject: hg: openjfx/2.2/controls/rt: fix RT-20720 NPE when removing last item in series in AreaChart Message-ID: <20120402224728.F2DFB47CD3@hg.openjdk.java.net> Changeset: 4889b4deb45e Author: Paru Somashekar Date: 2012-04-02 15:39 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/4889b4deb45e fix RT-20720 NPE when removing last item in series in AreaChart ! javafx-ui-charts/src/javafx/scene/chart/AreaChart.java From hang.vo at oracle.com Mon Apr 2 17:17:19 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Apr 2012 00:17:19 +0000 Subject: hg: openjfx/2.2/controls/rt: 6 new changesets Message-ID: <20120403001723.AC08A47CD5@hg.openjdk.java.net> Changeset: 05f86cff4777 Author: Kinsley Wong Date: 2012-03-30 11:55 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/05f86cff4777 Pagination: css cleanup ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: b421b3cdc003 Author: Kinsley Wong Date: 2012-04-02 16:54 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/b421b3cdc003 Pagination: include node size when computing pref width and height ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationCellSkin.java Changeset: b9dde81dbee6 Author: Kinsley Wong Date: 2012-04-02 16:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/b9dde81dbee6 Pagination: correctly compute the total number of pages and scroll pages using offsets. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 8909d2df17f0 Author: Kinsley Wong Date: 2012-04-02 16:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/8909d2df17f0 Pagination: css cleanup. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: ee1093741bde Author: Kinsley Wong Date: 2012-04-02 17:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/ee1093741bde Pagination: allowing scrolling to an offset. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualContainerBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 33eee41df3bd Author: Kinsley Wong Date: 2012-04-02 17:10 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/33eee41df3bd merge - javafx-ui-common/src/com/sun/javafx/tk/TextHelper.java From hang.vo at oracle.com Mon Apr 2 17:47:32 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Apr 2012 00:47:32 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-20686: -fx-font-smoothing-type: gray; does not parse. Parser sees "gray" as a color. Message-ID: <20120403004732.D5BF047CD6@hg.openjdk.java.net> Changeset: e08f86fc5989 Author: David Grieve Date: 2012-04-02 20:39 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/e08f86fc5989 RT-20686: -fx-font-smoothing-type: gray; does not parse. Parser sees "gray" as a color. ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest_AUTHOR.css ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest_UA.css ! javafx-ui-common/test/unit/javafx/scene/text/Text_cssMethods_Test.java From hang.vo at oracle.com Tue Apr 3 08:03:27 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Apr 2012 15:03:27 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-20210: A StyleHelper might not have been gc'd so the referent might not have been cleared before the Reference is used by code that relies on the reference being cleared as soon as the StyleHelper becomes invalid and not when the StyleHelper is gc'd. Message-ID: <20120403150329.8602F47D01@hg.openjdk.java.net> Changeset: ae28effcfa79 Author: David Grieve Date: 2012-04-03 10:51 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/ae28effcfa79 RT-20210: A StyleHelper might not have been gc'd so the referent might not have been cleared before the Reference is used by code that relies on the reference being cleared as soon as the StyleHelper becomes invalid and not when the StyleHelper is gc'd. ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java From hang.vo at oracle.com Tue Apr 3 10:48:19 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Apr 2012 17:48:19 +0000 Subject: hg: openjfx/2.2/graphics/rt: Fixed RT_20730: Unused variables in Text node Message-ID: <20120403174821.2E9FA47D18@hg.openjdk.java.net> Changeset: a5402446058e Author: prr Date: 2012-04-03 10:36 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a5402446058e Fixed RT_20730: Unused variables in Text node ! javafx-ui-common/src/javafx/scene/text/Text.java From hang.vo at oracle.com Tue Apr 3 13:49:35 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 03 Apr 2012 20:49:35 +0000 Subject: hg: openjfx/2.2/master/rt: 30 new changesets Message-ID: <20120403204958.7286747D21@hg.openjdk.java.net> Changeset: 1b875b2061a0 Author: Kinsley Wong Date: 2012-03-20 11:23 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/1b875b2061a0 [DOC-ONLY] RT-16310: javafx.scene.control.TableView: tableView inside of TilePane/FlowPane should be resized to keep inside the borders of pane ! javafx-ui-common/src/javafx/scene/layout/TilePane.java Changeset: 1bc5b548b5f5 Author: Kinsley Wong Date: 2012-03-20 14:12 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/1bc5b548b5f5 [DOC-ONLY] RT-20490: Region javadoc nees links. ! javafx-ui-common/src/javafx/scene/layout/Region.java Changeset: 4703f60525c5 Author: David Grieve Date: 2012-03-23 13:39 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/4703f60525c5 branch merge Changeset: 3f8024091f63 Author: David Grieve Date: 2012-03-23 13:30 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/3f8024091f63 RT-20513: optimization in inherit bypasses font lookup ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest.java Changeset: e1dc3a64d8c9 Author: David Grieve Date: 2012-03-23 13:39 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/e1dc3a64d8c9 branch merge Changeset: 380ad2619f75 Author: David Grieve Date: 2012-03-26 10:27 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/380ad2619f75 [DOCS-ONLY] RT-19807: minor corrections to cssref.html ! javafx-ui-common/src/javafx/scene/doc-files/cssref.html Changeset: cabf09d667e8 Author: David Grieve Date: 2012-03-26 11:27 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/cabf09d667e8 branch merge Changeset: c89ddb85192d Author: kcr Date: 2012-03-20 13:59 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/c89ddb85192d [DOC-ONLY] RT-19900: Window javadoc refers to some menu ! javafx-ui-common/src/javafx/stage/Window.java Changeset: 27d63ead743a Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-03-21 14:32 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/27d63ead743a Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/2.1/MASTER/jfx//rt Changeset: 37d21fdd9285 Author: kcr Date: 2012-03-26 14:51 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/37d21fdd9285 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.1/MASTER/jfx/rt Changeset: b07470e9d56e Author: hudson Date: 2012-03-27 17:12 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/b07470e9d56e Added tag 2.1-b19 for changeset 37d21fdd9285 ! .hgtags Changeset: dc9b910d1e55 Author: kcr Date: 2012-03-28 06:36 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/dc9b910d1e55 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.1/MASTER/jfx/rt ! .hgtags ! javafx-ui-common/src/javafx/stage/Window.java Changeset: 4d1d81b2c178 Author: hudson Date: 2012-03-28 12:38 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/4d1d81b2c178 Added tag 2.1-b20 for changeset b07470e9d56e ! .hgtags Changeset: 2e013bdbf6b9 Author: kcr Date: 2012-03-29 15:10 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/2e013bdbf6b9 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.1/MASTER/jfx/rt ! .hgtags Changeset: 06d28cb315ef Author: Martin Sladecek Date: 2012-03-27 11:22 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/06d28cb315ef RT-19173: TODO cleanup ! javafx-ui-common/src/javafx/scene/shape/Path.java ! javafx-ui-common/src/javafx/scene/shape/Rectangle.java ! javafx-ui-common/src/javafx/scene/shape/Shape.java Changeset: 503177e32885 Author: Martin Sladecek Date: 2012-03-27 13:11 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/503177e32885 RT-19169: TODO evaluation & cleanup ! javafx-ui-common/src/javafx/scene/Parent.java Changeset: 761f5394140f Author: Martin Sladecek Date: 2012-03-27 14:14 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/761f5394140f RT-19166: TODOs evaluation & cleanup. ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/DragEvent.java ! javafx-ui-common/src/javafx/scene/input/Dragboard.java Changeset: dd7676637b7f Author: Martin Sladecek Date: 2012-03-27 14:23 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/dd7676637b7f RT-19170: TODOs evaluation & cleanup ! javafx-ui-common/src/javafx/stage/PopupWindow.java ! javafx-ui-common/src/javafx/stage/Stage.java Changeset: 0cca9d649695 Author: Martin Sladecek Date: 2012-03-27 14:57 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/0cca9d649695 RT-19167: TODOs evaluation & cleanup. ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 484062ad6dda Author: Martin Sladecek Date: 2012-03-27 14:59 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/484062ad6dda Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/graphics/jfx/rt ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/stage/Stage.java Changeset: c4b198f66b4c Author: Lubomir Nerad Date: 2012-03-27 17:37 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/c4b198f66b4c Partial RT-19320: removed obsolete code ! javafx-ui-common/src/com/sun/javafx/stage/PopupWindowPeerListener.java Changeset: ba369f618738 Author: prr Date: 2012-03-28 09:14 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/ba369f618738 Fixed RT-13735: Render tree is modified during Text bounds calculation ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java - javafx-ui-common/src/com/sun/javafx/tk/TextHelper.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/test/unit/com/sun/javafx/pgstub/StubToolkit.java ! javafx-ui-common/test/unit/javafx/scene/text/TextTest.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubText.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextHelper.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: 085fcfbba269 Author: kcr Date: 2012-03-28 11:51 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/085fcfbba269 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt - javafx-ui-common/src/com/sun/javafx/tk/TextHelper.java ! javafx-ui-common/src/javafx/scene/Parent.java Changeset: edba48bc0a1c Author: prr Date: 2012-03-28 12:32 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/edba48bc0a1c Fixed RT-20617: Reformat very long lines in Text.java ! javafx-ui-common/src/javafx/scene/text/Text.java Changeset: 8076e4db0d6a Author: Pavel Safrata Date: 2012-03-29 08:33 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/8076e4db0d6a RT-20696: fixed code sample in documentation. ! javafx-ui-common/src/javafx/scene/package.html Changeset: d0b8ead187d2 Author: Lubomir Nerad Date: 2012-03-29 16:41 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/d0b8ead187d2 Fix for RT-20179: Gtk: Window.centerOnScreen synchronization problems ! javafx-ui-common/src/com/sun/javafx/tk/TKStage.java ! javafx-ui-common/src/javafx/stage/Window.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubStage.java Changeset: 412f8e73634c Author: kcr Date: 2012-03-29 16:04 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/412f8e73634c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt - javafx-ui-common/src/com/sun/javafx/tk/TextHelper.java Changeset: 0616970d62e6 Author: kcr Date: 2012-03-29 18:28 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/0616970d62e6 RT-19825: Contribution of Working Maven 3.0 Build For openjfx hg Source Contributed-By: Adam Bien Reviewed-By: kcr ! .hgignore ! .idea/misc.xml + javafx-beans-dt/pom.xml + javafx-concurrent/pom.xml + javafx-designtime/pom.xml + javafx-ueber-jar/pom.xml + javafx-ui-common/pom.xml + javafx-ui-controls/pom.xml + nbactions-javafx.xml + pom.xml + test-stub-toolkit/pom.xml Changeset: 474801a028b9 Author: Pavel Safrata Date: 2012-03-30 10:06 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/474801a028b9 RT-20648: removed impl_syncPGNodeDirect(). ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/test/unit/javafx/scene/Parent_structure_sync_Test.java Changeset: cebb10de0795 Author: hudson Date: 2012-04-03 13:44 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/cebb10de0795 Added tag 2.2-b03 for changeset 474801a028b9 ! .hgtags From hang.vo at oracle.com Wed Apr 4 01:34:15 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Apr 2012 08:34:15 +0000 Subject: hg: openjfx/2.2/graphics/rt: Fix for RT-20654, RT-20655: Image arguments validation Message-ID: <20120404083417.831B547D5E@hg.openjdk.java.net> Changeset: dcdd0ac56ce4 Author: Lubomir Nerad Date: 2012-04-04 10:22 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/dcdd0ac56ce4 Fix for RT-20654, RT-20655: Image arguments validation ! javafx-ui-common/src/javafx/scene/image/Image.java ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/test/unit/javafx/scene/image/ImageTest.java From hang.vo at oracle.com Wed Apr 4 04:48:48 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Apr 2012 11:48:48 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-16144 - ScrollBar: space between buttons has another width than buttons Message-ID: <20120404114850.7D29147D64@hg.openjdk.java.net> Changeset: 137908962b46 Author: mickf Date: 2012-04-04 12:41 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/137908962b46 RT-16144 - ScrollBar: space between buttons has another width than buttons ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ScrollPaneSkinTest.java From hang.vo at oracle.com Wed Apr 4 11:48:26 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Apr 2012 18:48:26 +0000 Subject: hg: openjfx/2.2/controls/rt: JAVADOC RT-20490 Region javadoc needs links. Message-ID: <20120404184827.D503047DA1@hg.openjdk.java.net> Changeset: 60861984b3f7 Author: Kinsley Wong Date: 2012-04-04 11:44 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/60861984b3f7 JAVADOC RT-20490 Region javadoc needs links. ! javafx-ui-common/src/javafx/scene/layout/Region.java From hang.vo at oracle.com Wed Apr 4 13:03:44 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Apr 2012 20:03:44 +0000 Subject: hg: openjfx/2.2/controls/rt: Pagination: add support for left and right key presses. Message-ID: <20120404200346.0CBCD47DB5@hg.openjdk.java.net> Changeset: 7d435026b5fe Author: Kinsley Wong Date: 2012-04-04 12:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/7d435026b5fe Pagination: add support for left and right key presses. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/PaginationBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css From hang.vo at oracle.com Wed Apr 4 15:17:55 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 04 Apr 2012 22:17:55 +0000 Subject: hg: openjfx/2.2/controls/rt: Pagination: do not use any of list-cell styles for pagination-cell. Message-ID: <20120404221756.94FBB47DE0@hg.openjdk.java.net> Changeset: abd899c37f61 Author: Kinsley Wong Date: 2012-04-04 15:03 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/abd899c37f61 Pagination: do not use any of list-cell styles for pagination-cell. ! javafx-ui-controls/src/com/sun/javafx/scene/control/PaginationCell.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java From hang.vo at oracle.com Wed Apr 4 23:03:45 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 05 Apr 2012 06:03:45 +0000 Subject: hg: openjfx/2.2/controls/rt: FXVK: Virtual keyboard layouts now defined in resource file Message-ID: <20120405060347.EF33847DFD@hg.openjdk.java.net> Changeset: 12bba27d5557 Author: leifs Date: 2012-04-04 22:51 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/12bba27d5557 FXVK: Virtual keyboard layouts now defined in resource file ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVK.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKCharEntities.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls.properties ! javafx-ui-controls/src/javafx/scene/control/TextInputControl.java From fbrunnerlist at gmx.ch Thu Apr 5 08:50:13 2012 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Thu, 5 Apr 2012 17:50:13 +0200 Subject: Patch: issue RT-14177 Message-ID: <201204051750.13667.fbrunnerlist@gmx.ch> 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 kevin.rushforth at oracle.com Thu Apr 5 09:54:38 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 05 Apr 2012 09:54:38 -0700 Subject: Patch: issue RT-14177 In-Reply-To: <201204051750.13667.fbrunnerlist@gmx.ch> References: <201204051750.13667.fbrunnerlist@gmx.ch> Message-ID: <4F7DCE4E.8090905@oracle.com> 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 Thu Apr 5 10:03:51 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 05 Apr 2012 17:03:51 +0000 Subject: hg: openjfx/2.2/controls/rt: 2 new changesets Message-ID: <20120405170353.B4B9D47E38@hg.openjdk.java.net> Changeset: cebb10de0795 Author: hudson Date: 2012-04-03 13:44 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/cebb10de0795 Added tag 2.2-b03 for changeset 474801a028b9 ! .hgtags Changeset: 15b9d61a37a9 Author: leifs Date: 2012-04-05 09:48 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/15b9d61a37a9 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt From kevin.rushforth at oracle.com Thu Apr 5 12:20:09 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 05 Apr 2012 12:20:09 -0700 Subject: JavaFX 2.2 early access builds are now available on the OTN download site Message-ID: <4F7DF069.6030009@oracle.com> http://www.oracle.com/technetwork/java/javafx/downloads/devpreview-1429449.html This will enable developers to build openjfx 2.2 again. -- Kevin From hang.vo at oracle.com Thu Apr 5 12:58:59 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 05 Apr 2012 19:58:59 +0000 Subject: hg: openjfx/2.1/master/rt: Added tag 2.1-b21 for changeset 4d1d81b2c178 Message-ID: <20120405195900.E24E847E41@hg.openjdk.java.net> Changeset: 5c3b3d524f07 Author: hudson Date: 2012-04-05 12:55 -0700 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/5c3b3d524f07 Added tag 2.1-b21 for changeset 4d1d81b2c178 ! .hgtags From hang.vo at oracle.com Thu Apr 5 13:18:53 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 05 Apr 2012 20:18:53 +0000 Subject: hg: openjfx/2.2/controls/rt: FXVK: Updated layouts Message-ID: <20120405201855.0B20147E45@hg.openjdk.java.net> Changeset: c6b279c12e00 Author: leifs Date: 2012-04-05 13:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/c6b279c12e00 FXVK: Updated layouts ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls.properties From hang.vo at oracle.com Thu Apr 5 14:04:11 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 05 Apr 2012 21:04:11 +0000 Subject: hg: openjfx/2.2/controls/rt: Fixed RT-16628: [TextArea, TextField] Selection on double click take the following whitespace into selection Message-ID: <20120405210412.8E56F47E4B@hg.openjdk.java.net> Changeset: cde48ec5b900 Author: leifs Date: 2012-04-05 13:57 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/cde48ec5b900 Fixed RT-16628: [TextArea,TextField] Selection on double click take the following whitespace into selection ! 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 Thu Apr 5 14:48:57 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 05 Apr 2012 21:48:57 +0000 Subject: hg: openjfx/2.2/controls/rt: fix RT-20657 focus ring gets stuck in a editable ComboBox. Message-ID: <20120405214857.D4EFE47E64@hg.openjdk.java.net> Changeset: 5aad7496e4de Author: Paru Somashekar Date: 2012-04-05 14:41 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/5aad7496e4de fix RT-20657 focus ring gets stuck in a editable ComboBox. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java From hang.vo at oracle.com Thu Apr 5 16:48:17 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 05 Apr 2012 23:48:17 +0000 Subject: hg: openjfx/2.2/controls/rt: Pagination: left and right swipe support. Message-ID: <20120405234818.8703347E86@hg.openjdk.java.net> Changeset: 9355216335fd Author: Kinsley Wong Date: 2012-04-05 16:45 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/9355216335fd Pagination: left and right swipe support. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java From hang.vo at oracle.com Thu Apr 5 22:18:41 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 06 Apr 2012 05:18:41 +0000 Subject: hg: openjfx/2.2/controls/rt: Fixed RT-19691: Mnemonic isn't shown when textProperty is bound. Message-ID: <20120406051843.046F647EF0@hg.openjdk.java.net> Changeset: a3c614e52249 Author: leifs Date: 2012-04-05 22:11 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/a3c614e52249 Fixed RT-19691: Mnemonic isn't shown when textProperty is bound. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java From hang.vo at oracle.com Fri Apr 6 04:04:30 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 06 Apr 2012 11:04:30 +0000 Subject: hg: openjfx/2.2/graphics/rt: Scene code cleanup - multiplicated picking and parent traversing code merged together, got rid of many instanceofs. RT-19346, RT-20832 and RT-20833 fixed along the way. Message-ID: <20120406110434.866EE47EF5@hg.openjdk.java.net> Changeset: b8de44e3e523 Author: Pavel Safrata Date: 2012-04-06 12:59 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/b8de44e3e523 Scene code cleanup - multiplicated picking and parent traversing code merged together, got rid of many instanceofs. RT-19346, RT-20832 and RT-20833 fixed along the way. ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/test/unit/javafx/scene/MouseTest.java From fbrunnerlist at gmx.ch Fri Apr 6 09:20:47 2012 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Fri, 6 Apr 2012 18:20:47 +0200 Subject: Patch: issue RT-14177 In-Reply-To: <4F7DCE4E.8090905@oracle.com> References: <201204051750.13667.fbrunnerlist@gmx.ch> <4F7DCE4E.8090905@oracle.com> Message-ID: <201204061820.48319.fbrunnerlist@gmx.ch> 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 kevin.rushforth at oracle.com Fri Apr 6 09:31:23 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 06 Apr 2012 09:31:23 -0700 Subject: Patch: issue RT-14177 In-Reply-To: <201204061820.48319.fbrunnerlist@gmx.ch> References: <201204051750.13667.fbrunnerlist@gmx.ch> <4F7DCE4E.8090905@oracle.com> <201204061820.48319.fbrunnerlist@gmx.ch> Message-ID: <4F7F1A5B.1000202@oracle.com> 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 fbrunnerlist at gmx.ch Fri Apr 6 10:10:30 2012 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Fri, 6 Apr 2012 19:10:30 +0200 Subject: Patch: issue RT-14177 In-Reply-To: <4F7F1A5B.1000202@oracle.com> References: <201204051750.13667.fbrunnerlist@gmx.ch> <201204061820.48319.fbrunnerlist@gmx.ch> <4F7F1A5B.1000202@oracle.com> Message-ID: <201204061910.31029.fbrunnerlist@gmx.ch> 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 Apr 6 17:03:58 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 07 Apr 2012 00:03:58 +0000 Subject: hg: openjfx/2.2/controls/rt: RT20171: Tab in FXML: define content property as DefaultProperty. Message-ID: <20120407000401.F3FB147F13@hg.openjdk.java.net> Changeset: 829382aecd2e Author: Kinsley Wong Date: 2012-04-06 16:47 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/829382aecd2e RT20171: Tab in FXML: define content property as DefaultProperty. ! javafx-ui-controls/src/javafx/scene/control/Tab.java From hang.vo at oracle.com Mon Apr 9 11:03:14 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 09 Apr 2012 18:03:14 +0000 Subject: hg: openjfx/2.2/controls/rt: Pagination: swipe directions were reversed. Message-ID: <20120409180317.0AC3347F86@hg.openjdk.java.net> Changeset: cce17d461292 Author: Kinsley Wong Date: 2012-04-09 10:51 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/cce17d461292 Pagination: swipe directions were reversed. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java From hang.vo at oracle.com Mon Apr 9 13:18:01 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 09 Apr 2012 20:18:01 +0000 Subject: hg: openjfx/2.2/controls/rt: 3 new changesets Message-ID: <20120409201804.D4B3D47F8D@hg.openjdk.java.net> Changeset: 5c3b3d524f07 Author: hudson Date: 2012-04-05 12:55 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/5c3b3d524f07 Added tag 2.1-b21 for changeset 4d1d81b2c178 ! .hgtags Changeset: b66c767bcbcb Author: kcr Date: 2012-04-05 14:43 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/b66c767bcbcb Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.1/MASTER/jfx/rt ! .hgtags - javafx-ui-common/src/com/sun/javafx/tk/TextHelper.java Changeset: fdc80b4d14e9 Author: leifs Date: 2012-04-09 13:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/fdc80b4d14e9 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt From hang.vo at oracle.com Mon Apr 9 17:03:07 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 10 Apr 2012 00:03:07 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-12765: GridPane addRow() and addColumn() methods should append to internal structure. Message-ID: <20120410000310.A1DDD47F93@hg.openjdk.java.net> Changeset: c2f82cdfe9fd Author: Kinsley Wong Date: 2012-04-09 16:50 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/c2f82cdfe9fd RT-12765: GridPane addRow() and addColumn() methods should append to internal structure. ! 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 Apr 9 17:48:10 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 10 Apr 2012 00:48:10 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-20476: A mouse press (rather than a mouse click) should select a Tab in TabPane. Message-ID: <20120410004811.A8FA347F95@hg.openjdk.java.net> Changeset: 818ef2149cf1 Author: Kinsley Wong Date: 2012-04-09 17:43 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/818ef2149cf1 RT-20476: A mouse press (rather than a mouse click) should select a Tab in TabPane. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java From hang.vo at oracle.com Mon Apr 9 19:18:17 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 10 Apr 2012 02:18:17 +0000 Subject: hg: openjfx/2.2/controls/rt: fix broken unit tests. Message-ID: <20120410021818.91E1F47F98@hg.openjdk.java.net> Changeset: 85016c7b7e6c Author: Kinsley Wong Date: 2012-04-09 19:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/85016c7b7e6c fix broken unit tests. ! javafx-ui-common/src/javafx/scene/layout/GridPane.java From hang.vo at oracle.com Mon Apr 9 21:03:46 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 10 Apr 2012 04:03:46 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-20869: Extending the Maven Build to include aggregated sources Message-ID: <20120410040348.63CE747F9A@hg.openjdk.java.net> Changeset: f33e24e8ff4d Author: kcr Date: 2012-04-09 20:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/f33e24e8ff4d RT-20869: Extending the Maven Build to include aggregated sources Contributed-By: Adam Bien Reviewed-By: kcr ! javafx-ueber-jar/pom.xml ! pom.xml From abien at adam-bien.com Tue Apr 10 00:05:01 2012 From: abien at adam-bien.com (Adam Bien) Date: Tue, 10 Apr 2012 09:05:01 +0200 Subject: Maven Build Works Message-ID: <17FCA2A8-E284-40E5-A475-1F50F8EFDABB@adam-bien.com> Hi *, Java FX 2.2 sources can be build with maven 3 now. I described the procedure in my blog: http://www.adam-bien.com/roller/abien/entry/daily_building_java_fx_2 Basically Maven 3 was tweaked to fit the current non-standard (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html) maven structure. The Maven 3 build is not good enough yet, but several improvements are already in the pipeline. After the introduction of the latest patch (not integrated yet), maven 3 will also aggregate all the sources into a single jar. Now Java FX is a little more "enterprisey" :-). Enjoy your daily FX brew. adam workshops.adam-bien.com blog.adam-bien.com about.adam-bien.com Author of: "Real World Java EE Night Hacks", "Real World Java EE Patterns--Rethinking Best Practices" From tbee at tbee.org Tue Apr 10 00:13:40 2012 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 10 Apr 2012 09:13:40 +0200 Subject: Maven Build Works In-Reply-To: <17FCA2A8-E284-40E5-A475-1F50F8EFDABB@adam-bien.com> References: <17FCA2A8-E284-40E5-A475-1F50F8EFDABB@adam-bien.com> Message-ID: <4F83DDA4.3000605@tbee.org> I was putting this off until it may actually be release into a repo, but great! Thanks! Tom On 2012-04-10 09:05, Adam Bien wrote: > Hi *, > > Java FX 2.2 sources can be build with maven 3 now. I described the procedure in my blog: http://www.adam-bien.com/roller/abien/entry/daily_building_java_fx_2 > > Basically Maven 3 was tweaked to fit the current non-standard (http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html) maven structure. > > The Maven 3 build is not good enough yet, but several improvements are already in the pipeline. > > After the introduction of the latest patch (not integrated yet), maven 3 will also aggregate all the sources into a single jar. > > Now Java FX is a little more "enterprisey" :-). Enjoy your daily FX brew. > > adam > > > > > workshops.adam-bien.com > blog.adam-bien.com > about.adam-bien.com > > Author of: > "Real World Java EE Night Hacks", "Real World Java EE Patterns--Rethinking Best Practices" > > > > > > > > > > > > > > > > > > From rla.dev at frontwerks.com Tue Apr 10 04:23:24 2012 From: rla.dev at frontwerks.com (Rainer Lang) Date: Tue, 10 Apr 2012 13:23:24 +0200 Subject: Source Code for FXCanvas (SWT) ? Message-ID: <4F84182C.80802@frontwerks.com> I cannot find the source code for the FXCanvas class in the following repositories: hg.openjdk.java.net/openjfx/2.2/master/rt or hg.openjdk.java.net/openjfx/2.1/master/rt. Can anybody give me a hint? Thanks, Rainer From hang.vo at oracle.com Tue Apr 10 04:34:10 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 10 Apr 2012 11:34:10 +0000 Subject: hg: openjfx/2.2/graphics/rt: 2 new changesets Message-ID: <20120410113413.84E2D47FA0@hg.openjdk.java.net> Changeset: 59cce19d3ba4 Author: Michael Heinrichs Date: 2012-04-05 16:00 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/59cce19d3ba4 Improved picking if cell cannot be reused [RT-20829] ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 02d3dce15c93 Author: Michael Heinrichs Date: 2012-04-10 10:50 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/02d3dce15c93 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/graphics/jfx/rt From hang.vo at oracle.com Tue Apr 10 05:03:29 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 10 Apr 2012 12:03:29 +0000 Subject: hg: openjfx/2.2/graphics/rt: 2 new changesets Message-ID: <20120410120330.CF8C547FA1@hg.openjdk.java.net> Changeset: 534afd2fb91f Author: Martin Sladecek Date: 2012-04-10 13:55 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/534afd2fb91f Scene's dirtyNodes optimization. Reviewed by Lubo. ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: b98d11b3a594 Author: Martin Sladecek Date: 2012-04-10 13:56 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/b98d11b3a594 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/graphics/jfx/rt ! javafx-ui-common/src/javafx/scene/Scene.java From steve.x.northover at oracle.com Tue Apr 10 05:54:07 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Tue, 10 Apr 2012 08:54:07 -0400 Subject: Source Code for FXCanvas (SWT) ? In-Reply-To: <4F84182C.80802@frontwerks.com> References: <4F84182C.80802@frontwerks.com> Message-ID: <4F842D6F.4040103@oracle.com> Hi Ranier, It has not been open sourced yet. Steve On 10/04/2012 7:23 AM, Rainer Lang wrote: > I cannot find the source code for the FXCanvas class in the following > repositories: > > hg.openjdk.java.net/openjfx/2.2/master/rt or > hg.openjdk.java.net/openjfx/2.1/master/rt. > > Can anybody give me a hint? > > Thanks, > Rainer From tom.schindl at bestsolution.at Tue Apr 10 06:46:38 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 10 Apr 2012 15:46:38 +0200 Subject: Patch: issue RT-14177 In-Reply-To: <201204061910.31029.fbrunnerlist@gmx.ch> References: <201204051750.13667.fbrunnerlist@gmx.ch> <201204061820.48319.fbrunnerlist@gmx.ch> <4F7F1A5B.1000202@oracle.com> <201204061910.31029.fbrunnerlist@gmx.ch> Message-ID: <4F8439BE.6030604@bestsolution.at> Hi, I think we need to take a highlevel look at this. So the real problem in an OSGi Environment is the fully qualified classname in OSGi has to have more information than in standard java. In standard java: ----------------- my.package.MyClass In OSGi: -------- my.bundle/my.package.MyClass So the problem we need to solve is to make the css and fxml framework classes pass on this information or make use it it directly (e.g. fxml loads classes itself, while css only passes a string to the control which does the classloading). So the first an most important API that is needed is the possibility to install a global Classloading-Delegate which understands the little bit more sophisticated FQN of a class in OSGi. interface ClassloadingDelegate { Class loadClass(String classnameUrl); String createClassNameUrl(String resourceURL, String classname); } there must be some place in javafx where such a classloading delegate could be installed (e.g. the Platform-Class?). Platform#setClassloadingDelegate(ClassloadingDelegate): void (I don't know if Platform is the best class for this because it is public API but this API is better suited in an internal one) *1. Usecase: All information coming from an OSGi-Bundle* The createClassnameUrl is used by the FXML and CSSEngine to create an URL from the simple class definitions e.g.: my.bundle/css/my.css -------------------- -fx-skin: my.package.MyClass passes in the following informations to ClassloadingDelegate#createClassNameUrl: resourceURL: bundle://1234/css/my.css classname: my.package.MyClass which results in: bundle://1234/my.package.MyClass which is then set in the Control's skinClassName. The control then uses ClassloadingDelegate#loadClass(String classnameUrl) to load the class. *2. Usecase: Information coming from css/fxml file on the filesystem* CSS nor FXML requires informations loaded from a bundle/jar file but they can resided fairly everywhere (e.g. file://, http://) and in this case the retrieval of the bundle to use when loading classes can not be derived from css filename but must be encoded into the css itself like this: file://C/my.css ------------- -fx-skin: my.bundle/my.package.MyClass so the CSS-Engine will call ClassloadingDelegate#createClassNameUrl with these values: resourceURL: file://C/my.css classname: my.bundle/my.package.MyClass and now the delegate has to do some more work because it first has to find the bundle with the symbolic name "my.bundle" (Probably by using the PackageAdmin-Service) and make up the bundle-url of it but the result would be the same: bundle://1234/my.package.MyClass What do you think about this proposal? Tom Am 06.04.12 19:10, schrieb Florian Brunner: > 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 hang.vo at oracle.com Tue Apr 10 09:34:05 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 10 Apr 2012 16:34:05 +0000 Subject: hg: openjfx/2.2/graphics/rt: 59 new changesets Message-ID: <20120410163452.D8EA947FAA@hg.openjdk.java.net> Changeset: cebb10de0795 Author: hudson Date: 2012-04-03 13:44 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/cebb10de0795 Added tag 2.2-b03 for changeset 474801a028b9 ! .hgtags Changeset: 5c3b3d524f07 Author: hudson Date: 2012-04-05 12:55 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/5c3b3d524f07 Added tag 2.1-b21 for changeset 4d1d81b2c178 ! .hgtags Changeset: b66c767bcbcb Author: kcr Date: 2012-04-05 14:43 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/b66c767bcbcb Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.1/MASTER/jfx/rt ! .hgtags - javafx-ui-common/src/com/sun/javafx/tk/TextHelper.java Changeset: 8acd74a463e3 Author: Paru Somashekar Date: 2012-03-26 12:07 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/8acd74a463e3 AddColorPane dialog for ColorPicker prototype ! javafx-ui-controls/src/com/sun/javafx/scene/control/ColorPicker.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/ColorPickerPanel.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ColorPickerBehavior.java ! 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 + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/center-btn-selected.png + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/center-btn.png + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/left-btn-selected.png + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/left-btn.png + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/right-btn-selected.png + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/right-btn.png Changeset: bc7aa1bdbf04 Author: Paru Somashekar Date: 2012-03-26 12:08 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/bc7aa1bdbf04 missed this in previous putback. + javafx-ui-controls/src/com/sun/javafx/scene/control/ColorPickerAddColorPane.java Changeset: 24c7fb48a91f Author: jgiles Date: 2012-03-22 13:00 +1300 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/24c7fb48a91f Partial implementation of RT-17975: Support for discontinuous selection in TableView/ListView/TreeView. (Total ListView and TreeView support, but no TableView support yet) ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewKeyInputTest.java Changeset: 24f22ed28f63 Author: jgiles Date: 2012-03-27 10:58 +1300 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/24f22ed28f63 Partial implementation of RT-19449: TableView: Improved keyboard navigation (discontinuous selection) (Support for row-based discontinuous selection, with cell-based coming in a separate changset once developed). ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java Changeset: 7b001733f381 Author: jgiles Date: 2012-03-27 11:56 +1300 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/7b001733f381 RT-19449: TableView: Improved keyboard navigation (discontinuous selection) (For cell-based selection) ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java Changeset: 646173cf1ff1 Author: jgiles Date: 2012-03-27 11:59 +1300 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/646173cf1ff1 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 459b180c6841 Author: leifs Date: 2012-03-27 10:58 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/459b180c6841 Fixed RT-18991: Right aligned TextFiel behaves incorrectly when containing long text Fixed RT-20035: TextField text alignment fails when delayed setText() call with alignment = Pos.CENTER ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java Changeset: 1f368473b22c Author: leifs Date: 2012-03-27 11:11 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/1f368473b22c Update to fix for RT-20035: TextField text alignment fails when delayed setText() call with alignment = Pos.CENTER ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java Changeset: 0170fb8eb4ff Author: Paru Somashekar Date: 2012-03-27 15:11 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/0170fb8eb4ff some color picker prototype visual changes. ! javafx-ui-controls/src/com/sun/javafx/scene/control/ColorPickerAddColorPane.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: 6d42959f42b2 Author: jgiles Date: 2012-03-28 11:56 +1300 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/6d42959f42b2 RT-20575: ComboBox editable incorrect paint behavior ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxBaseSkin.java Changeset: 89f8c2fda2d8 Author: jgiles Date: 2012-03-28 12:09 +1300 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/89f8c2fda2d8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 59773e9d3233 Author: Paru Somashekar Date: 2012-03-27 16:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/59773e9d3233 fix incorrect focus around editable ComboBox that was introduced while doing changes for ColorPicker ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxBaseSkin.java Changeset: c4d9edf225c4 Author: leifs Date: 2012-03-27 17:26 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/c4d9edf225c4 Fixed RT-20312: WrapText incorrectly calculates control height ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ButtonSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java Changeset: 0992d63e63b9 Author: Paru Somashekar Date: 2012-03-27 22:47 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/0992d63e63b9 fix RT-20639 Strange behavior for empty StackedAreaChart ! javafx-ui-charts/src/javafx/scene/chart/StackedAreaChart.java Changeset: 7c3dc5904604 Author: Paru Somashekar Date: 2012-03-28 09:35 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/7c3dc5904604 fix RT-18389 ScatterChart draws points shifted from expected position ! javafx-ui-charts/src/javafx/scene/chart/ScatterChart.java Changeset: 20df31a51b62 Author: leifs Date: 2012-03-28 13:28 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/20df31a51b62 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt Changeset: 65a00a7e79ef Author: Kinsley Wong Date: 2012-03-28 15:38 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/65a00a7e79ef RT-20508: VirtualContainerBase constructor should check for control properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualContainerBase.java Changeset: 55933b31214f Author: Kinsley Wong Date: 2012-03-28 15:41 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/55933b31214f Implement setPageIndex, setNumberOfVisiblePages, setNumberOfItems and setPageFactory. ! javafx-ui-controls/src/com/sun/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 3014f9f8ce87 Author: Greg Brown Date: 2012-03-29 08:48 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/3014f9f8ce87 Revert default property changes associated with RT-20547. ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java Changeset: c6bb8a5a32b0 Author: leifs Date: 2012-03-29 14:21 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/c6bb8a5a32b0 Fixed RT-20644: Strange behavior of TextField in GridPane. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java Changeset: b357d89c5b06 Author: Kinsley Wong Date: 2012-03-29 17:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/b357d89c5b06 pagination disable horizontal scrollbars. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: ab22b3c94222 Author: Kinsley Wong Date: 2012-03-29 17:57 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/ab22b3c94222 Pagination: resize the cell when the parent changes size. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationCellSkin.java Changeset: a64fe55fd5c5 Author: Kinsley Wong Date: 2012-03-29 17:58 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a64fe55fd5c5 Pagination: implement setPageIndex() ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 9735e7d0d5d2 Author: Kinsley Wong Date: 2012-03-29 19:11 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/9735e7d0d5d2 Pagination: update the number of visible pages if the number of pages is less than the number of visible pages. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 0cac4962eb87 Author: David Grieve Date: 2012-03-29 22:54 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/0cac4962eb87 RT-20210: StyleManager.Cache.cache should hold StyleHelper instance, not Reference ! 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 Changeset: 02b27d9e7bf2 Author: David Grieve Date: 2012-03-29 22:54 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/02b27d9e7bf2 RT-9784: when a new StyleHelper is needed, reset the styled properties to initial values ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java Changeset: da37fdc4a2f6 Author: David Grieve Date: 2012-03-29 22:54 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/da37fdc4a2f6 RT-20691: restore building of caspian.bss ! javafx-ui-controls/build.xml Changeset: 3c304eaa5b55 Author: leifs Date: 2012-03-30 13:50 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/3c304eaa5b55 Fixed RT-7547: TextField/PasswordField/TextArea needs undo/redo ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls.properties Changeset: 11cab33d9c55 Author: leifs Date: 2012-03-30 14:29 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/11cab33d9c55 Additional fix for RT-7547: TextField/PasswordField/TextArea needs undo/redo ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java Changeset: 55dafb84ad3f Author: leifs Date: 2012-03-31 16:33 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/55dafb84ad3f Fixed RT-19273: Ctrl-Backspace in Text Field ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! 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: 1e938a90f89a Author: leifs Date: 2012-03-31 17:19 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/1e938a90f89a Fixed RT-18711: [PasswordField] Using ctrl+shift+left/right allows to identify spaces in password. Fixed RT-18854 [PasswordField] mouse double click allow to identify spaces in password. + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/PasswordFieldBehavior.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 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PasswordFieldSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java Changeset: 1ba55d2ecc03 Author: leifs Date: 2012-04-02 10:10 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/1ba55d2ecc03 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 4889b4deb45e Author: Paru Somashekar Date: 2012-04-02 15:39 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/4889b4deb45e fix RT-20720 NPE when removing last item in series in AreaChart ! javafx-ui-charts/src/javafx/scene/chart/AreaChart.java Changeset: 05f86cff4777 Author: Kinsley Wong Date: 2012-03-30 11:55 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/05f86cff4777 Pagination: css cleanup ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: b421b3cdc003 Author: Kinsley Wong Date: 2012-04-02 16:54 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/b421b3cdc003 Pagination: include node size when computing pref width and height ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationCellSkin.java Changeset: b9dde81dbee6 Author: Kinsley Wong Date: 2012-04-02 16:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/b9dde81dbee6 Pagination: correctly compute the total number of pages and scroll pages using offsets. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 8909d2df17f0 Author: Kinsley Wong Date: 2012-04-02 16:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/8909d2df17f0 Pagination: css cleanup. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: ee1093741bde Author: Kinsley Wong Date: 2012-04-02 17:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/ee1093741bde Pagination: allowing scrolling to an offset. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualContainerBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 33eee41df3bd Author: Kinsley Wong Date: 2012-04-02 17:10 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/33eee41df3bd merge - javafx-ui-common/src/com/sun/javafx/tk/TextHelper.java Changeset: e08f86fc5989 Author: David Grieve Date: 2012-04-02 20:39 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/e08f86fc5989 RT-20686: -fx-font-smoothing-type: gray; does not parse. Parser sees "gray" as a color. ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest_AUTHOR.css ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest_UA.css ! javafx-ui-common/test/unit/javafx/scene/text/Text_cssMethods_Test.java Changeset: ae28effcfa79 Author: David Grieve Date: 2012-04-03 10:51 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/ae28effcfa79 RT-20210: A StyleHelper might not have been gc'd so the referent might not have been cleared before the Reference is used by code that relies on the reference being cleared as soon as the StyleHelper becomes invalid and not when the StyleHelper is gc'd. ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: 137908962b46 Author: mickf Date: 2012-04-04 12:41 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/137908962b46 RT-16144 - ScrollBar: space between buttons has another width than buttons ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ScrollPaneSkinTest.java Changeset: 60861984b3f7 Author: Kinsley Wong Date: 2012-04-04 11:44 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/60861984b3f7 JAVADOC RT-20490 Region javadoc needs links. ! javafx-ui-common/src/javafx/scene/layout/Region.java Changeset: 7d435026b5fe Author: Kinsley Wong Date: 2012-04-04 12:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/7d435026b5fe Pagination: add support for left and right key presses. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/PaginationBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: abd899c37f61 Author: Kinsley Wong Date: 2012-04-04 15:03 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/abd899c37f61 Pagination: do not use any of list-cell styles for pagination-cell. ! javafx-ui-controls/src/com/sun/javafx/scene/control/PaginationCell.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 12bba27d5557 Author: leifs Date: 2012-04-04 22:51 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/12bba27d5557 FXVK: Virtual keyboard layouts now defined in resource file ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVK.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKCharEntities.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls.properties ! javafx-ui-controls/src/javafx/scene/control/TextInputControl.java Changeset: 15b9d61a37a9 Author: leifs Date: 2012-04-05 09:48 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/15b9d61a37a9 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt Changeset: c6b279c12e00 Author: leifs Date: 2012-04-05 13:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/c6b279c12e00 FXVK: Updated layouts ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls.properties Changeset: cde48ec5b900 Author: leifs Date: 2012-04-05 13:57 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/cde48ec5b900 Fixed RT-16628: [TextArea,TextField] Selection on double click take the following whitespace into selection ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java Changeset: 5aad7496e4de Author: Paru Somashekar Date: 2012-04-05 14:41 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/5aad7496e4de fix RT-20657 focus ring gets stuck in a editable ComboBox. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 9355216335fd Author: Kinsley Wong Date: 2012-04-05 16:45 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/9355216335fd Pagination: left and right swipe support. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: a3c614e52249 Author: leifs Date: 2012-04-05 22:11 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a3c614e52249 Fixed RT-19691: Mnemonic isn't shown when textProperty is bound. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java Changeset: 829382aecd2e Author: Kinsley Wong Date: 2012-04-06 16:47 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/829382aecd2e RT20171: Tab in FXML: define content property as DefaultProperty. ! javafx-ui-controls/src/javafx/scene/control/Tab.java Changeset: cce17d461292 Author: Kinsley Wong Date: 2012-04-09 10:51 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/cce17d461292 Pagination: swipe directions were reversed. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: fdc80b4d14e9 Author: leifs Date: 2012-04-09 13:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/fdc80b4d14e9 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt Changeset: e9d45acca75f Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-04-10 09:16 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/e9d45acca75f Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java From hang.vo at oracle.com Tue Apr 10 13:19:05 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 10 Apr 2012 20:19:05 +0000 Subject: hg: openjfx/2.2/graphics/rt: fix .classpath Message-ID: <20120410201906.16A7E47FB5@hg.openjdk.java.net> Changeset: ff654a59c586 Author: snorthov Date: 2012-04-10 16:03 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/ff654a59c586 fix .classpath ! .classpath From kevin.rushforth at oracle.com Tue Apr 10 13:43:45 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 10 Apr 2012 13:43:45 -0700 Subject: API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking Message-ID: <4F849B81.5070603@oracle.com> JIRA: http://javafx-jira.kenai.com/browse/RT-19783 We have had several requests for a way to block the caller while a (modal) dialog is shown. The show() method on a Stage is specified to return to the caller immediately regardless of the modality of a stage. This is a good semantic for many applications, but complicates the logic for other applications which don't want to proceed until the dialog is dismissed. It is also needed internally to implement an Alert class (see RT-12643 for example). Swing dialog, for example, JOptionPane, work by blocking the caller until the dialog is dismissed meaning that Swing application programmers are already familiar with that model. Our proposal for JavaFX 2.2 is to add a new method on Stage, showAndWait(), which will block the caller until the stage is hidden. Note that while this is primarily useful for modal Stages, there is nothing in the API that restricts it to such. The proposed method and javadoc are described in the JIRA , but since it is so short, I will also list it here: /** * Show the stage and wait for it to be closed before returning to the * caller. This must be called on the FX Application thread. The stage * must not already be visible prior to calling this method. This must not * be called on the primary stage. * * @throws IllegalStateException if this method is called on a thread * other than the JavaFX Application Thread. * @throws IllegalStateException if this method is called on the * primary stage. * @throws IllegalStateException if this stage is already showing. */ public void showAndWait(); -- Kevin From richard.bair at oracle.com Tue Apr 10 13:45:55 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 10 Apr 2012 13:45:55 -0700 Subject: API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking In-Reply-To: <4F849B81.5070603@oracle.com> References: <4F849B81.5070603@oracle.com> Message-ID: Looks good to me, if nobody objects by tomorrow I'll mark this as approved. Richard On Apr 10, 2012, at 1:43 PM, Kevin Rushforth wrote: > JIRA: http://javafx-jira.kenai.com/browse/RT-19783 > > We have had several requests for a way to block the caller while a (modal) dialog is shown. The show() method on a Stage is specified to return to the caller immediately regardless of the modality of a stage. This is a good semantic for many applications, but complicates the logic for other applications which don't want to proceed until the dialog is dismissed. It is also needed internally to implement an Alert class (see RT-12643 for example). Swing dialog, for example, JOptionPane, work by blocking the caller until the dialog is dismissed meaning that Swing application programmers are already familiar with that model. > > Our proposal for JavaFX 2.2 is to add a new method on Stage, showAndWait(), which will block the caller until the stage is hidden. Note that while this is primarily useful for modal Stages, there is nothing in the API that restricts it to such. > > The proposed method and javadoc are described in the JIRA, but since it is so short, I will also list it here: > > /** > * Show the stage and wait for it to be closed before returning to the > * caller. This must be called on the FX Application thread. The stage > * must not already be visible prior to calling this method. This must not > * be called on the primary stage. > * > * @throws IllegalStateException if this method is called on a thread > * other than the JavaFX Application Thread. > * @throws IllegalStateException if this method is called on the > * primary stage. > * @throws IllegalStateException if this stage is already showing. > */ > public void showAndWait(); > > -- Kevin > From hang.vo at oracle.com Tue Apr 10 14:48:39 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 10 Apr 2012 21:48:39 +0000 Subject: hg: openjfx/2.2/controls/rt: dos2unix Message-ID: <20120410214841.A927A47FBA@hg.openjdk.java.net> Changeset: a9aa43c1c740 Author: Kinsley Wong Date: 2012-04-10 14:35 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/a9aa43c1c740 dos2unix ! javafx-ui-controls/src/com/sun/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/PaginationCell.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/PaginationBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java From deep.blue.6802 at gmail.com Tue Apr 10 16:01:40 2012 From: deep.blue.6802 at gmail.com (Jeff McDonald) Date: Tue, 10 Apr 2012 17:01:40 -0600 Subject: API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking In-Reply-To: References: <4F849B81.5070603@oracle.com> Message-ID: Just my 2 cents ... showAsModal or showModal sounds better. When I see showAndWait my first question before I read the docs is "what am I waiting for?" showAsModal or showModal seem more self-documenting than showAndWait. Cheers, Jeff On Tue, Apr 10, 2012 at 2:45 PM, Richard Bair wrote: > Looks good to me, if nobody objects by tomorrow I'll mark this as approved. > > Richard > > On Apr 10, 2012, at 1:43 PM, Kevin Rushforth wrote: > > > JIRA: http://javafx-jira.kenai.com/browse/RT-19783 > > > > We have had several requests for a way to block the caller while a > (modal) dialog is shown. The show() method on a Stage is specified to > return to the caller immediately regardless of the modality of a stage. > This is a good semantic for many applications, but complicates the logic > for other applications which don't want to proceed until the dialog is > dismissed. It is also needed internally to implement an Alert class (see > RT-12643 for example). Swing dialog, for example, JOptionPane, work by > blocking the caller until the dialog is dismissed meaning that Swing > application programmers are already familiar with that model. > > > > Our proposal for JavaFX 2.2 is to add a new method on Stage, > showAndWait(), which will block the caller until the stage is hidden. Note > that while this is primarily useful for modal Stages, there is nothing in > the API that restricts it to such. > > > > The proposed method and javadoc are described in the JIRA, but since it > is so short, I will also list it here: > > > > /** > > * Show the stage and wait for it to be closed before returning to > the > > * caller. This must be called on the FX Application thread. The > stage > > * must not already be visible prior to calling this method. This > must not > > * be called on the primary stage. > > * > > * @throws IllegalStateException if this method is called on a thread > > * other than the JavaFX Application Thread. > > * @throws IllegalStateException if this method is called on the > > * primary stage. > > * @throws IllegalStateException if this stage is already showing. > > */ > > public void showAndWait(); > > > > -- Kevin > > > > From kevin.rushforth at oracle.com Tue Apr 10 16:21:59 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 10 Apr 2012 16:21:59 -0700 Subject: API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking In-Reply-To: References: <4F849B81.5070603@oracle.com> Message-ID: <4F84C097.90103@oracle.com> The problem with showAsModal is that this method is independent of the modality attribute on Stage, so the name would be confusing. You can have a modal window (a window whose modality is Modality.WINDOW_MODAL or Modality.APPLICATION_MODAL), without having it block the caller. Conversely, you can have a non-modal window (Modality.NONE) that blocks if you call this method. I am open to a better name for this method, but I don't think it should have modal in the name. -- Kevin Jeff McDonald wrote: > Just my 2 cents ... showAsModal or showModal sounds better. When I see > showAndWait my first question before I read the docs is "what am I > waiting for?" showAsModal or showModal seem more self-documenting > than showAndWait. > > Cheers, > Jeff > > On Tue, Apr 10, 2012 at 2:45 PM, Richard Bair > wrote: > > Looks good to me, if nobody objects by tomorrow I'll mark this as > approved. > > Richard > > On Apr 10, 2012, at 1:43 PM, Kevin Rushforth wrote: > > > JIRA: http://javafx-jira.kenai.com/browse/RT-19783 > > > > We have had several requests for a way to block the caller while > a (modal) dialog is shown. The show() method on a Stage is > specified to return to the caller immediately regardless of the > modality of a stage. This is a good semantic for many > applications, but complicates the logic for other applications > which don't want to proceed until the dialog is dismissed. It is > also needed internally to implement an Alert class (see RT-12643 > for example). Swing dialog, for example, JOptionPane, work by > blocking the caller until the dialog is dismissed meaning that > Swing application programmers are already familiar with that model. > > > > Our proposal for JavaFX 2.2 is to add a new method on Stage, > showAndWait(), which will block the caller until the stage is > hidden. Note that while this is primarily useful for modal Stages, > there is nothing in the API that restricts it to such. > > > > The proposed method and javadoc are described in the JIRA, but > since it is so short, I will also list it here: > > > > /** > > * Show the stage and wait for it to be closed before > returning to the > > * caller. This must be called on the FX Application thread. > The stage > > * must not already be visible prior to calling this method. > This must not > > * be called on the primary stage. > > * > > * @throws IllegalStateException if this method is called on > a thread > > * other than the JavaFX Application Thread. > > * @throws IllegalStateException if this method is called on the > > * primary stage. > > * @throws IllegalStateException if this stage is already > showing. > > */ > > public void showAndWait(); > > > > -- Kevin > > > > From deep.blue.6802 at gmail.com Tue Apr 10 16:39:48 2012 From: deep.blue.6802 at gmail.com (Jeff McDonald) Date: Tue, 10 Apr 2012 17:39:48 -0600 Subject: API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking In-Reply-To: <4F84C097.90103@oracle.com> References: <4F849B81.5070603@oracle.com> <4F84C097.90103@oracle.com> Message-ID: Hmmmm ... maybe we're talking semantics here. What does Modality mean in JavaFX? What does "blocking" mean in a JavaFX? Cheers, Jeff On Tue, Apr 10, 2012 at 5:21 PM, Kevin Rushforth wrote: > ** > The problem with showAsModal is that this method is independent of the > modality attribute on Stage, so the name would be confusing. > > You can have a modal window (a window whose modality is > Modality.WINDOW_MODAL or Modality.APPLICATION_MODAL), without having it > block the caller. Conversely, you can have a non-modal window > (Modality.NONE) that blocks if you call this method. > > I am open to a better name for this method, but I don't think it should > have modal in the name. > > -- Kevin > > > > Jeff McDonald wrote: > > Just my 2 cents ... showAsModal or showModal sounds better. When I see > showAndWait my first question before I read the docs is "what am I waiting > for?" showAsModal or showModal seem more self-documenting than > showAndWait. > > Cheers, > Jeff > > On Tue, Apr 10, 2012 at 2:45 PM, Richard Bair wrote: > >> Looks good to me, if nobody objects by tomorrow I'll mark this as >> approved. >> >> Richard >> >> On Apr 10, 2012, at 1:43 PM, Kevin Rushforth wrote: >> >> > JIRA: http://javafx-jira.kenai.com/browse/RT-19783 >> > >> > We have had several requests for a way to block the caller while a >> (modal) dialog is shown. The show() method on a Stage is specified to >> return to the caller immediately regardless of the modality of a stage. >> This is a good semantic for many applications, but complicates the logic >> for other applications which don't want to proceed until the dialog is >> dismissed. It is also needed internally to implement an Alert class (see >> RT-12643 for example). Swing dialog, for example, JOptionPane, work by >> blocking the caller until the dialog is dismissed meaning that Swing >> application programmers are already familiar with that model. >> > >> > Our proposal for JavaFX 2.2 is to add a new method on Stage, >> showAndWait(), which will block the caller until the stage is hidden. Note >> that while this is primarily useful for modal Stages, there is nothing in >> the API that restricts it to such. >> > >> > The proposed method and javadoc are described in the JIRA, but since >> it is so short, I will also list it here: >> > >> > /** >> > * Show the stage and wait for it to be closed before returning to >> the >> > * caller. This must be called on the FX Application thread. The >> stage >> > * must not already be visible prior to calling this method. This >> must not >> > * be called on the primary stage. >> > * >> > * @throws IllegalStateException if this method is called on a >> thread >> > * other than the JavaFX Application Thread. >> > * @throws IllegalStateException if this method is called on the >> > * primary stage. >> > * @throws IllegalStateException if this stage is already showing. >> > */ >> > public void showAndWait(); >> > >> > -- Kevin >> > >> >> > From kevin.rushforth at oracle.com Tue Apr 10 17:13:36 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 10 Apr 2012 17:13:36 -0700 Subject: API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking In-Reply-To: References: <4F849B81.5070603@oracle.com> <4F84C097.90103@oracle.com> Message-ID: <4F84CCB0.2010100@oracle.com> The "modality" attribute on a stage is described thusly: *Modality* A stage has one of the following modalities: * |Modality.NONE| - a stage that does not block any other window. * |Modality.WINDOW_MODAL| - a stage that blocks input events from being delivered to all windows from its owner (parent) to its root. Its root is the closest ancestor window without an owner. * |Modality.APPLICATION_MODAL| - a stage that blocks input events from being delivered to all windows from the same application, except for those from its child hierarchy. When a window is blocked by a modal stage its Z-order relative to its ancestors is preserved, and it receives no input events and no window activation events, but continues to animate and render normally. Note that showing a modal stage does not block the calling thread. The |show()| method returns immediately regardless of the modality. The modality must be initialized before the stage is made visible. So yes, we use the term "blocking" to describe what the modal window does to the other windows. Btw, the proposed change to add show and wait will modify the last paragraph of the above to say: Note that showing a modal stage does not necessarily block the caller. The show() method returns immediately regardless of the modality. Use the showAndWait() method if you need to block until the modal stage is closed. So we use the term "modal" to describe whether or not the dialog blocks input and window activation events from being delivered to other windows. I realize that in my description of this I also use "blocking" to describe what the showAndWait method does, which is, that the method waits (that is does not return) until the stage in question is closed, thus blocking the flow of execution of the caller. I hope this clears it up, but if not, let me know. -- Kevin Jeff McDonald wrote: > Hmmmm ... maybe we're talking semantics here. What does Modality mean in > JavaFX? What does "blocking" mean in a JavaFX? > > Cheers, > Jeff > > On Tue, Apr 10, 2012 at 5:21 PM, Kevin Rushforth >> wrote: >> > > >> ** >> The problem with showAsModal is that this method is independent of the >> modality attribute on Stage, so the name would be confusing. >> >> You can have a modal window (a window whose modality is >> Modality.WINDOW_MODAL or Modality.APPLICATION_MODAL), without having it >> block the caller. Conversely, you can have a non-modal window >> (Modality.NONE) that blocks if you call this method. >> >> I am open to a better name for this method, but I don't think it should >> have modal in the name. >> >> -- Kevin >> >> >> >> Jeff McDonald wrote: >> >> Just my 2 cents ... showAsModal or showModal sounds better. When I see >> showAndWait my first question before I read the docs is "what am I waiting >> for?" showAsModal or showModal seem more self-documenting than >> showAndWait. >> >> Cheers, >> Jeff >> >> On Tue, Apr 10, 2012 at 2:45 PM, Richard Bair wrote: >> >> >>> Looks good to me, if nobody objects by tomorrow I'll mark this as >>> approved. >>> >>> Richard >>> >>> On Apr 10, 2012, at 1:43 PM, Kevin Rushforth wrote: >>> >>> >>>> JIRA: http://javafx-jira.kenai.com/browse/RT-19783 >>>> >>>> >>> > We have had several requests for a way to block the caller while a >>> (modal) dialog is shown. The show() method on a Stage is specified to >>> return to the caller immediately regardless of the modality of a stage. >>> This is a good semantic for many applications, but complicates the logic >>> for other applications which don't want to proceed until the dialog is >>> dismissed. It is also needed internally to implement an Alert class (see >>> RT-12643 for example). Swing dialog, for example, JOptionPane, work by >>> blocking the caller until the dialog is dismissed meaning that Swing >>> application programmers are already familiar with that model. >>> >>>> Our proposal for JavaFX 2.2 is to add a new method on Stage, >>>> >>> showAndWait(), which will block the caller until the stage is hidden. Note >>> that while this is primarily useful for modal Stages, there is nothing in >>> the API that restricts it to such. >>> >>> > The proposed method and javadoc are described in the JIRA, but since >>> it is so short, I will also list it here: >>> > >>> >>>> /** >>>> * Show the stage and wait for it to be closed before returning to >>>> >>> the >>> >>>> * caller. This must be called on the FX Application thread. The >>>> >>> stage >>> >>>> * must not already be visible prior to calling this method. This >>>> >>> must not >>> >>>> * be called on the primary stage. >>>> * >>>> * @throws IllegalStateException if this method is called on a >>>> >>> thread >>> >>>> * other than the JavaFX Application Thread. >>>> * @throws IllegalStateException if this method is called on the >>>> * primary stage. >>>> * @throws IllegalStateException if this stage is already showing. >>>> */ >>>> public void showAndWait(); >>>> >>>> -- Kevin >>>> >>>> >>> From tom.schindl at bestsolution.at Tue Apr 10 17:15:34 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 11 Apr 2012 02:15:34 +0200 Subject: API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking In-Reply-To: References: <4F849B81.5070603@oracle.com> <4F84C097.90103@oracle.com> Message-ID: <4F84CD26.6050002@bestsolution.at> * Modal means that the open window (stage) is the only one who can get input focus * Blocking means that the call only returns after the window (stage) is closed but while the window is open Tom Am 11.04.12 01:39, schrieb Jeff McDonald: > Hmmmm ... maybe we're talking semantics here. What does Modality mean in > JavaFX? What does "blocking" mean in a JavaFX? > > Cheers, > Jeff > > On Tue, Apr 10, 2012 at 5:21 PM, Kevin Rushforth > wrote: > >> ** >> The problem with showAsModal is that this method is independent of the >> modality attribute on Stage, so the name would be confusing. >> >> You can have a modal window (a window whose modality is >> Modality.WINDOW_MODAL or Modality.APPLICATION_MODAL), without having it >> block the caller. Conversely, you can have a non-modal window >> (Modality.NONE) that blocks if you call this method. >> >> I am open to a better name for this method, but I don't think it should >> have modal in the name. >> >> -- Kevin >> >> >> >> Jeff McDonald wrote: >> >> Just my 2 cents ... showAsModal or showModal sounds better. When I see >> showAndWait my first question before I read the docs is "what am I waiting >> for?" showAsModal or showModal seem more self-documenting than >> showAndWait. >> >> Cheers, >> Jeff >> >> On Tue, Apr 10, 2012 at 2:45 PM, Richard Bair wrote: >> >>> Looks good to me, if nobody objects by tomorrow I'll mark this as >>> approved. >>> >>> Richard >>> >>> On Apr 10, 2012, at 1:43 PM, Kevin Rushforth wrote: >>> >>>> JIRA: http://javafx-jira.kenai.com/browse/RT-19783 >>>> >>> > We have had several requests for a way to block the caller while a >>> (modal) dialog is shown. The show() method on a Stage is specified to >>> return to the caller immediately regardless of the modality of a stage. >>> This is a good semantic for many applications, but complicates the logic >>> for other applications which don't want to proceed until the dialog is >>> dismissed. It is also needed internally to implement an Alert class (see >>> RT-12643 for example). Swing dialog, for example, JOptionPane, work by >>> blocking the caller until the dialog is dismissed meaning that Swing >>> application programmers are already familiar with that model. >>>> >>>> Our proposal for JavaFX 2.2 is to add a new method on Stage, >>> showAndWait(), which will block the caller until the stage is hidden. Note >>> that while this is primarily useful for modal Stages, there is nothing in >>> the API that restricts it to such. >>>> >>> > The proposed method and javadoc are described in the JIRA, but since >>> it is so short, I will also list it here: >>> > >>>> /** >>>> * Show the stage and wait for it to be closed before returning to >>> the >>>> * caller. This must be called on the FX Application thread. The >>> stage >>>> * must not already be visible prior to calling this method. This >>> must not >>>> * be called on the primary stage. >>>> * >>>> * @throws IllegalStateException if this method is called on a >>> thread >>>> * other than the JavaFX Application Thread. >>>> * @throws IllegalStateException if this method is called on the >>>> * primary stage. >>>> * @throws IllegalStateException if this stage is already showing. >>>> */ >>>> public void showAndWait(); >>>> >>>> -- Kevin >>>> >>> >>> >> -- 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 Tue Apr 10 17:19:34 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 10 Apr 2012 17:19:34 -0700 Subject: API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking In-Reply-To: <4F84CD26.6050002@bestsolution.at> References: <4F849B81.5070603@oracle.com> <4F84C097.90103@oracle.com> <4F84CD26.6050002@bestsolution.at> Message-ID: <4F84CE16.1090103@oracle.com> Exactly. A much more succinct way of putting it than my last response. -- Kevin Tom Schindl wrote: > * Modal means that the open window (stage) is the only one who can get > input focus > * Blocking means that the call only returns after the window (stage) is > closed but while the window is open > > Tom > > Am 11.04.12 01:39, schrieb Jeff McDonald: > >> Hmmmm ... maybe we're talking semantics here. What does Modality mean in >> JavaFX? What does "blocking" mean in a JavaFX? >> >> Cheers, >> Jeff >> >> On Tue, Apr 10, 2012 at 5:21 PM, Kevin Rushforth > >>> wrote: >>> >>> ** >>> The problem with showAsModal is that this method is independent of the >>> modality attribute on Stage, so the name would be confusing. >>> >>> You can have a modal window (a window whose modality is >>> Modality.WINDOW_MODAL or Modality.APPLICATION_MODAL), without having it >>> block the caller. Conversely, you can have a non-modal window >>> (Modality.NONE) that blocks if you call this method. >>> >>> I am open to a better name for this method, but I don't think it should >>> have modal in the name. >>> >>> -- Kevin >>> >>> >>> >>> Jeff McDonald wrote: >>> >>> Just my 2 cents ... showAsModal or showModal sounds better. When I see >>> showAndWait my first question before I read the docs is "what am I waiting >>> for?" showAsModal or showModal seem more self-documenting than >>> showAndWait. >>> >>> Cheers, >>> Jeff >>> >>> On Tue, Apr 10, 2012 at 2:45 PM, Richard Bair wrote: >>> >>> >>>> Looks good to me, if nobody objects by tomorrow I'll mark this as >>>> approved. >>>> >>>> Richard >>>> >>>> On Apr 10, 2012, at 1:43 PM, Kevin Rushforth wrote: >>>> >>>> >>>>> JIRA: http://javafx-jira.kenai.com/browse/RT-19783 >>>>> >>>>> >>>> > We have had several requests for a way to block the caller while a >>>> (modal) dialog is shown. The show() method on a Stage is specified to >>>> return to the caller immediately regardless of the modality of a stage. >>>> This is a good semantic for many applications, but complicates the logic >>>> for other applications which don't want to proceed until the dialog is >>>> dismissed. It is also needed internally to implement an Alert class (see >>>> RT-12643 for example). Swing dialog, for example, JOptionPane, work by >>>> blocking the caller until the dialog is dismissed meaning that Swing >>>> application programmers are already familiar with that model. >>>> >>>>> Our proposal for JavaFX 2.2 is to add a new method on Stage, >>>>> >>>> showAndWait(), which will block the caller until the stage is hidden. Note >>>> that while this is primarily useful for modal Stages, there is nothing in >>>> the API that restricts it to such. >>>> >>>> > The proposed method and javadoc are described in the JIRA, but since >>>> it is so short, I will also list it here: >>>> > >>>> >>>>> /** >>>>> * Show the stage and wait for it to be closed before returning to >>>>> >>>> the >>>> >>>>> * caller. This must be called on the FX Application thread. The >>>>> >>>> stage >>>> >>>>> * must not already be visible prior to calling this method. This >>>>> >>>> must not >>>> >>>>> * be called on the primary stage. >>>>> * >>>>> * @throws IllegalStateException if this method is called on a >>>>> >>>> thread >>>> >>>>> * other than the JavaFX Application Thread. >>>>> * @throws IllegalStateException if this method is called on the >>>>> * primary stage. >>>>> * @throws IllegalStateException if this stage is already showing. >>>>> */ >>>>> public void showAndWait(); >>>>> >>>>> -- Kevin >>>>> >>>>> >>>> > > > From tom.schindl at bestsolution.at Tue Apr 10 17:29:30 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 11 Apr 2012 02:29:30 +0200 Subject: API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking In-Reply-To: <4F849B81.5070603@oracle.com> References: <4F849B81.5070603@oracle.com> Message-ID: <4F84D06A.4030103@bestsolution.at> What I'm not clear about is what are the circumstances the call returns. Is it only when the user hits the stages close icon, someone calls the close/hide method, ...? Maybe referring to close/hide in the javadoc makes it clear? So the revised javadoc could be: -- Show the stage and wait for it to be closed (through user interaction or by calling {@link #close} or {@link #hide}) before returning to the caller. This must be called on the FX Application thread. The stage must not already be visible prior to calling this method. This must not be called on the primary stage. -- Tom Am 10.04.12 22:43, schrieb Kevin Rushforth: > JIRA: http://javafx-jira.kenai.com/browse/RT-19783 > > We have had several requests for a way to block the caller while a > (modal) dialog is shown. The show() method on a Stage is specified to > return to the caller immediately regardless of the modality of a stage. > This is a good semantic for many applications, but complicates the logic > for other applications which don't want to proceed until the dialog is > dismissed. It is also needed internally to implement an Alert class (see > RT-12643 for example). > Swing dialog, for example, JOptionPane, work by blocking the caller > until the dialog is dismissed meaning that Swing application programmers > are already familiar with that model. > > Our proposal for JavaFX 2.2 is to add a new method on Stage, > showAndWait(), which will block the caller until the stage is hidden. > Note that while this is primarily useful for modal Stages, there is > nothing in the API that restricts it to such. > > The proposed method and javadoc are described in the JIRA > , > but since it is so short, I will also list it here: > > /** > * Show the stage and wait for it to be closed before returning > to the > * caller. This must be called on the FX Application thread. The > stage > * must not already be visible prior to calling this method. This > must not > * be called on the primary stage. > * > * @throws IllegalStateException if this method is called on a > thread > * other than the JavaFX Application Thread. > * @throws IllegalStateException if this method is called on the > * primary stage. > * @throws IllegalStateException if this stage is already showing. > */ > public void showAndWait(); > > > -- Kevin > -- 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 Tue Apr 10 19:38:22 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 10 Apr 2012 19:38:22 -0700 Subject: API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking In-Reply-To: <4F84D06A.4030103@bestsolution.at> References: <4F849B81.5070603@oracle.com> <4F84D06A.4030103@bestsolution.at> Message-ID: <4F84EE9E.603@oracle.com> Sure, I could add something like that to make it more clear. Anything that causes the window to be no longer showing will cause showAndWait() to return, which includes calling hide() or closing the window through window system interaction. I just realized that there is something else I need to add to the documentation: nested calls are permitted, but an "outer" call to showAndWait() will never return until all "inner" calls return. This can happen in the following case: { s1.showAndWait(); // blocks until s1 is hidden some instruction after s1 is hidden } ... { s2.showAndWait(); // blocks until s2 is hidden some instruction after s2 is hidden } At this point you have a nested event loop within a nested event loop. If some piece of code calls "s1.hide()" it will not unblock and exit "some instruction after s1 is hidden" until s2 is also closed. -- Kevin Tom Schindl wrote: > What I'm not clear about is what are the circumstances the call returns. > Is it only when the user hits the stages close icon, someone calls the > close/hide method, ...? > > Maybe referring to close/hide in the javadoc makes it clear? > > So the revised javadoc could be: > > -- > Show the stage and wait for it to be closed (through user interaction or > by calling {@link #close} or {@link #hide}) before returning to the > caller. This must be called on the FX Application thread. The stage must > not already be visible prior to calling this method. This must not be > called on the primary stage. > -- > > > Tom > > > > Am 10.04.12 22:43, schrieb Kevin Rushforth: > >> JIRA: http://javafx-jira.kenai.com/browse/RT-19783 >> >> We have had several requests for a way to block the caller while a >> (modal) dialog is shown. The show() method on a Stage is specified to >> return to the caller immediately regardless of the modality of a stage. >> This is a good semantic for many applications, but complicates the logic >> for other applications which don't want to proceed until the dialog is >> dismissed. It is also needed internally to implement an Alert class (see >> RT-12643 for example). >> Swing dialog, for example, JOptionPane, work by blocking the caller >> until the dialog is dismissed meaning that Swing application programmers >> are already familiar with that model. >> >> Our proposal for JavaFX 2.2 is to add a new method on Stage, >> showAndWait(), which will block the caller until the stage is hidden. >> Note that while this is primarily useful for modal Stages, there is >> nothing in the API that restricts it to such. >> >> The proposed method and javadoc are described in the JIRA >> , >> but since it is so short, I will also list it here: >> >> /** >> * Show the stage and wait for it to be closed before returning >> to the >> * caller. This must be called on the FX Application thread. The >> stage >> * must not already be visible prior to calling this method. This >> must not >> * be called on the primary stage. >> * >> * @throws IllegalStateException if this method is called on a >> thread >> * other than the JavaFX Application Thread. >> * @throws IllegalStateException if this method is called on the >> * primary stage. >> * @throws IllegalStateException if this stage is already showing. >> */ >> public void showAndWait(); >> >> >> -- Kevin >> >> > > > From tom.schindl at bestsolution.at Tue Apr 10 23:24:07 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 11 Apr 2012 08:24:07 +0200 Subject: API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking In-Reply-To: <4F84EE9E.603@oracle.com> References: <4F849B81.5070603@oracle.com> <4F84D06A.4030103@bestsolution.at> <4F84EE9E.603@oracle.com> Message-ID: <4F852387.9010409@bestsolution.at> Hi Kevin, Something else in this context came to my mind. Isn't it needed for Dialogs for example that their visibility is bound to the visibility of some parent stage? Say I have an application with a "main" stage and a none modal dialog stage, I think now closing the "main" stage should also bring down the dialog stage. Beside that a dialog stage should not have a Dock-Item showing for example. So I guess to really implement dialogs you'll also have to add a new constructor "Stage(Stage parent)" or are you going to add a new class which can be used as the super-class for that like FXDialog? Anyways this is maybe a different discussion but it just came to my mind because the current API doesn't allow me to implement my own dialog stages who don't show up in the dock. Tom Am 11.04.12 04:38, schrieb Kevin Rushforth: > Sure, I could add something like that to make it more clear. Anything > that causes the window to be no longer showing will cause showAndWait() > to return, which includes calling hide() or closing the window through > window system interaction. > > I just realized that there is something else I need to add to the > documentation: nested calls are permitted, but an "outer" call to > showAndWait() will never return until all "inner" calls return. This can > happen in the following case: > > { > s1.showAndWait(); // blocks until s1 is hidden > some instruction after s1 is hidden > } > > ... > > { > s2.showAndWait(); // blocks until s2 is hidden > some instruction after s2 is hidden > } > > At this point you have a nested event loop within a nested event loop. > If some piece of code calls "s1.hide()" it will not unblock and exit > "some instruction after s1 is hidden" until s2 is also closed. > > -- Kevin > > > Tom Schindl wrote: >> What I'm not clear about is what are the circumstances the call returns. >> Is it only when the user hits the stages close icon, someone calls the >> close/hide method, ...? >> >> Maybe referring to close/hide in the javadoc makes it clear? >> >> So the revised javadoc could be: >> >> -- >> Show the stage and wait for it to be closed (through user interaction or >> by calling {@link #close} or {@link #hide}) before returning to the >> caller. This must be called on the FX Application thread. The stage must >> not already be visible prior to calling this method. This must not be >> called on the primary stage. >> -- >> >> >> Tom >> >> >> >> Am 10.04.12 22:43, schrieb Kevin Rushforth: >> >>> JIRA: http://javafx-jira.kenai.com/browse/RT-19783 >>> >>> We have had several requests for a way to block the caller while a >>> (modal) dialog is shown. The show() method on a Stage is specified to >>> return to the caller immediately regardless of the modality of a stage. >>> This is a good semantic for many applications, but complicates the logic >>> for other applications which don't want to proceed until the dialog is >>> dismissed. It is also needed internally to implement an Alert class (see >>> RT-12643 for example). >>> Swing dialog, for example, JOptionPane, work by blocking the caller >>> until the dialog is dismissed meaning that Swing application programmers >>> are already familiar with that model. >>> >>> Our proposal for JavaFX 2.2 is to add a new method on Stage, >>> showAndWait(), which will block the caller until the stage is hidden. >>> Note that while this is primarily useful for modal Stages, there is >>> nothing in the API that restricts it to such. >>> >>> The proposed method and javadoc are described in the JIRA >>> , >>> but since it is so short, I will also list it here: >>> >>> /** >>> * Show the stage and wait for it to be closed before returning >>> to the >>> * caller. This must be called on the FX Application thread. The >>> stage >>> * must not already be visible prior to calling this method. This >>> must not >>> * be called on the primary stage. >>> * >>> * @throws IllegalStateException if this method is called on a >>> thread >>> * other than the JavaFX Application Thread. >>> * @throws IllegalStateException if this method is called on the >>> * primary stage. >>> * @throws IllegalStateException if this stage is already showing. >>> */ >>> public void showAndWait(); >>> >>> >>> -- Kevin >>> >>> >> >> >> -- 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 Wed Apr 11 03:33:29 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 11 Apr 2012 10:33:29 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-12663: Add DnD support to JFXPanel on Windows Message-ID: <20120411103333.033AA47FD8@hg.openjdk.java.net> Changeset: b25e2b26045e Author: Alexey Semenyuk (alexey.semenyuk at oracle.com) Date: 2012-04-11 14:16 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/b25e2b26045e RT-12663: Add DnD support to JFXPanel on Windows + javafx-ui-common/src/com/sun/javafx/embed/EmbeddedSceneDragSourceInterface.java + javafx-ui-common/src/com/sun/javafx/embed/EmbeddedSceneDragStartListenerInterface.java + javafx-ui-common/src/com/sun/javafx/embed/EmbeddedSceneDropTargetInterface.java ! javafx-ui-common/src/com/sun/javafx/embed/EmbeddedSceneInterface.java ! javafx-ui-common/src/com/sun/javafx/tk/TKDropEvent.java ! javafx-ui-common/src/com/sun/javafx/tk/TKScene.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/DragEvent.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubScene.java From artem.ananiev at oracle.com Wed Apr 11 03:50:42 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 11 Apr 2012 14:50:42 +0400 Subject: API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking In-Reply-To: <4F84EE9E.603@oracle.com> References: <4F849B81.5070603@oracle.com> <4F84D06A.4030103@bestsolution.at> <4F84EE9E.603@oracle.com> Message-ID: <4F856202.5090602@oracle.com> Hi, Kevin, On 4/11/2012 6:38 AM, Kevin Rushforth wrote: > Sure, I could add something like that to make it more clear. Anything > that causes the window to be no longer showing will cause showAndWait() > to return, which includes calling hide() or closing the window through > window system interaction. > > I just realized that there is something else I need to add to the > documentation: nested calls are permitted, but an "outer" call to > showAndWait() will never return until all "inner" calls return. This can > happen in the following case: > > { > s1.showAndWait(); // blocks until s1 is hidden > some instruction after s1 is hidden > } > > ... > > { > s2.showAndWait(); // blocks until s2 is hidden > some instruction after s2 is hidden > } > > At this point you have a nested event loop within a nested event loop. > If some piece of code calls "s1.hide()" it will not unblock and exit > "some instruction after s1 is hidden" until s2 is also closed. this is exactly the problem we have in AWT/Swing: we don't strictly specify our behavior for nested modal dialogs in our JavaDoc. It's good to see JavaFX specification is (will be) better in this case :) However, it's not enough, even if we showAndWait s1 only, without s2. Given that s1.hide() can only be called on JavaFX thread, it will likely be in { s1.hide/close(); some instructions here } These instructions are executed before "some instruction after s1 is hidden", despite s1.hide() has already been called. What's even worse, there may be many code frames in the stack before the last event handler, and all of them should be exited to proceed with the code after s1.showAndWait(). Thanks, Artem > -- Kevin > > > Tom Schindl wrote: >> What I'm not clear about is what are the circumstances the call returns. >> Is it only when the user hits the stages close icon, someone calls the >> close/hide method, ...? >> >> Maybe referring to close/hide in the javadoc makes it clear? >> >> So the revised javadoc could be: >> >> -- >> Show the stage and wait for it to be closed (through user interaction or >> by calling {@link #close} or {@link #hide}) before returning to the >> caller. This must be called on the FX Application thread. The stage must >> not already be visible prior to calling this method. This must not be >> called on the primary stage. >> -- >> >> >> Tom >> >> >> >> Am 10.04.12 22:43, schrieb Kevin Rushforth: >>> JIRA: http://javafx-jira.kenai.com/browse/RT-19783 >>> >>> We have had several requests for a way to block the caller while a >>> (modal) dialog is shown. The show() method on a Stage is specified to >>> return to the caller immediately regardless of the modality of a stage. >>> This is a good semantic for many applications, but complicates the logic >>> for other applications which don't want to proceed until the dialog is >>> dismissed. It is also needed internally to implement an Alert class (see >>> RT-12643 for example). >>> Swing dialog, for example, JOptionPane, work by blocking the caller >>> until the dialog is dismissed meaning that Swing application programmers >>> are already familiar with that model. >>> >>> Our proposal for JavaFX 2.2 is to add a new method on Stage, >>> showAndWait(), which will block the caller until the stage is hidden. >>> Note that while this is primarily useful for modal Stages, there is >>> nothing in the API that restricts it to such. >>> >>> The proposed method and javadoc are described in the JIRA >>> , >>> >>> but since it is so short, I will also list it here: >>> >>> /** >>> * Show the stage and wait for it to be closed before returning >>> to the >>> * caller. This must be called on the FX Application thread. The >>> stage >>> * must not already be visible prior to calling this method. This >>> must not >>> * be called on the primary stage. >>> * >>> * @throws IllegalStateException if this method is called on a >>> thread >>> * other than the JavaFX Application Thread. >>> * @throws IllegalStateException if this method is called on the >>> * primary stage. >>> * @throws IllegalStateException if this stage is already showing. >>> */ >>> public void showAndWait(); >>> >>> >>> -- Kevin >>> >> >> From kevin.rushforth at oracle.com Wed Apr 11 04:06:49 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 11 Apr 2012 04:06:49 -0700 Subject: API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking In-Reply-To: <4F856202.5090602@oracle.com> References: <4F849B81.5070603@oracle.com> <4F84D06A.4030103@bestsolution.at> <4F84EE9E.603@oracle.com> <4F856202.5090602@oracle.com> Message-ID: <4F8565C9.3040805@oracle.com> Thanks, Artem! Good suggestion, and I will add that to the description, since someone may be puzzled by the behavior if we don't. -- Kevin Artem Ananiev wrote: > Hi, Kevin, > > On 4/11/2012 6:38 AM, Kevin Rushforth wrote: >> Sure, I could add something like that to make it more clear. Anything >> that causes the window to be no longer showing will cause showAndWait() >> to return, which includes calling hide() or closing the window through >> window system interaction. >> >> I just realized that there is something else I need to add to the >> documentation: nested calls are permitted, but an "outer" call to >> showAndWait() will never return until all "inner" calls return. This can >> happen in the following case: >> >> { >> s1.showAndWait(); // blocks until s1 is hidden >> some instruction after s1 is hidden >> } >> >> ... >> >> { >> s2.showAndWait(); // blocks until s2 is hidden >> some instruction after s2 is hidden >> } >> >> At this point you have a nested event loop within a nested event loop. >> If some piece of code calls "s1.hide()" it will not unblock and exit >> "some instruction after s1 is hidden" until s2 is also closed. > > this is exactly the problem we have in AWT/Swing: we don't strictly > specify our behavior for nested modal dialogs in our JavaDoc. It's > good to see JavaFX specification is (will be) better in this case :) > > However, it's not enough, even if we showAndWait s1 only, without s2. > Given that s1.hide() can only be called on JavaFX thread, it will > likely be in > > { > s1.hide/close(); > some instructions here > } > > These instructions are executed before "some instruction after s1 is > hidden", despite s1.hide() has already been called. What's even worse, > there may be many code frames in the stack before the last event > handler, and all of them should be exited to proceed with the code > after s1.showAndWait(). > > Thanks, > > Artem > >> -- Kevin >> >> >> Tom Schindl wrote: >>> What I'm not clear about is what are the circumstances the call >>> returns. >>> Is it only when the user hits the stages close icon, someone calls the >>> close/hide method, ...? >>> >>> Maybe referring to close/hide in the javadoc makes it clear? >>> >>> So the revised javadoc could be: >>> >>> -- >>> Show the stage and wait for it to be closed (through user >>> interaction or >>> by calling {@link #close} or {@link #hide}) before returning to the >>> caller. This must be called on the FX Application thread. The stage >>> must >>> not already be visible prior to calling this method. This must not be >>> called on the primary stage. >>> -- >>> >>> >>> Tom >>> >>> >>> >>> Am 10.04.12 22:43, schrieb Kevin Rushforth: >>>> JIRA: http://javafx-jira.kenai.com/browse/RT-19783 >>>> >>>> We have had several requests for a way to block the caller while a >>>> (modal) dialog is shown. The show() method on a Stage is specified to >>>> return to the caller immediately regardless of the modality of a >>>> stage. >>>> This is a good semantic for many applications, but complicates the >>>> logic >>>> for other applications which don't want to proceed until the dialog is >>>> dismissed. It is also needed internally to implement an Alert class >>>> (see >>>> RT-12643 for example). >>>> Swing dialog, for example, JOptionPane, work by blocking the caller >>>> until the dialog is dismissed meaning that Swing application >>>> programmers >>>> are already familiar with that model. >>>> >>>> Our proposal for JavaFX 2.2 is to add a new method on Stage, >>>> showAndWait(), which will block the caller until the stage is hidden. >>>> Note that while this is primarily useful for modal Stages, there is >>>> nothing in the API that restricts it to such. >>>> >>>> The proposed method and javadoc are described in the JIRA >>>> , >>>> >>>> >>>> but since it is so short, I will also list it here: >>>> >>>> /** >>>> * Show the stage and wait for it to be closed before returning >>>> to the >>>> * caller. This must be called on the FX Application thread. The >>>> stage >>>> * must not already be visible prior to calling this method. This >>>> must not >>>> * be called on the primary stage. >>>> * >>>> * @throws IllegalStateException if this method is called on a >>>> thread >>>> * other than the JavaFX Application Thread. >>>> * @throws IllegalStateException if this method is called on the >>>> * primary stage. >>>> * @throws IllegalStateException if this stage is already showing. >>>> */ >>>> public void showAndWait(); >>>> >>>> >>>> -- Kevin >>>> >>> >>> From deep.blue.6802 at gmail.com Wed Apr 11 09:58:30 2012 From: deep.blue.6802 at gmail.com (Jeff McDonald) Date: Wed, 11 Apr 2012 10:58:30 -0600 Subject: API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking In-Reply-To: <4F8565C9.3040805@oracle.com> References: <4F849B81.5070603@oracle.com> <4F84D06A.4030103@bestsolution.at> <4F84EE9E.603@oracle.com> <4F856202.5090602@oracle.com> <4F8565C9.3040805@oracle.com> Message-ID: I put together a truth table of sorts to help me visualize the possible states. It's an ASCII chart so it needs to be viewed using a monspaced font for everything to line up. +--------------------------------+----------------------------------------+--------------------------------------------+ | Modality.NONE | Modality.WINDOW | Modality.APPLICATION | | initModality(Modality.NONE) | initModality(Modality.WINDOW_MODAL) | initModality(Modality.WINDOW_MODAL) | +-------------------+--------------------------------+----------------------------------------+--------------------------------------------+ | un-blocked | Supported (This is typical) | Supported | Supported | | show() | 1. initModality(Modality.NONE) | 1. initModality(Modality.WINDOW_MODAL) | 1. initModality(Modality.WINDOW_MODAL) | | | 2. show() | 2. show() | 2. show() | | | or just | | | | | 1. show() | | | +-------------------+--------------------------------+----------------------------------------+--------------------------------------------+ | blocked | Unsupported | Supported | Supported | | showAndWait() | Throws exception | 1. initModality(Modality.WINDOW_MODAL) | 1. initModality(Modality.APPLICATION_MODAL)| | (proposed) | | 2. showAndWait() | 2. showAndWait() | +-------------------+--------------------------------+----------------------------------------+--------------------------------------------+ I propose the following changes: 1. show() remains the same as it is now. 2. add showWindowModal(boolean wait) 3. add showAppModal(boolean wait) 4. remove initModality() 5. Add Tom's description of "modal" and "blocking" to the JavaDocs. His wording is clear and concise. The justification: The API is clearer and easier to understand because only one method call is required to execute the desired behavior instead of two method calls. The second benefit is that a single method call eliminates the potential of calling the initModality and show() / showAndWait() methods in the incorrect order. On Wed, Apr 11, 2012 at 5:06 AM, Kevin Rushforth wrote: > Thanks, Artem! > > Good suggestion, and I will add that to the description, since someone may > be puzzled by the behavior if we don't. > > -- Kevin > > > > Artem Ananiev wrote: > >> Hi, Kevin, >> >> On 4/11/2012 6:38 AM, Kevin Rushforth wrote: >> >>> Sure, I could add something like that to make it more clear. Anything >>> that causes the window to be no longer showing will cause showAndWait() >>> to return, which includes calling hide() or closing the window through >>> window system interaction. >>> >>> I just realized that there is something else I need to add to the >>> documentation: nested calls are permitted, but an "outer" call to >>> showAndWait() will never return until all "inner" calls return. This can >>> happen in the following case: >>> >>> { >>> s1.showAndWait(); // blocks until s1 is hidden >>> some instruction after s1 is hidden >>> } >>> >>> ... >>> >>> { >>> s2.showAndWait(); // blocks until s2 is hidden >>> some instruction after s2 is hidden >>> } >>> >>> At this point you have a nested event loop within a nested event loop. >>> If some piece of code calls "s1.hide()" it will not unblock and exit >>> "some instruction after s1 is hidden" until s2 is also closed. >>> >> >> this is exactly the problem we have in AWT/Swing: we don't strictly >> specify our behavior for nested modal dialogs in our JavaDoc. It's good to >> see JavaFX specification is (will be) better in this case :) >> >> However, it's not enough, even if we showAndWait s1 only, without s2. >> Given that s1.hide() can only be called on JavaFX thread, it will likely be >> in >> >> { >> s1.hide/close(); >> some instructions here >> } >> >> These instructions are executed before "some instruction after s1 is >> hidden", despite s1.hide() has already been called. What's even worse, >> there may be many code frames in the stack before the last event handler, >> and all of them should be exited to proceed with the code after >> s1.showAndWait(). >> >> Thanks, >> >> Artem >> >> -- Kevin >>> >>> >>> Tom Schindl wrote: >>> >>>> What I'm not clear about is what are the circumstances the call returns. >>>> Is it only when the user hits the stages close icon, someone calls the >>>> close/hide method, ...? >>>> >>>> Maybe referring to close/hide in the javadoc makes it clear? >>>> >>>> So the revised javadoc could be: >>>> >>>> -- >>>> Show the stage and wait for it to be closed (through user interaction or >>>> by calling {@link #close} or {@link #hide}) before returning to the >>>> caller. This must be called on the FX Application thread. The stage must >>>> not already be visible prior to calling this method. This must not be >>>> called on the primary stage. >>>> -- >>>> >>>> >>>> Tom >>>> >>>> >>>> >>>> Am 10.04.12 22:43, schrieb Kevin Rushforth: >>>> >>>>> JIRA: http://javafx-jira.kenai.com/**browse/RT-19783 >>>>> >>>>> We have had several requests for a way to block the caller while a >>>>> (modal) dialog is shown. The show() method on a Stage is specified to >>>>> return to the caller immediately regardless of the modality of a stage. >>>>> This is a good semantic for many applications, but complicates the >>>>> logic >>>>> for other applications which don't want to proceed until the dialog is >>>>> dismissed. It is also needed internally to implement an Alert class >>>>> (see >>>>> RT-12643 > >>>>> for example). >>>>> Swing dialog, for example, JOptionPane, work by blocking the caller >>>>> until the dialog is dismissed meaning that Swing application >>>>> programmers >>>>> are already familiar with that model. >>>>> >>>>> Our proposal for JavaFX 2.2 is to add a new method on Stage, >>>>> showAndWait(), which will block the caller until the stage is hidden. >>>>> Note that while this is primarily useful for modal Stages, there is >>>>> nothing in the API that restricts it to such. >>>>> >>>>> The proposed method and javadoc are described in the JIRA >>>>> >>>> focusedCommentId=110277&page=**com.atlassian.jira.plugin.** >>>>> system.issuetabpanels:comment-**tabpanel#comment-110277>, >>>>> >>>>> >>>>> but since it is so short, I will also list it here: >>>>> >>>>> /** >>>>> * Show the stage and wait for it to be closed before returning >>>>> to the >>>>> * caller. This must be called on the FX Application thread. The >>>>> stage >>>>> * must not already be visible prior to calling this method. This >>>>> must not >>>>> * be called on the primary stage. >>>>> * >>>>> * @throws IllegalStateException if this method is called on a >>>>> thread >>>>> * other than the JavaFX Application Thread. >>>>> * @throws IllegalStateException if this method is called on the >>>>> * primary stage. >>>>> * @throws IllegalStateException if this stage is already showing. >>>>> */ >>>>> public void showAndWait(); >>>>> >>>>> >>>>> -- Kevin >>>>> >>>>> >>>> >>>> From tom.schindl at bestsolution.at Wed Apr 11 10:08:34 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 11 Apr 2012 19:08:34 +0200 Subject: API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking In-Reply-To: References: <4F849B81.5070603@oracle.com> <4F84D06A.4030103@bestsolution.at> <4F84EE9E.603@oracle.com> <4F856202.5090602@oracle.com> <4F8565C9.3040805@oracle.com> Message-ID: <4F85BA92.3000808@bestsolution.at> Am 11.04.12 18:58, schrieb Jeff McDonald: > I put together a truth table of sorts to help me visualize the possible > states. It's an ASCII chart so it needs to be viewed using a monspaced font > for everything to line up. > > > +--------------------------------+----------------------------------------+--------------------------------------------+ > | Modality.NONE | Modality.WINDOW > | Modality.APPLICATION | > | initModality(Modality.NONE) | initModality(Modality.WINDOW_MODAL) > | initModality(Modality.WINDOW_MODAL) | > +-------------------+--------------------------------+----------------------------------------+--------------------------------------------+ > | un-blocked | Supported (This is typical) | Supported > | Supported | > | show() | 1. initModality(Modality.NONE) | 1. > initModality(Modality.WINDOW_MODAL) | 1. > initModality(Modality.WINDOW_MODAL) | > | | 2. show() | 2. show() > | 2. show() | > | | or just | > | | > | | 1. show() | > | | > +-------------------+--------------------------------+----------------------------------------+--------------------------------------------+ > | blocked | Unsupported | Supported > | Supported | > | showAndWait() | Throws exception | 1. > initModality(Modality.WINDOW_MODAL) | 1. > initModality(Modality.APPLICATION_MODAL)| > | (proposed) | | 2. showAndWait() > | 2. showAndWait() | > +-------------------+--------------------------------+----------------------------------------+--------------------------------------------+ > > I propose the following changes: > 1. show() remains the same as it is now. > 2. add showWindowModal(boolean wait) > 3. add showAppModal(boolean wait) > 4. remove initModality() > 5. Add Tom's description of "modal" and "blocking" to the JavaDocs. His > wording is clear and concise. > > The justification: The API is clearer and easier to understand because only > one method call is required to execute the desired behavior instead of two > method calls. The second benefit is that a single method call eliminates > the potential of calling the initModality and show() / showAndWait() > methods in the incorrect order. > This will break the backwards compat of a stage so I think it is too late for such an API. 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 kevin.rushforth at oracle.com Wed Apr 11 10:19:46 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 11 Apr 2012 10:19:46 -0700 Subject: API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking In-Reply-To: <4F85BA92.3000808@bestsolution.at> References: <4F849B81.5070603@oracle.com> <4F84D06A.4030103@bestsolution.at> <4F84EE9E.603@oracle.com> <4F856202.5090602@oracle.com> <4F8565C9.3040805@oracle.com> <4F85BA92.3000808@bestsolution.at> Message-ID: <4F85BD32.7070007@oracle.com> > > This will break the backwards compat of a stage so I think it is too > late for such an API. Right. We need to keep the existing API unmodified. Adding a single method is the easiest way to compatibly extend the API and keep the ideas of modality separate from whether or not the caller is blocked. -- Kevin Tom Schindl wrote: > Am 11.04.12 18:58, schrieb Jeff McDonald: > >> I put together a truth table of sorts to help me visualize the possible >> states. It's an ASCII chart so it needs to be viewed using a monspaced font >> for everything to line up. >> >> >> +--------------------------------+----------------------------------------+--------------------------------------------+ >> | Modality.NONE | Modality.WINDOW >> | Modality.APPLICATION | >> | initModality(Modality.NONE) | initModality(Modality.WINDOW_MODAL) >> | initModality(Modality.WINDOW_MODAL) | >> +-------------------+--------------------------------+----------------------------------------+--------------------------------------------+ >> | un-blocked | Supported (This is typical) | Supported >> | Supported | >> | show() | 1. initModality(Modality.NONE) | 1. >> initModality(Modality.WINDOW_MODAL) | 1. >> initModality(Modality.WINDOW_MODAL) | >> | | 2. show() | 2. show() >> | 2. show() | >> | | or just | >> | | >> | | 1. show() | >> | | >> +-------------------+--------------------------------+----------------------------------------+--------------------------------------------+ >> | blocked | Unsupported | Supported >> | Supported | >> | showAndWait() | Throws exception | 1. >> initModality(Modality.WINDOW_MODAL) | 1. >> initModality(Modality.APPLICATION_MODAL)| >> | (proposed) | | 2. showAndWait() >> | 2. showAndWait() | >> +-------------------+--------------------------------+----------------------------------------+--------------------------------------------+ >> >> I propose the following changes: >> 1. show() remains the same as it is now. >> 2. add showWindowModal(boolean wait) >> 3. add showAppModal(boolean wait) >> 4. remove initModality() >> 5. Add Tom's description of "modal" and "blocking" to the JavaDocs. His >> wording is clear and concise. >> >> The justification: The API is clearer and easier to understand because only >> one method call is required to execute the desired behavior instead of two >> method calls. The second benefit is that a single method call eliminates >> the potential of calling the initModality and show() / showAndWait() >> methods in the incorrect order. >> >> > > This will break the backwards compat of a stage so I think it is too > late for such an API. > > Tom > > From deep.blue.6802 at gmail.com Wed Apr 11 10:24:31 2012 From: deep.blue.6802 at gmail.com (Jeff McDonald) Date: Wed, 11 Apr 2012 11:24:31 -0600 Subject: API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking In-Reply-To: <4F85BD32.7070007@oracle.com> References: <4F849B81.5070603@oracle.com> <4F84D06A.4030103@bestsolution.at> <4F84EE9E.603@oracle.com> <4F856202.5090602@oracle.com> <4F8565C9.3040805@oracle.com> <4F85BA92.3000808@bestsolution.at> <4F85BD32.7070007@oracle.com> Message-ID: Seriously? So backwards compatibility is a requirement of JavaFX at this point? Or are you saying that the benefit of the proposal doesn't outweigh breaking backwards compatibility? On Wed, Apr 11, 2012 at 11:19 AM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > >> This will break the backwards compat of a stage so I think it is too >> late for such an API. >> > > Right. We need to keep the existing API unmodified. Adding a single method > is the easiest way to compatibly extend the API and keep the ideas of > modality separate from whether or not the caller is blocked. > > > -- Kevin > > > Tom Schindl wrote: > >> Am 11.04.12 18:58, schrieb Jeff McDonald: >> >> >>> I put together a truth table of sorts to help me visualize the possible >>> states. It's an ASCII chart so it needs to be viewed using a monspaced >>> font >>> for everything to line up. >>> >>> >>> +-----------------------------**---+--------------------------** >>> --------------+---------------**-----------------------------+ >>> | Modality.NONE | Modality.WINDOW >>> | Modality.APPLICATION | >>> | initModality(Modality.NONE) | initModality(Modality.WINDOW_** >>> MODAL) >>> | initModality(Modality.WINDOW_**MODAL) | >>> +-------------------+---------**-----------------------+------** >>> ------------------------------**----+-------------------------** >>> -------------------+ >>> | un-blocked | Supported (This is typical) | Supported >>> | Supported | >>> | show() | 1. initModality(Modality.NONE) | 1. >>> initModality(Modality.WINDOW_**MODAL) | 1. >>> initModality(Modality.WINDOW_**MODAL) | >>> | | 2. show() | 2. show() >>> | 2. show() | >>> | | or just | >>> | | >>> | | 1. show() | >>> | | >>> +-------------------+---------**-----------------------+------** >>> ------------------------------**----+-------------------------** >>> -------------------+ >>> | blocked | Unsupported | Supported >>> | Supported | >>> | showAndWait() | Throws exception | 1. >>> initModality(Modality.WINDOW_**MODAL) | 1. >>> initModality(Modality.**APPLICATION_MODAL)| >>> | (proposed) | | 2. showAndWait() >>> | 2. showAndWait() | >>> +-------------------+---------**-----------------------+------** >>> ------------------------------**----+-------------------------** >>> -------------------+ >>> >>> I propose the following changes: >>> 1. show() remains the same as it is now. >>> 2. add showWindowModal(boolean wait) >>> 3. add showAppModal(boolean wait) >>> 4. remove initModality() >>> 5. Add Tom's description of "modal" and "blocking" to the JavaDocs. His >>> wording is clear and concise. >>> >>> The justification: The API is clearer and easier to understand because >>> only >>> one method call is required to execute the desired behavior instead of >>> two >>> method calls. The second benefit is that a single method call eliminates >>> the potential of calling the initModality and show() / showAndWait() >>> methods in the incorrect order. >>> >>> >>> >> >> This will break the backwards compat of a stage so I think it is too >> late for such an API. >> >> Tom >> >> >> > From kevin.rushforth at oracle.com Wed Apr 11 10:26:02 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 11 Apr 2012 10:26:02 -0700 Subject: API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking In-Reply-To: References: <4F849B81.5070603@oracle.com> <4F84D06A.4030103@bestsolution.at> <4F84EE9E.603@oracle.com> <4F856202.5090602@oracle.com> <4F8565C9.3040805@oracle.com> <4F85BA92.3000808@bestsolution.at> <4F85BD32.7070007@oracle.com> Message-ID: <4F85BEAA.8010607@oracle.com> Both. What you propose would be a much bigger design change, and I am not sold on the need anyway. Also, there is a strong desire to not break compatibility. -- Kevin Jeff McDonald wrote: > Seriously? So backwards compatibility is a requirement of JavaFX at this > point? Or are you saying that the benefit of the proposal doesn't outweigh > breaking backwards compatibility? > > On Wed, Apr 11, 2012 at 11:19 AM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > > >>> This will break the backwards compat of a stage so I think it is too >>> late for such an API. >>> >>> >> Right. We need to keep the existing API unmodified. Adding a single method >> is the easiest way to compatibly extend the API and keep the ideas of >> modality separate from whether or not the caller is blocked. >> >> >> -- Kevin >> >> >> Tom Schindl wrote: >> >> >>> Am 11.04.12 18:58, schrieb Jeff McDonald: >>> >>> >>> >>>> I put together a truth table of sorts to help me visualize the possible >>>> states. It's an ASCII chart so it needs to be viewed using a monspaced >>>> font >>>> for everything to line up. >>>> >>>> >>>> +-----------------------------**---+--------------------------** >>>> --------------+---------------**-----------------------------+ >>>> | Modality.NONE | Modality.WINDOW >>>> | Modality.APPLICATION | >>>> | initModality(Modality.NONE) | initModality(Modality.WINDOW_** >>>> MODAL) >>>> | initModality(Modality.WINDOW_**MODAL) | >>>> +-------------------+---------**-----------------------+------** >>>> ------------------------------**----+-------------------------** >>>> -------------------+ >>>> | un-blocked | Supported (This is typical) | Supported >>>> | Supported | >>>> | show() | 1. initModality(Modality.NONE) | 1. >>>> initModality(Modality.WINDOW_**MODAL) | 1. >>>> initModality(Modality.WINDOW_**MODAL) | >>>> | | 2. show() | 2. show() >>>> | 2. show() | >>>> | | or just | >>>> | | >>>> | | 1. show() | >>>> | | >>>> +-------------------+---------**-----------------------+------** >>>> ------------------------------**----+-------------------------** >>>> -------------------+ >>>> | blocked | Unsupported | Supported >>>> | Supported | >>>> | showAndWait() | Throws exception | 1. >>>> initModality(Modality.WINDOW_**MODAL) | 1. >>>> initModality(Modality.**APPLICATION_MODAL)| >>>> | (proposed) | | 2. showAndWait() >>>> | 2. showAndWait() | >>>> +-------------------+---------**-----------------------+------** >>>> ------------------------------**----+-------------------------** >>>> -------------------+ >>>> >>>> I propose the following changes: >>>> 1. show() remains the same as it is now. >>>> 2. add showWindowModal(boolean wait) >>>> 3. add showAppModal(boolean wait) >>>> 4. remove initModality() >>>> 5. Add Tom's description of "modal" and "blocking" to the JavaDocs. His >>>> wording is clear and concise. >>>> >>>> The justification: The API is clearer and easier to understand because >>>> only >>>> one method call is required to execute the desired behavior instead of >>>> two >>>> method calls. The second benefit is that a single method call eliminates >>>> the potential of calling the initModality and show() / showAndWait() >>>> methods in the incorrect order. >>>> >>>> >>>> >>>> >>> This will break the backwards compat of a stage so I think it is too >>> late for such an API. >>> >>> Tom >>> >>> >>> >>> From deep.blue.6802 at gmail.com Wed Apr 11 10:31:29 2012 From: deep.blue.6802 at gmail.com (Jeff McDonald) Date: Wed, 11 Apr 2012 11:31:29 -0600 Subject: API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking In-Reply-To: <4F85BEAA.8010607@oracle.com> References: <4F849B81.5070603@oracle.com> <4F84D06A.4030103@bestsolution.at> <4F84EE9E.603@oracle.com> <4F856202.5090602@oracle.com> <4F8565C9.3040805@oracle.com> <4F85BA92.3000808@bestsolution.at> <4F85BD32.7070007@oracle.com> <4F85BEAA.8010607@oracle.com> Message-ID: I disagree with your conclusion, but I respect your decision. Thank you for considering my suggestions. Cheers, Jeff On Wed, Apr 11, 2012 at 11:26 AM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > Both. What you propose would be a much bigger design change, and I am not > sold on the need anyway. Also, there is a strong desire to not break > compatibility. > > > -- Kevin > > > Jeff McDonald wrote: > >> Seriously? So backwards compatibility is a requirement of JavaFX at this >> point? Or are you saying that the benefit of the proposal doesn't outweigh >> breaking backwards compatibility? >> >> On Wed, Apr 11, 2012 at 11:19 AM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >> >> >>> This will break the backwards compat of a stage so I think it is too >>>> late for such an API. >>>> >>>> >>>> >>> Right. We need to keep the existing API unmodified. Adding a single >>> method >>> is the easiest way to compatibly extend the API and keep the ideas of >>> modality separate from whether or not the caller is blocked. >>> >>> >>> -- Kevin >>> >>> >>> Tom Schindl wrote: >>> >>> >>> >>>> Am 11.04.12 18:58, schrieb Jeff McDonald: >>>> >>>> >>>> >>>> >>>>> I put together a truth table of sorts to help me visualize the possible >>>>> states. It's an ASCII chart so it needs to be viewed using a monspaced >>>>> font >>>>> for everything to line up. >>>>> >>>>> >>>>> +-----------------------------****---+------------------------**--** >>>>> --------------+---------------****----------------------------**-+ >>>>> | Modality.NONE | Modality.WINDOW >>>>> | Modality.APPLICATION | >>>>> | initModality(Modality.NONE) | initModality(Modality.WINDOW_**** >>>>> MODAL) >>>>> | initModality(Modality.WINDOW_****MODAL) | >>>>> +-------------------+---------****-----------------------+----**--** >>>>> ------------------------------****----+-----------------------**--** >>>>> >>>>> -------------------+ >>>>> | un-blocked | Supported (This is typical) | Supported >>>>> | Supported | >>>>> | show() | 1. initModality(Modality.NONE) | 1. >>>>> initModality(Modality.WINDOW_****MODAL) | 1. >>>>> initModality(Modality.WINDOW_****MODAL) | >>>>> >>>>> | | 2. show() | 2. show() >>>>> | 2. show() | >>>>> | | or just | >>>>> | | >>>>> | | 1. show() | >>>>> | | >>>>> +-------------------+---------****-----------------------+----**--** >>>>> ------------------------------****----+-----------------------**--** >>>>> >>>>> -------------------+ >>>>> | blocked | Unsupported | Supported >>>>> | Supported | >>>>> | showAndWait() | Throws exception | 1. >>>>> initModality(Modality.WINDOW_****MODAL) | 1. >>>>> initModality(Modality.****APPLICATION_MODAL)| >>>>> >>>>> | (proposed) | | 2. showAndWait() >>>>> | 2. showAndWait() | >>>>> +-------------------+---------****-----------------------+----**--** >>>>> ------------------------------****----+-----------------------**--** >>>>> >>>>> -------------------+ >>>>> >>>>> I propose the following changes: >>>>> 1. show() remains the same as it is now. >>>>> 2. add showWindowModal(boolean wait) >>>>> 3. add showAppModal(boolean wait) >>>>> 4. remove initModality() >>>>> 5. Add Tom's description of "modal" and "blocking" to the JavaDocs. His >>>>> wording is clear and concise. >>>>> >>>>> The justification: The API is clearer and easier to understand because >>>>> only >>>>> one method call is required to execute the desired behavior instead of >>>>> two >>>>> method calls. The second benefit is that a single method call >>>>> eliminates >>>>> the potential of calling the initModality and show() / showAndWait() >>>>> methods in the incorrect order. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> This will break the backwards compat of a stage so I think it is too >>>> late for such an API. >>>> >>>> Tom >>>> >>>> >>>> >>>> >>>> >>> From kevin.rushforth at oracle.com Wed Apr 11 13:08:55 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 11 Apr 2012 13:08:55 -0700 Subject: API REVIEW request for RT-19783: Provide an option to allow modal windows to be blocking In-Reply-To: <4F852387.9010409@bestsolution.at> References: <4F849B81.5070603@oracle.com> <4F84D06A.4030103@bestsolution.at> <4F84EE9E.603@oracle.com> <4F852387.9010409@bestsolution.at> Message-ID: <4F85E4D7.1070606@oracle.com> > > Beside that a dialog stage should not have a Dock-Item showing for > example. So I guess to really implement dialogs you'll also have to add > a new constructor "Stage(Stage parent)" or are you going to add a new > class which can be used as the super-class for that like FXDialog? We already have "initOwner(Window)" which sets the owner (parent) of that Stage. If the owner of a given stage is closed or iconified then that stage will also be closed or iconified. Also, it won't show up as a separate item in the dock. This should do what you want. The following API docs have been added to 2.1 that should explain this (which is available as a developer preview and will go live later this month). Note that this is just a javadoc change; the feature was available in 2.0. *Owner* A stage can optionally have an owner Window. When a window is a stage's owner, it is said to be the parent of that stage. When a parent window is closed, all its descendant windows are closed. The same chained behavior applied for a parent window that is iconified. A stage will always be on top of its parent window. The owner must be initialized before the stage is made visible. -- Kevin Tom Schindl wrote: > Hi Kevin, > > Something else in this context came to my mind. Isn't it needed for > Dialogs for example that their visibility is bound to the visibility of > some parent stage? > > Say I have an application with a "main" stage and a none modal dialog > stage, I think now closing the "main" stage should also bring down the > dialog stage. > > Beside that a dialog stage should not have a Dock-Item showing for > example. So I guess to really implement dialogs you'll also have to add > a new constructor "Stage(Stage parent)" or are you going to add a new > class which can be used as the super-class for that like FXDialog? > > Anyways this is maybe a different discussion but it just came to my mind > because the current API doesn't allow me to implement my own dialog > stages who don't show up in the dock. > > Tom > > Am 11.04.12 04:38, schrieb Kevin Rushforth: > >> Sure, I could add something like that to make it more clear. Anything >> that causes the window to be no longer showing will cause showAndWait() >> to return, which includes calling hide() or closing the window through >> window system interaction. >> >> I just realized that there is something else I need to add to the >> documentation: nested calls are permitted, but an "outer" call to >> showAndWait() will never return until all "inner" calls return. This can >> happen in the following case: >> >> { >> s1.showAndWait(); // blocks until s1 is hidden >> some instruction after s1 is hidden >> } >> >> ... >> >> { >> s2.showAndWait(); // blocks until s2 is hidden >> some instruction after s2 is hidden >> } >> >> At this point you have a nested event loop within a nested event loop. >> If some piece of code calls "s1.hide()" it will not unblock and exit >> "some instruction after s1 is hidden" until s2 is also closed. >> >> -- Kevin >> >> >> Tom Schindl wrote: >> >>> What I'm not clear about is what are the circumstances the call returns. >>> Is it only when the user hits the stages close icon, someone calls the >>> close/hide method, ...? >>> >>> Maybe referring to close/hide in the javadoc makes it clear? >>> >>> So the revised javadoc could be: >>> >>> -- >>> Show the stage and wait for it to be closed (through user interaction or >>> by calling {@link #close} or {@link #hide}) before returning to the >>> caller. This must be called on the FX Application thread. The stage must >>> not already be visible prior to calling this method. This must not be >>> called on the primary stage. >>> -- >>> >>> >>> Tom >>> >>> >>> >>> Am 10.04.12 22:43, schrieb Kevin Rushforth: >>> >>> >>>> JIRA: http://javafx-jira.kenai.com/browse/RT-19783 >>>> >>>> We have had several requests for a way to block the caller while a >>>> (modal) dialog is shown. The show() method on a Stage is specified to >>>> return to the caller immediately regardless of the modality of a stage. >>>> This is a good semantic for many applications, but complicates the logic >>>> for other applications which don't want to proceed until the dialog is >>>> dismissed. It is also needed internally to implement an Alert class (see >>>> RT-12643 for example). >>>> Swing dialog, for example, JOptionPane, work by blocking the caller >>>> until the dialog is dismissed meaning that Swing application programmers >>>> are already familiar with that model. >>>> >>>> Our proposal for JavaFX 2.2 is to add a new method on Stage, >>>> showAndWait(), which will block the caller until the stage is hidden. >>>> Note that while this is primarily useful for modal Stages, there is >>>> nothing in the API that restricts it to such. >>>> >>>> The proposed method and javadoc are described in the JIRA >>>> , >>>> but since it is so short, I will also list it here: >>>> >>>> /** >>>> * Show the stage and wait for it to be closed before returning >>>> to the >>>> * caller. This must be called on the FX Application thread. The >>>> stage >>>> * must not already be visible prior to calling this method. This >>>> must not >>>> * be called on the primary stage. >>>> * >>>> * @throws IllegalStateException if this method is called on a >>>> thread >>>> * other than the JavaFX Application Thread. >>>> * @throws IllegalStateException if this method is called on the >>>> * primary stage. >>>> * @throws IllegalStateException if this stage is already showing. >>>> */ >>>> public void showAndWait(); >>>> >>>> >>>> -- Kevin >>>> >>>> >>>> >>> >>> > > > From hang.vo at oracle.com Wed Apr 11 13:26:20 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 11 Apr 2012 20:26:20 +0000 Subject: hg: openjfx/2.2/master/rt: 68 new changesets Message-ID: <20120411202710.8FA2147FED@hg.openjdk.java.net> Changeset: 5c3b3d524f07 Author: hudson Date: 2012-04-05 12:55 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/5c3b3d524f07 Added tag 2.1-b21 for changeset 4d1d81b2c178 ! .hgtags Changeset: b66c767bcbcb Author: kcr Date: 2012-04-05 14:43 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/b66c767bcbcb Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.1/MASTER/jfx/rt ! .hgtags - javafx-ui-common/src/com/sun/javafx/tk/TextHelper.java Changeset: 8acd74a463e3 Author: Paru Somashekar Date: 2012-03-26 12:07 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/8acd74a463e3 AddColorPane dialog for ColorPicker prototype ! javafx-ui-controls/src/com/sun/javafx/scene/control/ColorPicker.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/ColorPickerPanel.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ColorPickerBehavior.java ! 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 + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/center-btn-selected.png + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/center-btn.png + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/left-btn-selected.png + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/left-btn.png + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/right-btn-selected.png + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/right-btn.png Changeset: bc7aa1bdbf04 Author: Paru Somashekar Date: 2012-03-26 12:08 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/bc7aa1bdbf04 missed this in previous putback. + javafx-ui-controls/src/com/sun/javafx/scene/control/ColorPickerAddColorPane.java Changeset: 24c7fb48a91f Author: jgiles Date: 2012-03-22 13:00 +1300 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/24c7fb48a91f Partial implementation of RT-17975: Support for discontinuous selection in TableView/ListView/TreeView. (Total ListView and TreeView support, but no TableView support yet) ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewKeyInputTest.java Changeset: 24f22ed28f63 Author: jgiles Date: 2012-03-27 10:58 +1300 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/24f22ed28f63 Partial implementation of RT-19449: TableView: Improved keyboard navigation (discontinuous selection) (Support for row-based discontinuous selection, with cell-based coming in a separate changset once developed). ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java Changeset: 7b001733f381 Author: jgiles Date: 2012-03-27 11:56 +1300 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/7b001733f381 RT-19449: TableView: Improved keyboard navigation (discontinuous selection) (For cell-based selection) ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java Changeset: 646173cf1ff1 Author: jgiles Date: 2012-03-27 11:59 +1300 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/646173cf1ff1 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 459b180c6841 Author: leifs Date: 2012-03-27 10:58 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/459b180c6841 Fixed RT-18991: Right aligned TextFiel behaves incorrectly when containing long text Fixed RT-20035: TextField text alignment fails when delayed setText() call with alignment = Pos.CENTER ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java Changeset: 1f368473b22c Author: leifs Date: 2012-03-27 11:11 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/1f368473b22c Update to fix for RT-20035: TextField text alignment fails when delayed setText() call with alignment = Pos.CENTER ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java Changeset: 0170fb8eb4ff Author: Paru Somashekar Date: 2012-03-27 15:11 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/0170fb8eb4ff some color picker prototype visual changes. ! javafx-ui-controls/src/com/sun/javafx/scene/control/ColorPickerAddColorPane.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: 6d42959f42b2 Author: jgiles Date: 2012-03-28 11:56 +1300 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/6d42959f42b2 RT-20575: ComboBox editable incorrect paint behavior ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxBaseSkin.java Changeset: 89f8c2fda2d8 Author: jgiles Date: 2012-03-28 12:09 +1300 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/89f8c2fda2d8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/controls/jfx/rt Changeset: 59773e9d3233 Author: Paru Somashekar Date: 2012-03-27 16:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/59773e9d3233 fix incorrect focus around editable ComboBox that was introduced while doing changes for ColorPicker ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxBaseSkin.java Changeset: c4d9edf225c4 Author: leifs Date: 2012-03-27 17:26 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/c4d9edf225c4 Fixed RT-20312: WrapText incorrectly calculates control height ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ButtonSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java Changeset: 0992d63e63b9 Author: Paru Somashekar Date: 2012-03-27 22:47 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/0992d63e63b9 fix RT-20639 Strange behavior for empty StackedAreaChart ! javafx-ui-charts/src/javafx/scene/chart/StackedAreaChart.java Changeset: 7c3dc5904604 Author: Paru Somashekar Date: 2012-03-28 09:35 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/7c3dc5904604 fix RT-18389 ScatterChart draws points shifted from expected position ! javafx-ui-charts/src/javafx/scene/chart/ScatterChart.java Changeset: 20df31a51b62 Author: leifs Date: 2012-03-28 13:28 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/20df31a51b62 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt Changeset: 65a00a7e79ef Author: Kinsley Wong Date: 2012-03-28 15:38 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/65a00a7e79ef RT-20508: VirtualContainerBase constructor should check for control properties ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualContainerBase.java Changeset: 55933b31214f Author: Kinsley Wong Date: 2012-03-28 15:41 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/55933b31214f Implement setPageIndex, setNumberOfVisiblePages, setNumberOfItems and setPageFactory. ! javafx-ui-controls/src/com/sun/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 3014f9f8ce87 Author: Greg Brown Date: 2012-03-29 08:48 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/3014f9f8ce87 Revert default property changes associated with RT-20547. ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java Changeset: c6bb8a5a32b0 Author: leifs Date: 2012-03-29 14:21 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/c6bb8a5a32b0 Fixed RT-20644: Strange behavior of TextField in GridPane. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java Changeset: b357d89c5b06 Author: Kinsley Wong Date: 2012-03-29 17:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/b357d89c5b06 pagination disable horizontal scrollbars. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: ab22b3c94222 Author: Kinsley Wong Date: 2012-03-29 17:57 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/ab22b3c94222 Pagination: resize the cell when the parent changes size. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationCellSkin.java Changeset: a64fe55fd5c5 Author: Kinsley Wong Date: 2012-03-29 17:58 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/a64fe55fd5c5 Pagination: implement setPageIndex() ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 9735e7d0d5d2 Author: Kinsley Wong Date: 2012-03-29 19:11 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/9735e7d0d5d2 Pagination: update the number of visible pages if the number of pages is less than the number of visible pages. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 0cac4962eb87 Author: David Grieve Date: 2012-03-29 22:54 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/0cac4962eb87 RT-20210: StyleManager.Cache.cache should hold StyleHelper instance, not Reference ! 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 Changeset: 02b27d9e7bf2 Author: David Grieve Date: 2012-03-29 22:54 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/02b27d9e7bf2 RT-9784: when a new StyleHelper is needed, reset the styled properties to initial values ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java Changeset: da37fdc4a2f6 Author: David Grieve Date: 2012-03-29 22:54 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/da37fdc4a2f6 RT-20691: restore building of caspian.bss ! javafx-ui-controls/build.xml Changeset: 3c304eaa5b55 Author: leifs Date: 2012-03-30 13:50 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/3c304eaa5b55 Fixed RT-7547: TextField/PasswordField/TextArea needs undo/redo ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls.properties Changeset: 11cab33d9c55 Author: leifs Date: 2012-03-30 14:29 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/11cab33d9c55 Additional fix for RT-7547: TextField/PasswordField/TextArea needs undo/redo ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java Changeset: 55dafb84ad3f Author: leifs Date: 2012-03-31 16:33 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/55dafb84ad3f Fixed RT-19273: Ctrl-Backspace in Text Field ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! 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: 1e938a90f89a Author: leifs Date: 2012-03-31 17:19 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/1e938a90f89a Fixed RT-18711: [PasswordField] Using ctrl+shift+left/right allows to identify spaces in password. Fixed RT-18854 [PasswordField] mouse double click allow to identify spaces in password. + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/PasswordFieldBehavior.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 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PasswordFieldSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java Changeset: 1ba55d2ecc03 Author: leifs Date: 2012-04-02 10:10 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/1ba55d2ecc03 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 4889b4deb45e Author: Paru Somashekar Date: 2012-04-02 15:39 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/4889b4deb45e fix RT-20720 NPE when removing last item in series in AreaChart ! javafx-ui-charts/src/javafx/scene/chart/AreaChart.java Changeset: 05f86cff4777 Author: Kinsley Wong Date: 2012-03-30 11:55 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/05f86cff4777 Pagination: css cleanup ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: b421b3cdc003 Author: Kinsley Wong Date: 2012-04-02 16:54 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/b421b3cdc003 Pagination: include node size when computing pref width and height ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationCellSkin.java Changeset: b9dde81dbee6 Author: Kinsley Wong Date: 2012-04-02 16:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/b9dde81dbee6 Pagination: correctly compute the total number of pages and scroll pages using offsets. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 8909d2df17f0 Author: Kinsley Wong Date: 2012-04-02 16:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/8909d2df17f0 Pagination: css cleanup. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: ee1093741bde Author: Kinsley Wong Date: 2012-04-02 17:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/ee1093741bde Pagination: allowing scrolling to an offset. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualContainerBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 33eee41df3bd Author: Kinsley Wong Date: 2012-04-02 17:10 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/33eee41df3bd merge - javafx-ui-common/src/com/sun/javafx/tk/TextHelper.java Changeset: e08f86fc5989 Author: David Grieve Date: 2012-04-02 20:39 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/e08f86fc5989 RT-20686: -fx-font-smoothing-type: gray; does not parse. Parser sees "gray" as a color. ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest_AUTHOR.css ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest_UA.css ! javafx-ui-common/test/unit/javafx/scene/text/Text_cssMethods_Test.java Changeset: ae28effcfa79 Author: David Grieve Date: 2012-04-03 10:51 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/ae28effcfa79 RT-20210: A StyleHelper might not have been gc'd so the referent might not have been cleared before the Reference is used by code that relies on the reference being cleared as soon as the StyleHelper becomes invalid and not when the StyleHelper is gc'd. ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: 137908962b46 Author: mickf Date: 2012-04-04 12:41 +0100 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/137908962b46 RT-16144 - ScrollBar: space between buttons has another width than buttons ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ScrollPaneSkinTest.java Changeset: 60861984b3f7 Author: Kinsley Wong Date: 2012-04-04 11:44 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/60861984b3f7 JAVADOC RT-20490 Region javadoc needs links. ! javafx-ui-common/src/javafx/scene/layout/Region.java Changeset: 7d435026b5fe Author: Kinsley Wong Date: 2012-04-04 12:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/7d435026b5fe Pagination: add support for left and right key presses. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/PaginationBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: abd899c37f61 Author: Kinsley Wong Date: 2012-04-04 15:03 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/abd899c37f61 Pagination: do not use any of list-cell styles for pagination-cell. ! javafx-ui-controls/src/com/sun/javafx/scene/control/PaginationCell.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 12bba27d5557 Author: leifs Date: 2012-04-04 22:51 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/12bba27d5557 FXVK: Virtual keyboard layouts now defined in resource file ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVK.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKCharEntities.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls.properties ! javafx-ui-controls/src/javafx/scene/control/TextInputControl.java Changeset: 15b9d61a37a9 Author: leifs Date: 2012-04-05 09:48 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/15b9d61a37a9 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt Changeset: c6b279c12e00 Author: leifs Date: 2012-04-05 13:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/c6b279c12e00 FXVK: Updated layouts ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/resources/controls.properties Changeset: cde48ec5b900 Author: leifs Date: 2012-04-05 13:57 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/cde48ec5b900 Fixed RT-16628: [TextArea,TextField] Selection on double click take the following whitespace into selection ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java Changeset: 5aad7496e4de Author: Paru Somashekar Date: 2012-04-05 14:41 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/5aad7496e4de fix RT-20657 focus ring gets stuck in a editable ComboBox. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 9355216335fd Author: Kinsley Wong Date: 2012-04-05 16:45 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/9355216335fd Pagination: left and right swipe support. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: a3c614e52249 Author: leifs Date: 2012-04-05 22:11 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/a3c614e52249 Fixed RT-19691: Mnemonic isn't shown when textProperty is bound. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java Changeset: 829382aecd2e Author: Kinsley Wong Date: 2012-04-06 16:47 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/829382aecd2e RT20171: Tab in FXML: define content property as DefaultProperty. ! javafx-ui-controls/src/javafx/scene/control/Tab.java Changeset: cce17d461292 Author: Kinsley Wong Date: 2012-04-09 10:51 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/cce17d461292 Pagination: swipe directions were reversed. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: fdc80b4d14e9 Author: leifs Date: 2012-04-09 13:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/fdc80b4d14e9 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt Changeset: 94e9b5588ae7 Author: Pavel Safrata Date: 2012-04-02 15:50 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/94e9b5588ae7 Removed unused import. ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java Changeset: a5402446058e Author: prr Date: 2012-04-03 10:36 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/a5402446058e Fixed RT_20730: Unused variables in Text node ! javafx-ui-common/src/javafx/scene/text/Text.java Changeset: dcdd0ac56ce4 Author: Lubomir Nerad Date: 2012-04-04 10:22 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/dcdd0ac56ce4 Fix for RT-20654, RT-20655: Image arguments validation ! javafx-ui-common/src/javafx/scene/image/Image.java ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/test/unit/javafx/scene/image/ImageTest.java Changeset: b8de44e3e523 Author: Pavel Safrata Date: 2012-04-06 12:59 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/b8de44e3e523 Scene code cleanup - multiplicated picking and parent traversing code merged together, got rid of many instanceofs. RT-19346, RT-20832 and RT-20833 fixed along the way. ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/test/unit/javafx/scene/MouseTest.java Changeset: f33e24e8ff4d Author: kcr Date: 2012-04-09 20:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/f33e24e8ff4d RT-20869: Extending the Maven Build to include aggregated sources Contributed-By: Adam Bien Reviewed-By: kcr ! javafx-ueber-jar/pom.xml ! pom.xml Changeset: 59cce19d3ba4 Author: Michael Heinrichs Date: 2012-04-05 16:00 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/59cce19d3ba4 Improved picking if cell cannot be reused [RT-20829] ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 02d3dce15c93 Author: Michael Heinrichs Date: 2012-04-10 10:50 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/02d3dce15c93 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/graphics/jfx/rt Changeset: 534afd2fb91f Author: Martin Sladecek Date: 2012-04-10 13:55 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/534afd2fb91f Scene's dirtyNodes optimization. Reviewed by Lubo. ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: b98d11b3a594 Author: Martin Sladecek Date: 2012-04-10 13:56 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/b98d11b3a594 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/graphics/jfx/rt ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: e9d45acca75f Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-04-10 09:16 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/e9d45acca75f Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: be3c4671a7e7 Author: hudson Date: 2012-04-11 13:23 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/master/rt/rev/be3c4671a7e7 Added tag 2.2-b04 for changeset e9d45acca75f ! .hgtags From hang.vo at oracle.com Thu Apr 12 04:03:56 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 12 Apr 2012 11:03:56 +0000 Subject: hg: openjfx/2.2/graphics/rt: Node's bounds optimization. Reviewed by Lubo. Message-ID: <20120412110359.5FFEF47028@hg.openjdk.java.net> Changeset: e027f8b61c60 Author: Martin Sladecek Date: 2012-04-12 12:56 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/e027f8b61c60 Node's bounds optimization. Reviewed by Lubo. ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java From hang.vo at oracle.com Thu Apr 12 12:18:17 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 12 Apr 2012 19:18:17 +0000 Subject: hg: openjfx/2.2/graphics/rt: Fix broken javafx.scene.input.DragAndDropTest unit test Message-ID: <20120412191819.A1DB047038@hg.openjdk.java.net> Changeset: dfbb8f49cd7a Author: Alexey Semenyuk (alexey.semenyuk at oracle.com) Date: 2012-04-12 23:12 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/dfbb8f49cd7a Fix broken javafx.scene.input.DragAndDropTest unit test ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubScene.java From kinsley.wong at oracle.com Thu Apr 12 14:39:45 2012 From: kinsley.wong at oracle.com (Kinsley Wong) Date: Thu, 12 Apr 2012 14:39:45 -0700 Subject: API REVIEW request for RT17668 Disable/enable tabs in a TabPane Message-ID: <4F874BA1.3090306@oracle.com> JIRA: http://javafx-jira.kenai.com/browse/RT-17668 This tweak will add the following api to Tab public final void setDisable(boolean value); public final boolean isDisable(); /** * Sets the disabled state of this tab. Setting * disable to true will cause this tab and the tab content to * become disabled. * * @defaultValue false */ public final BooleanProperty disableProperty(); From hang.vo at oracle.com Thu Apr 12 18:49:45 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 13 Apr 2012 01:49:45 +0000 Subject: hg: openjfx/2.2/controls/rt: 12 new changesets Message-ID: <20120413014956.608F147056@hg.openjdk.java.net> Changeset: 94e9b5588ae7 Author: Pavel Safrata Date: 2012-04-02 15:50 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/94e9b5588ae7 Removed unused import. ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java Changeset: a5402446058e Author: prr Date: 2012-04-03 10:36 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/a5402446058e Fixed RT_20730: Unused variables in Text node ! javafx-ui-common/src/javafx/scene/text/Text.java Changeset: dcdd0ac56ce4 Author: Lubomir Nerad Date: 2012-04-04 10:22 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/dcdd0ac56ce4 Fix for RT-20654, RT-20655: Image arguments validation ! javafx-ui-common/src/javafx/scene/image/Image.java ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/test/unit/javafx/scene/image/ImageTest.java Changeset: b8de44e3e523 Author: Pavel Safrata Date: 2012-04-06 12:59 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/b8de44e3e523 Scene code cleanup - multiplicated picking and parent traversing code merged together, got rid of many instanceofs. RT-19346, RT-20832 and RT-20833 fixed along the way. ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/test/unit/javafx/scene/MouseTest.java Changeset: f33e24e8ff4d Author: kcr Date: 2012-04-09 20:40 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/f33e24e8ff4d RT-20869: Extending the Maven Build to include aggregated sources Contributed-By: Adam Bien Reviewed-By: kcr ! javafx-ueber-jar/pom.xml ! pom.xml Changeset: 59cce19d3ba4 Author: Michael Heinrichs Date: 2012-04-05 16:00 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/59cce19d3ba4 Improved picking if cell cannot be reused [RT-20829] ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 02d3dce15c93 Author: Michael Heinrichs Date: 2012-04-10 10:50 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/02d3dce15c93 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/graphics/jfx/rt Changeset: 534afd2fb91f Author: Martin Sladecek Date: 2012-04-10 13:55 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/534afd2fb91f Scene's dirtyNodes optimization. Reviewed by Lubo. ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: b98d11b3a594 Author: Martin Sladecek Date: 2012-04-10 13:56 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/b98d11b3a594 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/scrum/graphics/jfx/rt ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: e9d45acca75f Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-04-10 09:16 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/e9d45acca75f Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: be3c4671a7e7 Author: hudson Date: 2012-04-11 13:23 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/be3c4671a7e7 Added tag 2.2-b04 for changeset e9d45acca75f ! .hgtags Changeset: 6d5dabb1a6cf Author: leifs Date: 2012-04-12 18:42 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/6d5dabb1a6cf Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt From tbee at tbee.org Thu Apr 12 21:57:59 2012 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 13 Apr 2012 06:57:59 +0200 Subject: API REVIEW request for RT17668 Disable/enable tabs in a TabPane In-Reply-To: <4F874BA1.3090306@oracle.com> References: <4F874BA1.3090306@oracle.com> Message-ID: <4F87B257.5040908@tbee.org> One non-mainstream scenario could be considered: the situation where a tab is not selectable by the user anymore, only programmatically, but the contents are still enabled (e.g. a wizard with enforced steps). This could be achieved by making the calls below only influence the tab itself, not the content, but that would make the programmer responsible for disabling the content. This is not the main usage (although, if a tab is disabled, how likely is it the content is being shown). A better solution would be to also introduce "setSelectable" and "isSelectable", which is a part of what is needed to implement "disabled". Tom On 2012-04-12 23:39, Kinsley Wong wrote: > JIRA: http://javafx-jira.kenai.com/browse/RT-17668 > > This tweak will add the following api to Tab > > public final void setDisable(boolean value); > public final boolean isDisable(); > > /** > * Sets the disabled state of this tab. Setting > * disable to true will cause this tab and the tab content to > * become disabled. > * > * @defaultValue false > */ > public final BooleanProperty disableProperty(); > From martin.sladecek at oracle.com Thu Apr 12 23:31:30 2012 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Fri, 13 Apr 2012 08:31:30 +0200 Subject: API Review Request for RT-17438 Message-ID: <4F87C842.1030305@oracle.com> Hello, JIRA: http://javafx-jira.kenai.com/browse/RT-17438 The JIRA requests methods for key classification on KeyEvent class, like KeyEvent.isFunctionKey() //F1, F2, F3, ..., F24 KeyEvent.isArrowKey() //UP, DOWN, LEFT, RIGHT. I propose to have these methods on KeyCode class (enum), where they are more natural and can be used anywhere the KeyCode objects are present (e.g. KeyCodeCombination class). So in case of the keyEvent, the calls would look like: ev.getCode().isArrowKey() The list of propsed KeyCode methods: /** * Functional keys like F1, F2, etc... * @return true if this key code corresponds to a functional key */ public final boolean isFunctionalKey() /** * Navigation keys are arrow keys and Page Down, Page Up, Home, End * @return true if this key code corresponds to a navigation key */ public final boolean isNavigationKey() /** * Left, right, up, down keys (including the keypad arrows) * @return true if this key code corresponds to an arrow key */ public final boolean isArrowKey() /** * Keys that could act as a modifier * @return true if this key code corresponds to a modifier key */ public final boolean isModifierKey() /** * All keys with letters * @return true if this key code corresponds to a letter key */ public final boolean isLetterKey() /** * All Digit keys (including the keypad digits) * @return true if this key code corresponds to a digit key */ public final boolean isDigitKey() /** * All keys on the keypad * @return true if this key code corresponds to a keypad key */ public final boolean isKeypadKey() /** * Space and tab * @return true if this key code corresponds to a whitespace key */ public final boolean isWhitespaceKey() /** * All multimedia keys (channel up/down, volume control, etc...) * @return true if this key code corresponds to a media key */ public final boolean isMediaKey() Thanks, -Martin From tom.schindl at bestsolution.at Fri Apr 13 00:09:42 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 13 Apr 2012 09:09:42 +0200 Subject: API REVIEW request for RT17668 Disable/enable tabs in a TabPane In-Reply-To: <4F874BA1.3090306@oracle.com> References: <4F874BA1.3090306@oracle.com> Message-ID: <4F87D136.3040200@bestsolution.at> Is the tab still selectable? If no, what will happen if the tab you are just disabling is the active one? Will the focus be shifted to the next/previous one? What if it is the only tab? If yes. Is disable really the right property name? Disabled means it can not be selected anymore (doesn't receive focus, not part of tab navigation, ...) Tom Am 12.04.12 23:39, schrieb Kinsley Wong: > JIRA: http://javafx-jira.kenai.com/browse/RT-17668 > > This tweak will add the following api to Tab > > public final void setDisable(boolean value); > public final boolean isDisable(); > > /** > * Sets the disabled state of this tab. Setting > * disable to true will cause this tab and the tab content to > * become disabled. > * > * @defaultValue false > */ > public final BooleanProperty disableProperty(); -- 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 jonathan.giles at oracle.com Fri Apr 13 01:47:16 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 13 Apr 2012 20:47:16 +1200 Subject: API REVIEW request for RT17668 Disable/enable tabs in a TabPane In-Reply-To: <4F87B257.5040908@tbee.org> References: <4F874BA1.3090306@oracle.com> <4F87B257.5040908@tbee.org> Message-ID: <4F87E814.3060300@oracle.com> +1...mostly. Without having spoken to Kinsley (I walked in the door 10 minutes ago from JavaOne Japan / vacation), my gut feeling is that 'disable' should make the tab unable to be interacted with by the user, but it should still be selectable programatically (with the tab having the required disable look). I don't think the Tab content should be disabled when the Tab is however. I don't think it is necessary to include the selectable property, but I might be missing something. -- Jonathan On 13/04/2012 4:57 p.m., Tom Eugelink wrote: > > One non-mainstream scenario could be considered: the situation where a > tab is not selectable by the user anymore, only programmatically, but > the contents are still enabled (e.g. a wizard with enforced steps). > > This could be achieved by making the calls below only influence the > tab itself, not the content, but that would make the programmer > responsible for disabling the content. This is not the main usage > (although, if a tab is disabled, how likely is it the content is being > shown). > > A better solution would be to also introduce "setSelectable" and > "isSelectable", which is a part of what is needed to implement > "disabled". > > Tom > > > > > On 2012-04-12 23:39, Kinsley Wong wrote: >> JIRA: http://javafx-jira.kenai.com/browse/RT-17668 >> >> This tweak will add the following api to Tab >> >> public final void setDisable(boolean value); >> public final boolean isDisable(); >> >> /** >> * Sets the disabled state of this tab. Setting >> * disable to true will cause this tab and the tab content to >> * become disabled. >> * >> * @defaultValue false >> */ >> public final BooleanProperty disableProperty(); >> > > From hang.vo at oracle.com Fri Apr 13 04:18:33 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 13 Apr 2012 11:18:33 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-20635 Refactor Scene's impl_isQuiescent() and impl_testPulseListener Message-ID: <20120413111836.11B2D470A3@hg.openjdk.java.net> Changeset: a7ff61d4dc35 Author: Martin Sladecek Date: 2012-04-13 12:58 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a7ff61d4dc35 RT-20635 Refactor Scene's impl_isQuiescent() and impl_testPulseListener ! javafx-ui-common/src/javafx/scene/Scene.java From hang.vo at oracle.com Fri Apr 13 05:48:16 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 13 Apr 2012 12:48:16 +0000 Subject: hg: openjfx/2.2/graphics/rt: 2 new changesets Message-ID: <20120413124817.EB76C470A4@hg.openjdk.java.net> Changeset: 4284cff17ca9 Author: Martin Sladecek Date: 2012-04-13 14:38 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/4284cff17ca9 RT-20633 Investigate: does Scene.setFocusDirty need to schedule a pulse? ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/test/unit/com/sun/javafx/pgstub/StubToolkit.java ! javafx-ui-common/test/unit/javafx/scene/FocusTest.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: c6ee3853f67c Author: Martin Sladecek Date: 2012-04-13 14:38 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/c6ee3853f67c Automated merge with file:///home/martin/Work/JavaFx/jfx-22-sync/rt ! javafx-ui-common/src/javafx/scene/Scene.java From hang.vo at oracle.com Fri Apr 13 12:03:50 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 13 Apr 2012 19:03:50 +0000 Subject: hg: openjfx/2.2/graphics/rt: Fixed RT-20918: TextField text disappears when selection in use Message-ID: <20120413190352.6F3AD470AB@hg.openjdk.java.net> Changeset: f114a167c3d6 Author: prr Date: 2012-04-13 11:46 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/f114a167c3d6 Fixed RT-20918: TextField text disappears when selection in use ! javafx-ui-common/src/com/sun/javafx/scene/DirtyBits.java ! javafx-ui-common/src/javafx/scene/text/Text.java From deep.blue.6802 at gmail.com Fri Apr 13 12:30:31 2012 From: deep.blue.6802 at gmail.com (Jeff McDonald) Date: Fri, 13 Apr 2012 13:30:31 -0600 Subject: API Review Request for RT-17438 In-Reply-To: <4F87C842.1030305@oracle.com> References: <4F87C842.1030305@oracle.com> Message-ID: +1 for me. Some random thoughts: - White space typically includes newlines, and the isWhitespace method returns true only for tabs and spaces. The documentations makes it clear what the method does, but it wouldn't be a stretch for a developer to assume that white space includes newlines. ... especially developers that do a lot of work with HTML. - "FunctionKey" is more common usage than "FunctionalKey" - 10 key numeric keypads typically map arrow keys on to the 2 (Down Arrow), 4 (Left Arrow), 6 (Right Arrow), 8 (Up arrow) keys. Do these keys return true for isArrowKey()? Make the methods public so that a method such as isWhitespace could be made to detect newlines. Extendability allows the methods to be overridden for other things such as custom keyboards or internationalized keyboards. Cheers, Jeff On Fri, Apr 13, 2012 at 12:31 AM, Martin Sladecek < martin.sladecek at oracle.com> wrote: > Hello, > > JIRA: http://javafx-jira.kenai.com/**browse/RT-17438 > > The JIRA requests methods for key classification on KeyEvent class, like > > KeyEvent.isFunctionKey() //F1, F2, F3, ..., F24 > > KeyEvent.isArrowKey() //UP, DOWN, LEFT, RIGHT. > > > I propose to have these methods on KeyCode class (enum), where they are > more natural and can be used anywhere the KeyCode objects are present (e.g. > KeyCodeCombination class). > So in case of the keyEvent, the calls would look like: > > ev.getCode().isArrowKey() > > > The list of propsed KeyCode methods: > > /** > * Functional keys like F1, F2, etc... > * @return true if this key code corresponds to a functional key > */ > public final boolean isFunctionalKey() > > /** > * Navigation keys are arrow keys and Page Down, Page Up, Home, End > * @return true if this key code corresponds to a navigation key > */ > public final boolean isNavigationKey() > > /** > * Left, right, up, down keys (including the keypad arrows) > * @return true if this key code corresponds to an arrow key > */ > public final boolean isArrowKey() > > /** > * Keys that could act as a modifier > * @return true if this key code corresponds to a modifier key > */ > public final boolean isModifierKey() > > /** > * All keys with letters > * @return true if this key code corresponds to a letter key > */ > public final boolean isLetterKey() > > /** > * All Digit keys (including the keypad digits) > * @return true if this key code corresponds to a digit key > */ > public final boolean isDigitKey() > > /** > * All keys on the keypad > * @return true if this key code corresponds to a keypad key > */ > public final boolean isKeypadKey() > > /** > * Space and tab > * @return true if this key code corresponds to a whitespace key > */ > public final boolean isWhitespaceKey() > > /** > * All multimedia keys (channel up/down, volume control, etc...) > * @return true if this key code corresponds to a media key > */ > public final boolean isMediaKey() > > > Thanks, > -Martin > > From richard.bair at oracle.com Fri Apr 13 13:05:02 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 13 Apr 2012 13:05:02 -0700 Subject: API Review Request for RT-17438 In-Reply-To: References: <4F87C842.1030305@oracle.com> Message-ID: <09EAA0C1-66E6-4639-BB1A-7DCCC354FFD1@oracle.com> > Some random thoughts: > - White space typically includes newlines, and the isWhitespace method > returns true only for tabs and spaces. The documentations makes it clear > what the method does, but it wouldn't be a stretch for a developer to > assume that white space includes newlines. ... especially developers that > do a lot of work with HTML. Good point. The Character.isWhiteSpace says: Determines if the specified character is white space according to Java. A character is a Java whitespace character if and only if it satisfies one of the following criteria: ? It is a Unicode space character (SPACE_SEPARATOR, LINE_SEPARATOR, or PARAGRAPH_SEPARATOR) but is not also a non-breaking space ('\u00A0', '\u2007', '\u202F'). ? It is '\t', U+0009 HORIZONTAL TABULATION. ? It is '\n', U+000A LINE FEED. ? It is '\u000B', U+000B VERTICAL TABULATION. ? It is '\f', U+000C FORM FEED. ? It is '\r', U+000D CARRIAGE RETURN. ? It is '\u001C', U+001C FILE SEPARATOR. ? It is '\u001D', U+001D GROUP SEPARATOR. ? It is '\u001E', U+001E RECORD SEPARATOR. ? It is '\u001F', U+001F UNIT SEPARATOR. Seems like we should have whitespace mean the same thing? Or is this the difference between detecting which physical key was pressed vs. which type of data was entered? From hang.vo at oracle.com Fri Apr 13 14:18:27 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 13 Apr 2012 21:18:27 +0000 Subject: hg: openjfx/2.2/graphics/rt: 2 new changesets Message-ID: <20120413211831.0A191470B1@hg.openjdk.java.net> Changeset: be3c4671a7e7 Author: hudson Date: 2012-04-11 13:23 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/be3c4671a7e7 Added tag 2.2-b04 for changeset e9d45acca75f ! .hgtags Changeset: 2159266a701b Author: kcr Date: 2012-04-13 14:13 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/2159266a701b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt From kinsley.wong at oracle.com Fri Apr 13 14:31:17 2012 From: kinsley.wong at oracle.com (Kinsley Wong) Date: Fri, 13 Apr 2012 14:31:17 -0700 Subject: API REVIEW request for RT17668 Disable/enable tabs in a TabPane In-Reply-To: <4F87E814.3060300@oracle.com> References: <4F874BA1.3090306@oracle.com> <4F87B257.5040908@tbee.org> <4F87E814.3060300@oracle.com> Message-ID: <4F889B25.1000700@oracle.com> Currently it is implemented exactly as Jonathan describes. The user cannot interact with a disabled tab. A disabled styled tab is still selectable programatically. Also the tab content is not disabled when the tab is disabled. Kinsley On 4/13/2012 1:47 AM, Jonathan Giles wrote: > +1...mostly. > > Without having spoken to Kinsley (I walked in the door 10 minutes ago > from JavaOne Japan / vacation), my gut feeling is that 'disable' > should make the tab unable to be interacted with by the user, but it > should still be selectable programatically (with the tab having the > required disable look). I don't think the Tab content should be > disabled when the Tab is however. > > I don't think it is necessary to include the selectable property, but > I might be missing something. > > -- Jonathan > > > On 13/04/2012 4:57 p.m., Tom Eugelink wrote: >> >> One non-mainstream scenario could be considered: the situation where >> a tab is not selectable by the user anymore, only programmatically, >> but the contents are still enabled (e.g. a wizard with enforced steps). >> >> This could be achieved by making the calls below only influence the >> tab itself, not the content, but that would make the programmer >> responsible for disabling the content. This is not the main usage >> (although, if a tab is disabled, how likely is it the content is >> being shown). >> >> A better solution would be to also introduce "setSelectable" and >> "isSelectable", which is a part of what is needed to implement >> "disabled". >> >> Tom >> >> >> >> >> On 2012-04-12 23:39, Kinsley Wong wrote: >>> JIRA: http://javafx-jira.kenai.com/browse/RT-17668 >>> >>> This tweak will add the following api to Tab >>> >>> public final void setDisable(boolean value); >>> public final boolean isDisable(); >>> >>> /** >>> * Sets the disabled state of this tab. Setting >>> * disable to true will cause this tab and the tab content to >>> * become disabled. >>> * >>> * @defaultValue false >>> */ >>> public final BooleanProperty disableProperty(); >>> >> >> From hang.vo at oracle.com Fri Apr 13 15:03:44 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 13 Apr 2012 22:03:44 +0000 Subject: hg: openjfx/2.2/graphics/rt: [TEST-ONLY] test fix, approved Message-ID: <20120413220344.D2E24470B2@hg.openjdk.java.net> Changeset: 9a7a2009aaff Author: pkirill Date: 2012-04-14 01:58 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/9a7a2009aaff [TEST-ONLY] test fix, approved ! javafx-ui-common/test/unit/javafx/scene/image/ImageTest.java From hang.vo at oracle.com Fri Apr 13 16:33:20 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 13 Apr 2012 23:33:20 +0000 Subject: hg: openjfx/2.2/controls/rt: 2 new changesets Message-ID: <20120413233324.17F10470B5@hg.openjdk.java.net> Changeset: a753578a5ebe Author: Kinsley Wong Date: 2012-04-13 16:18 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/a753578a5ebe RT20919: fx2.2-h17-b01: VirtualFlow changes caused 45% regression in Controls.TreeView-Keyboard. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 4cd43a31d899 Author: Kinsley Wong Date: 2012-04-13 16:25 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/4cd43a31d899 RT-20901: [JAVADOC] Incorrect code fragment in StackPane.html. ! javafx-ui-common/src/javafx/scene/layout/StackPane.java From hang.vo at oracle.com Fri Apr 13 16:48:02 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 13 Apr 2012 23:48:02 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-20437: ClassCastException in TilePane while using the CSS style -fx-pref-rows Message-ID: <20120413234803.356D6470B6@hg.openjdk.java.net> Changeset: 4c9bcf6130da Author: Kinsley Wong Date: 2012-04-13 16:37 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/4c9bcf6130da RT-20437: ClassCastException in TilePane while using the CSS style -fx-pref-rows ! javafx-ui-common/src/javafx/scene/layout/TilePane.java From pedro.duquevieira at gmail.com Fri Apr 13 17:20:04 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Sat, 14 Apr 2012 01:20:04 +0100 Subject: CSS on javaFX Message-ID: Hi, I'm going to express my opinion about using CSS on JavaFX, please don't take this too personally, I do love JavaFX, and I think you guys are doing a great job. So, here goes: I get that CSS is good for attracting designers to the JavaFX world and for taking advantage of lots of already made work available through out the internet. What I don't get is using only CSS to alter the looks of controls. CSS was good for the HTML model that was created several years back, but it is not good for creating the awesome UIs of the future. CSS3 is just a continuation of a broken model, the HTML model. CSS isn't even a language it lacks lots of common language constructs. Concluding, I think this issue is pretty important: http://javafx-jira.kenai.com/browse/RT-17293 It basically says we should have an object model on java to access properties which are now only available through CSS. Thanks, best regards, -- Pedro Duque Vieira From johan at lodgon.com Sat Apr 14 00:00:39 2012 From: johan at lodgon.com (Johan Vos) Date: Sat, 14 Apr 2012 09:00:39 +0200 Subject: CSS on javaFX In-Reply-To: References: Message-ID: <4F892097.4030706@lodgon.com> Hi, Whether CSS is great or not, I agree with the conclusion that it would be great to offer something to developers as well. Personally, I lost lots of time with typo's in css, and a type-safe way of applying styles would help me. On the other hand, I guess that more than half of the developers that could use JavaFX would prefer changing css files rather than writing code. Hence, I don't think that the two approaches are mutually exclusives -- "raw" css files should still be supported, but a programmatic way to manipulate would be very much appreciated by developers like me. I voted http://javafx-jira.kenai.com/browse/RT-17293 up - Johan On 04/14/2012 02:20 AM, Pedro Duque Vieira wrote: > Hi, > > I'm going to express my opinion about using CSS on JavaFX, please don't > take this too personally, I do love JavaFX, and I think you guys are doing > a great job. > > So, here goes: > I get that CSS is good for attracting designers to the JavaFX world and for > taking advantage of lots of already made work available through out the > internet. What I don't get is using only CSS to alter the looks of controls. > CSS was good for the HTML model that was created several years back, but it > is not good for creating the awesome UIs of the future. CSS3 is just a > continuation of a broken model, the HTML model. > > CSS isn't even a language it lacks lots of common language constructs. > > Concluding, I think this issue is pretty important: > http://javafx-jira.kenai.com/browse/RT-17293 It basically says we should > have an object model on java to access properties which are now only > available through CSS. > > Thanks, best regards, > From tbee at tbee.org Sat Apr 14 04:41:35 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 14 Apr 2012 13:41:35 +0200 Subject: CSS on javaFX In-Reply-To: <4F892097.4030706@lodgon.com> References: <4F892097.4030706@lodgon.com> Message-ID: <4F89626F.8060302@tbee.org> At the very least be able to read it; because when I write custom components, I try to copy the look (CSS) from the standard components, so my custom ones automatically blend in. Voted up. Tom On 2012-04-14 09:00, Johan Vos wrote: > Hi, > > Whether CSS is great or not, I agree with the conclusion that it would be great to offer something to developers as well. Personally, I lost lots of time with typo's in css, and a type-safe way of applying styles would help me. > > On the other hand, I guess that more than half of the developers that could use JavaFX would prefer changing css files rather than writing code. Hence, I don't think that the two approaches are mutually exclusives -- "raw" css files should still be supported, but a programmatic way to manipulate would be very much appreciated by developers like me. > > I voted http://javafx-jira.kenai.com/browse/RT-17293 up > > - Johan > > On 04/14/2012 02:20 AM, Pedro Duque Vieira wrote: >> Hi, >> >> I'm going to express my opinion about using CSS on JavaFX, please don't >> take this too personally, I do love JavaFX, and I think you guys are doing >> a great job. >> >> So, here goes: >> I get that CSS is good for attracting designers to the JavaFX world and for >> taking advantage of lots of already made work available through out the >> internet. What I don't get is using only CSS to alter the looks of controls. >> CSS was good for the HTML model that was created several years back, but it >> is not good for creating the awesome UIs of the future. CSS3 is just a >> continuation of a broken model, the HTML model. >> >> CSS isn't even a language it lacks lots of common language constructs. >> >> Concluding, I think this issue is pretty important: >> http://javafx-jira.kenai.com/browse/RT-17293 It basically says we should >> have an object model on java to access properties which are now only >> available through CSS. >> >> Thanks, best regards, >> > > From pedro.duquevieira at gmail.com Sat Apr 14 06:52:50 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Sat, 14 Apr 2012 14:52:50 +0100 Subject: CSS on javaFX Message-ID: I agree with you Johan, I also don't think the two approaches are not mutually exclusive. As you said I think the best would be to have both "worlds". And as I said CSS would be good to attract designers to JavaFX and also to absorb the years of knowledge and work done with it. Thanks, best regards, > Hi, > > Whether CSS is great or not, I agree with the conclusion that it would > be great to offer something to developers as well. Personally, I lost > lots of time with typo's in css, and a type-safe way of applying styles > would help me. > > On the other hand, I guess that more than half of the developers that > could use JavaFX would prefer changing css files rather than writing > code. Hence, I don't think that the two approaches are mutually > exclusives -- "raw" css files should still be supported, but a > programmatic way to manipulate would be very much appreciated by > developers like me. > > I voted http://javafx-jira.kenai.com/browse/RT-17293 up > > - Johan > -- Pedro Duque Vieira From tom.schindl at bestsolution.at Sat Apr 14 23:51:56 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sun, 15 Apr 2012 08:51:56 +0200 Subject: CSS on javaFX In-Reply-To: <4F892097.4030706@lodgon.com> References: <4F892097.4030706@lodgon.com> Message-ID: Well typos should be recognized by tooling and my Eclipse tooling (http://efxclipse.org) provides CSS support. Tom Von meinem iPhone gesendet Am 14.04.2012 um 09:00 schrieb Johan Vos : > Hi, > > Whether CSS is great or not, I agree with the conclusion that it would be great to offer something to developers as well. Personally, I lost lots of time with typo's in css, and a type-safe way of applying styles would help me. > > On the other hand, I guess that more than half of the developers that could use JavaFX would prefer changing css files rather than writing code. Hence, I don't think that the two approaches are mutually exclusives -- "raw" css files should still be supported, but a programmatic way to manipulate would be very much appreciated by developers like me. > > I voted http://javafx-jira.kenai.com/browse/RT-17293 up > > - Johan > > On 04/14/2012 02:20 AM, Pedro Duque Vieira wrote: >> Hi, >> >> I'm going to express my opinion about using CSS on JavaFX, please don't >> take this too personally, I do love JavaFX, and I think you guys are doing >> a great job. >> >> So, here goes: >> I get that CSS is good for attracting designers to the JavaFX world and for >> taking advantage of lots of already made work available through out the >> internet. What I don't get is using only CSS to alter the looks of controls. >> CSS was good for the HTML model that was created several years back, but it >> is not good for creating the awesome UIs of the future. CSS3 is just a >> continuation of a broken model, the HTML model. >> >> CSS isn't even a language it lacks lots of common language constructs. >> >> Concluding, I think this issue is pretty important: >> http://javafx-jira.kenai.com/browse/RT-17293 It basically says we should >> have an object model on java to access properties which are now only >> available through CSS. >> >> Thanks, best regards, >> > From steve at winnall.ch Sun Apr 15 06:15:29 2012 From: steve at winnall.ch (Stephen Winnall) Date: Sun, 15 Apr 2012 15:15:29 +0200 Subject: CSS on javaFX In-Reply-To: References: Message-ID: On 14 Apr 2012, at 02:20, Pedro Duque Vieira wrote: > > CSS isn't even a language it lacks lots of common language constructs. That depends on what you understand as a "language". I would agree that CSS is not a programming language, but it is not intended to be. Nor is XML for that matter. Both CSS and XML are data description languages and - as such - capture the state of the described data at the point where the CSS or XML is loaded (by Scene.getStylesheets.add() or FXMLLoader.load() etc). The provision of "common language constructs" is what scripting languages provide. We have enough of those already without adding scripting constructs to CSS and XML. In the context of JavaFX, it may make more sense to use Java itself. I agree that Zonski's proposal is interesting. In the XML world there is data binding, which allows you to create mapping from XML schemas to Java Beans. Something similar for CSS would be very useful. Steve From tobi at ultramixer.com Sun Apr 15 06:24:40 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Sun, 15 Apr 2012 15:24:40 +0200 Subject: CSS on javaFX In-Reply-To: References: Message-ID: If you are talking about css extensions please vote for native looking css skins too: http://javafx-jira.kenai.com/browse/RT-20299 Tobi Am 15.04.2012 um 15:15 schrieb Stephen Winnall : > On 14 Apr 2012, at 02:20, Pedro Duque Vieira wrote: >> >> CSS isn't even a language it lacks lots of common language constructs. > > That depends on what you understand as a "language". > > I would agree that CSS is not a programming language, but it is not intended to be. Nor is XML for that matter. Both CSS and XML are data description languages and - as such - capture the state of the described data at the point where the CSS or XML is loaded (by Scene.getStylesheets.add() or FXMLLoader.load() etc). > > The provision of "common language constructs" is what scripting languages provide. We have enough of those already without adding scripting constructs to CSS and XML. In the context of JavaFX, it may make more sense to use Java itself. > > I agree that Zonski's proposal is interesting. In the XML world there is data binding, which allows you to create mapping from XML schemas to Java Beans. Something similar for CSS would be very useful. > > Steve From tobi at ultramixer.com Sun Apr 15 07:36:58 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Sun, 15 Apr 2012 16:36:58 +0200 Subject: using :first-child selector? Message-ID: Hi, JavaFX 2 doesn't seams to support the :first-child selector in CSS. Is there any "workaround" to select only the first children of a parent element like a ListView? http://www.w3schools.com/cssref/sel_firstchild.asp Tobi From pedro.duquevieira at gmail.com Sun Apr 15 10:03:44 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Sun, 15 Apr 2012 18:03:44 +0100 Subject: CSS on javaFX In-Reply-To: References: Message-ID: I should have elaborated more on that sentence. Yes CSS is not a "programming language" nor is it intended to be, it tries to be a language to describe the visual part of interfaces separating the structure of a document (HTML) from its appearance (the CSS part). Problem is that for more elaborated interfaces, the looks start to have a logic, which CSS fails to provide. That's when HTML web developers start to use javascript, toggling HTML elements class's, I think CSS is a reasonable language to describe visual interfaces, but I think we can do much better. We have to remind ourselves of its origins, it appeared in the context of HTML to solve problems caused by its model, it didn't come up as a language on its own. One thing we can not naturally do today, that we would be able to do if we had an object model of the css properties is animating those properties. We will be able to do it eventually when CSS3 animations come to JavaFX, but on the meantime we can't, at least not on a natural, straight forward way. In conclusion I think CSS should not THE way to describe visual interfaces on JavaFX, rather I think it should be one more way of doing it, that is, we should also be able to accomplish the same by using Java or some other language without having to parse CSS strings. On Sun, Apr 15, 2012 at 2:15 PM, Stephen Winnall wrote: > On 14 Apr 2012, at 02:20, Pedro Duque Vieira wrote: > > > CSS isn't even a language it lacks lots of common language constructs. > > > That depends on what you understand as a "language". > > I would agree that CSS is not a programming language, but it is not > intended to be. Nor is XML for that matter. Both CSS and XML are data > description languages and - as such - capture the state of the described > data at the point where the CSS or XML is loaded (by > Scene.getStylesheets.add() or FXMLLoader.load() etc). > > The provision of "common language constructs" is what scripting languages > provide. We have enough of those already without adding scripting > constructs to CSS and XML. In the context of JavaFX, it may make more sense > to use Java itself. > > I agree that Zonski's proposal is interesting. In the XML world there is > data binding, which allows you to create mapping from XML schemas to Java > Beans. Something similar for CSS would be very useful. > > Steve > -- Pedro Duque Vieira From hang.vo at oracle.com Sun Apr 15 15:34:53 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sun, 15 Apr 2012 22:34:53 +0000 Subject: hg: openjfx/2.2/controls/rt: Fixed RT-20374: Secondary stage and Mac menu issue Message-ID: <20120415223455.42EB6470D1@hg.openjdk.java.net> Changeset: 64e05080d7f6 Author: lsamuels Date: 2012-04-15 15:25 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/64e05080d7f6 Fixed RT-20374: Secondary stage and Mac menu issue ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java From artem.ananiev at oracle.com Sun Apr 15 22:28:39 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 16 Apr 2012 09:28:39 +0400 Subject: Result: New OpenJFX Committer: Alexandre Iline In-Reply-To: <4F6731C3.1040106@oracle.com> References: <4F6731C3.1040106@oracle.com> Message-ID: <4F8BAE07.6000003@oracle.com> Voting for Alexandre Iline [1] is now closed. Yes: 3 Veto: 0 Abstain: 0 According to Bylaws definition of Lazy Consensus [2], this is sufficient to approve the nomination. Artem [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-March/000964.html [2] http://openjdk.java.net/bylaws#lazy-consensus From hang.vo at oracle.com Sun Apr 15 22:34:28 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 16 Apr 2012 05:34:28 +0000 Subject: hg: openjfx/2.2/controls/rt: More ColorPicker prototype changes. Message-ID: <20120416053430.2F99C470D8@hg.openjdk.java.net> Changeset: 6514c55a8a96 Author: Paru Somashekar Date: 2012-04-15 22:32 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/6514c55a8a96 More ColorPicker prototype changes. ! javafx-ui-controls/src/com/sun/javafx/scene/control/ColorPicker.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/ColorPickerAddColorPane.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/ColorPickerPanel.java + javafx-ui-controls/src/com/sun/javafx/scene/control/DoubleField.java + javafx-ui-controls/src/com/sun/javafx/scene/control/InputField.java + javafx-ui-controls/src/com/sun/javafx/scene/control/IntegerField.java + javafx-ui-controls/src/com/sun/javafx/scene/control/WebColorField.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ColorPickerBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/DoubleFieldSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/InputFieldSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/IntegerFieldSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/WebColorFieldSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css From hang.vo at oracle.com Sun Apr 15 23:04:57 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 16 Apr 2012 06:04:57 +0000 Subject: hg: openjfx/2.2/controls/rt: fix build error. Message-ID: <20120416060457.E0B5D470D9@hg.openjdk.java.net> Changeset: 0bca01d7bfc4 Author: Paru Somashekar Date: 2012-04-15 22:59 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/0bca01d7bfc4 fix build error. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java From martin.sladecek at oracle.com Mon Apr 16 00:31:39 2012 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Mon, 16 Apr 2012 09:31:39 +0200 Subject: API Review Request for RT-17438 In-Reply-To: References: <4F87C842.1030305@oracle.com> Message-ID: <4F8BCADB.9040205@oracle.com> On 04/13/2012 09:30 PM, Jeff McDonald wrote: > +1 for me. > > Some random thoughts: > - White space typically includes newlines, and the isWhitespace method > returns true only for tabs and spaces. The documentations makes it clear > what the method does, but it wouldn't be a stretch for a developer to > assume that white space includes newlines. ... especially developers that > do a lot of work with HTML. OK, I think we can also add Enter to the whitespace category. > - "FunctionKey" is more common usage than "FunctionalKey" Right, thanks. > - 10 key numeric keypads typically map arrow keys on to the 2 (Down Arrow), > 4 (Left Arrow), 6 (Right Arrow), 8 (Up arrow) keys. Do these keys return > true for isArrowKey()? There are separate keycodes for them depending on the numlock status (KP_LEFT, KP_RIGHT, ... or NUMPAD0, NUMPAD1, ...). > > Make the methods public so that a method such as isWhitespace could be made > to detect newlines. Extendability allows the methods to be overridden for > other things such as custom keyboards or internationalized keyboards. Not sure what you mean, there are already public, but KeyCode is an enum, so you can't extend from it. -Martin > > Cheers, > Jeff > > On Fri, Apr 13, 2012 at 12:31 AM, Martin Sladecek< > martin.sladecek at oracle.com> wrote: > >> Hello, >> >> JIRA: http://javafx-jira.kenai.com/**browse/RT-17438 >> >> The JIRA requests methods for key classification on KeyEvent class, like >> >> KeyEvent.isFunctionKey() //F1, F2, F3, ..., F24 >> >> KeyEvent.isArrowKey() //UP, DOWN, LEFT, RIGHT. >> >> >> I propose to have these methods on KeyCode class (enum), where they are >> more natural and can be used anywhere the KeyCode objects are present (e.g. >> KeyCodeCombination class). >> So in case of the keyEvent, the calls would look like: >> >> ev.getCode().isArrowKey() >> >> >> The list of propsed KeyCode methods: >> >> /** >> * Functional keys like F1, F2, etc... >> * @return true if this key code corresponds to a functional key >> */ >> public final boolean isFunctionalKey() >> >> /** >> * Navigation keys are arrow keys and Page Down, Page Up, Home, End >> * @return true if this key code corresponds to a navigation key >> */ >> public final boolean isNavigationKey() >> >> /** >> * Left, right, up, down keys (including the keypad arrows) >> * @return true if this key code corresponds to an arrow key >> */ >> public final boolean isArrowKey() >> >> /** >> * Keys that could act as a modifier >> * @return true if this key code corresponds to a modifier key >> */ >> public final boolean isModifierKey() >> >> /** >> * All keys with letters >> * @return true if this key code corresponds to a letter key >> */ >> public final boolean isLetterKey() >> >> /** >> * All Digit keys (including the keypad digits) >> * @return true if this key code corresponds to a digit key >> */ >> public final boolean isDigitKey() >> >> /** >> * All keys on the keypad >> * @return true if this key code corresponds to a keypad key >> */ >> public final boolean isKeypadKey() >> >> /** >> * Space and tab >> * @return true if this key code corresponds to a whitespace key >> */ >> public final boolean isWhitespaceKey() >> >> /** >> * All multimedia keys (channel up/down, volume control, etc...) >> * @return true if this key code corresponds to a media key >> */ >> public final boolean isMediaKey() >> >> >> Thanks, >> -Martin >> >> From lehmann at media-interactive.de Mon Apr 16 02:44:49 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 16 Apr 2012 11:44:49 +0200 Subject: CSS on javaFX In-Reply-To: References: Message-ID: <4F8BEA11.708@media-interactive.de> CSS pseudo classes would be quite helpful to avoid toggling styleClass in code. Unfortunately they cannot be provided by custom controls as of today (without unsafe hacks). On 15.04.2012 19:03, Pedro Duque Vieira wrote: > Problem > is that for more elaborated interfaces, the looks start to have a logic, > which CSS fails to provide. That's when HTML web developers start to use > javascript, toggling HTML elements class's, From hang.vo at oracle.com Mon Apr 16 04:05:39 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 16 Apr 2012 11:05:39 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-20634 Merge Scene's impl_getFocusOwner() and impl_focusOwner property Message-ID: <20120416110540.4F053470E0@hg.openjdk.java.net> Changeset: 9e5241252bf1 Author: Martin Sladecek Date: 2012-04-16 12:56 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/9e5241252bf1 RT-20634 Merge Scene's impl_getFocusOwner() and impl_focusOwner property ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ScrollPaneSkinTest.java From hang.vo at oracle.com Mon Apr 16 05:50:11 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 16 Apr 2012 12:50:11 +0000 Subject: hg: openjfx/2.2/graphics/rt: Fix for RT-20961: made Popup tests independent of each other Message-ID: <20120416125013.8F6B9470E1@hg.openjdk.java.net> Changeset: 2f8d57a36fd5 Author: Lubomir Nerad Date: 2012-04-16 14:43 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/2f8d57a36fd5 Fix for RT-20961: made Popup tests independent of each other ! javafx-ui-common/test/unit/com/sun/javafx/Utils_getScreenForPoint_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/Utils_getScreenForRectangle_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/pgstub/StubToolkit.java ! javafx-ui-common/test/unit/javafx/stage/PopupTest.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java From martin.sladecek at oracle.com Mon Apr 16 07:17:42 2012 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Mon, 16 Apr 2012 16:17:42 +0200 Subject: Color and Gradient animations Message-ID: <4F8C2A06.6010603@oracle.com> Hi, the current API uses StrokeTransition and FillTransition to animate color and you need to create custom Transition in order to animate gradients. Both ways do not perform well as Color and gradients are immutable, so new objects need to be created every pulse during the animation. Here are my proposals to solve this: 1) As Color, LinearGradient, etc... are immutable, we cannot just make them mutable without braking backward-compatibility, so we could have new Animated* (AnimatedColor, AnimatedStop, ...) classes, that would be mutually convertible with their immutable counterparts. The downside is that there would be a lot of duplicated code. Example usage: AnimatedColor color = new AnimatedColor(1.0, 0, 0); shape.setFill(color); //Timeline manipulating "red" property Also FillTransition and StrokeTransition can internally used this, although they would be limited to (Animated)Color. 2) Merge FillTransition and StrokeTransiton into ColorTransition (accepting ObjectProperty instead of Shape, although this is a bit different pattern to the other Transition classes) + introduce LinearGradientTransition and RadialGradientTransiton. The transition would then handle the mutations internally, although this probably means we need special implementations of ObjectProperty in all affected objects. *GradientTransition objects would be tricky however. It's hard (if impossible) to define any reasonable and generic interpolation between two arbitrary gradients, so everything would need to be configured by calling methods on the transition objects. 3) Have some ColorModifier/*GradientModifier classes, that would expose Color/*Gradient properties as FX properties, so they can be animated by normal timelines. Shape's fill and stroke properties would then bind to one property of these modifiers. ColorModifier cm = new ColorModifier(1.0, 0, 0); E.g. shape.fillProperty().bind(cm.result()); //Timeline manipulating some cm property Again, this means we need special implementations of ObjectProperty on Shape's properties in order this to work efficiently. What do you think? Any other ideas? -Martin From jeff at reportmill.com Mon Apr 16 08:01:46 2012 From: jeff at reportmill.com (Jeff Martin) Date: Mon, 16 Apr 2012 10:01:46 -0500 Subject: Color and Gradient animations In-Reply-To: <4F8C2A06.6010603@oracle.com> References: <4F8C2A06.6010603@oracle.com> Message-ID: I'd be surprised if creating new Paint objects was a significant overhead compared to a scene repaint. Have you done a measurement? Jeff Martin On Apr 16, 2012, at 9:17 AM, Martin Sladecek wrote: > Hi, > the current API uses StrokeTransition and FillTransition to animate color and you need to create custom Transition in order to animate gradients. Both ways do not perform well as Color and gradients are immutable, so new objects need to be created every pulse during the animation. > > Here are my proposals to solve this: > > 1) As Color, LinearGradient, etc... are immutable, we cannot just make them mutable without braking backward-compatibility, so we could have new Animated* (AnimatedColor, AnimatedStop, ...) classes, that would be mutually convertible with their immutable counterparts. The downside is that there would be a lot of duplicated code. > > Example usage: > AnimatedColor color = new AnimatedColor(1.0, 0, 0); > shape.setFill(color); > //Timeline manipulating "red" property > > Also FillTransition and StrokeTransition can internally used this, although they would be limited to (Animated)Color. > > 2) Merge FillTransition and StrokeTransiton into ColorTransition (accepting ObjectProperty instead of Shape, although this is a bit different pattern to the other Transition classes) + introduce LinearGradientTransition and RadialGradientTransiton. > The transition would then handle the mutations internally, although this probably means we need special implementations of ObjectProperty in all affected objects. > *GradientTransition objects would be tricky however. It's hard (if impossible) to define any reasonable and generic interpolation between two arbitrary gradients, so everything would need to be configured by calling methods on the transition objects. > > 3) Have some ColorModifier/*GradientModifier classes, that would expose Color/*Gradient properties as FX properties, so they can be animated by normal timelines. Shape's fill and stroke properties would then bind to one property of these modifiers. > > ColorModifier cm = new ColorModifier(1.0, 0, 0); > E.g. shape.fillProperty().bind(cm.result()); > //Timeline manipulating some cm property > > Again, this means we need special implementations of ObjectProperty on Shape's properties in order this to work efficiently. > > What do you think? Any other ideas? > > -Martin From richard.bair at oracle.com Mon Apr 16 07:36:49 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 16 Apr 2012 07:36:49 -0700 Subject: CSS on javaFX In-Reply-To: References: Message-ID: Hi Pedro, I think some of what you are asking for we simply cannot provide without making our Skin implementations public API. Let me explain. One of the key design principles for the JavaFX UI controls was a clear and strong separation between the View and the Model of the control. There is a design tension there where, for convenience, people want more visual state available on the Control class, but for flexibility, it is a bad choice to do so. For example, the Swing JButton specified different icons for different states that the button might be in, as public API on the JButton class. Carried to its logical extreme you would have literally hundreds of such APIs. But even more so, a single control might have radically different views. One use case we used to talk about was a slider. In the normal case there is a track and a knob and you slide the knob within the track. However what if I were doing an application for a Chiropractor, and I wanted the slider to be curved in the shape of the back and the knob to be a vertebra? Or perhaps I will want my slider to be represented as a spinning knob as in A/V equipment, where there isn't a track at all? We have also noted that a ToggleButton and RadioButton are both actually the same control, but with different skins. The TabPane and the "dot pagination" control (like you might see on an iPhone home screen) are actually the same control, just with different visual representation. So we wanted to make sure we kept the View/Model separation as strict as possible. In some places we fudged it, such as the "font" on a Label. Some things like the "graphic text gap", "content display" and so forth also made compromises. Whenever such state is added to the control, it restricts the range of choices available to a Skin provider. All skin implementations of a Label (that are meant for a wider audience than just yourself!) have to deal with all the various content display settings and alignment and so forth. In the most strict sense those variables shouldn't have been on our Labeled, but should have been part of the skin and set via CSS (or some other mechanism for styling the skins). So we did make compromises. So when you are styling things from CSS, sometimes you are styling the control, and sometimes the Skin. And of course from CSS you can also specify the skin! Our default skin implementations are all designed to be styled from CSS. So here are two options for being able to set the style on a skin from Java code. One is type-safe, one is not. Option A: Make the Skin APIs public and specify the skin manually In this option, we would move our default skin implementations to javafx.scene.control.skin.caspian, for example. When you wanted to change the background fills of a button, you could do something like this: Button button = new Button("Hi"); ButtonSkin skin = new ButtonSkin(button); button.setSkin(skin); skin.getBackgrounds().addAll(...); This approach you can do today, except that ButtonSkin isn't public API so it can (and most likely will) change in incompatible ways as time goes on and the ability to set backgrounds / borders / etc is functionality in Region that doesn't have public API yet. But from an architectural perspective this is doable today. This is the only real way to have what you ultimately want -- the type-safe code friendly way to style things. Now, some designer can come along and still override your settings from CSS, so later on if you assume that this skin is actually set up the way you think it is and somebody has styled it differently from CSS it will break, but that's actually intended behavior -- you the developer might be off working on some other project and some poor designer has to spruce up the UI. So best practice would be not to make assumptions on the view (even what skin is being used!). So if you follow this pattern the best practice would be to set it up and then afterwards make no assumption as to what it actually looks like. But that's up to you, if you make such assumptions, then somebody cannot come later and style it without potentially breaking the app. That's your choice. Option B: Modify CSS Styles from Java This option is not type-safe, in fact it is just like in HTML where from JavaScript you can modify the CSS style. We might do it a little differently but the idea is the same. For example: Button button = new Button("Hi"); Style style = button.getStyle(); style.backgrounds.addAll(...); Or something like that. Such that you can hang any known CSS variables on the style for a single node, and then have some string based implementation for styles that we don't know about (since our CSS allows you to create new "variables" in the CSS just by declaring them). So for example: style.put("-my-variable-name", "25pt"); style.fontSize("-my-variable-name"); Or whatnot. This API has not yet been designed, I'm just making this up as I go. But you get the idea -- there would be some kind of API for dealing with common things in a type-safe way (that also allows us to avoid having to do conversions and such) but also some fallback onto essentially a string-based CSS syntax that we can parse and deal with for those things that we cannot anticipate and provide predefined API for. I'm not sure which of these alternatives is something that you prefer, but I'm guessing it is more Option A. The problem with Option A is that it introduces a *lot* of new public API and so we need to be careful about it and it takes time to vet it. Once released, we live with it forever. Of course anybody could take our existing skins and spruce them up, put them in another package, license as GPL (with classpath extension) and publish their own set of Skins which allow you to set everything via a public API, you don't have to wait for us to do it and include it in the platform. Cheers Richard On Apr 15, 2012, at 10:03 AM, Pedro Duque Vieira wrote: > I should have elaborated more on that sentence. > Yes CSS is not a "programming language" nor is it intended to be, it tries > to be a language to describe the visual part of interfaces separating the > structure of a document (HTML) from its appearance (the CSS part). Problem > is that for more elaborated interfaces, the looks start to have a logic, > which CSS fails to provide. That's when HTML web developers start to use > javascript, toggling HTML elements class's, > > I think CSS is a reasonable language to describe visual interfaces, but I > think we can do much better. We have to remind ourselves of its origins, it > appeared in the context of HTML to solve problems caused by its model, it > didn't come up as a language on its own. > > One thing we can not naturally do today, that we would be able to do if we > had an object model of the css properties is animating those properties. We > will be able to do it eventually when CSS3 animations come to JavaFX, but > on the meantime we can't, at least not on a natural, straight forward way. > > In conclusion I think CSS should not THE way to describe visual interfaces > on JavaFX, rather I think it should be one more way of doing it, that is, > we should also be able to accomplish the same by using Java or some other > language without having to parse CSS strings. > > > On Sun, Apr 15, 2012 at 2:15 PM, Stephen Winnall wrote: > >> On 14 Apr 2012, at 02:20, Pedro Duque Vieira wrote: >> >> >> CSS isn't even a language it lacks lots of common language constructs. >> >> >> That depends on what you understand as a "language". >> >> I would agree that CSS is not a programming language, but it is not >> intended to be. Nor is XML for that matter. Both CSS and XML are data >> description languages and - as such - capture the state of the described >> data at the point where the CSS or XML is loaded (by >> Scene.getStylesheets.add() or FXMLLoader.load() etc). >> >> The provision of "common language constructs" is what scripting languages >> provide. We have enough of those already without adding scripting >> constructs to CSS and XML. In the context of JavaFX, it may make more sense >> to use Java itself. >> >> I agree that Zonski's proposal is interesting. In the XML world there is >> data binding, which allows you to create mapping from XML schemas to Java >> Beans. Something similar for CSS would be very useful. >> >> Steve >> > > > > -- > Pedro Duque Vieira From hang.vo at oracle.com Mon Apr 16 11:19:48 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 16 Apr 2012 18:19:48 +0000 Subject: hg: openjfx/2.2/controls/rt: Fixed RT-20951: [Mac] System menu MenuBar is leaked when replacing the stage content Message-ID: <20120416181950.8C3C7470F0@hg.openjdk.java.net> Changeset: 52f318bb9a3f Author: lsamuels Date: 2012-04-16 11:04 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/52f318bb9a3f Fixed RT-20951: [Mac] System menu MenuBar is leaked when replacing the stage content ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java From hang.vo at oracle.com Mon Apr 16 12:05:10 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 16 Apr 2012 19:05:10 +0000 Subject: hg: openjfx/2.2/controls/rt: 4 new changesets Message-ID: <20120416190512.EE3C6470F1@hg.openjdk.java.net> Changeset: 8294b8b16ba5 Author: Kinsley Wong Date: 2012-04-13 16:49 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/8294b8b16ba5 Unit test for RT-20437 ClassCastException in TilePane while using the CSS style -fx-pref-rows. ! javafx-ui-common/test/unit/javafx/scene/layout/TilePaneTest.java Changeset: b1c22b295a54 Author: Kinsley Wong Date: 2012-04-16 10:25 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/b1c22b295a54 merge Changeset: 602ee5b1762e Author: Kinsley Wong Date: 2012-04-16 11:31 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/602ee5b1762e Merge Changeset: 96608885accb Author: Kinsley Wong Date: 2012-04-16 11:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/96608885accb Pagination: fix npe in createCellFactory. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java From deep.blue.6802 at gmail.com Mon Apr 16 12:15:22 2012 From: deep.blue.6802 at gmail.com (Jeff McDonald) Date: Mon, 16 Apr 2012 13:15:22 -0600 Subject: API Review Request for RT-17438 In-Reply-To: <4F8BCADB.9040205@oracle.com> References: <4F87C842.1030305@oracle.com> <4F8BCADB.9040205@oracle.com> Message-ID: On Mon, Apr 16, 2012 at 1:31 AM, Martin Sladecek wrote: > On 04/13/2012 09:30 PM, Jeff McDonald wrote: > >> +1 for me. >> >> Some random thoughts: >> - White space typically includes newlines, and the isWhitespace method >> returns true only for tabs and spaces. The documentations makes it clear >> what the method does, but it wouldn't be a stretch for a developer to >> assume that white space includes newlines. ... especially developers that >> do a lot of work with HTML. >> > OK, I think we can also add Enter to the whitespace category. Richard posted a much more detailed email about whitespace. The list he included is more comprehensive, but the bulk of those characters aren't KeyCodes so they don't fall into the scope of this class and feature. After scanning over the KeyCode class the KeyCode.ENTER (I'm guessing that the RETURN and ENTER keys map to the same KeyCode) is the only one that should be added. > - "FunctionKey" is more common usage than "FunctionalKey" >> > Right, thanks. > > - 10 key numeric keypads typically map arrow keys on to the 2 (Down >> Arrow), >> 4 (Left Arrow), 6 (Right Arrow), 8 (Up arrow) keys. Do these keys return >> true for isArrowKey()? > > There are separate keycodes for them depending on the numlock status > (KP_LEFT, KP_RIGHT, ... or NUMPAD0, NUMPAD1, ...). Your initial proposal already answered this question. The javadoc comments are nice and clear regarding which KeyCodes included and which ones aren't. Disregard my suggestion. > > >> Make the methods public so that a method such as isWhitespace could be >> made >> to detect newlines. Extendability allows the methods to be overridden for >> other things such as custom keyboards or internationalized keyboards. >> > Not sure what you mean, there are already public, but KeyCode is an enum, > so you can't extend from it. > I meant to say to make the to make them non-final rather than "not public", however, enums can't be extended so my suggestion doesn't fit. Please disregard this suggestion as well. Cheers, Jeff > -Martin > >> >> Cheers, >> Jeff >> >> On Fri, Apr 13, 2012 at 12:31 AM, Martin Sladecek< >> martin.sladecek at oracle.com> wrote: >> >> Hello, >>> >>> JIRA: http://javafx-jira.kenai.com/****browse/RT-17438 >>> >>> > >>> >>> >>> The JIRA requests methods for key classification on KeyEvent class, like >>> >>> KeyEvent.isFunctionKey() //F1, F2, F3, ..., F24 >>> >>> KeyEvent.isArrowKey() //UP, DOWN, LEFT, RIGHT. >>> >>> >>> I propose to have these methods on KeyCode class (enum), where they are >>> more natural and can be used anywhere the KeyCode objects are present >>> (e.g. >>> KeyCodeCombination class). >>> So in case of the keyEvent, the calls would look like: >>> >>> ev.getCode().isArrowKey() >>> >>> >>> The list of propsed KeyCode methods: >>> >>> /** >>> * Functional keys like F1, F2, etc... >>> * @return true if this key code corresponds to a functional key >>> */ >>> public final boolean isFunctionalKey() >>> >>> /** >>> * Navigation keys are arrow keys and Page Down, Page Up, Home, End >>> * @return true if this key code corresponds to a navigation key >>> */ >>> public final boolean isNavigationKey() >>> >>> /** >>> * Left, right, up, down keys (including the keypad arrows) >>> * @return true if this key code corresponds to an arrow key >>> */ >>> public final boolean isArrowKey() >>> >>> /** >>> * Keys that could act as a modifier >>> * @return true if this key code corresponds to a modifier key >>> */ >>> public final boolean isModifierKey() >>> >>> /** >>> * All keys with letters >>> * @return true if this key code corresponds to a letter key >>> */ >>> public final boolean isLetterKey() >>> >>> /** >>> * All Digit keys (including the keypad digits) >>> * @return true if this key code corresponds to a digit key >>> */ >>> public final boolean isDigitKey() >>> >>> /** >>> * All keys on the keypad >>> * @return true if this key code corresponds to a keypad key >>> */ >>> public final boolean isKeypadKey() >>> >>> /** >>> * Space and tab >>> * @return true if this key code corresponds to a whitespace key >>> */ >>> public final boolean isWhitespaceKey() >>> >>> /** >>> * All multimedia keys (channel up/down, volume control, etc...) >>> * @return true if this key code corresponds to a media key >>> */ >>> public final boolean isMediaKey() >>> >>> >>> Thanks, >>> -Martin >>> >>> >>> > From james.graham at oracle.com Mon Apr 16 12:29:25 2012 From: james.graham at oracle.com (Jim Graham) Date: Mon, 16 Apr 2012 12:29:25 -0700 Subject: Color and Gradient animations In-Reply-To: <4F8C2A06.6010603@oracle.com> References: <4F8C2A06.6010603@oracle.com> Message-ID: <4F8C7315.7030100@oracle.com> One "new overhead" issue to consider - if you create non-mutable paint instances and set them into Shape objects directly and then expect a repaint whenever those mutable paints mutate then there will have to be some sort of new listener created to manage that. If the implementation is too basic (assuming all Paint objects could be mutable) then we end up with listeners for all paint objects even if they are immutable. If the implementation is at least smart enough to recognize the mutable objects then we still have listeners for those objects and there is still some turmoil when they animate or change - thus negating much of the benefit over just having the external animation object set a new immutable paint object. Binding the Shape paint properties to a mutating value property involves the least overhead on the part of the Shape node I think...? ...jim On 4/16/2012 7:17 AM, Martin Sladecek wrote: > Hi, > the current API uses StrokeTransition and FillTransition to animate > color and you need to create custom Transition in order to animate > gradients. Both ways do not perform well as Color and gradients are > immutable, so new objects need to be created every pulse during the > animation. > > Here are my proposals to solve this: > > 1) As Color, LinearGradient, etc... are immutable, we cannot just make > them mutable without braking backward-compatibility, so we could have > new Animated* (AnimatedColor, AnimatedStop, ...) classes, that would be > mutually convertible with their immutable counterparts. The downside is > that there would be a lot of duplicated code. > > Example usage: > AnimatedColor color = new AnimatedColor(1.0, 0, 0); > shape.setFill(color); > //Timeline manipulating "red" property > > Also FillTransition and StrokeTransition can internally used this, > although they would be limited to (Animated)Color. > > 2) Merge FillTransition and StrokeTransiton into ColorTransition > (accepting ObjectProperty instead of Shape, although this is a > bit different pattern to the other Transition classes) + introduce > LinearGradientTransition and RadialGradientTransiton. > The transition would then handle the mutations internally, although this > probably means we need special implementations of ObjectProperty > in all affected objects. > *GradientTransition objects would be tricky however. It's hard (if > impossible) to define any reasonable and generic interpolation between > two arbitrary gradients, so everything would need to be configured by > calling methods on the transition objects. > > 3) Have some ColorModifier/*GradientModifier classes, that would expose > Color/*Gradient properties as FX properties, so they can be animated by > normal timelines. Shape's fill and stroke properties would then bind to > one property of these modifiers. > > ColorModifier cm = new ColorModifier(1.0, 0, 0); > E.g. shape.fillProperty().bind(cm.result()); > //Timeline manipulating some cm property > > Again, this means we need special implementations of > ObjectProperty on Shape's properties in order this to work > efficiently. > > What do you think? Any other ideas? > > -Martin From pedro.duquevieira at gmail.com Mon Apr 16 13:43:17 2012 From: pedro.duquevieira at gmail.com (pedro.duquevieira at gmail.com) Date: Mon, 16 Apr 2012 21:43:17 +0100 Subject: CSS on JavaFX In-Reply-To: References: Message-ID: <37753DE6-601E-400E-853A-A15D925263D7@gmail.com> Hi Richard, First of all I'd like to thank you for taking the time and patience to read and answer my post. I think you and the rest of the JavaFX team are doing a great job. I find it also very amazing that you take so much interest in what the community has to say. To answer your question, yes I do prefer option A, and yes I think providing that functionality on the skin class is the way to go, separating the model from the view. Making the skin class APIs public sounds like a great idea. As for breaking backwards compatibility, wouldn't it be possible for you to create a new skin class whenever there is new API that will break previous uses of the old skin class? Like ButtonSkin2_2? I don't know how much of a big deal breaking backwards compatibility is, you as a JavaFX platform developer will surely know much better, if what I said above isn't possible would it be acceptable to make the Skin APIs public and issuing a warning to whoever is using them that they may break on subsequent releases? As for your suggestion to do it myself, I would love to but unfortunately I currently don't have time. I would prefer investing my time on another project like bringing more 3d support to JavaFX, which might me of interest on a project I'm doing. Once again thanks, I hope what I said makes some sense. Cheers, > Hi Pedro, > > I think some of what you are asking for we simply cannot provide without making our Skin implementations public API. Let me explain. > > One of the key design principles for the JavaFX UI controls was a clear and strong separation between the View and the Model of the control. There is a design tension there where, for convenience, people want more visual state available on the Control class, but for flexibility, it is a bad choice to do so. For example, the Swing JButton specified different icons for different states that the button might be in, as public API on the JButton class. Carried to its logical extreme you would have literally hundreds of such APIs. > > But even more so, a single control might have radically different views. One use case we used to talk about was a slider. In the normal case there is a track and a knob and you slide the knob within the track. However what if I were doing an application for a Chiropractor, and I wanted the slider to be curved in the shape of the back and the knob to be a vertebra? Or perhaps I will want my slider to be represented as a spinning knob as in A/V equipment, where there isn't a track at all? > > We have also noted that a ToggleButton and RadioButton are both actually the same control, but with different skins. The TabPane and the "dot pagination" control (like you might see on an iPhone home screen) are actually the same control, just with different visual representation. > > So we wanted to make sure we kept the View/Model separation as strict as possible. In some places we fudged it, such as the "font" on a Label. Some things like the "graphic text gap", "content display" and so forth also made compromises. Whenever such state is added to the control, it restricts the range of choices available to a Skin provider. All skin implementations of a Label (that are meant for a wider audience than just yourself!) have to deal with all the various content display settings and alignment and so forth. In the most strict sense those variables shouldn't have been on our Labeled, but should have been part of the skin and set via CSS (or some other mechanism for styling the skins). So we did make compromises. > > So when you are styling things from CSS, sometimes you are styling the control, and sometimes the Skin. And of course from CSS you can also specify the skin! > > Our default skin implementations are all designed to be styled from CSS. So here are two options for being able to set the style on a skin from Java code. One is type-safe, one is not. > > Option A: Make the Skin APIs public and specify the skin manually > > In this option, we would move our default skin implementations to javafx.scene.control.skin.caspian, for example. When you wanted to change the background fills of a button, you could do something like this: > > Button button = new Button("Hi"); > ButtonSkin skin = new ButtonSkin(button); > button.setSkin(skin); > skin.getBackgrounds().addAll(...); > > This approach you can do today, except that ButtonSkin isn't public API so it can (and most likely will) change in incompatible ways as time goes on and the ability to set backgrounds / borders / etc is functionality in Region that doesn't have public API yet. But from an architectural perspective this is doable today. This is the only real way to have what you ultimately want -- the type-safe code friendly way to style things. Now, some designer can come along and still override your settings from CSS, so later on if you assume that this skin is actually set up the way you think it is and somebody has styled it differently from CSS it will break, but that's actually intended behavior -- you the developer might be off working on some other project and some poor designer has to spruce up the UI. So best practice would be not to make assumptions on the view (even what skin is being used!). So if you follow this pattern the best practice would be to set it up and then afterward! > s make no assumption as to what it actually looks like. But that's up to you, if you make such assumptions, then somebody cannot come later and style it without potentially breaking the app. That's your choice. > > Option B: Modify CSS Styles from Java > > This option is not type-safe, in fact it is just like in HTML where from JavaScript you can modify the CSS style. We might do it a little differently but the idea is the same. For example: > > Button button = new Button("Hi"); > Style style = button.getStyle(); > style.backgrounds.addAll(...); > > Or something like that. Such that you can hang any known CSS variables on the style for a single node, and then have some string based implementation for styles that we don't know about (since our CSS allows you to create new "variables" in the CSS just by declaring them). So for example: > > style.put("-my-variable-name", "25pt"); > style.fontSize("-my-variable-name"); > > Or whatnot. This API has not yet been designed, I'm just making this up as I go. But you get the idea -- there would be some kind of API for dealing with common things in a type-safe way (that also allows us to avoid having to do conversions and such) but also some fallback onto essentially a string-based CSS syntax that we can parse and deal with for those things that we cannot anticipate and provide predefined API for. > > I'm not sure which of these alternatives is something that you prefer, but I'm guessing it is more Option A. The problem with Option A is that it introduces a *lot* of new public API and so we need to be careful about it and it takes time to vet it. Once released, we live with it forever. Of course anybody could take our existing skins and spruce them up, put them in another package, license as GPL (with classpath extension) and publish their own set of Skins which allow you to set everything via a public API, you don't have to wait for us to do it and include it in the platform. > > Cheers > Richard From hang.vo at oracle.com Mon Apr 16 14:34:51 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 16 Apr 2012 21:34:51 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-19783: Provide an option to allow modal windows to be blocking Message-ID: <20120416213455.96E9F470F6@hg.openjdk.java.net> Changeset: eb8eb40f9746 Author: kcr Date: 2012-04-16 14:16 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/eb8eb40f9746 RT-19783: Provide an option to allow modal windows to be blocking ! javafx-ui-common/src/javafx/stage/Stage.java From hang.vo at oracle.com Mon Apr 16 15:35:30 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 16 Apr 2012 22:35:30 +0000 Subject: hg: openjfx/2.2/controls/rt: 2 new changesets Message-ID: <20120416223533.5BD0C470FF@hg.openjdk.java.net> Changeset: d20f555d0611 Author: Kinsley Wong Date: 2012-04-16 15:12 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/d20f555d0611 Pagination: consume all scrolling events. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 2da390c66ea6 Author: Kinsley Wong Date: 2012-04-16 15:13 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/2da390c66ea6 RT-20764: Vertical scrollbars do not work in a horizontal list view. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java From hang.vo at oracle.com Mon Apr 16 17:19:24 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 17 Apr 2012 00:19:24 +0000 Subject: hg: openjfx/2.2/controls/rt: some minor fixes Message-ID: <20120417001926.5665347109@hg.openjdk.java.net> Changeset: 64dda18b2529 Author: Paru Somashekar Date: 2012-04-16 17:18 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/64dda18b2529 some minor fixes ! javafx-ui-controls/src/com/sun/javafx/scene/control/ColorPickerAddColorPane.java From hang.vo at oracle.com Mon Apr 16 22:33:56 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 17 Apr 2012 05:33:56 +0000 Subject: hg: openjfx/2.2/graphics/rt: RT-20979: minor javadoc fix. Message-ID: <20120417053357.F11D947113@hg.openjdk.java.net> Changeset: f95479e4ed3b Author: Pavel Safrata Date: 2012-04-17 07:19 +0200 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/f95479e4ed3b RT-20979: minor javadoc fix. ! javafx-ui-common/src/javafx/scene/Node.java From hang.vo at oracle.com Tue Apr 17 09:03:58 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 17 Apr 2012 16:03:58 +0000 Subject: hg: openjfx/2.2/graphics/rt: 17 new changesets Message-ID: <20120417160411.DB5A74711F@hg.openjdk.java.net> Changeset: c2f82cdfe9fd Author: Kinsley Wong Date: 2012-04-09 16:50 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/c2f82cdfe9fd RT-12765: GridPane addRow() and addColumn() methods should append to internal structure. ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/test/unit/javafx/scene/layout/GridPaneTest.java Changeset: 818ef2149cf1 Author: Kinsley Wong Date: 2012-04-09 17:43 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/818ef2149cf1 RT-20476: A mouse press (rather than a mouse click) should select a Tab in TabPane. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java Changeset: 85016c7b7e6c Author: Kinsley Wong Date: 2012-04-09 19:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/85016c7b7e6c fix broken unit tests. ! javafx-ui-common/src/javafx/scene/layout/GridPane.java Changeset: a9aa43c1c740 Author: Kinsley Wong Date: 2012-04-10 14:35 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a9aa43c1c740 dos2unix ! javafx-ui-controls/src/com/sun/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/PaginationCell.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/PaginationBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 6d5dabb1a6cf Author: leifs Date: 2012-04-12 18:42 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/6d5dabb1a6cf Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/rt Changeset: a753578a5ebe Author: Kinsley Wong Date: 2012-04-13 16:18 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/a753578a5ebe RT20919: fx2.2-h17-b01: VirtualFlow changes caused 45% regression in Controls.TreeView-Keyboard. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 4cd43a31d899 Author: Kinsley Wong Date: 2012-04-13 16:25 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/4cd43a31d899 RT-20901: [JAVADOC] Incorrect code fragment in StackPane.html. ! javafx-ui-common/src/javafx/scene/layout/StackPane.java Changeset: 4c9bcf6130da Author: Kinsley Wong Date: 2012-04-13 16:37 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/4c9bcf6130da RT-20437: ClassCastException in TilePane while using the CSS style -fx-pref-rows ! javafx-ui-common/src/javafx/scene/layout/TilePane.java Changeset: 64e05080d7f6 Author: lsamuels Date: 2012-04-15 15:25 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/64e05080d7f6 Fixed RT-20374: Secondary stage and Mac menu issue ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java Changeset: 6514c55a8a96 Author: Paru Somashekar Date: 2012-04-15 22:32 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/6514c55a8a96 More ColorPicker prototype changes. ! javafx-ui-controls/src/com/sun/javafx/scene/control/ColorPicker.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/ColorPickerAddColorPane.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/ColorPickerPanel.java + javafx-ui-controls/src/com/sun/javafx/scene/control/DoubleField.java + javafx-ui-controls/src/com/sun/javafx/scene/control/InputField.java + javafx-ui-controls/src/com/sun/javafx/scene/control/IntegerField.java + javafx-ui-controls/src/com/sun/javafx/scene/control/WebColorField.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ColorPickerBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/DoubleFieldSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/InputFieldSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/IntegerFieldSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/WebColorFieldSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: 0bca01d7bfc4 Author: Paru Somashekar Date: 2012-04-15 22:59 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/0bca01d7bfc4 fix build error. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java Changeset: 52f318bb9a3f Author: lsamuels Date: 2012-04-16 11:04 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/52f318bb9a3f Fixed RT-20951: [Mac] System menu MenuBar is leaked when replacing the stage content ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java Changeset: 8294b8b16ba5 Author: Kinsley Wong Date: 2012-04-13 16:49 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/8294b8b16ba5 Unit test for RT-20437 ClassCastException in TilePane while using the CSS style -fx-pref-rows. ! javafx-ui-common/test/unit/javafx/scene/layout/TilePaneTest.java Changeset: b1c22b295a54 Author: Kinsley Wong Date: 2012-04-16 10:25 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/b1c22b295a54 merge Changeset: 602ee5b1762e Author: Kinsley Wong Date: 2012-04-16 11:31 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/602ee5b1762e Merge Changeset: 96608885accb Author: Kinsley Wong Date: 2012-04-16 11:56 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/96608885accb Pagination: fix npe in createCellFactory. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: bee66ffe3182 Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-04-17 08:57 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/graphics/rt/rev/bee66ffe3182 Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx//rt From hang.vo at oracle.com Tue Apr 17 10:04:48 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 17 Apr 2012 17:04:48 +0000 Subject: hg: openjfx/2.2/controls/rt: RT-20576: font size is inherited twice in controls Message-ID: <20120417170450.0013C47123@hg.openjdk.java.net> Changeset: fd3c17005048 Author: David Grieve Date: 2012-04-17 11:50 -0400 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/fd3c17005048 RT-20576: font size is inherited twice in controls ! javafx-ui-common/src/com/sun/javafx/css/CascadingStyle.java ! javafx-ui-common/src/com/sun/javafx/css/Declaration.java ! javafx-ui-common/src/com/sun/javafx/css/StyleConverter.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/converters/FontConverter.java ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.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/StyleablePropertyTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/parser/CSSParserTest.java From leif.samuelsson at oracle.com Tue Apr 17 15:45:30 2012 From: leif.samuelsson at oracle.com (Leif Samuelsson) Date: Tue, 17 Apr 2012 15:45:30 -0700 Subject: API REVIEW request for RT-17138 Allow promptText on TextArea controls Message-ID: <4F8DF28A.7000908@oracle.com> JIRA: http://javafx-jira.kenai.com/browse/RT-17138 This tweak will move the following API up from TextField to its superclass TextInputControl, and will therefore also be available on TextArea. /** * The prompt text to display in the {@code TextInputControl}, or * null if no prompt text is displayed. */ public final StringProperty promptTextProperty(); public final String getPromptText(); public final void setPromptText(String value); From jonathan.giles at oracle.com Tue Apr 17 16:20:03 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 18 Apr 2012 11:20:03 +1200 Subject: API REVIEW request for RT-17138 Allow promptText on TextArea controls In-Reply-To: <4F8DF28A.7000908@oracle.com> References: <4F8DF28A.7000908@oracle.com> Message-ID: <4F8DFAA3.9070808@oracle.com> +1 -- Jonathan On Wednesday, 18 April 2012 10:45:30 a.m., Leif Samuelsson wrote: > JIRA: http://javafx-jira.kenai.com/browse/RT-17138 > > This tweak will move the following API up from TextField to its > superclass > TextInputControl, and will therefore also be available on TextArea. > > /** > * The prompt text to display in the {@code TextInputControl}, or > * null if no prompt text is displayed. > */ > public final StringProperty promptTextProperty(); > public final String getPromptText(); > public final void setPromptText(String value); > From jonathan.giles at oracle.com Tue Apr 17 17:15:35 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 18 Apr 2012 12:15:35 +1200 Subject: [REVIEW REQUEST] Add userData property and properties map to TableColumn class Message-ID: <4F8E07A7.6090000@oracle.com> Hi all, A simple API addition request for your pondering today: http://javafx-jira.kenai.com/browse/RT-20956 This RFE asks for the userData property to be added to TableColumn. userData is a property on Node, and in fact is just a shortcut to setting a property in the Node.properties map. Therefore, I would like to expose both userData and the properties map on TableColumn. I can see the value in adding this in, and there is a patch attached to the Jira issue above that adds this in. This API has already been added to another 'non-control' (i.e. a class in the controls package that doesn't extend from Control, and thus Node) - the MenuItem class has both the userData property and the properties map. It could be argued that this should be against all controls that do not extend Control (including TableColumn, Tab, and the MenuItem classes from memory), but for now I'm taking it on a case-by-case base. I'm totally happen to be asked to add this API to Tab as well, if people want, as it is now the only outlier. -- -- Jonathan From jonathan.giles at oracle.com Tue Apr 17 17:30:01 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 18 Apr 2012 12:30:01 +1200 Subject: [REVIEW REQUEST] Add text property to ComboBox In-Reply-To: <4F62FAD6.3000904@oracle.com> References: <4F5FEC1F.4080309@oracle.com> <4F6080D6.6040108@oracle.com> <4F60FCBC.9000900@oracle.com> <4F61A04F.1030103@oracle.com> <4F61C8A7.9000900@bestsolution.at> <4F61EF81.8050003@oracle.com> <4F62461F.9040805@oracle.com> <4F62FAD6.3000904@oracle.com> Message-ID: <4F8E0B09.4010206@oracle.com> Hi all, Now that I'm back to work and feature freeze for 2.2 is nearing, I'm hoping to get a resolution on this topic. The basic premise is covered here: http://javafx-jira.kenai.com/browse/RT-19589 Simply put, there are often requirements to access the editor component of the ComboBox control, to do things such as reading and writing the current input (without interacting with the ComboBox value property), showing prompt text, setting or clearing text selection, etc. This is being especially driven by the Scene Builder team, who are finding the ComboBox control limiting for them. The ComboBox control is a specialisation of the ComboBoxBase control. ComboBoxBase is display-agnostic (both in terms of the editor functionality, as well as what happens when show() is called), whereas ComboBox is defined to be the most commonly-required ComboBox design: a Button/TextField that pops up a ListView when clicked. This means that conceptually it is totally fine for ComboBox to return the TextField/TextInputControl via some 'getEditor()' (or similar) method. The concern expressed in earlier emails was that this was leaking the skin implementation out into the public control API. I would argue that this is not necessarily true - it is leaking it out into the ComboBox public API definitely, but not into the ComboBoxBase API. This means that future implementers of ComboBox-like functionality who are not wanting the editing functionality to be TextInputControl/TextField-based would be unwise to extend ComboBox, but they should be totally fine extending ComboBoxBase, where there will be no 'getEditor()' (or similar) method. What are peoples thoughts? Can we wrap this one up by simply exposing the TextField/TextInputControl, or are there concerns with this? Also, if we are to expose one, I'm tempted to expose TextField rather than TextInputControl... Thanks, Jonathan On 16/03/2012 9:33 p.m., Jerome Cambon wrote: > > > On 3/15/12 8:42 PM, Jonathan Giles wrote: >> >> On 16/03/2012 2:32 a.m., Jerome Cambon wrote: >>> Exposing TextInputControl is exactly what we need. At least it is >>> the purpose of the Jira which is the base of this discussion. >>> We have concrete requirements in Scene Builder for this. >>> >>> Our use case is the following : >>> - we have a set of editable ComboBox in a VBox, with initial values set >>> - for convenience, once modified, we directly type TAB to go to the >>> next ComboBox >>> - its value is selected so that we can directly enter the new value >>> without having to remove the old one >>> >>> This seems to be a very common use case... >>> >> I can see the point of exposing the TextField, but as with others in >> this thread, it does leave me feeling uncomfortable. My inclination >> is to provide the desired API directly on ComboBox. > > I agree to not expose TextField. I'm speaking about TextInputControl > here. > What do you mean by "the desired API" ? > > thanks > JErome > From hang.vo at oracle.com Tue Apr 17 18:49:53 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 18 Apr 2012 01:49:53 +0000 Subject: hg: openjfx/2.2/controls/rt: 3 new changesets Message-ID: <20120418014956.CAF7B47136@hg.openjdk.java.net> Changeset: 6f70a6e9bb6c Author: Kinsley Wong Date: 2012-04-17 12:13 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/6f70a6e9bb6c Pagination: Switch skin code to use a ScrollPane instead of a ListView. ! javafx-ui-controls/src/com/sun/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/PaginationBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: ec49c62b9b1c Author: Kinsley Wong Date: 2012-04-17 18:43 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/ec49c62b9b1c Pagination: add page transition effects. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java Changeset: 3d6637fc8259 Author: Kinsley Wong Date: 2012-04-17 18:44 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2/controls/rt/rev/3d6637fc8259 merge From tbee at tbee.org Tue Apr 17 22:25:42 2012 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 18 Apr 2012 07:25:42 +0200 Subject: [REVIEW REQUEST] Add text property to ComboBox In-Reply-To: <4F8E0B09.4010206@oracle.com> References: <4F5FEC1F.4080309@oracle.com> <4F6080D6.6040108@oracle.com> <4F60FCBC.9000900@oracle.com> <4F61A04F.1030103@oracle.com> <4F61C8A7.9000900@bestsolution.at> <4F61EF81.8050003@oracle.com> <4F62461F.9040805@oracle.com> <4F62FAD6.3000904@oracle.com> <4F8E0B09.4010206@oracle.com> Message-ID: <4F8E5056.7040705@tbee.org> I think this is a point where there is no absolute true or false. Your reasoning is sound, the question is how hard this "separation of concerns" should be. In his email two days ago Richard mentioned there were other compromises, so this could be one as well. On the other hand; if you are exposing the TextField, there will be other usage of that as well. People will not only react to text changes, but start doing other stuff with the TextField field. It will set a way of working, not how JavaFX wants things to be. Why would we expose the full TextField instead of only what actually is needed to solve the problem? My gut keeps saying no. Tom On 2012-04-18 02:30, Jonathan Giles wrote: > Hi all, > > Now that I'm back to work and feature freeze for 2.2 is nearing, I'm hoping to get a resolution on this topic. > > The basic premise is covered here: http://javafx-jira.kenai.com/browse/RT-19589 > > Simply put, there are often requirements to access the editor component of the ComboBox control, to do things such as reading and writing the current input (without interacting with the ComboBox value property), showing prompt text, setting or clearing text selection, etc. This is being especially driven by the Scene Builder team, who are finding the ComboBox control limiting for them. > > The ComboBox control is a specialisation of the ComboBoxBase control. ComboBoxBase is display-agnostic (both in terms of the editor functionality, as well as what happens when show() is called), whereas ComboBox is defined to be the most commonly-required ComboBox design: a Button/TextField that pops up a ListView when clicked. This means that conceptually it is totally fine for ComboBox to return the TextField/TextInputControl via some 'getEditor()' (or similar) method. > > The concern expressed in earlier emails was that this was leaking the skin implementation out into the public control API. I would argue that this is not necessarily true - it is leaking it out into the ComboBox public API definitely, but not into the ComboBoxBase API. This means that future implementers of ComboBox-like functionality who are not wanting the editing functionality to be TextInputControl/TextField-based would be unwise to extend ComboBox, but they should be totally fine extending ComboBoxBase, where there will be no 'getEditor()' (or similar) method. > > What are peoples thoughts? Can we wrap this one up by simply exposing the TextField/TextInputControl, or are there concerns with this? Also, if we are to expose one, I'm tempted to expose TextField rather than TextInputControl... > > Thanks, > Jonathan > > On 16/03/2012 9:33 p.m., Jerome Cambon wrote: >> >> >> On 3/15/12 8:42 PM, Jonathan Giles wrote: >>> >>> On 16/03/2012 2:32 a.m., Jerome Cambon wrote: >>>> Exposing TextInputControl is exactly what we need. At least it is the purpose of the Jira which is the base of this discussion. >>>> We have concrete requirements in Scene Builder for this. >>>> >>>> Our use case is the following : >>>> - we have a set of editable ComboBox in a VBox, with initial values set >>>> - for convenience, once modified, we directly type TAB to go to the next ComboBox >>>> - its value is selected so that we can directly enter the new value without having to remove the old one >>>> >>>> This seems to be a very common use case... >>>> >>> I can see the point of exposing the TextField, but as with others in this thread, it does leave me feeling uncomfortable. My inclination is to provide the desired API directly on ComboBox. >> >> I agree to not expose TextField. I'm speaking about TextInputControl here. >> What do you mean by "the desired API" ? >> >> thanks >> JErome >> > From tbee at tbee.org Tue Apr 17 22:29:06 2012 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 18 Apr 2012 07:29:06 +0200 Subject: [REVIEW REQUEST] Add text property to ComboBox In-Reply-To: <4F8E5056.7040705@tbee.org> References: <4F5FEC1F.4080309@oracle.com> <4F6080D6.6040108@oracle.com> <4F60FCBC.9000900@oracle.com> <4F61A04F.1030103@oracle.com> <4F61C8A7.9000900@bestsolution.at> <4F61EF81.8050003@oracle.com> <4F62461F.9040805@oracle.com> <4F62FAD6.3000904@oracle.com> <4F8E0B09.4010206@oracle.com> <4F8E5056.7040705@tbee.org> Message-ID: <4F8E5122.3030407@tbee.org> (Nagging kids about some breakfast they want, so I forgot one argument. ;-) As a parallel: in the compromise where the font was exposed, why wasn't the whole control in the skin exposed? Tom On 2012-04-18 07:25, Tom Eugelink wrote: > > I think this is a point where there is no absolute true or false. Your reasoning is sound, the question is how hard this "separation of concerns" should be. In his email two days ago Richard mentioned there were other compromises, so this could be one as well. > > On the other hand; if you are exposing the TextField, there will be other usage of that as well. People will not only react to text changes, but start doing other stuff with the TextField field. It will set a way of working, not how JavaFX wants things to be. Why would we expose the full TextField instead of only what actually is needed to solve the problem? > > My gut keeps saying no. > > Tom > > > > > On 2012-04-18 02:30, Jonathan Giles wrote: >> Hi all, >> >> Now that I'm back to work and feature freeze for 2.2 is nearing, I'm hoping to get a resolution on this topic. >> >> The basic premise is covered here: http://javafx-jira.kenai.com/browse/RT-19589 >> >> Simply put, there are often requirements to access the editor component of the ComboBox control, to do things such as reading and writing the current input (without interacting with the ComboBox value property), showing prompt text, setting or clearing text selection, etc. This is being especially driven by the Scene Builder team, who are finding the ComboBox control limiting for them. >> >> The ComboBox control is a specialisation of the ComboBoxBase control. ComboBoxBase is display-agnostic (both in terms of the editor functionality, as well as what happens when show() is called), whereas ComboBox is defined to be the most commonly-required ComboBox design: a Button/TextField that pops up a ListView when clicked. This means that conceptually it is totally fine for ComboBox to return the TextField/TextInputControl via some 'getEditor()' (or similar) method. >> >> The concern expressed in earlier emails was that this was leaking the skin implementation out into the public control API. I would argue that this is not necessarily true - it is leaking it out into the ComboBox public API definitely, but not into the ComboBoxBase API. This means that future implementers of ComboBox-like functionality who are not wanting the editing functionality to be TextInputControl/TextField-based would be unwise to extend ComboBox, but they should be totally fine extending ComboBoxBase, where there will be no 'getEditor()' (or similar) method. >> >> What are peoples thoughts? Can we wrap this one up by simply exposing the TextField/TextInputControl, or are there concerns with this? Also, if we are to expose one, I'm tempted to expose TextField rather than TextInputControl... >> >> Thanks, >> Jonathan >> >> On 16/03/2012 9:33 p.m., Jerome Cambon wrote: >>> >>> >>> On 3/15/12 8:42 PM, Jonathan Giles wrote: >>>> >>>> On 16/03/2012 2:32 a.m., Jerome Cambon wrote: >>>>> Exposing TextInputControl is exactly what we need. At least it is the purpose of the Jira which is the base of this discussion. >>>>> We have concrete requirements in Scene Builder for this. >>>>> >>>>> Our use case is the following : >>>>> - we have a set of editable ComboBox in a VBox, with initial values set >>>>> - for convenience, once modified, we directly type TAB to go to the next ComboBox >>>>> - its value is selected so that we can directly enter the new value without having to remove the old one >>>>> >>>>> This seems to be a very common use case... >>>>> >>>> I can see the point of exposing the TextField, but as with others in this thread, it does leave me feeling uncomfortable. My inclination is to provide the desired API directly on ComboBox. >>> >>> I agree to not expose TextField. I'm speaking about TextInputControl here. >>> What do you mean by "the desired API" ? >>> >>> thanks >>> JErome >>> >> > > > From zonski at googlemail.com Wed Apr 18 00:39:05 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Wed, 18 Apr 2012 15:39:05 +0800 Subject: CSS on javaFX In-Reply-To: References: Message-ID: <2351E08F-8245-41BE-AA64-420B4FA71D7D@gmail.com> Hi Richard, Some thoughts (I'm in a remote outback town, on a temperamental connection, on my phone so apologies for the dodgy pseudo code and looseness of this email). There are two parts to CSS. The first are the 'attributes' which are just a bunch of settings - a kind of 'display model'. The second is the whole selector/class/specifier stuff that is used to derive the applicable attributes for each Control. I'm not a fan of CSS selectors and the 'cascading' part of it all. I'd personally prefer this whole part to go away. It is way too loose, fragile and error prone for my liking. One man's trash is another man's treasure though, and what I dislike, for its looseness, others seem to love for it's dynamicness. So assuming CSS selectors are here to stay, I'd prefer to see an option C that focused less on Control styles and more on an Object Model for the Stylesheets themselves. A kind of DOM for the Stylesheet that we can read and manipulate. So to set a Stylesheet on a scene we would do: Stylesheet sheet = Stylesheet.load("mystyles.css"); scene.getStylesheets().add(sheet); And the 'Stylesheet' would allow us to iterate over its styles (and variables, etc): List