From hang.vo at oracle.com Wed Feb 1 06:52:49 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 01 Feb 2012 14:52:49 +0000 Subject: hg: openjfx/2.1/master/rt: 5 new changesets Message-ID: <20120201145250.C5B18472DB@hg.openjdk.java.net> Changeset: 82c9e6f656ca Author: Morris Meyer Date: 2012-01-25 00:01 -0500 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/82c9e6f656ca [TEST ONLY] turn off tests that fail recent p21-graphics integration ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java Changeset: 90103969cc77 Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-01-25 09:31 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/90103969cc77 Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/2.1/MASTER/jfx/rt ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java Changeset: bcf63abfdbbf Author: Michael Heinrichs Date: 2012-01-31 10:13 +0100 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/bcf63abfdbbf Ignore tests that rely on reflecting internal implementation of properties [RT-19311] ! javafx-ui-controls/test/javafx/scene/control/LabelTest.java ! javafx-ui-controls/test/javafx/scene/control/ListCellTest.java Changeset: b68ae02f60e5 Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-01-31 10:07 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/b68ae02f60e5 Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/2.1/MASTER/jfx/rt ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java Changeset: 5fd0bc71c9d6 Author: David Grieve Date: 2012-02-01 09:34 -0500 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/5fd0bc71c9d6 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.1/MASTER/jfx/rt From hang.vo at oracle.com Wed Feb 1 14:03:55 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 01 Feb 2012 22:03:55 +0000 Subject: hg: openjfx/2.1/master/rt: Fixed RT-19122: MenuBar: focused state is not displayed Message-ID: <20120201220357.097B5472E4@hg.openjdk.java.net> Changeset: 42a04bbebdfe Author: leifs Date: 2012-02-01 13:53 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/42a04bbebdfe Fixed RT-19122: MenuBar: focused state is not displayed ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/javafx/scene/control/MenuButton.java From hang.vo at oracle.com Wed Feb 1 15:52:56 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 01 Feb 2012 23:52:56 +0000 Subject: hg: openjfx/2.1/master/rt: 2 new changesets Message-ID: <20120201235256.E4A0A472E5@hg.openjdk.java.net> Changeset: b0401c94eaf9 Author: jgiles Date: 2012-02-02 12:48 +1300 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/b0401c94eaf9 RT-19276: CSS ladders work not correctly with "dark" backgrounds ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: 29cf18d011d8 Author: jgiles Date: 2012-02-02 12:50 +1300 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/29cf18d011d8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.1/scrum/controls/jfx/rt ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css From hang.vo at oracle.com Wed Feb 1 16:42:39 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 02 Feb 2012 00:42:39 +0000 Subject: hg: openjfx/2.1/master/rt: Fixed RT-16617: It is not possible to move focus from TextArea to another control using keyboard (Mac) Message-ID: <20120202004239.92EE5472EE@hg.openjdk.java.net> Changeset: aa30a7a38cc8 Author: leifs Date: 2012-02-01 16:33 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/aa30a7a38cc8 Fixed RT-16617: It is not possible to move focus from TextArea to another control using keyboard (Mac) ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java From hang.vo at oracle.com Wed Feb 1 17:03:35 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 02 Feb 2012 01:03:35 +0000 Subject: hg: openjfx/2.1/master/rt: Additional fix for RT-16617: It is not possible to move focus from TextArea to another control using keyboard (Mac) Message-ID: <20120202010335.7C1E0472F1@hg.openjdk.java.net> Changeset: c414f044df83 Author: leifs Date: 2012-02-01 16:58 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/c414f044df83 Additional fix for RT-16617: It is not possible to move focus from TextArea to another control using keyboard (Mac) ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/BehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java From hang.vo at oracle.com Wed Feb 1 17:12:39 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 02 Feb 2012 01:12:39 +0000 Subject: hg: openjfx/2.1/master/rt: Fix broken build. Message-ID: <20120202011240.264B1472F7@hg.openjdk.java.net> Changeset: 931e260dd0e8 Author: leifs Date: 2012-02-01 17:07 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/931e260dd0e8 Fix broken build. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/BehaviorBase.java From hang.vo at oracle.com Wed Feb 1 18:12:36 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 02 Feb 2012 02:12:36 +0000 Subject: hg: openjfx/2.1/master/rt: Additional fix for RT-16617: Ctrl-F7 still wasn't working on Mac. Message-ID: <20120202021237.2688A472F8@hg.openjdk.java.net> Changeset: e52158134356 Author: leifs Date: 2012-02-01 18:04 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/e52158134356 Additional fix for RT-16617: Ctrl-F7 still wasn't working on Mac. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/BehaviorBase.java From hang.vo at oracle.com Thu Feb 2 16:22:44 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 03 Feb 2012 00:22:44 +0000 Subject: hg: openjfx/2.1/master/rt: RT-19408: Image is overlapping the button text. Message-ID: <20120203002245.7385147322@hg.openjdk.java.net> Changeset: f71b3db3cab9 Author: Kinsley Wong Date: 2012-02-02 16:12 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/f71b3db3cab9 RT-19408: Image is overlapping the button text. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css From jonathan.giles at oracle.com Fri Feb 3 16:18:16 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Sat, 04 Feb 2012 13:18:16 +1300 Subject: [REVIEW] Restricting the ComboBox selection model to single selection Message-ID: <4F2C7948.60806@oracle.com> Hi all, http://javafx-jira.kenai.com/browse/RT-19367 I'm asking for approval to change the API of the ComboBox selectionModel property, from the more general SelectionModel class, to the more specific SingleSelectionModel class. This enforces the fact that the ComboBox, for now and evermore, will only support single selection (much like the ChoiceBox control). Should multiple selection ever be needed, a separate 'ListBox' control can be developed to more aptly serve these needs. The desire to make this change is, however, more due to the fact that the current API does no one any favours. It misleads developers to think that by installing a MultipleSelectionModel into the property, they may be afforded some multiple selection functionality, which is not true. This change makes it impossible for them to think this, as compilation will fail in this case. I would argue that this is a bug in the API, and one that should be fixed prior to being set in stone. Not fixing this bug prior to shipping the ComboBox control will lead to confusion and / or bug reports from developers expecting functionality. The proposed patch is attached to the Jira issue. The changes are minimal and, I would argue, as risk free as one can hope. It has no impact on unit tests as there were no multiple selection tests written, and I hope the same can be said for the automated tests. Thanks, Jonathan From steve.x.northover at oracle.com Fri Feb 3 16:42:22 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Fri, 03 Feb 2012 19:42:22 -0500 Subject: [REVIEW] Restricting the ComboBox selection model to single selection In-Reply-To: <4F2C7948.60806@oracle.com> References: <4F2C7948.60806@oracle.com> Message-ID: <4F2C7EEE.5030600@oracle.com> +1 If not fixed, forever will it haunt us! Steve On 03/02/2012 7:18 PM, Jonathan Giles wrote: > Hi all, > > http://javafx-jira.kenai.com/browse/RT-19367 > > I'm asking for approval to change the API of the ComboBox > selectionModel property, from the more general SelectionModel class, > to the more specific SingleSelectionModel class. This enforces the > fact that the ComboBox, for now and evermore, will only support single > selection (much like the ChoiceBox control). Should multiple selection > ever be needed, a separate 'ListBox' control can be developed to more > aptly serve these needs. > > The desire to make this change is, however, more due to the fact that > the current API does no one any favours. It misleads developers to > think that by installing a MultipleSelectionModel into the property, > they may be afforded some multiple selection functionality, which is > not true. This change makes it impossible for them to think this, as > compilation will fail in this case. I would argue that this is a bug > in the API, and one that should be fixed prior to being set in stone. > Not fixing this bug prior to shipping the ComboBox control will lead > to confusion and / or bug reports from developers expecting > functionality. > > The proposed patch is attached to the Jira issue. The changes are > minimal and, I would argue, as risk free as one can hope. It has no > impact on unit tests as there were no multiple selection tests > written, and I hope the same can be said for the automated tests. > > Thanks, > Jonathan From deep.blue.6802 at gmail.com Sat Feb 4 20:12:05 2012 From: deep.blue.6802 at gmail.com (Jeff McDonald) Date: Sat, 4 Feb 2012 21:12:05 -0700 Subject: [REVIEW] Restricting the ComboBox selection model to single selection Message-ID: +1 I support the proposal. The selection behavior should be different between a single selection and a multiple selection ComboBox. With a single selection ComboBox the popup should disappear once an item is selected. A multi-selection ComboBox should allow multiple selections before disappearing. Being able to skin a single-selection ComboBox differently than a multi-selection ComboBox would be a benefit as well. See Multi-choice ComboBox which is a Silverlight multi-selection component. Cheers, Jeff On 03/02/2012 7:18 PM, Jonathan Giles wrote: > Hi all, > > http://javafx-jira.kenai.com/browse/RT-19367 > > I'm asking for approval to change the API of the ComboBox > selectionModel property, from the more general SelectionModel class, > to the more specific SingleSelectionModel class. This enforces the > fact that the ComboBox, for now and evermore, will only support single > selection (much like the ChoiceBox control). Should multiple selection > ever be needed, a separate 'ListBox' control can be developed to more > aptly serve these needs. > > The desire to make this change is, however, more due to the fact that > the current API does no one any favours. It misleads developers to > think that by installing a MultipleSelectionModel into the property, > they may be afforded some multiple selection functionality, which is > not true. This change makes it impossible for them to think this, as > compilation will fail in this case. I would argue that this is a bug > in the API, and one that should be fixed prior to being set in stone. > Not fixing this bug prior to shipping the ComboBox control will lead > to confusion and / or bug reports from developers expecting > functionality. > > The proposed patch is attached to the Jira issue. The changes are > minimal and, I would argue, as risk free as one can hope. It has no > impact on unit tests as there were no multiple selection tests > written, and I hope the same can be said for the automated tests. > > Thanks, > Jonathan From tbee at tbee.org Sun Feb 5 00:14:17 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 05 Feb 2012 09:14:17 +0100 Subject: [REVIEW] Restricting the ComboBox selection model to single selection In-Reply-To: References: Message-ID: <4F2E3A59.4030404@tbee.org> Not sure if you two are talking about the same thing. As I understand Jonathan's proposal, he wants to restrict combobox to singleselection, so it never will be possible to have a multiselection combobox. Jeff, OTOH, assumes the option of a multiselect combobox remains. Tom On 2012-02-05 05:12, Jeff McDonald wrote: > +1 > > I support the proposal. > > The selection behavior should be different between a single selection and a > multiple selection ComboBox. With a single selection ComboBox the popup > should disappear once an item is selected. A multi-selection ComboBox > should allow multiple selections before disappearing. Being able to skin a > single-selection ComboBox differently than a multi-selection ComboBox would > be a benefit as well. See Multi-choice > ComboBox > which > is a Silverlight multi-selection component. > > Cheers, > Jeff > > On 03/02/2012 7:18 PM, Jonathan Giles wrote: >> Hi all, >> >> http://javafx-jira.kenai.com/browse/RT-19367 >> >> I'm asking for approval to change the API of the ComboBox >> selectionModel property, from the more general SelectionModel class, >> to the more specific SingleSelectionModel class. This enforces the >> fact that the ComboBox, for now and evermore, will only support single >> selection (much like the ChoiceBox control). Should multiple selection >> ever be needed, a separate 'ListBox' control can be developed to more >> aptly serve these needs. >> >> The desire to make this change is, however, more due to the fact that >> the current API does no one any favours. It misleads developers to >> think that by installing a MultipleSelectionModel into the property, >> they may be afforded some multiple selection functionality, which is >> not true. This change makes it impossible for them to think this, as >> compilation will fail in this case. I would argue that this is a bug >> in the API, and one that should be fixed prior to being set in stone. >> Not fixing this bug prior to shipping the ComboBox control will lead >> to confusion and / or bug reports from developers expecting >> functionality. >> >> The proposed patch is attached to the Jira issue. The changes are >> minimal and, I would argue, as risk free as one can hope. It has no >> impact on unit tests as there were no multiple selection tests >> written, and I hope the same can be said for the automated tests. >> >> Thanks, >> Jonathan From kiranmahlsekar at gmail.com Sun Feb 5 00:11:41 2012 From: kiranmahlsekar at gmail.com (Kiran Mahlsekar) Date: Sun, 5 Feb 2012 13:41:41 +0530 Subject: Contents of openjfx-dev digest..." Message-ID: -- Kiran Mahlsekar 9481953295 From deep.blue.6802 at gmail.com Sun Feb 5 01:15:07 2012 From: deep.blue.6802 at gmail.com (Jeff McDonald) Date: Sun, 5 Feb 2012 02:15:07 -0700 Subject: [REVIEW] Restricting the ComboBox selection model to single selection Message-ID: Hi Tom, A multi-selection combobox (referred to as a ListBox in Jonathan's proposal) would only be available as a unique component (if there's enough interest), and not an option or setting available from a single-selection combobox. Thank for asking for a clarification. Cheers, Jeff >Not sure if you two are talking about the same thing. As I understand Jonathan's proposal, >he wants to restrict combobox to singleselection, so it never will be possible to have a >multiselection combobox. Jeff, OTOH, assumes the option of a multiselect combobox remains. >Tom On 2012-02-05 05:12, Jeff McDonald wrote: > +1 > > I support the proposal. > > The selection behavior should be different between a single selection and a > multiple selection ComboBox. With a single selection ComboBox the popup > should disappear once an item is selected. A multi-selection ComboBox > should allow multiple selections before disappearing. Being able to skin a > single-selection ComboBox differently than a multi-selection ComboBox would > be a benefit as well. See Multi-choice > ComboBox< http://www.codeproject.com/Articles/42133/Multiple-Selection-ComboBox-for-Silverlight > > which > is a Silverlight multi-selection component. > > Cheers, > Jeff > > On 03/02/2012 7:18 PM, Jonathan Giles wrote: >> Hi all, >> >> http://javafx-jira.kenai.com/browse/RT-19367 >> >> I'm asking for approval to change the API of the ComboBox >> selectionModel property, from the more general SelectionModel class, >> to the more specific SingleSelectionModel class. This enforces the >> fact that the ComboBox, for now and evermore, will only support single >> selection (much like the ChoiceBox control). Should multiple selection >> ever be needed, a separate 'ListBox' control can be developed to more >> aptly serve these needs. >> >> The desire to make this change is, however, more due to the fact that >> the current API does no one any favours. It misleads developers to >> think that by installing a MultipleSelectionModel into the property, >> they may be afforded some multiple selection functionality, which is >> not true. This change makes it impossible for them to think this, as >> compilation will fail in this case. I would argue that this is a bug >> in the API, and one that should be fixed prior to being set in stone. >> Not fixing this bug prior to shipping the ComboBox control will lead >> to confusion and / or bug reports from developers expecting >> functionality. >> >> The proposed patch is attached to the Jira issue. The changes are >> minimal and, I would argue, as risk free as one can hope. It has no >> impact on unit tests as there were no multiple selection tests >> written, and I hope the same can be said for the automated tests. >> >> Thanks, >> Jonathan From webczat_200 at poczta.onet.pl Sun Feb 5 04:40:38 2012 From: webczat_200 at poczta.onet.pl (=?UTF-8?B?TWljaGHFgiBaZWdhbg==?=) Date: Sun, 05 Feb 2012 13:40:38 +0100 Subject: accessibility Message-ID: <4F2E78C6.2010807@poczta.onet.pl> Hello, I have the question: Is it planned at all to include linux accessibility in openjfx/javafx? I mean atk or at-spi integration. From richard.bair at oracle.com Mon Feb 6 06:50:22 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 6 Feb 2012 06:50:22 -0800 Subject: [REVIEW] Restricting the ComboBox selection model to single selection In-Reply-To: <4F2C7948.60806@oracle.com> References: <4F2C7948.60806@oracle.com> Message-ID: Sounds like a universal +1. Shura can you chime in? On Feb 3, 2012, at 4:18 PM, Jonathan Giles wrote: > Hi all, > > http://javafx-jira.kenai.com/browse/RT-19367 > > I'm asking for approval to change the API of the ComboBox selectionModel property, from the more general SelectionModel class, to the more specific SingleSelectionModel class. This enforces the fact that the ComboBox, for now and evermore, will only support single selection (much like the ChoiceBox control). Should multiple selection ever be needed, a separate 'ListBox' control can be developed to more aptly serve these needs. > > The desire to make this change is, however, more due to the fact that the current API does no one any favours. It misleads developers to think that by installing a MultipleSelectionModel into the property, they may be afforded some multiple selection functionality, which is not true. This change makes it impossible for them to think this, as compilation will fail in this case. I would argue that this is a bug in the API, and one that should be fixed prior to being set in stone. Not fixing this bug prior to shipping the ComboBox control will lead to confusion and / or bug reports from developers expecting functionality. > > The proposed patch is attached to the Jira issue. The changes are minimal and, I would argue, as risk free as one can hope. It has no impact on unit tests as there were no multiple selection tests written, and I hope the same can be said for the automated tests. > > Thanks, > Jonathan From kevin.rushforth at oracle.com Tue Feb 7 17:05:37 2012 From: kevin.rushforth at oracle.com (kevin.rushforth at oracle.com) Date: Wed, 08 Feb 2012 01:05:37 +0000 Subject: hg: openjfx/2.1/master: build file cleanup Message-ID: <20120208010537.2C054473D1@hg.openjdk.java.net> Changeset: 69c1a5e297ed Author: kcr Date: 2012-02-07 16:46 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rev/69c1a5e297ed build file cleanup ! build-src/build-importer.xml From hang.vo at oracle.com Wed Feb 8 09:56:33 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 08 Feb 2012 17:56:33 +0000 Subject: hg: openjfx/2.1/master/rt: 15 new changesets Message-ID: <20120208175638.62BEB473EE@hg.openjdk.java.net> Changeset: 3557441fca66 Author: hudson Date: 2012-02-01 10:05 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/3557441fca66 Added tag 2.1-b11 for changeset b68ae02f60e5 ! .hgtags Changeset: 5604827e2f6c Author: mickf Date: 2012-02-03 13:37 +0000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/5604827e2f6c RT-19389 : Accelerator text in menus doesn't display non-KeyCode KeyCharacterCombinations ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/KeystrokeUtils.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/KeystrokeUtilsTest.java Changeset: 3afd889b4061 Author: rbair Date: 2012-02-06 11:52 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/3afd889b4061 Fix for RT-19476: ToolBar should have "items" as the DefaultProperty for FXML. Reviewed by Greg Brown. ! javafx-ui-controls/src/javafx/scene/control/ToolBar.java Changeset: 518bdc90d272 Author: rbair Date: 2012-02-06 14:33 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/518bdc90d272 Fix for RT-19478: SplitPane should not rquire with FXML. Reviewed by Greg Brown, tested by Richard. ! javafx-ui-controls/src/javafx/scene/control/SplitPane.java Changeset: 9b9b1b3e1747 Author: leifs Date: 2012-02-06 16:02 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/9b9b1b3e1747 Fixed RT-19332: TextArea regression: clicking misses the target when text is scrolled vertically. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java Changeset: b092ce36823a Author: mickf Date: 2012-02-07 11:21 +0000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/b092ce36823a RT-18293 - [ScrollEvent] cannot be received by scrollBar, which is embedded in a VirtualFlow ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 40dc48688ac9 Author: mickf Date: 2012-02-07 11:23 +0000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/40dc48688ac9 RT-17713 - Odd behavior of horizontal scrolling in TreeView, TableView, and ListView ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 9eae2657ecb0 Author: David Grieve Date: 2012-02-07 10:05 -0500 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/9eae2657ecb0 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.1/MASTER/jfx/rt Changeset: d5cc45b05dc5 Author: rbair Date: 2012-02-01 09:34 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/d5cc45b05dc5 [DOC-ONLY] Fix for RT-19111: Doc bug: javafx.concurrent.Service example has improper generics ! javafx-concurrent/src/javafx/concurrent/Service.java Changeset: 1f8a31913061 Author: Lubomir Nerad Date: 2012-02-06 15:33 +0100 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/1f8a31913061 Fix for RT-19317: Handle transformation, fill and stroke in Shape.intersect, Shape.subtract and Shape.union ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: ba55c693bbd7 Author: kcr Date: 2012-02-06 16:10 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/ba55c693bbd7 RT-19308: Linux/Mac: libraries should be under lib (and not bin) Reviewed by Igor, Scott ! common.properties Changeset: 5259aa889b15 Author: Michael Heinrichs Date: 2012-02-07 12:36 +0100 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/5259aa889b15 Unified listener handling [RT-19252] ! javafx-ui-controls/src/com/sun/javafx/scene/control/ReadOnlyUnbackedObservableList.java ! javafx-ui-controls/src/javafx/scene/control/TextArea.java ! javafx-ui-controls/test/javafx/scene/control/ControlTestUtils.java ! javafx-ui-controls/test/javafx/scene/control/ListCellTest.java Changeset: bff8f9852aad Author: Michael Heinrichs Date: 2012-02-07 12:46 +0100 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/bff8f9852aad Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.1/scrum/graphics/jfx/rt Changeset: 7d7747d58734 Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-02-07 10:59 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/7d7747d58734 Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/2.1/MASTER/jfx//rt Changeset: 829b27e97eb1 Author: hudson Date: 2012-02-08 09:52 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/829b27e97eb1 Added tag 2.1-b12 for changeset 7d7747d58734 ! .hgtags From deep.blue.6802 at gmail.com Wed Feb 8 21:36:44 2012 From: deep.blue.6802 at gmail.com (Jeff McDonald) Date: Wed, 8 Feb 2012 22:36:44 -0700 Subject: The Next Great Thing: An Application Framework Message-ID: Now that JavaFX is delivering on it's promise of delivering the components and pieces need to make an application, it's a perfect time to take a higher level look at what's needed to make a complete application. Here is your chance to add your ideas, comments, criticisms, insights,etc, and say what's on your mind. I don't work for Oracle nor do I speak for Oracle, however, the JavaFX team has shown great interest in listening to developers and delivering what's important to the developer community. Having an application frameworks integrated into the JavaFX library would be a huge advantage to Java developers. Below is a simple bullet list of ideas and features that could be useful to application developers: - Application types to consider: - Desktop - Tablet - Phone - Command line - TV - Set-top box / Bluray player - Service or daemon - Application tooling needs? - Application level / lifecycle events - Exit event (From JSR 296) - Shutdown event (From JSR 296) - Sleep event - Pause event - Show help window event - Show help hints (ala Apple style help) - Eventbus: allow any component to send message and listen to messages from any other component. Message consumers only have to listen to events and are not required to have references to any other objects (other than the eventbus) in order to receive event notices. - Screen resolution change event - Monitor added / removed events - Screen orientation change event - Full screen mode / normal screen mode. - App dock icon menu event / taskbar menu event / start menu event. - Application environment - Supports 3D? - Supports hardware acceleration? - LCD text supported? - Bidi text supported? - Supports full screen mode - Supports App menubar? - Supports dock? - Supports taskbar? - Application controls - App menubar (setter & getter) (The application level is really where the Application menubar should be handled, and not on the Stage/Window level.) - App taskbar - App dock - Set application name (This is app name, not stage or window name. Could be set to display Scene name when focus changes or to show static text.) - App dock icon menu / taskbar menu / start menu. - Application naviagtion - Get window (by id) - Bring window to front - Send window to back - Move window to location - Expose for FX stages to aid in navigating and organizing multiple windows (MacOS style functionality see: YouTube : MacOS X Expose Video ) - Application focus - Get current focused window - Get current focused component - Application state / session management - Save & restore window size & location - Automatic application state saves - Automatic document saves. - Actions / Actions manager - A superpowered decendant of the Swing AbstractAction class & Action interface. - Conditional state actions (Ex. If the "control" key is depressed then an alternate action is made visible or the text of a menu item might change). - Toggle actions (Ex. bold/un-bold or hide/show) - Multi-state actions - Application print support? - Inter-application communication - Allow apps to communicate to each other using a common architecture. From webczat_200 at poczta.onet.pl Thu Feb 9 02:13:25 2012 From: webczat_200 at poczta.onet.pl (=?UTF-8?B?TWljaGHFgiBaZWdhbg==?=) Date: Thu, 09 Feb 2012 11:13:25 +0100 Subject: The Next Great Thing: An Application Framework In-Reply-To: References: Message-ID: <4F339C45.2000005@poczta.onet.pl> Firdst, isn't standard java enough for command line, and java rmi enough for app communications? Second, javax.print looks like something thatis enough for printing, but it still requires java.awt for printing renderable images, so making a new DocFlavor or what? From deep.blue.6802 at gmail.com Thu Feb 9 13:10:20 2012 From: deep.blue.6802 at gmail.com (Jeff McDonald) Date: Thu, 9 Feb 2012 14:10:20 -0700 Subject: The Next Great Thing: An Application Framework In-Reply-To: <4F339C45.2000005@poczta.onet.pl> References: <4F339C45.2000005@poczta.onet.pl> Message-ID: Command line apps could benefit from being able to listen to and respond to application lifecycle events. Command line applications aren't (and shouldn't be) a focus for JavaFX, but maximizing the benefits to all app developers with little or no effort benefits the entire Java ecosystem. JSR-296 also included command line apps as a design consideration for that reason. There are many technologies that can allow apps to send data to one another. The suggestion here is see if we can establish a common set of needs and make it easier for developers write apps that need to communicate with one another. This would a low priority feature in my estimation, but would benefit app developers. javax.print would require the inclusion of AWT into JavaFX, and possibly the Java2D/Swing APIs. Having a dependency on any one of those libraries would be a big step backwards. If someone wanted to make the point that a printing API doesn't quite fit in with the objectives of an Application Framework and should be a separate project then a good argument could be made to support that view. JavaFX currently doesn't have a printing API. It needs one, and one that doesn't rely on AWT or Swing. It would be nice to have some modern features in a new print API. What features would need to be added to Java would largely depend on the level of abstraction that we'd want to support. Apple has done some innovative things such as creating the Bonjour protocol to allow self discovery of devices (including printers). AirPrint is another great idea that allows mobile devices to print to devices without the need for driver installs and such. Printing to PDF would be another nice feature. Some of those features are available in native platforms, but they aren't universally available. Cheers, Jeff On Thu, Feb 9, 2012 at 3:13 AM, Micha? Zegan wrote: > Firdst, isn't standard java enough for command line, and java rmi enough > for app communications? > Second, javax.print looks like something thatis enough for printing, but > it still requires java.awt for printing renderable images, so making a new > DocFlavor or what? > From zonski at googlemail.com Thu Feb 9 15:36:31 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Fri, 10 Feb 2012 09:36:31 +1000 Subject: The Next Great Thing: An Application Framework In-Reply-To: References: Message-ID: The things I feel are needed for an application framework are the features I am putting into JFX Flow , but this is targeted towards web-style, online, form-based business apps. My feeling is that we are better off if JFX just provides a core library with fundamental building blocks, rather than trying to provide a full application framework that forces a specific architecture. People build all sorts of applications, with all sorts of wonderful architectures, and no App framework can cater to all. For example, the application framework needed for an online, form-based business style app vs a desktop, offline app (e.g. an IDE or graphics drawing program) are significantly different. For my money we are much better off keeping these application frameworks as separate, open source, free, community managed projects. We can then have a few key ones that cater to the major flavours of apps. This also decouples the frameworks from the JFX release cycles, and allows them to make use of other open source projects (such as Validation frameworks, Apache commons, Spring, Guice, logging, remoting toolkits, etc), which the core JFX library cannot do. This approach has worked well in web land. You have the official servlet infrastructure as part of the core JEE library and then on top of this people have built frameworks like SpringMVC, Struts, GWT, Seam, etc. People can choose the framework that best solves their needs. As framework builders have come up with new ways to do things, the servlet spec has gradually, and carefully, evolved to support these things. The application frameworks on the other hand have been totally rewritten, thrown away and redone to account for new ways of doing things, new styles, new understandings (e.g. Struts != Struts2, GWT2 is a major change from GWT1, and HTML5 is a game changer for most of these frameworks). So in my mind there are two topics for discussion: 1. What are the flavours of applications that people will want to use JFX to build, and what open source projects should we create to provide for these and what features should they contain? Who's keen to do this work and can we get a collaborative community effort going on this front (I'd be more than happy to get more community involvement on Flow and if someone has a better way of doing things, I'd also happily merge efforts). 2. Based on the discussions from #1 what are the core elements that JFX needs to provide in order to support these frameworks and features? What fundamental building blocks need to be fixed/improved or need to be added? I feel like a lot of the points you've raised in your email are good contributions to the second topic, but there are a few that for me should not be part of JFX and instead should be part of extension libraries: - Eventbus (there are a hundred different ways these can be implemented and plenty of app architectures that don't use them) - Application environment (not exactly sure what this means but it sounds architecture specific?) - Application controls (as above) - Application naviagtion (as above) - Automatic application state saves (there is generally a lot of business logic associated with this, not JFX's domain in my opinion) - Automatic document saves (as above only more so) - Actions / Actions manager (these were not applicable in Swing for a MVP, browser style architecture, they solve only a subset of architectural problems, e.g. undo when using remoting) - A superpowered decendant of the Swing AbstractAction class & Action interface (as above). - Conditional state actions (Ex. If the "control" key is depressed then an alternate action is made visible or the text of a menu item might change). - (as above) - Toggle actions (Ex. bold/un-bold or hide/show) - (as above) - Multi-state actions (as above) - Inter-application communication (this is a Java issue, not a JFX issue. It could be a JSR for inclusion in the Java platform or just a separate library, it is not part of a GUI framework) - Allow apps to communicate to each other using a common architecture (as above) I think also that a lot of the things people require (and hopefully most of the things you listed), should already be in JIRA and if not, should be added to JIRA. I do wonder how the JFX team choose the issues to be fixed/worked on? I don't believe much notice is taken of the voting system, perhaps it should be used more solidly, to allow the community to drive the feature sets they see as important? It would be great if there was a bit of love put into the JIRA setup to define some filters for the following: 1. Listing issues in order of votes (highest to lowest) 2. Listing issues for the next releases/milestones It would be really great if actual dates were put into JIRA for release/milestones so we could see a roadmap of what's being done when and when releases are due. It is not obvious to me (and I am fairly active in the whole thing) which releases are happening when, what features are in which - all I really know is 'lombard' means 'not any time soon mate' and everything else could happen sometime in the next year or two. It's all a bit confusing and vague. One final comment, the absolute fundamental issue that affects all platforms and for me is of such critical importance (it is the weakness that hamstrung Swing), is the whole deployment issue. This needs to be clean, smooth, simple. I can't emphasize this one enough. I feel like we're going to lose the battle to HTML5 if we don't address this issue up front and quickly (like in the next couple of months). I don't want JFX to spend the next 10 years playing second fiddle to crappy web-apps, like Swing has had to. Please don't make me write more JavaScript. On Thu, Feb 9, 2012 at 3:36 PM, Jeff McDonald wrote: > Now that JavaFX is delivering on it's promise of delivering the components > and pieces need to make an application, it's a perfect time to take a > higher level look at what's needed to make a complete application. > > Here is your chance to add your ideas, comments, criticisms, insights,etc, > and say what's on your mind. I don't work for Oracle nor do I speak for > Oracle, however, the JavaFX team has shown great interest in listening to > developers and delivering what's important to the developer community. > Having an application frameworks integrated into the JavaFX library would > be a huge advantage to Java developers. > > Below is a simple bullet list of ideas and features that could be useful to > application developers: > > - Application types to consider: > - Desktop > - Tablet > - Phone > - Command line > - TV > - Set-top box / Bluray player > - Service or daemon > > - Application tooling needs? > > - Application level / lifecycle events > - Exit event (From JSR 296) > - Shutdown event (From JSR 296) > - Sleep event > - Pause event > - Show help window event > - Show help hints (ala Apple style help) > - Eventbus: allow any component to send message and listen to messages from > any other component. Message consumers only have to listen to events and > are not required to have references to any other objects (other than the > eventbus) in order to receive event notices. > - Screen resolution change event > - Monitor added / removed events > - Screen orientation change event > - Full screen mode / normal screen mode. > - App dock icon menu event / taskbar menu event / start menu event. > - Application environment > - Supports 3D? > - Supports hardware acceleration? > - LCD text supported? > - Bidi text supported? > - Supports full screen mode > - Supports App menubar? > - Supports dock? > - Supports taskbar? > - Application controls > - App menubar (setter & getter) (The application level is really where the > Application menubar should be handled, and not on the Stage/Window level.) > - App taskbar > - App dock > - Set application name (This is app name, not stage or window name. > Could be set to display Scene name when focus changes or to show static > text.) > - App dock icon menu / taskbar menu / start menu. > > - Application naviagtion > - Get window (by id) > - Bring window to front > - Send window to back > - Move window to location > - Expose for FX stages to aid in navigating and organizing multiple windows > (MacOS style functionality see: YouTube : MacOS X Expose > Video > ) > - Application focus > - Get current focused window > - Get current focused component > - Application state / session management > - Save & restore window size & location > - Automatic application state saves > - Automatic document saves. > - Actions / Actions manager > - A superpowered decendant of the Swing AbstractAction class & Action > interface. > - Conditional state actions (Ex. If the "control" key is depressed then an > alternate action is made visible or the text of a menu item might change). > - Toggle actions (Ex. bold/un-bold or hide/show) > - Multi-state actions > - Application print support? > > - Inter-application communication > - Allow apps to communicate to each other using a common architecture. > From richard.bair at oracle.com Thu Feb 9 16:15:10 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 9 Feb 2012 16:15:10 -0800 Subject: The Next Great Thing: An Application Framework In-Reply-To: References: Message-ID: <67E68928-E012-4167-80E4-7A7CD303D073@oracle.com> On the other hand, the more structured the application framework, the better tool support you can get. For example, if SceneBuilder had enough structure, it could show all the different pages in your application, indicate which actions move from one page to the next, what CSS files apply to which pages, what methods are available on the controller, what localization files exist for different pages, switch between locales to see what things look like, show the layout for iPad vs. Desktop vs. whatever, etc. I don't to tie scene builder to a specific app framework, unless that app framework is part of the platform. Other things, like validation, I think really wants to be part of the controls API as opposed to be completely standalone. But you make really good arguments for being conservative in what goes into the core. I think one of the things that made Swing so hard to learn, was that it didn't provide any structure at all. > The things I feel are needed for an application framework are the features > I am putting into JFX Flow , but this is > targeted towards web-style, online, form-based business apps. > > My feeling is that we are better off if JFX just provides a core library > with fundamental building blocks, rather than trying to provide a full > application framework that forces a specific architecture. People build all > sorts of applications, with all sorts of wonderful architectures, and no > App framework can cater to all. For example, the application framework > needed for an online, form-based business style app vs a desktop, offline > app (e.g. an IDE or graphics drawing program) are significantly different. I think you make a solid argument that there are different classes of applications. The SceneBuilder itself, for example, wouldn't make any use of a page-based application framework, neither would an IDE. Yet most apps I've written would work very comfortably with a page-based framework -- and those were all traditional desktop apps! A CAD program or 3D game would again be some other application arch-type. But does that mean we shouldn't provide an API for the most common application arch-type in the platform? Suppose we did so, but it was in a separate module, meaning you didn't have to use it if you didn't want to? Richard From zonski at googlemail.com Thu Feb 9 17:30:31 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Fri, 10 Feb 2012 11:30:31 +1000 Subject: The Next Great Thing: An Application Framework In-Reply-To: <67E68928-E012-4167-80E4-7A7CD303D073@oracle.com> References: <67E68928-E012-4167-80E4-7A7CD303D073@oracle.com> Message-ID: On Fri, Feb 10, 2012 at 10:15 AM, Richard Bair wrote: > On the other hand, the more structured the application framework, the > better tool support you can get. For example, if SceneBuilder had enough > structure, it could show all the different pages in your application, > indicate which actions move from one page to the next, what CSS files apply > to which pages, what methods are available on the controller, what > localization files exist for different pages, switch between locales to see > what things look like, show the layout for iPad vs. Desktop vs. whatever, > etc. > > I don't to tie scene builder to a specific app framework, unless that app > framework is part of the platform. Other things, like validation, I think > really wants to be part of the controls API as opposed to be completely > standalone. > Tool support would be improved with a well defined application framework, absolutely. But tool support doesn't require the app framework to be part of the core library. There are some awesome tools out there (IntelliJ and Eclipse without looking too far) that do amazing tool support around frameworks such as Struts, Spring, GWT, Maven, JUnit, Hibernate, Guice, Groovy, etc. These have all gained tooling support because they are popular, not because they are part of a JDK or the like. SceneBuilder is a bit of an enigma for most us still on this side of the fence. Various forum topics have eluded to what it might or might not be but I for one am not really sure. If it is just a tool for constructing scene graphs then it should be applicable for any application framework but won't have any of the cool features you mentioned. If it is intended to be a full RAD tool, which can give the features you outlined, then it is going to have to pick a particular architecture (and possibly a remoting framework, data store framework, transaction framework, logging framework, testing framework, depending on what we consider an 'application', which comes back to point #1). Products like Spring Roo, Ruby on Rails, Grails, etc, are examples of some RAD tools out there (though they tend to work off code files and not use 'Scene' drawing tools, which might be a clue to their success), as well as examples such as .NET's VisualStudio and I'm sure many others that do use scene builders. All of these force an architecture and at least constrain, if not dictate, the technologies and the features that you can use. I'd be leaning quite strongly towards SceneBuilder not being part of JFX directly but instead being a tool offering on the side of it. I'd also see merit in SceneBuilder being an API that tool builders (e.g. IntelliJ, Eclipse) could use to add scene construction stuff to their existing tool suite, rather than a full RAD tool. IntelliJ for example would do a fine job of plugging in a SceneBuilder that was able to map back to class files, property files, etc - it has done all the hard work already, it just needs a WYSIWYG editor for FXML. On a related front, two other areas that in my mind probably would have been better off external to JFX are: - FXML: it is built on-top of JFX and so does not need to be part of the core. It also implies a certain MVC architecture, and as we've seen that's not ubiquitous (nor is the architecture style chosen particularly in-line with at least a sub-section of the community which is an example of the sorts of complications an Application framework creates) - Charts: seems like an add-on that will become something of a hassle for the JFX team to maintain, grow, support at the rate it will need, as well as adding complexity for mobile platforms (should a pie chart look the same on a mobile app with touch screen, no mouse over, etc). Just my opinion, but they are the sorts of things I'm thinking of when I'm talking about keeping the core as a core. > But you make really good arguments for being conservative in what goes > into the core. I think one of the things that made Swing so hard to learn, > was that it didn't provide any structure at all. > My personal take on this is that no one bothered building a nice application framework on top of Swing because there wasn't enough momentum behind the platform in the early days. Swing became an unloved technology because it was nasty (for the end user) to install/launch, and because the default look and feel was hideously ugly. Web apps, despite being a horrific programming model and much less powerful, took center stage because they looked good out of the box and ran instantly. Victory was that simple. If Swing had gained enough popularity for the Google guys to build the Google Swing Toolkit or for there to be a SpringSwingMVC framework, we'd be laughing write now - churning out amazing, rich, maintainable apps every day and life would be full of sunshine and rainbows. For me that's what I'd like to see happen with JFX, the core libraries focus on getting the core things really good (such as looking good, which it most certainly has achieved, and deployment, which it most certainly hasn't), This core then facilitates the construction of feature rich application frameworks to solve specific domain cases for it. What I'd really love to see instead of SceneBuilder is something more like Spring ROO that can rapidly knock up an initial UI, database, remoting layer, etc for me with 80% of the grunt work done magically, but allows me to write the remaining code in code. I love the idea that SceneBuilder will fill a need for a bunch of developers out there, but it is really for a sub-set only, much as Spring ROO FX would be for a different sub-set. > > The things I feel are needed for an application framework are the > features > > I am putting into JFX Flow , but this > is > > targeted towards web-style, online, form-based business apps. > > > > My feeling is that we are better off if JFX just provides a core library > > with fundamental building blocks, rather than trying to provide a full > > application framework that forces a specific architecture. People build > all > > sorts of applications, with all sorts of wonderful architectures, and no > > App framework can cater to all. For example, the application framework > > needed for an online, form-based business style app vs a desktop, offline > > app (e.g. an IDE or graphics drawing program) are significantly > different. > > I think you make a solid argument that there are different classes of > applications. The SceneBuilder itself, for example, wouldn't make any use > of a page-based application framework, neither would an IDE. Yet most apps > I've written would work very comfortably with a page-based framework -- and > those were all traditional desktop apps! A CAD program or 3D game would > again be some other application arch-type. > > But does that mean we shouldn't provide an API for the most common > application arch-type in the platform? Let's say we did manage to get a consensus that the application style to support is the page based one (probably upsetting the game programmers, animators, desktop tool builders, little flash-like applet builders, and creatives who just like to do things differently). I have some doubts that we'll then get any kind of consensus on what the best application *architecture *is to actually support this style. If you did a show of hands for support of just the various flavours of MVP (such as those outlined in my post), I reckon you'll get some vehement, devout, angry arguments both passionately for and passionately against each of the options. That's before you start looking at MVC, MVPC, etc, etc. Which one do we choose to support? Suppose we did so, but it was in a separate module, meaning you didn't have > to use it if you didn't want to? That'd help, but you still have the same challenges as above, especially the ones regarding choosing an architecture to support and not being able to use third party. The big question really is what are the advantages of putting into the core library? There are tangible drawbacks, what are the gains (apart from SceneBuilder support)? If it is just credibility and standardisation, we should be able to achieve that through a community consensus and group effort. Just my thoughts anyway. From tbee at tbee.org Thu Feb 9 21:54:39 2012 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 10 Feb 2012 06:54:39 +0100 Subject: The Next Great Thing: An Application Framework In-Reply-To: References: Message-ID: <4F34B11F.3020402@tbee.org> I agree with that Oracle's JFX team will want JFX to be self contained and thus not use existing libraries. And that will be a big drawback for any such library. Placing it outside the core JFX does not have to limit Oracle's JFX developers to assist in the development, does it? (Or will Oracle be making the "if we worked on it, it's ours" mistake (again)? (Hudson, open office) Because that usually backfires.) Tom On 2012-02-10 00:36, Daniel Zwolenski wrote: > The things I feel are needed for an application framework are the features > I am putting into JFX Flow, but this is > targeted towards web-style, online, form-based business apps. > > My feeling is that we are better off if JFX just provides a core library > with fundamental building blocks, rather than trying to provide a full > application framework that forces a specific architecture. People build all > sorts of applications, with all sorts of wonderful architectures, and no > App framework can cater to all. For example, the application framework > needed for an online, form-based business style app vs a desktop, offline > app (e.g. an IDE or graphics drawing program) are significantly different. > > For my money we are much better off keeping these application frameworks as > separate, open source, free, community managed projects. We can then have a > few key ones that cater to the major flavours of apps. This also decouples > the frameworks from the JFX release cycles, and allows them to make use of > other open source projects (such as Validation frameworks, Apache commons, > Spring, Guice, logging, remoting toolkits, etc), which the core JFX library > cannot do. > > This approach has worked well in web land. You have the official servlet > infrastructure as part of the core JEE library and then on top of this > people have built frameworks like SpringMVC, Struts, GWT, Seam, etc. People > can choose the framework that best solves their needs. As framework > builders have come up with new ways to do things, the servlet spec has > gradually, and carefully, evolved to support these things. The application > frameworks on the other hand have been totally rewritten, thrown away and > redone to account for new ways of doing things, new styles, new > understandings (e.g. Struts != Struts2, GWT2 is a major change from GWT1, > and HTML5 is a game changer for most of these frameworks). > > So in my mind there are two topics for discussion: > > 1. What are the flavours of applications that people will want to use JFX > to build, and what open source projects should we create to provide for > these and what features should they contain? Who's keen to do this work and > can we get a collaborative community effort going on this front (I'd be > more than happy to get more community involvement on Flow and if someone > has a better way of doing things, I'd also happily merge efforts). > > 2. Based on the discussions from #1 what are the core elements that JFX > needs to provide in order to support these frameworks and features? What > fundamental building blocks need to be fixed/improved or need to be added? > > I feel like a lot of the points you've raised in your email are > good contributions to the second topic, but there are a few that for me > should not be part of JFX and instead should be part of extension libraries: > > - Eventbus (there are a hundred different ways these can be implemented and > plenty of app architectures that don't use them) > - Application environment (not exactly sure what this means but it sounds > architecture specific?) > - Application controls (as above) > - Application naviagtion (as above) > - Automatic application state saves (there is generally a lot of business > logic associated with this, not JFX's domain in my opinion) > - Automatic document saves (as above only more so) > - Actions / Actions manager (these were not applicable in Swing for a MVP, > browser style architecture, they solve only a subset of architectural > problems, e.g. undo when using remoting) > - A superpowered decendant of the Swing AbstractAction class& > Action interface (as above). > - Conditional state actions (Ex. If the "control" key is depressed then > an alternate action is made visible or the text of a menu item might > change). - (as above) > - Toggle actions (Ex. bold/un-bold or hide/show) - (as above) > - Multi-state actions (as above) > - Inter-application communication (this is a Java issue, not a JFX issue. > It could be a JSR for inclusion in the Java platform or just a separate > library, it is not part of a GUI framework) > - Allow apps to communicate to each other using a common architecture (as > above) > > > I think also that a lot of the things people require (and hopefully most of > the things you listed), should already be in JIRA and if not, should be > added to JIRA. I do wonder how the JFX team choose the issues to be > fixed/worked on? I don't believe much notice is taken of the voting system, > perhaps it should be used more solidly, to allow the community to drive the > feature sets they see as important? It would be great if there was a bit of > love put into the JIRA setup to define some filters for the following: > > 1. Listing issues in order of votes (highest to lowest) > 2. Listing issues for the next releases/milestones > > It would be really great if actual dates were put into JIRA for > release/milestones so we could see a roadmap of what's being done when and > when releases are due. It is not obvious to me (and I am fairly active in > the whole thing) which releases are happening when, what features are in > which - all I really know is 'lombard' means 'not any time soon mate' and > everything else could happen sometime in the next year or two. It's all a > bit confusing and vague. > > One final comment, the absolute fundamental issue that affects all > platforms and for me is of such critical importance (it is the weakness > that hamstrung Swing), is the whole deployment issue. This needs to be > clean, smooth, simple. I can't emphasize this one enough. I feel like we're > going to lose the battle to HTML5 if we don't address this issue up front > and quickly (like in the next couple of months). I don't want JFX to spend > the next 10 years playing second fiddle to crappy web-apps, like Swing has > had to. Please don't make me write more JavaScript. > > > > On Thu, Feb 9, 2012 at 3:36 PM, Jeff McDonaldwrote: > >> Now that JavaFX is delivering on it's promise of delivering the components >> and pieces need to make an application, it's a perfect time to take a >> higher level look at what's needed to make a complete application. >> >> Here is your chance to add your ideas, comments, criticisms, insights,etc, >> and say what's on your mind. I don't work for Oracle nor do I speak for >> Oracle, however, the JavaFX team has shown great interest in listening to >> developers and delivering what's important to the developer community. >> Having an application frameworks integrated into the JavaFX library would >> be a huge advantage to Java developers. >> >> Below is a simple bullet list of ideas and features that could be useful to >> application developers: >> >> - Application types to consider: >> - Desktop >> - Tablet >> - Phone >> - Command line >> - TV >> - Set-top box / Bluray player >> - Service or daemon >> >> - Application tooling needs? >> >> - Application level / lifecycle events >> - Exit event (From JSR 296) >> - Shutdown event (From JSR 296) >> - Sleep event >> - Pause event >> - Show help window event >> - Show help hints (ala Apple style help) >> - Eventbus: allow any component to send message and listen to messages from >> any other component. Message consumers only have to listen to events and >> are not required to have references to any other objects (other than the >> eventbus) in order to receive event notices. >> - Screen resolution change event >> - Monitor added / removed events >> - Screen orientation change event >> - Full screen mode / normal screen mode. >> - App dock icon menu event / taskbar menu event / start menu event. >> - Application environment >> - Supports 3D? >> - Supports hardware acceleration? >> - LCD text supported? >> - Bidi text supported? >> - Supports full screen mode >> - Supports App menubar? >> - Supports dock? >> - Supports taskbar? >> - Application controls >> - App menubar (setter& getter) (The application level is really where the >> Application menubar should be handled, and not on the Stage/Window level.) >> - App taskbar >> - App dock >> - Set application name (This is app name, not stage or window name. >> Could be set to display Scene name when focus changes or to show static >> text.) >> - App dock icon menu / taskbar menu / start menu. >> >> - Application naviagtion >> - Get window (by id) >> - Bring window to front >> - Send window to back >> - Move window to location >> - Expose for FX stages to aid in navigating and organizing multiple windows >> (MacOS style functionality see: YouTube : MacOS X Expose >> Video >> ) >> - Application focus >> - Get current focused window >> - Get current focused component >> - Application state / session management >> - Save& restore window size& location >> - Automatic application state saves >> - Automatic document saves. >> - Actions / Actions manager >> - A superpowered decendant of the Swing AbstractAction class& Action >> interface. >> - Conditional state actions (Ex. If the "control" key is depressed then an >> alternate action is made visible or the text of a menu item might change). >> - Toggle actions (Ex. bold/un-bold or hide/show) >> - Multi-state actions >> - Application print support? >> >> - Inter-application communication >> - Allow apps to communicate to each other using a common architecture. >> From tbee at tbee.org Thu Feb 9 21:54:47 2012 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 10 Feb 2012 06:54:47 +0100 Subject: The Next Great Thing: An Application Framework In-Reply-To: References: Message-ID: <4F34B127.4010500@tbee.org> I agree with that Oracle's JFX team will want JFX to be self contained and thus not use existing libraries. And that will be a big drawback for any such library. Placing it outside the core JFX does not have to limit Oracle's JFX developers to assist in the development, does it? Tom On 2012-02-10 00:36, Daniel Zwolenski wrote: > The things I feel are needed for an application framework are the features > I am putting into JFX Flow, but this is > targeted towards web-style, online, form-based business apps. > > My feeling is that we are better off if JFX just provides a core library > with fundamental building blocks, rather than trying to provide a full > application framework that forces a specific architecture. People build all > sorts of applications, with all sorts of wonderful architectures, and no > App framework can cater to all. For example, the application framework > needed for an online, form-based business style app vs a desktop, offline > app (e.g. an IDE or graphics drawing program) are significantly different. > > For my money we are much better off keeping these application frameworks as > separate, open source, free, community managed projects. We can then have a > few key ones that cater to the major flavours of apps. This also decouples > the frameworks from the JFX release cycles, and allows them to make use of > other open source projects (such as Validation frameworks, Apache commons, > Spring, Guice, logging, remoting toolkits, etc), which the core JFX library > cannot do. > > This approach has worked well in web land. You have the official servlet > infrastructure as part of the core JEE library and then on top of this > people have built frameworks like SpringMVC, Struts, GWT, Seam, etc. People > can choose the framework that best solves their needs. As framework > builders have come up with new ways to do things, the servlet spec has > gradually, and carefully, evolved to support these things. The application > frameworks on the other hand have been totally rewritten, thrown away and > redone to account for new ways of doing things, new styles, new > understandings (e.g. Struts != Struts2, GWT2 is a major change from GWT1, > and HTML5 is a game changer for most of these frameworks). > > So in my mind there are two topics for discussion: > > 1. What are the flavours of applications that people will want to use JFX > to build, and what open source projects should we create to provide for > these and what features should they contain? Who's keen to do this work and > can we get a collaborative community effort going on this front (I'd be > more than happy to get more community involvement on Flow and if someone > has a better way of doing things, I'd also happily merge efforts). > > 2. Based on the discussions from #1 what are the core elements that JFX > needs to provide in order to support these frameworks and features? What > fundamental building blocks need to be fixed/improved or need to be added? > > I feel like a lot of the points you've raised in your email are > good contributions to the second topic, but there are a few that for me > should not be part of JFX and instead should be part of extension libraries: > > - Eventbus (there are a hundred different ways these can be implemented and > plenty of app architectures that don't use them) > - Application environment (not exactly sure what this means but it sounds > architecture specific?) > - Application controls (as above) > - Application naviagtion (as above) > - Automatic application state saves (there is generally a lot of business > logic associated with this, not JFX's domain in my opinion) > - Automatic document saves (as above only more so) > - Actions / Actions manager (these were not applicable in Swing for a MVP, > browser style architecture, they solve only a subset of architectural > problems, e.g. undo when using remoting) > - A superpowered decendant of the Swing AbstractAction class& > Action interface (as above). > - Conditional state actions (Ex. If the "control" key is depressed then > an alternate action is made visible or the text of a menu item might > change). - (as above) > - Toggle actions (Ex. bold/un-bold or hide/show) - (as above) > - Multi-state actions (as above) > - Inter-application communication (this is a Java issue, not a JFX issue. > It could be a JSR for inclusion in the Java platform or just a separate > library, it is not part of a GUI framework) > - Allow apps to communicate to each other using a common architecture (as > above) > > > I think also that a lot of the things people require (and hopefully most of > the things you listed), should already be in JIRA and if not, should be > added to JIRA. I do wonder how the JFX team choose the issues to be > fixed/worked on? I don't believe much notice is taken of the voting system, > perhaps it should be used more solidly, to allow the community to drive the > feature sets they see as important? It would be great if there was a bit of > love put into the JIRA setup to define some filters for the following: > > 1. Listing issues in order of votes (highest to lowest) > 2. Listing issues for the next releases/milestones > > It would be really great if actual dates were put into JIRA for > release/milestones so we could see a roadmap of what's being done when and > when releases are due. It is not obvious to me (and I am fairly active in > the whole thing) which releases are happening when, what features are in > which - all I really know is 'lombard' means 'not any time soon mate' and > everything else could happen sometime in the next year or two. It's all a > bit confusing and vague. > > One final comment, the absolute fundamental issue that affects all > platforms and for me is of such critical importance (it is the weakness > that hamstrung Swing), is the whole deployment issue. This needs to be > clean, smooth, simple. I can't emphasize this one enough. I feel like we're > going to lose the battle to HTML5 if we don't address this issue up front > and quickly (like in the next couple of months). I don't want JFX to spend > the next 10 years playing second fiddle to crappy web-apps, like Swing has > had to. Please don't make me write more JavaScript. > > > > On Thu, Feb 9, 2012 at 3:36 PM, Jeff McDonaldwrote: > >> Now that JavaFX is delivering on it's promise of delivering the components >> and pieces need to make an application, it's a perfect time to take a >> higher level look at what's needed to make a complete application. >> >> Here is your chance to add your ideas, comments, criticisms, insights,etc, >> and say what's on your mind. I don't work for Oracle nor do I speak for >> Oracle, however, the JavaFX team has shown great interest in listening to >> developers and delivering what's important to the developer community. >> Having an application frameworks integrated into the JavaFX library would >> be a huge advantage to Java developers. >> >> Below is a simple bullet list of ideas and features that could be useful to >> application developers: >> >> - Application types to consider: >> - Desktop >> - Tablet >> - Phone >> - Command line >> - TV >> - Set-top box / Bluray player >> - Service or daemon >> >> - Application tooling needs? >> >> - Application level / lifecycle events >> - Exit event (From JSR 296) >> - Shutdown event (From JSR 296) >> - Sleep event >> - Pause event >> - Show help window event >> - Show help hints (ala Apple style help) >> - Eventbus: allow any component to send message and listen to messages from >> any other component. Message consumers only have to listen to events and >> are not required to have references to any other objects (other than the >> eventbus) in order to receive event notices. >> - Screen resolution change event >> - Monitor added / removed events >> - Screen orientation change event >> - Full screen mode / normal screen mode. >> - App dock icon menu event / taskbar menu event / start menu event. >> - Application environment >> - Supports 3D? >> - Supports hardware acceleration? >> - LCD text supported? >> - Bidi text supported? >> - Supports full screen mode >> - Supports App menubar? >> - Supports dock? >> - Supports taskbar? >> - Application controls >> - App menubar (setter& getter) (The application level is really where the >> Application menubar should be handled, and not on the Stage/Window level.) >> - App taskbar >> - App dock >> - Set application name (This is app name, not stage or window name. >> Could be set to display Scene name when focus changes or to show static >> text.) >> - App dock icon menu / taskbar menu / start menu. >> >> - Application naviagtion >> - Get window (by id) >> - Bring window to front >> - Send window to back >> - Move window to location >> - Expose for FX stages to aid in navigating and organizing multiple windows >> (MacOS style functionality see: YouTube : MacOS X Expose >> Video >> ) >> - Application focus >> - Get current focused window >> - Get current focused component >> - Application state / session management >> - Save& restore window size& location >> - Automatic application state saves >> - Automatic document saves. >> - Actions / Actions manager >> - A superpowered decendant of the Swing AbstractAction class& Action >> interface. >> - Conditional state actions (Ex. If the "control" key is depressed then an >> alternate action is made visible or the text of a menu item might change). >> - Toggle actions (Ex. bold/un-bold or hide/show) >> - Multi-state actions >> - Application print support? >> >> - Inter-application communication >> - Allow apps to communicate to each other using a common architecture. >> From webczat_200 at poczta.onet.pl Fri Feb 10 06:42:36 2012 From: webczat_200 at poczta.onet.pl (=?UTF-8?B?TWljaGHFgiBaZWdhbg==?=) Date: Fri, 10 Feb 2012 15:42:36 +0100 Subject: The Next Great Thing: An Application Framework In-Reply-To: References: <67E68928-E012-4167-80E4-7A7CD303D073@oracle.com> Message-ID: <4F352CDC.1060601@poczta.onet.pl> javax.print.* apis do not depend on the java awt except the renderable image doc flavor and similar, unless I'm wrong. I am not sure if it may be possible to create new doc flavors but it may suffice. I would personally benefit from the framework placed in the jfx, it won't be so hard to choose an appropriate one. From richard.bair at oracle.com Fri Feb 10 10:39:18 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 10 Feb 2012 10:39:18 -0800 Subject: Charts: Was The Next Great Thing: An Application Framework In-Reply-To: References: <67E68928-E012-4167-80E4-7A7CD303D073@oracle.com> Message-ID: <9B0BA313-9396-4662-A372-B1774003E865@oracle.com> > - Charts: seems like an add-on that will become something of a hassle for the JFX team to maintain, grow, support at the rate it will need, as well as adding complexity for mobile platforms (should a pie chart look the same on a mobile app with touch screen, no mouse over, etc). Different topic, but I thought this comment was interesting. Why are charts any different than controls? We see them as the same thing really. Charts are extensible -- folks can add new charts, or use the built in ones, exactly like controls. Both are intended to be drop-in use for applications. Charts are actually much more powerful than we've gotten credit for so far (I suspect this is because nobody has dug into them deeply and we've not documented a lot of the capabilities on fxexperience or javafx.com yet). Richard From jeff at reportmill.com Fri Feb 10 11:44:19 2012 From: jeff at reportmill.com (Jeff Martin) Date: Fri, 10 Feb 2012 13:44:19 -0600 Subject: The Next Great Thing: An Application Framework In-Reply-To: References: <67E68928-E012-4167-80E4-7A7CD303D073@oracle.com> Message-ID: <7C9C7276-36F9-4725-B41C-F902479C064E@reportmill.com> I'm working on a consumer friendly IDE and application framework for Java and JavaFX that I hope people on this list will keep their eye on. It is intended to be comprehensive and mainstream, free and initially targeted at education. Kind of FileMaker meets Eclipse/NetBeans, with iTunes elegance and sensibility, and some InterfaceBuilder, InDesign, Flash Designer, Flash-Player/Acrobat-Reader, ORM, Crystal Reports and Cloud computing thrown in. It has a page based application player for desktop (JWS) and browser apps with page navigation, refresh and animated transitions (even the IDE is build on it), a Java source editor and rund/debug environment, a graphical UI, page and report builder (supporting JavaFX, Swing and Java2D - supporting vector graphics, animation, image effects, etc.), a graphical data table builder (with graphical data entry, data binding, an ORM system, a JSON remoting layer with adapters to save to Files, Google App Engine, JDBC and FTP), and remote repository synchronization to publish your app on the internet with 1 click. I'm a month or two shy of a preview, but all the primary features are there. I'm a little under resourced - Oracle doesn't have a venture investment arm, does it? :-) Jeff Martin Java Inventor Duke Award Winner, 2009 From richard.bair at oracle.com Fri Feb 10 11:46:06 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 10 Feb 2012 11:46:06 -0800 Subject: The Next Great Thing: An Application Framework In-Reply-To: <7C9C7276-36F9-4725-B41C-F902479C064E@reportmill.com> References: <67E68928-E012-4167-80E4-7A7CD303D073@oracle.com> <7C9C7276-36F9-4725-B41C-F902479C064E@reportmill.com> Message-ID: When you post some code we'll definitely be giving it a look :-) On Feb 10, 2012, at 11:44 AM, Jeff Martin wrote: > I'm working on a consumer friendly IDE and application framework for Java and JavaFX that I hope people on this list will keep their eye on. It is intended to be comprehensive and mainstream, free and initially targeted at education. Kind of FileMaker meets Eclipse/NetBeans, with iTunes elegance and sensibility, and some InterfaceBuilder, InDesign, Flash Designer, Flash-Player/Acrobat-Reader, ORM, Crystal Reports and Cloud computing thrown in. > > It has a page based application player for desktop (JWS) and browser apps with page navigation, refresh and animated transitions (even the IDE is build on it), a Java source editor and rund/debug environment, a graphical UI, page and report builder (supporting JavaFX, Swing and Java2D - supporting vector graphics, animation, image effects, etc.), a graphical data table builder (with graphical data entry, data binding, an ORM system, a JSON remoting layer with adapters to save to Files, Google App Engine, JDBC and FTP), and remote repository synchronization to publish your app on the internet with 1 click. > > I'm a month or two shy of a preview, but all the primary features are there. I'm a little under resourced - Oracle doesn't have a venture investment arm, does it? :-) > > Jeff Martin > > > Java Inventor > > Duke Award Winner, 2009 From jeff at reportmill.com Fri Feb 10 12:06:17 2012 From: jeff at reportmill.com (Jeff Martin) Date: Fri, 10 Feb 2012 14:06:17 -0600 Subject: The Next Great Thing: An Application Framework In-Reply-To: References: <67E68928-E012-4167-80E4-7A7CD303D073@oracle.com> <7C9C7276-36F9-4725-B41C-F902479C064E@reportmill.com> Message-ID: <044CCCF7-C5A0-4FD5-AD12-1E0EE3504F44@reportmill.com> I do hope to make it "Source Available" via a project you can check out from Java Inventor. Though, like Oracle, I need to get corporate customers to fund development in some manner, so I need to figure out how to do it while protecting it. One of the cute features of Java Inventor is that with just a hyperlink you can launch Javi via JWS opened to a local copy of any published app, which offers a lot of possibilities for code sharing, collaboration and support. Javi is currently less than 2mb, packed. jeff On Feb 10, 2012, at 1:46 PM, Richard Bair wrote: > When you post some code we'll definitely be giving it a look :-) > > On Feb 10, 2012, at 11:44 AM, Jeff Martin wrote: > >> I'm working on a consumer friendly IDE and application framework for Java and JavaFX that I hope people on this list will keep their eye on. It is intended to be comprehensive and mainstream, free and initially targeted at education. Kind of FileMaker meets Eclipse/NetBeans, with iTunes elegance and sensibility, and some InterfaceBuilder, InDesign, Flash Designer, Flash-Player/Acrobat-Reader, ORM, Crystal Reports and Cloud computing thrown in. >> >> It has a page based application player for desktop (JWS) and browser apps with page navigation, refresh and animated transitions (even the IDE is build on it), a Java source editor and rund/debug environment, a graphical UI, page and report builder (supporting JavaFX, Swing and Java2D - supporting vector graphics, animation, image effects, etc.), a graphical data table builder (with graphical data entry, data binding, an ORM system, a JSON remoting layer with adapters to save to Files, Google App Engine, JDBC and FTP), and remote repository synchronization to publish your app on the internet with 1 click. >> >> I'm a month or two shy of a preview, but all the primary features are there. I'm a little under resourced - Oracle doesn't have a venture investment arm, does it? :-) >> >> Jeff Martin >> >> >> Java Inventor >> >> Duke Award Winner, 2009 > From richard.bair at oracle.com Fri Feb 10 12:34:39 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 10 Feb 2012 12:34:39 -0800 Subject: The Next Great Thing: An Application Framework In-Reply-To: References: Message-ID: > I think also that a lot of the things people require (and hopefully most of > the things you listed), should already be in JIRA and if not, should be > added to JIRA. I do wonder how the JFX team choose the issues to be > fixed/worked on? I don't believe much notice is taken of the voting system, > perhaps it should be used more solidly, to allow the community to drive the > feature sets they see as important? It would be great if there was a bit of > love put into the JIRA setup to define some filters for the following: > > 1. Listing issues in order of votes (highest to lowest) > 2. Listing issues for the next releases/milestones As far as #1 goes, if you have a JIRA login can you create your own filters? If so you could also share them with everyone. It would be easy enough for me to then add this as part of the OpenJFX 2.1 Dashboard. Richard From sven.reimers at gmail.com Fri Feb 10 12:49:29 2012 From: sven.reimers at gmail.com (Sven Reimers) Date: Fri, 10 Feb 2012 21:49:29 +0100 Subject: Charts: Was The Next Great Thing: An Application Framework In-Reply-To: <9B0BA313-9396-4662-A372-B1774003E865@oracle.com> References: <67E68928-E012-4167-80E4-7A7CD303D073@oracle.com> <9B0BA313-9396-4662-A372-B1774003E865@oracle.com> Message-ID: There are some ideas sitzung in Jira that would be good for msking Charts even more successful, e.g. logarithmic axis and multiple y-axis.. Hope OpenJFX will be the place to make those things happen. Sven Am 10.02.2012 19:39 schrieb "Richard Bair" : > > > - Charts: seems like an add-on that will become something of a hassle > for the JFX team to maintain, grow, support at the rate it will need, as > well as adding complexity for mobile platforms (should a pie chart look the > same on a mobile app with touch screen, no mouse over, etc). > > Different topic, but I thought this comment was interesting. Why are > charts any different than controls? We see them as the same thing really. > Charts are extensible -- folks can add new charts, or use the built in > ones, exactly like controls. Both are intended to be drop-in use for > applications. Charts are actually much more powerful than we've gotten > credit for so far (I suspect this is because nobody has dug into them > deeply and we've not documented a lot of the capabilities on fxexperience > or javafx.com yet). > > Richard From richard.bair at oracle.com Fri Feb 10 12:49:31 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 10 Feb 2012 12:49:31 -0800 Subject: The Next Great Thing: An Application Framework In-Reply-To: References: <67E68928-E012-4167-80E4-7A7CD303D073@oracle.com> Message-ID: <89C9D991-1100-445E-A4E3-51A0857175C0@oracle.com> A couple days ago I would have said "Oh ya, we're absolutely doing an app framework". But I tend to agree with your reasoning here. Except for one thing, which is that experienced developers definitely love having many different frameworks and choices, whereas less experienced (or maybe just those who aren't so bothered and just want to get on with it) definitely prefer something being available out of the box. However I think you make a very persuasive point that at this time there are app frameworks either released (yours) or in development (Jeff Martin's) and undoubtedly there will be more, and that perhaps we ought to spend our energy at Oracle in solving the part of the problem that only we can solve -- deployment and basic app lifecycle (such as is required to wire it all up to the native OS app lifecycle stuff). Richard On Feb 9, 2012, at 5:30 PM, Daniel Zwolenski wrote: > On Fri, Feb 10, 2012 at 10:15 AM, Richard Bair wrote: > On the other hand, the more structured the application framework, the better tool support you can get. For example, if SceneBuilder had enough structure, it could show all the different pages in your application, indicate which actions move from one page to the next, what CSS files apply to which pages, what methods are available on the controller, what localization files exist for different pages, switch between locales to see what things look like, show the layout for iPad vs. Desktop vs. whatever, etc. > > I don't to tie scene builder to a specific app framework, unless that app framework is part of the platform. Other things, like validation, I think really wants to be part of the controls API as opposed to be completely standalone. > > Tool support would be improved with a well defined application framework, absolutely. But tool support doesn't require the app framework to be part of the core library. There are some awesome tools out there (IntelliJ and Eclipse without looking too far) that do amazing tool support around frameworks such as Struts, Spring, GWT, Maven, JUnit, Hibernate, Guice, Groovy, etc. These have all gained tooling support because they are popular, not because they are part of a JDK or the like. > > SceneBuilder is a bit of an enigma for most us still on this side of the fence. Various forum topics have eluded to what it might or might not be but I for one am not really sure. If it is just a tool for constructing scene graphs then it should be applicable for any application framework but won't have any of the cool features you mentioned. > > If it is intended to be a full RAD tool, which can give the features you outlined, then it is going to have to pick a particular architecture (and possibly a remoting framework, data store framework, transaction framework, logging framework, testing framework, depending on what we consider an 'application', which comes back to point #1). Products like Spring Roo, Ruby on Rails, Grails, etc, are examples of some RAD tools out there (though they tend to work off code files and not use 'Scene' drawing tools, which might be a clue to their success), as well as examples such as .NET's VisualStudio and I'm sure many others that do use scene builders. All of these force an architecture and at least constrain, if not dictate, the technologies and the features that you can use. > > I'd be leaning quite strongly towards SceneBuilder not being part of JFX directly but instead being a tool offering on the side of it. I'd also see merit in SceneBuilder being an API that tool builders (e.g. IntelliJ, Eclipse) could use to add scene construction stuff to their existing tool suite, rather than a full RAD tool. IntelliJ for example would do a fine job of plugging in a SceneBuilder that was able to map back to class files, property files, etc - it has done all the hard work already, it just needs a WYSIWYG editor for FXML. > > On a related front, two other areas that in my mind probably would have been better off external to JFX are: > > - FXML: it is built on-top of JFX and so does not need to be part of the core. It also implies a certain MVC architecture, and as we've seen that's not ubiquitous (nor is the architecture style chosen particularly in-line with at least a sub-section of the community which is an example of the sorts of complications an Application framework creates) > > - Charts: seems like an add-on that will become something of a hassle for the JFX team to maintain, grow, support at the rate it will need, as well as adding complexity for mobile platforms (should a pie chart look the same on a mobile app with touch screen, no mouse over, etc). > > Just my opinion, but they are the sorts of things I'm thinking of when I'm talking about keeping the core as a core. > > > But you make really good arguments for being conservative in what goes into the core. I think one of the things that made Swing so hard to learn, was that it didn't provide any structure at all. > > My personal take on this is that no one bothered building a nice application framework on top of Swing because there wasn't enough momentum behind the platform in the early days. Swing became an unloved technology because it was nasty (for the end user) to install/launch, and because the default look and feel was hideously ugly. Web apps, despite being a horrific programming model and much less powerful, took center stage because they looked good out of the box and ran instantly. Victory was that simple. > > If Swing had gained enough popularity for the Google guys to build the Google Swing Toolkit or for there to be a SpringSwingMVC framework, we'd be laughing write now - churning out amazing, rich, maintainable apps every day and life would be full of sunshine and rainbows. > > For me that's what I'd like to see happen with JFX, the core libraries focus on getting the core things really good (such as looking good, which it most certainly has achieved, and deployment, which it most certainly hasn't), This core then facilitates the construction of feature rich application frameworks to solve specific domain cases for it. > > What I'd really love to see instead of SceneBuilder is something more like Spring ROO that can rapidly knock up an initial UI, database, remoting layer, etc for me with 80% of the grunt work done magically, but allows me to write the remaining code in code. I love the idea that SceneBuilder will fill a need for a bunch of developers out there, but it is really for a sub-set only, much as Spring ROO FX would be for a different sub-set. > > > > The things I feel are needed for an application framework are the features > > I am putting into JFX Flow , but this is > > targeted towards web-style, online, form-based business apps. > > > > My feeling is that we are better off if JFX just provides a core library > > with fundamental building blocks, rather than trying to provide a full > > application framework that forces a specific architecture. People build all > > sorts of applications, with all sorts of wonderful architectures, and no > > App framework can cater to all. For example, the application framework > > needed for an online, form-based business style app vs a desktop, offline > > app (e.g. an IDE or graphics drawing program) are significantly different. > > I think you make a solid argument that there are different classes of applications. The SceneBuilder itself, for example, wouldn't make any use of a page-based application framework, neither would an IDE. Yet most apps I've written would work very comfortably with a page-based framework -- and those were all traditional desktop apps! A CAD program or 3D game would again be some other application arch-type. > > But does that mean we shouldn't provide an API for the most common application arch-type in the platform? > > Let's say we did manage to get a consensus that the application style to support is the page based one (probably upsetting the game programmers, animators, desktop tool builders, little flash-like applet builders, and creatives who just like to do things differently). I have some doubts that we'll then get any kind of consensus on what the best application architecture is to actually support this style. If you did a show of hands for support of just the various flavours of MVP (such as those outlined in my post), I reckon you'll get some vehement, devout, angry arguments both passionately for and passionately against each of the options. That's before you start looking at MVC, MVPC, etc, etc. Which one do we choose to support? > > Suppose we did so, but it was in a separate module, meaning you didn't have to use it if you didn't want to? > > That'd help, but you still have the same challenges as above, especially the ones regarding choosing an architecture to support and not being able to use third party. > > The big question really is what are the advantages of putting into the core library? There are tangible drawbacks, what are the gains (apart from SceneBuilder support)? If it is just credibility and standardisation, we should be able to achieve that through a community consensus and group effort. > > Just my thoughts anyway. > From sven.reimers at gmail.com Fri Feb 10 13:00:47 2012 From: sven.reimers at gmail.com (Sven Reimers) Date: Fri, 10 Feb 2012 22:00:47 +0100 Subject: The Next Great Thing: An Application Framework Message-ID: Seems there is more than one approach out there for getting a JavaFX RCP in shape. As a die hard NetBeans RCP user I started an open source java.netproject called efx, which tries to reuse a lot of the NetBeans RCP pattern while getting rid of the Swing UI. So the focus is more on RCP not on an IDE or something similiar, but with first class support for development of such RCP based applications.. Sven Am 10.02.2012 21:35 schrieb "Richard Bair" : From tom.schindl at bestsolution.at Fri Feb 10 14:55:48 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 10 Feb 2012 23:55:48 +0100 Subject: The Next Great Thing: An Application Framework In-Reply-To: References: Message-ID: <4F35A074.6040601@bestsolution.at> In my thinking is an IDE is simply a large large RCP-Application? In this sense like you as an die hard Eclipse users I've started developing an RCP framework built on top if Eclipse 4 Application Platform which provides the completely new runtime layer the Eclipse 4.x IDE is built upon. The key things are: * extensibility by using OSGi * event bus built on OSGi Event Admin * service architectur built on OSGi * theming via CSS * programming model based upon JSR 330 (javax.inject) * DOM like Application Model providing clean seperation between application state and rendered UI * commands/handler framework Kai T?dter is also doing work in this area (he also builds on the Eclipse 4 Application Platform) and has published nice screenshots of applications [1]. I'm currently working on a demo application which we'll demonstrate at Eclipse Con North America in March showing how a collabrative application can be built using the Eclipse 4 Application Platform and JavaFX (because it's at EclipseCon we'll even mix SWT into the game but that's a minor thing) [2]. Coming back to my above assumption that an IDE is nothing more than a big RCP application - the RCP the framework built by us - can easily be expanded to an IDE e.g. by mixin in other Eclipse technologies like e.g. JDT-Core, Xtext for DSLs, ... . I think the important thing for efx and the e(fx)clipse runtime platforms is that they build upon hardened frameworks because other big products (Netbeans and Eclipse) are built upon them. This makes those 2 frameworks share resources with others (e.g. e(fx)clipse runtime platform currently has around 20 classes and supports all important UI paradigms starting from menus to toolbars to tabs) while inheriting all other features from the framework developed at Eclipse. BTW if you are not happy with the UI-Paradigms currently defined in the Eclipse 4 Application Platform you are able to expand and mix in your owns. All our sources are provided under EPL [3]. Tom [1] http://www.toedter.com/blog/?p=709 [2] http://www.eclipsecon.org/2012/sessions/eclipse-4-meets-cdo-now-you-see-it-and-so-do-they [3] http://github.com/tomsontom/e-fx-clipse Am 10.02.12 22:00, schrieb Sven Reimers: > Seems there is more than one approach out there for getting a JavaFX RCP in > shape. As a die hard NetBeans RCP user I started an open source > java.netproject called efx, which tries to reuse a lot of the NetBeans > RCP pattern > while getting rid of the Swing UI. > > So the focus is more on RCP not on an IDE or something similiar, but with > first class support for development of such RCP based applications.. > > Sven > Am 10.02.2012 21:35 schrieb "Richard Bair" : -- 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 zonski at googlemail.com Sat Feb 11 21:59:06 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Sun, 12 Feb 2012 15:59:06 +1000 Subject: The Next Great Thing: An Application Framework In-Reply-To: <4F35A074.6040601@bestsolution.at> References: <4F35A074.6040601@bestsolution.at> Message-ID: I like all the thinking on this front and the different initiatives (and the enthusiasm). I think there is a lot of room for us to exchange ideas (and code!) and either make sure each of the platforms is doing something unique, or merge efforts if they are not. One of my fundamental goals however is to not tie a developer into a specific development toolset/environment as much as possible (as a developer I hate it when I can't use my tools, so I try to make it so everyone else can use their weapon of choice too), so the frameworks based around Eclipse (or any specific IDE) are unfortunately not of direct appeal to me. Having said that, I'd love to keep abreast of the features being added, how they are being implemented, architectural patterns and motivations, etc. Perhaps there is even room for a project like JFXtras to become a spot for us to put common toolkits that our frameworks can all share, rather than each of us reinventing wheels. If there is anything in JFX Flow that people would like to use in their toollkits, let me know and we'll see if we can section stuff off. Likewise I will look through your frameworks as much as time allows and see what overlaps (e.g. maybe we could all work on a form validation framework together that our application frameworks then share and add to, etc). Richard, on the topic of what the JFX platform should/shouldn't include, can I add another way of thinking into the mix for you to mull over: although there is a strong case for keeping the JFX platform as the 'core' library, just because other modules/elements are not part of the 'core' doesn't mean that Oracle can't produce them, sponsor them, contribute to them, etc. It would be great to see Oracle champion initiatives on each of the logical extension fronts (full app frameworks, game platforms, form/wizard frameworks, navigation/event-bus libraries, high-level animation libraries, PDF/doc browsing/editing, voice/video conferencing, etc). This approach would achieve the goal of getting all these needed value-add frameworks built in a consistent, 'official' way, but would remove the restrictions implied by a core framework (e.g. can't use 3rd party, tied to core release timeline, legal issues, etc). Also the cost to Oracle would be massively reduced, allowing them to achieve far more with limited resources. If Oracle is driving initiatives they can still keep their brand on it - Google uses a similar approach and it only adds to their brand and their platform (see http://code.google.com/). In some (few) cases this could be in the form of Oracle putting together it's own closed team (like the JFX team is now) on a project if Oracle feels that area is of critical importance/urgency to the JFX platform. My preference however would be for Oracle to instead either lead or support open source community efforts. Perhaps by providing a project lead for it and getting members of the community to sign up and join in (perhaps even sponsoring some community developers - like a 'key contributors' model or something). Alternatively (or as well) it would be awesome if Oracle had an internal, dedicated team of 'community supporters' who's full time job it is to assist community projects that Oracle sees as value add to the platform. This team would help guide/support projects that look to add value to the JFX platform, possibly by providing direct development resources, or otherwise by providing publicity, official 'sanctioning', infrastructure/hosting support, and communication links to funnel requests back to the JFX team for core support/enhancements, etc. Additionally this team could also help identify duplicate efforts and try and foster/guide collaboration and effort-merging to limit the number of similar initiatives (for us garage developers working out how to collaborate is a lot harder than it sounds, and having a trusted third-party assist with this would be useful). In a better world, the java.net developers site would be the ideal infrastructure for these sorts of projects, but unfortunately (in my opinion at least) it is a dog's breakfast of a system with a horribly unusable UI, outdated/limited features and poor performance. I've tried to use it in the past and found it too painful and ended up switching to google code. If some energy were to be expended on making java.net more like a modern day collaboration suite (the Atlassian toolset for example) then this could be the perfect platform for this sort of community effort, all to the mutual benefit of Oracle and the JavaFX community as a whole. Win-win. For what it's worth, I would volunteer what spare time I could find to work with guys on your end to make something like this a reality. On Sat, Feb 11, 2012 at 8:55 AM, Tom Schindl wrote: > In my thinking is an IDE is simply a large large RCP-Application? > > In this sense like you as an die hard Eclipse users I've started > developing an RCP framework built on top if Eclipse 4 Application > Platform which provides the completely new runtime layer the Eclipse 4.x > IDE is built upon. > > The key things are: > * extensibility by using OSGi > * event bus built on OSGi Event Admin > * service architectur built on OSGi > * theming via CSS > * programming model based upon JSR 330 (javax.inject) > * DOM like Application Model providing clean seperation between > application state and rendered UI > * commands/handler framework > > Kai T?dter is also doing work in this area (he also builds on the > Eclipse 4 Application Platform) and has published nice screenshots of > applications [1]. > > I'm currently working on a demo application which we'll demonstrate at > Eclipse Con North America in March showing how a collabrative > application can be built using the Eclipse 4 Application Platform and > JavaFX (because it's at EclipseCon we'll even mix SWT into the game but > that's a minor thing) [2]. > > Coming back to my above assumption that an IDE is nothing more than a > big RCP application - the RCP the framework built by us - can easily be > expanded to an IDE e.g. by mixin in other Eclipse technologies like e.g. > JDT-Core, Xtext for DSLs, ... . > > I think the important thing for efx and the e(fx)clipse runtime > platforms is that they build upon hardened frameworks because other big > products (Netbeans and Eclipse) are built upon them. > > This makes those 2 frameworks share resources with others (e.g. > e(fx)clipse runtime platform currently has around 20 classes and > supports all important UI paradigms starting from menus to toolbars to > tabs) while inheriting all other features from the framework developed > at Eclipse. > > BTW if you are not happy with the UI-Paradigms currently defined in the > Eclipse 4 Application Platform you are able to expand and mix in your owns. > > All our sources are provided under EPL [3]. > > Tom > > [1] http://www.toedter.com/blog/?p=709 > [2] > > http://www.eclipsecon.org/2012/sessions/eclipse-4-meets-cdo-now-you-see-it-and-so-do-they > [3] http://github.com/tomsontom/e-fx-clipse > > Am 10.02.12 22:00, schrieb Sven Reimers: > > Seems there is more than one approach out there for getting a JavaFX RCP > in > > shape. As a die hard NetBeans RCP user I started an open source > > java.netproject called efx, which tries to reuse a lot of the NetBeans > > RCP pattern > > while getting rid of the Swing UI. > > > > So the focus is more on RCP not on an IDE or something similiar, but with > > first class support for development of such RCP based applications.. > > > > Sven > > Am 10.02.2012 21:35 schrieb "Richard Bair" : > > > -- > 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 zonski at googlemail.com Sat Feb 11 22:38:00 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Sun, 12 Feb 2012 16:38:00 +1000 Subject: Charts: Was The Next Great Thing: An Application Framework In-Reply-To: References: <67E68928-E012-4167-80E4-7A7CD303D073@oracle.com> <9B0BA313-9396-4662-A372-B1774003E865@oracle.com> Message-ID: Hi Richard, It's not that I don't like having charts available when I want them and although I haven't looked at them in depth yet, it looks like it is a very powerful toolkit. It's just that I feel only a sub-set of applications (specifically business/data apps) will actually use charts, whereas things like buttons, labels, textfields are fairly ubiquitous building blocks for everything. Charts feel more like a higher-level feature to me, on par with things like 'mapping', file editing, PDF browsing, a 'game engine', or a statistics package, etc. It is definitely possible that I may not fully understand the chart API as yet though and my comments may be premature. I haven't had call to use them yet in my applications, perhaps when I do I will change my viewpoint. With that caveat in mind, the main drawbacks I see to charts being in the core platform are these: 1. Resourcing - I have a gut feel that building/maintaining something like this was and will be something of a hassle that will draw all-important JavaFX resources away from more fundamental features. The community would probably pick charts up if it was left out, so it feels like Oracle is blowing 'coin' I'd rather see spent on stuff that can't (easily) be done by the community because it is more 'core' (like video playback, true 3D support, mobile phone support, etc). If Oracle's got resources to burn on this then this is not such an issue, but I'd personally rather get a media capture API, or a mobile version in there over charts, because charts I can build myself, whereas media capture and/or mobile requires nasty native libraries and weird non-java magic. 2. Bloat - it's good to keep the base platform as small and light as possible so when we look at supporting platforms (like mobile, set top boxes, etc) we only have to move the core features on to these and not be moving a massive codebase across (and also downloading a massive jar). It's easier to keep the platform stable too, less code means less bugs. If we didn't have charts when we go 'mobile' then the move would be easier (i.e. catering for touch screens, smaller screens, etc). Modularisation may help with this, but I think the additional code in the core platform will still result in more work. 3. Change management - my gut feel is something like charts will have a more rapid change/fix cycle than the core platform. I don't particularly want my end user to have to download a new JFX RT every other week (especially if there are more annoying popups) because there has been a fix in the way 'ticks' are rendered on a chart if I'm not using charts (whereas HBox probably isn't going to change too often). Again maybe modularisation will help with this, but it is still a way off and the deployment battle may well be fought and lost before Java8 gets on it's horse and makes a charge. As per my previous email, all of the above is not to say I wouldn't love to see a separate ChartsFX library published by Oracle that had the exact features in the core jfx charts module at the moment (deployed into Maven would be even better :) ). As always, I'm definitely not putting down any of the effort put in by the JFX team. I'm an unashamed platform zealot and a fan. JFX is the development environment I've been dreaming about for years and I love it. I'm more concerned about providing (hopefully) constructive feedback on making it better and making sure the platform is sustainable so it can become the standard and every new job I look at uses it. As we get stuck into nutting out features and working through problems, it's easy to forget to say it, so for the record: very nice work guys. Cheers, Dan On Sat, Feb 11, 2012 at 6:49 AM, Sven Reimers wrote: > There are some ideas sitzung in Jira that would be good for msking Charts > even more successful, e.g. logarithmic axis and multiple y-axis.. > > Hope OpenJFX will be the place to make those things happen. > > Sven > Am 10.02.2012 19:39 schrieb "Richard Bair" : > > >> > - Charts: seems like an add-on that will become something of a hassle >> for the JFX team to maintain, grow, support at the rate it will need, as >> well as adding complexity for mobile platforms (should a pie chart look the >> same on a mobile app with touch screen, no mouse over, etc). >> >> Different topic, but I thought this comment was interesting. Why are >> charts any different than controls? We see them as the same thing really. >> Charts are extensible -- folks can add new charts, or use the built in >> ones, exactly like controls. Both are intended to be drop-in use for >> applications. Charts are actually much more powerful than we've gotten >> credit for so far (I suspect this is because nobody has dug into them >> deeply and we've not documented a lot of the capabilities on fxexperience >> or javafx.com yet). >> >> Richard > > From tbee at tbee.org Sat Feb 11 23:18:03 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 12 Feb 2012 08:18:03 +0100 Subject: Charts: Was The Next Great Thing: An Application Framework In-Reply-To: References: <67E68928-E012-4167-80E4-7A7CD303D073@oracle.com> <9B0BA313-9396-4662-A372-B1774003E865@oracle.com> Message-ID: <4F3767AB.5030801@tbee.org> To add my ?0.02 on the chart topic; Dan here does hit the nail on the head. I started an email yesterday trying to explain exactly this, but I did not succeed (may have something to do with this fever thing I've got going on), so I'm gladly stealing Dan's points here. To me it most definitely is something of a higher abstraction level than controls. I can understand Richard's point of view though, but then a lot of stuff (like Dan's examples) are at the same level. Why only charts? Naturally this is of absolutely no practical consequence, because it is great that JFX has charts, no discussion there. But it may be interesting in light of how end-users look at charts and indeed on how OpenJFX is organized into modules or separate projects. Tom On 2012-02-12 07:38, Daniel Zwolenski wrote: > Hi Richard, > > It's not that I don't like having charts available when I want them and > although I haven't looked at them in depth yet, it looks like it is a very > powerful toolkit. It's just that I feel only a sub-set of applications > (specifically business/data apps) will actually use charts, whereas things > like buttons, labels, textfields are fairly ubiquitous building blocks for > everything. Charts feel more like a higher-level feature to me, on par with > things like 'mapping', file editing, PDF browsing, a 'game engine', or a > statistics package, etc. > > It is definitely possible that I may not fully understand the chart API as > yet though and my comments may be premature. I haven't had call to use them > yet in my applications, perhaps when I do I will change my viewpoint. With > that caveat in mind, the main drawbacks I see to charts being in the core > platform are these: > > 1. Resourcing - I have a gut feel that building/maintaining something like > this was and will be something of a hassle that will draw all-important > JavaFX resources away from more fundamental features. The community would > probably pick charts up if it was left out, so it feels like Oracle is > blowing 'coin' I'd rather see spent on stuff that can't (easily) be done by > the community because it is more 'core' (like video playback, true 3D > support, mobile phone support, etc). If Oracle's got resources to burn on > this then this is not such an issue, but I'd personally rather get a media > capture API, or a mobile version in there over charts, because charts I can > build myself, whereas media capture and/or mobile requires nasty native > libraries and weird non-java magic. > > 2. Bloat - it's good to keep the base platform as small and light as > possible so when we look at supporting platforms (like mobile, set top > boxes, etc) we only have to move the core features on to these and not be > moving a massive codebase across (and also downloading a massive jar). It's > easier to keep the platform stable too, less code means less bugs. If we > didn't have charts when we go 'mobile' then the move would be easier (i.e. > catering for touch screens, smaller screens, etc). Modularisation may help > with this, but I think the additional code in the core platform will still > result in more work. > > 3. Change management - my gut feel is something like charts will have a > more rapid change/fix cycle than the core platform. I don't particularly > want my end user to have to download a new JFX RT every other week > (especially if there are more annoying popups) because there has been a fix > in the way 'ticks' are rendered on a chart if I'm not using charts (whereas > HBox probably isn't going to change too often). Again maybe modularisation > will help with this, but it is still a way off and the deployment battle > may well be fought and lost before Java8 gets on it's horse and makes a > charge. > > As per my previous email, all of the above is not to say I wouldn't love to > see a separate ChartsFX library published by Oracle that had the exact > features in the core jfx charts module at the moment (deployed into Maven > would be even better :) ). > > As always, I'm definitely not putting down any of the effort put in by the > JFX team. I'm an unashamed platform zealot and a fan. JFX is the > development environment I've been dreaming about for years and I love it. > I'm more concerned about providing (hopefully) constructive feedback on > making it better and making sure the platform is sustainable so it can > become the standard and every new job I look at uses it. As we get stuck > into nutting out features and working through problems, it's easy to forget > to say it, so for the record: very nice work guys. > > Cheers, > Dan > > > > On Sat, Feb 11, 2012 at 6:49 AM, Sven Reimerswrote: > >> There are some ideas sitzung in Jira that would be good for msking Charts >> even more successful, e.g. logarithmic axis and multiple y-axis.. >> >> Hope OpenJFX will be the place to make those things happen. >> >> Sven >> Am 10.02.2012 19:39 schrieb "Richard Bair": >> >> >>>> - Charts: seems like an add-on that will become something of a hassle >>> for the JFX team to maintain, grow, support at the rate it will need, as >>> well as adding complexity for mobile platforms (should a pie chart look the >>> same on a mobile app with touch screen, no mouse over, etc). >>> >>> Different topic, but I thought this comment was interesting. Why are >>> charts any different than controls? We see them as the same thing really. >>> Charts are extensible -- folks can add new charts, or use the built in >>> ones, exactly like controls. Both are intended to be drop-in use for >>> applications. Charts are actually much more powerful than we've gotten >>> credit for so far (I suspect this is because nobody has dug into them >>> deeply and we've not documented a lot of the capabilities on fxexperience >>> or javafx.com yet). >>> >>> Richard >> From tom.schindl at bestsolution.at Sun Feb 12 01:47:36 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sun, 12 Feb 2012 10:47:36 +0100 Subject: The Next Great Thing: An Application Framework In-Reply-To: References: <4F35A074.6040601@bestsolution.at> Message-ID: <4F378AB8.2020508@bestsolution.at> Am 12.02.12 06:59, schrieb Daniel Zwolenski: > I like all the thinking on this front and the different initiatives (and > the enthusiasm). I think there is a lot of room for us to exchange ideas > (and code!) and either make sure each of the platforms is doing something > unique, or merge efforts if they are not. One of my fundamental goals > however is to not tie a developer into a specific development > toolset/environment as much as possible (as a developer I hate it when I > can't use my tools, so I try to make it so everyone else can use their > weapon of choice too), so the frameworks based around Eclipse (or any > specific IDE) are unfortunately not of direct appeal to me. > My RCP framework uses some of the core components developed at Eclipse yes but Eclipse like Netbeans has a layered architecture which looks like this for Eclipse: ---------------- | JVM | ---------------- | OSGi | ---------------- | E4AP | ---------------- | Eclipse SDK | ---------------- E4AP = Eclipse 4 Application Platform So e(fx)clipse rcp forces you to use OSGi (at least Netbeans knows who to deal with OSGi Bundles) - everything beside OSGi is provided but you are not forced to use it. The useage of dependency injection helps a lot in this respect because if you don't want to use it simply don't let the framework inject it, because there is no inheritance your component can be used even outside e(fx)clipse rcp. You want to use spring, fine. You want to use Guice, fine. You want to use your own Event Bus, fine .... You can now say OSGi is a no go for you but for an application framework one has to provide extensibility and OSGi beside e.g. the Netbeans module system is one of industry proven ones. 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 deep.blue.6802 at gmail.com Sun Feb 12 21:46:14 2012 From: deep.blue.6802 at gmail.com (Jeff McDonald) Date: Sun, 12 Feb 2012 22:46:14 -0700 Subject: Deployment Message-ID: Deployment is so important that I'd hope that it is at the top of the list. For me, I've always wanted to be able to push out a single double clickable app. No Java installs necessary. No Java version worries. As a developer I want full control of handling the versioning dependencies in my apps (co-bundling the JRE and all other libs and resources). I like it in part because I can take responsibility for what I ship. Most people prefer double clickable apps that require a one step install. Richard has talked about possibly adding a built in updater framework (like Sparkle ) in JavaFX before. That would be the ultimate combo with the double clickable app. This one should be up there in priority with double clickable apps. Daniel has discussed other requirements for deployment in previous postings. Maybe this thread can be a good place to pull those ideas together. Daniel Zwolenski wrote: The absolute fundamental issue that affects all platforms and for me is of such critical importance (it is the weakness that hamstrung Swing), is the whole deployment issue. This needs to be clean, smooth, simple. I can't emphasize this one enough. I feel like we're going to lose the battle to HTML5 if we don't address this issue up front and quickly (like in the next couple of months). I don't want JFX to spend the next 10 years playing second fiddle to crappy web-apps, like Swing has had to. Please don't make me write more JavaScript. For me that's what I'd like to see happen with JFX, the core libraries focus on getting the core things really good (such as looking good, which it most certainly has achieved, and deployment, which it most certainly hasn't), This core then facilitates the construction of feature rich application frameworks to solve specific domain cases for it. Richard Bair wrote: I think you make a very persuasive point that at this time there are app frameworks either released (yours) or in development (Jeff Martin's) and undoubtedly there will be more, and that perhaps we ought to spend our energy at Oracle in solving the part of the problem that only we can solve -- deployment and basic app lifecycle (such as is required to wire it all up to the native OS app lifecycle stuff). From deep.blue.6802 at gmail.com Sun Feb 12 23:03:33 2012 From: deep.blue.6802 at gmail.com (Jeff McDonald) Date: Mon, 13 Feb 2012 00:03:33 -0700 Subject: Charts: Was The Next Great Thing: An Application Framework In-Reply-To: <4F3767AB.5030801@tbee.org> References: <67E68928-E012-4167-80E4-7A7CD303D073@oracle.com> <9B0BA313-9396-4662-A372-B1774003E865@oracle.com> <4F3767AB.5030801@tbee.org> Message-ID: Charts .. I love them! Daniel nails the list of concerns, but on some of his points I come to different conclusions. 1. Resources - I agree, there are higher priorities on my list too (deployment would be one, and image processing APis another), but I gotta say ... the charts stuff Rocks! 2. Bloat - always a concern. I think charts are more common than one might think. Charts are something that I will use a lot more now that they will be a part of JavaFX so for me .. they aren't bloat. Considering that Oracle is funding all of the development and they are an enterprise customer that uses lots of charts ... I can see why they would have been important to include. Remembering that mobile platforms may be supported in the future size becomes more important. Java 8 change the landscape a bit because there will be greater flexibility to eliminate un-needed modules. 3. Change management - this is the real issue. Charts are off to a good start, but it they need to evolve and mature more first. I'd like to see them evolve on a different schedule than JavaFX and especially the JDK. Perhaps Java 8 will help out here too as mentioned before. The sweet spot would be to use Java 8 to allow inclusion or exclusion of charts in a app (deployment), and to have an updater service (like Sparkle) to let developers release updates when it seems best for them and their users. On Sun, Feb 12, 2012 at 12:18 AM, Tom Eugelink wrote: > > To add my ?0.02 on the chart topic; Dan here does hit the nail on the > head. I started an email yesterday trying to explain exactly this, but I > did not succeed (may have something to do with this fever thing I've got > going on), so I'm gladly stealing Dan's points here. To me it most > definitely is something of a higher abstraction level than controls. I can > understand Richard's point of view though, but then a lot of stuff (like > Dan's examples) are at the same level. Why only charts? > > Naturally this is of absolutely no practical consequence, because it is > great that JFX has charts, no discussion there. But it may be interesting > in light of how end-users look at charts and indeed on how OpenJFX is > organized into modules or separate projects. > > Tom > > > > On 2012-02-12 07:38, Daniel Zwolenski wrote: > >> Hi Richard, >> >> It's not that I don't like having charts available when I want them and >> although I haven't looked at them in depth yet, it looks like it is a very >> powerful toolkit. It's just that I feel only a sub-set of applications >> (specifically business/data apps) will actually use charts, whereas things >> like buttons, labels, textfields are fairly ubiquitous building blocks for >> everything. Charts feel more like a higher-level feature to me, on par >> with >> things like 'mapping', file editing, PDF browsing, a 'game engine', or a >> statistics package, etc. >> >> It is definitely possible that I may not fully understand the chart API as >> yet though and my comments may be premature. I haven't had call to use >> them >> yet in my applications, perhaps when I do I will change my viewpoint. With >> that caveat in mind, the main drawbacks I see to charts being in the core >> platform are these: >> >> 1. Resourcing - I have a gut feel that building/maintaining something like >> this was and will be something of a hassle that will draw all-important >> JavaFX resources away from more fundamental features. The community would >> probably pick charts up if it was left out, so it feels like Oracle is >> blowing 'coin' I'd rather see spent on stuff that can't (easily) be done >> by >> the community because it is more 'core' (like video playback, true 3D >> support, mobile phone support, etc). If Oracle's got resources to burn on >> this then this is not such an issue, but I'd personally rather get a media >> capture API, or a mobile version in there over charts, because charts I >> can >> build myself, whereas media capture and/or mobile requires nasty native >> libraries and weird non-java magic. >> >> 2. Bloat - it's good to keep the base platform as small and light as >> possible so when we look at supporting platforms (like mobile, set top >> boxes, etc) we only have to move the core features on to these and not be >> moving a massive codebase across (and also downloading a massive jar). >> It's >> easier to keep the platform stable too, less code means less bugs. If we >> didn't have charts when we go 'mobile' then the move would be easier (i.e. >> catering for touch screens, smaller screens, etc). Modularisation may help >> with this, but I think the additional code in the core platform will still >> result in more work. >> >> 3. Change management - my gut feel is something like charts will have a >> more rapid change/fix cycle than the core platform. I don't particularly >> want my end user to have to download a new JFX RT every other week >> (especially if there are more annoying popups) because there has been a >> fix >> in the way 'ticks' are rendered on a chart if I'm not using charts >> (whereas >> HBox probably isn't going to change too often). Again maybe modularisation >> will help with this, but it is still a way off and the deployment battle >> may well be fought and lost before Java8 gets on it's horse and makes a >> charge. >> >> As per my previous email, all of the above is not to say I wouldn't love >> to >> see a separate ChartsFX library published by Oracle that had the exact >> features in the core jfx charts module at the moment (deployed into Maven >> would be even better :) ). >> >> As always, I'm definitely not putting down any of the effort put in by the >> JFX team. I'm an unashamed platform zealot and a fan. JFX is the >> development environment I've been dreaming about for years and I love it. >> I'm more concerned about providing (hopefully) constructive feedback on >> making it better and making sure the platform is sustainable so it can >> become the standard and every new job I look at uses it. As we get stuck >> into nutting out features and working through problems, it's easy to >> forget >> to say it, so for the record: very nice work guys. >> >> Cheers, >> Dan >> >> >> >> On Sat, Feb 11, 2012 at 6:49 AM, Sven Reimers> >wrote: >> >> There are some ideas sitzung in Jira that would be good for msking Charts >>> even more successful, e.g. logarithmic axis and multiple y-axis.. >>> >>> Hope OpenJFX will be the place to make those things happen. >>> >>> Sven >>> Am 10.02.2012 19:39 schrieb "Richard Bair"**: >>> >>> >>> - Charts: seems like an add-on that will become something of a hassle >>>>> >>>> for the JFX team to maintain, grow, support at the rate it will need, as >>>> well as adding complexity for mobile platforms (should a pie chart look >>>> the >>>> same on a mobile app with touch screen, no mouse over, etc). >>>> >>>> Different topic, but I thought this comment was interesting. Why are >>>> charts any different than controls? We see them as the same thing >>>> really. >>>> Charts are extensible -- folks can add new charts, or use the built in >>>> ones, exactly like controls. Both are intended to be drop-in use for >>>> applications. Charts are actually much more powerful than we've gotten >>>> credit for so far (I suspect this is because nobody has dug into them >>>> deeply and we've not documented a lot of the capabilities on >>>> fxexperience >>>> or javafx.com yet). >>>> >>>> Richard >>>> >>> >>> > > From deep.blue.6802 at gmail.com Mon Feb 13 03:04:06 2012 From: deep.blue.6802 at gmail.com (Jeff McDonald) Date: Mon, 13 Feb 2012 04:04:06 -0700 Subject: FXML [was The Next Great Thing: An Application Framework] Message-ID: Daniel Zwolenski wrote: >>On a related front, two other areas that in my mind probably would have been better off external to JFX are: >> FXML: it is built on-top of JFX and so does not need to be part of the core. It also implies a certain MVC architecture, and >> as we've seen that's not ubiquitous (nor is the architecture style chosen particularly in-line with at least a sub-section of the >> community which is an example of the sorts of complications an Application framework creates) Isn't FXML development closely tied to the components/styles/properties of a specific release version. If so, then developing the JavaFX core and FXML in lock-step is the way to go, otherwise there would be version concerns. FXML is still a "what is it?" kinda thing for me. At first I thought it was more like a serialization format for JavaFX, but there seems to be more to it. It would be nice to call some like FXML.build("my_window.fxml") and then get a nice object graph back. At least the JavaFX team didn't follow Microsoft's lead and add partial classes to Java like MS did in .net. From tbee at tbee.org Mon Feb 13 03:41:57 2012 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 13 Feb 2012 12:41:57 +0100 Subject: FXML [was The Next Great Thing: An Application Framework] In-Reply-To: References: Message-ID: <4F38F705.5030308@tbee.org> FXML dynamically maps the XML to the classes, that is how it was possible to (quite easily I must say) add support for MigLayoutFX to FXML. Tom PS: partial classes, yeah, that kinda had me spinning my head for a while there when I did some C#. All though I would not mind having mixins back. On 2012-02-13 12:04, Jeff McDonald wrote: > Daniel Zwolenski wrote: > >>> On a related front, two other areas that in my mind probably would have > been better off external to JFX are: > >>> FXML: it is built on-top of JFX and so does not need to be part of the > core. It also implies a certain MVC architecture, and >>> as we've seen that's not ubiquitous (nor is the architecture style > chosen particularly in-line with at least a sub-section of the >>> community which is an example of the sorts of complications an > Application framework creates) > > Isn't FXML development closely tied to the components/styles/properties of > a specific release version. If so, then developing the JavaFX core and FXML > in lock-step is the way to go, otherwise there would be version concerns. > > FXML is still a "what is it?" kinda thing for me. At first I thought it was > more like a serialization format for JavaFX, but there seems to be more to > it. It would be nice to call some like FXML.build("my_window.fxml") and > then get a nice object graph back. > > At least the JavaFX team didn't follow Microsoft's lead and add partial > classes to Java like MS did in .net. > From zonski at googlemail.com Mon Feb 13 04:32:04 2012 From: zonski at googlemail.com (Daniel Zwolenski) Date: Mon, 13 Feb 2012 22:32:04 +1000 Subject: FXML [was The Next Great Thing: An Application Framework] In-Reply-To: <4F38F705.5030308@tbee.org> References: <4F38F705.5030308@tbee.org> Message-ID: <0A30F011-C4AB-4378-9120-717AD670C981@gmail.com> As Tom says, it's all reflection based, basically the tag