From richard.bair at oracle.com Thu Dec 1 16:16:58 2011 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 1 Dec 2011 16:16:58 -0800 Subject: Hello World! Message-ID: Hello, is this thing on? Hey everybody, just wanted to be first to post to the brand spanking new openjfx-dev mailing list :-) Cheers Richard From brian.beck at oracle.com Thu Dec 1 16:17:42 2011 From: brian.beck at oracle.com (Brian Beck) Date: Thu, 01 Dec 2011 16:17:42 -0800 Subject: We're here! Message-ID: <4ED81926.2050108@oracle.com> Ready and rarin' to go. Brian. From mark.reinhold at oracle.com Thu Dec 1 16:22:01 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 01 Dec 2011 16:22:01 -0800 Subject: Hello World! In-Reply-To: richard.bair@oracle.com; Thu, 01 Dec 2011 16:16:58 PST; Message-ID: <20111202002201.7EB6B16D4@eggemoggin.niobe.net> 2011/12/1 16:16 -0800, richard.bair at oracle.com: > Hello, is this thing on? ... Yep. You have a web page and an empty Mercurial forest, too: http://openjdk.java.net/projects/openjfx/ http://hg.openjdk.java.net/openjfx/2.1/master - Mark From richard.bair at oracle.com Thu Dec 1 16:23:12 2011 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 1 Dec 2011 16:23:12 -0800 Subject: Hello World! In-Reply-To: <20111202002201.7EB6B16D4@eggemoggin.niobe.net> References: <20111202002201.7EB6B16D4@eggemoggin.niobe.net> Message-ID: Excellent! Thanks Mark! On Dec 1, 2011, at 4:22 PM, mark.reinhold at oracle.com wrote: > 2011/12/1 16:16 -0800, richard.bair at oracle.com: >> Hello, is this thing on? ... > > Yep. You have a web page and an empty Mercurial forest, too: > > http://openjdk.java.net/projects/openjfx/ > http://hg.openjdk.java.net/openjfx/2.1/master > > - Mark From kevin.rushforth at oracle.com Thu Dec 1 16:52:22 2011 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 01 Dec 2011 16:52:22 -0800 Subject: Hello Message-ID: <4ED82146.9030703@oracle.com> Just checking that Ii can send an e-mail... -- Kevin From neugens.limasoftware at gmail.com Fri Dec 2 01:34:32 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 2 Dec 2011 10:34:32 +0100 Subject: Hello World! Message-ID: > > Hello, is this thing on? ... > > Yep. ?You have a web page and an empty Mercurial forest, too:>>? http://openjdk.java.net/projects/openjfx/>? http://hg.openjdk.java.net/openjfx/2.1/master>> - Mark And now let's fill it up! Cheers everyone! Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA? FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From kevin.rushforth at oracle.com Fri Dec 2 14:42:10 2011 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 02 Dec 2011 14:42:10 -0800 Subject: Source code for JavaFX UI controls now available on openjfx Message-ID: <4ED95442.5070403@oracle.com> The Mercurial repositories are now populated with the source code for the JavaFX UI Controls. You can clone the repository at: hg clone http://hg.openjdk.java.net/openjfx/2.1/master/rt Enjoy! -- Kevin Rushforth JavaFX Team From richard.bair at oracle.com Fri Dec 2 14:56:36 2011 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 2 Dec 2011 14:56:36 -0800 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <4ED95442.5070403@oracle.com> References: <4ED95442.5070403@oracle.com> Message-ID: <399CEBFC-D94E-489F-BF96-17A628736C4B@oracle.com> Great! And with that the doors are open for business :-) We're happy for all sorts of patches, from performance to documentation to bug fixes to general cleanup. You'll want to post such things to this list for now, while we expect there to be a controls specific list setup sometime soonish. The following query exposes the list of bugs and features for UI controls presently targeted at 2.1. Of course if you have bugs you want to fix that are not in this list, you can certainly head for those as well. http://javafx-jira.kenai.com/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+RT+AND+issuetype+not+in+%28Sub-task%29+AND+status+%21%3D+New+AND+resolution+%3D+Unresolved+AND+fixVersion+%3D+%222.1%22+AND+component+%3D+Control+ORDER+BY+key+DESC Probably it is easiest to start in on something minor to get your feet wet (and ours too) in the whole process. You can see the OpenJDK rules and bylaws (http://openjdk.java.net/bylaws). Basically, we ask people to initially contribute patches, and after some number of non-trivial patches, if you're interested, we can call a vote to give you commit privileges. As a rule of thumb this takes about 3 months -- our desire is to hand commit rights out only to those who have shown a strong commitment to the project. Along these lines, we have not given commit rights to all of our own developers either, only those who have similarly been actively involved in committing code into JavaFX. Let's get started! Cheers Richard On Dec 2, 2011, at 2:42 PM, Kevin Rushforth wrote: > The Mercurial repositories are now populated with the source code for the JavaFX UI Controls. You can clone the repository at: > > hg clone http://hg.openjdk.java.net/openjfx/2.1/master/rt > > Enjoy! > > -- > Kevin Rushforth > JavaFX Team > From neugens.limasoftware at gmail.com Fri Dec 2 14:57:04 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 2 Dec 2011 23:57:04 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <4ED95442.5070403@oracle.com> References: <4ED95442.5070403@oracle.com> Message-ID: <651B13B4-A077-45E0-856F-60CBEFFA13D4@gmail.com> Il giorno 02/dic/2011, alle ore 23:42, Kevin Rushforth ha scritto: > The Mercurial repositories are now populated with the source code for the JavaFX UI Controls. You can clone the repository at: > > hg clone http://hg.openjdk.java.net/openjfx/2.1/master/rt > > Enjoy! Great, thanks a lot! Cheers, Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From neugens.limasoftware at gmail.com Fri Dec 2 15:04:28 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sat, 3 Dec 2011 00:04:28 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <399CEBFC-D94E-489F-BF96-17A628736C4B@oracle.com> References: <4ED95442.5070403@oracle.com> <399CEBFC-D94E-489F-BF96-17A628736C4B@oracle.com> Message-ID: Il giorno 02/dic/2011, alle ore 23:56, Richard Bair ha scritto: > Great! And with that the doors are open for business :-) > > We're happy for all sorts of patches, from performance to documentation to bug fixes to general cleanup. You'll want to post such things to this list for now, while we expect there to be a controls specific list setup sometime soonish. > > The following query exposes the list of bugs and features for UI controls presently targeted at 2.1. Of course if you have bugs you want to fix that are not in this list, you can certainly head for those as well. http://javafx-jira.kenai.com/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+RT+AND+issuetype+not+in+%28Sub-task%29+AND+status+%21%3D+New+AND+resolution+%3D+Unresolved+AND+fixVersion+%3D+%222.1%22+AND+component+%3D+Control+ORDER+BY+key+DESC > > Probably it is easiest to start in on something minor to get your feet wet (and ours too) in the whole process. > > You can see the OpenJDK rules and bylaws (http://openjdk.java.net/bylaws). Basically, we ask people to initially contribute patches, and after some number of non-trivial patches, if you're interested, we can call a vote to give you commit privileges. As a rule of thumb this takes about 3 months -- our desire is to hand commit rights out only to those who have shown a strong commitment to the project. Along these lines, we have not given commit rights to all of our own developers either, only those who have similarly been actively involved in committing code into JavaFX. > > Let's get started! > > Cheers > Richard > > On Dec 2, 2011, at 2:42 PM, Kevin Rushforth wrote: > >> The Mercurial repositories are now populated with the source code for the JavaFX UI Controls. You can clone the repository at: >> >> hg clone http://hg.openjdk.java.net/openjfx/2.1/master/rt >> >> Enjoy! >> >> -- >> Kevin Rushforth >> JavaFX Team >> > Maybe the first thing to know is how to build it :) Cheers, Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From richard.bair at oracle.com Fri Dec 2 15:12:36 2011 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 2 Dec 2011 15:12:36 -0800 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <651B13B4-A077-45E0-856F-60CBEFFA13D4@gmail.com> References: <4ED95442.5070403@oracle.com> <651B13B4-A077-45E0-856F-60CBEFFA13D4@gmail.com> Message-ID: So I cloned: hg clone http://hg.openjdk.java.net/openjfx/2.1/master cd master hg clone http://hg.openjdk.java.net/openjfx/2.1/master/rt This gets all the sources, but unfortunately it isn't building (had to cd into master/rt/javafx-ui-controls). I get: BUILD FAILED /Developer/Projects/openjfx/workspace-2.1/master/rt/javafx-ui-controls/build.xml:5: The following error occurred while executing this line: /Developer/Projects/openjfx/workspace-2.1/master/rt/build-defs.xml:10: Cannot find /Developer/Projects/openjfx/workspace-2.1/master/build-defs.xml imported from /Developer/Projects/openjfx/workspace-2.1/master/rt/build-defs.xml We are supposed to also have weekly 2.1 drops, and until we get the rest open sourced, you have to have the 2.1 jar to build with. However it doesn't look like that part of the process has completed (which is quite embarrassing). Looking into it. Richard On Dec 2, 2011, at 2:57 PM, Mario Torre wrote: > Il giorno 02/dic/2011, alle ore 23:42, Kevin Rushforth ha scritto: >> The Mercurial repositories are now populated with the source code for the JavaFX UI Controls. You can clone the repository at: >> >> hg clone http://hg.openjdk.java.net/openjfx/2.1/master/rt >> >> Enjoy! > > > Great, thanks a lot! > > Cheers, > Mario > --- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > http://www.ladybug-studio.com > > IcedRobot: www.icedrobot.org > Proud GNU Classpath developer: http://www.classpath.org/ > Read About us at: http://planet.classpath.org > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ > > > > > From neugens.limasoftware at gmail.com Fri Dec 2 15:42:13 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sat, 3 Dec 2011 00:42:13 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: References: <4ED95442.5070403@oracle.com> <651B13B4-A077-45E0-856F-60CBEFFA13D4@gmail.com> Message-ID: <3256D7C0-3DC1-44A8-8F78-592050C2B0F4@gmail.com> Il giorno 03/dic/2011, alle ore 00:12, Richard Bair ha scritto: > So I cloned: > > hg clone http://hg.openjdk.java.net/openjfx/2.1/master > cd master > hg clone http://hg.openjdk.java.net/openjfx/2.1/master/rt > > This gets all the sources, but unfortunately it isn't building (had to cd into master/rt/javafx-ui-controls). I get: > > BUILD FAILED > /Developer/Projects/openjfx/workspace-2.1/master/rt/javafx-ui-controls/build.xml:5: The following error occurred while executing this line: > /Developer/Projects/openjfx/workspace-2.1/master/rt/build-defs.xml:10: Cannot find /Developer/Projects/openjfx/workspace-2.1/master/build-defs.xml imported from /Developer/Projects/openjfx/workspace-2.1/master/rt/build-defs.xml > > We are supposed to also have weekly 2.1 drops, and until we get the rest open sourced, you have to have the 2.1 jar to build with. However it doesn't look like that part of the process has completed (which is quite embarrassing). Looking into it. > > Richard Is a simple file missing from the root directory of the forest: What I don't understand is also where to put the (and where to find) the jar files with the binary plugs, will they be downloaded by ant? (still reading the build file, but the code is more interesting ;) Cheers, Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From brian.beck at oracle.com Fri Dec 2 15:48:43 2011 From: brian.beck at oracle.com (Brian Beck) Date: Fri, 02 Dec 2011 15:48:43 -0800 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <399CEBFC-D94E-489F-BF96-17A628736C4B@oracle.com> References: <4ED95442.5070403@oracle.com> <399CEBFC-D94E-489F-BF96-17A628736C4B@oracle.com> Message-ID: <4ED963DB.5020204@oracle.com> On 12/2/11 2:56 PM, Richard Bair wrote: > Great! And with that the doors are open for business :-) Sort of. The open part of JavaFX necessarily depends on the closed part for awhile yet. Which means that you'll need a recent build of the closed code in order to build what's in openjfx. We're planning on making weekly builds of the closed bits available but so far that hasn't happened yet. (Lawyers, yada yada yada) We expect to see it soon. In the meantime folks will just have to look at the code and sigh. :-) Seriously, we know it's a drag to wait but we though this was better than keeping the source locked up until the weekly builds were ready. Brian. From brian.beck at oracle.com Fri Dec 2 16:02:47 2011 From: brian.beck at oracle.com (Brian Beck) Date: Fri, 02 Dec 2011 16:02:47 -0800 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <3256D7C0-3DC1-44A8-8F78-592050C2B0F4@gmail.com> References: <4ED95442.5070403@oracle.com> <651B13B4-A077-45E0-856F-60CBEFFA13D4@gmail.com> <3256D7C0-3DC1-44A8-8F78-592050C2B0F4@gmail.com> Message-ID: <4ED96727.1040502@oracle.com> On 12/2/11 3:42 PM, Mario Torre wrote: > > Is a simple file missing from the root directory of the forest: > > > > What I don't understand is also where to put the (and where to find) the jar files with the binary plugs, will they be downloaded by ant? (still reading the build file, but the code is more interesting ;) Mario: My previous message was probably not clear enough. The binary plugs will, for now, be the entire JavaFX binaries - including the UI Controls. The idea is that you will download the latest Oracle's binaries, use it to build the open bits and then put the jar file you built ahead of the Oracle jar file on your command line. This is all temporary of course but it was the quickest way to get started. The problem at the moment is that the Oracle binaries are not quite ready to be posted. When they are they will be on a standard Oracle download site. We would like them to be placed at a fixed location that would allow ant to find them but that requires some Oracle policy changes which may or may not happen. Worse case is that you have to manually download the Oracle weekly binaries. We know this is all very ad hoc but it is a work in progress. We thought it would be best to get the code out fast and refine the details over time. Brian. From neugens.limasoftware at gmail.com Fri Dec 2 16:25:09 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sat, 3 Dec 2011 01:25:09 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <4ED96727.1040502@oracle.com> References: <4ED95442.5070403@oracle.com> <651B13B4-A077-45E0-856F-60CBEFFA13D4@gmail.com> <3256D7C0-3DC1-44A8-8F78-592050C2B0F4@gmail.com> <4ED96727.1040502@oracle.com> Message-ID: Il giorno 03/dic/2011, alle ore 01:02, Brian Beck ha scritto: > On 12/2/11 3:42 PM, Mario Torre wrote: >> >> Is a simple file missing from the root directory of the forest: >> >> >> >> What I don't understand is also where to put the (and where to find) the jar files with the binary plugs, will they be downloaded by ant? (still reading the build file, but the code is more interesting ;) > Mario: > > My previous message was probably not clear enough. The binary plugs will, for now, be the entire JavaFX binaries - including the UI Controls. The idea is that you will download the latest Oracle's binaries, use it to build the open bits and then put the jar file you built ahead of the Oracle jar file on your command line. This is all temporary of course but it was the quickest way to get started. > > The problem at the moment is that the Oracle binaries are not quite ready to be posted. When they are they will be on a standard Oracle download site. We would like them to be placed at a fixed location that would allow ant to find them but that requires some Oracle policy changes which may or may not happen. Worse case is that you have to manually download the Oracle weekly binaries. > > We know this is all very ad hoc but it is a work in progress. We thought it would be best to get the code out fast and refine the details over time. > > Brian. Hi Brian, Sorry I misunderstood, I was expecting something similar to the binary plugs we had in OpenJDK, not a full version of the current release, hence the question. I was able to import the project successfully into eclipse (and netbeans) with the FX runtime and it seems to compile fine. I'll play with this code a bit and see how we can help out until everything else is sorted out. I think that while this is a suboptimal situation (but hey, we Free Software freaks are never happy, right? :) is still a great step forward, and we have a chance to study the code and the internals before everything gets released. Speaking about this, do you think we can have some "specs" about the internal interfaces? I know from JavaOne that the internal code is pretty abstracted and modular, and can actually be "easily" replaced (not sure the exact definition of easily though, but what you have shown at J1 was very impressive). We can probably help speeding up things if we know what things should be replaced and implement some clear room version of what will come later in the game, in a similar way we did with the Pisces renderer in Java2D, what do you think? I'm specifically thinking about the Linux port here, since to be honest "late 2012" is eons away. Cheers, Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From brian.beck at oracle.com Fri Dec 2 16:34:46 2011 From: brian.beck at oracle.com (Brian Beck) Date: Fri, 02 Dec 2011 16:34:46 -0800 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: References: <4ED95442.5070403@oracle.com> <651B13B4-A077-45E0-856F-60CBEFFA13D4@gmail.com> <3256D7C0-3DC1-44A8-8F78-592050C2B0F4@gmail.com> <4ED96727.1040502@oracle.com> Message-ID: <4ED96EA6.3090208@oracle.com> On 12/2/11 4:25 PM, Mario Torre wrote: > Hi Brian, > > Sorry I misunderstood, I was expecting something similar to the binary plugs we had in OpenJDK, not a full version of the current release, hence the question. > Makes sense. And in fact, I expect that we'll have binary plugs in the OpenJDK style once we get a bit more of the platform moved into the open. But right now this seemed to get us going the fastest. > Speaking about this, do you think we can have some "specs" about the internal interfaces? Yes, I do. This is another thing we've talked about but just aren't ready with. I'm hoping to get a wiki set up that can be used for this sort of documentation. I'm in negotiations with the folks who control the OpenJDK infrastructure but I don't have any resolution yet. And of course we will have to write a lot of that documentation. That's not always high on our list when products need to be shipped. :-) Again, we know this is rough at the moment but we expect it to improve rapidly. Our philosophy was to get the code out fast and then evolve the project as a community rather than make everything smooth from day one. We'll see whether or not that was a good idea. Brian. From richard.bair at oracle.com Fri Dec 2 17:43:20 2011 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 2 Dec 2011 17:43:20 -0800 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: References: <4ED95442.5070403@oracle.com> <651B13B4-A077-45E0-856F-60CBEFFA13D4@gmail.com> <3256D7C0-3DC1-44A8-8F78-592050C2B0F4@gmail.com> <4ED96727.1040502@oracle.com> Message-ID: <2F7DEE03-9940-4820-9CBE-7883FF86C20D@oracle.com> > Sorry I misunderstood, I was expecting something similar to the binary plugs we had in OpenJDK, not a full version of the current release, hence the question. > > I was able to import the project successfully into eclipse (and netbeans) with the FX runtime and it seems to compile fine. Oh, that's interesting. I grabbed the latest 2.0.2 code for Mac that I had available but it was failing on: [javac] /Developer/Projects/openjfx/workspace-2.1/master/rt/javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ButtonBehavior.java:42: cannot find symbol [javac] symbol : class PlatformUtil [javac] location: package com.sun.javafx [javac] import com.sun.javafx.PlatformUtil; [javac] ^ And a bunch of other such failures. So I thought PlatformUtil had been removed between the 2.0.2 code I had (from early November) and the newer code in the 2.1 tree. If you got it to build in Eclipse on an older release -- well that is interesting! What version of JavaFX are you using for the binary plug? Do you want to post some basic instructions so other folks can do likewise? > I'll play with this code a bit and see how we can help out until everything else is sorted out. > > I think that while this is a suboptimal situation (but hey, we Free Software freaks are never happy, right? :) is still a great step forward, and we have a chance to study the code and the internals before everything gets released. > > Speaking about this, do you think we can have some "specs" about the internal interfaces? Probably in the short term asking me questions is the fastest way to get answers, unfortunately. I do need to be badgered to write up some documents though and put them up on our pages. Please do feel free to badger me: squeaky wheel and all that :-) > I know from JavaOne that the internal code is pretty abstracted and modular, and can actually be "easily" replaced (not sure the exact definition of easily though, but what you have shown at J1 was very impressive). > > We can probably help speeding up things if we know what things should be replaced and implement some clear room version of what will come later in the game, in a similar way we did with the Pisces renderer in Java2D, what do you think? > > I'm specifically thinking about the Linux port here, since to be honest "late 2012" is eons away. What we have released so far is the controls portion, which all sits above the "toolkit implementation" line. Basically on the "top" we've got controls, scene graph, css, properties, binding, collections, services, and that sort of thing. There is a Toolkit interface (com.sun.javafx.tk.Toolkit) which defines the abstraction between the public API portions of the platform and the underlying toolkit implementation (threading, windowing, opengl, d3d, fonts, etc). Likely it will be a couple months before we start putting out the lower-level bits en masse, due to having to be careful there over 3rd party code etc (there isn't much, mostly fonts and some SVG, but we have to do all the due diligence). The other problem is the same guys who have to do that, have to get the Mac port finished (both for Java 7 and for Java FX). However I will follow up with the guys doing linux and see if we can get that out sooner (they're busy working away on it and it would be cool to get it open faster, but at the very least get it included in the bits so you can run on linux). Cheers Richard From roman at kennke.org Sat Dec 3 00:37:25 2011 From: roman at kennke.org (Roman Kennke) Date: Sat, 03 Dec 2011 09:37:25 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <4ED95442.5070403@oracle.com> References: <4ED95442.5070403@oracle.com> Message-ID: <1322901445.3603.3.camel@moonlight> Hi there, > The Mercurial repositories are now populated with the source code for > the JavaFX UI Controls. You can clone the repository at: > > hg clone http://hg.openjdk.java.net/openjfx/2.1/master/rt Amazing stuff, thanks! I will give it a spin when I find some time (quite busy at the moment..). Cheers, Roman From roman at kennke.org Sat Dec 3 00:42:17 2011 From: roman at kennke.org (Roman Kennke) Date: Sat, 03 Dec 2011 09:42:17 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <4ED95442.5070403@oracle.com> References: <4ED95442.5070403@oracle.com> Message-ID: <1322901737.3603.5.camel@moonlight> Ah and we might start thinking about if/how to integrate the SwingView into OpenJFX: http://rkennke.wordpress.com/2011/11/16/swing-in-javafx-demo/ Not sure if it belongs in controls (it's a sort of control anyway... ) or in some other package though, maybe in the same package as the JFXPanel. Cheers, Roman Am Freitag, den 02.12.2011, 14:42 -0800 schrieb Kevin Rushforth: > The Mercurial repositories are now populated with the source code for > the JavaFX UI Controls. You can clone the repository at: > > hg clone http://hg.openjdk.java.net/openjfx/2.1/master/rt > > Enjoy! > From neugens.limasoftware at gmail.com Sat Dec 3 01:40:51 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sat, 3 Dec 2011 10:40:51 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <1322901737.3603.5.camel@moonlight> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> Message-ID: <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> Il giorno 03/dic/2011, alle ore 09:42, Roman Kennke ha scritto: > Ah and we might start thinking about if/how to integrate the SwingView > into OpenJFX: > > http://rkennke.wordpress.com/2011/11/16/swing-in-javafx-demo/ > > Not sure if it belongs in controls (it's a sort of control anyway... ) > or in some other package though, maybe in the same package as the > JFXPanel. > > Cheers, Roman > > Am Freitag, den 02.12.2011, 14:42 -0800 schrieb Kevin Rushforth: >> The Mercurial repositories are now populated with the source code for >> the JavaFX UI Controls. You can clone the repository at: >> >> hg clone http://hg.openjdk.java.net/openjfx/2.1/master/rt >> >> Enjoy! >> > > Yeah, I was about to prepare a webrev before getting asleep yesterday :) I think it's a control, after all is supposed to be used to show Swing widgets :) Btw, is there any reason why the code is GPL only and not LGPL or GPL plus Classpath as the JDK? It seems weird for me since is a library (we did the same "mistakes" for ThinkgsFX btw). Cheers, Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From jonathan.giles at oracle.com Sat Dec 3 02:07:05 2011 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Sat, 03 Dec 2011 20:07:05 +1000 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> Message-ID: <4ED9F4C9.4000108@oracle.com> With regards as to whether the SwingView feature you've developed is considered a control or not: my unofficial means of classifying would say that unless it extends from, or somehow makes use of the javafx.scene.control.Control class, it is not a control. If this isn't the case (I haven't looked myself, but my guess is that it isn't), then I'd say that this feature is not destined to be included in the ui-controls project. Of course, it isn't my place to say this with any conviction, I'm just saying what my interpretation is. With regard to the licensing (and note that I am very much not a lawyer), I just loaded up some of the source files from the ui-controls project, and it appears to me that everything is licensed as GPL plus classpath already. For example, here is the full header for Control.java with the relevant section made bold: /* * Copyright (c) 2010, 2011, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. *Oracle designates this * particular file as subject to the "Classpath" exception as provided * by Oracle in the LICENSE file that accompanied this code.* * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * version 2 for more details (a copy is included in the LICENSE file that * accompanied this code). * * You should have received a copy of the GNU General Public License version * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. */ Referring to the LICENSE file in the root folder of openjfx, I see at line 326 mention of the classpath exception. Hope that helps. -- Jonathan > > > Yeah, I was about to prepare a webrev before getting asleep yesterday :) > > I think it's a control, after all is supposed to be used to show Swing > widgets :) > > Btw, is there any reason why the code is GPL only and not LGPL or GPL > plus Classpath as the JDK? > > It seems weird for me since is a library (we did the same "mistakes" > for ThinkgsFX btw). > > Cheers, > Mario > --- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > http://www.ladybug-studio.com > > IcedRobot: www.icedrobot.org > Proud GNU Classpath developer: http://www.classpath.org/ > Read About us at: http://planet.classpath.org > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ > > > From neugens.limasoftware at gmail.com Sat Dec 3 03:25:18 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sat, 3 Dec 2011 12:25:18 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <4ED9F4C9.4000108@oracle.com> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> Message-ID: Il giorno 03/dic/2011, alle ore 11:07, Jonathan Giles ha scritto: > > With regards as to whether the SwingView feature you've developed is considered a control or not: my unofficial means of classifying would say that unless it extends from, or somehow makes use of the javafx.scene.control.Control class, it is not a control. If this isn't the case (I haven't looked myself, but my guess is that it isn't), then I'd say that this feature is not destined to be included in the ui-controls project. Of course, it isn't my place to say this with any conviction, I'm just saying what my interpretation is. Hello Jonathan, It consist of two parts, one is the BufferedImageView, this is a View, then we have the SwingView control, which extends Control. BufferImageView is needed by SwingView, so if SwingView gets integrated in the Controls (its natural space) we still need BufferedImageView. If the views are in a separate repository and the BufferedImageView needs to be submitted "later" in the process, then we either need to integrate it for now in the SwingView or make it package private, or let this little but useful alien live in the Control repository. We also do have few classes, which are package private. The usual way for Sun/Oracle to handle implementation classes is to make everything public but in a separate "hidden" namespace, instead we prefer to have the classes local to where they are used, but this of course tends to pollute the package with hidden classes (it's the same from user perspective though, and as you know, some users will still mess up with internal classes ;). > With regard to the licensing (and note that I am very much not a lawyer), I just loaded up some of the source files from the ui-controls project, and it appears to me that everything is licensed as GPL plus classpath already. For example, here is the full header for Control.java with the relevant section made bold: > Referring to the LICENSE file in the root folder of openjfx, I see at line 326 mention of the classpath exception. > My bad, indeed! I had yet to have my coffee... but now I see again ;) Sorry for the confusion! So, this is the first iteration, BufferdImageView is part of the controls here with SwingView, the package private classes are in the same package and the package is javafx.embed.swing (which I think makes sense for both those two classes). Users must call SwingFX.init() before anything else if they want to use the SwingView, since we need to install some properties and the correct KeyboardFocusManagement peer. So we have 3 public classes, SwingFX, SwingView and BufferedImageView. Here is the webrev: http://cr.openjdk.java.net/~neugens/javafx-swing/webrev.01/ I expect to have few iteration until the code gets in the shape for official release, and I don't expect this to be already this afternoon ;) of course, so any comment is very welcomed. Thanks a lot! Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From roman at kennke.org Sat Dec 3 03:45:48 2011 From: roman at kennke.org (Roman Kennke) Date: Sat, 03 Dec 2011 12:45:48 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> Message-ID: <1322912748.3603.11.camel@moonlight> Hi Mario, > I think it's a control, after all is supposed to be used to show Swing widgets :) Yes, but it introduces a dependency on Swing, which is probably not wanted (pulls in gazillions of fluff). Maybe it's better to put it side by side with the JFXPanel. Actually I think even the JFXPanel should be in an extra package/jar because of this dependency on Swing/AWT/Java2D. > Btw, is there any reason why the code is GPL only and not LGPL or GPL plus Classpath as the JDK? > > It seems weird for me since is a library (we did the same "mistakes" for ThinkgsFX btw). I think that is a fine license. Why is this a mistake? Why is LGPL or GPL+Exception better? I guess it depends on what you wanna do with it, if you want to ensure it's only used in other free software, and prevent use of it in non-free than that's fine (for example, if you put it as LGPL or BSD or whatnot, every commercial vendor can use it, modify it and redistribute the modified version in its own closed software/device without publishing its modifications, which is most likely not in Oracle's - and our - interest). On the other hand, it would be in Oracle's interest to make it available as liberally as possible to help adoption to begin with. So there's a tradeoff I guess. Pure GPL leans a little on the too-restrictive/hindering adoption side though... Best regards, Roman Regards, Roman From roman at kennke.org Sat Dec 3 03:50:00 2011 From: roman at kennke.org (Roman Kennke) Date: Sat, 03 Dec 2011 12:50:00 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <4ED9F4C9.4000108@oracle.com> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> Message-ID: <1322913000.3603.13.camel@moonlight> Hi Jonathan, > With regards as to whether the SwingView feature you've developed is > considered a control or not: my unofficial means of classifying would > say that unless it extends from, or somehow makes use of the > javafx.scene.control.Control class, it is not a control. If this isn't > the case (I haven't looked myself, but my guess is that it isn't), > then I'd say that this feature is not destined to be included in the > ui-controls project. Of course, it isn't my place to say this with any > conviction, I'm just saying what my interpretation is. The SwingView is a subclass of control. However, I still don't feel it should go side by side with the other controls, since it's not a 'regular' control like button, labels, combobox, etc. It could still be part of the ui-controls, just maybe in a different package. Cheers, Roman From mp at jugs.org Sat Dec 3 05:00:23 2011 From: mp at jugs.org (Dr. Michael Paus) Date: Sat, 03 Dec 2011 14:00:23 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <1322913000.3603.13.camel@moonlight> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> Message-ID: <4EDA1D67.2030505@jugs.org> Before any decisions are made on this issue you might look at the following forum post. It is a long post. Just go to the end of it for the discussion which started on Dec. 2nd. I think there is an overlap of activities. LG, Michael Am 03.12.2011 12:50, schrieb Roman Kennke: > Hi Jonathan, > >> With regards as to whether the SwingView feature you've developed is >> considered a control or not: my unofficial means of classifying would >> say that unless it extends from, or somehow makes use of the >> javafx.scene.control.Control class, it is not a control. If this isn't >> the case (I haven't looked myself, but my guess is that it isn't), >> then I'd say that this feature is not destined to be included in the >> ui-controls project. Of course, it isn't my place to say this with any >> conviction, I'm just saying what my interpretation is. > The SwingView is a subclass of control. However, I still don't feel it > should go side by side with the other controls, since it's not a > 'regular' control like button, labels, combobox, etc. It could still be > part of the ui-controls, just maybe in a different package. > > Cheers, Roman > > -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From roman at kennke.org Sat Dec 3 05:17:22 2011 From: roman at kennke.org (Roman Kennke) Date: Sat, 03 Dec 2011 14:17:22 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <4EDA1D67.2030505@jugs.org> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> <4EDA1D67.2030505@jugs.org> Message-ID: <1322918242.3603.16.camel@moonlight> Hi Michael, > Before any decisions are made on this issue you might look at the following > forum post. > > > > It is a long post. Just go to the end of it for the discussion which > started on Dec. 2nd. > > I think there is an overlap of activities. Cool, didn't know it. However, I don't see any discussion or activity (in terms of code, or something) there. It looks a bit like what our BufferedImageView does: it takes a BufferedImage and renders it in a (subclass of) JavaFX ImageView. It's a very small class that's basically a frontend to some JavaFX internal API to do the conversion. The SwingView then builds on this for it's rendering. Regards, Roman From neugens.limasoftware at gmail.com Sat Dec 3 05:18:21 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sat, 3 Dec 2011 14:18:21 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <4EDA1D67.2030505@jugs.org> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> <4EDA1D67.2030505@jugs.org> Message-ID: Il giorno 03/dic/2011, alle ore 14:00, Dr. Michael Paus ha scritto: > Before any decisions are made on this issue you might look at the following > forum post. > > > > It is a long post. Just go to the end of it for the discussion which started on Dec. 2nd. > > I think there is an overlap of activities. > > LG, Michael > Hi Micheal, I'm not sure where the overlap is, I think the code we submitted for review contains exactly what the original poster was asking (integration for BufferedImage in this case), or I'm misunderstanding your comment? Cheers, Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From mp at jugs.org Sat Dec 3 05:26:49 2011 From: mp at jugs.org (Dr. Michael Paus) Date: Sat, 03 Dec 2011 14:26:49 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <1322918242.3603.16.camel@moonlight> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> <4EDA1D67.2030505@jugs.org> <1322918242.3603.16.camel@moonlight> Message-ID: <4EDA2399.30602@jugs.org> I meant the work of Jasper Potts which Richard Bair mentioned in his post. "To be honest, it wasn't until just a couple weeks back at Devoxx that Jasper and I looked at each other and realized how stupid we were that we didn't think of providing a custom node in the javafx.embed.swing package that was capable of doing 2D graphics" Could this not be the basis of your SwingView? Am 03.12.2011 14:17, schrieb Roman Kennke: > Hi Michael, > >> Before any decisions are made on this issue you might look at the following >> forum post. >> >> >> >> It is a long post. Just go to the end of it for the discussion which >> started on Dec. 2nd. >> >> I think there is an overlap of activities. > Cool, didn't know it. However, I don't see any discussion or activity > (in terms of code, or something) there. > > It looks a bit like what our BufferedImageView does: it takes a > BufferedImage and renders it in a (subclass of) JavaFX ImageView. It's a > very small class that's basically a frontend to some JavaFX internal API > to do the conversion. > > The SwingView then builds on this for it's rendering. > > Regards, Roman > > -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From roman at kennke.org Sat Dec 3 05:34:02 2011 From: roman at kennke.org (Roman Kennke) Date: Sat, 03 Dec 2011 14:34:02 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <4EDA2399.30602@jugs.org> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> <4EDA1D67.2030505@jugs.org> <1322918242.3603.16.camel@moonlight> <4EDA2399.30602@jugs.org> Message-ID: <1322919242.3603.17.camel@moonlight> Hi, > I meant the work of Jasper Potts which Richard Bair mentioned in his post. > > "To be honest, it wasn't until just a couple weeks back at Devoxx that > Jasper and I looked at each other and realized how stupid we were that > we didn't think of providing a custom node in the javafx.embed.swing > package that was capable of doing 2D graphics" > > Could this not be the basis of your SwingView? Right. Is there any work done in this regard? If not, I guess that's more or less exactly what we did. Roman > > > Am 03.12.2011 14:17, schrieb Roman Kennke: > > Hi Michael, > > > >> Before any decisions are made on this issue you might look at the following > >> forum post. > >> > >> > >> > >> It is a long post. Just go to the end of it for the discussion which > >> started on Dec. 2nd. > >> > >> I think there is an overlap of activities. > > Cool, didn't know it. However, I don't see any discussion or activity > > (in terms of code, or something) there. > > > > It looks a bit like what our BufferedImageView does: it takes a > > BufferedImage and renders it in a (subclass of) JavaFX ImageView. It's a > > very small class that's basically a frontend to some JavaFX internal API > > to do the conversion. > > > > The SwingView then builds on this for it's rendering. > > > > Regards, Roman > > > > > > From roman at kennke.org Sat Dec 3 05:39:08 2011 From: roman at kennke.org (Roman Kennke) Date: Sat, 03 Dec 2011 14:39:08 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <4EDA2399.30602@jugs.org> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> <4EDA1D67.2030505@jugs.org> <1322918242.3603.16.camel@moonlight> <4EDA2399.30602@jugs.org> Message-ID: <1322919548.3603.19.camel@moonlight> Sorry I was probably stupid. From the link you sent it was not immediately obvious how to get to the discussion. This here should be it: https://forums.oracle.com/forums/message.jspa?messageID=10014892 Cheers, Roman Am Samstag, den 03.12.2011, 14:26 +0100 schrieb Dr. Michael Paus: > I meant the work of Jasper Potts which Richard Bair mentioned in his post. > > "To be honest, it wasn't until just a couple weeks back at Devoxx that > Jasper and I looked at each other and realized how stupid we were that > we didn't think of providing a custom node in the javafx.embed.swing > package that was capable of doing 2D graphics" > > Could this not be the basis of your SwingView? > > > Am 03.12.2011 14:17, schrieb Roman Kennke: > > Hi Michael, > > > >> Before any decisions are made on this issue you might look at the following > >> forum post. > >> > >> > >> > >> It is a long post. Just go to the end of it for the discussion which > >> started on Dec. 2nd. > >> > >> I think there is an overlap of activities. > > Cool, didn't know it. However, I don't see any discussion or activity > > (in terms of code, or something) there. > > > > It looks a bit like what our BufferedImageView does: it takes a > > BufferedImage and renders it in a (subclass of) JavaFX ImageView. It's a > > very small class that's basically a frontend to some JavaFX internal API > > to do the conversion. > > > > The SwingView then builds on this for it's rendering. > > > > Regards, Roman > > > > > > From mp at jugs.org Sat Dec 3 05:44:30 2011 From: mp at jugs.org (Dr. Michael Paus) Date: Sat, 03 Dec 2011 14:44:30 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <1322919242.3603.17.camel@moonlight> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> <4EDA1D67.2030505@jugs.org> <1322918242.3603.16.camel@moonlight> <4EDA2399.30602@jugs.org> <1322919242.3603.17.camel@moonlight> Message-ID: <4EDA27BE.5040002@jugs.org> I am not the right person to answer this question but Richard said that Jasper has been working on this for a week or so and from what I have read it sounds to me as if this could be a very efficient implementation. Am 03.12.2011 14:34, schrieb Roman Kennke: > Hi, > >> I meant the work of Jasper Potts which Richard Bair mentioned in his post. >> >> "To be honest, it wasn't until just a couple weeks back at Devoxx that >> Jasper and I looked at each other and realized how stupid we were that >> we didn't think of providing a custom node in the javafx.embed.swing >> package that was capable of doing 2D graphics" >> >> Could this not be the basis of your SwingView? > Right. Is there any work done in this regard? If not, I guess that's > more or less exactly what we did. > > Roman > > >> >> Am 03.12.2011 14:17, schrieb Roman Kennke: >>> Hi Michael, >>> >>>> Before any decisions are made on this issue you might look at the following >>>> forum post. >>>> >>>> >>>> >>>> It is a long post. Just go to the end of it for the discussion which >>>> started on Dec. 2nd. >>>> >>>> I think there is an overlap of activities. >>> Cool, didn't know it. However, I don't see any discussion or activity >>> (in terms of code, or something) there. >>> >>> It looks a bit like what our BufferedImageView does: it takes a >>> BufferedImage and renders it in a (subclass of) JavaFX ImageView. It's a >>> very small class that's basically a frontend to some JavaFX internal API >>> to do the conversion. >>> >>> The SwingView then builds on this for it's rendering. >>> >>> Regards, Roman >>> >>> >> > -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From roman at kennke.org Sat Dec 3 05:49:26 2011 From: roman at kennke.org (Roman Kennke) Date: Sat, 03 Dec 2011 14:49:26 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <4EDA27BE.5040002@jugs.org> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> <4EDA1D67.2030505@jugs.org> <1322918242.3603.16.camel@moonlight> <4EDA2399.30602@jugs.org> <1322919242.3603.17.camel@moonlight> <4EDA27BE.5040002@jugs.org> Message-ID: <1322920166.3603.21.camel@moonlight> > I am not the right person to answer this question but Richard said that > Jasper has been working > on this for a week or so and from what I have read it sounds to me as if > this could be a very > efficient implementation. Yep. This is basically what I have been looking for when I did the SwingView :-) So either we wait until this new stuff hits a release (it'll not be in the controls repo I suppose) or we go with what we submitted and improve it once this Graphics2D-Node is available. Cheers, Roman From roman at kennke.org Sat Dec 3 05:57:25 2011 From: roman at kennke.org (Roman Kennke) Date: Sat, 03 Dec 2011 14:57:25 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <4EDA27BE.5040002@jugs.org> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> <4EDA1D67.2030505@jugs.org> <1322918242.3603.16.camel@moonlight> <4EDA2399.30602@jugs.org> <1322919242.3603.17.camel@moonlight> <4EDA27BE.5040002@jugs.org> Message-ID: <1322920645.3603.25.camel@moonlight> > I am not the right person to answer this question but Richard said that > Jasper has been working > on this for a week or so and from what I have read it sounds to me as if > this could be a very > efficient implementation. It's not clear from this thread if there's already work being done on this, or if they are only thinking about possible solutions. Notably: "But then we thought we were freaking idiots for not just doing a Canvas2D Node in the embed package that had normal AWT APIs. In the first instance it could be dumb and just do an image copy, and then get upgraded to do direct texture stuff (there is some additional complication there, notably, the splitting of the rendering and event threads, but anyway). In any case it should be more than fast enough. So that's kind of where we're at." The first part, i.e. image copy, is exactly what we do. We have a BufferedImageView, which renders BufferedImage in JavaFX, and we provide a Graphics2D which can paint on it. It's fairly dumb because we couldn't use or change any internals of JavaFX, but it works well, and it's not *that* slow. Now... if there's more than this already done in JavaFX @ Oracle, we can scrap this and use what's in JavaFX. On the other side, if this is not the case, our implementation could be used as starting point and improved over time. (We need the other parts of the JavaFX sources to help with this!) Roman From mp at jugs.org Sat Dec 3 06:01:46 2011 From: mp at jugs.org (Dr. Michael Paus) Date: Sat, 03 Dec 2011 15:01:46 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <1322920645.3603.25.camel@moonlight> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> <4EDA1D67.2030505@jugs.org> <1322918242.3603.16.camel@moonlight> <4EDA2399.30602@jugs.org> <1322919242.3603.17.camel@moonlight> <4EDA27BE.5040002@jugs.org> <1322920645.3603.25.camel@moonlight> Message-ID: <4EDA2BCA.5050203@jugs.org> Right - I just wanted to make you aware of this work so that you can somehow coordinate your activities. Am 03.12.2011 14:57, schrieb Roman Kennke: >> I am not the right person to answer this question but Richard said that >> Jasper has been working >> on this for a week or so and from what I have read it sounds to me as if >> this could be a very >> efficient implementation. > It's not clear from this thread if there's already work being done on > this, or if they are only thinking about possible solutions. Notably: > > "But then we thought we were freaking idiots for not just doing a > Canvas2D Node in the embed package that had normal AWT APIs. In the > first instance it could be dumb and just do an image copy, and then get > upgraded to do direct texture stuff (there is some additional > complication there, notably, the splitting of the rendering and event > threads, but anyway). In any case it should be more than fast enough. So > that's kind of where we're at." > > The first part, i.e. image copy, is exactly what we do. We have a > BufferedImageView, which renders BufferedImage in JavaFX, and we provide > a Graphics2D which can paint on it. It's fairly dumb because we couldn't > use or change any internals of JavaFX, but it works well, and it's not > *that* slow. > > Now... if there's more than this already done in JavaFX @ Oracle, we can > scrap this and use what's in JavaFX. On the other side, if this is not > the case, our implementation could be used as starting point and > improved over time. (We need the other parts of the JavaFX sources to > help with this!) > > Roman > > -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From kevin.rushforth at oracle.com Sat Dec 3 06:57:39 2011 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 03 Dec 2011 06:57:39 -0800 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <1322920645.3603.25.camel@moonlight> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> <4EDA1D67.2030505@jugs.org> <1322918242.3603.16.camel@moonlight> <4EDA2399.30602@jugs.org> <1322919242.3603.17.camel@moonlight> <4EDA27BE.5040002@jugs.org> <1322920645.3603.25.camel@moonlight> Message-ID: <4EDA38E3.2020703@oracle.com> From roman at kennke.org Sat Dec 3 07:20:52 2011 From: roman at kennke.org (Roman Kennke) Date: Sat, 03 Dec 2011 16:20:52 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <4EDA38E3.2020703@oracle.com> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> <4EDA1D67.2030505@jugs.org> <1322918242.3603.16.camel@moonlight> <4EDA2399.30602@jugs.org> <1322919242.3603.17.camel@moonlight> <4EDA27BE.5040002@jugs.org> <1322920645.3603.25.camel@moonlight> <4EDA38E3.2020703@oracle.com> Message-ID: <1322925652.3603.33.camel@moonlight> Hi Kevin, > As has been pointed out, anything like a Canvas2D or a SwingView will > need to be done in such a way that the core APIs have no > Java2D/Swing/AWT dependencies. Yep, I think I mentioned this ;-) What is considered core APIs and what is not? Is ui-controls core APIs? (If yes we can stop talking about SwingView until we get hands on some non-core API.) > In any case, until more of the platform is open it will be hard to > integrate this in a way that won't produce throw-away code, or have to > be refactored later. Yeah, that's what I was thinking. On the other hand, the throw-away code would mostly center around the painting which will need to be improved as soon as the platform provides us something better than the Image(View) that we use for now. There are lots of other things in the SwingView code that will stay (I guess) which is all of the event handling, ProxyWindowPeer and glue code. I'd think it'd be worth integrating what we have now (if we can, considering the first part of the email), maybe in a package name space that is not public, and focus on getting out the relevant pieces of remaining code and polishing up the things. (Guys, you want to do an open source project, don't just throw out code drops and do NIH fluff... ;-) ) Cheers, Roman > -- Kevin > > > Roman Kennke wrote: > > > I am not the right person to answer this question but Richard said that > > > Jasper has been working > > > on this for a week or so and from what I have read it sounds to me as if > > > this could be a very > > > efficient implementation. > > > > > > > It's not clear from this thread if there's already work being done on > > this, or if they are only thinking about possible solutions. Notably: > > > > "But then we thought we were freaking idiots for not just doing a > > Canvas2D Node in the embed package that had normal AWT APIs. In the > > first instance it could be dumb and just do an image copy, and then get > > upgraded to do direct texture stuff (there is some additional > > complication there, notably, the splitting of the rendering and event > > threads, but anyway). In any case it should be more than fast enough. So > > that's kind of where we're at." > > > > The first part, i.e. image copy, is exactly what we do. We have a > > BufferedImageView, which renders BufferedImage in JavaFX, and we provide > > a Graphics2D which can paint on it. It's fairly dumb because we couldn't > > use or change any internals of JavaFX, but it works well, and it's not > > *that* slow. > > > > Now... if there's more than this already done in JavaFX @ Oracle, we can > > scrap this and use what's in JavaFX. On the other side, if this is not > > the case, our implementation could be used as starting point and > > improved over time. (We need the other parts of the JavaFX sources to > > help with this!) > > > > Roman > > > > > > From neugens.limasoftware at gmail.com Sat Dec 3 08:04:42 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sat, 3 Dec 2011 17:04:42 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <1322925652.3603.33.camel@moonlight> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> <4EDA1D67.2030505@jugs.org> <1322918242.3603.16.camel@moonlight> <4EDA2399.30602@jugs.org> <1322919242.3603.17.camel@moonlight> <4EDA27BE.5040002@jugs.org> <1322920645.3603.25.camel@moonlight> <4EDA38E3.2020703@oracle.com> <1322925652.3603.33.camel@moonlight> Message-ID: Il giorno 03/dic/2011, alle ore 16:20, Roman Kennke ha scritto: > Hi Kevin, > >> As has been pointed out, anything like a Canvas2D or a SwingView will >> need to be done in such a way that the core APIs have no >> Java2D/Swing/AWT dependencies. > > Yep, I think I mentioned this ;-) What is considered core APIs and what > is not? Is ui-controls core APIs? (If yes we can stop talking about > SwingView until we get hands on some non-core API.) > >> In any case, until more of the platform is open it will be hard to >> integrate this in a way that won't produce throw-away code, or have to >> be refactored later. > > Yeah, that's what I was thinking. On the other hand, the throw-away code > would mostly center around the painting which will need to be improved > as soon as the platform provides us something better than the > Image(View) that we use for now. There are lots of other things in the > SwingView code that will stay (I guess) which is all of the event > handling, ProxyWindowPeer and glue code. I'd think it'd be worth > integrating what we have now (if we can, considering the first part of > the email), maybe in a package name space that is not public, and focus > on getting out the relevant pieces of remaining code and polishing up > the things. (Guys, you want to do an open source project, don't just > throw out code drops and do NIH fluff... ;-) ) > > Cheers, Roman > Hi Kevin, Roman, I didn't get the mail from Kevin for some reason (it appears blank on my mailer...), but for what I've extrapolated from the discussion it seems to me that the code can be integrated anyway, and even if not as is, it can serve as a good basis for your work, why duplicate code if you have already a working solution? As Roman said, the code may not be ready for prime time, but it's definitely a basis for future refinement. I'm personally quite excited about this opportunity and I'm looking forward to share my experiences (and confront them) with yours. Cheers, Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From kevin.rushforth at oracle.com Sat Dec 3 08:06:17 2011 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 03 Dec 2011 08:06:17 -0800 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <1322925652.3603.33.camel@moonlight> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> <4EDA1D67.2030505@jugs.org> <1322918242.3603.16.camel@moonlight> <4EDA2399.30602@jugs.org> <1322919242.3603.17.camel@moonlight> <4EDA27BE.5040002@jugs.org> <1322920645.3603.25.camel@moonlight> <4EDA38E3.2020703@oracle.com> <1322925652.3603.33.camel@moonlight> Message-ID: <4EDA48F9.9010908@oracle.com> >> , anything like a Canvas2D or a SwingView will >> need to be done in such a way that the core APIs have no >> Java2D/Swing/AWT dependencies. >> > > Yep, I think I mentioned this ;-) What is considered core APIs and what > is not? Is ui-controls core APIs? (If yes we can stop talking about > SwingView until we get hands on some non-core API.) > Yes, it is part of the base or core set, which includes the UI Controls, Scene Graph, animation, beans & collections & stuff. The main requirement is that we need to separate anything that references Java2D, etc., into it's own package name space and module. >> In any case, until more of the platform is open it will be hard to >> integrate this in a way that won't produce throw-away code, or have to >> be refactored later. >> > > Yeah, that's what I was thinking. On the other hand, the throw-away code > would mostly center around the painting which will need to be improved > as soon as the platform provides us something better than the > Image(View) that we use for now. There are lots of other things in the > SwingView code that will stay (I guess) which is all of the event > handling, ProxyWindowPeer and glue code. This might make sense as long as the implementation is something that could easily be swapped out later. > I'd think it'd be worth > integrating what we have now (if we can, considering the first part of > the email), maybe in a package name space that is not public, and focus > on getting out the relevant pieces of remaining code and polishing up > the things. And there's the rub. The javafx-ui-controls project cannot directly reference Java2D -- at least not in the long term, so it would probably be better not to start now, although to be honest, the javafx.embed.swing package is currently in the javafx-ui-common module, and the universe hasn't exploded as a result. :) It's just one more thing we'd have to move later, but if done carefully (e.g., by putting it in a separate non-public package first) it might not be too much trouble. > (Guys, you want to do an open source project, don't just > throw out code drops and do NIH fluff... ;-) ) > Certainly. We're heading that direction, but as Brian pointed out, it will take some time. Also we don't want to add new features too quickly at the expense of, say, modularity or platform stability. Also, in general I would want to be careful putting something in javafx-ui-controls just because it's there. If the right place for it is something that is currently in the closed source, then that's an indicator of something that should probably wait. Anyway, I don't want to throw a wet blanket on this, since solving this problem is worth doing. -- Kevin From kevin.rushforth at oracle.com Sat Dec 3 08:10:02 2011 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 03 Dec 2011 08:10:02 -0800 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> <4EDA1D67.2030505@jugs.org> <1322918242.3603.16.camel@moonlight> <4EDA2399.30602@jugs.org> <1322919242.3603.17.camel@moonlight> <4EDA27BE.5040002@jugs.org> <1322920645.3603.25.camel@moonlight> <4EDA38E3.2020703@oracle.com> <1322925652.3603.33.camel@moonlight> Message-ID: <4EDA49DA.9020401@oracle.com> > > I didn't get the mail from Kevin for some reason (it appears blank on > my mailer...) I think there is still something wrong with the mail server delivering e-mail that is sent in HTML only. I also got a blank message. I'll reconfigure to send out in text and HTML. -- Kevin From roman at kennke.org Sat Dec 3 08:19:51 2011 From: roman at kennke.org (Roman Kennke) Date: Sat, 03 Dec 2011 17:19:51 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <4EDA48F9.9010908@oracle.com> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> <4EDA1D67.2030505@jugs.org> <1322918242.3603.16.camel@moonlight> <4EDA2399.30602@jugs.org> <1322919242.3603.17.camel@moonlight> <4EDA27BE.5040002@jugs.org> <1322920645.3603.25.camel@moonlight> <4EDA38E3.2020703@oracle.com> <1322925652.3603.33.camel@moonlight> <4EDA48F9.9010908@oracle.com> Message-ID: <1322929191.2698.3.camel@moonlight> Hi Kevin, > Also, in general I would want to be careful putting something in > javafx-ui-controls just because it's there. If the right place for it > is something that is currently in the closed source, then that's an > indicator of something that should probably wait. Absolutely. It's not like the code doesn't exist or cannot be worked on only because it's not in JavaFX ;-) If the right place for this is not open yet (because it references Java2D and AWT/Swing) then let's wait. I'd be happy if you take a look anyway, maybe you can find something cool to improve in the meantime. Also, if the Canvas2D becomes available, let us know :-) Cheers, Roman From kevin.rushforth at oracle.com Sat Dec 3 08:37:37 2011 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 03 Dec 2011 08:37:37 -0800 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <1322929191.2698.3.camel@moonlight> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> <4EDA1D67.2030505@jugs.org> <1322918242.3603.16.camel@moonlight> <4EDA2399.30602@jugs.org> <1322919242.3603.17.camel@moonlight> <4EDA27BE.5040002@jugs.org> <1322920645.3603.25.camel@moonlight> <4EDA38E3.2020703@oracle.com> <1322925652.3603.33.camel@moonlight> <4EDA48F9.9010908@oracle.com> <1322929191.2698.3.camel@moonlight> Message-ID: <4EDA5051.1070503@oracle.com> Sounds good. I will be traveling for a while so won't be as responsive over the next week or so. Maybe one of the controls guys can take a look. -- Kevin Roman Kennke wrote: > Hi Kevin, > > >> Also, in general I would want to be careful putting something in >> javafx-ui-controls just because it's there. If the right place for it >> is something that is currently in the closed source, then that's an >> indicator of something that should probably wait. >> > > Absolutely. It's not like the code doesn't exist or cannot be worked on > only because it's not in JavaFX ;-) If the right place for this is not > open yet (because it references Java2D and AWT/Swing) then let's wait. > I'd be happy if you take a look anyway, maybe you can find something > cool to improve in the meantime. Also, if the Canvas2D becomes > available, let us know :-) > > Cheers, Roman > > From kevin.rushforth at oracle.com Sat Dec 3 08:50:35 2011 From: kevin.rushforth at oracle.com (kevin.rushforth at oracle.com) Date: Sat, 03 Dec 2011 16:50:35 +0000 Subject: hg: openjfx/2.1/master/rt: 27 new changesets Message-ID: <20111203165040.B55FE47552@hg.openjdk.java.net> Changeset: 0513410ad497 Author: leifs Date: 2011-11-29 19:25 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/0513410ad497 Fixed RT-17640: [CheckBox] TextWrap algorithm enhancement Fixed RT-17644: [CheckBox] TextWrap don't work, when graphicTextGap is big ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CheckBoxSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/RadioButtonSkin.java Changeset: ed91b7a303d9 Author: leifs Date: 2011-11-29 19:25 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/ed91b7a303d9 Fixed RT-17107: Bad stop in ladder spec of caspian.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: 72189bd682fe Author: leifs Date: 2011-11-30 00:54 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/72189bd682fe Fixed a minor regression in the fix for RT-17640, and temporarily disabled some tests in LabelSkinTest which assume that Label.minWidth(-1) doesn't include padding. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/Utils.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabelSkinTest.java Changeset: 2dd082b14d62 Author: Greg Brown Date: 2011-11-30 11:33 -0500 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/2dd082b14d62 Add @DefaultProperty annotations (RT-14879). ! javafx-ui-controls/src/javafx/scene/control/Labeled.java ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/Menu.java ! javafx-ui-controls/src/javafx/scene/control/MenuBar.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TextInputControl.java ! javafx-ui-controls/src/javafx/scene/control/TitledPane.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java Changeset: 87f489a5e00a Author: snorthov Date: 2011-11-30 15:57 -0500 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/87f489a5e00a fix .classpath + .classpath + .project Changeset: 5ed2ae1b35be Author: Jonathan Giles Date: 2011-11-30 08:48 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/5ed2ae1b35be RT-18259: [Non-Editable ComboBox] UP and DOWN keys should change items in the ComboBox ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ComboBoxBaseBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ComboBoxListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxBaseSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java Changeset: 628587bfd5e8 Author: Jonathan Giles Date: 2011-11-30 11:48 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/628587bfd5e8 RT-18242: Focus should take precedence over selection ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: c6375310e143 Author: Jonathan Giles Date: 2011-12-01 07:58 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/c6375310e143 RT-18304: ComboBox hide issues ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: b8d5a05a415b Author: Jonathan Giles Date: 2011-12-01 08:01 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/b8d5a05a415b 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 Changeset: 1136e747223c Author: Paru Somashekar Date: 2011-11-30 16:38 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/1136e747223c added copyright header to UAStylesheetLoader & made it a package private class. ! javafx-ui-controls/src/javafx/scene/control/UAStylesheetLoader.java Changeset: ad9c4f1b10f6 Author: Jonathan Giles Date: 2011-12-01 08:57 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/ad9c4f1b10f6 RT-18275: [ComboBox] When list is empty, thin line of shadow is visible. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 349ecca8c8da Author: Jonathan Giles Date: 2011-12-01 09:42 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/349ecca8c8da RT-18278: [ComboBox] Initial size and size after making empty are not equal. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ListViewSkin.java Changeset: b13ea35c580f Author: Jonathan Giles Date: 2011-12-01 10:12 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/b13ea35c580f RT-18306: NPE in TreeView FocusModel ! javafx-ui-controls/src/javafx/scene/control/TreeView.java Changeset: 581183c6c16a Author: Jonathan Giles Date: 2011-12-01 10:21 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/581183c6c16a RT-18290: TreeView: consumes a MOUSE_DRAGGED event (b24) ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java Changeset: bafb77d6c156 Author: Jonathan Giles Date: 2011-12-01 10:31 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/bafb77d6c156 RT-18273: getTableRow returns null on first calls with custom cell renderers ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkin.java Changeset: 35f9a4405120 Author: Jonathan Giles Date: 2011-12-01 11:21 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/35f9a4405120 RT-18280: [ComboBox] Dynamic element adding shifts index of currently selected element and changes it in combo box. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 31fb596f444a Author: Jonathan Giles Date: 2011-12-01 12:59 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/31fb596f444a Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.1/scrum/controls/jfx/rt Changeset: 6cbfd718d28f Author: snorthov Date: 2011-12-01 11:33 -0500 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/6cbfd718d28f RT-15275: Use platforms context menu detect event to show ContextMenu instead of MouseRelease event. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableHeaderRow.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java Changeset: 3ae65a0b9d75 Author: leifs Date: 2011-12-01 10:58 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/3ae65a0b9d75 [TEST ONLY] Re-enabled tests for minWidth in LabelSkinTest ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabelSkinTest.java Changeset: 307a9edf9422 Author: leifs Date: 2011-12-01 13:20 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/307a9edf9422 [TEST ONLY] Re-enabled remaining tests in LabelSkinTest ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabelSkinTest.java Changeset: bce68e5011e0 Author: snorthov Date: 2011-12-01 17:10 -0500 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/bce68e5011e0 perform an action only if the menu was not shown ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java Changeset: 287a106f0d6d Author: snorthov Date: 2011-12-01 17:14 -0500 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/287a106f0d6d fix dumb null pointer ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java Changeset: 2becf153e10c Author: snorthov Date: 2011-12-01 17:21 -0500 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/2becf153e10c need to check both showing and popup trigger to aviod the button release action ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java Changeset: 5ad9a8a11d2b Author: Jonathan Giles Date: 2011-12-02 08:27 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/5ad9a8a11d2b RT-15529: TableView does not allow selection in empty cells, even in row-selection mode ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/javafx/scene/control/Cell.java ! javafx-ui-controls/src/javafx/scene/control/TableCell.java Changeset: 963d7c07346e Author: Jonathan Giles Date: 2011-12-02 17:50 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/963d7c07346e RT-18331: Investigate performance drop in Controls.TableView-MoveRows and Controls.TableView-Sort in fx2.1-b02 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java ! javafx-ui-controls/src/javafx/scene/control/IndexedCell.java ! javafx-ui-controls/src/javafx/scene/control/ListCell.java ! javafx-ui-controls/src/javafx/scene/control/TableCell.java ! javafx-ui-controls/src/javafx/scene/control/TableRow.java ! javafx-ui-controls/test/javafx/scene/control/CellTest.java Changeset: c4437d337bad Author: Jonathan Giles Date: 2011-12-02 17:51 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/c4437d337bad Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.1/scrum/controls/jfx/rt Changeset: e69ac8c4bab6 Author: mickf Date: 2011-12-02 14:28 +0000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/e69ac8c4bab6 RT-17890 : ScrollPane steals MouseClicked from parent ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ScrollPaneSkinTest.java From richard.bair at oracle.com Sat Dec 3 09:07:17 2011 From: richard.bair at oracle.com (Richard Bair) Date: Sat, 3 Dec 2011 09:07:17 -0800 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <1322913000.3603.13.camel@moonlight> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> Message-ID: <4680EC6D-9040-49C1-B785-C3D90522A9CE@oracle.com> On Dec 3, 2011, at 3:50 AM, Roman Kennke wrote: > Hi Jonathan, > >> With regards as to whether the SwingView feature you've developed is >> considered a control or not: my unofficial means of classifying would >> say that unless it extends from, or somehow makes use of the >> javafx.scene.control.Control class, it is not a control. If this isn't >> the case (I haven't looked myself, but my guess is that it isn't), >> then I'd say that this feature is not destined to be included in the >> ui-controls project. Of course, it isn't my place to say this with any >> conviction, I'm just saying what my interpretation is. > > The SwingView is a subclass of control. However, I still don't feel it > should go side by side with the other controls, since it's not a > 'regular' control like button, labels, combobox, etc. It could still be > part of the ui-controls, just maybe in a different package. I think it would go in the embed.swing package, for the reason outlined (modularity and not depending on AWT). I think it is ok to have swing specific nodes, controls, etc in javafx.embed.swing. Richard From kevin.rushforth at oracle.com Sat Dec 3 09:09:39 2011 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 03 Dec 2011 09:09:39 -0800 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <4680EC6D-9040-49C1-B785-C3D90522A9CE@oracle.com> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> <4680EC6D-9040-49C1-B785-C3D90522A9CE@oracle.com> Message-ID: <4EDA57D3.7020809@oracle.com> Richard Bair wrote: > >> The SwingView is a subclass of control. However, I still don't feel it >> should go side by side with the other controls, since it's not a >> 'regular' control like button, labels, combobox, etc. It could still be >> part of the ui-controls, just maybe in a different package. >> > > I think it would go in the embed.swing package, for the reason outlined (modularity and not depending on AWT). I think it is ok to have swing specific nodes, controls, etc in javafx.embed.swing. > Makes sense to me, too. -- Kevin From richard.bair at oracle.com Sat Dec 3 09:14:56 2011 From: richard.bair at oracle.com (Richard Bair) Date: Sat, 3 Dec 2011 09:14:56 -0800 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: <1322929191.2698.3.camel@moonlight> References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> <4EDA1D67.2030505@jugs.org> <1322918242.3603.16.camel@moonlight> <4EDA2399.30602@jugs.org> <1322919242.3603.17.camel@moonlight> <4EDA27BE.5040002@jugs.org> <1322920645.3603.25.camel@moonlight> <4EDA38E3.2020703@oracle.com> <1322925652.3603.33.camel@moonlight> <4EDA48F9.9010908@oracle.com> <1322929191.2698.3.camel@moonlight> Message-ID: Hey this is great stuff, I'm definitely eager to get our first OS contributions and work through the process. There are some things around testing & QA we will have to work through (any public API will need QA testing and such, which requires coordination and buy-in from that team). However I think there is no theoretical problem with putting this code in some form into javafx.embed.swing. Artem is the guy who owns this portion of the code, so either he or one of the Swing / AWT guys will probably be the primary point of contact for code reviews. I'll take a look again on Monday and follow up with Jasper. On Dec 3, 2011, at 8:19 AM, Roman Kennke wrote: > Hi Kevin, > >> Also, in general I would want to be careful putting something in >> javafx-ui-controls just because it's there. If the right place for it >> is something that is currently in the closed source, then that's an >> indicator of something that should probably wait. > > Absolutely. It's not like the code doesn't exist or cannot be worked on > only because it's not in JavaFX ;-) If the right place for this is not > open yet (because it references Java2D and AWT/Swing) then let's wait. > I'd be happy if you take a look anyway, maybe you can find something > cool to improve in the meantime. Also, if the Canvas2D becomes > available, let us know :-) > > Cheers, Roman > From neugens.limasoftware at gmail.com Sat Dec 3 10:15:01 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sat, 3 Dec 2011 19:15:01 +0100 Subject: Source code for JavaFX UI controls now available on openjfx In-Reply-To: References: <4ED95442.5070403@oracle.com> <1322901737.3603.5.camel@moonlight> <8D57DE70-31B9-49F7-87C4-3510B5F39EC5@gmail.com> <4ED9F4C9.4000108@oracle.com> <1322913000.3603.13.camel@moonlight> <4EDA1D67.2030505@jugs.org> <1322918242.3603.16.camel@moonlight> <4EDA2399.30602@jugs.org> <1322919242.3603.17.camel@moonlight> <4EDA27BE.5040002@jugs.org> <1322920645.3603.25.camel@moonlight> <4EDA38E3.2020703@oracle.com> <1322925652.3603.33.camel@moonlight> <4EDA48F9.9010908@oracle.com> <1322929191.2698.3.camel@moonlight> Message-ID: Il giorno 03/dic/2011, alle ore 18:14, Richard Bair ha scritto: > Hey this is great stuff, I'm definitely eager to get our first OS contributions and work through the process. There are some things around testing & QA we will have to work through (any public API will need QA testing and such, which requires coordination and buy-in from that team). However I think there is no theoretical problem with putting this code in some form into javafx.embed.swing. > > Artem is the guy who owns this portion of the code, so either he or one of the Swing / AWT guys will probably be the primary point of contact for code reviews. > > I'll take a look again on Monday and follow up with Jasper. Hi Richard, Thanks a lot! We will surely add all the needed tests and the likes. I'm waiting forward to Monday to get the first impressions! :) Cheers, Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From kevin.rushforth at oracle.com Tue Dec 6 02:31:41 2011 From: kevin.rushforth at oracle.com (kevin.rushforth at oracle.com) Date: Tue, 06 Dec 2011 10:31:41 +0000 Subject: hg: openjfx/2.1/master: Update README file to make it easier to find the rt repo Message-ID: <20111206103141.5FD9447594@hg.openjdk.java.net> Changeset: 67f9658dfd32 Author: kcr Date: 2011-12-06 08:30 -0200 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rev/67f9658dfd32 Update README file to make it easier to find the rt repo ! README From kevin.rushforth at oracle.com Tue Dec 6 02:34:17 2011 From: kevin.rushforth at oracle.com (kevin.rushforth at oracle.com) Date: Tue, 06 Dec 2011 10:34:17 +0000 Subject: hg: openjfx/2.1/master/rt: 2 new changesets Message-ID: <20111206103417.EC75C47595@hg.openjdk.java.net> Changeset: ad7c7e6580a3 Author: leifs Date: 2011-12-05 12:20 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/ad7c7e6580a3 Fixed RT-17316: TextField does not support TextInputControl styles including psuedo-class of 'readonly' and 'editable' ! javafx-ui-controls/src/javafx/scene/control/TextInputControl.java Changeset: 2b29532ca4c9 Author: leifs Date: 2011-12-05 12:55 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/2b29532ca4c9 Fixed: RT-17895, RT-17896, RT-17897 [Cmd-][Shift-]Home/End does not work as expected (Mac) ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java From zonski at googlemail.com Sat Dec 3 17:06:43 2011 From: zonski at googlemail.com (Daniel Zwolenski) Date: Sun, 4 Dec 2011 12:06:43 +1100 Subject: Possible additions to JavaFX to facilitate forms and validations Message-ID: Hi, This is my first post to this mailing list so please let me know if I do anything wrong or am posting in the wrong way or place. I have been exploring the options for a 'form' framework built in JavaFX and there is a forum post with detail here: https://forums.oracle.com/forums/thread.jspa?threadID=2316760&tstart=0 In my opinion it is too early to include this form stuff in JavaFX as it needs to be put through its paces in some real world situations first. It works well as an open source library for now that can provide a reference implementation for possible later inclusion. There are however two core enhancements that I would like to see in the base JavaFX API that will simplify this form framework and also help out in other areas. Here are the two proposals: *1. Node annotations* Extend the base Node class to include the concept of Node 'annotations' (i.e. visual markers on a Node, nothing to do with Java code annotations), where each Node can have arbitrary Nodes placed on top of them. In a form framework this would be used to add 'error icons' onto fields, but this same feature could be used to implement things like a 'help' icon that links to context sensitive help, or an 'arrow pointer' (e.g. for scripted walk-throughs of a UI) or 'fluro highlight' (e.g. for searching and highlighting on a screen), etc. I'm sure developers would find many other useful ways to use this feature. I would see each Node having an 'anchor' constraint of type javafx.geometry.Pos which defines where the annotation should be layed out relative to the Node's bounds. The annotations should probably not affect the bounds, etc, and they should have a z-order that draws them above regular Nodes. They could also have x, y offset constraints, or the existing translateX/Y features could be used for this. For reference, I have a crude version of this using a StackPane: http://code.google.com/p/jfxee/source/browse/trunk/jfxforms/src/main/java/com/zenjava/jfxforms/framework/AnnotatedNode.java But it would be much cleaner if it was part of the core API rather than built ontop of it. Unfortunately 'Node' is not a 'control' so it is not yet open sourced, so I can't submit a patch, but I would be happy to work with anyone on the JFX team to achieve this feature if it helps. *2. Control Value Properties * Currently the Controls API is very type specific when accessing the 'value' of a control. So the 'value' for a TextField is its 'textProperty', whereas for a CheckBox it is its 'selectedProperty' and for a ChoiceBox it is it's selectionModel's 'selectedItem', etc. It would be useful if the value concept was more generic and we then had a generic way to interact with the 'value' of all Controls. Having a generic 'value' property would make it a lot easier to detect when a value has changed (which is important for form validation) as we could avoid a whole lot of if-then-else listener logic. I think this 'value' property would also simplify binding to fields, where a property can just be bound to the value of a property and not care whether that field is a CheckBox or a ComboBox so long as the 'value' is of the right type. Combined with some reflection, developers could probably create more generic binders between beans and fields, possibly facilitating cleaner PresentationModel patterns, etc. I'd like to propose the addition of an interface along the lines of: interface HasValue { ValueType getValue(); void setValue(ValueType value); Property valueProperty(); } Which would then be implemented by every Control that has the concept of a 'value' to map their specific value (e.g. the textProperty in a TextField) to a generic Property instance. As a point of reference, a crude helper class (providing read-only access currently) is here: http://code.google.com/p/jfxee/source/browse/trunk/jfxforms/src/main/java/com/zenjava/jfxforms/framework/ValueHelper.java For ListView and TableView I would see the current selected 'row' as the value. Multi-selection has some additional challenges here, and I would be interested in other thoughts on this. One option is that these controls use List as their ValueType, another (and probably my preference) is that there is a separate interface called 'HasValues' for binding to multi-selection value controls, while still allowing simple binding to single-selection values. If there is interest in this idea then I would put forward to this forum a list of controls and propose what the 'value' for that control would be and then look for comments, feedback on this list. The code changes for this should all be contained to the 'controls' package so if there is general approval for this idea, I am willing to look at submitting some possible patches to implement this for review (once we have a way to actually build the code), though I would be looking for some input and support on some areas from you guys. Cheers, zonski From richard.bair at oracle.com Tue Dec 6 08:14:45 2011 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Dec 2011 08:14:45 -0800 Subject: Possible additions to JavaFX to facilitate forms and validations In-Reply-To: References: Message-ID: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> Hi Dan, Probably we should split these two suggestions into different threads so we can keep track of tionthem better. > *1. Node annotations* A couple issues here to think about. First, how would the "annotation" be associated with the node? Since Nodes have no children (Parents do) it wouldn't be a child, in the scene graph sense, but it would be in how it is defined in paint order. That is, you want it to paint last. The picking code and such would need to be updated. Is the annotation outside the clip, if one exists on the node? Does it contribute to the bounds of the Node? If so we might have a contradiction to work through (the definition for boundsInLocal and boundsInParent would need massaging). Also I think for the use case you also will want annotations that can be beneath the Node. Personally I'm not sure it makes sense to add this to every node. I imagine if there was some built in support on Control, plus some decorator pattern for other nodes, it will probably do the job without complicating the Node semantics. What do you think? > *2. Control Value Properties * Oh, I just had a crazy idea. What if we just reused WritableValue? Have value holding controls implement WritableValue. Hmmm. Richard From roman at kennke.org Tue Dec 6 08:34:09 2011 From: roman at kennke.org (Roman Kennke) Date: Tue, 06 Dec 2011 17:34:09 +0100 Subject: Possible additions to JavaFX to facilitate forms and validations In-Reply-To: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> Message-ID: <1323189249.2752.19.camel@moonlight> Hi there, First of all, let me say I like the idea. Seems like a useful addition to JFX. > > *1. Node annotations* > > A couple issues here to think about. First, how would the "annotation" be associated with the node? Since Nodes have no children (Parents do) it wouldn't be a child, in the scene graph sense, but it would be in how it is defined in paint order. That is, you want it to paint last. The picking code and such would need to be updated. Is the annotation outside the clip, if one exists on the node? Does it contribute to the bounds of the Node? If so we might have a contradiction to work through (the definition for boundsInLocal and boundsInParent would need massaging). Also I think for the use case you also will want annotations that can be beneath the Node. My feeling is that doing this in Control rather than Node is more natural. What would be the meaning/use case of an annotation on arbitrary nodes? Like lines, or geometric objects? Regards, Roman From tom.schindl at bestsolution.at Tue Dec 6 08:40:17 2011 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 06 Dec 2011 17:40:17 +0100 Subject: Possible additions to JavaFX to facilitate forms and validations In-Reply-To: <1323189249.2752.19.camel@moonlight> References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> <1323189249.2752.19.camel@moonlight> Message-ID: <4EDE4571.2060301@bestsolution.at> Am 06.12.11 17:34, schrieb Roman Kennke: > Hi there, > > First of all, let me say I like the idea. Seems like a useful addition > to JFX. > >>> *1. Node annotations* >> >> A couple issues here to think about. First, how would the "annotation" be associated with the node? Since Nodes have no children (Parents do) it wouldn't be a child, in the scene graph sense, but it would be in how it is defined in paint order. That is, you want it to paint last. The picking code and such would need to be updated. Is the annotation outside the clip, if one exists on the node? Does it contribute to the bounds of the Node? If so we might have a contradiction to work through (the definition for boundsInLocal and boundsInParent would need massaging). Also I think for the use case you also will want annotations that can be beneath the Node. > > My feeling is that doing this in Control rather than Node is more > natural. What would be the meaning/use case of an annotation on > arbitrary nodes? Like lines, or geometric objects? > > Regards, Roman > > I don't see this on any of those two (Node nor Control) but would say this is the job of a NodeDecorator which gets the Control and provides the possibility to decorate it. Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From tom.schindl at bestsolution.at Tue Dec 6 08:41:58 2011 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 06 Dec 2011 17:41:58 +0100 Subject: Possible additions to JavaFX to facilitate forms and validations In-Reply-To: <4EDE4571.2060301@bestsolution.at> References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> <1323189249.2752.19.camel@moonlight> <4EDE4571.2060301@bestsolution.at> Message-ID: <4EDE45D6.1040006@bestsolution.at> Am 06.12.11 17:40, schrieb Tom Schindl: > Am 06.12.11 17:34, schrieb Roman Kennke: >> Hi there, >> >> First of all, let me say I like the idea. Seems like a useful addition >> to JFX. >> >>>> *1. Node annotations* >>> >>> A couple issues here to think about. First, how would the "annotation" be associated with the node? Since Nodes have no children (Parents do) it wouldn't be a child, in the scene graph sense, but it would be in how it is defined in paint order. That is, you want it to paint last. The picking code and such would need to be updated. Is the annotation outside the clip, if one exists on the node? Does it contribute to the bounds of the Node? If so we might have a contradiction to work through (the definition for boundsInLocal and boundsInParent would need massaging). Also I think for the use case you also will want annotations that can be beneath the Node. >> >> My feeling is that doing this in Control rather than Node is more >> natural. What would be the meaning/use case of an annotation on >> arbitrary nodes? Like lines, or geometric objects? >> >> Regards, Roman >> >> > > I don't see this on any of those two (Node nor Control) but would say > this is the job of a NodeDecorator which gets the Control and provides which would better named ControlDecorator then :-) 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 neugens.limasoftware at gmail.com Tue Dec 6 08:56:44 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 6 Dec 2011 17:56:44 +0100 Subject: Node Annotation [was Re: Possible additions to JavaFX to facilitate forms and validations] In-Reply-To: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> Message-ID: <865DB77E-D442-44F8-82B9-F67E376DC3DE@gmail.com> Il giorno 06/dic/2011, alle ore 17:14, Richard Bair ha scritto: > Hi Dan, > > Probably we should split these two suggestions into different threads so we can keep track of tionthem better. > >> *1. Node annotations* > > A couple issues here to think about. First, how would the "annotation" be associated with the node? Since Nodes have no children (Parents do) it wouldn't be a child, in the scene graph sense, but it would be in how it is defined in paint order. That is, you want it to paint last. The picking code and such would need to be updated. Is the annotation outside the clip, if one exists on the node? Does it contribute to the bounds of the Node? If so we might have a contradiction to work through (the definition for boundsInLocal and boundsInParent would need massaging). Also I think for the use case you also will want annotations that can be beneath the Node. > > Personally I'm not sure it makes sense to add this to every node. I imagine if there was some built in support on Control, plus some decorator pattern for other nodes, it will probably do the job without complicating the Node semantics. What do you think? hi Richard, Daniel, Is nice to see this kind of discussion :) and I think the idea of an annotation is quite interesting. Speaking about the ideas, let's split the thread like you suggested, and let this be the Node Annotation thread :) For the same reason outlined by Richard, I feel that an annotated Node would introduce an unnecessary (and optional) payload to each and every Node, cluttering the API, but the same addition to the Control could instead be quite elegant. I wonder, though, if such thing cannot be simply done with a clever use of Groups, rather than introducing a specific API? After all, an annotation (in graphical terms) is nothing but a node/parent/control/group itself, in other words, this kind of functionality is implicit in the constructed scene graph hierarchy (you can annotate annotated groups, for example annotate an element with a preview of a html5 video both in form of annotated elements, annotate then again with a parental advisory sign or other disclaimers [1]), so the original proposal could be seen a way to make the process of creating such hierarchy smoother (rather than do this by hand all the time). Cheers, Mario [1] Ok, such UI would be very terrible :) but you get the point From knut.arne.vedaa at broadpark.no Tue Dec 6 08:57:22 2011 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Tue, 06 Dec 2011 17:57:22 +0100 Subject: Possible additions to JavaFX to facilitate forms and validations In-Reply-To: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> Message-ID: <4EDE4972.8030205@broadpark.no> On 06.12.2011 17:14, Richard Bair wrote: > Oh, I just had a crazy idea. What if we just reused WritableValue? Have value holding controls implement WritableValue. Hmmm. That's not so crazy. Actually, I proposed it in the forum thread. :) (Ok, I proposed ObservableValue.) There's a set of interfaces that may be considered for this. The simplest would be Observable. That gives you add/remove listener. Since these are not parameterized, you could have a List and call them on each item. Next up is ObservableValue/WritableValue, which gives you getValue/+setValue. Since these are parameterized, you won't be able to iterate through a List> and use them on each item without casting; could be useful still. Lastly, Property, which gives you the binding methods as well. In that case, i.e. class Control implements Property, the control would *be* the property for the value it holds, i.e. instead of textField.textProperty.bind(someObservable) you could do textField.bind(someObservable). The actual methods could just could be proxies to the control-specific value property. (This is what would be compatible with zonski's original proposal.) I'm not sure how much it gives though, since most controls will hold different datatypes so you can't really abstract over them. Just some quick thoughts. Knut Arne From richard.bair at oracle.com Tue Dec 6 09:02:46 2011 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Dec 2011 09:02:46 -0800 Subject: Controls with Values [was Possible additions to JavaFX to facilitate forms and validations] In-Reply-To: <4EDE4972.8030205@broadpark.no> References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> <4EDE4972.8030205@broadpark.no> Message-ID: <67E8E7BD-24DB-4242-81FD-6C35389A7699@oracle.com> > > Oh, I just had a crazy idea. What if we just reused WritableValue? Have value holding controls implement WritableValue. Hmmm. > > That's not so crazy. Actually, I proposed it in the forum thread. :) (Ok, I proposed ObservableValue.) Oh, you probably gave the idea to me sub-consciously :-) > There's a set of interfaces that may be considered for this. > > The simplest would be Observable. That gives you add/remove listener. Since these are not parameterized, you could have a List and call them on each item. > > Next up is ObservableValue/WritableValue, which gives you getValue/+setValue. > > Since these are parameterized, you won't be able to iterate through a List> and use them on each item without casting; could be useful still. > > Lastly, Property, which gives you the binding methods as well. > > In that case, i.e. class Control implements Property, the control would *be* the property for the value it holds, i.e. instead of textField.textProperty.bind(someObservable) you could do textField.bind(someObservable). The actual methods could just could be proxies to the control-specific value property. > > (This is what would be compatible with zonski's original proposal.) > > I'm not sure how much it gives though, since most controls will hold different datatypes so you can't really abstract over them. > > Just some quick thoughts. From a naming perspective, the idea that TextField would implement property seems wrong, although the idea of binding a TextField to something directly seems great (we had similar API in SwingLabs back in the day for a set of data-aware components I was experimenting with). It takes thinking of a Control a little differently -- in addition to being a thing with a bunch of state, it is also, fundamentally, used for displaying and editing a value. It still wouldn't be what we would call a "Property" in the meaning of the word, but the Property interface does express the API that could be useful in this context. Hmmm. Richard From richard.bair at oracle.com Tue Dec 6 10:28:34 2011 From: richard.bair at oracle.com (richard.bair at oracle.com) Date: Tue, 06 Dec 2011 18:28:34 +0000 Subject: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls. Actually they are probably not ALL needed, but they don't hurt. We need to clean these things all up as part of the open sourcing process, since the mechanism by which we download and install the necessary libs are probably going to be different than what we have been doing up to this point. Message-ID: <20111206182834.BE46A475A5@hg.openjdk.java.net> Changeset: 8d968b638b49 Author: rbair Date: 2011-12-06 09:28 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rev/8d968b638b49 Added build scripts that are needed for building UI controls. Actually they are probably not ALL needed, but they don't hurt. We need to clean these things all up as part of the open sourcing process, since the mechanism by which we download and install the necessary libs are probably going to be different than what we have been doing up to this point. + build-defs.xml + build-src/build-cache.xml + build-src/build-component-template.xml + build-src/build-components.xml + build-src/build-copy.xml + build-src/build-environment.xml + build-src/build-importer.xml + build-src/build-inventory.xml + build-src/build-invoice.xml + build-src/build-jar-importer.xml + build-src/build-linux-defs.xml + build-src/build-macosx-defs.xml + build-src/build-os-arch.xml + build-src/build-perf.xml + build-src/build-sdk-rt.xml + build-src/build-solaris-defs.xml + build-src/build-windows-defs.xml + build-src/build-zips.xml + build-src/genVSproperties.bat + build-src/startup2_template.html From richard.bair at oracle.com Tue Dec 6 09:46:32 2011 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Dec 2011 09:46:32 -0800 Subject: Attempting to Build [ was Source code for JavaFX UI controls now available on openjfx] In-Reply-To: <2F7DEE03-9940-4820-9CBE-7883FF86C20D@oracle.com> References: <4ED95442.5070403@oracle.com> <651B13B4-A077-45E0-856F-60CBEFFA13D4@gmail.com> <3256D7C0-3DC1-44A8-8F78-592050C2B0F4@gmail.com> <4ED96727.1040502@oracle.com> <2F7DEE03-9940-4820-9CBE-7883FF86C20D@oracle.com> Message-ID: If you got to Oracle.com and download JavaFX and find the tiny link that switches to the Mac Developer Preview download and grab it, you will get a very recent 2.1 build. This can be used as the binary plug for building. Unfortunately, some build files are missing in the master/ repo. I tried to push these files in, but the server is not happy with my ssl configuration. I'm trying to track that down. With those build files put in, there is one other slight modification to master/rt/build-defs.xml, but this will then allow you to actually build the controls repo and, if you are on Mac, run it. I'll keep you all abreast of the work, hopefully we'll have something fully buildable a little later today. Richard On Dec 2, 2011, at 5:43 PM, Richard Bair wrote: >> Sorry I misunderstood, I was expecting something similar to the binary plugs we had in OpenJDK, not a full version of the current release, hence the question. >> >> I was able to import the project successfully into eclipse (and netbeans) with the FX runtime and it seems to compile fine. > > Oh, that's interesting. I grabbed the latest 2.0.2 code for Mac that I had available but it was failing on: > > [javac] /Developer/Projects/openjfx/workspace-2.1/master/rt/javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ButtonBehavior.java:42: cannot find symbol > [javac] symbol : class PlatformUtil > [javac] location: package com.sun.javafx > [javac] import com.sun.javafx.PlatformUtil; > [javac] ^ > > And a bunch of other such failures. So I thought PlatformUtil had been removed between the 2.0.2 code I had (from early November) and the newer code in the 2.1 tree. If you got it to build in Eclipse on an older release -- well that is interesting! What version of JavaFX are you using for the binary plug? > > Do you want to post some basic instructions so other folks can do likewise? > >> I'll play with this code a bit and see how we can help out until everything else is sorted out. >> >> I think that while this is a suboptimal situation (but hey, we Free Software freaks are never happy, right? :) is still a great step forward, and we have a chance to study the code and the internals before everything gets released. >> >> Speaking about this, do you think we can have some "specs" about the internal interfaces? > > Probably in the short term asking me questions is the fastest way to get answers, unfortunately. I do need to be badgered to write up some documents though and put them up on our pages. Please do feel free to badger me: squeaky wheel and all that :-) > >> I know from JavaOne that the internal code is pretty abstracted and modular, and can actually be "easily" replaced (not sure the exact definition of easily though, but what you have shown at J1 was very impressive). >> >> We can probably help speeding up things if we know what things should be replaced and implement some clear room version of what will come later in the game, in a similar way we did with the Pisces renderer in Java2D, what do you think? >> >> I'm specifically thinking about the Linux port here, since to be honest "late 2012" is eons away. > > What we have released so far is the controls portion, which all sits above the "toolkit implementation" line. Basically on the "top" we've got controls, scene graph, css, properties, binding, collections, services, and that sort of thing. There is a Toolkit interface (com.sun.javafx.tk.Toolkit) which defines the abstraction between the public API portions of the platform and the underlying toolkit implementation (threading, windowing, opengl, d3d, fonts, etc). > > Likely it will be a couple months before we start putting out the lower-level bits en masse, due to having to be careful there over 3rd party code etc (there isn't much, mostly fonts and some SVG, but we have to do all the due diligence). The other problem is the same guys who have to do that, have to get the Mac port finished (both for Java 7 and for Java FX). However I will follow up with the guys doing linux and see if we can get that out sooner (they're busy working away on it and it would be cool to get it open faster, but at the very least get it included in the bits so you can run on linux). > > Cheers > Richard From richard.bair at oracle.com Tue Dec 6 10:52:52 2011 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Dec 2011 10:52:52 -0800 Subject: Attempting to Build [ was Source code for JavaFX UI controls now available on openjfx] In-Reply-To: References: <4ED95442.5070403@oracle.com> <651B13B4-A077-45E0-856F-60CBEFFA13D4@gmail.com> <3256D7C0-3DC1-44A8-8F78-592050C2B0F4@gmail.com> <4ED96727.1040502@oracle.com> <2F7DEE03-9940-4820-9CBE-7883FF86C20D@oracle.com> Message-ID: The missing scripts have been pushed, so I think I can now give reproducible instructions for building and testing. Download the 2.1 binary for Mac from http://www.oracle.com/technetwork/java/javafx/downloads/javafx2-macosx-487281.html. 1) hg clone http://hg.openjdk.java.net/openjfx/2.1/master 2) cd master 3) mkdir -p artifacts/sdk/rt/lib 4) cp ~/Downloads/javafx-sdk2.1.0-beta/rt/lib/jfxrt.jar artifacts/sdk/rt/lib - Or from wherever you have downloaded this file 5) hg clone hg.openjdk.java.net/openjfx/2.1/master/rt 6) vi build-defs.xml - There is some library being used but not registered properly, there is probably another way to do this. Anyway, just edit the master/rt/build-defs.xml and comment out the line: 7) cd javafx-ui-controls 8) ant That should be enough to actually have built the project. The built class files should be sitting in master/rt/javafx-ui-common/dist/javafx-ui-controls.jar. You can then run by placing the newly created javafx-ui-controls.jar before jfxrt.jar on your classpath. Let me know if you have any success! Thanks Richard On Dec 6, 2011, at 9:46 AM, Richard Bair wrote: > If you got to Oracle.com and download JavaFX and find the tiny link that switches to the Mac Developer Preview download and grab it, you will get a very recent 2.1 build. This can be used as the binary plug for building. Unfortunately, some build files are missing in the master/ repo. I tried to push these files in, but the server is not happy with my ssl configuration. I'm trying to track that down. With those build files put in, there is one other slight modification to master/rt/build-defs.xml, but this will then allow you to actually build the controls repo and, if you are on Mac, run it. > > I'll keep you all abreast of the work, hopefully we'll have something fully buildable a little later today. > > Richard > > > On Dec 2, 2011, at 5:43 PM, Richard Bair wrote: > >>> Sorry I misunderstood, I was expecting something similar to the binary plugs we had in OpenJDK, not a full version of the current release, hence the question. >>> >>> I was able to import the project successfully into eclipse (and netbeans) with the FX runtime and it seems to compile fine. >> >> Oh, that's interesting. I grabbed the latest 2.0.2 code for Mac that I had available but it was failing on: >> >> [javac] /Developer/Projects/openjfx/workspace-2.1/master/rt/javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ButtonBehavior.java:42: cannot find symbol >> [javac] symbol : class PlatformUtil >> [javac] location: package com.sun.javafx >> [javac] import com.sun.javafx.PlatformUtil; >> [javac] ^ >> >> And a bunch of other such failures. So I thought PlatformUtil had been removed between the 2.0.2 code I had (from early November) and the newer code in the 2.1 tree. If you got it to build in Eclipse on an older release -- well that is interesting! What version of JavaFX are you using for the binary plug? >> >> Do you want to post some basic instructions so other folks can do likewise? >> >>> I'll play with this code a bit and see how we can help out until everything else is sorted out. >>> >>> I think that while this is a suboptimal situation (but hey, we Free Software freaks are never happy, right? :) is still a great step forward, and we have a chance to study the code and the internals before everything gets released. >>> >>> Speaking about this, do you think we can have some "specs" about the internal interfaces? >> >> Probably in the short term asking me questions is the fastest way to get answers, unfortunately. I do need to be badgered to write up some documents though and put them up on our pages. Please do feel free to badger me: squeaky wheel and all that :-) >> >>> I know from JavaOne that the internal code is pretty abstracted and modular, and can actually be "easily" replaced (not sure the exact definition of easily though, but what you have shown at J1 was very impressive). >>> >>> We can probably help speeding up things if we know what things should be replaced and implement some clear room version of what will come later in the game, in a similar way we did with the Pisces renderer in Java2D, what do you think? >>> >>> I'm specifically thinking about the Linux port here, since to be honest "late 2012" is eons away. >> >> What we have released so far is the controls portion, which all sits above the "toolkit implementation" line. Basically on the "top" we've got controls, scene graph, css, properties, binding, collections, services, and that sort of thing. There is a Toolkit interface (com.sun.javafx.tk.Toolkit) which defines the abstraction between the public API portions of the platform and the underlying toolkit implementation (threading, windowing, opengl, d3d, fonts, etc). >> >> Likely it will be a couple months before we start putting out the lower-level bits en masse, due to having to be careful there over 3rd party code etc (there isn't much, mostly fonts and some SVG, but we have to do all the due diligence). The other problem is the same guys who have to do that, have to get the Mac port finished (both for Java 7 and for Java FX). However I will follow up with the guys doing linux and see if we can get that out sooner (they're busy working away on it and it would be cool to get it open faster, but at the very least get it included in the bits so you can run on linux). >> >> Cheers >> Richard > From tbee at tbee.org Tue Dec 6 11:25:28 2011 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 06 Dec 2011 20:25:28 +0100 Subject: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls. In-Reply-To: <20111206182834.BE46A475A5@hg.openjdk.java.net> References: <20111206182834.BE46A475A5@hg.openjdk.java.net> Message-ID: <4EDE6C28.1060301@tbee.org> On 2011-12-06 19:28, richard.bair at oracle.com wrote: > Added build scripts that are needed for building UI controls. Actually they are probably not ALL needed, but they don't hurt. We need to clean these things all up as part of the open sourcing process, since the mechanism by which we download and install the necessary libs are probably going to be different than what we have been doing up to this point. > May I suggest that if the build process is refactored, it is smart to be focussing on generating artifacts. I do not really care if that is done using ANT & Ivy, Gradle or Maven, but I think generating Maven compatible artifacts with dependency information is very wise. Tom From richard.bair at oracle.com Tue Dec 6 11:39:58 2011 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Dec 2011 11:39:58 -0800 Subject: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls. In-Reply-To: <4EDE6C28.1060301@tbee.org> References: <20111206182834.BE46A475A5@hg.openjdk.java.net> <4EDE6C28.1060301@tbee.org> Message-ID: > On 2011-12-06 19:28, richard.bair at oracle.com wrote: >> Added build scripts that are needed for building UI controls. Actually they are probably not ALL needed, but they don't hurt. We need to clean these things all up as part of the open sourcing process, since the mechanism by which we download and install the necessary libs are probably going to be different than what we have been doing up to this point. >> > > May I suggest that if the build process is refactored, it is smart to be focussing on generating artifacts. I do not really care if that is done using ANT & Ivy, Gradle or Maven, but I think generating Maven compatible artifacts with dependency information is very wise. The way this works in our internal builds is that: - We have some 200+ individual NB projects which span everything from samples, demos, performance tests, and actual production code. - Each NB project produces both myproject/build/... class files as well as myproject/dist/myproject.jar file - The larger system them builds these into artifacts/, such that there is a full & complete SDK (minus the installer) We use Ant for all the builds, although there is some concern about how we'll go about doing things when we get integrated into the JDK (where they use make... yikes!). We use a little make as well for building the native parts (media, webkit, glass). I think modifying the build scripts so that they also produce maven-compatible artifacts is fine, I know this has been asked for frequently. We don't know how to do it though (I don't know any of our team that has any significant time in Maven). Any large changes to the build system though will need to be done very deliberately so as not to disrupt the engineering team or deliverables for 2.1 or 2.2. But it would probably be a worthwhile exercise to collect the requirements for the system. Cheers Richard From roman at kennke.org Tue Dec 6 11:52:21 2011 From: roman at kennke.org (Roman Kennke) Date: Tue, 06 Dec 2011 20:52:21 +0100 Subject: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls. In-Reply-To: References: <20111206182834.BE46A475A5@hg.openjdk.java.net> <4EDE6C28.1060301@tbee.org> Message-ID: <1323201141.2752.24.camel@moonlight> > I think modifying the build scripts so that they also produce maven-compatible artifacts is fine, I know this has been asked for frequently. We don't know how to do it though (I don't know any of our team that has any significant time in Maven). I could take a look at this. Problem is that this would be very difficult (and a bit pointless) as long as the other pieces are not open sourced. Those would need to get provided in a publicly accessible Maven repository to be of any use for building the open source part. Regards, Roman From tbee at tbee.org Tue Dec 6 12:00:30 2011 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 06 Dec 2011 21:00:30 +0100 Subject: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls. In-Reply-To: References: <20111206182834.BE46A475A5@hg.openjdk.java.net> <4EDE6C28.1060301@tbee.org> Message-ID: <4EDE745E.30306@tbee.org> On 2011-12-06 20:39, Richard Bair wrote: > We use Ant for all the builds, although there is some concern about how we'll go about doing things when we get integrated into the JDK (where they use make... yikes!). We use a little make as well for building the native parts (media, webkit, glass). Basically you're building one big monolitic jar. From a startup speed perspective that may not be the best choice. Is the JDK modularization (Jigsaw) going to influence your structure? I think there are people enough who can, and would be willing to, help out with Maven / OSGi modularisation (since we know diddly about Jigsaw, I can't comment on that). Tom From tbee at tbee.org Tue Dec 6 12:13:26 2011 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 06 Dec 2011 21:13:26 +0100 Subject: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls. In-Reply-To: <1323201141.2752.24.camel@moonlight> References: <20111206182834.BE46A475A5@hg.openjdk.java.net> <4EDE6C28.1060301@tbee.org> <1323201141.2752.24.camel@moonlight> Message-ID: <4EDE7766.6010806@tbee.org> On 2011-12-06 20:52, Roman Kennke wrote: >> I think modifying the build scripts so that they also produce maven-compatible artifacts is fine, I know this has been asked for frequently. We don't know how to do it though (I don't know any of our team that has any significant time in Maven). > I could take a look at this. Problem is that this would be very > difficult (and a bit pointless) as long as the other pieces are not open > sourced. Those would need to get provided in a publicly accessible Maven > repository to be of any use for building the open source part. > Not only that, but also the DLL loading should be extended to be able to load from an artifact. I've done some work with the "prelaunch" method in JFXtras' Application class, but there are better ways probably. Tom From richard.bair at oracle.com Tue Dec 6 12:39:14 2011 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Dec 2011 12:39:14 -0800 Subject: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls. In-Reply-To: <4EDE745E.30306@tbee.org> References: <20111206182834.BE46A475A5@hg.openjdk.java.net> <4EDE6C28.1060301@tbee.org> <4EDE745E.30306@tbee.org> Message-ID: >> We use Ant for all the builds, although there is some concern about how we'll go about doing things when we get integrated into the JDK (where they use make... yikes!). We use a little make as well for building the native parts (media, webkit, glass). > > Basically you're building one big monolitic jar. From a startup speed perspective that may not be the best choice. I'm not sure of the current numbers, but I know that previously we did comparisons and the monolithic jar was faster at startup (and smaller at download since we pack200 the whole thing), but that analysis may have been with WebStart (since that is how the 1.x platform shipped), and not with the installer variety. Igor do you know? > Is the JDK modularization (Jigsaw) going to influence your structure? Definitely. From a project perspective I think we're more or less there (ie: our source "modules" already exist and are fairly well decoupled and so forth), so when Java 8 modularity is far enough along and we're past 2.2 and working on 3.0 we'll start using Java 8 modularity. > I think there are people enough who can, and would be willing to, help out with Maven / OSGi modularisation (since we know diddly about Jigsaw, I can't comment on that). That would be good! Richard From neugens.limasoftware at gmail.com Tue Dec 6 12:42:58 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 6 Dec 2011 21:42:58 +0100 Subject: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls. In-Reply-To: <1323201141.2752.24.camel@moonlight> References: <20111206182834.BE46A475A5@hg.openjdk.java.net> <4EDE6C28.1060301@tbee.org> <1323201141.2752.24.camel@moonlight> Message-ID: Il giorno 06/dic/2011, alle ore 20:52, Roman Kennke ha scritto: > >> I think modifying the build scripts so that they also produce maven-compatible artifacts is fine, I know this has been asked for frequently. We don't know how to do it though (I don't know any of our team that has any significant time in Maven). > > I could take a look at this. Problem is that this would be very > difficult (and a bit pointless) as long as the other pieces are not open > sourced. Those would need to get provided in a publicly accessible Maven > repository to be of any use for building the open source part. > > Regards, Roman > > Oracle could still produce a downloadable artifact, since is quite easy, even if the build is not mavenized (which is good unless you want JavaFX to become a google mirror!!! - no pun intended ;) In any case, installing one locally is trivial, this is what we do to build ThingsFX: mvn install:install-file -Dfile=/path/to/javafx-sdk2.0.2-beta/rt/lib/jfxrt.jar -DgroupId=com.oracle.javafx -DartifactId=javafx -Dversion=2.0 -Dpackaging=jar This can even go in the build.xml of the binary package so that you don't need to mavenize, just install the library. The only gotcha is that the jar file doesn't include the native library, and only doing this fails to produce a runnable binary, at least on OSX (this can be easily fixed though). Cheers, Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From igor.nekrestyanov at oracle.com Tue Dec 6 13:09:17 2011 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Tue, 06 Dec 2011 13:09:17 -0800 Subject: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls. In-Reply-To: References: <20111206182834.BE46A475A5@hg.openjdk.java.net> <4EDE6C28.1060301@tbee.org> <4EDE745E.30306@tbee.org> Message-ID: <4EDE847D.4050707@oracle.com> On 12/6/11 12:39 PM, Richard Bair wrote: >>> We use Ant for all the builds, although there is some concern about how we'll go about doing things when we get integrated into the JDK (where they use make... yikes!). We use a little make as well for building the native parts (media, webkit, glass). >> Basically you're building one big monolitic jar. From a startup speed perspective that may not be the best choice. > I'm not sure of the current numbers, but I know that previously we did comparisons and the monolithic jar was faster at startup (and smaller at download since we pack200 the whole thing), but that analysis may have been with WebStart (since that is how the 1.x platform shipped), and not with the installer variety. Igor do you know? yes, for webstart based deployment single jar is clearly superior from the startup standpoint. I am not sure that splitting into multiple jars helps startup much unless a lot of these jars are not used. You mostly save on reading fewer data from zip directory but reading multiple files may be more expensive as you do not benefit from disk prefetching. I am not sure what is current size of zip directory for jfxrt.jar but it is likely to be couple of hundreds Kb i think (and controls only part is smaller). This needs to be measured again of course but my gut feeling we will not win much. -igor From tbee at tbee.org Tue Dec 6 13:20:47 2011 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 06 Dec 2011 22:20:47 +0100 Subject: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls. In-Reply-To: References: <20111206182834.BE46A475A5@hg.openjdk.java.net> <4EDE6C28.1060301@tbee.org> <1323201141.2752.24.camel@moonlight> Message-ID: <4EDE872F.80609@tbee.org> On 2011-12-06 21:42, Mario Torre wrote: > In any case, installing one locally is trivial, this is what we do to build ThingsFX: > > mvn install:install-file > -Dfile=/path/to/javafx-sdk2.0.2-beta/rt/lib/jfxrt.jar > -DgroupId=com.oracle.javafx -DartifactId=javafx -Dversion=2.0 > -Dpackaging=jar > For JFXtras we do the same (I think we call the artifact javafx-runtime or something), but we also create a jar containing all the DLLs and install that with the same name plus the "windows" classifier. Application.prelaunch unpacks the DLLs to a temp directory and modifies the java-library-path to match. It would be better if the DLL load logic could load directly from the jar. Tom From roman at kennke.org Tue Dec 6 13:24:54 2011 From: roman at kennke.org (Roman Kennke) Date: Tue, 06 Dec 2011 22:24:54 +0100 Subject: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls. In-Reply-To: <4EDE872F.80609@tbee.org> References: <20111206182834.BE46A475A5@hg.openjdk.java.net> <4EDE6C28.1060301@tbee.org> <1323201141.2752.24.camel@moonlight> <4EDE872F.80609@tbee.org> Message-ID: <1323206694.2752.29.camel@moonlight> Hi, > > In any case, installing one locally is trivial, this is what we do to build ThingsFX: > > > > mvn install:install-file > > -Dfile=/path/to/javafx-sdk2.0.2-beta/rt/lib/jfxrt.jar > > -DgroupId=com.oracle.javafx -DartifactId=javafx -Dversion=2.0 > > -Dpackaging=jar > > > > For JFXtras we do the same (I think we call the artifact javafx-runtime or something), but we also create a jar containing all the DLLs and install that with the same name plus the "windows" classifier. Application.prelaunch unpacks the DLLs to a temp directory and modifies the java-library-path to match. It would be better if the DLL load logic could load directly from the jar. This should not be difficult to implement (I did that for a project a while ago) and it helps a lot because if the native lib is embedded in the JAR it's much easier to use the library because you can copy around the JAR only and it still works because the lib is loaded as a resource. Depending on the size of the native lib and requirements regarding download size, you could even embed all the native libs for different platforms in the jar and ship only one version to rule them all ;-) It's a bit more tricky to make it fast because you don't want to unpack this thing on each launch, but not rocket science either. I have already hit a couple of instances where my Eclipse had the jfxrt.jar in its classpath but couldn't find the native lib because jfxrt.jar was not in its original location. Cheers, Roman From knut.arne.vedaa at broadpark.no Tue Dec 6 13:41:07 2011 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Tue, 06 Dec 2011 22:41:07 +0100 Subject: Controls with Values [was Possible additions to JavaFX to facilitate forms and validations] In-Reply-To: <67E8E7BD-24DB-4242-81FD-6C35389A7699@oracle.com> References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> <4EDE4972.8030205@broadpark.no> <67E8E7BD-24DB-4242-81FD-6C35389A7699@oracle.com> Message-ID: <4EDE8BF3.1080109@broadpark.no> On 06.12.2011 18:02, Richard Bair wrote: > Oh, you probably gave the idea to me sub-consciously :-) Great minds think alike. :) > From a naming perspective, the idea that TextField would implement property seems wrong, although the idea of binding a TextField to something directly seems great (we had similar API in SwingLabs back in the day for a set of data-aware components I was experimenting with). It takes thinking of a Control a little differently -- in addition to being a thing with a bunch of state, it is also, fundamentally, used for displaying and editing a value. It still wouldn't be what we would call a "Property" in the meaning of the word, but the Property interface does express the API that could be useful in this context. What about a new interface Bindable (or BindableValue) that has the methods that Property has now (all the binding methods): interface Bindable extends ObservableValue, WritableValue interface Property extends ReadOnlyProperty, Bindable abstract class ValueControl extends Control implements Bindable Knut Arne From tom.schindl at bestsolution.at Tue Dec 6 13:49:47 2011 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 06 Dec 2011 22:49:47 +0100 Subject: Possible additions to JavaFX to facilitate forms and validations In-Reply-To: References: Message-ID: <4EDE8DFB.6050409@bestsolution.at> [...] > For ListView and TableView I would see the current selected 'row' as the > value. Multi-selection has some additional challenges here, and I would be > interested in other thoughts on this. One option is that these controls use > List as their ValueType, another (and probably my preference) is > that there is a separate interface called 'HasValues' for binding to > multi-selection value controls, while still allowing simple binding to > single-selection values. Well for TableView and Lists the business value could also be the ObservableList of Items itself not? Take for example the addresses of a person which are shown in the TableView. 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 richard.bair at oracle.com Tue Dec 6 14:10:39 2011 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Dec 2011 14:10:39 -0800 Subject: Notes on our current process and forest structure Message-ID: Hi everyone, I thought it would be useful to outline our current internal working process, and then describe some of the challenges we need to solve in moving this all out into the open. I'm hoping this sort of insight will help illuminate why everything isn't running smoothly from day one and what we're trying to resolve. As with the JDK, JavaFX sources are built out of a mercurial forest. The current internal forest structure is basically: jfx/ - This is the root forest jfx/apps - Contains a number of public apps (such as Ensemble and DataApp) and internal apps (which have been ported from FX Script to Java but haven't been blessed) jfx/glass - All of the windows / mac / linux / other platform implementations jfx/webnode - WebKit, plus some Java code that glues webkit to the public API jfx/media - GStreamer, plus some Java code that glues gstreamer to the public API jfx/tests - Mostly performance tests jfx/runtime - The bulk of the platform -- all controls, charts, etc are in this repo There are, basically, four forests: master - The master forest is the forest from which all promotions and releases are built graphics - Used by the graphics, scenegraph, and most other teams controls - Used by the controls team media - Used by the media team Although mercurial doesn't actually operate this way, you can think of the master as being the root of a tree with graphics, controls, and media as children. Once a week (typically Tuesday) we do integrations. The "integrator" for each child forest will pull the latest from Master into their forest. They will merge up, run tests, run some sample apps, and make sure things are all good to go. They will then push their changesets from their forest (what we call the integration forest or scrum forest) up to the master. The three teams do this according to some negotiated schedule, so that all these merges are done in an orderly fashion. After everybody has integrated, everybody does a fresh pull from master so that after integration, each child forest is in essence sync'd up completely and identical. Then the teams continue working for another week in their own forests, and re-integrate the following Tuesday. We didn't start with this system in place, at one point we had just a single master. That of course left the master in some undefined state at any given time -- there was no gate to make sure only "good" changes made it to master. So we had an integration and a master forest. But eventually the size of the team became such that we had to split things out further, because changes in one team would be unstable for some few days and this would impact the work of other teams. So we have grown the number of integration forests organically as needed. In general you want as few as you can get away with. Presently in OpenJFX we have essentially added a fifth integration forest, also called master. Lets call it "openjfx-master". This is actually being populated based on the controls forest. So when the controls folks push fixes into the controls forest, it is propagated to the openjfx-master. This is a short-term position. the openjfx-master is intended to become the real master, and we will fire up additional forests for the controls, graphics, and media scrums to use. At least, that is my first-shot proposal and seems the most sensible since it will mean we continue to work much as we have, and so it will have the least disruption to the team while also opening up the development process. When somebody has a fix to contribute, they will work with one of these scrum teams (depending on whether it is a controls fix or a media fix or somewhere in the scene graph or core libraries or prism). Fixes will go into the appropriate scrum team forest, and from there will get merged into the master on a weekly basis. Now, we don't really want to keep forest structure that I described at the start of this message. We really would like to cut down the number of repos in the forest. One proposal is to do something like this: jfx/ - This is the root forest jfx/apps - As presently constituted jfx/webkit - WebKit, plus our patches to webkit (but no Java code) jfx/gstreamer - GStreamer, plus our patches (but no Java code) jfx/rt - The bulk of the platform -- all controls, charts, glass, Java parts for web view, java parts for media, performance tests, other tests, etc In this arrangement we have reduced the number of forests and, if you are only working on the platform, you generally will only need the rt/ and not the full forest (although personally I think everybody should always use the full forest because when doing find-usages in the IDE it is instructive to also have all the apps and samples and such in front of you). So in the process of open sourcing, we're also planning how to make things a bit cleaner and more accessible to developers than they are currently. In the old closed runtime, we had a bunch of projects such as: decora-compiler decora-d3d decora-d3d-native decora-es2 decora-jsw decora-ogl decora-prism decora-prism-ps decora-prism-sw decora-runtime decora-sse decora-sse-native javafx-anim javafx-annotation-processor javafx-beans javafx-common javafx-sg-common javafx-sg-prism javafx-ui-charts javafx-ui-common javafx-ui-controls javafx-ui-quantum javafx-ui-webnode prism-common prism-d3d prism-d3d-native prism-es2 prism-j2d prism-jogl prism-null prism-ps prism-util And a lot more. This has grown organically, and over time we've acquired a fair number of projects. Obviously some of these have a relation: all the decora- ones are related with a single decora-runtime and another compiler and then a pile of backend implementations. There is prism-common and prism-util and a pile of prism implementations. Instead of having a flat directory with a huge pile of different projects, we'd like to organize things when we move these to open source. So for example, maybe we do: Graphics/Decora/ decora-compiler decora-d3d decora-d3d-native decora-es2 decora-jsw decora-ogl decora-prism decora-prism-ps decora-prism-sw decora-runtime decora-sse decora-sse-native Graphics/Prism/ prism-common prism-d3d prism-d3d-native prism-es2 prism-j2d prism-jogl prism-null prism-ps prism-util Graphics/Glass/ .... CoreLibs/ javafx-anim javafx-beans javafx-common Controls/ javafx-ui-controls javafx-ui-charts SceneGraph/ javafx-ui-common WebView/ javafx-ui-webnode I'm totally making this up, but this is the general idea. Maybe we do this in two steps -- open source first, and then rearrange to clean things up. Or maybe we do it in one go. In any case, I wanted to take a few moments and mention at least somewhat of what we're doing. In addition to doing the due-diligence on third party code checks and making sure header files are all correct and so forth, we're also taking a look at the tools used to build and the structure of the forest to see if there is anything we can do to make it easier for developers to grok. It was painful enough just getting new hires up to speed, with all this in the open and trying to make it accessible to a wide range of new engineers it becomes even more important to make it clean and easy to use. Cheers Richard PS I might be a bit out of date with the exact specifics. I think glass may have already been folded into runtime, and the runtime name is actually not runtime anymore, but I digress. From knut.arne.vedaa at broadpark.no Tue Dec 6 14:11:54 2011 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Tue, 06 Dec 2011 23:11:54 +0100 Subject: Node Annotation [was Re: Possible additions to JavaFX to facilitate forms and validations] In-Reply-To: References: Message-ID: <4EDE932A.1090700@broadpark.no> On 04.12.2011 02:06, Daniel Zwolenski wrote: > highlighting on a screen), etc. I'm sure developers would find many other > useful ways to use this feature. Another simple use case: display a "dirty" marker, i.e. "this value has been edited". Knut Arne From kevin.rushforth at oracle.com Tue Dec 6 15:01:52 2011 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 06 Dec 2011 21:01:52 -0200 Subject: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls. In-Reply-To: <4EDE7766.6010806@tbee.org> References: <20111206182834.BE46A475A5@hg.openjdk.java.net> <4EDE6C28.1060301@tbee.org> <1323201141.2752.24.camel@moonlight> <4EDE7766.6010806@tbee.org> Message-ID: <4EDE9EE0.8000305@oracle.com> This is a good discussion, and as Rich noted, the main thing we should do in the short-term is collect requirements. We will be moving to a Jigsaw-based modularization in JDK8 / JavaFX 3.0, which also needs to be taken into account. -- Kevin Tom Eugelink wrote: > > On 2011-12-06 20:52, Roman Kennke wrote: >>> I think modifying the build scripts so that they also produce >>> maven-compatible artifacts is fine, I know this has been asked for >>> frequently. We don't know how to do it though (I don't know any of >>> our team that has any significant time in Maven). >> I could take a look at this. Problem is that this would be very >> difficult (and a bit pointless) as long as the other pieces are not open >> sourced. Those would need to get provided in a publicly accessible Maven >> repository to be of any use for building the open source part. >> > > Not only that, but also the DLL loading should be extended to be able > to load from an artifact. I've done some work with the "prelaunch" > method in JFXtras' Application class, but there are better ways probably. > > Tom > > From kevin.rushforth at oracle.com Tue Dec 6 15:17:14 2011 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 06 Dec 2011 21:17:14 -0200 Subject: Notes on our current process and forest structure In-Reply-To: References: Message-ID: <4EDEA27A.6040003@oracle.com> Good summary. Based on a cursory reading of this, it looks pretty up-to-date to me. Btw, glass will be folded into runtime (initially the closed repo) later this month. > Maybe we do this in two steps -- open source first, and then rearrange to clean things up. Or maybe we do it in one go. Could be done either way, although the "do it one go" would probably be more like: rearrange to clean things up first and then open source second, since some pieces will be open-sourced earlier than others. There are pros/cons to either ordering. As you can all imagine, there are a lot of details to work out, but this is a rough idea of where we are headed. -- Kevin Richard Bair wrote: > Hi everyone, > > I thought it would be useful to outline our current internal working process, and then describe some of the challenges we need to solve in moving this all out into the open. I'm hoping this sort of insight will help illuminate why everything isn't running smoothly from day one and what we're trying to resolve. > > As with the JDK, JavaFX sources are built out of a mercurial forest. The current internal forest structure is basically: > > jfx/ - This is the root forest > jfx/apps - Contains a number of public apps (such as Ensemble and DataApp) and internal apps (which have been ported from FX Script to Java but haven't been blessed) > jfx/glass - All of the windows / mac / linux / other platform implementations > jfx/webnode - WebKit, plus some Java code that glues webkit to the public API > jfx/media - GStreamer, plus some Java code that glues gstreamer to the public API > jfx/tests - Mostly performance tests > jfx/runtime - The bulk of the platform -- all controls, charts, etc are in this repo > > There are, basically, four forests: > > master - The master forest is the forest from which all promotions and releases are built > graphics - Used by the graphics, scenegraph, and most other teams > controls - Used by the controls team > media - Used by the media team > > Although mercurial doesn't actually operate this way, you can think of the master as being the root of a tree with graphics, controls, and media as children. Once a week (typically Tuesday) we do integrations. The "integrator" for each child forest will pull the latest from Master into their forest. They will merge up, run tests, run some sample apps, and make sure things are all good to go. They will then push their changesets from their forest (what we call the integration forest or scrum forest) up to the master. The three teams do this according to some negotiated schedule, so that all these merges are done in an orderly fashion. After everybody has integrated, everybody does a fresh pull from master so that after integration, each child forest is in essence sync'd up completely and identical. Then the teams continue working for another week in their own forests, and re-integrate the following Tuesday. > > We didn't start with this system in place, at one point we had just a single master. That of course left the master in some undefined state at any given time -- there was no gate to make sure only "good" changes made it to master. So we had an integration and a master forest. But eventually the size of the team became such that we had to split things out further, because changes in one team would be unstable for some few days and this would impact the work of other teams. So we have grown the number of integration forests organically as needed. In general you want as few as you can get away with. > > Presently in OpenJFX we have essentially added a fifth integration forest, also called master. Lets call it "openjfx-master". This is actually being populated based on the controls forest. So when the controls folks push fixes into the controls forest, it is propagated to the openjfx-master. This is a short-term position. the openjfx-master is intended to become the real master, and we will fire up additional forests for the controls, graphics, and media scrums to use. At least, that is my first-shot proposal and seems the most sensible since it will mean we continue to work much as we have, and so it will have the least disruption to the team while also opening up the development process. > > When somebody has a fix to contribute, they will work with one of these scrum teams (depending on whether it is a controls fix or a media fix or somewhere in the scene graph or core libraries or prism). Fixes will go into the appropriate scrum team forest, and from there will get merged into the master on a weekly basis. > > Now, we don't really want to keep forest structure that I described at the start of this message. We really would like to cut down the number of repos in the forest. One proposal is to do something like this: > > jfx/ - This is the root forest > jfx/apps - As presently constituted > jfx/webkit - WebKit, plus our patches to webkit (but no Java code) > jfx/gstreamer - GStreamer, plus our patches (but no Java code) > jfx/rt - The bulk of the platform -- all controls, charts, glass, Java parts for web view, java parts for media, performance tests, other tests, etc > > In this arrangement we have reduced the number of forests and, if you are only working on the platform, you generally will only need the rt/ and not the full forest (although personally I think everybody should always use the full forest because when doing find-usages in the IDE it is instructive to also have all the apps and samples and such in front of you). So in the process of open sourcing, we're also planning how to make things a bit cleaner and more accessible to developers than they are currently. > > In the old closed runtime, we had a bunch of projects such as: > > decora-compiler > decora-d3d > decora-d3d-native > decora-es2 > decora-jsw > decora-ogl > decora-prism > decora-prism-ps > decora-prism-sw > decora-runtime > decora-sse > decora-sse-native > javafx-anim > javafx-annotation-processor > javafx-beans > javafx-common > javafx-sg-common > javafx-sg-prism > javafx-ui-charts > javafx-ui-common > javafx-ui-controls > javafx-ui-quantum > javafx-ui-webnode > prism-common > prism-d3d > prism-d3d-native > prism-es2 > prism-j2d > prism-jogl > prism-null > prism-ps > prism-util > > And a lot more. This has grown organically, and over time we've acquired a fair number of projects. Obviously some of these have a relation: all the decora- ones are related with a single decora-runtime and another compiler and then a pile of backend implementations. There is prism-common and prism-util and a pile of prism implementations. Instead of having a flat directory with a huge pile of different projects, we'd like to organize things when we move these to open source. So for example, maybe we do: > > Graphics/Decora/ > decora-compiler > decora-d3d > decora-d3d-native > decora-es2 > decora-jsw > decora-ogl > decora-prism > decora-prism-ps > decora-prism-sw > decora-runtime > decora-sse > decora-sse-native > Graphics/Prism/ > prism-common > prism-d3d > prism-d3d-native > prism-es2 > prism-j2d > prism-jogl > prism-null > prism-ps > prism-util > Graphics/Glass/ > .... > CoreLibs/ > javafx-anim > javafx-beans > javafx-common > Controls/ > javafx-ui-controls > javafx-ui-charts > SceneGraph/ > javafx-ui-common > WebView/ > javafx-ui-webnode > > I'm totally making this up, but this is the general idea. Maybe we do this in two steps -- open source first, and then rearrange to clean things up. Or maybe we do it in one go. In any case, I wanted to take a few moments and mention at least somewhat of what we're doing. In addition to doing the due-diligence on third party code checks and making sure header files are all correct and so forth, we're also taking a look at the tools used to build and the structure of the forest to see if there is anything we can do to make it easier for developers to grok. It was painful enough just getting new hires up to speed, with all this in the open and trying to make it accessible to a wide range of new engineers it becomes even more important to make it clean and easy to use. > > Cheers > Richard > > PS I might be a bit out of date with the exact specifics. I think glass may have already been folded into runtime, and the runtime name is actually not runtime anymore, but I digress. From james.graham at oracle.com Tue Dec 6 15:28:24 2011 From: james.graham at oracle.com (Jim Graham) Date: Tue, 06 Dec 2011 15:28:24 -0800 Subject: Controls with Values [was Possible additions to JavaFX to facilitate forms and validations] In-Reply-To: <67E8E7BD-24DB-4242-81FD-6C35389A7699@oracle.com> References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> <4EDE4972.8030205@broadpark.no> <67E8E7BD-24DB-4242-81FD-6C35389A7699@oracle.com> Message-ID: <4EDEA518.5090102@oracle.com> OK, time for a graphics nerd to put his foot in his mouth and try to sound less than dim-witted in a Controls discussion... It feels like the proposals here are heading in the direction of FX owning the data. That's great for applications that never do anything other than display the data on a single FX-capable screen, but I can imagine more complicated applications for whom screen display is only one of their goals/modes of use. Consider an application that is meant to view a database. When displaying it on the screen the data needs to be managed by both the database and the FX nodes, but the FX nodes don't really own the data there, that is just one way to manage that part of the interaction. Meanwhile there may be back end modes of this application that run as network services to manage updates to this database through web or net services. It may have a command line interface for batch processing. It may have an HTML5 back end for displaying on devices that don't yet support FX. It may want to support displaying the database on multiple screens or in multiple views on the same screen. I don't think the proposals for Controls to "be" properties will necessarily preclude any of that, but would it be more natural for Controls to talk to a property that is owned by the application? In other words, TextFoo is a Control that takes a Text property, it is not itself a text property. And when you do data binding, you would be binding the raw properties that the application manages, not the Control nodes. And when you have multiple views on the same data open then you don't have to have a cloud of self-important nodes that all believe they own the data that needs to be coordinated so they all make sure they own the same version of the data as each other... Or am I off base here? ...jim From zonski at googlemail.com Tue Dec 6 15:35:06 2011 From: zonski at googlemail.com (Daniel Zwolenski) Date: Wed, 7 Dec 2011 10:35:06 +1100 Subject: JavaFX Maven support (was: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls.) Message-ID: Maven support would be fantastic. There's two distinct and independent aspects to this and it's probably worth making these real clear, especially for the non-maven users: 1. Allow the general public to build their JavaFX applications using Maven. 2. Allow openjfx developers to build the runtime, etc, using Maven The first one is critical for JFX uptake by Maven users - we Maven users are so hooked into the whole Maven eco-sphere that if something is not in a maven repo it virtually doesn't exist for us :) The second is really a nice to have - so long as the JFX runtime build process is easy and well documented then it doesn't really matter what build tool is used (although Maven would make a lot of that modularisation stuff easier and simplify build scripts significantly). Regarding the first one (which is my priority), the two things stopping this from happening right now are: 1. The native DLL loading issue. Maven only really works with the classpath and not the system path for natives, so we need to do some tricks. 2. The licencing issue - it is currently illegal for anyone other than Oracle to distribute the runtime, so we can't put the runtime jar or natives in a public repo yet. There's no real way to make Java's 'DLL load logic' load directly from a jar unfortunately (as far as I know). It's the operating system that has to load the DLLs (or whatever native files are relevant for that OS) and the OS doesn't understand a 'jar'. One reasonably common trick is the one described below where the natives are included in the jar and then on startup, the natives are extracted to a local temporary location, which the OS is then made aware of. This works but it is a little hacky - the jar is now more of a delivery mechanism for the natives, rather than just a resource containing them (e.g. remove the jar and there's no guarantee the extracted dll's are gone, etc). Given no other option, this is the fallback. Another option is to keep the natives outside of the jar and have them as a system path dependency. That's pretty much how it works now, except that the JFX dll loading code uses a directory relative to the jfxrt.jar location, which is based on the JFX installation structure (i.e. the natives are in a 'rt/bin' directory and the rt.jar is in 'rt/lib''). When we start putting things in Maven it loses this directory structure so this load code fails to find the natives. I think perhaps if we removed this relative directory structure then Maven could be made to work by including the natives in the same dependency as the rt.jar. There may be other options? One bigger question this whole topic raises for me though: what exactly is the JavaFX installer doing? If it's just a case of getting the natives on the path to make JavaFX work, why do we have to make users (and developers) go through the whole, do you want to install JavaFX drama? Why can't it just be another jar on the path of my custom application - a simple dependency that I manage, much like I manage my log4j, spring, and datafx dependencies, etc? And if it turns out the installer does actually need to run, why doesn't it just put the jfx natives on the system path so that when the runtime starts up it will always find it, regardless of where that jfxrt.jar is on the local filesystem? It would be good to get some insight on the inner workings of all this. On Wed, Dec 7, 2011 at 8:24 AM, Roman Kennke wrote: > Hi, > > > > In any case, installing one locally is trivial, this is what we do to > build ThingsFX: > > > > > > mvn install:install-file > > > -Dfile=/path/to/javafx-sdk2.0.2-beta/rt/lib/jfxrt.jar > > > -DgroupId=com.oracle.javafx -DartifactId=javafx -Dversion=2.0 > > > -Dpackaging=jar > > > > > > > For JFXtras we do the same (I think we call the artifact javafx-runtime > or something), but we also create a jar containing all the DLLs and install > that with the same name plus the "windows" classifier. > Application.prelaunch unpacks the DLLs to a temp directory and modifies the > java-library-path to match. It would be better if the DLL load logic could > load directly from the jar. > > This should not be difficult to implement (I did that for a project a > while ago) and it helps a lot because if the native lib is embedded in > the JAR it's much easier to use the library because you can copy around > the JAR only and it still works because the lib is loaded as a resource. > Depending on the size of the native lib and requirements regarding > download size, you could even embed all the native libs for different > platforms in the jar and ship only one version to rule them all ;-) It's > a bit more tricky to make it fast because you don't want to unpack this > thing on each launch, but not rocket science either. I have already hit > a couple of instances where my Eclipse had the jfxrt.jar in its > classpath but couldn't find the native lib because jfxrt.jar was not in > its original location. > > Cheers, Roman > > > From roman at kennke.org Tue Dec 6 15:39:34 2011 From: roman at kennke.org (Roman Kennke) Date: Wed, 07 Dec 2011 00:39:34 +0100 Subject: Notes on our current process and forest structure In-Reply-To: <4EDEA27A.6040003@oracle.com> References: <4EDEA27A.6040003@oracle.com> Message-ID: <1323214774.29813.5.camel@moonlight> Hi Kevin & Richard, I find this information very interesting, thanks for posting it. I believe it's good to involve the community not only code-wise but also in infrastructure issues :-) Out of personal interest, I am wondering how much of this integration process is manual vs. automated. If a majority of the tests are automated or can reasonably be made automated, this could be helpful for streamlining the process. There are continuous integration tools (e.g. teamcity) that for example can run a whole bunch of tests and checks pre-push and reject integration into 'golden' repo if that fails. Cheers, Roman > Good summary. Based on a cursory reading of this, it looks pretty > up-to-date to me. Btw, glass will be folded into runtime (initially the > closed repo) later this month. > > > Maybe we do this in two steps -- open source first, and then rearrange to clean things up. Or maybe we do it in one go. > > Could be done either way, although the "do it one go" would probably be > more like: rearrange to clean things up first and then open source > second, since some pieces will be open-sourced earlier than others. > There are pros/cons to either ordering. > > As you can all imagine, there are a lot of details to work out, but this > is a rough idea of where we are headed. > > -- Kevin > > > Richard Bair wrote: > > Hi everyone, > > > > I thought it would be useful to outline our current internal working process, and then describe some of the challenges we need to solve in moving this all out into the open. I'm hoping this sort of insight will help illuminate why everything isn't running smoothly from day one and what we're trying to resolve. > > > > As with the JDK, JavaFX sources are built out of a mercurial forest. The current internal forest structure is basically: > > > > jfx/ - This is the root forest > > jfx/apps - Contains a number of public apps (such as Ensemble and DataApp) and internal apps (which have been ported from FX Script to Java but haven't been blessed) > > jfx/glass - All of the windows / mac / linux / other platform implementations > > jfx/webnode - WebKit, plus some Java code that glues webkit to the public API > > jfx/media - GStreamer, plus some Java code that glues gstreamer to the public API > > jfx/tests - Mostly performance tests > > jfx/runtime - The bulk of the platform -- all controls, charts, etc are in this repo > > > > There are, basically, four forests: > > > > master - The master forest is the forest from which all promotions and releases are built > > graphics - Used by the graphics, scenegraph, and most other teams > > controls - Used by the controls team > > media - Used by the media team > > > > Although mercurial doesn't actually operate this way, you can think of the master as being the root of a tree with graphics, controls, and media as children. Once a week (typically Tuesday) we do integrations. The "integrator" for each child forest will pull the latest from Master into their forest. They will merge up, run tests, run some sample apps, and make sure things are all good to go. They will then push their changesets from their forest (what we call the integration forest or scrum forest) up to the master. The three teams do this according to some negotiated schedule, so that all these merges are done in an orderly fashion. After everybody has integrated, everybody does a fresh pull from master so that after integration, each child forest is in essence sync'd up completely and identical. Then the teams continue working for another week in their own forests, and re-integrate the following Tuesday. > > > > We didn't start with this system in place, at one point we had just a single master. That of course left the master in some undefined state at any given time -- there was no gate to make sure only "good" changes made it to master. So we had an integration and a master forest. But eventually the size of the team became such that we had to split things out further, because changes in one team would be unstable for some few days and this would impact the work of other teams. So we have grown the number of integration forests organically as needed. In general you want as few as you can get away with. > > > > Presently in OpenJFX we have essentially added a fifth integration forest, also called master. Lets call it "openjfx-master". This is actually being populated based on the controls forest. So when the controls folks push fixes into the controls forest, it is propagated to the openjfx-master. This is a short-term position. the openjfx-master is intended to become the real master, and we will fire up additional forests for the controls, graphics, and media scrums to use. At least, that is my first-shot proposal and seems the most sensible since it will mean we continue to work much as we have, and so it will have the least disruption to the team while also opening up the development process. > > > > When somebody has a fix to contribute, they will work with one of these scrum teams (depending on whether it is a controls fix or a media fix or somewhere in the scene graph or core libraries or prism). Fixes will go into the appropriate scrum team forest, and from there will get merged into the master on a weekly basis. > > > > Now, we don't really want to keep forest structure that I described at the start of this message. We really would like to cut down the number of repos in the forest. One proposal is to do something like this: > > > > jfx/ - This is the root forest > > jfx/apps - As presently constituted > > jfx/webkit - WebKit, plus our patches to webkit (but no Java code) > > jfx/gstreamer - GStreamer, plus our patches (but no Java code) > > jfx/rt - The bulk of the platform -- all controls, charts, glass, Java parts for web view, java parts for media, performance tests, other tests, etc > > > > In this arrangement we have reduced the number of forests and, if you are only working on the platform, you generally will only need the rt/ and not the full forest (although personally I think everybody should always use the full forest because when doing find-usages in the IDE it is instructive to also have all the apps and samples and such in front of you). So in the process of open sourcing, we're also planning how to make things a bit cleaner and more accessible to developers than they are currently. > > > > In the old closed runtime, we had a bunch of projects such as: > > > > decora-compiler > > decora-d3d > > decora-d3d-native > > decora-es2 > > decora-jsw > > decora-ogl > > decora-prism > > decora-prism-ps > > decora-prism-sw > > decora-runtime > > decora-sse > > decora-sse-native > > javafx-anim > > javafx-annotation-processor > > javafx-beans > > javafx-common > > javafx-sg-common > > javafx-sg-prism > > javafx-ui-charts > > javafx-ui-common > > javafx-ui-controls > > javafx-ui-quantum > > javafx-ui-webnode > > prism-common > > prism-d3d > > prism-d3d-native > > prism-es2 > > prism-j2d > > prism-jogl > > prism-null > > prism-ps > > prism-util > > > > And a lot more. This has grown organically, and over time we've acquired a fair number of projects. Obviously some of these have a relation: all the decora- ones are related with a single decora-runtime and another compiler and then a pile of backend implementations. There is prism-common and prism-util and a pile of prism implementations. Instead of having a flat directory with a huge pile of different projects, we'd like to organize things when we move these to open source. So for example, maybe we do: > > > > Graphics/Decora/ > > decora-compiler > > decora-d3d > > decora-d3d-native > > decora-es2 > > decora-jsw > > decora-ogl > > decora-prism > > decora-prism-ps > > decora-prism-sw > > decora-runtime > > decora-sse > > decora-sse-native > > Graphics/Prism/ > > prism-common > > prism-d3d > > prism-d3d-native > > prism-es2 > > prism-j2d > > prism-jogl > > prism-null > > prism-ps > > prism-util > > Graphics/Glass/ > > .... > > CoreLibs/ > > javafx-anim > > javafx-beans > > javafx-common > > Controls/ > > javafx-ui-controls > > javafx-ui-charts > > SceneGraph/ > > javafx-ui-common > > WebView/ > > javafx-ui-webnode > > > > I'm totally making this up, but this is the general idea. Maybe we do this in two steps -- open source first, and then rearrange to clean things up. Or maybe we do it in one go. In any case, I wanted to take a few moments and mention at least somewhat of what we're doing. In addition to doing the due-diligence on third party code checks and making sure header files are all correct and so forth, we're also taking a look at the tools used to build and the structure of the forest to see if there is anything we can do to make it easier for developers to grok. It was painful enough just getting new hires up to speed, with all this in the open and trying to make it accessible to a wide range of new engineers it becomes even more important to make it clean and easy to use. > > > > Cheers > > Richard > > > > PS I might be a bit out of date with the exact specifics. I think glass may have already been folded into runtime, and the runtime name is actually not runtime anymore, but I digress. > > From neugens.limasoftware at gmail.com Tue Dec 6 15:45:14 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 7 Dec 2011 00:45:14 +0100 Subject: Controls with Values [was Possible additions to JavaFX to facilitate forms and validations] In-Reply-To: <4EDEA518.5090102@oracle.com> References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> <4EDE4972.8030205@broadpark.no> <67E8E7BD-24DB-4242-81FD-6C35389A7699@oracle.com> <4EDEA518.5090102@oracle.com> Message-ID: <8E1808A6-1FAA-4C13-A3AE-D5C8660FAA69@gmail.com> Il giorno 07/dic/2011, alle ore 00:28, Jim Graham ha scritto: > OK, time for a graphics nerd to put his foot in his mouth and try to sound less than dim-witted in a Controls discussion... > > It feels like the proposals here are heading in the direction of FX owning the data. That's great for applications that never do anything other than display the data on a single FX-capable screen, but I can imagine more complicated applications for whom screen display is only one of their goals/modes of use. > > Consider an application that is meant to view a database. When displaying it on the screen the data needs to be managed by both the database and the FX nodes, but the FX nodes don't really own the data there, that is just one way to manage that part of the interaction. Meanwhile there may be back end modes of this application that run as network services to manage updates to this database through web or net services. It may have a command line interface for batch processing. It may have an HTML5 back end for displaying on devices that don't yet support FX. It may want to support displaying the database on multiple screens or in multiple views on the same screen. > > I don't think the proposals for Controls to "be" properties will necessarily preclude any of that, but would it be more natural for Controls to talk to a property that is owned by the application? In other words, TextFoo is a Control that takes a Text property, it is not itself a text property. And when you do data binding, you would be binding the raw properties that the application manages, not the Control nodes. And when you have multiple views on the same data open then you don't have to have a cloud of self-important nodes that all believe they own the data that needs to be coordinated so they all make sure they own the same version of the data as each other... > > Or am I off base here? > > ...jim No, I think you're perfectly right. In my experience, strict decoupling of Data and View is very important, and the more we make the API capable of easily (and I put accent on *easily*) handle this decoupling, the more you avoid mistakes that pollute renderer. I've seen plenty of example like this, where Swing was misused to the extreme (don't block the EDT mantra anyone?). After all, the View should not really care about the data, it only should know how to represent it graphically, so all the binding should go via properties that the application knows how to manage and the view knows how to render, but indeed the view should never own the data. Cheers, Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From richard.bair at oracle.com Tue Dec 6 15:49:37 2011 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Dec 2011 15:49:37 -0800 Subject: JavaFX Maven support (was: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls.) In-Reply-To: References: Message-ID: <4C2C99B6-35CD-4E56-879D-49736745272F@oracle.com> > Maven support would be fantastic. There's two distinct and independent > aspects to this and it's probably worth making these real clear, especially > for the non-maven users: > > 1. Allow the general public to build their JavaFX applications using Maven. > 2. Allow openjfx developers to build the runtime, etc, using Maven > > The first one is critical for JFX uptake by Maven users - we Maven users > are so hooked into the whole Maven eco-sphere that if something is not in a > maven repo it virtually doesn't exist for us :) > > The second is really a nice to have - so long as the JFX runtime build > process is easy and well documented then it doesn't really matter what > build tool is used (although Maven would make a lot of that modularisation > stuff easier and simplify build scripts significantly). I think #1 is definitely doable, I would be less optimistic about #2 because it introduces a new build time dependency that we've never had before, and if/when we get slurped into the JDK, we'll probably also lose ant and get make, since there is a build team responsible for such things in JDK land. > Regarding the first one (which is my priority), the two things stopping > this from happening right now are: > > 1. The native DLL loading issue. Maven only really works with the classpath > and not the system path for natives, so we need to do some tricks. > 2. The licencing issue - it is currently illegal for anyone other than > Oracle to distribute the runtime, so we can't put the runtime jar or > natives in a public repo yet. On #2 here, when 2.0.2 ships (any day now), to my understanding, the licensing issue will be fixed. SO that is good at least :-). I'll leave the discussion of #1 up to you and Roman and the experts since I have no idea. > There may be other options? > > One bigger question this whole topic raises for me though: what exactly is > the JavaFX installer doing? If it's just a case of getting the natives on > the path to make JavaFX work, why do we have to make users (and developers) > go through the whole, do you want to install JavaFX drama? Why can't it > just be another jar on the path of my custom application - a simple > dependency that I manage, much like I manage my log4j, spring, and datafx > dependencies, etc? A big part of it is the applet. Also, in the near future we'll be co-installed and then co-bundled with Java, so it will be everywhere Java is. > And if it turns out the installer does actually need to run, why doesn't it > just put the jfx natives on the system path so that when the runtime starts > up it will always find it, regardless of where that jfxrt.jar is on the > local filesystem? > > It would be good to get some insight on the inner workings of all this. I'm not sure of the specifics but these are really good questions that Igor could answer. Cheers Richard From kevin.rushforth at oracle.com Tue Dec 6 15:50:29 2011 From: kevin.rushforth at oracle.com (kevin.rushforth at oracle.com) Date: Tue, 06 Dec 2011 23:50:29 +0000 Subject: hg: openjfx/2.1/master/rt: 3 new changesets Message-ID: <20111206235030.31EBC475BE@hg.openjdk.java.net> Changeset: d07657025137 Author: hudson Date: 2011-12-01 10:13 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/d07657025137 Added tag 2.1-b03 for changeset b65602d25894 ! .hgtags Changeset: 4970348dbafd Author: David Grieve Date: 2011-12-06 10:01 -0500 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/4970348dbafd Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.1/MASTER/jfx/rt Changeset: 1145eb73b1b1 Author: leifs Date: 2011-12-06 15:47 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/1145eb73b1b1 Fixed RT-17968: [TextField] selection is not applied immediately. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java From richard.bair at oracle.com Tue Dec 6 15:51:47 2011 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Dec 2011 15:51:47 -0800 Subject: Notes on our current process and forest structure In-Reply-To: <1323214774.29813.5.camel@moonlight> References: <4EDEA27A.6040003@oracle.com> <1323214774.29813.5.camel@moonlight> Message-ID: <7D354640-C5FC-4B4A-94B5-62F573F6C03F@oracle.com> All the unit tests are run automatically, but what we call the "SWAT testing" -- pulling up Ensemble and going through all the pages, pulling up BrickBreaker and playing a round, or whatever other apps they are running (Kevin does this every week so he knows well :-)) is manual. Right now I'm talking with our SQE guys about getting the automated visual testing infrastructure (and with any luck, the tests!) released as well, so maybe that would be a way to make it more automatic? Richard On Dec 6, 2011, at 3:39 PM, Roman Kennke wrote: > Hi Kevin & Richard, > > I find this information very interesting, thanks for posting it. I > believe it's good to involve the community not only code-wise but also > in infrastructure issues :-) > > Out of personal interest, I am wondering how much of this integration > process is manual vs. automated. If a majority of the tests are > automated or can reasonably be made automated, this could be helpful for > streamlining the process. There are continuous integration tools (e.g. > teamcity) that for example can run a whole bunch of tests and checks > pre-push and reject integration into 'golden' repo if that fails. > > Cheers, Roman > >> Good summary. Based on a cursory reading of this, it looks pretty >> up-to-date to me. Btw, glass will be folded into runtime (initially the >> closed repo) later this month. >> >>> Maybe we do this in two steps -- open source first, and then rearrange to clean things up. Or maybe we do it in one go. >> >> Could be done either way, although the "do it one go" would probably be >> more like: rearrange to clean things up first and then open source >> second, since some pieces will be open-sourced earlier than others. >> There are pros/cons to either ordering. >> >> As you can all imagine, there are a lot of details to work out, but this >> is a rough idea of where we are headed. >> >> -- Kevin >> >> >> Richard Bair wrote: >>> Hi everyone, >>> >>> I thought it would be useful to outline our current internal working process, and then describe some of the challenges we need to solve in moving this all out into the open. I'm hoping this sort of insight will help illuminate why everything isn't running smoothly from day one and what we're trying to resolve. >>> >>> As with the JDK, JavaFX sources are built out of a mercurial forest. The current internal forest structure is basically: >>> >>> jfx/ - This is the root forest >>> jfx/apps - Contains a number of public apps (such as Ensemble and DataApp) and internal apps (which have been ported from FX Script to Java but haven't been blessed) >>> jfx/glass - All of the windows / mac / linux / other platform implementations >>> jfx/webnode - WebKit, plus some Java code that glues webkit to the public API >>> jfx/media - GStreamer, plus some Java code that glues gstreamer to the public API >>> jfx/tests - Mostly performance tests >>> jfx/runtime - The bulk of the platform -- all controls, charts, etc are in this repo >>> >>> There are, basically, four forests: >>> >>> master - The master forest is the forest from which all promotions and releases are built >>> graphics - Used by the graphics, scenegraph, and most other teams >>> controls - Used by the controls team >>> media - Used by the media team >>> >>> Although mercurial doesn't actually operate this way, you can think of the master as being the root of a tree with graphics, controls, and media as children. Once a week (typically Tuesday) we do integrations. The "integrator" for each child forest will pull the latest from Master into their forest. They will merge up, run tests, run some sample apps, and make sure things are all good to go. They will then push their changesets from their forest (what we call the integration forest or scrum forest) up to the master. The three teams do this according to some negotiated schedule, so that all these merges are done in an orderly fashion. After everybody has integrated, everybody does a fresh pull from master so that after integration, each child forest is in essence sync'd up completely and identical. Then the teams continue working for another week in their own forests, and re-integrate the following Tuesday. >>> >>> We didn't start with this system in place, at one point we had just a single master. That of course left the master in some undefined state at any given time -- there was no gate to make sure only "good" changes made it to master. So we had an integration and a master forest. But eventually the size of the team became such that we had to split things out further, because changes in one team would be unstable for some few days and this would impact the work of other teams. So we have grown the number of integration forests organically as needed. In general you want as few as you can get away with. >>> >>> Presently in OpenJFX we have essentially added a fifth integration forest, also called master. Lets call it "openjfx-master". This is actually being populated based on the controls forest. So when the controls folks push fixes into the controls forest, it is propagated to the openjfx-master. This is a short-term position. the openjfx-master is intended to become the real master, and we will fire up additional forests for the controls, graphics, and media scrums to use. At least, that is my first-shot proposal and seems the most sensible since it will mean we continue to work much as we have, and so it will have the least disruption to the team while also opening up the development process. >>> >>> When somebody has a fix to contribute, they will work with one of these scrum teams (depending on whether it is a controls fix or a media fix or somewhere in the scene graph or core libraries or prism). Fixes will go into the appropriate scrum team forest, and from there will get merged into the master on a weekly basis. >>> >>> Now, we don't really want to keep forest structure that I described at the start of this message. We really would like to cut down the number of repos in the forest. One proposal is to do something like this: >>> >>> jfx/ - This is the root forest >>> jfx/apps - As presently constituted >>> jfx/webkit - WebKit, plus our patches to webkit (but no Java code) >>> jfx/gstreamer - GStreamer, plus our patches (but no Java code) >>> jfx/rt - The bulk of the platform -- all controls, charts, glass, Java parts for web view, java parts for media, performance tests, other tests, etc >>> >>> In this arrangement we have reduced the number of forests and, if you are only working on the platform, you generally will only need the rt/ and not the full forest (although personally I think everybody should always use the full forest because when doing find-usages in the IDE it is instructive to also have all the apps and samples and such in front of you). So in the process of open sourcing, we're also planning how to make things a bit cleaner and more accessible to developers than they are currently. >>> >>> In the old closed runtime, we had a bunch of projects such as: >>> >>> decora-compiler >>> decora-d3d >>> decora-d3d-native >>> decora-es2 >>> decora-jsw >>> decora-ogl >>> decora-prism >>> decora-prism-ps >>> decora-prism-sw >>> decora-runtime >>> decora-sse >>> decora-sse-native >>> javafx-anim >>> javafx-annotation-processor >>> javafx-beans >>> javafx-common >>> javafx-sg-common >>> javafx-sg-prism >>> javafx-ui-charts >>> javafx-ui-common >>> javafx-ui-controls >>> javafx-ui-quantum >>> javafx-ui-webnode >>> prism-common >>> prism-d3d >>> prism-d3d-native >>> prism-es2 >>> prism-j2d >>> prism-jogl >>> prism-null >>> prism-ps >>> prism-util >>> >>> And a lot more. This has grown organically, and over time we've acquired a fair number of projects. Obviously some of these have a relation: all the decora- ones are related with a single decora-runtime and another compiler and then a pile of backend implementations. There is prism-common and prism-util and a pile of prism implementations. Instead of having a flat directory with a huge pile of different projects, we'd like to organize things when we move these to open source. So for example, maybe we do: >>> >>> Graphics/Decora/ >>> decora-compiler >>> decora-d3d >>> decora-d3d-native >>> decora-es2 >>> decora-jsw >>> decora-ogl >>> decora-prism >>> decora-prism-ps >>> decora-prism-sw >>> decora-runtime >>> decora-sse >>> decora-sse-native >>> Graphics/Prism/ >>> prism-common >>> prism-d3d >>> prism-d3d-native >>> prism-es2 >>> prism-j2d >>> prism-jogl >>> prism-null >>> prism-ps >>> prism-util >>> Graphics/Glass/ >>> .... >>> CoreLibs/ >>> javafx-anim >>> javafx-beans >>> javafx-common >>> Controls/ >>> javafx-ui-controls >>> javafx-ui-charts >>> SceneGraph/ >>> javafx-ui-common >>> WebView/ >>> javafx-ui-webnode >>> >>> I'm totally making this up, but this is the general idea. Maybe we do this in two steps -- open source first, and then rearrange to clean things up. Or maybe we do it in one go. In any case, I wanted to take a few moments and mention at least somewhat of what we're doing. In addition to doing the due-diligence on third party code checks and making sure header files are all correct and so forth, we're also taking a look at the tools used to build and the structure of the forest to see if there is anything we can do to make it easier for developers to grok. It was painful enough just getting new hires up to speed, with all this in the open and trying to make it accessible to a wide range of new engineers it becomes even more important to make it clean and easy to use. >>> >>> Cheers >>> Richard >>> >>> PS I might be a bit out of date with the exact specifics. I think glass may have already been folded into runtime, and the runtime name is actually not runtime anymore, but I digress. >> >> > > From richard.bair at oracle.com Tue Dec 6 15:58:55 2011 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Dec 2011 15:58:55 -0800 Subject: Controls with Values [was Possible additions to JavaFX to facilitate forms and validations] In-Reply-To: <4EDEA518.5090102@oracle.com> References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> <4EDE4972.8030205@broadpark.no> <67E8E7BD-24DB-4242-81FD-6C35389A7699@oracle.com> <4EDEA518.5090102@oracle.com> Message-ID: > I don't think the proposals for Controls to "be" properties will necessarily preclude any of that, but would it be more natural for Controls to talk to a property that is owned by the application? In other words, TextFoo is a Control that takes a Text property, it is not itself a text property. And when you do data binding, you would be binding the raw properties that the application manages, not the Control nodes. And when you have multiple views on the same data open then you don't have to have a cloud of self-important nodes that all believe they own the data that needs to be coordinated so they all make sure they own the same version of the data as each other... Well, this is what happens now. So for example, I have a Person object which has a "name" StringProperty. And the TextField has a "text" StringProperty. So I can do: textField.textProperty().bindBidirectional(person.nameProperty()); Really what is being proposed is to just shorten this, such that TextField would also have the notion of a "value" that it was displaying, and you could bind this value, such as: textField.bindBidirectional(person.nameProperty()) The actual data value is still in the "Person" model object, and the TextField is just displaying the result. The only difference is that basically we've taken one property from the TextField and promoted it to represent the "value" of that Control. In another example, I have a List of Person objects as the data model for my ListView. Instead of: listView.itemsProperty().bind(controller.peopleListProperty()) I can just do: listView.bind(controller.peopleListProperty()) I don't think it actually changes the relationship between the data model and the view. In Martin Fowler's terminology, the "record state" (in the database) is the one true record, and then on the client you have "session state" which is whatever view of the record state existed at the time you did your database query, and the "view state" is just a copy of the session state such as it was at the time you last sync'd it. With binding, we keep the "view state" and "session state" fairly well sync'd -- but as far as the app is concerned, the session state is authoritative and the view state is just a copy of the state (usually converted to a String) for the purpose of display or text entry. Cheers Richard From kevin.rushforth at oracle.com Tue Dec 6 16:08:38 2011 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 06 Dec 2011 22:08:38 -0200 Subject: Notes on our current process and forest structure In-Reply-To: <7D354640-C5FC-4B4A-94B5-62F573F6C03F@oracle.com> References: <4EDEA27A.6040003@oracle.com> <1323214774.29813.5.camel@moonlight> <7D354640-C5FC-4B4A-94B5-62F573F6C03F@oracle.com> Message-ID: <4EDEAE86.9050107@oracle.com> Actually, Jennifer has been doing the graphics integrations for a quite a while (unless she is out), so I just end up keeping tabs on all of the team integrators, and being a general nuisance if anything slips through that oughtn't. :) Getting more automated tests is a very good thing, and there is still much that could, and should, be done in this area to improve things, but I remain very skeptical that we will ever get to the point where manual tests are no longer necessary for a graphics library. -- Kevin Richard Bair wrote: > All the unit tests are run automatically, but what we call the "SWAT testing" -- pulling up Ensemble and going through all the pages, pulling up BrickBreaker and playing a round, or whatever other apps they are running (Kevin does this every week so he knows well :-)) is manual. > > Right now I'm talking with our SQE guys about getting the automated visual testing infrastructure (and with any luck, the tests!) released as well, so maybe that would be a way to make it more automatic? > > Richard > > On Dec 6, 2011, at 3:39 PM, Roman Kennke wrote: > > >> Hi Kevin & Richard, >> >> I find this information very interesting, thanks for posting it. I >> believe it's good to involve the community not only code-wise but also >> in infrastructure issues :-) >> >> Out of personal interest, I am wondering how much of this integration >> process is manual vs. automated. If a majority of the tests are >> automated or can reasonably be made automated, this could be helpful for >> streamlining the process. There are continuous integration tools (e.g. >> teamcity) that for example can run a whole bunch of tests and checks >> pre-push and reject integration into 'golden' repo if that fails. >> >> Cheers, Roman >> >> >>> Good summary. Based on a cursory reading of this, it looks pretty >>> up-to-date to me. Btw, glass will be folded into runtime (initially the >>> closed repo) later this month. >>> >>> >>>> Maybe we do this in two steps -- open source first, and then rearrange to clean things up. Or maybe we do it in one go. >>>> >>> Could be done either way, although the "do it one go" would probably be >>> more like: rearrange to clean things up first and then open source >>> second, since some pieces will be open-sourced earlier than others. >>> There are pros/cons to either ordering. >>> >>> As you can all imagine, there are a lot of details to work out, but this >>> is a rough idea of where we are headed. >>> >>> -- Kevin >>> >>> >>> Richard Bair wrote: >>> >>>> Hi everyone, >>>> >>>> I thought it would be useful to outline our current internal working process, and then describe some of the challenges we need to solve in moving this all out into the open. I'm hoping this sort of insight will help illuminate why everything isn't running smoothly from day one and what we're trying to resolve. >>>> >>>> As with the JDK, JavaFX sources are built out of a mercurial forest. The current internal forest structure is basically: >>>> >>>> jfx/ - This is the root forest >>>> jfx/apps - Contains a number of public apps (such as Ensemble and DataApp) and internal apps (which have been ported from FX Script to Java but haven't been blessed) >>>> jfx/glass - All of the windows / mac / linux / other platform implementations >>>> jfx/webnode - WebKit, plus some Java code that glues webkit to the public API >>>> jfx/media - GStreamer, plus some Java code that glues gstreamer to the public API >>>> jfx/tests - Mostly performance tests >>>> jfx/runtime - The bulk of the platform -- all controls, charts, etc are in this repo >>>> >>>> There are, basically, four forests: >>>> >>>> master - The master forest is the forest from which all promotions and releases are built >>>> graphics - Used by the graphics, scenegraph, and most other teams >>>> controls - Used by the controls team >>>> media - Used by the media team >>>> >>>> Although mercurial doesn't actually operate this way, you can think of the master as being the root of a tree with graphics, controls, and media as children. Once a week (typically Tuesday) we do integrations. The "integrator" for each child forest will pull the latest from Master into their forest. They will merge up, run tests, run some sample apps, and make sure things are all good to go. They will then push their changesets from their forest (what we call the integration forest or scrum forest) up to the master. The three teams do this according to some negotiated schedule, so that all these merges are done in an orderly fashion. After everybody has integrated, everybody does a fresh pull from master so that after integration, each child forest is in essence sync'd up completely and identical. Then the teams continue working for another week in their own forests, and re-integrate the following Tuesday. >>>> >>>> We didn't start with this system in place, at one point we had just a single master. That of course left the master in some undefined state at any given time -- there was no gate to make sure only "good" changes made it to master. So we had an integration and a master forest. But eventually the size of the team became such that we had to split things out further, because changes in one team would be unstable for some few days and this would impact the work of other teams. So we have grown the number of integration forests organically as needed. In general you want as few as you can get away with. >>>> >>>> Presently in OpenJFX we have essentially added a fifth integration forest, also called master. Lets call it "openjfx-master". This is actually being populated based on the controls forest. So when the controls folks push fixes into the controls forest, it is propagated to the openjfx-master. This is a short-term position. the openjfx-master is intended to become the real master, and we will fire up additional forests for the controls, graphics, and media scrums to use. At least, that is my first-shot proposal and seems the most sensible since it will mean we continue to work much as we have, and so it will have the least disruption to the team while also opening up the development process. >>>> >>>> When somebody has a fix to contribute, they will work with one of these scrum teams (depending on whether it is a controls fix or a media fix or somewhere in the scene graph or core libraries or prism). Fixes will go into the appropriate scrum team forest, and from there will get merged into the master on a weekly basis. >>>> >>>> Now, we don't really want to keep forest structure that I described at the start of this message. We really would like to cut down the number of repos in the forest. One proposal is to do something like this: >>>> >>>> jfx/ - This is the root forest >>>> jfx/apps - As presently constituted >>>> jfx/webkit - WebKit, plus our patches to webkit (but no Java code) >>>> jfx/gstreamer - GStreamer, plus our patches (but no Java code) >>>> jfx/rt - The bulk of the platform -- all controls, charts, glass, Java parts for web view, java parts for media, performance tests, other tests, etc >>>> >>>> In this arrangement we have reduced the number of forests and, if you are only working on the platform, you generally will only need the rt/ and not the full forest (although personally I think everybody should always use the full forest because when doing find-usages in the IDE it is instructive to also have all the apps and samples and such in front of you). So in the process of open sourcing, we're also planning how to make things a bit cleaner and more accessible to developers than they are currently. >>>> >>>> In the old closed runtime, we had a bunch of projects such as: >>>> >>>> decora-compiler >>>> decora-d3d >>>> decora-d3d-native >>>> decora-es2 >>>> decora-jsw >>>> decora-ogl >>>> decora-prism >>>> decora-prism-ps >>>> decora-prism-sw >>>> decora-runtime >>>> decora-sse >>>> decora-sse-native >>>> javafx-anim >>>> javafx-annotation-processor >>>> javafx-beans >>>> javafx-common >>>> javafx-sg-common >>>> javafx-sg-prism >>>> javafx-ui-charts >>>> javafx-ui-common >>>> javafx-ui-controls >>>> javafx-ui-quantum >>>> javafx-ui-webnode >>>> prism-common >>>> prism-d3d >>>> prism-d3d-native >>>> prism-es2 >>>> prism-j2d >>>> prism-jogl >>>> prism-null >>>> prism-ps >>>> prism-util >>>> >>>> And a lot more. This has grown organically, and over time we've acquired a fair number of projects. Obviously some of these have a relation: all the decora- ones are related with a single decora-runtime and another compiler and then a pile of backend implementations. There is prism-common and prism-util and a pile of prism implementations. Instead of having a flat directory with a huge pile of different projects, we'd like to organize things when we move these to open source. So for example, maybe we do: >>>> >>>> Graphics/Decora/ >>>> decora-compiler >>>> decora-d3d >>>> decora-d3d-native >>>> decora-es2 >>>> decora-jsw >>>> decora-ogl >>>> decora-prism >>>> decora-prism-ps >>>> decora-prism-sw >>>> decora-runtime >>>> decora-sse >>>> decora-sse-native >>>> Graphics/Prism/ >>>> prism-common >>>> prism-d3d >>>> prism-d3d-native >>>> prism-es2 >>>> prism-j2d >>>> prism-jogl >>>> prism-null >>>> prism-ps >>>> prism-util >>>> Graphics/Glass/ >>>> .... >>>> CoreLibs/ >>>> javafx-anim >>>> javafx-beans >>>> javafx-common >>>> Controls/ >>>> javafx-ui-controls >>>> javafx-ui-charts >>>> SceneGraph/ >>>> javafx-ui-common >>>> WebView/ >>>> javafx-ui-webnode >>>> >>>> I'm totally making this up, but this is the general idea. Maybe we do this in two steps -- open source first, and then rearrange to clean things up. Or maybe we do it in one go. In any case, I wanted to take a few moments and mention at least somewhat of what we're doing. In addition to doing the due-diligence on third party code checks and making sure header files are all correct and so forth, we're also taking a look at the tools used to build and the structure of the forest to see if there is anything we can do to make it easier for developers to grok. It was painful enough just getting new hires up to speed, with all this in the open and trying to make it accessible to a wide range of new engineers it becomes even more important to make it clean and easy to use. >>>> >>>> Cheers >>>> Richard >>>> >>>> PS I might be a bit out of date with the exact specifics. I think glass may have already been folded into runtime, and the runtime name is actually not runtime anymore, but I digress. >>>> >>> >> > > From kevin.rushforth at oracle.com Tue Dec 6 16:16:01 2011 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 06 Dec 2011 22:16:01 -0200 Subject: Attempting to Build [ was Source code for JavaFX UI controls now available on openjfx] In-Reply-To: References: <4ED95442.5070403@oracle.com> <651B13B4-A077-45E0-856F-60CBEFFA13D4@gmail.com> <3256D7C0-3DC1-44A8-8F78-592050C2B0F4@gmail.com> <4ED96727.1040502@oracle.com> <2F7DEE03-9940-4820-9CBE-7883FF86C20D@oracle.com> Message-ID: <4EDEB041.5020501@oracle.com> Regarding #4 I think Jonathan added a property (or was going to add one) so you don't have to copy it in, although copying it may be the easiest way to do it anyway. Regarding having to comment out the propertycopy ant task, I filed http://javafx-jira.kenai.com/browse/RT-18408 to track this. -- Kevin Richard Bair wrote: > The missing scripts have been pushed, so I think I can now give reproducible instructions for building and testing. Download the 2.1 binary for Mac from http://www.oracle.com/technetwork/java/javafx/downloads/javafx2-macosx-487281.html. > > 1) hg clone http://hg.openjdk.java.net/openjfx/2.1/master > 2) cd master > 3) mkdir -p artifacts/sdk/rt/lib > 4) cp ~/Downloads/javafx-sdk2.1.0-beta/rt/lib/jfxrt.jar artifacts/sdk/rt/lib > - Or from wherever you have downloaded this file > 5) hg clone hg.openjdk.java.net/openjfx/2.1/master/rt > 6) vi build-defs.xml > - There is some library being used but not registered properly, there is probably another way to do this. > Anyway, just edit the master/rt/build-defs.xml and comment out the line: > > 7) cd javafx-ui-controls > 8) ant > > That should be enough to actually have built the project. The built class files should be sitting in master/rt/javafx-ui-common/dist/javafx-ui-controls.jar. You can then run by placing the newly created javafx-ui-controls.jar before jfxrt.jar on your classpath. > > Let me know if you have any success! > Thanks > Richard > > On Dec 6, 2011, at 9:46 AM, Richard Bair wrote: > > >> If you got to Oracle.com and download JavaFX and find the tiny link that switches to the Mac Developer Preview download and grab it, you will get a very recent 2.1 build. This can be used as the binary plug for building. Unfortunately, some build files are missing in the master/ repo. I tried to push these files in, but the server is not happy with my ssl configuration. I'm trying to track that down. With those build files put in, there is one other slight modification to master/rt/build-defs.xml, but this will then allow you to actually build the controls repo and, if you are on Mac, run it. >> >> I'll keep you all abreast of the work, hopefully we'll have something fully buildable a little later today. >> >> Richard >> >> >> On Dec 2, 2011, at 5:43 PM, Richard Bair wrote: >> >> >>>> Sorry I misunderstood, I was expecting something similar to the binary plugs we had in OpenJDK, not a full version of the current release, hence the question. >>>> >>>> I was able to import the project successfully into eclipse (and netbeans) with the FX runtime and it seems to compile fine. >>>> >>> Oh, that's interesting. I grabbed the latest 2.0.2 code for Mac that I had available but it was failing on: >>> >>> [javac] /Developer/Projects/openjfx/workspace-2.1/master/rt/javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ButtonBehavior.java:42: cannot find symbol >>> [javac] symbol : class PlatformUtil >>> [javac] location: package com.sun.javafx >>> [javac] import com.sun.javafx.PlatformUtil; >>> [javac] ^ >>> >>> And a bunch of other such failures. So I thought PlatformUtil had been removed between the 2.0.2 code I had (from early November) and the newer code in the 2.1 tree. If you got it to build in Eclipse on an older release -- well that is interesting! What version of JavaFX are you using for the binary plug? >>> >>> Do you want to post some basic instructions so other folks can do likewise? >>> >>> >>>> I'll play with this code a bit and see how we can help out until everything else is sorted out. >>>> >>>> I think that while this is a suboptimal situation (but hey, we Free Software freaks are never happy, right? :) is still a great step forward, and we have a chance to study the code and the internals before everything gets released. >>>> >>>> Speaking about this, do you think we can have some "specs" about the internal interfaces? >>>> >>> Probably in the short term asking me questions is the fastest way to get answers, unfortunately. I do need to be badgered to write up some documents though and put them up on our pages. Please do feel free to badger me: squeaky wheel and all that :-) >>> >>> >>>> I know from JavaOne that the internal code is pretty abstracted and modular, and can actually be "easily" replaced (not sure the exact definition of easily though, but what you have shown at J1 was very impressive). >>>> >>>> We can probably help speeding up things if we know what things should be replaced and implement some clear room version of what will come later in the game, in a similar way we did with the Pisces renderer in Java2D, what do you think? >>>> >>>> I'm specifically thinking about the Linux port here, since to be honest "late 2012" is eons away. >>>> >>> What we have released so far is the controls portion, which all sits above the "toolkit implementation" line. Basically on the "top" we've got controls, scene graph, css, properties, binding, collections, services, and that sort of thing. There is a Toolkit interface (com.sun.javafx.tk.Toolkit) which defines the abstraction between the public API portions of the platform and the underlying toolkit implementation (threading, windowing, opengl, d3d, fonts, etc). >>> >>> Likely it will be a couple months before we start putting out the lower-level bits en masse, due to having to be careful there over 3rd party code etc (there isn't much, mostly fonts and some SVG, but we have to do all the due diligence). The other problem is the same guys who have to do that, have to get the Mac port finished (both for Java 7 and for Java FX). However I will follow up with the guys doing linux and see if we can get that out sooner (they're busy working away on it and it would be cool to get it open faster, but at the very least get it included in the bits so you can run on linux). >>> >>> Cheers >>> Richard >>> > > From tom.schindl at bestsolution.at Tue Dec 6 16:19:36 2011 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 07 Dec 2011 01:19:36 +0100 Subject: Controls with Values [was Possible additions to JavaFX to facilitate forms and validations] In-Reply-To: References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> <4EDE4972.8030205@broadpark.no> <67E8E7BD-24DB-4242-81FD-6C35389A7699@oracle.com> <4EDEA518.5090102@oracle.com> Message-ID: <4EDEB118.6010702@bestsolution.at> Am 07.12.11 00:58, schrieb Richard Bair: >> I don't think the proposals for Controls to "be" properties will necessarily preclude any of that, but would it be more natural for Controls to talk to a property that is owned by the application? In other words, TextFoo is a Control that takes a Text property, it is not itself a text property. And when you do data binding, you would be binding the raw properties that the application manages, not the Control nodes. And when you have multiple views on the same data open then you don't have to have a cloud of self-important nodes that all believe they own the data that needs to be coordinated so they all make sure they own the same version of the data as each other... > > Well, this is what happens now. So for example, I have a Person object which has a "name" StringProperty. And the TextField has a "text" StringProperty. So I can do: > > textField.textProperty().bindBidirectional(person.nameProperty()); > > Really what is being proposed is to just shorten this, such that TextField would also have the notion of a "value" that it was displaying, and you could bind this value, such as: > > textField.bindBidirectional(person.nameProperty()) > > The actual data value is still in the "Person" model object, and the TextField is just displaying the result. The only difference is that basically we've taken one property from the TextField and promoted it to represent the "value" of that Control. In another example, I have a List of Person objects as the data model for my ListView. Instead of: > > listView.itemsProperty().bind(controller.peopleListProperty()) > > I can just do: > > listView.bind(controller.peopleListProperty()) > > I don't think it actually changes the relationship between the data model and the view. In Martin Fowler's terminology, the "record state" (in the database) is the one true record, and then on the client you have "session state" which is whatever view of the record state existed at the time you did your database query, and the "view state" is just a copy of the session state such as it was at the time you last sync'd it. With binding, we keep the "view state" and "session state" fairly well sync'd -- but as far as the app is concerned, the session state is authoritative and the view state is just a copy of the state (usually converted to a String) for the purpose of display or text entry. > > Cheers > Richard On List/Table/Tree the value you want to bind is not predefined: a) items (=content) b) selection, including multi-selection I'm not sure makeing the binding directly on the Control is a good idea because you start to clutter the interface of the control with methods. I think the important thing Daniel was proposing that Controls have a way to provide a property with the same name pointing to the "domain value property" so that there's no difference between e.g. binding the value of a Text, Checkbox, ... so in fact "valueProperty" is simply a synonym for Text#textProperty and so all toolings understand this property by default (including FXML) and don't need to make an extra case. So I'm with the proposal from Daniel to introduce an interface control subclasses can implement optionally (it might not make sense to all of them) and e.g. things like ToggleGroup could implement it as well which is not a subclass of Control. 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 richard.bair at oracle.com Tue Dec 6 16:20:28 2011 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 6 Dec 2011 16:20:28 -0800 Subject: Attempting to Build [ was Source code for JavaFX UI controls now available on openjfx] In-Reply-To: <4EDEB041.5020501@oracle.com> References: <4ED95442.5070403@oracle.com> <651B13B4-A077-45E0-856F-60CBEFFA13D4@gmail.com> <3256D7C0-3DC1-44A8-8F78-592050C2B0F4@gmail.com> <4ED96727.1040502@oracle.com> <2F7DEE03-9940-4820-9CBE-7883FF86C20D@oracle.com> <4EDEB041.5020501@oracle.com> Message-ID: Ya the property is in javafx-ui-common/project.properties called JFXRT_HOME. If you just set this property then you don't have to manually move the jfxrt.jar into artifacts/sdk/rt/lib. Thanks for filing the issue! Richard On Dec 6, 2011, at 4:16 PM, Kevin Rushforth wrote: > Regarding #4 I think Jonathan added a property (or was going to add one) so you don't have to copy it in, although copying it may be the easiest way to do it anyway. > > Regarding having to comment out the propertycopy ant task, I filed http://javafx-jira.kenai.com/browse/RT-18408 to track this. > > -- Kevin > > > Richard Bair wrote: >> >> The missing scripts have been pushed, so I think I can now give reproducible instructions for building and testing. Download the 2.1 binary for Mac from http://www.oracle.com/technetwork/java/javafx/downloads/javafx2-macosx-487281.html. >> >> 1) hg clone http://hg.openjdk.java.net/openjfx/2.1/master >> 2) cd master >> 3) mkdir -p artifacts/sdk/rt/lib >> 4) cp ~/Downloads/javafx-sdk2.1.0-beta/rt/lib/jfxrt.jar artifacts/sdk/rt/lib >> - Or from wherever you have downloaded this file >> 5) hg clone hg.openjdk.java.net/openjfx/2.1/master/rt >> 6) vi build-defs.xml >> - There is some library being used but not registered properly, there is probably another way to do this. >> Anyway, just edit the master/rt/build-defs.xml and comment out the line: >> >> 7) cd javafx-ui-controls >> 8) ant >> >> That should be enough to actually have built the project. The built class files should be sitting in master/rt/javafx-ui-common/dist/javafx-ui-controls.jar. You can then run by placing the newly created javafx-ui-controls.jar before jfxrt.jar on your classpath. >> >> Let me know if you have any success! >> Thanks >> Richard >> >> On Dec 6, 2011, at 9:46 AM, Richard Bair wrote: >> >> >>> If you got to Oracle.com and download JavaFX and find the tiny link that switches to the Mac Developer Preview download and grab it, you will get a very recent 2.1 build. This can be used as the binary plug for building. Unfortunately, some build files are missing in the master/ repo. I tried to push these files in, but the server is not happy with my ssl configuration. I'm trying to track that down. With those build files put in, there is one other slight modification to master/rt/build-defs.xml, but this will then allow you to actually build the controls repo and, if you are on Mac, run it. >>> >>> I'll keep you all abreast of the work, hopefully we'll have something fully buildable a little later today. >>> >>> Richard >>> >>> >>> On Dec 2, 2011, at 5:43 PM, Richard Bair wrote: >>> >>> >>>>> Sorry I misunderstood, I was expecting something similar to the binary plugs we had in OpenJDK, not a full version of the current release, hence the question. >>>>> >>>>> I was able to import the project successfully into eclipse (and netbeans) with the FX runtime and it seems to compile fine. >>>>> >>>> Oh, that's interesting. I grabbed the latest 2.0.2 code for Mac that I had available but it was failing on: >>>> >>>> [javac] /Developer/Projects/openjfx/workspace-2.1/master/rt/javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ButtonBehavior.java:42: cannot find symbol >>>> [javac] symbol : class PlatformUtil >>>> [javac] location: package com.sun.javafx >>>> [javac] import com.sun.javafx.PlatformUtil; >>>> [javac] ^ >>>> >>>> And a bunch of other such failures. So I thought PlatformUtil had been removed between the 2.0.2 code I had (from early November) and the newer code in the 2.1 tree. If you got it to build in Eclipse on an older release -- well that is interesting! What version of JavaFX are you using for the binary plug? >>>> >>>> Do you want to post some basic instructions so other folks can do likewise? >>>> >>>> >>>>> I'll play with this code a bit and see how we can help out until everything else is sorted out. >>>>> >>>>> I think that while this is a suboptimal situation (but hey, we Free Software freaks are never happy, right? :) is still a great step forward, and we have a chance to study the code and the internals before everything gets released. >>>>> >>>>> Speaking about this, do you think we can have some "specs" about the internal interfaces? >>>>> >>>> Probably in the short term asking me questions is the fastest way to get answers, unfortunately. I do need to be badgered to write up some documents though and put them up on our pages. Please do feel free to badger me: squeaky wheel and all that :-) >>>> >>>> >>>>> I know from JavaOne that the internal code is pretty abstracted and modular, and can actually be "easily" replaced (not sure the exact definition of easily though, but what you have shown at J1 was very impressive). >>>>> >>>>> We can probably help speeding up things if we know what things should be replaced and implement some clear room version of what will come later in the game, in a similar way we did with the Pisces renderer in Java2D, what do you think? >>>>> >>>>> I'm specifically thinking about the Linux port here, since to be honest "late 2012" is eons away. >>>>> >>>> What we have released so far is the controls portion, which all sits above the "toolkit implementation" line. Basically on the "top" we've got controls, scene graph, css, properties, binding, collections, services, and that sort of thing. There is a Toolkit interface (com.sun.javafx.tk.Toolkit) which defines the abstraction between the public API portions of the platform and the underlying toolkit implementation (threading, windowing, opengl, d3d, fonts, etc). >>>> >>>> Likely it will be a couple months before we start putting out the lower-level bits en masse, due to having to be careful there over 3rd party code etc (there isn't much, mostly fonts and some SVG, but we have to do all the due diligence). The other problem is the same guys who have to do that, have to get the Mac port finished (both for Java 7 and for Java FX). However I will follow up with the guys doing linux and see if we can get that out sooner (they're busy working away on it and it would be cool to get it open faster, but at the very least get it included in the bits so you can run on linux). >>>> >>>> Cheers >>>> Richard >>>> >> >> From igor.nekrestyanov at oracle.com Tue Dec 6 16:22:19 2011 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Tue, 06 Dec 2011 16:22:19 -0800 Subject: JavaFX Maven support (was: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls.) In-Reply-To: <4C2C99B6-35CD-4E56-879D-49736745272F@oracle.com> References: <4C2C99B6-35CD-4E56-879D-49736745272F@oracle.com> Message-ID: <4EDEB1BB.5000409@oracle.com> >> >> One bigger question this whole topic raises for me though: what exactly is >> the JavaFX installer doing? If it's just a case of getting the natives on >> the path to make JavaFX work, why do we have to make users (and developers) >> go through the whole, do you want to install JavaFX drama? Why can't it >> just be another jar on the path of my custom application - a simple >> dependency that I manage, much like I manage my log4j, spring, and datafx >> dependencies, etc? > A big part of it is the applet. Also, in the near future we'll be co-installed and then co-bundled with Java, so it will be everywhere Java is. There are many reasons to have installer. To be able to launch JavaFX application embedded in the browser or using Webstart we need to have JavaFX aware plugin/deployment stack to be registered in the browser. As of now we expect JavaFX to work on top of JRE6 and therefore we ship new version of deployment stack as part of JavaFX. To register it in the browser/OS on Windows you need to make registry changes. This is one big reason to have install JavaFX runtime. We also assume that JavaFX runtime is shared install per system (or eventually per user) and then we want to be able to keep track of what users have installed/use and autoupdate it when important updates are available (e.g. security). We also use the fact that JavaFX runtime is installed to be able to autodetect runtime install path when standalone application is being launched and to ensure other requirements are met (e.g. application may require specific version of JavaFX to be available or presence of compatible JRE). IDE like Netbeans can also detect where runtime/sdk is installed and validate that libraries used to compile code . Overall, having installer helps to ensure typical user/developer has reasonable environment. We realize it may be not perfect way for everybody and this does not mean other distribution options are not possible. E.g. 1) Cobundling JavaFX Runtime with the application In that case application is responsible to update private copy of runtime and there are no detection issues 2) Installing JavaFX runtime as part of JRE or as JDK8 module 3) shipping JavaFX SDK as zip or maven module, etc. I can not tell if Oracle will officially support any of them for binaries distributed by Oracle. Adding new official artifacts contributes to the test/support costs and it is not my call anyways but once JavaFX code is open sourced alternative/additional build artifacts can be easily added. Like Oracle does not provide official JRE/JDK packages tailored for each of existing flavors of Linux but distro vendors can create them based on OpenJDK if desired. >> And if it turns out the installer does actually need to run, why doesn't it >> just put the jfx natives on the system path so that when the runtime starts >> up it will always find it, regardless of where that jfxrt.jar is on the >> local filesystem? BTW, having open lookup path for native libraries is generally security hole that intruder may use if he finds a way to add file to the directory on the path. -igor From jonathan.giles at oracle.com Tue Dec 6 16:33:12 2011 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 07 Dec 2011 10:33:12 +1000 Subject: Attempting to Build [ was Source code for JavaFX UI controls now available on openjfx] In-Reply-To: References: <4ED95442.5070403@oracle.com> <651B13B4-A077-45E0-856F-60CBEFFA13D4@gmail.com> <3256D7C0-3DC1-44A8-8F78-592050C2B0F4@gmail.com> <4ED96727.1040502@oracle.com> <2F7DEE03-9940-4820-9CBE-7883FF86C20D@oracle.com> <4EDEB041.5020501@oracle.com> Message-ID: <4EDEB448.701@oracle.com> I don't believe this variable is fully implemented. I actually define the same property up in the rt/build-defs.xml file, but there needs to be some more work in the javafx-ui-controls folder to only use this reference. I've made some half-attempts at getting this all hooked up in the past, but haven't yet completed it. There are a number of paths that need testing: * compile from rt-closed, * compile from 'jfx'/root directory with 'ant clean dev-build', * compile from within javafx-ui-controls folder, * compilation from within NetBeans. Also, it's worth noting that in the same part of build-defs.xml I pull in all environment variables, so if the developer simply sets JFXRT_HOME to a path on their file system in the environment settings, this should be picked up (although with the caveat that ant doesn't apparently support environment variables in all operating systems). Once I'm back from vacation, if nobody else has taken a look at JFXRT_HOME improvements (and indeed whether we should be pointing at JFXRT_HOME, or more simply JFX_HOME (which may be a directory or two higher up the path)), I'll take another stab at it. -- Jonathan On Wednesday, 7 December 2011 10:20:28 a.m., Richard Bair wrote: > > Ya the property is in javafx-ui-common/project.properties called > JFXRT_HOME. If you just set this property then you don't have to > manually move the jfxrt.jar into artifacts/sdk/rt/lib. > > Thanks for filing the issue! > > Richard > > > On Dec 6, 2011, at 4:16 PM, Kevin Rushforth wrote: > >> >> Regarding #4 I think Jonathan added a property (or was going to add >> one) so you don't have to copy it in, although copying it may be the >> easiest way to do it anyway. >> >> Regarding having to comment out the propertycopy ant task, I filed >> http://javafx-jira.kenai.com/browse/RT-18408 to track this. >> >> -- Kevin >> >> >> Richard Bair wrote: >>> >>> >>> The missing scripts have been pushed, so I think I can now give >>> reproducible instructions for building and testing. Download the 2.1 >>> binary for Mac from >>> http://www.oracle.com/technetwork/java/javafx/downloads/javafx2-macosx-487281.html. >>> >>> 1) hg clone http://hg.openjdk.java.net/openjfx/2.1/master >>> 2) cd master >>> 3) mkdir -p artifacts/sdk/rt/lib >>> 4) cp ~/Downloads/javafx-sdk2.1.0-beta/rt/lib/jfxrt.jar >>> artifacts/sdk/rt/lib >>> - Or from wherever you have downloaded this file >>> 5) hg clone hg.openjdk.java.net/openjfx/2.1/master/rt >>> 6) vi build-defs.xml >>> - There is some library being used but not registered properly, >>> there is probably another way to do this. >>> Anyway, just edit the master/rt/build-defs.xml and comment out the line: >>> >> from="${ant.project.name}.javac.debuglevel" silent="true" >>> override="true"/> >>> 7) cd javafx-ui-controls >>> 8) ant >>> >>> That should be enough to actually have built the project. The built >>> class files should be sitting in >>> master/rt/javafx-ui-common/dist/javafx-ui-controls.jar. You can then >>> run by placing the newly created javafx-ui-controls.jar before >>> jfxrt.jar on your classpath. >>> >>> Let me know if you have any success! >>> Thanks >>> Richard >>> >>> On Dec 6, 2011, at 9:46 AM, Richard Bair wrote: >>> >>> >>>> >>>> If you got to Oracle.com and download JavaFX and find the tiny link >>>> that switches to the Mac Developer Preview download and grab it, >>>> you will get a very recent 2.1 build. This can be used as the >>>> binary plug for building. Unfortunately, some build files are >>>> missing in the master/ repo. I tried to push these files in, but >>>> the server is not happy with my ssl configuration. I'm trying to >>>> track that down. With those build files put in, there is one other >>>> slight modification to master/rt/build-defs.xml, but this will then >>>> allow you to actually build the controls repo and, if you are on >>>> Mac, run it. >>>> >>>> I'll keep you all abreast of the work, hopefully we'll have >>>> something fully buildable a little later today. >>>> >>>> Richard >>>> >>>> >>>> On Dec 2, 2011, at 5:43 PM, Richard Bair wrote: >>>> >>>> >>>>> >>>>>> >>>>>> Sorry I misunderstood, I was expecting something similar to the >>>>>> binary plugs we had in OpenJDK, not a full version of the current >>>>>> release, hence the question. >>>>>> >>>>>> I was able to import the project successfully into eclipse (and >>>>>> netbeans) with the FX runtime and it seems to compile fine. >>>>>> >>>>> >>>>> Oh, that's interesting. I grabbed the latest 2.0.2 code for Mac >>>>> that I had available but it was failing on: >>>>> >>>>> [javac] >>>>> /Developer/Projects/openjfx/workspace-2.1/master/rt/javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ButtonBehavior.java:42: >>>>> cannot find symbol >>>>> [javac] symbol : class PlatformUtil >>>>> [javac] location: package com.sun.javafx >>>>> [javac] import com.sun.javafx.PlatformUtil; >>>>> [javac] ^ >>>>> >>>>> And a bunch of other such failures. So I thought PlatformUtil had >>>>> been removed between the 2.0.2 code I had (from early November) >>>>> and the newer code in the 2.1 tree. If you got it to build in >>>>> Eclipse on an older release -- well that is interesting! What >>>>> version of JavaFX are you using for the binary plug? >>>>> >>>>> Do you want to post some basic instructions so other folks can do >>>>> likewise? >>>>> >>>>> >>>>>> >>>>>> I'll play with this code a bit and see how we can help out until >>>>>> everything else is sorted out. >>>>>> >>>>>> I think that while this is a suboptimal situation (but hey, we >>>>>> Free Software freaks are never happy, right? :) is still a great >>>>>> step forward, and we have a chance to study the code and the >>>>>> internals before everything gets released. >>>>>> >>>>>> Speaking about this, do you think we can have some "specs" about >>>>>> the internal interfaces? >>>>>> >>>>> >>>>> Probably in the short term asking me questions is the fastest way >>>>> to get answers, unfortunately. I do need to be badgered to write >>>>> up some documents though and put them up on our pages. Please do >>>>> feel free to badger me: squeaky wheel and all that :-) >>>>> >>>>> >>>>>> >>>>>> I know from JavaOne that the internal code is pretty abstracted >>>>>> and modular, and can actually be "easily" replaced (not sure the >>>>>> exact definition of easily though, but what you have shown at J1 >>>>>> was very impressive). >>>>>> >>>>>> We can probably help speeding up things if we know what things >>>>>> should be replaced and implement some clear room version of what >>>>>> will come later in the game, in a similar way we did with the >>>>>> Pisces renderer in Java2D, what do you think? >>>>>> >>>>>> I'm specifically thinking about the Linux port here, since to be >>>>>> honest "late 2012" is eons away. >>>>>> >>>>> >>>>> What we have released so far is the controls portion, which all >>>>> sits above the "toolkit implementation" line. Basically on the >>>>> "top" we've got controls, scene graph, css, properties, binding, >>>>> collections, services, and that sort of thing. There is a Toolkit >>>>> interface (com.sun.javafx.tk.Toolkit) which defines the >>>>> abstraction between the public API portions of the platform and >>>>> the underlying toolkit implementation (threading, windowing, >>>>> opengl, d3d, fonts, etc). >>>>> >>>>> Likely it will be a couple months before we start putting out the >>>>> lower-level bits en masse, due to having to be careful there over >>>>> 3rd party code etc (there isn't much, mostly fonts and some SVG, >>>>> but we have to do all the due diligence). The other problem is the >>>>> same guys who have to do that, have to get the Mac port finished >>>>> (both for Java 7 and for Java FX). However I will follow up with >>>>> the guys doing linux and see if we can get that out sooner >>>>> (they're busy working away on it and it would be cool to get it >>>>> open faster, but at the very least get it included in the bits so >>>>> you can run on linux). >>>>> >>>>> Cheers >>>>> Richard >>>>> >>>> >>> >>> >>> >> > From james.graham at oracle.com Tue Dec 6 16:50:01 2011 From: james.graham at oracle.com (Jim Graham) Date: Tue, 06 Dec 2011 16:50:01 -0800 Subject: Controls with Values [was Possible additions to JavaFX to facilitate forms and validations] In-Reply-To: References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> <4EDE4972.8030205@broadpark.no> <67E8E7BD-24DB-4242-81FD-6C35389A7699@oracle.com> <4EDEA518.5090102@oracle.com> Message-ID: <4EDEB839.9060704@oracle.com> Ah, I see. The fact that you are making it easier to refer to the Control's "typical" data does not necessarily mean that it will own that data. Yes, the current call sequences to perform binding are fairly verbose so reducing the common cases would be a nice feat... ...jim On 12/6/11 3:58 PM, Richard Bair wrote: >> I don't think the proposals for Controls to "be" properties will necessarily preclude any of that, but would it be more natural for Controls to talk to a property that is owned by the application? In other words, TextFoo is a Control that takes a Text property, it is not itself a text property. And when you do data binding, you would be binding the raw properties that the application manages, not the Control nodes. And when you have multiple views on the same data open then you don't have to have a cloud of self-important nodes that all believe they own the data that needs to be coordinated so they all make sure they own the same version of the data as each other... > > Well, this is what happens now. So for example, I have a Person object which has a "name" StringProperty. And the TextField has a "text" StringProperty. So I can do: > > textField.textProperty().bindBidirectional(person.nameProperty()); > > Really what is being proposed is to just shorten this, such that TextField would also have the notion of a "value" that it was displaying, and you could bind this value, such as: > > textField.bindBidirectional(person.nameProperty()) > > The actual data value is still in the "Person" model object, and the TextField is just displaying the result. The only difference is that basically we've taken one property from the TextField and promoted it to represent the "value" of that Control. In another example, I have a List of Person objects as the data model for my ListView. Instead of: > > listView.itemsProperty().bind(controller.peopleListProperty()) > > I can just do: > > listView.bind(controller.peopleListProperty()) > > I don't think it actually changes the relationship between the data model and the view. In Martin Fowler's terminology, the "record state" (in the database) is the one true record, and then on the client you have "session state" which is whatever view of the record state existed at the time you did your database query, and the "view state" is just a copy of the session state such as it was at the time you last sync'd it. With binding, we keep the "view state" and "session state" fairly well sync'd -- but as far as the app is concerned, the session state is authoritative and the view state is just a copy of the state (usually converted to a String) for the purpose of display or text entry. > > Cheers > Richard From zonski at googlemail.com Tue Dec 6 18:09:35 2011 From: zonski at googlemail.com (Daniel Zwolenski) Date: Wed, 7 Dec 2011 13:09:35 +1100 Subject: Controls with Values [was Possible additions to JavaFX to facilitate forms and validations] In-Reply-To: <4EDEB118.6010702@bestsolution.at> References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> <4EDE4972.8030205@broadpark.no> <67E8E7BD-24DB-4242-81FD-6C35389A7699@oracle.com> <4EDEA518.5090102@oracle.com> <4EDEB118.6010702@bestsolution.at> Message-ID: Good discussions on this. I agree with Tom (who agrees with me :) ). Having a 'value' property and a HasValue interface feels a little more honest to me. Binding to the value of a choicebox is how I would conceptualise it in my head, whereas binding to a checkbox might imply that I am binding to all properties of it or maybe its visual properties. You can see newbies trying to bind to it and hoping they will get notified when its bounds change, etc. Also I reckon making it a separate value will make it easier to implement/extend. If I build a custom date picker, I simply have to expose my ObjectProperty as the value property and I'm away, whereas if I have to extend an AbstractValueControl it gets messy. With respect to the property for List, Tree and Table (i.e. things that support multselection), I think we need to support the two basic use cases. Single selection, I want to use my list much as a I would use a ChoiceBox, so the value is just the currently selected row. Multi-selection I want to have an observable list that I can watch and get the selected values from. To me the most workable solution from the end users perspective is to have two fields: a HasValue.valueProperty() and a HasValues.values() ObservableList. It would be nice if there was a cleaner way, but if we go the ObservableList for the value then we end up with an ObservableProperty containing an ObservableList which makes the multi-selection painful (I have to listen to both for changes) and the single selection even more so (I have to list to both, then map to my single value). Just my thoughts anyway. On Wed, Dec 7, 2011 at 11:19 AM, Tom Schindl wrote: > Am 07.12.11 00:58, schrieb Richard Bair: > >> I don't think the proposals for Controls to "be" properties will > necessarily preclude any of that, but would it be more natural for Controls > to talk to a property that is owned by the application? In other words, > TextFoo is a Control that takes a Text property, it is not itself a text > property. And when you do data binding, you would be binding the raw > properties that the application manages, not the Control nodes. And when > you have multiple views on the same data open then you don't have to have a > cloud of self-important nodes that all believe they own the data that needs > to be coordinated so they all make sure they own the same version of the > data as each other... > > > > Well, this is what happens now. So for example, I have a Person object > which has a "name" StringProperty. And the TextField has a "text" > StringProperty. So I can do: > > > > textField.textProperty().bindBidirectional(person.nameProperty()); > > > > Really what is being proposed is to just shorten this, such that > TextField would also have the notion of a "value" that it was displaying, > and you could bind this value, such as: > > > > textField.bindBidirectional(person.nameProperty()) > > > > The actual data value is still in the "Person" model object, and the > TextField is just displaying the result. The only difference is that > basically we've taken one property from the TextField and promoted it to > represent the "value" of that Control. In another example, I have a List of > Person objects as the data model for my ListView. Instead of: > > > > listView.itemsProperty().bind(controller.peopleListProperty()) > > > > I can just do: > > > > listView.bind(controller.peopleListProperty()) > > > > I don't think it actually changes the relationship between the data > model and the view. In Martin Fowler's terminology, the "record state" (in > the database) is the one true record, and then on the client you have > "session state" which is whatever view of the record state existed at the > time you did your database query, and the "view state" is just a copy of > the session state such as it was at the time you last sync'd it. With > binding, we keep the "view state" and "session state" fairly well sync'd -- > but as far as the app is concerned, the session state is authoritative and > the view state is just a copy of the state (usually converted to a String) > for the purpose of display or text entry. > > > > Cheers > > Richard > > On List/Table/Tree the value you want to bind is not predefined: > a) items (=content) > b) selection, including multi-selection > > I'm not sure makeing the binding directly on the Control is a good idea > because you start to clutter the interface of the control with methods. > > I think the important thing Daniel was proposing that Controls have a > way to provide a property with the same name pointing to the "domain > value property" so that there's no difference between e.g. binding the > value of a Text, Checkbox, ... so in fact "valueProperty" is simply a > synonym for Text#textProperty and so all toolings understand this > property by default (including FXML) and don't need to make an extra case. > > So I'm with the proposal from Daniel to introduce an interface control > subclasses can implement optionally (it might not make sense to all of > them) and e.g. things like ToggleGroup could implement it as well which > is not a subclass of Control. > > 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 zonski at googlemail.com Tue Dec 6 22:06:32 2011 From: zonski at googlemail.com (Daniel Zwolenski) Date: Wed, 7 Dec 2011 17:06:32 +1100 Subject: JavaFX Maven support (was: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls.) In-Reply-To: <4EDEB1BB.5000409@oracle.com> References: <4C2C99B6-35CD-4E56-879D-49736745272F@oracle.com> <4EDEB1BB.5000409@oracle.com> Message-ID: Hi Igor, Thanks for the info, some comments inline below. To be able to launch JavaFX application embedded in the browser or using > Webstart we need to have JavaFX aware plugin/deployment stack to be > registered in the browser. > The plugin to run Java makes sense, and this has been around for a while now. Improving it is nice, but this should be done back in the core JRE area I would have thought? It's the 'install' of JavaFX that I am confused about. I'm possibly over simplifying things but if JavaFX is just a jar and some native DLLs then isn't it just another library that gets added to the classpath like everything else? Ideally installing the plugin(s) really needs to be simple (1 or 2 click install). Currently the Java one takes me off to another page and makes me jump through a lot more hoops and then the JFX one has another go at me. It would be great if we could work out ways to avoid these hoops. Maybe the co-bundling will fix all this, but it would be nice to just streamline everything as soon as possible. The installation is the first experience everyone will have of JFX and it there is a legacy in this area from old Applets, etc, of Java being heavy, unfriendly and buggy in this area. It was one of the reasons we lost ground to the web guys in the early days of AWT and Swing. JavaFX needs to fight the "battle for hearts and minds" on this one, failing that it needs to call in some "shock and awe". We also assume that JavaFX runtime is shared install per system (or > eventually per user) and then we want to be able to keep track of what > users have installed/use and autoupdate it when important updates are > available (e.g. security). > This is a risky approach, especially for developers. I often have multiple JDKs and JVMs installed on my machine which means I need the correct JFX install in each. I currently have a system where it thinks I don't have JFX installed but I do, but not in the JRE the browser is using, but the deployment tool won't let me install it because it thinks I have it already installed. In fact each of the computers I use (3 of them) seem to do something slightly different when I try to run an applet and something different again when I run a webstart app (and rarely do they work, and never with any real message on why they failed). My best guess is that the multiple versions of stuff is confusing the deployer. I have 64 bit and 32 bit versions on my machine at the same time too, as some of the native libraries (e.g. finger print scanner) that I use need this. I think it will probably be a bigger problem than just for weird developers like myself in the future though. When we have multiple versions of JFX out there, we will end up with JNLP files specifying specific specific versions to use (as we see now with Swing and JRE versions). If a jnlp file sepcifies an older version of JFX is required (i.e. I don't want my code to run on the latest because it causes me problems, etc), then what will the install tools do in this case? What exactly are the security risks associated with JavaFX? How does this differ to say me using another display library like SWT or any toolkit like GWT, or hibernate, or spring. Or even application servers like tomcat - if these have problems, I download a new release when it suits me, I don't want tomcat randomly updating itself. Is it actually JavaFX that has the risks and needs to be updated, or is the browser plugin deployment tool thing? We also use the fact that JavaFX runtime is installed to be able to > autodetect runtime install path when standalone application is being > launched Can you elaborate on why standalone apps would need this and how they can work this out? The problem we have at the moment is exactly that the standalone app can't find the installation path (and hence the native files) without being told where it is via the system path, which is not setup by the installer. I'd be interested to understand more about this autodetect mechanism, how it is used currently, and how I might be able to make use of it. > and to ensure other requirements are met (e.g. application may require > specific version of JavaFX to be available or presence of compatible JRE). This should all be taken care of by the normal JNLP stuff no? What is it that JFX does above beyond what standard JRE/JNLP has been doing for a while? > IDE like Netbeans can also detect where runtime/sdk is installed and > validate that libraries used to compile code . > IDE's are built to work off jars on the classpath. I would think they should be able to validate against a jar? In most cases I imagine they would find this more natural and easier than referencing an install path somewhere. Overall, having installer helps to ensure typical user/developer has > reasonable environment. > We realize it may be not perfect way for everybody and this does not mean > other distribution options are not possible. E.g. > > 1) Cobundling JavaFX Runtime with the application > In that case application is responsible to update private copy of > runtime and there are no detection issues > > 2) Installing JavaFX runtime as part of JRE or as JDK8 module > > 3) shipping JavaFX SDK as zip or maven module, etc. > Once the licencing issues are sorted and once we get access to the code that does the DLL loading, I will certainly be looking at ways to make the install as simple as possible for my end users. Webstart is such a powerful feature though and the newer JFX build tools make all this nice and easy to use. It seems a shame not to be able to leverage these due to reasons of usability, rather than technical requirements. BTW, having open lookup path for native libraries is generally security > hole that intruder may use if he finds a way to add file to the directory > on the path. Agreed, I was thinking more about placing the dlls on the windows system path as when you install most other normal windows applications. Then when the code is run, it won't matter where the jar is, the dlls will be found. From igor.nekrestyanov at oracle.com Tue Dec 6 22:56:28 2011 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Tue, 06 Dec 2011 22:56:28 -0800 Subject: JavaFX Maven support (was: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls.) In-Reply-To: References: <4C2C99B6-35CD-4E56-879D-49736745272F@oracle.com> <4EDEB1BB.5000409@oracle.com> Message-ID: <4EDF0E1C.1000607@oracle.com> Hi, To be able to launch JavaFX application embedded in the browser or using >> Webstart we need to have JavaFX aware plugin/deployment stack to be >> registered in the browser. >> > The plugin to run Java makes sense, and this has been around for a while > now. Improving it is nice, but this should be done back in the core JRE > area I would have thought? It's the 'install' of JavaFX that I am confused > about. I'm possibly over simplifying things but if JavaFX is just a jar and > some native DLLs then isn't it just another library that gets added to the > classpath like everything else? No, unfortunately it is not that simple. First of all plugin and webstart code used to be inherently Swing/AWT based. To get most of JavaFX (at least performance wise) you do not want to run it in the heavyweight AWT container or load Swing/AWT classes. Browser integration is not that simple if you want to use hardware acceleration in browser window. There is special code in JavaFX to attach stage to window handle provided by the browser. Obviously Java plugin in JRE6 has no idea of JavaFX existence as it was implemented years before it. Hence to be able to support users who stuck with JRE6 and can not switch to latest JRE7 (or 8) we are shipping updated copy of deployment with JavaFX. JavaFX-specific changes are merged back into JRE source base. E.g. JRE7 update 2 has (almost) the same deployment stack as JavaFX 2.0.2. But deployment code need to be in sync with JavaFX code and dependencies are tight. So, as we march to support new platforms (Mac/Linux) source bases will again be different for some more time. Eventually JRE will include full JavaFX capable plugin and there will be no need to include it into JavaFX (assuming most of the users will migrate to new version of JRE). But this likely will take time. > Ideally installing the plugin(s) really needs to be simple (1 or 2 click install). Currently the Java one takes me off to another page and makes me jump through a lot more hoops and then the > JFX one has another go at me. It would be great if we could work out ways to avoid these hoops. Maybe the co-bundling will fix all this, but it would be nice to just streamline everything as > soon as possible. Cobundling should improve things a little but in general i agree user experience could be improved. We would be happy to hear about possible ideas of how to improve the process (and yet satisfy legal requirements such as accepting the license). > We also assume that JavaFX runtime is shared install per system (or >> eventually per user) and then we want to be able to keep track of what >> users have installed/use and autoupdate it when important updates are >> available (e.g. security). >> > This is a risky approach, especially for developers. I often have multiple > JDKs and JVMs installed on my machine which means I need the correct JFX > install in each. There is a difference between developer who needs SDK to build app and user who only needs runtime to run app. We are not autoupdating SDK as it can not be used by attacker. Like with JDK you may still have multiple JavaFX SDK installed (at least i do not see why not). Runtime is different. Whenever you open web page with javafx application it will be launched using installed runtime. And if this runtime is vulnerable then user is in trouble. Keeping it up to data and secure is important. If you really need to test with older version of runtime then you can install it and decline offers to autoupdate it. > I currently have a system where it thinks I don't have JFX installed but I do, but not in the JRE the browser is using, but the deployment tool won't let me install it because it thinks I have it > already installed. In fact each of the computers I use (3 of them) seem to do something slightly different when I try to run an applet and something different again when I run a webstart app > (and rarely do they work, and never with any real message on why they failed). Sorry to hear that. Would you mind filing issues on this and providing us with trace/log files? > My best guess is that the multiple versions of stuff is confusing the deployer. I have 64 bit and 32 bit versions on my machine at the same time too, as some of the native libraries (e.g. finger print scanner) that I use need this. Well, in theory both plugin and webstart are supposed to use one "latest" version as it should supersede others. If you have both 32 and 64 bit versions then there are 2 "latest" versions and they are selected depending on whether your browser is 32 or 64 bit. (Most of the browsers are still 32 bit). Typical source of the issues right now is that JRE6 is not fully updated to be JavaFX aware and if JRE6 is installed/uninstalled/upgraded while JavaFX runtime is installed then it can corrupt registry. Also, before 2.0.2 installer had nasty bug and if JavaFX runtime was installed by one user then another user could neither install it nor use it i think. We are solving these issues as we learn about them. Please report bugs to JIRA and we will do our best to make it more robust. > When we have multiple versions of JFX out there, we will end up with JNLP files specifying specific specific versions to use (as we see now with Swing and JRE versions). If a jnlp file sepcifies an older version of JFX is required (i.e. I don't want my code to run on the latest because it causes me problems, etc), then what will the install tools do in this case? Current thinking is that we will only allow to specify minimal version assuming all JavaFX version in the same family are backward compatible. I.e. you can request 2.0.2+ but if user has 2.0.3 installed you can not request him to install 2.0.2. > What exactly are the security risks associated with JavaFX? How does this differ to say me using another display library like SWT or any toolkit like GWT, or hibernate, or spring. The biggest difference is that JavaFX will likely be preinstalled on large number of systems and shared between different applications. It does not come as private part of the application (by default). > We also use the fact that JavaFX runtime is installed to be able to autodetect runtime install path when standalone application is being launched > > Can you elaborate on why standalone apps would need this and how they can > work this out? The problem we have at the moment is exactly that the > standalone app can't find the installation path (and hence the native > files) without being told where it is via the system path, which is not > setup by the installer. I'd be interested to understand more about this > autodetect mechanism, how it is used currently, and how I might be able to > make use of it. If you follow JavaFX application packaging guidelines (see deployment guide on javafx.com) then result application jar will contain small launcher program that will be used as default entry point (e.g. when you double click on jar) and it is capable of checking system requirements (e.g. presence of JRE) and detecting where JavaFX runtime is installed. Then it will setup classpath to include required.jars and instantiate main Application class. > What is it > that JFX does above beyond what standard JRE/JNLP has been doing for a > while? E.g. embedded launcher can check this without JNLP. I.e. you can ship just jar file and user will be guided how to run it as long as it has java. -igor From kevin.rushforth at oracle.com Wed Dec 7 02:13:44 2011 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 07 Dec 2011 08:13:44 -0200 Subject: Attempting to Build [ was Source code for JavaFX UI controls now available on openjfx] In-Reply-To: <4EDEB448.701@oracle.com> References: <4ED95442.5070403@oracle.com> <651B13B4-A077-45E0-856F-60CBEFFA13D4@gmail.com> <3256D7C0-3DC1-44A8-8F78-592050C2B0F4@gmail.com> <4ED96727.1040502@oracle.com> <2F7DEE03-9940-4820-9CBE-7883FF86C20D@oracle.com> <4EDEB041.5020501@oracle.com> <4EDEB448.701@oracle.com> Message-ID: <4EDF3C58.6000901@oracle.com> Btw, I know what the cause of http://javafx-jira.kenai.com/browse/RT-18408 is (I updated the bug report). We rely on ant-contrib for a few tasks and propertycopy is one of them. Until we get the top-level build wired up, the solution is for developers to do the following manually: cd JFXROOT mkdir import cd import wget http://downloads.sourceforge.net/ant-contrib/ant-contrib-1.0b3-bin.tar.gz and unzip it into the import/ directory such that it ends up in import/ant-contrib-1.0b3/ Then you can build from JFXROOT/rt/javafx-ui-controls without commenting out the propertycopy class. As Jonathan indicated, the idea is to gradually improve the ability to build from just the open sources, but for now this is a solution that developers can use. -- Kevin Jonathan Giles wrote: > I don't believe this variable is fully implemented. I actually define > the same property up in the rt/build-defs.xml file, but there needs to > be some more work in the javafx-ui-controls folder to only use this > reference. I've made some half-attempts at getting this all hooked up > in the past, but haven't yet completed it. There are a number of paths > that need testing: > > * compile from rt-closed, > * compile from 'jfx'/root directory with 'ant clean dev-build', > * compile from within javafx-ui-controls folder, > * compilation from within NetBeans. > > Also, it's worth noting that in the same part of build-defs.xml I pull > in all environment variables, so if the developer simply sets > JFXRT_HOME to a path on their file system in the environment settings, > this should be picked up (although with the caveat that ant doesn't > apparently support environment variables in all operating systems). > > Once I'm back from vacation, if nobody else has taken a look at > JFXRT_HOME improvements (and indeed whether we should be pointing at > JFXRT_HOME, or more simply JFX_HOME (which may be a directory or two > higher up the path)), I'll take another stab at it. > > -- Jonathan > > On Wednesday, 7 December 2011 10:20:28 a.m., Richard Bair wrote: >> >> Ya the property is in javafx-ui-common/project.properties called >> JFXRT_HOME. If you just set this property then you don't have to >> manually move the jfxrt.jar into artifacts/sdk/rt/lib. >> >> Thanks for filing the issue! >> >> Richard >> >> >> On Dec 6, 2011, at 4:16 PM, Kevin Rushforth wrote: >> >>> >>> Regarding #4 I think Jonathan added a property (or was going to add >>> one) so you don't have to copy it in, although copying it may be the >>> easiest way to do it anyway. >>> >>> Regarding having to comment out the propertycopy ant task, I filed >>> http://javafx-jira.kenai.com/browse/RT-18408 to track this. >>> >>> -- Kevin >>> >>> >>> Richard Bair wrote: >>>> >>>> >>>> The missing scripts have been pushed, so I think I can now give >>>> reproducible instructions for building and testing. Download the >>>> 2.1 binary for Mac from >>>> http://www.oracle.com/technetwork/java/javafx/downloads/javafx2-macosx-487281.html. >>>> >>>> 1) hg clone http://hg.openjdk.java.net/openjfx/2.1/master >>>> 2) cd master >>>> 3) mkdir -p artifacts/sdk/rt/lib >>>> 4) cp ~/Downloads/javafx-sdk2.1.0-beta/rt/lib/jfxrt.jar >>>> artifacts/sdk/rt/lib >>>> - Or from wherever you have downloaded this file >>>> 5) hg clone hg.openjdk.java.net/openjfx/2.1/master/rt >>>> 6) vi build-defs.xml >>>> - There is some library being used but not registered properly, >>>> there is probably another way to do this. >>>> Anyway, just edit the master/rt/build-defs.xml and comment out the >>>> line: >>>> >>> from="${ant.project.name}.javac.debuglevel" silent="true" >>>> override="true"/> >>>> 7) cd javafx-ui-controls >>>> 8) ant >>>> >>>> That should be enough to actually have built the project. The built >>>> class files should be sitting in >>>> master/rt/javafx-ui-common/dist/javafx-ui-controls.jar. You can >>>> then run by placing the newly created javafx-ui-controls.jar before >>>> jfxrt.jar on your classpath. >>>> >>>> Let me know if you have any success! >>>> Thanks >>>> Richard >>>> >>>> On Dec 6, 2011, at 9:46 AM, Richard Bair wrote: >>>> >>>> >>>>> >>>>> If you got to Oracle.com and download JavaFX and find the tiny >>>>> link that switches to the Mac Developer Preview download and grab >>>>> it, you will get a very recent 2.1 build. This can be used as the >>>>> binary plug for building. Unfortunately, some build files are >>>>> missing in the master/ repo. I tried to push these files in, but >>>>> the server is not happy with my ssl configuration. I'm trying to >>>>> track that down. With those build files put in, there is one other >>>>> slight modification to master/rt/build-defs.xml, but this will >>>>> then allow you to actually build the controls repo and, if you are >>>>> on Mac, run it. >>>>> >>>>> I'll keep you all abreast of the work, hopefully we'll have >>>>> something fully buildable a little later today. >>>>> >>>>> Richard >>>>> >>>>> >>>>> On Dec 2, 2011, at 5:43 PM, Richard Bair wrote: >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> Sorry I misunderstood, I was expecting something similar to the >>>>>>> binary plugs we had in OpenJDK, not a full version of the >>>>>>> current release, hence the question. >>>>>>> >>>>>>> I was able to import the project successfully into eclipse (and >>>>>>> netbeans) with the FX runtime and it seems to compile fine. >>>>>>> >>>>>> >>>>>> Oh, that's interesting. I grabbed the latest 2.0.2 code for Mac >>>>>> that I had available but it was failing on: >>>>>> >>>>>> [javac] >>>>>> /Developer/Projects/openjfx/workspace-2.1/master/rt/javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ButtonBehavior.java:42: >>>>>> cannot find symbol >>>>>> [javac] symbol : class PlatformUtil >>>>>> [javac] location: package com.sun.javafx >>>>>> [javac] import com.sun.javafx.PlatformUtil; >>>>>> [javac] ^ >>>>>> >>>>>> And a bunch of other such failures. So I thought PlatformUtil had >>>>>> been removed between the 2.0.2 code I had (from early November) >>>>>> and the newer code in the 2.1 tree. If you got it to build in >>>>>> Eclipse on an older release -- well that is interesting! What >>>>>> version of JavaFX are you using for the binary plug? >>>>>> >>>>>> Do you want to post some basic instructions so other folks can do >>>>>> likewise? >>>>>> >>>>>> >>>>>>> >>>>>>> I'll play with this code a bit and see how we can help out until >>>>>>> everything else is sorted out. >>>>>>> >>>>>>> I think that while this is a suboptimal situation (but hey, we >>>>>>> Free Software freaks are never happy, right? :) is still a great >>>>>>> step forward, and we have a chance to study the code and the >>>>>>> internals before everything gets released. >>>>>>> >>>>>>> Speaking about this, do you think we can have some "specs" about >>>>>>> the internal interfaces? >>>>>>> >>>>>> >>>>>> Probably in the short term asking me questions is the fastest way >>>>>> to get answers, unfortunately. I do need to be badgered to write >>>>>> up some documents though and put them up on our pages. Please do >>>>>> feel free to badger me: squeaky wheel and all that :-) >>>>>> >>>>>> >>>>>>> >>>>>>> I know from JavaOne that the internal code is pretty abstracted >>>>>>> and modular, and can actually be "easily" replaced (not sure the >>>>>>> exact definition of easily though, but what you have shown at J1 >>>>>>> was very impressive). >>>>>>> >>>>>>> We can probably help speeding up things if we know what things >>>>>>> should be replaced and implement some clear room version of what >>>>>>> will come later in the game, in a similar way we did with the >>>>>>> Pisces renderer in Java2D, what do you think? >>>>>>> >>>>>>> I'm specifically thinking about the Linux port here, since to be >>>>>>> honest "late 2012" is eons away. >>>>>>> >>>>>> >>>>>> What we have released so far is the controls portion, which all >>>>>> sits above the "toolkit implementation" line. Basically on the >>>>>> "top" we've got controls, scene graph, css, properties, binding, >>>>>> collections, services, and that sort of thing. There is a Toolkit >>>>>> interface (com.sun.javafx.tk.Toolkit) which defines the >>>>>> abstraction between the public API portions of the platform and >>>>>> the underlying toolkit implementation (threading, windowing, >>>>>> opengl, d3d, fonts, etc). >>>>>> >>>>>> Likely it will be a couple months before we start putting out the >>>>>> lower-level bits en masse, due to having to be careful there over >>>>>> 3rd party code etc (there isn't much, mostly fonts and some SVG, >>>>>> but we have to do all the due diligence). The other problem is >>>>>> the same guys who have to do that, have to get the Mac port >>>>>> finished (both for Java 7 and for Java FX). However I will follow >>>>>> up with the guys doing linux and see if we can get that out >>>>>> sooner (they're busy working away on it and it would be cool to >>>>>> get it open faster, but at the very least get it included in the >>>>>> bits so you can run on linux). >>>>>> >>>>>> Cheers >>>>>> Richard >>>>>> >>>>> >>>> >>>> >>>> >>> >> From knut.arne.vedaa at broadpark.no Wed Dec 7 10:27:44 2011 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Wed, 07 Dec 2011 19:27:44 +0100 Subject: Controls with Values [was Possible additions to JavaFX to facilitate forms and validations] In-Reply-To: References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> <4EDE4972.8030205@broadpark.no> <67E8E7BD-24DB-4242-81FD-6C35389A7699@oracle.com> <4EDEA518.5090102@oracle.com> <4EDEB118.6010702@bestsolution.at> Message-ID: <4EDFB020.3060005@broadpark.no> On 07.12.2011 03:09, Daniel Zwolenski wrote: > I agree with Tom (who agrees with me :) ). Having a 'value' property and a > HasValue interface feels a little more honest to me. Binding to the value > of a choicebox is how I would conceptualise it in my head, whereas binding > to a checkbox might imply that I am binding to all properties of it or > maybe its visual properties. You can see newbies trying to bind to it and > hoping they will get notified when its bounds change, etc. > > Also I reckon making it a separate value will make it easier to > implement/extend. If I build a custom date picker, I simply have to expose > my ObjectProperty as the value property and I'm away, whereas if I > have to extend an AbstractValueControl it gets messy. I have come to agree as well. :) I think this is the cleanest solution. I don't think you'd need getValue/setValue on the HasValue interface. They'd be available through valueProperty.getValue/setValue anyway. However, I'm not quite sure if "valueProperty" is the best name, as "value" is used so much elsewhere. You'd have valueProperty.getValue, but also heightProperty.getValue etc. This could be confusing. What about "dataProperty"? (And thus "HasData"?) > With respect to the property for List, Tree and Table (i.e. things that > support multselection), I think we need to support the two basic use cases. > Single selection, I want to use my list much as a I would use a ChoiceBox, > so the value is just the currently selected row. Multi-selection I want to > have an observable list that I can watch and get the selected values from. I agree. The selected item is the natural "data value" of a List etc. You'd then have a separate interface HasMultipleData with a method getMultipleData that returns an ObservableList of the multiple-selected items (e.g. forwards to MultipleSelectionModel.getSelectedItems). However, one current complication is that for e.g. TextField the data property would be a Property, but for the "selected item" on e.g. a ListView it would be a ReadOnlyProperty. (Let's for now assume this problem can be solved and the selected item property can be writable. Otherwise you'd need a HasReadOnlyData as well.) It'd also be nice to have a common interface for the entire items list of ListView and TreeView. They both have an itemsProperty that wraps an ObservableList, but no common interface. What about interface HasItems, with an itemsProperty field? So, to sum it up, my suggestions: interface HasData { Property dataProperty } interface HasMultipleData { ObservableList getMultipleData } interface HasItems { ObjectProperty> itemsProperty } (I'd consider naming them DataHolder, MultipleDataHolder, ItemsHolder instead, but that's cosmetics.) Knut Arne From richard.bair at oracle.com Wed Dec 7 10:52:16 2011 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 7 Dec 2011 10:52:16 -0800 Subject: Controls with Values [was Possible additions to JavaFX to facilitate forms and validations] In-Reply-To: <4EDFB020.3060005@broadpark.no> References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> <4EDE4972.8030205@broadpark.no> <67E8E7BD-24DB-4242-81FD-6C35389A7699@oracle.com> <4EDEA518.5090102@oracle.com> <4EDEB118.6010702@bestsolution.at> <4EDFB020.3060005@broadpark.no> Message-ID: > interface HasData { > Property dataProperty > } > > interface HasMultipleData { > ObservableList getMultipleData > } > > interface HasItems { > ObjectProperty> itemsProperty > } > > (I'd consider naming them DataHolder, MultipleDataHolder, ItemsHolder instead, but that's cosmetics.) Actually, that is the thing that bothers me here. The HasData is kind of an awkward name, so what would I rather have called it? ValueHolder (or DataHolder, that's fine). But wait! We've already got one of those called ObservableValue! That's where I think the naming is actually quite instructive. Actually what is interesting is that in some sense this is an argument that "Oh dang, you guys should have used the name 'value' or 'data' consistently!", such that instead of having TextField.text, it would have been TextField.value. Had we been so strict, overlaying an interface that essentially redefined the naming convention would have been pretty clean. Lacking that, I do like "value" better than "data", as I have tended to use the name "data" for "application data" or "domain data". Value also will actually work in some cases (such as Slider). However, I don't like the name HasValue. "Valuable" just made me chuckle. Coming up with a good name is a good indication of whether the concept itself is right (or in some cases English just lacks the right name for the concept). Dan, can you recapitulate the use case? Richard From richard.bair at oracle.com Wed Dec 7 12:22:33 2011 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 7 Dec 2011 12:22:33 -0800 Subject: Attempting to Build [ was Source code for JavaFX UI controls now available on openjfx] In-Reply-To: <4EDF3C58.6000901@oracle.com> References: <4ED95442.5070403@oracle.com> <651B13B4-A077-45E0-856F-60CBEFFA13D4@gmail.com> <3256D7C0-3DC1-44A8-8F78-592050C2B0F4@gmail.com> <4ED96727.1040502@oracle.com> <2F7DEE03-9940-4820-9CBE-7883FF86C20D@oracle.com> <4EDEB041.5020501@oracle.com> <4EDEB448.701@oracle.com> <4EDF3C58.6000901@oracle.com> Message-ID: Cool. I guess at this point we can actually post some kind of build instructions to the project web pages. Richard On Dec 7, 2011, at 2:13 AM, Kevin Rushforth wrote: > Btw, I know what the cause of http://javafx-jira.kenai.com/browse/RT-18408 is (I updated the bug report). We rely on ant-contrib for a few tasks and propertycopy is one of them. Until we get the top-level build wired up, the solution is for developers to do the following manually: > > cd JFXROOT > mkdir import > cd import > wget http://downloads.sourceforge.net/ant-contrib/ant-contrib-1.0b3-bin.tar.gz > > and unzip it into the import/ directory such that it ends up in import/ant-contrib-1.0b3/ > > Then you can build from JFXROOT/rt/javafx-ui-controls without commenting out the propertycopy class. > > As Jonathan indicated, the idea is to gradually improve the ability to build from just the open sources, but for now this is a solution that developers can use. > > -- Kevin > > > Jonathan Giles wrote: >> >> I don't believe this variable is fully implemented. I actually define the same property up in the rt/build-defs.xml file, but there needs to be some more work in the javafx-ui-controls folder to only use this reference. I've made some half-attempts at getting this all hooked up in the past, but haven't yet completed it. There are a number of paths that need testing: >> compile from rt-closed, >> compile from 'jfx'/root directory with 'ant clean dev-build', >> compile from within javafx-ui-controls folder, >> compilation from within NetBeans. >> Also, it's worth noting that in the same part of build-defs.xml I pull in all environment variables, so if the developer simply sets JFXRT_HOME to a path on their file system in the environment settings, this should be picked up (although with the caveat that ant doesn't apparently support environment variables in all operating systems). >> >> Once I'm back from vacation, if nobody else has taken a look at JFXRT_HOME improvements (and indeed whether we should be pointing at JFXRT_HOME, or more simply JFX_HOME (which may be a directory or two higher up the path)), I'll take another stab at it. >> >> -- Jonathan >> >> On Wednesday, 7 December 2011 10:20:28 a.m., Richard Bair wrote: >>> >>> Ya the property is in javafx-ui-common/project.properties called JFXRT_HOME. If you just set this property then you don't have to manually move the jfxrt.jar into artifacts/sdk/rt/lib. >>> >>> Thanks for filing the issue! >>> >>> Richard >>> >>> >>> On Dec 6, 2011, at 4:16 PM, Kevin Rushforth wrote: >>> >>>> >>>> Regarding #4 I think Jonathan added a property (or was going to add one) so you don't have to copy it in, although copying it may be the easiest way to do it anyway. >>>> >>>> Regarding having to comment out the propertycopy ant task, I filed http://javafx-jira.kenai.com/browse/RT-18408 to track this. >>>> >>>> -- Kevin >>>> >>>> >>>> Richard Bair wrote: >>>>> >>>>> >>>>> The missing scripts have been pushed, so I think I can now give reproducible instructions for building and testing. Download the 2.1 binary for Mac from http://www.oracle.com/technetwork/java/javafx/downloads/javafx2-macosx-487281.html. >>>>> >>>>> 1) hg clone http://hg.openjdk.java.net/openjfx/2.1/master >>>>> 2) cd master >>>>> 3) mkdir -p artifacts/sdk/rt/lib >>>>> 4) cp ~/Downloads/javafx-sdk2.1.0-beta/rt/lib/jfxrt.jar artifacts/sdk/rt/lib >>>>> - Or from wherever you have downloaded this file >>>>> 5) hg clone hg.openjdk.java.net/openjfx/2.1/master/rt >>>>> 6) vi build-defs.xml >>>>> - There is some library being used but not registered properly, there is probably another way to do this. >>>>> Anyway, just edit the master/rt/build-defs.xml and comment out the line: >>>>> >>>>> 7) cd javafx-ui-controls >>>>> 8) ant >>>>> >>>>> That should be enough to actually have built the project. The built class files should be sitting in master/rt/javafx-ui-common/dist/javafx-ui-controls.jar. You can then run by placing the newly created javafx-ui-controls.jar before jfxrt.jar on your classpath. >>>>> >>>>> Let me know if you have any success! >>>>> Thanks >>>>> Richard >>>>> >>>>> On Dec 6, 2011, at 9:46 AM, Richard Bair wrote: >>>>> >>>>> >>>>>> >>>>>> If you got to Oracle.com and download JavaFX and find the tiny link that switches to the Mac Developer Preview download and grab it, you will get a very recent 2.1 build. This can be used as the binary plug for building. Unfortunately, some build files are missing in the master/ repo. I tried to push these files in, but the server is not happy with my ssl configuration. I'm trying to track that down. With those build files put in, there is one other slight modification to master/rt/build-defs.xml, but this will then allow you to actually build the controls repo and, if you are on Mac, run it. >>>>>> >>>>>> I'll keep you all abreast of the work, hopefully we'll have something fully buildable a little later today. >>>>>> >>>>>> Richard >>>>>> >>>>>> >>>>>> On Dec 2, 2011, at 5:43 PM, Richard Bair wrote: >>>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> Sorry I misunderstood, I was expecting something similar to the binary plugs we had in OpenJDK, not a full version of the current release, hence the question. >>>>>>>> >>>>>>>> I was able to import the project successfully into eclipse (and netbeans) with the FX runtime and it seems to compile fine. >>>>>>>> >>>>>>> >>>>>>> Oh, that's interesting. I grabbed the latest 2.0.2 code for Mac that I had available but it was failing on: >>>>>>> >>>>>>> [javac] /Developer/Projects/openjfx/workspace-2.1/master/rt/javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ButtonBehavior.java:42: cannot find symbol >>>>>>> [javac] symbol : class PlatformUtil >>>>>>> [javac] location: package com.sun.javafx >>>>>>> [javac] import com.sun.javafx.PlatformUtil; >>>>>>> [javac] ^ >>>>>>> >>>>>>> And a bunch of other such failures. So I thought PlatformUtil had been removed between the 2.0.2 code I had (from early November) and the newer code in the 2.1 tree. If you got it to build in Eclipse on an older release -- well that is interesting! What version of JavaFX are you using for the binary plug? >>>>>>> >>>>>>> Do you want to post some basic instructions so other folks can do likewise? >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> I'll play with this code a bit and see how we can help out until everything else is sorted out. >>>>>>>> >>>>>>>> I think that while this is a suboptimal situation (but hey, we Free Software freaks are never happy, right? :) is still a great step forward, and we have a chance to study the code and the internals before everything gets released. >>>>>>>> >>>>>>>> Speaking about this, do you think we can have some "specs" about the internal interfaces? >>>>>>>> >>>>>>> >>>>>>> Probably in the short term asking me questions is the fastest way to get answers, unfortunately. I do need to be badgered to write up some documents though and put them up on our pages. Please do feel free to badger me: squeaky wheel and all that :-) >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> I know from JavaOne that the internal code is pretty abstracted and modular, and can actually be "easily" replaced (not sure the exact definition of easily though, but what you have shown at J1 was very impressive). >>>>>>>> >>>>>>>> We can probably help speeding up things if we know what things should be replaced and implement some clear room version of what will come later in the game, in a similar way we did with the Pisces renderer in Java2D, what do you think? >>>>>>>> >>>>>>>> I'm specifically thinking about the Linux port here, since to be honest "late 2012" is eons away. >>>>>>>> >>>>>>> >>>>>>> What we have released so far is the controls portion, which all sits above the "toolkit implementation" line. Basically on the "top" we've got controls, scene graph, css, properties, binding, collections, services, and that sort of thing. There is a Toolkit interface (com.sun.javafx.tk.Toolkit) which defines the abstraction between the public API portions of the platform and the underlying toolkit implementation (threading, windowing, opengl, d3d, fonts, etc). >>>>>>> >>>>>>> Likely it will be a couple months before we start putting out the lower-level bits en masse, due to having to be careful there over 3rd party code etc (there isn't much, mostly fonts and some SVG, but we have to do all the due diligence). The other problem is the same guys who have to do that, have to get the Mac port finished (both for Java 7 and for Java FX). However I will follow up with the guys doing linux and see if we can get that out sooner (they're busy working away on it and it would be cool to get it open faster, but at the very least get it included in the bits so you can run on linux). >>>>>>> >>>>>>> Cheers >>>>>>> Richard >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> From neugens.limasoftware at gmail.com Wed Dec 7 13:26:49 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 7 Dec 2011 22:26:49 +0100 Subject: JavaFX Maven support (was: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls.) In-Reply-To: <4EDF0E1C.1000607@oracle.com> References: <4C2C99B6-35CD-4E56-879D-49736745272F@oracle.com> <4EDEB1BB.5000409@oracle.com> <4EDF0E1C.1000607@oracle.com> Message-ID: <84EB6395-265E-4CE5-A060-716112B562A2@gmail.com> Il giorno 07/dic/2011, alle ore 07:56, Igor Nekrestyanov ha scritto: > Hi, [...long...] >> What is it >> that JFX does above beyond what standard JRE/JNLP has been doing for a >> while? > E.g. embedded launcher can check this without JNLP. > I.e. you can ship just jar file and user will be guided how to run it as long as it has java. I still dream of a World where CacioWeb is used to run all sort of Java related things in HTML5 based browsers. Cheers, Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From zonski at googlemail.com Wed Dec 7 15:50:18 2011 From: zonski at googlemail.com (Daniel Zwolenski) Date: Thu, 8 Dec 2011 10:50:18 +1100 Subject: JavaFX Desktop deployment (offshoot from: JavaFX Maven support) Message-ID: Thanks for the in-depth info Igor. The pieces of the puzzle are starting to become clear to me, sorry it takes my head a while to get in gear :) I've renamed the thread (again) to reflect the direction this conversation is taking. I think the Maven conversation is now separate and should be continued off on its own. If this thread is not a correct conversation for this forum, please let me know and I can take it to the forums, or wherever you think it should belong. Summing up: the deployment complexities seem to be mostly centered around embedding JFX within a Browser, which makes a lot of sense (it's fairly amazing this can be achieved at all). Additionally there are some challenges with maintaining a 'current' JFX install and auto-updating this when new releases are made. The focus of the install+plugin is mostly in solving these two issues. The reason I was simplifying the deployment in my head is because the two issues are not features that I use in my deployment. The end result being that I am having to jump hurdles that don't make sense in my scenario. My apps are mostly desktop business apps, often used in the 'back-office'. It is rare for me to use Applets or have a need to embed my application in a Browser. I also often don't want auto-updates of JFX (or the JRE for that matter) as there is often corporate policy/control over this, which mandates installation privileges and tries to ensure all desktops in the organisation are running the same version of things, etc. The sys admins would want to know about and control any updates, especially security holes. Perhaps the end result is that the current webstart deployment mechanism is not actually for pure desktop apps, and we instead need to look at an alternate mechanism like the ones you have suggested. What desktop app developers really need is something like a (free) InstallShield for JavaFX, that also includes automatic updates. For desktop apps, the web is a distribution mechanism, not the application platform/runtime. As a thought-experiment I've tried to come up with the perfect deployment user experience for a pure desktop app, ignoring the fact that applets even exist. It would be nice to work backwards from this to see what can be achieved, whether it is a case of updating the deployment tools, creating new ones in JFX, or this feature being left to third-party tools (like Java installshield, but it is currently not in a good state). *Background* Lisa is a business user at ACME mining, responsible for determining its carbon footprint in order to reduce greenhouse gas emissions. Lisa has just learnt of a new product called FootprintFX, a desktop application for calculating carbon footprints, built in JavaFX. Lisa is a Windows 7 user with basic technical skills. She has no Java installed on her machine and has no idea what Java or JavaFX really are. *Installation steps* 1. Using her favourite web browser and google, Lisa finds the home page for FootprintFX and clicks the 'download for Windows7 now' button 2. The browser downloads an exe to Lisa's computer, which she then runs 3. Windows security pops up a message (as it likes to do) saying "do you want to let this program make changes". Lisa hits yes. 4. The executable detects that Java is not installed. It shows a screen asking the user if they would like to install it and the directory to install to. Lisa leaves it at the default directory (c:\Program Files\java) 5. The executable shows a combined T&C for using Java, JavaFX. Lisa does the usual - ticks 'I agree' without reading it and hits 'next' 6. The executable installs Java and JavaFX to the location specified (JFX is installed in the same directory as the JRE). Lisa just sees a single progress bar for all this, with no dialogs popping up, etc. 7. Once Java and JFX are installed the system then asks Lisa where to install FootprintFX and whether she wants a Start Menu and Desktop link. Lisa leaves it at the default settings (c:/Program Files/FootprintFX) 8. The install is complete (an icon has been added to the Start Menu and Desktop - as per Lisa's selection) and Lisa has the option to 'Run Now' *Running * 1. Lisa clicks the desktop shortcut or start menu link 2. The application shows the custom splash screen for FootprintFX while behind the scenes Java is loading and the FootprintFX main window is being created. 3. On startup a check is made back to the FootprintFX for any updates. If an update is found, Lisa is given the option to update to this new version automatically. If Lisa clicks yes, then the new jars/resources are downloaded and the JVM is restarted with the new details. 4. Once the latest code has been loaded, the splash screen is hidden and the application is run. Although the jars are not signed, the application has all permissions (i.e. no sandbox). *Variations and comments: * - If the user already has Java and/or JavaFX installed the installer should just use these and skip this whole step. - If the user has Java installed but not JavaFX, the step should just be the install of this - If the user has an older version of these, it should give the user the option to upgrade the current install, or install a seperate version - Auto updates (of Java, JFX and/or the app) should be configurable by the creator of the installation package - The installer should be able to map file types to the installed Application - i.e. I should be able to make files of type .cfp (carbon footprint) get directed directly to FootprintFX. There is one very hard feature but very powerful feature that would be awesome to have. It would be incredibly useful to be able to have something like an 'application url', where we can embed this url inside an email or web page, and when a user clicks on it, it opens the local desktop application but passes in parameters to it. This is the same idea (and would be used in the same way) as web browser URLs, which launch the local web browser and pass an address to it. Being able to embed a link in an email to a page on the web has been incredibly useful for web apps. Being able to embed a link in an email to a 'place' within an application (e.g. open FootprintFX and point it to the 'flights calculation page' with flight details prepoluated) would be amazing. I don't know how this would be achieved however. The only way I can think of is to use a URL that opens a web page that then triggers the launcher to be run passing in parameters, i.e. hijack the browser way of doing it and then hook in a Java trigger. Not ideal, but otherwise both the operating system and the email browsers (and web browsers) would need to support an 'application URL' and I'm not sure that's achievable. Something like this would be the place to start looking I guess: http://msdn.microsoft.com/en-us/library/aa767914(v=vs.85).aspx Each OS would do this differently if it does it at all. Interested in hearing a variety of thoughts on this topic. What do other people see as the key deployment issues/models/options for JavaFX? On Wed, Dec 7, 2011 at 5:56 PM, Igor Nekrestyanov < igor.nekrestyanov at oracle.com> wrote: > Hi, > > > To be able to launch JavaFX application embedded in the browser or using > >> Webstart we need to have JavaFX aware plugin/deployment stack to be >>> registered in the browser. >>> >>> The plugin to run Java makes sense, and this has been around for a while >> now. Improving it is nice, but this should be done back in the core JRE >> area I would have thought? It's the 'install' of JavaFX that I am confused >> about. I'm possibly over simplifying things but if JavaFX is just a jar >> and >> some native DLLs then isn't it just another library that gets added to the >> classpath like everything else? >> > No, unfortunately it is not that simple. > > First of all plugin and webstart code used to be inherently Swing/AWT > based. > To get most of JavaFX (at least performance wise) you do not want to run > it in the heavyweight AWT container or load Swing/AWT classes. > > Browser integration is not that simple if you want to use hardware > acceleration in browser window. > There is special code in JavaFX to attach stage to window handle provided > by the browser. > > Obviously Java plugin in JRE6 has no idea of JavaFX existence as it was > implemented years before it. > Hence to be able to support users who stuck with JRE6 and can not switch > to latest JRE7 (or 8) we > are shipping updated copy of deployment with JavaFX. > > JavaFX-specific changes are merged back into JRE source base. E.g. JRE7 > update 2 has (almost) the same deployment stack as JavaFX 2.0.2. > But deployment code need to be in sync with JavaFX code and dependencies > are tight. So, as we march to support new platforms (Mac/Linux) > source bases will again be different for some more time. > > Eventually JRE will include full JavaFX capable plugin and there will be > no need to include it into JavaFX (assuming most of the users will migrate > to > new version of JRE). But this likely will take time. > > > > Ideally installing the plugin(s) really needs to be simple (1 or 2 click > install). Currently the Java one takes me off to another page and makes me > jump through a lot more hoops and then the > JFX one has another go at me. > It would be great if we could work out ways to avoid these hoops. Maybe the > co-bundling will fix all this, but it would be nice to just streamline > everything as > > soon as possible. > > Cobundling should improve things a little but in general i agree user > experience could be improved. > We would be happy to hear about possible ideas of how to improve the > process (and yet satisfy legal requirements such as accepting the license). > > > > We also assume that JavaFX runtime is shared install per system (or > >> eventually per user) and then we want to be able to keep track of what >>> users have installed/use and autoupdate it when important updates are >>> available (e.g. security). >>> >>> This is a risky approach, especially for developers. I often have >> multiple >> JDKs and JVMs installed on my machine which means I need the correct JFX >> install in each. >> > There is a difference between developer who needs SDK to build app and > user who only needs runtime to run app. > We are not autoupdating SDK as it can not be used by attacker. > Like with JDK you may still have multiple JavaFX SDK installed (at least i > do not see why not). > > Runtime is different. Whenever you open web page with javafx application > it will be launched using installed runtime. > And if this runtime is vulnerable then user is in trouble. Keeping it up > to data and secure is important. > > If you really need to test with older version of runtime then you can > install it and decline offers to autoupdate it. > > > > I currently have a system where it thinks I don't have JFX installed but > I do, but not in the JRE the browser is using, but the deployment tool > won't let me install it because it thinks I have it > > already installed. In fact each of the computers I use (3 of them) seem > to do something slightly different when I try to run an applet and > something different again when I run a webstart app > (and rarely do they > work, and never with any real message on why they failed). > > Sorry to hear that. > Would you mind filing issues on this and providing us with trace/log files? > > > > My best guess is that the multiple versions of stuff is confusing the > deployer. I have 64 bit and 32 bit versions on my machine at the same time > too, as some of the native libraries (e.g. finger print scanner) that I use > need this. > > Well, in theory both plugin and webstart are supposed to use one "latest" > version as it should supersede others. > If you have both 32 and 64 bit versions then there are 2 "latest" versions > and they are selected depending on whether your browser is 32 or 64 bit. > (Most of the browsers are still 32 bit). > > Typical source of the issues right now is that JRE6 is not fully updated > to be JavaFX aware and if JRE6 is installed/uninstalled/upgraded while > JavaFX runtime is installed then it can corrupt registry. Also, before > 2.0.2 installer had nasty bug and if JavaFX runtime was installed by one > user then another user could neither install it nor use it i think. > > We are solving these issues as we learn about them. Please report bugs to > JIRA and we will do our best to make it more robust. > > > > When we have multiple versions of JFX out there, we will end up with > JNLP files specifying specific specific versions to use (as we see now with > Swing and JRE versions). If a jnlp file sepcifies an older version of JFX > is required (i.e. I don't want my code to run on the latest because it > causes me problems, etc), then what will the install tools do in this case? > > Current thinking is that we will only allow to specify minimal version > assuming all JavaFX version in the same family are backward compatible. > I.e. you can request 2.0.2+ but if user has 2.0.3 installed you can not > request him to install 2.0.2. > > > > What exactly are the security risks associated with JavaFX? How does > this differ to say me using another display library like SWT or any toolkit > like GWT, or hibernate, or spring. > > The biggest difference is that JavaFX will likely be preinstalled on large > number of systems and shared between different applications. > It does not come as private part of the application (by default). > > > > We also use the fact that JavaFX runtime is installed to be able to > autodetect runtime install path when standalone application is being > launched > >> >> Can you elaborate on why standalone apps would need this and how they can >> work this out? The problem we have at the moment is exactly that the >> standalone app can't find the installation path (and hence the native >> files) without being told where it is via the system path, which is not >> setup by the installer. I'd be interested to understand more about this >> autodetect mechanism, how it is used currently, and how I might be able to >> make use of it. >> > If you follow JavaFX application packaging guidelines (see deployment > guide on javafx.com) then result application jar will contain small > launcher program > that will be used as default entry point (e.g. when you double click on > jar) and it is capable of checking system requirements (e.g. presence of > JRE) > and detecting where JavaFX runtime is installed. Then it will setup > classpath to include required.jars and instantiate main Application class. > > > What is it >> that JFX does above beyond what standard JRE/JNLP has been doing for a >> while? >> > E.g. embedded launcher can check this without JNLP. > I.e. you can ship just jar file and user will be guided how to run it as > long as it has java. > > -igor > > From stardrive.engineering at gmail.com Wed Dec 7 19:46:38 2011 From: stardrive.engineering at gmail.com (Stardrive Engineering) Date: Wed, 7 Dec 2011 21:46:38 -0600 Subject: JavaFX Desktop deployment (offshoot from: JavaFX Maven support) Message-ID: Very much love the very hard but powerful feature you describe. I would extend that a bit further if possible to include the following. Lets say we have an app to create drawings, then that this app can publish those drawings as HTML5/SVG web pages. Then as web users discover the published web pages via the built in meta-tags the users can simply click on a button on the web page to auto download the drawing (which is referenced by the web page and published to a the same host or even linked to lets say a Lucene/Solr index somewhere). Then if the clicking user does not have the drawing app it is first auto downloaded then the running app auto loads the drawing. If the user does not have JavaFX it first installs that then the app then loads the drawing. Consider the published drawing to be an advanced form of landing pages. So, if the maker of the drawing app wanted to publish 1000 cool drawings with different meta-tags each they would have 1000 web agents at their service serving them very well. Another consideration for the optimal smart installer (that JavaFX can then use to dominate the world :-) would be licensing. Having optional hooks to build in something like the Nalpeiron solution would be very nice. See http://www.nalpeiron.com Stardrive On 2011-12-07, at 5:50 PM, Daniel Zwolenski wrote: > Thanks for the in-depth info Igor. The pieces of the puzzle are starting to > become clear to me, sorry it takes my head a while to get in gear :) see previous message for very long text that maxed out allowable message length when attempting to send this message... From igor.nekrestyanov at oracle.com Wed Dec 7 21:35:24 2011 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Wed, 07 Dec 2011 21:35:24 -0800 Subject: JavaFX Desktop deployment (offshoot from: JavaFX Maven support) In-Reply-To: References: Message-ID: <4EE04C9C.7020804@oracle.com> Scenario you are describing essentially is "all-in-one" native installers for application. This assumes that you are ok with: a) increased footprint due to need to ship JRE and FX with every copy of the app (online user may download part on demand but this will not work for offline installs) b) having package per platform This scenario is likely doable now (once javafx is open sourced): a) You can build/pick parts of JRE/FX you need to cobundle with your app based on open source b) Use existing platform specific tools to package installer for platform - e.g. dmg/Sparkle for Mac, WiX for windows, rpm/deb for Linux, etc. I do not see why tool needs to be tailored for Java. c) You may even use JNLP install-desc to distribute your app with Webstart This way you can get updates (as full download) and also autoselect the installer to launch based on the platform. But this assumes user has Java installed (that is true for large fraction of users though) I totally agree that this scenario make sense for some applications but it is not silver bullet for all use cases. E.g. this is a lot of overhead for tiny utility. -igor On 12/7/11 3:50 PM, Daniel Zwolenski wrote: > Thanks for the in-depth info Igor. The pieces of the puzzle are starting to > become clear to me, sorry it takes my head a while to get in gear :) > > I've renamed the thread (again) to reflect the direction this conversation > is taking. I think the Maven conversation is now separate and should be > continued off on its own. If this thread is not a correct conversation for > this forum, please let me know and I can take it to the forums, or wherever > you think it should belong. > > Summing up: the deployment complexities seem to be mostly centered around > embedding JFX within a Browser, which makes a lot of sense (it's fairly > amazing this can be achieved at all). Additionally there are some > challenges with maintaining a 'current' JFX install and auto-updating this > when new releases are made. The focus of the install+plugin is mostly in > solving these two issues. > > The reason I was simplifying the deployment in my head is because the two > issues are not features that I use in my deployment. The end result being > that I am having to jump hurdles that don't make sense in my scenario. > > My apps are mostly desktop business apps, often used in the 'back-office'. > It is rare for me to use Applets or have a need to embed my application in > a Browser. I also often don't want auto-updates of JFX (or the JRE for that > matter) as there is often corporate policy/control over this, which > mandates installation privileges and tries to ensure all desktops in the > organisation are running the same version of things, etc. The sys admins > would want to know about and control any updates, especially security > holes. > > Perhaps the end result is that the current webstart deployment mechanism is > not actually for pure desktop apps, and we instead need to look at an > alternate mechanism like the ones you have suggested. What desktop app > developers really need is something like a (free) InstallShield for JavaFX, > that also includes automatic updates. For desktop apps, the web is a > distribution mechanism, not the application platform/runtime. > > As a thought-experiment I've tried to come up with the perfect deployment > user experience for a pure desktop app, ignoring the fact that applets even > exist. It would be nice to work backwards from this to see what can be > achieved, whether it is a case of updating the deployment tools, creating > new ones in JFX, or this feature being left to third-party tools (like Java > installshield, but it is currently not in a good state). > > *Background* > > Lisa is a business user at ACME mining, responsible for determining its > carbon footprint in order to reduce greenhouse gas emissions. Lisa has just > learnt of a new product called FootprintFX, a desktop application for > calculating carbon footprints, built in JavaFX. Lisa is a Windows 7 user > with basic technical skills. She has no Java installed on her machine and > has no idea what Java or JavaFX really are. > > *Installation steps* > > 1. Using her favourite web browser and google, Lisa finds the home page > for FootprintFX and clicks the 'download for Windows7 now' button > 2. The browser downloads an exe to Lisa's computer, which she then runs > 3. Windows security pops up a message (as it likes to do) saying "do you > want to let this program make changes". Lisa hits yes. > 4. The executable detects that Java is not installed. It shows a screen > asking the user if they would like to install it and the directory to > install to. Lisa leaves it at the default directory (c:\Program Files\java) > 5. The executable shows a combined T&C for using Java, JavaFX. Lisa does > the usual - ticks 'I agree' without reading it and hits 'next' > 6. The executable installs Java and JavaFX to the location specified > (JFX is installed in the same directory as the JRE). Lisa just sees a > single progress bar for all this, with no dialogs popping up, etc. > 7. Once Java and JFX are installed the system then asks Lisa where to > install FootprintFX and whether she wants a Start Menu and Desktop link. > Lisa leaves it at the default settings (c:/Program Files/FootprintFX) > 8. The install is complete (an icon has been added to the Start Menu and > Desktop - as per Lisa's selection) and Lisa has the option to 'Run Now' > > *Running * > > > > 1. Lisa clicks the desktop shortcut or start menu link > 2. The application shows the custom splash screen for FootprintFX while > behind the scenes Java is loading and the FootprintFX main window is being > created. > 3. On startup a check is made back to the FootprintFX for any updates. > If an update is found, Lisa is given the option to update to this new > version automatically. If Lisa clicks yes, then the new jars/resources are > downloaded and the JVM is restarted with the new details. > 4. Once the latest code has been loaded, the splash screen is hidden and > the application is run. Although the jars are not signed, the application > has all permissions (i.e. no sandbox). > > *Variations and comments: * > > - If the user already has Java and/or JavaFX installed the installer > should just use these and skip this whole step. > - If the user has Java installed but not JavaFX, the step should just be > the install of this > - If the user has an older version of these, it should give the user the > option to upgrade the current install, or install a seperate version > - Auto updates (of Java, JFX and/or the app) should be configurable by > the creator of the installation package > - The installer should be able to map file types to the installed > Application - i.e. I should be able to make files of type .cfp (carbon > footprint) get directed directly to FootprintFX. > > There is one very hard feature but very powerful feature that would be > awesome to have. It would be incredibly useful to be able to have something > like an 'application url', where we can embed this url inside an email or > web page, and when a user clicks on it, it opens the local desktop > application but passes in parameters to it. This is the same idea (and > would be used in the same way) as web browser URLs, which launch the local > web browser and pass an address to it. > > Being able to embed a link in an email to a page on the web has been > incredibly useful for web apps. Being able to embed a link in an email to a > 'place' within an application (e.g. open FootprintFX and point it to the > 'flights calculation page' with flight details prepoluated) would be > amazing. > > I don't know how this would be achieved however. The only way I can think > of is to use a URL that opens a web page that then triggers the launcher to > be run passing in parameters, i.e. hijack the browser way of doing it and > then hook in a Java trigger. Not ideal, but otherwise both the operating > system and the email browsers (and web browsers) would need to support an > 'application URL' and I'm not sure that's achievable. Something like this > would be the place to start looking I guess: > http://msdn.microsoft.com/en-us/library/aa767914(v=vs.85).aspx Each OS > would do this differently if it does it at all. > > > Interested in hearing a variety of thoughts on this topic. What do other > people see as the key deployment issues/models/options for JavaFX? > > > > On Wed, Dec 7, 2011 at 5:56 PM, Igor Nekrestyanov< > igor.nekrestyanov at oracle.com> wrote: > >> Hi, >> >> >> To be able to launch JavaFX application embedded in the browser or using >> >>> Webstart we need to have JavaFX aware plugin/deployment stack to be >>>> registered in the browser. >>>> >>>> The plugin to run Java makes sense, and this has been around for a while >>> now. Improving it is nice, but this should be done back in the core JRE >>> area I would have thought? It's the 'install' of JavaFX that I am confused >>> about. I'm possibly over simplifying things but if JavaFX is just a jar >>> and >>> some native DLLs then isn't it just another library that gets added to the >>> classpath like everything else? >>> >> No, unfortunately it is not that simple. >> >> First of all plugin and webstart code used to be inherently Swing/AWT >> based. >> To get most of JavaFX (at least performance wise) you do not want to run >> it in the heavyweight AWT container or load Swing/AWT classes. >> >> Browser integration is not that simple if you want to use hardware >> acceleration in browser window. >> There is special code in JavaFX to attach stage to window handle provided >> by the browser. >> >> Obviously Java plugin in JRE6 has no idea of JavaFX existence as it was >> implemented years before it. >> Hence to be able to support users who stuck with JRE6 and can not switch >> to latest JRE7 (or 8) we >> are shipping updated copy of deployment with JavaFX. >> >> JavaFX-specific changes are merged back into JRE source base. E.g. JRE7 >> update 2 has (almost) the same deployment stack as JavaFX 2.0.2. >> But deployment code need to be in sync with JavaFX code and dependencies >> are tight. So, as we march to support new platforms (Mac/Linux) >> source bases will again be different for some more time. >> >> Eventually JRE will include full JavaFX capable plugin and there will be >> no need to include it into JavaFX (assuming most of the users will migrate >> to >> new version of JRE). But this likely will take time. >> >> >>> Ideally installing the plugin(s) really needs to be simple (1 or 2 click >> install). Currently the Java one takes me off to another page and makes me >> jump through a lot more hoops and then the> JFX one has another go at me. >> It would be great if we could work out ways to avoid these hoops. Maybe the >> co-bundling will fix all this, but it would be nice to just streamline >> everything as >>> soon as possible. >> Cobundling should improve things a little but in general i agree user >> experience could be improved. >> We would be happy to hear about possible ideas of how to improve the >> process (and yet satisfy legal requirements such as accepting the license). >> >> >>> We also assume that JavaFX runtime is shared install per system (or >>> eventually per user) and then we want to be able to keep track of what >>>> users have installed/use and autoupdate it when important updates are >>>> available (e.g. security). >>>> >>>> This is a risky approach, especially for developers. I often have >>> multiple >>> JDKs and JVMs installed on my machine which means I need the correct JFX >>> install in each. >>> >> There is a difference between developer who needs SDK to build app and >> user who only needs runtime to run app. >> We are not autoupdating SDK as it can not be used by attacker. >> Like with JDK you may still have multiple JavaFX SDK installed (at least i >> do not see why not). >> >> Runtime is different. Whenever you open web page with javafx application >> it will be launched using installed runtime. >> And if this runtime is vulnerable then user is in trouble. Keeping it up >> to data and secure is important. >> >> If you really need to test with older version of runtime then you can >> install it and decline offers to autoupdate it. >> >> >>> I currently have a system where it thinks I don't have JFX installed but >> I do, but not in the JRE the browser is using, but the deployment tool >> won't let me install it because it thinks I have it >>> already installed. In fact each of the computers I use (3 of them) seem >> to do something slightly different when I try to run an applet and >> something different again when I run a webstart app> (and rarely do they >> work, and never with any real message on why they failed). >> >> Sorry to hear that. >> Would you mind filing issues on this and providing us with trace/log files? >> >> >>> My best guess is that the multiple versions of stuff is confusing the >> deployer. I have 64 bit and 32 bit versions on my machine at the same time >> too, as some of the native libraries (e.g. finger print scanner) that I use >> need this. >> >> Well, in theory both plugin and webstart are supposed to use one "latest" >> version as it should supersede others. >> If you have both 32 and 64 bit versions then there are 2 "latest" versions >> and they are selected depending on whether your browser is 32 or 64 bit. >> (Most of the browsers are still 32 bit). >> >> Typical source of the issues right now is that JRE6 is not fully updated >> to be JavaFX aware and if JRE6 is installed/uninstalled/upgraded while >> JavaFX runtime is installed then it can corrupt registry. Also, before >> 2.0.2 installer had nasty bug and if JavaFX runtime was installed by one >> user then another user could neither install it nor use it i think. >> >> We are solving these issues as we learn about them. Please report bugs to >> JIRA and we will do our best to make it more robust. >> >> >>> When we have multiple versions of JFX out there, we will end up with >> JNLP files specifying specific specific versions to use (as we see now with >> Swing and JRE versions). If a jnlp file sepcifies an older version of JFX >> is required (i.e. I don't want my code to run on the latest because it >> causes me problems, etc), then what will the install tools do in this case? >> >> Current thinking is that we will only allow to specify minimal version >> assuming all JavaFX version in the same family are backward compatible. >> I.e. you can request 2.0.2+ but if user has 2.0.3 installed you can not >> request him to install 2.0.2. >> >> >>> What exactly are the security risks associated with JavaFX? How does >> this differ to say me using another display library like SWT or any toolkit >> like GWT, or hibernate, or spring. >> >> The biggest difference is that JavaFX will likely be preinstalled on large >> number of systems and shared between different applications. >> It does not come as private part of the application (by default). >> >> >>> We also use the fact that JavaFX runtime is installed to be able to >> autodetect runtime install path when standalone application is being >> launched >> >>> Can you elaborate on why standalone apps would need this and how they can >>> work this out? The problem we have at the moment is exactly that the >>> standalone app can't find the installation path (and hence the native >>> files) without being told where it is via the system path, which is not >>> setup by the installer. I'd be interested to understand more about this >>> autodetect mechanism, how it is used currently, and how I might be able to >>> make use of it. >>> >> If you follow JavaFX application packaging guidelines (see deployment >> guide on javafx.com) then result application jar will contain small >> launcher program >> that will be used as default entry point (e.g. when you double click on >> jar) and it is capable of checking system requirements (e.g. presence of >> JRE) >> and detecting where JavaFX runtime is installed. Then it will setup >> classpath to include required.jars and instantiate main Application class. >> >> >> What is it >>> that JFX does above beyond what standard JRE/JNLP has been doing for a >>> while? >>> >> E.g. embedded launcher can check this without JNLP. >> I.e. you can ship just jar file and user will be guided how to run it as >> long as it has java. >> >> -igor >> >> From Martin.Soch at oracle.com Thu Dec 8 01:08:58 2011 From: Martin.Soch at oracle.com (Martin Soch) Date: Thu, 08 Dec 2011 10:08:58 +0100 Subject: request for API change approval: ObservableSet In-Reply-To: References: <4EDF7F83.2070909@oracle.com> Message-ID: <4EE07EAA.8060708@oracle.com> Hi Richard, thanks for your comments. - public wrappers: Martin Sladecek is recently (in a separate request) moving wrapper classes to the javafx.collection package as well; I don't know the motivation behind but Michael Heinrichs (on CC) might know more - var-arg factory method: will add it unless anyone has any objections Thanks Martin On 12/07/2011 08:09 PM, Richard Bair wrote: > Hi Martin, > > Generally I would suggest that we move this conversation to the openjfx-dev mailing list. I'm wanting to start moving as many of these sorts of design approval requests there as we can. > > However, my first thoughts: > - Yay! > - Why is ObservableSetWrapper public? We don't have any other Wrappers for the other collections public, do we? Are we sure we want to do this now? > - I would suggest adding a var-args factory method to FXCollections for creating a set, as well as a Collections version for convenience > > Otherwise looks consistent with our other Observable collections as far as I can see. > > Thanks > Richard > > On Dec 7, 2011, at 7:00 AM, Martin Soch wrote: > >> Hi team, >> >> I would like to ask you for approval for a new API to be pushed to 2.1 repository. This new API is adding ObservableSet interface into javafx.collection package with basic wrapper implementation. This change is not modifying any current API; just adding new functionality. >> >> JIRA: http://javafx-jira.kenai.com/browse/RT-14664 >> WebRev: http://javame-linux.cz.oracle.com/r/1334/ >> >> Thanks >> Martin > From lubomir.nerad at oracle.com Thu Dec 8 01:12:56 2011 From: lubomir.nerad at oracle.com (Lubomir Nerad) Date: Thu, 08 Dec 2011 10:12:56 +0100 Subject: ImageView should have shorthand creation function Message-ID: <4EE07F98.5070207@oracle.com> Hi, I am looking at http://javafx-jira.kenai.com/browse/RT-6554. It requests to add a possibility to create image view and its image from url in one step. What I think should be discussed is whether to add this as a new constructor to the ImageView class or as a static factory method. So the options are: 1) public ImageView(String url) { ... } 2) public static ImageView image(String url) { ... } (or another name) Unless we expect that we will need more possibilities for image specification (more shorthand creation methods) in the future, I am leaning towards option 1. What do you think? Thanks, Lubo From zonski at googlemail.com Thu Dec 8 01:41:53 2011 From: zonski at googlemail.com (Daniel Zwolenski) Date: Thu, 8 Dec 2011 20:41:53 +1100 Subject: ImageView should have shorthand creation function In-Reply-To: <4EE07F98.5070207@oracle.com> References: <4EE07F98.5070207@oracle.com> Message-ID: Option 1 is better for FXML (although we can just use builders). Gets my vote anyway. Will the URL be relative to the classpath? I.e will the implementation be equivalent to Image.getClass().getResource and will this be ok in deployed apps I think there have been issues with this on other areas (I think multiple classloaders are used in deploy mode). On 08/12/2011, at 8:12 PM, Lubomir Nerad wrote: > Hi, > > I am looking at http://javafx-jira.kenai.com/browse/RT-6554. It requests to add a possibility to create image view and its image from url in one step. What I think should be discussed is whether to add this as a new constructor to the ImageView class or as a static factory method. > > So the options are: > > 1) public ImageView(String url) { ... } > 2) public static ImageView image(String url) { ... } (or another name) > > Unless we expect that we will need more possibilities for image specification (more shorthand creation methods) in the future, I am leaning towards option 1. > > What do you think? > > Thanks, > Lubo > From zonski at googlemail.com Thu Dec 8 01:48:05 2011 From: zonski at googlemail.com (Daniel Zwolenski) Date: Thu, 8 Dec 2011 20:48:05 +1100 Subject: JavaFX Desktop deployment (offshoot from: JavaFX Maven support) In-Reply-To: <4EE04C9C.7020804@oracle.com> References: <4EE04C9C.7020804@oracle.com> Message-ID: <3B7FE119-6AD7-4FA1-BFF5-4C38A06FBC8F@gmail.com> > I totally agree that this scenario make sense for some applications but it is not silver bullet for all use cases. > E.g. this is a lot of overhead for tiny utility. I would have said the exact same thing about the embedded applet utility ;) From kirill.prazdnikov at oracle.com Thu Dec 8 02:01:19 2011 From: kirill.prazdnikov at oracle.com (Kirill.Prazdnikov) Date: Thu, 08 Dec 2011 14:01:19 +0400 Subject: ImageView should have shorthand creation function In-Reply-To: <4EE07F98.5070207@oracle.com> References: <4EE07F98.5070207@oracle.com> Message-ID: <4EE08AEF.3060100@oracle.com> Method #2 allows returning null, which i think is nice. -Kirill On 08-Dec-11 13:12, Lubomir Nerad wrote: > Hi, > > I am looking at http://javafx-jira.kenai.com/browse/RT-6554. It > requests to add a possibility to create image view and its image from > url in one step. What I think should be discussed is whether to add > this as a new constructor to the ImageView class or as a static > factory method. > > So the options are: > > 1) public ImageView(String url) { ... } > 2) public static ImageView image(String url) { ... } (or another name) > > Unless we expect that we will need more possibilities for image > specification (more shorthand creation methods) in the future, I am > leaning towards option 1. > > What do you think? > > Thanks, > Lubo > From Martin.Soch at oracle.com Thu Dec 8 02:14:49 2011 From: Martin.Soch at oracle.com (Martin Soch) Date: Thu, 08 Dec 2011 11:14:49 +0100 Subject: request for API change approval: ObservableSet In-Reply-To: <4EE07EAA.8060708@oracle.com> References: <4EDF7F83.2070909@oracle.com> <4EE07EAA.8060708@oracle.com> Message-ID: <4EE08E19.3090209@oracle.com> Hi Richard, after discussion with Martin Sladecek he suggested to remove ObservableSetWrapper from public API so it will be consistent for now. Thanks Martin On 12/08/2011 10:08 AM, Martin Soch wrote: > Hi Richard, > > thanks for your comments. > > - public wrappers: Martin Sladecek is recently (in a separate request) > moving wrapper classes to the javafx.collection package as well; I don't > know the motivation behind but Michael Heinrichs (on CC) might know more > - var-arg factory method: will add it unless anyone has any objections > > Thanks > Martin > > On 12/07/2011 08:09 PM, Richard Bair wrote: >> Hi Martin, >> >> Generally I would suggest that we move this conversation to the >> openjfx-dev mailing list. I'm wanting to start moving as many of these >> sorts of design approval requests there as we can. >> >> However, my first thoughts: >> - Yay! >> - Why is ObservableSetWrapper public? We don't have any other Wrappers >> for the other collections public, do we? Are we sure we want to do >> this now? >> - I would suggest adding a var-args factory method to FXCollections >> for creating a set, as well as a Collections version for convenience >> >> Otherwise looks consistent with our other Observable collections as >> far as I can see. >> >> Thanks >> Richard >> >> On Dec 7, 2011, at 7:00 AM, Martin Soch wrote: >> >>> Hi team, >>> >>> I would like to ask you for approval for a new API to be pushed to >>> 2.1 repository. This new API is adding ObservableSet interface into >>> javafx.collection package with basic wrapper implementation. This >>> change is not modifying any current API; just adding new functionality. >>> >>> JIRA: http://javafx-jira.kenai.com/browse/RT-14664 >>> WebRev: http://javame-linux.cz.oracle.com/r/1334/ >>> >>> Thanks >>> Martin >> > From lubomir.nerad at oracle.com Thu Dec 8 03:53:49 2011 From: lubomir.nerad at oracle.com (Lubomir Nerad) Date: Thu, 08 Dec 2011 12:53:49 +0100 Subject: ImageView should have shorthand creation function In-Reply-To: References: <4EE07F98.5070207@oracle.com> Message-ID: <4EE0A54D.2000404@oracle.com> Hi Daniel, thanks for your vote. Currently the plan is to have the same interpretation of the url parameter as in "new Image(url)". But there is http://javafx-jira.kenai.com/browse/RT-18291 which will address the relative URL issue. Lubo On 8.12.2011 10:41, Daniel Zwolenski wrote: > Option 1 is better for FXML (although we can just use builders). Gets my vote anyway. > > Will the URL be relative to the classpath? I.e will the implementation be equivalent to Image.getClass().getResource and will this be ok in deployed apps I think there have been issues with this on other areas (I think multiple classloaders are used in deploy mode). > > > On 08/12/2011, at 8:12 PM, Lubomir Nerad wrote: > >> Hi, >> >> I am looking at http://javafx-jira.kenai.com/browse/RT-6554. It requests to add a possibility to create image view and its image from url in one step. What I think should be discussed is whether to add this as a new constructor to the ImageView class or as a static factory method. >> >> So the options are: >> >> 1) public ImageView(String url) { ... } >> 2) public static ImageView image(String url) { ... } (or another name) >> >> Unless we expect that we will need more possibilities for image specification (more shorthand creation methods) in the future, I am leaning towards option 1. >> >> What do you think? >> >> Thanks, >> Lubo >> From lubomir.nerad at oracle.com Thu Dec 8 03:58:29 2011 From: lubomir.nerad at oracle.com (Lubomir Nerad) Date: Thu, 08 Dec 2011 12:58:29 +0100 Subject: ImageView should have shorthand creation function In-Reply-To: <4EE08AEF.3060100@oracle.com> References: <4EE07F98.5070207@oracle.com> <4EE08AEF.3060100@oracle.com> Message-ID: <4EE0A665.6070207@oracle.com> Hi Kirill, I don't think that this possibility is useful for ImageView construction. Thanks, Lubo On 8.12.2011 11:01, Kirill.Prazdnikov wrote: > Method #2 allows returning null, which i think is nice. > > -Kirill > > On 08-Dec-11 13:12, Lubomir Nerad wrote: >> Hi, >> >> I am looking at http://javafx-jira.kenai.com/browse/RT-6554. It >> requests to add a possibility to create image view and its image from >> url in one step. What I think should be discussed is whether to add >> this as a new constructor to the ImageView class or as a static >> factory method. >> >> So the options are: >> >> 1) public ImageView(String url) { ... } >> 2) public static ImageView image(String url) { ... } (or another name) >> >> Unless we expect that we will need more possibilities for image >> specification (more shorthand creation methods) in the future, I am >> leaning towards option 1. >> >> What do you think? >> >> Thanks, >> Lubo >> > From richard.bair at oracle.com Thu Dec 8 10:34:32 2011 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 8 Dec 2011 10:34:32 -0800 Subject: ImageView should have shorthand creation function In-Reply-To: <4EE0A54D.2000404@oracle.com> References: <4EE07F98.5070207@oracle.com> <4EE0A54D.2000404@oracle.com> Message-ID: <104DBD46-F929-4D70-9CDA-0E44044866BA@oracle.com> I agree, I like the constructor. I think something special will have to be done to make it usable from FXML though (but that's because "url" isn't a property on ImageView and thus it will have to be special in the ImageViewBuilder for FXML to use it). I agree it needs to match the semantics of new Image(url). Richard On Dec 8, 2011, at 3:53 AM, Lubomir Nerad wrote: > Hi Daniel, > > thanks for your vote. Currently the plan is to have the same interpretation of the url parameter as in "new Image(url)". But there is http://javafx-jira.kenai.com/browse/RT-18291 which will address the relative URL issue. > > Lubo > > On 8.12.2011 10:41, Daniel Zwolenski wrote: >> Option 1 is better for FXML (although we can just use builders). Gets my vote anyway. >> >> Will the URL be relative to the classpath? I.e will the implementation be equivalent to Image.getClass().getResource and will this be ok in deployed apps I think there have been issues with this on other areas (I think multiple classloaders are used in deploy mode). >> >> >> On 08/12/2011, at 8:12 PM, Lubomir Nerad wrote: >> >>> Hi, >>> >>> I am looking at http://javafx-jira.kenai.com/browse/RT-6554. It requests to add a possibility to create image view and its image from url in one step. What I think should be discussed is whether to add this as a new constructor to the ImageView class or as a static factory method. >>> >>> So the options are: >>> >>> 1) public ImageView(String url) { ... } >>> 2) public static ImageView image(String url) { ... } (or another name) >>> >>> Unless we expect that we will need more possibilities for image specification (more shorthand creation methods) in the future, I am leaning towards option 1. >>> >>> What do you think? >>> >>> Thanks, >>> Lubo >>> From richard.bair at oracle.com Thu Dec 8 10:48:12 2011 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 8 Dec 2011 10:48:12 -0800 Subject: JavaFX Desktop deployment (offshoot from: JavaFX Maven support) In-Reply-To: References: Message-ID: <5D390EB0-F3DC-4CD0-BAC6-F16939EEF4ED@oracle.com> I think basically this comes down to: - Make it easy to co-bundle a JRE with the app - Make it easy to auto-update the app (including co-bundled JRE) This first part is doable (and licensing any day now for JavaFX when 2.0.2 goes out will allow it). We could do with some better tools, but maybe that is a business opportunity for somebody out there :-) The second part is interesting and also doable, though nothing like it exists yet for Java in general. However you might want to check the Sparkle framework available on Mac. Basically if you had that, but for Java, you'd be good to go. That also doesn't *need* to be part of the platform, it could be an open source project or commercial project. But in any case, I also think these are the natural thing to want to do for many Java applications. Richard From richard.bair at oracle.com Thu Dec 8 10:51:00 2011 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 8 Dec 2011 10:51:00 -0800 Subject: JavaFX Maven support (was: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls.) In-Reply-To: <84EB6395-265E-4CE5-A060-716112B562A2@gmail.com> References: <4C2C99B6-35CD-4E56-879D-49736745272F@oracle.com> <4EDEB1BB.5000409@oracle.com> <4EDF0E1C.1000607@oracle.com> <84EB6395-265E-4CE5-A060-716112B562A2@gmail.com> Message-ID: <9DA496D2-0E79-48FB-BA25-C3E5B47BFFB4@oracle.com> > [...long...] > >>> What is it >>> that JFX does above beyond what standard JRE/JNLP has been doing for a >>> while? >> E.g. embedded launcher can check this without JNLP. >> I.e. you can ship just jar file and user will be guided how to run it as long as it has java. > > > I still dream of a World where CacioWeb is used to run all sort of Java related > things in HTML5 based browsers. You and me both. Though I wouldn't necessarily use CacioWeb (the FX architecture would lend itself to doing things a little differently), the concept is definitely something I find interesting. Richard From gajasutra at gmail.com Thu Dec 8 11:07:26 2011 From: gajasutra at gmail.com (Gaja Sutra) Date: Thu, 08 Dec 2011 20:07:26 +0100 Subject: ListChangeListener Message-ID: <4EE10AEE.1010009@gmail.com> When trying to write the collections needed by my application and lacking in JavaFX runtime, I have found difficult to use ListChangeListener, because the code to write (the while loop on each change with tests of operation type) is difficult to read. I suggest the following addition to API: 1) In ObservableList add the following new method and create the corresponding interface: |public void addListener(ListChangeHandler obs);| |public interface ListChangeHandler { public void begin(); public void addedItem(int index, E addedItem); public void addedItems(int from, int to, List readOnlyAddedItems); // ReadOnlyIntList wrap the int[] to be read-only public void swapped(int from, int to, ReadOnlyIntList permutation); public void removedItems(int index, int size, List readOnlyDeletedItems); public void removedItem(int index, E removedItem); public void end(); } | 2) Provide a class of utilities methods for ListChangeHandler giving implementation of methods by delegating to it: |public class ListChangeUtils { public static void addedItems(ListChangeHandler handler, int from, int to, List readOnlyAddedItems) { for (int i = from; i, add default implementations for all methods excepted the following four methods: |public interface ListChangeHandler { public void begin(); public void addedItem(int index, E addedItem); public void removedItem(int index, E removedItem); public void end(); }| by having code like this, for other methods, in the preceding interface: | public void addedItems(int from, int to, List readOnlyAddedItems) default ListChangeUtils.||addedItems||; | 4) Conclusion: I think this will give correct performance by allowing, like with ListChangeListener, to have a specialized handler receiving directly the addition of multiple items (if it support this feature). But if the handler can not have optimized path for this case it will need in current Java to implement addedItems by calling |ListChangeUtils.addedItems(this, from, to, readOnlyAddedItems)| or in Java8 by doing nothing (automatically supported by defender method). This is the symmetric model for receiving notification of changes, like com.sun.javafx.collections.IterableChangeBuilder is for creating changes notification. For code readability, I think having one method for each type of operation on list will be much more clean and readable, because the while loop will disappear and each type of operation will correspond to one method of handler separated from others. Thanks for your opinions, Daniel. From han.solo at muenster.de Thu Dec 8 11:02:29 2011 From: han.solo at muenster.de (Gerrit Grunwald) Date: Thu, 8 Dec 2011 20:02:29 +0100 Subject: JavaFX Desktop deployment (offshoot from: JavaFX Maven support) In-Reply-To: <5D390EB0-F3DC-4CD0-BAC6-F16939EEF4ED@oracle.com> References: <5D390EB0-F3DC-4CD0-BAC6-F16939EEF4ED@oracle.com> Message-ID: <392F6C8D-5DAF-48B9-A5FD-FE7AE13700E1@muenster.de> I like the idea using a Sparkle like framework for auto-update functionality. A while ago I used this so called appcasting to auto-update a java desktop app that was wrapped into an exe file. In principle it is a rss feed that delivers a binary file similar to a podcast but with a program instead of an audio file. Should be relatively easy to do. Gerrit Am 08.12.2011 um 19:48 schrieb Richard Bair : > I think basically this comes down to: > > - Make it easy to co-bundle a JRE with the app > - Make it easy to auto-update the app (including co-bundled JRE) > > This first part is doable (and licensing any day now for JavaFX when 2.0.2 goes out will allow it). We could do with some better tools, but maybe that is a business opportunity for somebody out there :-) > > The second part is interesting and also doable, though nothing like it exists yet for Java in general. However you might want to check the Sparkle framework available on Mac. Basically if you had that, but for Java, you'd be good to go. That also doesn't *need* to be part of the platform, it could be an open source project or commercial project. > > But in any case, I also think these are the natural thing to want to do for many Java applications. > > Richard From richard.bair at oracle.com Thu Dec 8 11:52:53 2011 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 8 Dec 2011 11:52:53 -0800 Subject: request for API change approval: ObservableSet In-Reply-To: <4EE08E19.3090209@oracle.com> References: <4EDF7F83.2070909@oracle.com> <4EE07EAA.8060708@oracle.com> <4EE08E19.3090209@oracle.com> Message-ID: Cool. Can you create a new patch with the latest proposal and attach it to the JIRA issue? Thanks! Richard On Dec 8, 2011, at 2:14 AM, Martin Soch wrote: > Hi Richard, > > after discussion with Martin Sladecek he suggested to remove ObservableSetWrapper from public API so it will be consistent for now. > > Thanks > Martin > > On 12/08/2011 10:08 AM, Martin Soch wrote: >> Hi Richard, >> >> thanks for your comments. >> >> - public wrappers: Martin Sladecek is recently (in a separate request) >> moving wrapper classes to the javafx.collection package as well; I don't >> know the motivation behind but Michael Heinrichs (on CC) might know more >> - var-arg factory method: will add it unless anyone has any objections >> >> Thanks >> Martin >> >> On 12/07/2011 08:09 PM, Richard Bair wrote: >>> Hi Martin, >>> >>> Generally I would suggest that we move this conversation to the >>> openjfx-dev mailing list. I'm wanting to start moving as many of these >>> sorts of design approval requests there as we can. >>> >>> However, my first thoughts: >>> - Yay! >>> - Why is ObservableSetWrapper public? We don't have any other Wrappers >>> for the other collections public, do we? Are we sure we want to do >>> this now? >>> - I would suggest adding a var-args factory method to FXCollections >>> for creating a set, as well as a Collections version for convenience >>> >>> Otherwise looks consistent with our other Observable collections as >>> far as I can see. >>> >>> Thanks >>> Richard >>> >>> On Dec 7, 2011, at 7:00 AM, Martin Soch wrote: >>> >>>> Hi team, >>>> >>>> I would like to ask you for approval for a new API to be pushed to >>>> 2.1 repository. This new API is adding ObservableSet interface into >>>> javafx.collection package with basic wrapper implementation. This >>>> change is not modifying any current API; just adding new functionality. >>>> >>>> JIRA: http://javafx-jira.kenai.com/browse/RT-14664 >>>> WebRev: http://javame-linux.cz.oracle.com/r/1334/ >>>> >>>> Thanks >>>> Martin >>> >> > From peter.pilgrim at gmail.com Thu Dec 8 12:50:39 2011 From: peter.pilgrim at gmail.com (peter.pilgrim at gmail.com) Date: Thu, 8 Dec 2011 20:50:39 +0000 Subject: Maven JavaFx native libraries and OSGi Message-ID: Hi All What are ideas for JavaFX and native libraries? Has any one thought of a better maven schematic G.A.V that works with Jar and the myriad native DLL and Shared Object libraries for the future? Also how is JavaFX 2.x compatible with OSGi? Sent from my iPhone 4S From tbee at tbee.org Thu Dec 8 13:30:23 2011 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 08 Dec 2011 22:30:23 +0100 Subject: Maven JavaFx native libraries and OSGi In-Reply-To: References: Message-ID: <4EE12C6F.8080106@tbee.org> On 2011-12-08 21:50, peter.pilgrim at gmail.com wrote: > Hi All > > What are ideas for JavaFX and native libraries? Has any one thought of a better maven schematic G.A.V that works with Jar and the myriad native DLL and Shared Object libraries for the future? One idea is is to put all DLL's in a Maven artifact (jar) with a classifier of the platform and load them from that DLL. Workaround for this is implemented in JFXtras, but it could easily become part of the actual DLL loader. > > Also how is JavaFX 2.x compatible with OSGi? Not. It will be Jigsawed. Next question is: how OSGi compatible will Jigsaw be. Tom From zonski at googlemail.com Thu Dec 8 13:36:15 2011 From: zonski at googlemail.com (Daniel Zwolenski) Date: Fri, 9 Dec 2011 08:36:15 +1100 Subject: Maven JavaFx native libraries and OSGi In-Reply-To: <4EE12C6F.8080106@tbee.org> References: <4EE12C6F.8080106@tbee.org> Message-ID: > > One idea is is to put all DLL's in a Maven artifact (jar) with a > classifier of the platform and load them from that DLL. Workaround for this > is implemented in JFXtras, but it could easily become part of the actual > DLL loader. Would you see this extracting as only for developers or for runtime usage as well? If runtime, one thing to consider is the user may not have write permission to whatever directory the pre-loader is extracting to (e.g. unsigned app, or only admin can write to that directory). Also, for all cases its worth considering possible problems relating to versioning and removing the DLLs. i.e. could be hard to work out which DLLs are being used when something goes wrong (e.g. I've got 2.0.1 dlls somewhere on my system but I'm using a 2.1 jar, etc). From kevin.rushforth at oracle.com Thu Dec 8 14:04:33 2011 From: kevin.rushforth at oracle.com (kevin.rushforth at oracle.com) Date: Thu, 08 Dec 2011 22:04:33 +0000 Subject: hg: openjfx/2.1/master/rt: 12 new changesets Message-ID: <20111208220436.514C147643@hg.openjdk.java.net> Changeset: be35b718a109 Author: mickf Date: 2011-12-07 13:13 +0000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/be35b718a109 RT-17754 : [ProgressIndicator] Size is not updated dynamicaly ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java Changeset: 4c0d75c08ba5 Author: Paru Somashekar Date: 2011-12-07 17:21 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/4c0d75c08ba5 fix RT-17148 ChoiceBox popup styling issue ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ChoiceBoxSkin.java Changeset: 3195a596fa31 Author: leifs Date: 2011-12-07 17:18 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/3195a596fa31 Fixed RT-18422: TextInputControl should not notify content listeners on intermediate values when replacing text ! javafx-ui-controls/src/javafx/scene/control/TextArea.java ! javafx-ui-controls/src/javafx/scene/control/TextField.java ! javafx-ui-controls/src/javafx/scene/control/TextInputControl.java ! javafx-ui-controls/test/javafx/scene/control/TextAreaTest.java ! javafx-ui-controls/test/javafx/scene/control/TextFieldTest.java Changeset: 1258b293c169 Author: Paru Somashekar Date: 2011-12-07 20:43 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/1258b293c169 remove debug line ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ChoiceBoxSkin.java Changeset: 1426b6d5b791 Author: jgiles Date: 2011-12-08 10:59 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/1426b6d5b791 RT-18071: [Editable ComboBox] Pressing F4 should open/close the active list ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 0f2c75af06d6 Author: jgiles Date: 2011-12-08 12:25 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/0f2c75af06d6 RT-16482: Simple TableView operations are inefficient (Disabled duplicate calls to layoutChildren() in VirtualFlow) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 667124e26056 Author: jgiles Date: 2011-12-08 14:31 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/667124e26056 RT-18388: TableView.getSelectionModel().getSelectedItems() duplicates items select with Shift-Click ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: 6acce1b14ede Author: jgiles Date: 2011-12-08 15:11 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/6acce1b14ede RT-18385: TableView: incorrect selection while adding data items ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: a2aa78525c76 Author: jgiles Date: 2011-12-08 15:27 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/a2aa78525c76 RT-16482: Simple TableView operations are inefficient, part 2 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 682bde65e6d3 Author: jgiles Date: 2011-12-08 17:46 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/682bde65e6d3 RT-18388: TableView.getSelectionModel().getSelectedItems() duplicates items select with Shift-Click ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehavior.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: 39b77f7b2433 Author: jgiles Date: 2011-12-08 17:47 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/39b77f7b2433 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.1/scrum/controls/jfx/rt Changeset: f6abb0dd0f61 Author: mickf Date: 2011-12-08 14:01 +0000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/f6abb0dd0f61 RT-16821 - Mac OS: CSS padding not correctly applied on the ScrollPane content ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java From zonski at googlemail.com Thu Dec 8 14:27:46 2011 From: zonski at googlemail.com (Daniel Zwolenski) Date: Fri, 9 Dec 2011 09:27:46 +1100 Subject: Controls with Values [was Possible additions to JavaFX to facilitate forms and validations] In-Reply-To: <424E6A89-D6CD-4A71-87CE-98F14B66AA94@oracle.com> References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> <4EDE4972.8030205@broadpark.no> <67E8E7BD-24DB-4242-81FD-6C35389A7699@oracle.com> <4EDEA518.5090102@oracle.com> <4EDEB118.6010702@bestsolution.at> <4EDFB020.3060005@broadpark.no> <424E6A89-D6CD-4A71-87CE-98F14B66AA94@oracle.com> Message-ID: It seems I hit reply instead of reply-all on this email earlier - sorry about that. Embedded below is an email from myself (the most indented one), which was then replied-to by Richard (the less indented one) and my latest comments (the not indented one). *(Dan said)* After googling the definition of 'recapitulate' (turns out it > doesn't mean to give up twice), here is a summary: > > > *(Richard said)* > > Hehehe :-). After I typed it I rechecked the definition just to make sure I > had the right word. It does sound like giving up twice, I hadn't recognized > that before :-) > > *What*: > > Add a way to consistently access the primary 'value' of Controls where > such a value can be identified. The 'value' is whatever attribute of that > Control a developer would most consider it's defining data attribute (e.g. > text for TextField, selected for CheckBox). > > *Why:* > > 1. *Detect value changes*: a consistent valueProperty will make it > significantly easier to observe Controls and watch for changes made by the > user. This is particularly useful for creating 'forms', allowing the > developer to detect when a form has 'dirty' data and needs to be saved > (e.g. attempting to close the window shows a prompt "Save changes?") and > also to auto-validate a form field when it is changed and provide the user > with some visual feedback (e.g. a red 'X' or border highlight). > > 2. *Facilitate cleaner binding*: a consistent valueProperty will allow > for simpler, more intuitive binding between Controls and model properties > (e.g. a PresentationModel). For example, to bind a ChoiceBox currently the > developer must bind to > choiceBox.getSelectionModel().selectedItemProperty(), whereas the proposal > will allow for choiceBox.valueProperty(). This is more intuitive but also > removes the problem of watching for changes in the actual selectionModel > itself (the choiceBox.valueProperty will do this internally). Additionally > a consistent API will also allow for easier development of generic, > reflection based field binding tools (e.g. automagically bind all fields on > a PresentationModel to the correspondingly named Controls on the view). > > 3. *Facilitate bidirectional binding*: several Controls (in particular > those with a SelectionModel) provide only read-only access to their 'value' > fields and instead have additional methods for changing the value (such as > select(value) and clearSelection()) . The proposed valueProperty should be > able to hide this from the developer (i.e. the internal implementation can > map to the appropriate selection model call), providing a simple read-write > property with full binding support. This is of particular usefulness for > FXML where mapping to the relevant method call would be very messy. > > I think the benefit in having a HasValue is that it allows frameworks to > work with controls in a generic manner. I'm not sure it actually adds > benefit to developers directly. So for example, the fact that > TextField.text is used in one place and Slider.value in another I don't > think causes confusion for developers, but it does cause confusion for > automated tools. So I probably would have worded the argument such that > having tools that can deal with controls in an abstract manner is important > because it enables the following use cases (a "form" framework which > manages blah, or whatnot). So for example each of the argument lead ins > ("Detect value changes", "Facilitate cleaner binding", "Facilitate > bidirectional binding") don't require HasValue -- they are satisfied with > the current design. Not trying to nitpick, just refine the argument so it > is clear exactly what we're going after here. From a gut sense it seems > there is something valuable (ha ha) in the proposal, but I'm trying to work > it down to the essence. > > The argument in #2 I think is not very strong because HasValue isn't > required to fix this. That is, we can add a "value" property to ChoiceBox > without having a HasValue interface, so it doesn't address the question > "why is HasValue important?". > True. The only thing that is arguably 'more intuitive' is the ChoiceBox, where the concept of a 'value' is added. This could definitely be done by looking at the ChoiceBox/ComboBox in isolation. So generally, yes, the proposal of a generic HasValue thing is of most benefit to framework development that wants to access fields in a generic way. There is a style of MVP design pattern however where this generic HasValue would be of benefit to the developer. I could create an interface for my view like so: PersonView { HasValue getFirstNameField(); HasValue getLastNameField(); HasValue getGenderField(); } And then my Presenter can interact with it in a view-implementation-agnostic way (i.e. just set the values as needed). If the view chooses to implement the HasValue with a ComboBox a ChoiceBox or some custom built HasValue implementing control, then the controller doesn't change. Very nice view/presenter separation. Of course this pattern has developed in the absence of observable properties and both aim to solve similar problems. It's not yet clear (to me anyway) whether this 'View interface' pattern is superseeded by JFX properties. To a certain extent, FXML doesn't facilitate the above pattern (it could but would need some changes) so there will be a natural lean away from it and towards observable presentation model style patterns. #3 is very interesting because I would have said that the "value" of a > ListView is the "items" list, not the selection. This is another reason I > am trying to refine the arguments, because I think there is something > interesting in that your proposal was that the "value" was the selected > item whereas my assumption was that it was the data model. > Good point. The problem comes back to the ChoiceBox (and ComboBox) I think. The 'selection' in a ChoiceBox is very different conceptually to the selection in a TreeView or TableView. I think my comments/arguments make most sense in the context of ChoiceBox/ComboBox (which, thinking back was what I first started with, and then List/Table/Tree were organic, and perhaps wrong, extensions of that thought process). Further thoughts on this would be good - perhaps List/Tree/Table shouldn't implement HasValue at all. > > That is, I'm thinking of the "value" as the data model object added to a > control. But the selectedItem is something else entirely. Why do you think > this is? It seems what you might think of as the "value" depends on > context. It seems maybe we should divide the world in "value" controls and > "multi-value" controls (as you first did with HasValue vs. HasValues). But > the difference would be that the multi-value control is one where it has a > value (an ObservableList or TreeItem or something) and also some > selection. And then you have some generic way to interact with both the > concept of value and selection on such controls. > > > > And then each Control would implement this interface to map to their > relevant Control specific property as follows: > > - Accordian => (n/a) > - ChoiceBox => selectionModel.selectedItemProperty > - HTMLEditor => (n/a - htmlText is not a property?) > > Oh crap, that was an oversight! Do you want to file an RFE? Yikes! > http://javafx-jira.kenai.com/browse/RT-18436 > > *Outstanding Issues: * > > - *Naming*: the HasValue name makes a lot of sense to me, but Richard > has raised some concerns. I think this is just a question of what you are > used to. Anyone using Google frameworks will find the HasX (and IsX) naming > convention very familiar (for example just found this: > http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/user/client/ui/HasValue.java?r=4202). > I thought Spring and other frameworks used similar stuff but I can't find > any examples so perhaps I imagined this (there is a HasGetTransferHandler > buried in Swing's DnD and AspectJ has some HasX classes). The floor is open > on this one: HasValue, Valuable, ValueProvider, ValueSource, ValueOwner, > HasValueProperty, ValueThingThatWeCouldntThinkOfAGoodNameFor? > > What else, other than controls, would implement this proposed interface? > That is, is it really HasValue, or is it SingleValuedControl, > MultiValuedControl? This gets back to the need to tighten up the use cases > and arguments. Is the goal to make UI Controls more uniform for tools, or > is there a larger goal? For example, what happens if I have a layout > container that implements this interface. Is there some good reason why I > might want to do that? > Well, there's a possible example below with 'ToggleGroup'. Another possibility that is in the back of my mind but I'm not sure if it will work cleanly is a 'form' itself. In this case you would have a whole lot of HasValue fields binding to a bean, which in turn is exposed as the HasValue of the entire form (which is probably extending one of the Panes or MigPane). Also, if the 'View interface' outlined above is used then creating Mock objects is a definite possibility for testing. i.e. I don't need to create a real TextField for testing my controller/presenter, I can just create a mock HasValue and fire different things at it (like invalid text for testing validation). Frameworks like Spring (and following on Guice and GWT) have made interfaces-for-everything fairly popular with the general "it's better for testing" argument as the default and other arguments (such as multiple-inheritance, aspect injection, etc) just as a bonus. > > - *Toggle/RadioButton and ToggleGroup*: a new issue that has come out > of putting the above list together is the binding for toggle button groups. > Ideally we would be able to bind to this in much the same way we bind to a > ChoiceBox, where the value is the 'item' of the selected button. The toggle > group doesn't have the idea of items in it however. Perhaps it should. > Thoughts on this? > > A good thing to think on. I think most people would agree that from a > data-representation perspective, a ToggleGroup of RadioButtons is > essentially just a variation on a ChoiceBox. Having some similarity there > would be nice. > Agreed. > > Another thing I wanted to mention was why SelectionModel doesn't allow you > to bind. The basic issue is that, with binding, all bets are off. If you > bind a property to something (unidirectionally), then it is off limits to > the Skin (an attempt to set a property that is unidirectionally bound > results in an exception). We tried to avoid any API where exposing > something as a full property would compromise the usability of the control. > So for example, Button has an "armed" read only property with "arm()" and > "disarm()" methods. They don't do anything other than set the armed state. > Why wasn't this just made a mutable property? Because doing so would mean > somebody could bind armed unidirectionally and then the Button would no > longer look or act right. Avoiding inconsistent states made the controls > code a lot easier and more bullet-proof. > > I don't remember but I suspect that is another reason why SelectionModel > is as it is. If we provided a "value" property that mapped to the > selectedItem, then somebody could bind the value property unidirectionally, > and any attempt to change selection on the SelectionModel would be broken. > Is that really what we want? What is the use case for binding > (unidirectionally or bidirectionally) the selectedItem? You can listen to > it as it changes easily enough, but why drive it based on the data model? > > And if that is a use case that has to be supported, then we have to > evaluate the impact on the SelectionModel. That is, any attempts to mutate > the selection from the Skin code simply won't work (but that's OK if that's > OK, if you know what I mean). We (meaning all of us on this list) need to > evaluate what the impact is both semantically and in code. Typically we'd > put if(!isBound()) checks into the SelectionModel implementations so they > only change the selectedItem if it isn't bound to avoid the exception in > that case. > I think this one relates back to the fact that in List/Table/Tree the 'selection' is a visual GUI thing, more like 'focus', whereas in ChoiceBox/ComboBox the selection is a data thing, more like 'items'. Ideas for one seem to cause conflict with the other. Is there an argument here for ChoiceBox/ComboBox not using a selection model? Seems almost illogical that it wouldn't have a selectionModel but in reality it is semantically different to the normal selectionModel usage. > > So to recapitulate :-) > - The only (?) reason for HasValue is to facilitate frameworks. What kinds > of frameworks would use it? > - What else might want to be a HasValue besides a Control? Or would > SingleValueControl / MultiValueControl be more appropriate to what we're > trying to do? > - Why would the value of a ListView be the selected item instead of the > items? > - Why would the developer want to bind the selected item of a ListView, > TreeView, or TableView? (Not bind to, but bind) > > Cheers! > Richard > > (Doh, is there a reason this is off the openjfx-dev list? I'm guessing a > mistake, you can repost if you like) > Yep, doh. From omurata at ga2.so-net.ne.jp Thu Dec 8 14:37:04 2011 From: omurata at ga2.so-net.ne.jp (Tadashi Ohmura) Date: Fri, 09 Dec 2011 07:37:04 +0900 Subject: ImageView should have shorthand creation function In-Reply-To: <4EE07F98.5070207@oracle.com> References: <4EE07F98.5070207@oracle.com> Message-ID: <4EE13C10.2080709@ga2.so-net.ne.jp> Dear members of OpenFX I think that we need a shorthand creation function of ImageView. I agree with Option 1 Thanks Tadashi Ohmura (2011/12/08 18:12), Lubomir Nerad wrote: > Hi, > > I am looking at http://javafx-jira.kenai.com/browse/RT-6554. It > requests to add a possibility to create image view and its image from > url in one step. What I think should be discussed is whether to add > this as a new constructor to the ImageView class or as a static > factory method. > > So the options are: > > 1) public ImageView(String url) { ... } > 2) public static ImageView image(String url) { ... } (or another name) > > Unless we expect that we will need more possibilities for image > specification (more shorthand creation methods) in the future, I am > leaning towards option 1. > > What do you think? > > Thanks, > Lubo > > > From richard.bair at oracle.com Thu Dec 8 15:12:30 2011 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 8 Dec 2011 15:12:30 -0800 Subject: Controls with Values [was Possible additions to JavaFX to facilitate forms and validations] In-Reply-To: References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> <4EDE4972.8030205@broadpark.no> <67E8E7BD-24DB-4242-81FD-6C35389A7699@oracle.com> <4EDEA518.5090102@oracle.com> <4EDEB118.6010702@bestsolution.at> <4EDFB020.3060005@broadpark.no> <424E6A89-D6CD-4A71-87CE-98F14B66AA94@oracle.com> Message-ID: Hi Dan, >> The argument in #2 I think is not very strong because HasValue isn't >> required to fix this. That is, we can add a "value" property to ChoiceBox >> without having a HasValue interface, so it doesn't address the question >> "why is HasValue important?". >> > > True. The only thing that is arguably 'more intuitive' is the ChoiceBox, > where the concept of a 'value' is added. This could definitely be done by > looking at the ChoiceBox/ComboBox in isolation. > > So generally, yes, the proposal of a generic HasValue thing is of most > benefit to framework development that wants to access fields in a generic > way. > > There is a style of MVP design pattern however where this generic HasValue > would be of benefit to the developer. I could create an interface for my > view like so: > > PersonView > { > HasValue getFirstNameField(); > HasValue getLastNameField(); > HasValue getGenderField(); > } Can't I just do: PersonView { WritableValue getFirstNameField(); WritableValue getLastNameField(); WritableValue getGenderField(); } I should be able to do this today, and implement it trivially (the PersonViewImpl for getFirstNameField() would return textField.textProperty(), for example). I don't think it really adds an argument for HasValue itself, which still seems to be really only beneficial to tools and frameworks (which is still a good thing). > #3 is very interesting because I would have said that the "value" of a >> ListView is the "items" list, not the selection. This is another reason I >> am trying to refine the arguments, because I think there is something >> interesting in that your proposal was that the "value" was the selected >> item whereas my assumption was that it was the data model. >> > > Good point. The problem comes back to the ChoiceBox (and ComboBox) I think. ComboBox is likely to be different since it has an editable area that is distinct from the drop down -- I guess we can all go and check out the source code now that it is out there though :-) >> What else, other than controls, would implement this proposed interface? >> That is, is it really HasValue, or is it SingleValuedControl, >> MultiValuedControl? This gets back to the need to tighten up the use cases >> and arguments. Is the goal to make UI Controls more uniform for tools, or >> is there a larger goal? For example, what happens if I have a layout >> container that implements this interface. Is there some good reason why I >> might want to do that? >> > > Well, there's a possible example below with 'ToggleGroup'. True, although it is "control-related". So it is safe to say it isn't just for controls, though so far the use cases are control related at least. > Another possibility that is in the back of my mind but I'm not sure if it > will work cleanly is a 'form' itself. In this case you would have a whole > lot of HasValue fields binding to a bean, which in turn is exposed as the > HasValue of the entire form (which is probably extending one of the Panes > or MigPane). Ya, that is good. >> And if that is a use case that has to be supported, then we have to >> evaluate the impact on the SelectionModel. That is, any attempts to mutate >> the selection from the Skin code simply won't work (but that's OK if that's >> OK, if you know what I mean). We (meaning all of us on this list) need to >> evaluate what the impact is both semantically and in code. Typically we'd >> put if(!isBound()) checks into the SelectionModel implementations so they >> only change the selectedItem if it isn't bound to avoid the exception in >> that case. >> > > I think this one relates back to the fact that in List/Table/Tree the > 'selection' is a visual GUI thing, more like 'focus', whereas in > ChoiceBox/ComboBox the selection is a data thing, more like 'items'. Ideas > for one seem to cause conflict with the other. Is there an argument here > for ChoiceBox/ComboBox not using a selection model? Seems almost illogical > that it wouldn't have a selectionModel but in reality it is semantically > different to the normal selectionModel usage. Well, we can't remove the selection model from the API, but I think you are right that there is a difference between what selection means in a ChoiceBox vs. a ListView / TreeView / TableView. There is another problem though, with a ChoiceBox the "value" is supposed to be limited strictly to those items contained in the selection list. It isn't a ComboBox -- there is no possibility to add custom items. Yet when you add a "value" property to ChoiceBox, as the ChoiceBox author, you have to accept that sometimes people will set something that isn't in the list. SO basically to make ChoiceBox usable with binding, we have to give up the invariant that the selected item is always one of the items in the list. Unavoidable it seems. Thanks Richard From zonski at googlemail.com Thu Dec 8 17:50:16 2011 From: zonski at googlemail.com (Daniel Zwolenski) Date: Fri, 9 Dec 2011 12:50:16 +1100 Subject: Controls with Values [was Possible additions to JavaFX to facilitate forms and validations] In-Reply-To: References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> <4EDE4972.8030205@broadpark.no> <67E8E7BD-24DB-4242-81FD-6C35389A7699@oracle.com> <4EDEA518.5090102@oracle.com> <4EDEB118.6010702@bestsolution.at> <4EDFB020.3060005@broadpark.no> <424E6A89-D6CD-4A71-87CE-98F14B66AA94@oracle.com> Message-ID: > > Can't I just do: > > PersonView { > WritableValue getFirstNameField(); > WritableValue getLastNameField(); > WritableValue getGenderField(); > } > > I should be able to do this today, and implement it trivially (the > PersonViewImpl for getFirstNameField() would return > textField.textProperty(), for example). I don't think it really adds an > argument for HasValue itself, which still seems to be really only > beneficial to tools and frameworks (which is still a good thing). Yea, nice, although WritableValue isn't observable and doesn't support binding. Also implementing it 'trivially' for a ChoiceBox is not quite true because of the whole selection model not being writable thing, but this is back to the ChoiceBox API debate, rather than the HasValue debate. > There is another problem though, with a ChoiceBox the "value" is supposed > to be limited strictly to those items contained in the selection list. It > isn't a ComboBox -- there is no possibility to add custom items. Yet when > you add a "value" property to ChoiceBox, as the ChoiceBox author, you have > to accept that sometimes people will set something that isn't in the list. > SO basically to make ChoiceBox usable with binding, we have to give up the > invariant that the selected item is always one of the items in the list. > Unavoidable it seems. > I think the same argument on the value not being in the list applies to selectionModel.select(T), so whatever rules are being used there should carry over. Looks like Jonathan has already put something in place for the ComboBox free-type text issue. He's got a 'StringConverter' in there that maps the entered text to a 'value' (and there's a valueProperty already there for us). I haven't quite worked out what happens if the text doesn't map to a value but I'm guessing a null value in this case. *

Because a ComboBox can be {@link #editableProperty() editable}, and the * default means of allowing user input is via a {@link TextField}, a * {@link #converterProperty() string converter} property is provided to allow * for developers to specify how to translate a users string into an object of * type T, such that the {@link #valueProperty() value} property may contain it. * By default the converter simply returns the String input as the user typed it, * which therefore assumes that the type of the editable ComboBox is String. If * a different type is specified and the ComboBox is to be editable, it is * necessary to specify a custom {@link StringConverter}. From jonathan.giles at oracle.com Thu Dec 8 18:04:18 2011 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 09 Dec 2011 12:04:18 +1000 Subject: Controls with Values [was Possible additions to JavaFX to facilitate forms and validations] In-Reply-To: References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> <4EDE4972.8030205@broadpark.no> <67E8E7BD-24DB-4242-81FD-6C35389A7699@oracle.com> <4EDEA518.5090102@oracle.com> <4EDEB118.6010702@bestsolution.at> <4EDFB020.3060005@broadpark.no> <424E6A89-D6CD-4A71-87CE-98F14B66AA94@oracle.com> Message-ID: <4EE16CA2.6020906@oracle.com> >> There is another problem though, with a ChoiceBox the "value" is supposed >> to be limited strictly to those items contained in the selection list. It >> isn't a ComboBox -- there is no possibility to add custom items. Yet when >> you add a "value" property to ChoiceBox, as the ChoiceBox author, you have >> to accept that sometimes people will set something that isn't in the list. >> SO basically to make ChoiceBox usable with binding, we have to give up the >> invariant that the selected item is always one of the items in the list. >> Unavoidable it seems. >> > I think the same argument on the value not being in the list applies to > selectionModel.select(T), so whatever rules are being used there should > carry over. > > Looks like Jonathan has already put something in place for the ComboBox > free-type text issue. He's got a 'StringConverter' in there that maps the > entered text to a 'value' (and there's a valueProperty already there for > us). I haven't quite worked out what happens if the text doesn't map to a > value but I'm guessing a null value in this case. > > *

Because a ComboBox can be {@link #editableProperty() editable}, and > the > * default means of allowing user input is via a {@link TextField}, a > * {@link #converterProperty() string converter} property is provided to > allow > * for developers to specify how to translate a users string into an object > of > * type T, such that the {@link #valueProperty() value} property may > contain it. > * By default the converter simply returns the String input as the user > typed it, > * which therefore assumes that the type of the editable ComboBox is > String. If > * a different type is specified and the ComboBox is to be editable, it is > * necessary to specify a custom {@link StringConverter}. In general I'm staying out of this rabbit hole, but I thought I'd reply here seeing as I was explicitly dragged into the discussion :-) So, for starters, ComboBox is preview API - it may change drastically once people start providing API feedback (yeah, Rich, I'm looking at you :-). Moving past that, the value property in ComboBox represents the current value of the ComboBox (I'm sure my English teacher would frown on me using the term in the definition, but alas, I digress). To clarify, the current value is either the last selected item from the items list, or the last input text typed by the user (in the case of an editable ComboBox) - whatever happened most recently. What this means is that the StringConverter can take a user-typed String, attempt to convert it to T, and then set it in the value property - without the T object actually being a part of the items list. The value, if it does not exist in the items list, is NOT added to the items list - I leave that as a challenge for the end-developer. However, this can be trivially done if that is the UX expectation: simply add a listener to the valueProperty, and updating the items list when it changes (and if the item is not already in the list). Conversely, the StringConverter is also used in the opposite direction to convert a selected item of type T into a String, such that it may be edited by the user in the ComboBox TextField. Upon the user pressing enter, this String is converted back to type T, and set in the value property. Again, this does not result in the items list being updated. Hope that clarifies things with respect to the ComboBox. For what it is worth, if you have specific feedback on ComboBox API, let's please move it to a separate thread - it's not my intention to deep-dive any further on ComboBox and hijack this thread. -- Jonathan From Bryan.Young at scruffles.net Thu Dec 8 20:27:08 2011 From: Bryan.Young at scruffles.net (Bryan) Date: Thu, 8 Dec 2011 22:27:08 -0600 Subject: Opening Kenai Issues Message-ID: <1D0CF933-9FA8-4F10-AE15-0B687BC1D582@scruffles.net> Are there plans to open up permissions in Kenai for JavaFX issues. I don't know if this is common, or an isolated incident, but several issues I'm interested in have been marked as duplicates of RT-11270, which I don't have permissions to view. Thanks Bryan From tbee at tbee.org Thu Dec 8 21:57:54 2011 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 09 Dec 2011 06:57:54 +0100 Subject: Maven JavaFx native libraries and OSGi In-Reply-To: References: <4EE12C6F.8080106@tbee.org> Message-ID: <4EE1A362.9080303@tbee.org> On 2011-12-08 22:36, Daniel Zwolenski wrote: > > One idea is is to put all DLL's in a Maven artifact (jar) with a classifier of the platform and load them from that DLL. Workaround for this is implemented in JFXtras, but it could easily become part of the actual DLL loader. > > > Would you see this extracting as only for developers or for runtime usage as well? If runtime, one thing to consider is the user may not have write permission to whatever directory the pre-loader is extracting to (e.g. unsigned app, or only admin can write to that directory). Currently the JFXtras workaround extracts to a tempdir, but the better approach would be to load the DLL's as resources directly from the jar. No need to extract then and that also would work fine for runtime. > > Also, for all cases its worth considering possible problems relating to versioning and removing the DLLs. i.e. could be hard to work out which DLLs are being used when something goes wrong (e.g. I've got 2.0.1 dlls somewhere on my system but I'm using a 2.1 jar, etc). The DLL are never formally installed, they just have to be present on the classpath to be loaded as a resource. Multiple jars containing the DLL's are classpath errors and should be resolved. The workaround in JFXtras extracts to a temp dir with the JFX version in the name, so that works as well. Tom From tom.schindl at bestsolution.at Thu Dec 8 23:27:43 2011 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 09 Dec 2011 08:27:43 +0100 Subject: Maven JavaFx native libraries and OSGi In-Reply-To: References: Message-ID: <4EE1B86F.5020608@bestsolution.at> Am 08.12.11 21:50, schrieb peter.pilgrim at gmail.com: > > Hi All > > What are ideas for JavaFX and native libraries? Has any one thought of a better maven schematic G.A.V that works with Jar and the myriad native DLL and Shared Object libraries for the future? > > Also how is JavaFX 2.x compatible with OSGi? > Currently running in OSGi works quite good (at least with Equinox) though there are some tricks I had to use (which you don't really need to know if you are using my libraries). All my code is public [1] and part of the e(fx)clipse effort [2] [1] https://github.com/tomsontom/e-fx-clipse [2] http://www.efxclipse.org/ Tom > Sent from my iPhone 4S -- 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 Thu Dec 8 23:52:09 2011 From: zonski at googlemail.com (Daniel Zwolenski) Date: Fri, 9 Dec 2011 18:52:09 +1100 Subject: Maven JavaFx native libraries and OSGi In-Reply-To: <4EE1A362.9080303@tbee.org> References: <4EE12C6F.8080106@tbee.org> <4EE1A362.9080303@tbee.org> Message-ID: >> >> >> > Currently the JFXtras workaround extracts to a tempdir, but the better approach would be to load the DLL's as resources directly from the jar. No need to extract then and that also would work fine for runtime. Unfortunately I don't believe it is physically possible to "load the DLL's as resources directly from the jar". Unlike classes, images, property files, etc, which are loaded into the JVM (ie the virtual 'OS'), the dll's need to be loaded by the physical OS (win, osx, linux, etc). The physical OS obviously has no idea how to read a dll from within a jar file. And therein lies the heart of the whole problem. I'd love to be wrong on this, so if anyone can contradict this please do! That leaves two options that I can see: extracting it from the jar on first run, or delivering it outside of the jar as another top level file. The extraction will solve the maven problem but is a little clunky for other usages. It's not so bad as to be unusable though and in my mind is our best viable hack. Would be good if could just be a special maven dependency, like jfx-prelauncher that is separate to the jfx runtime. Could your code be made to work that way do you think? Otherwise perhaps the maven version of the runtime is 'special' and has the prelauncher in it, unlike the normal distro? The other alternatives I can think of are: 1) Change the jfx code to tell windows to load the dlls from the same dir the jfxrt.jar is in, instead of the relative 'bin' dir it uses currently when telling windows to load the dlls (it could check the normal spot first to not break current code). By chance Maven does allow you to put more than one file in for an asset (I'm not sure it is meant for this purpose, but better not to look a gift horse in the mouth), so this could be a do-able option. I think we would either have to deploy the jfxrt.jar once for each platform along with it's natives (ie one artifact for each platform, each containing the jar and relevant binaries) or we would need to bundle all the native binaries for all platforms into one single artifact with the jar. I _think_ either of those options will work. This requires a code change from the JFX guys though and as yet I've not had a response on whether they would be willing to do this. (was that nudge unsubtle enough ;) ) 2) have a jfx maven plugin that has a jfx:run command. Similar to tomcat:run or gwt:run. This could do anything - put dlls on the path, even download the sdk and add the jar from there to the run classpath, etc. But it is clunky. IDE's probably won't like it and its a lot more pain for developers - and it just shouldn't be needed (tomcat and gwt are platforms/servers so they can justify needing to be run in a special way, jfx can't). Co-bundling jfx+jre will be an interesting addition to this whole problem. Where will the dlls live then and will that mean just cause I have java installed, I'll have the jfxrt.jar automatically on my classpath and it will then have access to the dlls? If so all of this will be academic, we won't need a maven dependency, anymore than we need one for java.util or java.swing, etc. Can anyone elaborate on this and also the expected timeframe for co-bundling? > >> From pgronkiewicz at gmail.com Fri Dec 9 00:26:13 2011 From: pgronkiewicz at gmail.com (=?UTF-8?Q?Pawe=C5=82_Gronkiewicz?=) Date: Fri, 9 Dec 2011 09:26:13 +0100 Subject: So, will it work? Message-ID: Hi, I am member of a university team working on our diplomma now. Our subject is a desktop app that would help writers in writing books - novels mostly. One of our major goals is to make it work both on Windows and Linux. We are writing it in Java and we want something else for UI than ugly and unfriendly Swing. JavaFX 2 looks very promising (and would be great thing to learn and put in our resumes). But the question is - will it work? Is it reliable enough? Can it work on Linux despite no official release yet? End of 2012 is way too late for us, we need something working within a month. But what we need are just some UI controls - to make main interface, that is all menus, navigation, etc [similar to what Word has]. Is it possible with current OpenJFX release? If yes, is there any maven archetype to start working on the project? Or some sample app (just showing "it works!" when opened) to expand? From Martin.Soch at oracle.com Fri Dec 9 01:05:42 2011 From: Martin.Soch at oracle.com (Martin Soch) Date: Fri, 09 Dec 2011 10:05:42 +0100 Subject: request for API change approval: ObservableSet In-Reply-To: References: <4EDF7F83.2070909@oracle.com> <4EE07EAA.8060708@oracle.com> <4EE08E19.3090209@oracle.com> Message-ID: <4EE1CF66.1010308@oracle.com> OK, Jira is updated with the patch now. JIRA: http://javafx-jira.kenai.com/browse/RT-14664 Thanks Martin On 12/08/2011 08:52 PM, Richard Bair wrote: > Cool. Can you create a new patch with the latest proposal and attach it to the JIRA issue? > > Thanks! > Richard > > On Dec 8, 2011, at 2:14 AM, Martin Soch wrote: > >> Hi Richard, >> >> after discussion with Martin Sladecek he suggested to remove ObservableSetWrapper from public API so it will be consistent for now. >> >> Thanks >> Martin >> >> On 12/08/2011 10:08 AM, Martin Soch wrote: >>> Hi Richard, >>> >>> thanks for your comments. >>> >>> - public wrappers: Martin Sladecek is recently (in a separate request) >>> moving wrapper classes to the javafx.collection package as well; I don't >>> know the motivation behind but Michael Heinrichs (on CC) might know more >>> - var-arg factory method: will add it unless anyone has any objections >>> >>> Thanks >>> Martin >>> >>> On 12/07/2011 08:09 PM, Richard Bair wrote: >>>> Hi Martin, >>>> >>>> Generally I would suggest that we move this conversation to the >>>> openjfx-dev mailing list. I'm wanting to start moving as many of these >>>> sorts of design approval requests there as we can. >>>> >>>> However, my first thoughts: >>>> - Yay! >>>> - Why is ObservableSetWrapper public? We don't have any other Wrappers >>>> for the other collections public, do we? Are we sure we want to do >>>> this now? >>>> - I would suggest adding a var-args factory method to FXCollections >>>> for creating a set, as well as a Collections version for convenience >>>> >>>> Otherwise looks consistent with our other Observable collections as >>>> far as I can see. >>>> >>>> Thanks >>>> Richard >>>> >>>> On Dec 7, 2011, at 7:00 AM, Martin Soch wrote: >>>> >>>>> Hi team, >>>>> >>>>> I would like to ask you for approval for a new API to be pushed to >>>>> 2.1 repository. This new API is adding ObservableSet interface into >>>>> javafx.collection package with basic wrapper implementation. This >>>>> change is not modifying any current API; just adding new functionality. >>>>> >>>>> JIRA: http://javafx-jira.kenai.com/browse/RT-14664 >>>>> WebRev: http://javame-linux.cz.oracle.com/r/1334/ >>>>> >>>>> Thanks >>>>> Martin >>>> >>> >> > From neugens.limasoftware at gmail.com Fri Dec 9 01:31:18 2011 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 9 Dec 2011 10:31:18 +0100 Subject: So, will it work? In-Reply-To: References: Message-ID: <7B66F3A7-D38C-4FBF-BDD3-3C6FF060140E@gmail.com> Il giorno 09/dic/2011, alle ore 09:26, Pawe? Gronkiewicz ha scritto: > Hi, > > I am member of a university team working on our diplomma now. Our > subject is a desktop app that would help writers in writing books - > novels mostly. One of our major goals is to make it work both on > Windows and Linux. We are writing it in Java and we want something > else for UI than ugly and unfriendly Swing. JavaFX 2 looks very > promising (and would be great thing to learn and put in our resumes). > But the question is - will it work? Is it reliable enough? Can it work > on Linux despite no official release yet? End of 2012 is way too late > for us, we need something working within a month. But what we need are > just some UI controls - to make main interface, that is all menus, > navigation, etc [similar to what Word has]. Is it possible with > current OpenJFX release? If yes, is there any maven archetype to start > working on the project? Or some sample app (just showing "it works!" > when opened) to expand? JavaFX is reliable, fast and very attractive, I would suggest this to you, but sadly, Oracle official position is that the Linux port end of 2012... I agree with you is too late for any practical purpose, anyway, this is the final release date, I expect a beta way earlier than that, (after all, there's no release for Mac either, it's still a beta), and the good folks on this list are working hard to make it happen sooner rather than later. It's a bit embarrassing that a Linux version is not even in preview state, I really don't know why it has been decided to ignore Linux since it's an important platform, especially to attract developers, but I hope this is going to be fixed soon... I leave to the Oracle people a better reply on this subject. Cheers, Mario --- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF http://www.ladybug-studio.com IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From michael.heinrichs at oracle.com Fri Dec 9 01:33:30 2011 From: michael.heinrichs at oracle.com (Michael Heinrichs) Date: Fri, 9 Dec 2011 10:33:30 +0100 Subject: Bidirectional binding with conversion Message-ID: Hi everybody, I am working on a solution for the Binding API that allows bidirectional bindings between an arbitrary property and a StringProperty. (The long term plan is to allow bidirectional bindings between two arbitrary properties in JavaFX 3.0). The request is tracked here: http://javafx-jira.kenai.com/browse/RT-18203 The class javafx.beans.binding.Bindings will get two new methods: public static void bindBidirectional(Property stringProperty, Property otherProperty, Format format) public static void unbindBidirectional(Object property1, Object property2) The class javafx.beans.property.StringProperty will also get two new methods: public void bindBidirectional(Property other, Format format) public void unbindBidirectional(Object other) If parsing the StringProperty fails, the other property will be set to the default value. If formatting the arbitraty property fails, the StringProperty will be set to the empty String. Any thoughts? Thanks, Michael From jonathan.giles at oracle.com Fri Dec 9 01:42:00 2011 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 09 Dec 2011 19:42:00 +1000 Subject: Bidirectional binding with conversion In-Reply-To: References: Message-ID: <4EE1D7E8.8050702@oracle.com> I'm sure there is a reason, but why do the unbind methods take Object rather than Property or similar? -- Jonathan On Friday, 9 December 2011 7:33:30 p.m., Michael Heinrichs wrote: > Hi everybody, > > I am working on a solution for the Binding API that allows bidirectional bindings between an arbitrary property and a StringProperty. (The long term plan is to allow bidirectional bindings between two arbitrary properties in JavaFX 3.0). The request is tracked here: http://javafx-jira.kenai.com/browse/RT-18203 > > The class javafx.beans.binding.Bindings will get two new methods: > public static void bindBidirectional(Property stringProperty, Property otherProperty, Format format) > public static void unbindBidirectional(Object property1, Object property2) > > > The class javafx.beans.property.StringProperty will also get two new methods: > public void bindBidirectional(Property other, Format format) > public void unbindBidirectional(Object other) > > If parsing the StringProperty fails, the other property will be set to the default value. If formatting the arbitraty property fails, the StringProperty will be set to the empty String. > > Any thoughts? > > Thanks, > Michael From michael.heinrichs at oracle.com Fri Dec 9 02:18:21 2011 From: michael.heinrichs at oracle.com (Michael Heinrichs) Date: Fri, 9 Dec 2011 11:18:21 +0100 Subject: ListChangeListener In-Reply-To: <4EE10AEE.1010009@gmail.com> References: <4EE10AEE.1010009@gmail.com> Message-ID: <3E4F1CBA-7A1F-4AFA-8B2D-2BC56DE762CD@oracle.com> Hi Daniel, thank you very much for your input. Feedback like yours helps us to understand the difficulties user encounter and improve the API. Unfortunately we will not be able to implement your proposal for some time. ObservableList is an interface and we will not be able to make changes until JDK 8. Even with virtual extension methods in place, we will probably not be able to add the addListener method to ObservableList, because there is no default implementation as far as I can tell. The other issue is, that you will have a hard time to convince people in the JavaFX team. One of the high level goals for the JavaFX API is to use SAMs as much as possible to benefit from lambda expressions later. You may have noticed that all listeners, event handlers, callbacks etc. in the JavaFX library are SAMs. Convincing people to break this pattern with the ListChangeHandler will be tough. :-) Now what we can do now and what we should do is improve the documentation. From my experience most ListChangeListeners are actually quite simple, because usually you do not have to test the operation type. For example if you loop over all removed elements, this will also work for an add-operation, because the list of removed elements will be empty. But AFAIK this is not documented so far, I can imagine we need a tutorial or somebody should blog about some common cases and how you can implement them with ListChangeListeners. Maybe you bumped into some use cases that we are not aware of. Could you please give us some examples? That would be very helpful to understand the difficulties you have encountered. Thanks, Michael On 08.12.2011, at 20:07, Gaja Sutra wrote: > When trying to write the collections needed by my application and lacking in JavaFX runtime, I have found difficult to use ListChangeListener, because the code to write (the while loop on each change with tests of operation type) is difficult to read. I suggest the following addition to API: > > 1) In ObservableList add the following new method and create the corresponding interface: > > |public void addListener(ListChangeHandler obs);| > > |public interface ListChangeHandler { > public void begin(); > public void addedItem(int index, E addedItem); > public void addedItems(int from, int to, List readOnlyAddedItems); > // ReadOnlyIntList wrap the int[] to be read-only > public void swapped(int from, int to, ReadOnlyIntList permutation); > public void removedItems(int index, int size, List readOnlyDeletedItems); > public void removedItem(int index, E removedItem); > public void end(); > } > | > > 2) Provide a class of utilities methods for ListChangeHandler giving implementation of methods by delegating to it: > |public class ListChangeUtils { > public static void addedItems(ListChangeHandler handler, int from, int to, List readOnlyAddedItems) { > for (int i = from; i handler.addedItem(i, readOnlyAddedItems.get(i-from)); > } > } > } > | > > 3) In Java8, with defenders methods , add default implementations for all methods excepted the following four methods: > > |public interface ListChangeHandler { > public void begin(); > public void addedItem(int index, E addedItem); > public void removedItem(int index, E removedItem); > public void end(); > }| > > by having code like this, for other methods, in the preceding interface: > > | public void addedItems(int from, int to, List readOnlyAddedItems) default ListChangeUtils.||addedItems||; > | > > 4) Conclusion: I think this will give correct performance by allowing, like with ListChangeListener, to have a specialized handler receiving directly the addition of multiple items (if it support this feature). But if the handler can not have optimized path for this case it will need in current Java to implement addedItems by calling |ListChangeUtils.addedItems(this, from, to, readOnlyAddedItems)| or in Java8 by doing nothing (automatically supported by defender method). This is the symmetric model for receiving notification of changes, like com.sun.javafx.collections.IterableChangeBuilder is for creating changes notification. > > For code readability, I think having one method for each type of operation on list will be much more clean and readable, because the while loop will disappear and each type of operation will correspond to one method of handler separated from others. > > Thanks for your opinions, > Daniel. > From michael.heinrichs at oracle.com Fri Dec 9 02:24:41 2011 From: michael.heinrichs at oracle.com (Michael Heinrichs) Date: Fri, 9 Dec 2011 11:24:41 +0100 Subject: Bidirectional binding with conversion In-Reply-To: <4EE1D7E8.8050702@oracle.com> References: <4EE1D7E8.8050702@oracle.com> Message-ID: Hi Jonathan, it is very likely that we will add other types of bindings later. With a generic unbind method, we only have to add new bind methods in the future, significantly reducing the number of methods. Looking back it was a mistake to make the unbind methods symmetrical to the bind methods, they should have been generic right from the start. I hope I will have a chance to fix it at some point in the future. - Michael On 09.12.2011, at 10:42, Jonathan Giles wrote: > I'm sure there is a reason, but why do the unbind methods take Object rather than Property or similar? > > -- Jonathan > > On Friday, 9 December 2011 7:33:30 p.m., Michael Heinrichs wrote: >> Hi everybody, >> >> I am working on a solution for the Binding API that allows bidirectional bindings between an arbitrary property and a StringProperty. (The long term plan is to allow bidirectional bindings between two arbitrary properties in JavaFX 3.0). The request is tracked here: http://javafx-jira.kenai.com/browse/RT-18203 >> >> The class javafx.beans.binding.Bindings will get two new methods: >> public static void bindBidirectional(Property stringProperty, Property otherProperty, Format format) >> public static void unbindBidirectional(Object property1, Object property2) >> >> >> The class javafx.beans.property.StringProperty will also get two new methods: >> public void bindBidirectional(Property other, Format format) >> public void unbindBidirectional(Object other) >> >> If parsing the StringProperty fails, the other property will be set to the default value. If formatting the arbitraty property fails, the StringProperty will be set to the empty String. >> >> Any thoughts? >> >> Thanks, >> Michael From zonski at googlemail.com Fri Dec 9 02:41:07 2011 From: zonski at googlemail.com (Daniel Zwolenski) Date: Fri, 9 Dec 2011 21:41:07 +1100 Subject: ListChangeListener In-Reply-To: References: <4EE10AEE.1010009@gmail.com> Message-ID: Resending this as I forgot to reply all (again). On 09/12/2011, at 3:38 PM, Daniel Zwolenski wrote: > I'd quite like to see a simplification of list change handling, as I agree this can be a little cumbersome to implement. Given the API is already in place, perhaps your suggestion could be achieved just by having an AbstractListChangeListener (or following the Swing naming pattern, a ListChangeListenerAdapter), that provided the default looping implementation and called out to abstract methods on itself? > > Then you could probably just do something like the following (this is just indicative, there'd be more to it than this, I'm sure): > > myObservableList.addListener(new ListChangeListenerAdapter() { > void itemAdded(int index, E item) { > // handle add > } > > void itemRemoved(int index, E item) { > // handle remove > } > > void itemUpdated(int index, E item) { > // handle update > } > } > } > > Would that work? > > > On Fri, Dec 9, 2011 at 6:07 AM, Gaja Sutra wrote: > When trying to write the collections needed by my application and lacking in JavaFX runtime, I have found difficult to use ListChangeListener, because the code to write (the while loop on each change with tests of operation type) is difficult to read. I suggest the following addition to API: > > 1) In ObservableList add the following new method and create the corresponding interface: > > |public void addListener(ListChangeHandler obs);| > > |public interface ListChangeHandler { > public void begin(); > public void addedItem(int index, E addedItem); > public void addedItems(int from, int to, List readOnlyAddedItems); > // ReadOnlyIntList wrap the int[] to be read-only > public void swapped(int from, int to, ReadOnlyIntList permutation); > public void removedItems(int index, int size, List readOnlyDeletedItems); > public void removedItem(int index, E removedItem); > public void end(); > } > | > > 2) Provide a class of utilities methods for ListChangeHandler giving implementation of methods by delegating to it: > |public class ListChangeUtils { > public static void addedItems(ListChangeHandler handler, int from, int to, List readOnlyAddedItems) { > for (int i = from; i handler.addedItem(i, readOnlyAddedItems.get(i-from)); > } > } > } > | > > 3) In Java8, with defenders methods , add default implementations for all methods excepted the following four methods: > > |public interface ListChangeHandler { > public void begin(); > public void addedItem(int index, E addedItem); > public void removedItem(int index, E removedItem); > public void end(); > }| > > by having code like this, for other methods, in the preceding interface: > > | public void addedItems(int from, int to, List readOnlyAddedItems) default ListChangeUtils.||addedItems||; > | > > 4) Conclusion: I think this will give correct performance by allowing, like with ListChangeListener, to have a specialized handler receiving directly the addition of multiple items (if it support this feature). But if the handler can not have optimized path for this case it will need in current Java to implement addedItems by calling |ListChangeUtils.addedItems(this, from, to, readOnlyAddedItems)| or in Java8 by doing nothing (automatically supported by defender method). This is the symmetric model for receiving notification of changes, like com.sun.javafx.collections.IterableChangeBuilder is for creating changes notification. > > For code readability, I think having one method for each type of operation on list will be much more clean and readable, because the while loop will disappear and each type of operation will correspond to one method of handler separated from others. > > Thanks for your opinions, > Daniel. > > From zonski at googlemail.com Fri Dec 9 03:25:28 2011 From: zonski at googlemail.com (Daniel Zwolenski) Date: Fri, 9 Dec 2011 22:25:28 +1100 Subject: Bidirectional binding with conversion In-Reply-To: References: <4EE1D7E8.8050702@oracle.com> Message-ID: <194CF9E1-B82C-4AAA-983D-3978D8B117E1@gmail.com> Nice idea, I can see it being useful. Does it need to be limited to bidirectional bindings? Any reason unidirectional bindings cant use a converter too? I wonder if we need a way to detect the failed parsing/formatting? For example if we were converting a TextField.textProperty to a Number (or Date) and it couldn't be parsed, I reckon I'd want to highlight the field as an error. Maybe this could be done with a custom formatter, is that the best way though? On 09/12/2011, at 9:24 PM, Michael Heinrichs wrote: > Hi Jonathan, > > it is very likely that we will add other types of bindings later. With a generic unbind method, we only have to add new bind methods in the future, significantly reducing the number of methods. > > Looking back it was a mistake to make the unbind methods symmetrical to the bind methods, they should have been generic right from the start. I hope I will have a chance to fix it at some point in the future. > > - Michael > > > > On 09.12.2011, at 10:42, Jonathan Giles wrote: > >> I'm sure there is a reason, but why do the unbind methods take Object rather than Property or similar? >> >> -- Jonathan >> >> On Friday, 9 December 2011 7:33:30 p.m., Michael Heinrichs wrote: >>> Hi everybody, >>> >>> I am working on a solution for the Binding API that allows bidirectional bindings between an arbitrary property and a StringProperty. (The long term plan is to allow bidirectional bindings between two arbitrary properties in JavaFX 3.0). The request is tracked here: http://javafx-jira.kenai.com/browse/RT-18203 >>> >>> The class javafx.beans.binding.Bindings will get two new methods: >>> public static void bindBidirectional(Property stringProperty, Property otherProperty, Format format) >>> public static void unbindBidirectional(Object property1, Object property2) >>> >>> >>> The class javafx.beans.property.StringProperty will also get two new methods: >>> public void bindBidirectional(Property other, Format format) >>> public void unbindBidirectional(Object other) >>> >>> If parsing the StringProperty fails, the other property will be set to the default value. If formatting the arbitraty property fails, the StringProperty will be set to the empty String. >>> >>> Any thoughts? >>> >>> Thanks, >>> Michael > From peter.pilgrim at gmail.com Fri Dec 9 03:30:47 2011 From: peter.pilgrim at gmail.com (Peter Pilgrim) Date: Fri, 9 Dec 2011 11:30:47 +0000 Subject: Compilation Build Failures Message-ID: Hi I am getting build compilation failures C:\Users\PeterP\Documents\Projects\openjfx-master\rt\javafx-ui-controls>ant Buildfile: C:\Users\PeterP\Documents\Projects\openjfx-master\rt\javafx-ui-controls\build.xml [taskdef] Could not load definitions from resource net/sf/antcontrib/antcontrib.properties. It could not be found. -pre-init: init: jar: [javac] Compiling 167 source files to C:\Users\PeterP\Documents\Projects\openjfx-master\rt\j avafx-ui-controls\build\classes [javac] C:\Users\PeterP\Documents\Projects\openjfx-master\rt\javafx-ui-controls\src\com\java fx\preview\control\ComboBox.java:28: package com.sun.javafx.css does not exist [javac] import com.sun.javafx.css.StyleManager; [javac] ^ [javac] C:\Users\PeterP\Documents\Projects\openjfx-master\rt\javafx-ui-controls\src\com\java fx\preview\control\ComboBox.java:34: package javafx.beans does not exist [javac] import javafx.beans.InvalidationListener; [javac] ^ [javac] C:\Users\PeterP\Documents\Projects\openjfx-master\rt\javafx-ui-controls\src\com\java fx\preview\control\ComboBox.java:35: package javafx.beans does not exist [javac] import javafx.beans.Observable; [javac] ^ How do specify the JavaFX runtime location? In the project.properties file I edited the JFXRT_HOME property setting to: OLD_JFXRT_HOME=\ ${runtime.dist.root.dir}/../artifacts/sdk/rt/lib #JFXRT_HOME=C:\\Program Files\\Oracle\\JavaFX 2.0 SDK\\rt\\lib JFXRT_HOME=C:\\Users\PeterP\\Documents\\Projects\\openjfx-master First, I figured out that the ant build does not like spaces and then I copied the jfxrt.jar into the workspace root directory... -- Peter Pilgrim, From tom.schindl at bestsolution.at Fri Dec 9 04:43:22 2011 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 09 Dec 2011 13:43:22 +0100 Subject: Bidirectional binding with conversion In-Reply-To: <194CF9E1-B82C-4AAA-983D-3978D8B117E1@gmail.com> References: <4EE1D7E8.8050702@oracle.com> <194CF9E1-B82C-4AAA-983D-3978D8B117E1@gmail.com> Message-ID: <4EE2026A.6070205@bestsolution.at> Am 09.12.11 12:25, schrieb Daniel Zwolenski: > Nice idea, I can see it being useful. > > Does it need to be limited to bidirectional bindings? Any reason unidirectional bindings cant use a converter too? > Correct I don't see a reason for that. > I wonder if we need a way to detect the failed parsing/formatting? For example if we were converting a TextField.textProperty to a Number (or Date) and it couldn't be parsed, I reckon I'd want to highlight the field as an error. Maybe this could be done with a custom formatter, is that the best way though? Yes we should. Why don't we allow the method to return a type: public static ValueBinding bindBidirectional(Property stringProperty, Property otherProperty, Format format) public ValueBinding bindBidirectional(Property other, Format format) class Binding { ObjectProperty status; public dispose() { } } We can then: a) Observe the status of the binding b) remove the need of the unbind method because we can dispose the binding 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 michael.heinrichs at oracle.com Fri Dec 9 05:36:19 2011 From: michael.heinrichs at oracle.com (Michael Heinrichs) Date: Fri, 9 Dec 2011 14:36:19 +0100 Subject: Bidirectional binding with conversion In-Reply-To: <4EE2026A.6070205@bestsolution.at> References: <4EE1D7E8.8050702@oracle.com> <194CF9E1-B82C-4AAA-983D-3978D8B117E1@gmail.com> <4EE2026A.6070205@bestsolution.at> Message-ID: <9D962C0A-5D37-4F2F-91D0-000134E3B593@oracle.com> Hi, comments see inlined. - Michael On 09.12.2011, at 13:43, Tom Schindl wrote: > Am 09.12.11 12:25, schrieb Daniel Zwolenski: >> Nice idea, I can see it being useful. >> >> Does it need to be limited to bidirectional bindings? Any reason unidirectional bindings cant use a converter too? >> > > Correct I don't see a reason for that. Unidirectional bindings are already capable of conversions. There are a number of convenient methods to format anything into a String and one can always create a custom binding to do more complex conversions. Bidirectional bindings do not allow custom bindings (yet). > >> I wonder if we need a way to detect the failed parsing/formatting? For example if we were converting a TextField.textProperty to a Number (or Date) and it couldn't be parsed, I reckon I'd want to highlight the field as an error. Maybe this could be done with a custom formatter, is that the best way though? > > Yes we should. Why don't we allow the method to return a type: > > public static ValueBinding bindBidirectional(Property > stringProperty, Property otherProperty, Format format) > > public ValueBinding bindBidirectional(Property other, Format format) > > class Binding { > ObjectProperty status; > > public dispose() { > > } > > } > > We can then: > a) Observe the status of the binding > b) remove the need of the unbind method because we can dispose the > binding Observing the status of a binding is an interesting idea, but it does not fit the intend of bindings in the Property and Binding API. The only purpose of bidirectional bindings in this library is to keep two properties in-sync. And they have to be as light-weight as possible to allow huge amounts of them. There are many enhancements possible: input validation, lifecycle management, support for transactions etc. etc., but if they do not serve the main intent, they just add complexity, increase footprint and thus have to be solved elsewhere. Relying on a dispose() method would force developers to keep track of references to bindings, if they want to unbind them eventually. Calling a static method with the two properties seems a lot more convenient to me. > > 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 gajasutra at gmail.com Fri Dec 9 04:07:19 2011 From: gajasutra at gmail.com (Gaja Sutra) Date: Fri, 09 Dec 2011 13:07:19 +0100 Subject: So, will it work? In-Reply-To: References: Message-ID: <4EE1F9F7.3060500@gmail.com> > Our subject is a desktop app that would help writers in writing books > - novels mostly. > But what we need are just some UI controls - to make main interface, > that is all menus, navigation, etc [similar to what Word has]. Is it > possible with current OpenJFX release? I think you need to verify if features supported for multi-styled text are sufficient for your needs (currently mostly HTMLEditor on Webkit). http://docs.oracle.com/javafx/2.0/api/javafx/scene/web/HTMLEditor.html Daniel. From gajasutra at gmail.com Fri Dec 9 06:22:02 2011 From: gajasutra at gmail.com (Gaja Sutra) Date: Fri, 09 Dec 2011 15:22:02 +0100 Subject: ListChangeListener In-Reply-To: References: <4EE10AEE.1010009@gmail.com> Message-ID: <4EE2198A.10109@gmail.com> Yes, when I have a complex ListChangeListener, I am already using an inner class with the corresponding methods for each operation. If I want to support ListChangeListener with an interface as argument, it will be by adapting it to current ListChangeListener with this idiom for splitting code in multiple simple methods and having readable code. NB: Given its lack of internal state and its role as a contract, I have suggested the interface and not the abstract class, but this is not an important aspect for me. Thank you, Daniel. > I'd quite like to see a simplification of list change handling, as I agree this can be a little cumbersome to implement. Given the API is already in place, perhaps your suggestion could be achieved just by having an AbstractListChangeListener (or following the Swing naming pattern, a ListChangeListenerAdapter), that provided the default looping implementation and called out to abstract methods on itself? > > Would that work? From gajasutra at gmail.com Fri Dec 9 06:28:55 2011 From: gajasutra at gmail.com (Gaja Sutra) Date: Fri, 09 Dec 2011 15:28:55 +0100 Subject: ListChangeListener In-Reply-To: <3E4F1CBA-7A1F-4AFA-8B2D-2BC56DE762CD@oracle.com> References: <4EE10AEE.1010009@gmail.com> <3E4F1CBA-7A1F-4AFA-8B2D-2BC56DE762CD@oracle.com> Message-ID: <4EE21B27.1090809@gmail.com> > Unfortunately we will not be able to implement your proposal for some time. ObservableList is an interface and we will not be able to make changes until JDK 8. Even with virtual extension methods in place, we will probably not be able to add the addListener method to ObservableList, because there is no default implementation as far as I can tell. Yes, this is clearly not possible now with good compatibility, but I have not found problem before (sorry for not trying to write an ObservableList before). In Java8, the default implementation can be: wrap interface in an adaptor for current listener, like Daniel (Zwolenski) say. > The other issue is, that you will have a hard time to convince people in the JavaFX team. One of the high level goals for the JavaFX API is to use SAMs as much as possible to benefit from lambda expressions later. You may have noticed that all listeners, event handlers, callbacks etc. in the JavaFX library are SAMs. Convincing people to break this pattern with the ListChangeHandler will be tough. :-) Yes, but others listeners are on simple properties, not on collections (MapChangeListener seem to have the same problem than ListChangeListener for me, even if I doesn't have tried to write one). This is not a simple event handler, because you iterate on each operation of the change (because it listen a collection). > Now what we can do now and what we should do is improve the documentation. From my experience most ListChangeListeners are actually quite simple, because usually you do not have to test the operation type. For example if you loop over all removed elements, this will also work for an add-operation, because the list of removed elements will be empty. But AFAIK this is not documented so far, I can imagine we need a tutorial or somebody should blog about some common cases and how you can implement them with ListChangeListeners. After thinking, I think there is a bigger problem with current design: impossibility of evolving Change class with new change type from improving performance when many listeners uses this change type and can have specialized code for this change type. Contrary to current Change object, the two stream API will be easier to extends with new change type (IterableChangeBuilder need only adding a method, ListChangeHandler will only need another method (if it is an abstract class it will need to have a default implementation splitting it in existing operations, or if it is an interface to have a Java8 extension method with default pointing to same code than abstract class default implementation). By example adding a new change type, like swap between two items without change on items between them, will be impossible on Change (need code change in all listeners to add a new test wasSwap(): then swap will always be broken using current simpler operations (like add+remove or big permute concerning items between the two) by IterableChangeBuilder constructing Change and knowledge of swap will be lost in Change instance. It will be impossible to have a specialized handler for swap (like one doing less work if size of list is unchanged (*), or if some items in the middle are unchanged (#)). After some thinking, I think only the streams API can be evolved by adding new change operations in future (but only with abstract class currently or interface using Java8 virtual extension methods). (*) Like a ReadOnlyIntegerProperty with the size of ObservableList (possible useful addition), if swap is expanded in add+remove. (#) Like a FilteredList observing items in the middle of swap but not the two swapped items, if swap is expanded in a big permute. > Maybe you bumped into some use cases that we are not aware of. Could you please give us some examples? That would be very helpful to understand the difficulties you have encountered. Yes. my biggest problem is with ConcatenatedList (an ObservableList of ObservableList offering a living read-only view of concatenated lists). I have copied code (without listeners, for readability and shortness). As an use-case, I am interested in using it to populate a TableView with items coming from multiples sources (changing sources, changing items from each source).| || public class ConcatenatedList extends ObservableListWrapper> { private final class ReadOnlyView extends ReadOnlyUnbackedObservableList { @Override public final E get(final int index) { final int search = ConcatenatedList.this.readPartIndex(index); final ObservableList part = ConcatenatedList.this.get(search); return part.get(index - ConcatenatedList.this.ends[search]); } @Override public final int size() { return ConcatenatedList.this.ends[ConcatenatedList.this.ends.length - 1]; } } private final ReadOnlyView concatenated = new ReadOnlyView(); /** * Boundaries between parts with (this.size()+1) items. first item is 0, last item is size of concatenated list. */ private final int[] ends; /* this listener transform change by changing list (from part list to global view) /* and shifting indexes and resend it on concatenated view listeners. */ private final ListChangeListener listener; @SafeVarargs ConcatenatedList(final Class type, final ObservableList... parts) { super(Arrays.asList(parts)); final int size = this.size(); this.ends = new int[size + 1]; this.ends[0] = 0; for (int i = 0; i < size; i++) { final ObservableList part = this.get(i); this.ends[i + 1] = this.ends[i] + part.size(); part.addListener(this.listener); } /* the following listener add and remove listeners on parts added or removed. * It need to creating change by adding, removing and permuting blocks of items corresponding to each part list. */ this.addListener(/* */); } @Override public final ObservableList getConcatenated() { return this.concatenated; } /** * * @param index * @return part corresponding to this index */ private final int readPartIndex(final int index) { int search = Arrays.binarySearch(this.ends, index); if (search < 0) { search = -search - 1; } return search; } }| Thank you, Daniel. From pgronkiewicz at gmail.com Fri Dec 9 06:48:15 2011 From: pgronkiewicz at gmail.com (=?UTF-8?Q?Pawe=C5=82_Gronkiewicz?=) Date: Fri, 9 Dec 2011 15:48:15 +0100 Subject: So, will it work? Message-ID: Daniel: We are not going to use any text formatting really. Just plain text, with an option to export to LaTeX and plain text. And I don't think JavaFX has to do anything with text formatting? Our tool will bring managing of chapters, scenes, characters, locations etc. BTW, that mailing groups is not easy to use. How to respond to messages? I get mail as digest, I see no option to reply. I cannot see an option like that by browsing archives either. Google Groups makes all that easy... From richard.bair at oracle.com Fri Dec 9 07:44:36 2011 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 9 Dec 2011 07:44:36 -0800 Subject: Opening Kenai Issues In-Reply-To: <1D0CF933-9FA8-4F10-AE15-0B687BC1D582@scruffles.net> References: <1D0CF933-9FA8-4F10-AE15-0B687BC1D582@scruffles.net> Message-ID: Most issues that were internal can now be made public, this is one of those. I've marked it public, so you should be able to see it and related issues now. Thanks Richard On Dec 8, 2011, at 8:27 PM, Bryan wrote: > Are there plans to open up permissions in Kenai for JavaFX issues. I don't know if this is common, or an isolated incident, but several issues I'm interested in have been marked as duplicates of RT-11270, which I don't have permissions to view. > > Thanks > > Bryan From richard.bair at oracle.com Fri Dec 9 07:55:18 2011 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 9 Dec 2011 07:55:18 -0800 Subject: Bidirectional binding with conversion In-Reply-To: References: Message-ID: Hi Michael, What about adding: public void bindBidirectional(Property other, StringConverter) as well? The StringConverter is in javafx.util and seems like another well suited means for conversion to/from String. One other question not directly related -- why do our bindBidirectional methods take a Property instead of a WritableValue? Thanks Richard On Dec 9, 2011, at 1:33 AM, Michael Heinrichs wrote: > Hi everybody, > > I am working on a solution for the Binding API that allows bidirectional bindings between an arbitrary property and a StringProperty. (The long term plan is to allow bidirectional bindings between two arbitrary properties in JavaFX 3.0). The request is tracked here: http://javafx-jira.kenai.com/browse/RT-18203 > > The class javafx.beans.binding.Bindings will get two new methods: > public static void bindBidirectional(Property stringProperty, Property otherProperty, Format format) > public static void unbindBidirectional(Object property1, Object property2) > > > The class javafx.beans.property.StringProperty will also get two new methods: > public void bindBidirectional(Property other, Format format) > public void unbindBidirectional(Object other) > > If parsing the StringProperty fails, the other property will be set to the default value. If formatting the arbitraty property fails, the StringProperty will be set to the empty String. > > Any thoughts? > > Thanks, > Michael From richard.bair at oracle.com Fri Dec 9 07:58:44 2011 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 9 Dec 2011 07:58:44 -0800 Subject: So, will it work? In-Reply-To: References: Message-ID: <3C7261DE-2918-4BB2-8F89-B62426CCC6ED@oracle.com> I'm afraid I can't commit to getting any Linux bits (either binary or source) out in less than a month, so if you have to run on Linux I'm afraid we won't be ready to help you yet. Also, this sort of question really belongs on the Forums (https://forums.oracle.com/forums/forum.jspa?forumID=1385), as this list should be reserved for development discussions. Thanks! Richard On Dec 9, 2011, at 12:26 AM, Pawe? Gronkiewicz wrote: > Hi, > > I am member of a university team working on our diplomma now. Our > subject is a desktop app that would help writers in writing books - > novels mostly. One of our major goals is to make it work both on > Windows and Linux. We are writing it in Java and we want something > else for UI than ugly and unfriendly Swing. JavaFX 2 looks very > promising (and would be great thing to learn and put in our resumes). > But the question is - will it work? Is it reliable enough? Can it work > on Linux despite no official release yet? End of 2012 is way too late > for us, we need something working within a month. But what we need are > just some UI controls - to make main interface, that is all menus, > navigation, etc [similar to what Word has]. Is it possible with > current OpenJFX release? If yes, is there any maven archetype to start > working on the project? Or some sample app (just showing "it works!" > when opened) to expand? From michael.heinrichs at oracle.com Fri Dec 9 08:14:06 2011 From: michael.heinrichs at oracle.com (Michael Heinrichs) Date: Fri, 9 Dec 2011 17:14:06 +0100 Subject: Bidirectional binding with conversion In-Reply-To: References: Message-ID: <37D18C97-4EC1-43C2-A230-316FE9FC4B80@oracle.com> On 09.12.2011, at 16:55, Richard Bair wrote: > Hi Michael, > > What about adding: > > public void bindBidirectional(Property other, StringConverter) > > as well? The StringConverter is in javafx.util and seems like another well suited means for conversion to/from String. > Yeah, makes sense. I did not know this class exists. > One other question not directly related -- why do our bindBidirectional methods take a Property instead of a WritableValue? > Because a WritableValue is not observable. I think at some point we had something like public static & ObservableValue> void bindBidirectional(T obj1, T obj2) but then we dropped it and used properties instead to make the signature more readable. So far properties are the only implementation of both interfaces. - Michael > Thanks > Richard > > On Dec 9, 2011, at 1:33 AM, Michael Heinrichs wrote: > >> Hi everybody, >> >> I am working on a solution for the Binding API that allows bidirectional bindings between an arbitrary property and a StringProperty. (The long term plan is to allow bidirectional bindings between two arbitrary properties in JavaFX 3.0). The request is tracked here: http://javafx-jira.kenai.com/browse/RT-18203 >> >> The class javafx.beans.binding.Bindings will get two new methods: >> public static void bindBidirectional(Property stringProperty, Property otherProperty, Format format) >> public static void unbindBidirectional(Object property1, Object property2) >> >> >> The class javafx.beans.property.StringProperty will also get two new methods: >> public void bindBidirectional(Property other, Format format) >> public void unbindBidirectional(Object other) >> >> If parsing the StringProperty fails, the other property will be set to the default value. If formatting the arbitraty property fails, the StringProperty will be set to the empty String. >> >> Any thoughts? >> >> Thanks, >> Michael > From richard.bair at oracle.com Fri Dec 9 08:16:27 2011 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 9 Dec 2011 08:16:27 -0800 Subject: Bidirectional binding with conversion In-Reply-To: <37D18C97-4EC1-43C2-A230-316FE9FC4B80@oracle.com> References: <37D18C97-4EC1-43C2-A230-316FE9FC4B80@oracle.com> Message-ID: <8E2CCAA7-6286-4B26-BB0C-FA45EC945008@oracle.com> >> Hi Michael, >> >> What about adding: >> >> public void bindBidirectional(Property other, StringConverter) >> >> as well? The StringConverter is in javafx.util and seems like another well suited means for conversion to/from String. >> > > Yeah, makes sense. I did not know this class exists. > >> One other question not directly related -- why do our bindBidirectional methods take a Property instead of a WritableValue? >> > > Because a WritableValue is not observable. I think at some point we had something like > public static & ObservableValue> void bindBidirectional(T obj1, T obj2) > but then we dropped it and used properties instead to make the signature more readable. So far properties are the only implementation of both interfaces. Ah, that is what Dan was saying in another thread (WritableValue is not an ObservableValue), but I have forgotten that. Thanks Richard From knut.arne.vedaa at broadpark.no Fri Dec 9 08:33:10 2011 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Fri, 09 Dec 2011 17:33:10 +0100 Subject: Bidirectional binding with conversion In-Reply-To: <8E2CCAA7-6286-4B26-BB0C-FA45EC945008@oracle.com> References: <37D18C97-4EC1-43C2-A230-316FE9FC4B80@oracle.com> <8E2CCAA7-6286-4B26-BB0C-FA45EC945008@oracle.com> Message-ID: <4EE23846.2040408@broadpark.no> On 09.12.2011 17:16, Richard Bair wrote: >>> One other question not directly related -- why do our bindBidirectional methods take a Property instead of a WritableValue? >>> >> >> Because a WritableValue is not observable. I think at some point we had something like >> public static & ObservableValue> void bindBidirectional(T obj1, T obj2) >> but then we dropped it and used properties instead to make the signature more readable. So far properties are the only implementation of both interfaces. > > Ah, that is what Dan was saying in another thread (WritableValue is not an ObservableValue), but I have forgotten that. My suggestion from the Controls thread could be useful then, at least semantically: interface Bindable extends ObservableValue, WritableValue interface Property extends ReadOnlyProperty, Bindable (Where the bind methods are moved from Property to Bindable.) This would avoid what I would see as a small semantic problem with Property, that the name indicates it is a property _of_ something. Which is doesn't have to be just for binding to it. Knut Arne From jonathan.giles at oracle.com Fri Dec 9 14:56:24 2011 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Sat, 10 Dec 2011 08:56:24 +1000 Subject: Supporting the Mac OS menubar in JavaFX Message-ID: <4EE29218.4090305@oracle.com> Hi all, One of the things we're planning to support in JavaFX 2.1 is the native Mac OS menubar. This email is intended primarily to discuss the API one expects to see to set a MenuBar in the native Mac OS menubar area. Your feedback is sought and will be very much appreciated. The current thinking is that Application feels like the right place to specify a global, application-wide javafx.scene.control.MenuBar on. It could be assumed that if a developer were to set this property, and the operating system upon which the end-user was running the JavaFX application was Mac OS, that the menubar will be displayed using the native Mac OS menubar. Of course, if a developer wants a cross-platform look and feel, they could just place the MenuBar in the stage as per usual and it would display as it currently does. This approach opens up a number of questions and issues: 1) What happens in the case of the end-user being on Windows? Is the Application.MenuBar ignored, or is it automagically added to the main Stage? (I would argue for totally ignoring it....but that leads to the next point). 2) This approach means there needs to be operating specific code in the UI to test whether a non-native MenuBar should be added (in the case of Windows, for example). This starts to clutter the UI code, and without careful consideration by the developer may result in needing to duplicate their MenuBar code. Is there a better approach? Another place to specify a MenuBar would be on Stage, rather than (or in addition to), Application. Having a MenuBar property on Stage would allow for the MenuBar to change based on the currently focused Stage - but I'm not certain this is desirable or even the expected behaviour of Mac OS. Therefore, I'm thinking that this is not likely to happen unless we hear otherwise. Like I said, we're at a very early exploration point in this process. The controls team is very keen to hear feedback from the community, as well as from the owners of the Application API, and the Mac OS experts on this list. Thanks, -- Jonathan From richard.bair at oracle.com Fri Dec 9 15:18:31 2011 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 9 Dec 2011 15:18:31 -0800 Subject: Supporting the Mac OS menubar in JavaFX In-Reply-To: <4EE29218.4090305@oracle.com> References: <4EE29218.4090305@oracle.com> Message-ID: Hi Jonathan, There is one other problem, which is modularity. Having Application or Stage know about javafx.scene.control package would mean a new dependency. What about the idea that the MenuBarSkin either shows itself, or doesn't, based on OS? And hoists the contents into the Mac menu bar when needed? Richard On Dec 9, 2011, at 2:56 PM, Jonathan Giles wrote: > Hi all, > > One of the things we're planning to support in JavaFX 2.1 is the native Mac OS menubar. This email is intended primarily to discuss the API one expects to see to set a MenuBar in the native Mac OS menubar area. Your feedback is sought and will be very much appreciated. > > The current thinking is that Application feels like the right place to specify a global, application-wide javafx.scene.control.MenuBar on. It could be assumed that if a developer were to set this property, and the operating system upon which the end-user was running the JavaFX application was Mac OS, that the menubar will be displayed using the native Mac OS menubar. Of course, if a developer wants a cross-platform look and feel, they could just place the MenuBar in the stage as per usual and it would display as it currently does. This approach opens up a number of questions and issues: > > 1) What happens in the case of the end-user being on Windows? Is the Application.MenuBar ignored, or is it automagically added to the main Stage? (I would argue for totally ignoring it....but that leads to the next point). > 2) This approach means there needs to be operating specific code in the UI to test whether a non-native MenuBar should be added (in the case of Windows, for example). This starts to clutter the UI code, and without careful consideration by the developer may result in needing to duplicate their MenuBar code. Is there a better approach? > > Another place to specify a MenuBar would be on Stage, rather than (or in addition to), Application. Having a MenuBar property on Stage would allow for the MenuBar to change based on the currently focused Stage - but I'm not certain this is desirable or even the expected behaviour of Mac OS. Therefore, I'm thinking that this is not likely to happen unless we hear otherwise. > > Like I said, we're at a very early exploration point in this process. The controls team is very keen to hear feedback from the community, as well as from the owners of the Application API, and the Mac OS experts on this list. > > Thanks, > -- Jonathan From steve.x.northover at oracle.com Fri Dec 9 15:24:19 2011 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Fri, 09 Dec 2011 18:24:19 -0500 Subject: Supporting the Mac OS menubar in JavaFX In-Reply-To: References: <4EE29218.4090305@oracle.com> Message-ID: <4EE298A3.7090306@oracle.com> I'm wondering about the ability to support the native menu bar and expose all of the functionality of JavaFX using the existing menu bar classes. Most operating systems provide a custom draw capability but it is quite limited and unlikely to respond well to a scene graph based widget toolkit like JavaFX. I suspect strongly that we will need new classes to model the native menu bar ... but I would love to be wrong. Steve On 09/12/2011 6:18 PM, Richard Bair wrote: > Hi Jonathan, > > There is one other problem, which is modularity. Having Application or Stage know about javafx.scene.control package would mean a new dependency. What about the idea that the MenuBarSkin either shows itself, or doesn't, based on OS? And hoists the contents into the Mac menu bar when needed? > > Richard > > On Dec 9, 2011, at 2:56 PM, Jonathan Giles wrote: > >> Hi all, >> >> One of the things we're planning to support in JavaFX 2.1 is the native Mac OS menubar. This email is intended primarily to discuss the API one expects to see to set a MenuBar in the native Mac OS menubar area. Your feedback is sought and will be very much appreciated. >> >> The current thinking is that Application feels like the right place to specify a global, application-wide javafx.scene.control.MenuBar on. It could be assumed that if a developer were to set this property, and the operating system upon which the end-user was running the JavaFX application was Mac OS, that the menubar will be displayed using the native Mac OS menubar. Of course, if a developer wants a cross-platform look and feel, they could just place the MenuBar in the stage as per usual and it would display as it currently does. This approach opens up a number of questions and issues: >> >> 1) What happens in the case of the end-user being on Windows? Is the Application.MenuBar ignored, or is it automagically added to the main Stage? (I would argue for totally ignoring it....but that leads to the next point). >> 2) This approach means there needs to be operating specific code in the UI to test whether a non-native MenuBar should be added (in the case of Windows, for example). This starts to clutter the UI code, and without careful consideration by the developer may result in needing to duplicate their MenuBar code. Is there a better approach? >> >> Another place to specify a MenuBar would be on Stage, rather than (or in addition to), Application. Having a MenuBar property on Stage would allow for the MenuBar to change based on the currently focused Stage - but I'm not certain this is desirable or even the expected behaviour of Mac OS. Therefore, I'm thinking that this is not likely to happen unless we hear otherwise. >> >> Like I said, we're at a very early exploration point in this process. The controls team is very keen to hear feedback from the community, as well as from the owners of the Application API, and the Mac OS experts on this list. >> >> Thanks, >> -- Jonathan From jonathan.giles at oracle.com Fri Dec 9 15:28:33 2011 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Sat, 10 Dec 2011 09:28:33 +1000 Subject: Supporting the Mac OS menubar in JavaFX In-Reply-To: <4EE298A3.7090306@oracle.com> References: <4EE29218.4090305@oracle.com> <4EE298A3.7090306@oracle.com> Message-ID: <4EE299A1.5060201@oracle.com> My understanding, from an incredibly haven't-been-involved-in-the-discussion high-level, is that there will be API exposed at the Toolkit level [1], which would not be based around javafx.scene.control.Menu* classes. It would be a requirement for the controls team to convert from javafx.scene.control.Menu* to the relevant native menu bar API. We would lose some functionality along the way (CustomMenuItem would probably not be supported at all in 2.1) [1] http://javafx-jira.kenai.com/browse/RT-18056 -- Jonathan On Saturday, 10 December 2011 9:24:19 a.m., steve.x.northover at oracle.com wrote: > I'm wondering about the ability to support the native menu bar and > expose all of the functionality of JavaFX using the existing menu bar > classes. Most operating systems provide a custom draw capability but > it is quite limited and unlikely to respond well to a scene graph > based widget toolkit like JavaFX. > > I suspect strongly that we will need new classes to model the native > menu bar ... but I would love to be wrong. > > Steve > > On 09/12/2011 6:18 PM, Richard Bair wrote: >> Hi Jonathan, >> >> There is one other problem, which is modularity. Having Application >> or Stage know about javafx.scene.control package would mean a new >> dependency. What about the idea that the MenuBarSkin either shows >> itself, or doesn't, based on OS? And hoists the contents into the Mac >> menu bar when needed? >> >> Richard >> >> On Dec 9, 2011, at 2:56 PM, Jonathan Giles wrote: >> >>> Hi all, >>> >>> One of the things we're planning to support in JavaFX 2.1 is the >>> native Mac OS menubar. This email is intended primarily to discuss >>> the API one expects to see to set a MenuBar in the native Mac OS >>> menubar area. Your feedback is sought and will be very much >>> appreciated. >>> >>> The current thinking is that Application feels like the right place >>> to specify a global, application-wide javafx.scene.control.MenuBar >>> on. It could be assumed that if a developer were to set this >>> property, and the operating system upon which the end-user was >>> running the JavaFX application was Mac OS, that the menubar will be >>> displayed using the native Mac OS menubar. Of course, if a developer >>> wants a cross-platform look and feel, they could just place the >>> MenuBar in the stage as per usual and it would display as it >>> currently does. This approach opens up a number of questions and >>> issues: >>> >>> 1) What happens in the case of the end-user being on Windows? Is the >>> Application.MenuBar ignored, or is it automagically added to the >>> main Stage? (I would argue for totally ignoring it....but that leads >>> to the next point). >>> 2) This approach means there needs to be operating specific code in >>> the UI to test whether a non-native MenuBar should be added (in the >>> case of Windows, for example). This starts to clutter the UI code, >>> and without careful consideration by the developer may result in >>> needing to duplicate their MenuBar code. Is there a better approach? >>> >>> Another place to specify a MenuBar would be on Stage, rather than >>> (or in addition to), Application. Having a MenuBar property on Stage >>> would allow for the MenuBar to change based on the currently focused >>> Stage - but I'm not certain this is desirable or even the expected >>> behaviour of Mac OS. Therefore, I'm thinking that this is not likely >>> to happen unless we hear otherwise. >>> >>> Like I said, we're at a very early exploration point in this >>> process. The controls team is very keen to hear feedback from the >>> community, as well as from the owners of the Application API, and >>> the Mac OS experts on this list. >>> >>> Thanks, >>> -- Jonathan From jonathan.giles at oracle.com Fri Dec 9 15:33:35 2011 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Sat, 10 Dec 2011 09:33:35 +1000 Subject: Supporting the Mac OS menubar in JavaFX In-Reply-To: References: <4EE29218.4090305@oracle.com> Message-ID: <4EE29ACF.3040907@oracle.com> Rich, Thanks - that's a good point about modularity. The approach you suggest seems like a good alternative. It nicely avoids the need to specify a MenuBar in two places (Application and in the developers scenegraph). I have a few comments: 1) I'm assuming we would add a boolean property to MenuBar to allow for developers to prevent the conversion to native if that wasn't their desire. 2) We would have to develop some semantics around what MenuBar becomes the native menu bar. I would assume that it is the first MenuBar found on the currently focused Stage that has the boolean mentioned in 1) above set to allow for native conversion. In cases where a Stage is brought up that does not have a MenuBar (or the menubar is not allowed to convert to native), the previously converted menu bar will remain showing. Am I missing anything else? -- Jonathan -- Jonathan On 10/12/2011 9:18 a.m., Richard Bair wrote: > Hi Jonathan, > > There is one other problem, which is modularity. Having Application or Stage know about javafx.scene.control package would mean a new dependency. What about the idea that the MenuBarSkin either shows itself, or doesn't, based on OS? And hoists the contents into the Mac menu bar when needed? > > Richard > > On Dec 9, 2011, at 2:56 PM, Jonathan Giles wrote: > >> Hi all, >> >> One of the things we're planning to support in JavaFX 2.1 is the native Mac OS menubar. This email is intended primarily to discuss the API one expects to see to set a MenuBar in the native Mac OS menubar area. Your feedback is sought and will be very much appreciated. >> >> The current thinking is that Application feels like the right place to specify a global, application-wide javafx.scene.control.MenuBar on. It could be assumed that if a developer were to set this property, and the operating system upon which the end-user was running the JavaFX application was Mac OS, that the menubar will be displayed using the native Mac OS menubar. Of course, if a developer wants a cross-platform look and feel, they could just place the MenuBar in the stage as per usual and it would display as it currently does. This approach opens up a number of questions and issues: >> >> 1) What happens in the case of the end-user being on Windows? Is the Application.MenuBar ignored, or is it automagically added to the main Stage? (I would argue for totally ignoring it....but that leads to the next point). >> 2) This approach means there needs to be operating specific code in the UI to test whether a non-native MenuBar should be added (in the case of Windows, for example). This starts to clutter the UI code, and without careful consideration by the developer may result in needing to duplicate their MenuBar code. Is there a better approach? >> >> Another place to specify a MenuBar would be on Stage, rather than (or in addition to), Application. Having a MenuBar property on Stage would allow for the MenuBar to change based on the currently focused Stage - but I'm not certain this is desirable or even the expected behaviour of Mac OS. Therefore, I'm thinking that this is not likely to happen unless we hear otherwise. >> >> Like I said, we're at a very early exploration point in this process. The controls team is very keen to hear feedback from the community, as well as from the owners of the Application API, and the Mac OS experts on this list. >> >> Thanks, >> -- Jonathan From tom.schindl at bestsolution.at Fri Dec 9 15:34:13 2011 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sat, 10 Dec 2011 00:34:13 +0100 Subject: Supporting the Mac OS menubar in JavaFX In-Reply-To: <4EE29218.4090305@oracle.com> References: <4EE29218.4090305@oracle.com> Message-ID: <4EE29AF5.5010608@bestsolution.at> [...] > Another place to specify a MenuBar would be on Stage, rather than (or in > addition to), Application. Having a MenuBar property on Stage would > allow for the MenuBar to change based on the currently focused Stage - > but I'm not certain this is desirable or even the expected behaviour of > Mac OS. Therefore, I'm thinking that this is not likely to happen unless > we hear otherwise. Well the menu changes definately based upon the focused top-level window. So I'm quite sure the MenuBar has to be specified on the Stage not? I'm wondering though how you'd like to support all the themeing stuff one is able to apply on menus/menuitems on OS-X. IIRC I recently read in a mail from Mike Swingler that one can implement arbitary Java Drawing post-Leopard but I'm not sure that matches the OS-X Menubar idea and all the fancy things one can do with JavaFX. Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From tom.schindl at bestsolution.at Fri Dec 9 15:36:25 2011 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sat, 10 Dec 2011 00:36:25 +0100 Subject: Supporting the Mac OS menubar in JavaFX In-Reply-To: <4EE29AF5.5010608@bestsolution.at> References: <4EE29218.4090305@oracle.com> <4EE29AF5.5010608@bestsolution.at> Message-ID: <4EE29B79.70204@bestsolution.at> Am 10.12.11 00:34, schrieb Tom Schindl: > [...] > >> Another place to specify a MenuBar would be on Stage, rather than (or in >> addition to), Application. Having a MenuBar property on Stage would >> allow for the MenuBar to change based on the currently focused Stage - >> but I'm not certain this is desirable or even the expected behaviour of >> Mac OS. Therefore, I'm thinking that this is not likely to happen unless >> we hear otherwise. > > Well the menu changes definately based upon the focused top-level > window. So I'm quite sure the MenuBar has to be specified on the Stage not? > > I'm wondering though how you'd like to support all the themeing stuff > one is able to apply on menus/menuitems on OS-X. ^^^^^^^^ JavaFX 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 steve.x.northover at oracle.com Fri Dec 9 15:46:03 2011 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Fri, 09 Dec 2011 18:46:03 -0500 Subject: Supporting the Mac OS menubar in JavaFX In-Reply-To: <4EE29AF5.5010608@bestsolution.at> References: <4EE29218.4090305@oracle.com> <4EE29AF5.5010608@bestsolution.at> Message-ID: <4EE29DBB.6030706@oracle.com> Many toolkits have supported portabilitly between Mac and Windows (and other operating systems that put the menu bar in the window) by swapping the menu bar on stage focus in and out. This is what SWT does. Recently, an app wide menu bar was added to support the Mac. Steve On 09/12/2011 6:34 PM, Tom Schindl wrote: > [...] > >> Another place to specify a MenuBar would be on Stage, rather than (or in >> addition to), Application. Having a MenuBar property on Stage would >> allow for the MenuBar to change based on the currently focused Stage - >> but I'm not certain this is desirable or even the expected behaviour of >> Mac OS. Therefore, I'm thinking that this is not likely to happen unless >> we hear otherwise. > Well the menu changes definately based upon the focused top-level > window. So I'm quite sure the MenuBar has to be specified on the Stage not? > > I'm wondering though how you'd like to support all the themeing stuff > one is able to apply on menus/menuitems on OS-X. > > IIRC I recently read in a mail from Mike Swingler that one can implement > arbitary Java Drawing post-Leopard but I'm not sure that matches the > OS-X Menubar idea and all the fancy things one can do with JavaFX. > > Tom > From james.graham at oracle.com Fri Dec 9 16:19:00 2011 From: james.graham at oracle.com (Jim Graham) Date: Fri, 09 Dec 2011 16:19:00 -0800 Subject: Supporting the Mac OS menubar in JavaFX In-Reply-To: <4EE29DBB.6030706@oracle.com> References: <4EE29218.4090305@oracle.com> <4EE29AF5.5010608@bestsolution.at> <4EE29DBB.6030706@oracle.com> Message-ID: <4EE2A574.9080709@oracle.com> If this was simply a skinning technique of "moving the Stage's menubar to the screen's menubar" that works if you have a window open, but it doesn't solve the problem of what happens when you have no windows open when Mac applications typically still manifest menus in the screen menubar. Sticking a "separate but equal" menubar somewhere would lead to applications failing to look like native Mac apps until the developers are made aware of the issues and require "extra" coding to deal with Mac deployment. If we could provide a way to specify: - Here are the menubar items that apply to all windows. - Here are the additional menubar items that apply to a specific window. - To be most flexible, the "additional items" might have to be additional items in the top-level menus that were specified for all windows - Would there also be a need to specify "but not these items" for some windows to delete some items that only make sense when no windows are open? Then it would be both an API for letting the runtime know which menubar items should remain after the last window closes on Mac, and a way to be able to populate lots of window menubars when an application has multiple windows. The actual manifestation of the menubar would be a control, but the specification of what items are needed could be in an independent format that doesn't bring in a whole new package. We could create skeleton "menu-ish-bar-ish-item" classes in the application package and those could be the data that the Menu* controls take, but one could attach a list of those to an Application object without having Application depend on controls. A Stage could then take an additional list and combine it with the list on the Application to make the full menu bar list which is then skinned by the controls. When no windows are open, then the Mac-specific application could still skin them in a native skin and deploy them on the screen menubar, or have a hidden dependency on the controls for that platform only. That's a fairly loose conceptual hand-waving outline, but maybe it could dislodge a more concrete design from someone more familiar with how all of those objects interact? ...jim On 12/9/2011 3:46 PM, steve.x.northover at oracle.com wrote: > Many toolkits have supported portabilitly between Mac and Windows (and > other operating systems that put the menu bar in the window) by swapping > the menu bar on stage focus in and out. This is what SWT does. Recently, > an app wide menu bar was added to support the Mac. > > Steve > > On 09/12/2011 6:34 PM, Tom Schindl wrote: >> [...] >> >>> Another place to specify a MenuBar would be on Stage, rather than (or in >>> addition to), Application. Having a MenuBar property on Stage would >>> allow for the MenuBar to change based on the currently focused Stage - >>> but I'm not certain this is desirable or even the expected behaviour of >>> Mac OS. Therefore, I'm thinking that this is not likely to happen unless >>> we hear otherwise. >> Well the menu changes definately based upon the focused top-level >> window. So I'm quite sure the MenuBar has to be specified on the Stage >> not? >> >> I'm wondering though how you'd like to support all the themeing stuff >> one is able to apply on menus/menuitems on OS-X. >> >> IIRC I recently read in a mail from Mike Swingler that one can implement >> arbitary Java Drawing post-Leopard but I'm not sure that matches the >> OS-X Menubar idea and all the fancy things one can do with JavaFX. >> >> Tom >> From jonathan.giles at oracle.com Fri Dec 9 16:38:59 2011 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Sat, 10 Dec 2011 10:38:59 +1000 Subject: Supporting the Mac OS menubar in JavaFX In-Reply-To: <4EE2A574.9080709@oracle.com> References: <4EE29218.4090305@oracle.com> <4EE29AF5.5010608@bestsolution.at> <4EE29DBB.6030706@oracle.com> <4EE2A574.9080709@oracle.com> Message-ID: <4EE2AA23.8060902@oracle.com> Just as a further data point to what Jim is saying: the javafx.scene.control.Menu* classes (MenuItem, and subclasses Menu, RadioMenuItem, CheckMenuItem, CustomMenuItem and SeparatorMenuItem) are not actually Controls. The only Menu* class that is a Control is MenuBar. From this perspective, it is actually unfortunate that these non-Control classes actually live in javafx-ui-control, as they may be totally suitable in the abstract sense that Jim discusses. -- -- Jonathan On Saturday, 10 December 2011 10:19:00 a.m., Jim Graham wrote: > > If this was simply a skinning technique of "moving the Stage's menubar > to the screen's menubar" that works if you have a window open, but it > doesn't solve the problem of what happens when you have no windows > open when Mac applications typically still manifest menus in the > screen menubar. > > Sticking a "separate but equal" menubar somewhere would lead to > applications failing to look like native Mac apps until the developers > are made aware of the issues and require "extra" coding to deal with > Mac deployment. > > If we could provide a way to specify: > > - Here are the menubar items that apply to all windows. > - Here are the additional menubar items that apply to a specific window. > - To be most flexible, the "additional items" might have to be > additional items in the top-level menus that were specified for all > windows > - Would there also be a need to specify "but not these items" for some > windows to delete some items that only make sense when no windows are > open? > > Then it would be both an API for letting the runtime know which > menubar items should remain after the last window closes on Mac, and a > way to be able to populate lots of window menubars when an application > has multiple windows. > > The actual manifestation of the menubar would be a control, but the > specification of what items are needed could be in an independent > format that doesn't bring in a whole new package. We could create > skeleton "menu-ish-bar-ish-item" classes in the application package > and those could be the data that the Menu* controls take, but one > could attach a list of those to an Application object without having > Application depend on controls. A Stage could then take an additional > list and combine it with the list on the Application to make the full > menu bar list which is then skinned by the controls. > > When no windows are open, then the Mac-specific application could > still skin them in a native skin and deploy them on the screen > menubar, or have a hidden dependency on the controls for that platform > only. > > That's a fairly loose conceptual hand-waving outline, but maybe it > could dislodge a more concrete design from someone more familiar with > how all of those objects interact? > > ...jim > > On 12/9/2011 3:46 PM, steve.x.northover at oracle.com wrote: >> >> Many toolkits have supported portabilitly between Mac and Windows (and >> other operating systems that put the menu bar in the window) by swapping >> the menu bar on stage focus in and out. This is what SWT does. Recently, >> an app wide menu bar was added to support the Mac. >> >> Steve >> >> On 09/12/2011 6:34 PM, Tom Schindl wrote: >>> >>> [...] >>> >>>> >>>> Another place to specify a MenuBar would be on Stage, rather than >>>> (or in >>>> addition to), Application. Having a MenuBar property on Stage would >>>> allow for the MenuBar to change based on the currently focused Stage - >>>> but I'm not certain this is desirable or even the expected >>>> behaviour of >>>> Mac OS. Therefore, I'm thinking that this is not likely to happen >>>> unless >>>> we hear otherwise. >>> >>> Well the menu changes definately based upon the focused top-level >>> window. So I'm quite sure the MenuBar has to be specified on the Stage >>> not? >>> >>> I'm wondering though how you'd like to support all the themeing stuff >>> one is able to apply on menus/menuitems on OS-X. >>> >>> IIRC I recently read in a mail from Mike Swingler that one can >>> implement >>> arbitary Java Drawing post-Leopard but I'm not sure that matches the >>> OS-X Menubar idea and all the fancy things one can do with JavaFX. >>> >>> Tom From steve.x.northover at oracle.com Fri Dec 9 17:04:50 2011 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Fri, 09 Dec 2011 20:04:50 -0500 Subject: Supporting the Mac OS menubar in JavaFX In-Reply-To: <4EE2AA23.8060902@oracle.com> References: <4EE29218.4090305@oracle.com> <4EE29AF5.5010608@bestsolution.at> <4EE29DBB.6030706@oracle.com> <4EE2A574.9080709@oracle.com> <4EE2AA23.8060902@oracle.com> Message-ID: <4EE2B032.2090707@oracle.com> Right. I knew that at one point (MenuItem and friends are not Nodes). They take a Node as a graphic and that would be really interesting if someone put a web browser in there! Steve On 09/12/2011 7:38 PM, Jonathan Giles wrote: > Just as a further data point to what Jim is saying: the > javafx.scene.control.Menu* classes (MenuItem, and subclasses Menu, > RadioMenuItem, CheckMenuItem, CustomMenuItem and SeparatorMenuItem) > are not actually Controls. The only Menu* class that is a Control is > MenuBar. > > From this perspective, it is actually unfortunate that these > non-Control classes actually live in javafx-ui-control, as they may be > totally suitable in the abstract sense that Jim discusses. > From richard.bair at oracle.com Fri Dec 9 17:57:22 2011 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 9 Dec 2011 17:57:22 -0800 Subject: Supporting the Mac OS menubar in JavaFX In-Reply-To: <4EE2AA23.8060902@oracle.com> References: <4EE29218.4090305@oracle.com> <4EE29AF5.5010608@bestsolution.at> <4EE29DBB.6030706@oracle.com> <4EE2A574.9080709@oracle.com> <4EE2AA23.8060902@oracle.com> Message-ID: <8E8F7400-AAD1-4984-B7FD-C511482077B5@oracle.com> Ya, that's the bummer. We exactly designed the menus for the exact usage Jim describes, but didn't put them in a suitable package for modularization. Drat!!! On Dec 9, 2011, at 4:38 PM, Jonathan Giles wrote: > Just as a further data point to what Jim is saying: the javafx.scene.control.Menu* classes (MenuItem, and subclasses Menu, RadioMenuItem, CheckMenuItem, CustomMenuItem and SeparatorMenuItem) are not actually Controls. The only Menu* class that is a Control is MenuBar. > > From this perspective, it is actually unfortunate that these non-Control classes actually live in javafx-ui-control, as they may be totally suitable in the abstract sense that Jim discusses. > > -- > -- Jonathan > > > > On Saturday, 10 December 2011 10:19:00 a.m., Jim Graham wrote: >> >> If this was simply a skinning technique of "moving the Stage's menubar >> to the screen's menubar" that works if you have a window open, but it >> doesn't solve the problem of what happens when you have no windows >> open when Mac applications typically still manifest menus in the >> screen menubar. >> >> Sticking a "separate but equal" menubar somewhere would lead to >> applications failing to look like native Mac apps until the developers >> are made aware of the issues and require "extra" coding to deal with >> Mac deployment. >> >> If we could provide a way to specify: >> >> - Here are the menubar items that apply to all windows. >> - Here are the additional menubar items that apply to a specific window. >> - To be most flexible, the "additional items" might have to be >> additional items in the top-level menus that were specified for all >> windows >> - Would there also be a need to specify "but not these items" for some >> windows to delete some items that only make sense when no windows are >> open? >> >> Then it would be both an API for letting the runtime know which >> menubar items should remain after the last window closes on Mac, and a >> way to be able to populate lots of window menubars when an application >> has multiple windows. >> >> The actual manifestation of the menubar would be a control, but the >> specification of what items are needed could be in an independent >> format that doesn't bring in a whole new package. We could create >> skeleton "menu-ish-bar-ish-item" classes in the application package >> and those could be the data that the Menu* controls take, but one >> could attach a list of those to an Application object without having >> Application depend on controls. A Stage could then take an additional >> list and combine it with the list on the Application to make the full >> menu bar list which is then skinned by the controls. >> >> When no windows are open, then the Mac-specific application could >> still skin them in a native skin and deploy them on the screen >> menubar, or have a hidden dependency on the controls for that platform >> only. >> >> That's a fairly loose conceptual hand-waving outline, but maybe it >> could dislodge a more concrete design from someone more familiar with >> how all of those objects interact? >> >> ...jim >> >> On 12/9/2011 3:46 PM, steve.x.northover at oracle.com wrote: >>> >>> Many toolkits have supported portabilitly between Mac and Windows (and >>> other operating systems that put the menu bar in the window) by swapping >>> the menu bar on stage focus in and out. This is what SWT does. Recently, >>> an app wide menu bar was added to support the Mac. >>> >>> Steve >>> >>> On 09/12/2011 6:34 PM, Tom Schindl wrote: >>>> >>>> [...] >>>> >>>>> >>>>> Another place to specify a MenuBar would be on Stage, rather than >>>>> (or in >>>>> addition to), Application. Having a MenuBar property on Stage would >>>>> allow for the MenuBar to change based on the currently focused Stage - >>>>> but I'm not certain this is desirable or even the expected >>>>> behaviour of >>>>> Mac OS. Therefore, I'm thinking that this is not likely to happen >>>>> unless >>>>> we hear otherwise. >>>> >>>> Well the menu changes definately based upon the focused top-level >>>> window. So I'm quite sure the MenuBar has to be specified on the Stage >>>> not? >>>> >>>> I'm wondering though how you'd like to support all the themeing stuff >>>> one is able to apply on menus/menuitems on OS-X. >>>> >>>> IIRC I recently read in a mail from Mike Swingler that one can >>>> implement >>>> arbitary Java Drawing post-Leopard but I'm not sure that matches the >>>> OS-X Menubar idea and all the fancy things one can do with JavaFX. >>>> >>>> Tom From james.graham at oracle.com Fri Dec 9 18:55:34 2011 From: james.graham at oracle.com (Jim Graham) Date: Fri, 09 Dec 2011 18:55:34 -0800 Subject: Supporting the Mac OS menubar in JavaFX In-Reply-To: <8E8F7400-AAD1-4984-B7FD-C511482077B5@oracle.com> References: <4EE29218.4090305@oracle.com> <4EE29AF5.5010608@bestsolution.at> <4EE29DBB.6030706@oracle.com> <4EE2A574.9080709@oracle.com> <4EE2AA23.8060902@oracle.com> <8E8F7400-AAD1-4984-B7FD-C511482077B5@oracle.com> Message-ID: <4EE2CA26.6010108@oracle.com> Could the classes be copied to javafx.application, the old classes made into empty subclasses of the copies, and then the signatures on the methods that accepted them be relaxed to the supertype? (Possibly might have to have duplicate methods if that isn't binary compatible?) ...jim On 12/9/2011 5:57 PM, Richard Bair wrote: > Ya, that's the bummer. We exactly designed the menus for the exact usage Jim describes, but didn't put them in a suitable package for modularization. Drat!!! > > On Dec 9, 2011, at 4:38 PM, Jonathan Giles wrote: > >> Just as a further data point to what Jim is saying: the javafx.scene.control.Menu* classes (MenuItem, and subclasses Menu, RadioMenuItem, CheckMenuItem, CustomMenuItem and SeparatorMenuItem) are not actually Controls. The only Menu* class that is a Control is MenuBar. >> >> From this perspective, it is actually unfortunate that these non-Control classes actually live in javafx-ui-control, as they may be totally suitable in the abstract sense that Jim discusses. >> >> -- >> -- Jonathan >> >> >> >> On Saturday, 10 December 2011 10:19:00 a.m., Jim Graham wrote: >>> >>> If this was simply a skinning technique of "moving the Stage's menubar >>> to the screen's menubar" that works if you have a window open, but it >>> doesn't solve the problem of what happens when you have no windows >>> open when Mac applications typically still manifest menus in the >>> screen menubar. >>> >>> Sticking a "separate but equal" menubar somewhere would lead to >>> applications failing to look like native Mac apps until the developers >>> are made aware of the issues and require "extra" coding to deal with >>> Mac deployment. >>> >>> If we could provide a way to specify: >>> >>> - Here are the menubar items that apply to all windows. >>> - Here are the additional menubar items that apply to a specific window. >>> - To be most flexible, the "additional items" might have to be >>> additional items in the top-level menus that were specified for all >>> windows >>> - Would there also be a need to specify "but not these items" for some >>> windows to delete some items that only make sense when no windows are >>> open? >>> >>> Then it would be both an API for letting the runtime know which >>> menubar items should remain after the last window closes on Mac, and a >>> way to be able to populate lots of window menubars when an application >>> has multiple windows. >>> >>> The actual manifestation of the menubar would be a control, but the >>> specification of what items are needed could be in an independent >>> format that doesn't bring in a whole new package. We could create >>> skeleton "menu-ish-bar-ish-item" classes in the application package >>> and those could be the data that the Menu* controls take, but one >>> could attach a list of those to an Application object without having >>> Application depend on controls. A Stage could then take an additional >>> list and combine it with the list on the Application to make the full >>> menu bar list which is then skinned by the controls. >>> >>> When no windows are open, then the Mac-specific application could >>> still skin them in a native skin and deploy them on the screen >>> menubar, or have a hidden dependency on the controls for that platform >>> only. >>> >>> That's a fairly loose conceptual hand-waving outline, but maybe it >>> could dislodge a more concrete design from someone more familiar with >>> how all of those objects interact? >>> >>> ...jim >>> >>> On 12/9/2011 3:46 PM, steve.x.northover at oracle.com wrote: >>>> >>>> Many toolkits have supported portabilitly between Mac and Windows (and >>>> other operating systems that put the menu bar in the window) by swapping >>>> the menu bar on stage focus in and out. This is what SWT does. Recently, >>>> an app wide menu bar was added to support the Mac. >>>> >>>> Steve >>>> >>>> On 09/12/2011 6:34 PM, Tom Schindl wrote: >>>>> >>>>> [...] >>>>> >>>>>> >>>>>> Another place to specify a MenuBar would be on Stage, rather than >>>>>> (or in >>>>>> addition to), Application. Having a MenuBar property on Stage would >>>>>> allow for the MenuBar to change based on the currently focused Stage - >>>>>> but I'm not certain this is desirable or even the expected >>>>>> behaviour of >>>>>> Mac OS. Therefore, I'm thinking that this is not likely to happen >>>>>> unless >>>>>> we hear otherwise. >>>>> >>>>> Well the menu changes definately based upon the focused top-level >>>>> window. So I'm quite sure the MenuBar has to be specified on the Stage >>>>> not? >>>>> >>>>> I'm wondering though how you'd like to support all the themeing stuff >>>>> one is able to apply on menus/menuitems on OS-X. >>>>> >>>>> IIRC I recently read in a mail from Mike Swingler that one can >>>>> implement >>>>> arbitary Java Drawing post-Leopard but I'm not sure that matches the >>>>> OS-X Menubar idea and all the fancy things one can do with JavaFX. >>>>> >>>>> Tom > From zonski at googlemail.com Fri Dec 9 20:46:53 2011 From: zonski at googlemail.com (Daniel Zwolenski) Date: Sat, 10 Dec 2011 15:46:53 +1100 Subject: Supporting the Mac OS menubar in JavaFX In-Reply-To: <4EE2CA26.6010108@oracle.com> References: <4EE29218.4090305@oracle.com> <4EE29AF5.5010608@bestsolution.at> <4EE29DBB.6030706@oracle.com> <4EE2A574.9080709@oracle.com> <4EE2AA23.8060902@oracle.com> <8E8F7400-AAD1-4984-B7FD-C511482077B5@oracle.com> <4EE2CA26.6010108@oracle.com> Message-ID: Can I throw a few more bigger picture things into the murky puddle of OS menu bars and integration. I'm not saying these are all directly related to the problem at hand or even are things JFX should be solving, but I think floating them past the think tank in the context of this conversation is not an unhealthy thing to do: * In windows 7 (and possibly other versions, not sure), if I right click on the icon in the task bar it gives me an application-specific menu, which I think is not completely dissimilar in usage to the application-level Mac toolbar options (i.e. the ones that are left after you close all the windows). * Windows also has the 'system tray' thing for 'background-style' applications. Right-clicking on an icon in this brings up another menu that is application related. * OS variations are not the only issue. There is Applet vs Application to think about. This whole toolbar thing is only relevant in true desktop apps (as far as I can see) so Applets (even on Mac) need to have their rules defined. * iPhone/iPad and Android all have their own 'os' specific menu systems that are similar but not completely the same as the mac window. If the mobile support for JavaFX happens (please, please, please), then a menu API will be needed for this that doesn't look totally dissimilar to the mac one again. Over-future proofing can be a problem, but being generally aware of likely future directions can be healthy. In Android it is the 'options menu' http://developer.android.com/guide/topics/ui/menus.html and in iPhone/iPad it is the 'navigation toolbar' http://developer.apple.com/library/IOs/#featuredarticles/ViewControllerPGforiPhoneOS/NavigationControllers/NavigationControllers.html#//apple_ref/doc/uid/TP40007457-CH103-SW4 As I said, just food for thought rather than direct issues in need of solutions. On Sat, Dec 10, 2011 at 1:55 PM, Jim Graham wrote: > Could the classes be copied to javafx.application, the old classes made > into empty subclasses of the copies, and then the signatures on the methods > that accepted them be relaxed to the supertype? (Possibly might have to > have duplicate methods if that isn't binary compatible?) > > ...jim > > > On 12/9/2011 5:57 PM, Richard Bair wrote: > >> Ya, that's the bummer. We exactly designed the menus for the exact usage >> Jim describes, but didn't put them in a suitable package for >> modularization. Drat!!! >> >> On Dec 9, 2011, at 4:38 PM, Jonathan Giles wrote: >> >> Just as a further data point to what Jim is saying: the >>> javafx.scene.control.Menu* classes (MenuItem, and subclasses Menu, >>> RadioMenuItem, CheckMenuItem, CustomMenuItem and SeparatorMenuItem) are not >>> actually Controls. The only Menu* class that is a Control is MenuBar. >>> >>> From this perspective, it is actually unfortunate that these >>> non-Control classes actually live in javafx-ui-control, as they may be >>> totally suitable in the abstract sense that Jim discusses. >>> >>> -- >>> -- Jonathan >>> >>> >>> >>> On Saturday, 10 December 2011 10:19:00 a.m., Jim Graham wrote: >>> >>>> >>>> If this was simply a skinning technique of "moving the Stage's menubar >>>> to the screen's menubar" that works if you have a window open, but it >>>> doesn't solve the problem of what happens when you have no windows >>>> open when Mac applications typically still manifest menus in the >>>> screen menubar. >>>> >>>> Sticking a "separate but equal" menubar somewhere would lead to >>>> applications failing to look like native Mac apps until the developers >>>> are made aware of the issues and require "extra" coding to deal with >>>> Mac deployment. >>>> >>>> If we could provide a way to specify: >>>> >>>> - Here are the menubar items that apply to all windows. >>>> - Here are the additional menubar items that apply to a specific window. >>>> - To be most flexible, the "additional items" might have to be >>>> additional items in the top-level menus that were specified for all >>>> windows >>>> - Would there also be a need to specify "but not these items" for some >>>> windows to delete some items that only make sense when no windows are >>>> open? >>>> >>>> Then it would be both an API for letting the runtime know which >>>> menubar items should remain after the last window closes on Mac, and a >>>> way to be able to populate lots of window menubars when an application >>>> has multiple windows. >>>> >>>> The actual manifestation of the menubar would be a control, but the >>>> specification of what items are needed could be in an independent >>>> format that doesn't bring in a whole new package. We could create >>>> skeleton "menu-ish-bar-ish-item" classes in the application package >>>> and those could be the data that the Menu* controls take, but one >>>> could attach a list of those to an Application object without having >>>> Application depend on controls. A Stage could then take an additional >>>> list and combine it with the list on the Application to make the full >>>> menu bar list which is then skinned by the controls. >>>> >>>> When no windows are open, then the Mac-specific application could >>>> still skin them in a native skin and deploy them on the screen >>>> menubar, or have a hidden dependency on the controls for that platform >>>> only. >>>> >>>> That's a fairly loose conceptual hand-waving outline, but maybe it >>>> could dislodge a more concrete design from someone more familiar with >>>> how all of those objects interact? >>>> >>>> ...jim >>>> >>>> On 12/9/2011 3:46 PM, steve.x.northover at oracle.com wrote: >>>> >>>>> >>>>> Many toolkits have supported portabilitly between Mac and Windows (and >>>>> other operating systems that put the menu bar in the window) by >>>>> swapping >>>>> the menu bar on stage focus in and out. This is what SWT does. >>>>> Recently, >>>>> an app wide menu bar was added to support the Mac. >>>>> >>>>> Steve >>>>> >>>>> On 09/12/2011 6:34 PM, Tom Schindl wrote: >>>>> >>>>>> >>>>>> [...] >>>>>> >>>>>> >>>>>>> Another place to specify a MenuBar would be on Stage, rather than >>>>>>> (or in >>>>>>> addition to), Application. Having a MenuBar property on Stage would >>>>>>> allow for the MenuBar to change based on the currently focused Stage >>>>>>> - >>>>>>> but I'm not certain this is desirable or even the expected >>>>>>> behaviour of >>>>>>> Mac OS. Therefore, I'm thinking that this is not likely to happen >>>>>>> unless >>>>>>> we hear otherwise. >>>>>>> >>>>>> >>>>>> Well the menu changes definately based upon the focused top-level >>>>>> window. So I'm quite sure the MenuBar has to be specified on the Stage >>>>>> not? >>>>>> >>>>>> I'm wondering though how you'd like to support all the themeing stuff >>>>>> one is able to apply on menus/menuitems on OS-X. >>>>>> >>>>>> IIRC I recently read in a mail from Mike Swingler that one can >>>>>> implement >>>>>> arbitary Java Drawing post-Leopard but I'm not sure that matches the >>>>>> OS-X Menubar idea and all the fancy things one can do with JavaFX. >>>>>> >>>>>> Tom >>>>>> >>>>> >> From mp at jugs.org Sat Dec 10 03:32:39 2011 From: mp at jugs.org (Dr. Michael Paus) Date: Sat, 10 Dec 2011 12:32:39 +0100 Subject: Supporting the Mac OS menubar in JavaFX In-Reply-To: References: <4EE29218.4090305@oracle.com> <4EE29AF5.5010608@bestsolution.at> <4EE29DBB.6030706@oracle.com> <4EE2A574.9080709@oracle.com> <4EE2AA23.8060902@oracle.com> <8E8F7400-AAD1-4984-B7FD-C511482077B5@oracle.com> <4EE2CA26.6010108@oracle.com> Message-ID: <4EE34357.8020109@jugs.org> Hi, I agree with Zonski that there is more to look at than just the menu bar. In order to get some ideas it might be interesting to look at what apple or others recommend now for making Swing apps look more native on MacOS. A good introduction can be found here: Going through this document you will see that there are more things that we should consider which go beyond the pure placement of the menu bar. Michael Am 10.12.2011 05:46, schrieb Daniel Zwolenski: > Can I throw a few more bigger picture things into the murky puddle of OS > menu bars and integration. I'm not saying these are all directly related to > the problem at hand or even are things JFX should be solving, but I think > floating them past the think tank in the context of this conversation is > not an unhealthy thing to do: > > * In windows 7 (and possibly other versions, not sure), if I right click on > the icon in the task bar it gives me an application-specific menu, which I > think is not completely dissimilar in usage to the application-level Mac > toolbar options (i.e. the ones that are left after you close all the > windows). > > * Windows also has the 'system tray' thing for 'background-style' > applications. Right-clicking on an icon in this brings up another menu that > is application related. > > * OS variations are not the only issue. There is Applet vs Application to > think about. This whole toolbar thing is only relevant in true desktop apps > (as far as I can see) so Applets (even on Mac) need to have their rules > defined. > > * iPhone/iPad and Android all have their own 'os' specific menu systems > that are similar but not completely the same as the mac window. If the > mobile support for JavaFX happens (please, please, please), then a menu API > will be needed for this that doesn't look totally dissimilar to the mac one > again. Over-future proofing can be a problem, but being generally aware of > likely future directions can be healthy. In Android it is the 'options > menu' http://developer.android.com/guide/topics/ui/menus.html and in > iPhone/iPad it is the 'navigation toolbar' > http://developer.apple.com/library/IOs/#featuredarticles/ViewControllerPGforiPhoneOS/NavigationControllers/NavigationControllers.html#//apple_ref/doc/uid/TP40007457-CH103-SW4 > > > > As I said, just food for thought rather than direct issues in need of > solutions. > > > On Sat, Dec 10, 2011 at 1:55 PM, Jim Graham wrote: > >> Could the classes be copied to javafx.application, the old classes made >> into empty subclasses of the copies, and then the signatures on the methods >> that accepted them be relaxed to the supertype? (Possibly might have to >> have duplicate methods if that isn't binary compatible?) >> >> ...jim >> >> >> On 12/9/2011 5:57 PM, Richard Bair wrote: >> >>> Ya, that's the bummer. We exactly designed the menus for the exact usage >>> Jim describes, but didn't put them in a suitable package for >>> modularization. Drat!!! >>> >>> On Dec 9, 2011, at 4:38 PM, Jonathan Giles wrote: >>> >>> Just as a further data point to what Jim is saying: the >>>> javafx.scene.control.Menu* classes (MenuItem, and subclasses Menu, >>>> RadioMenuItem, CheckMenuItem, CustomMenuItem and SeparatorMenuItem) are not >>>> actually Controls. The only Menu* class that is a Control is MenuBar. >>>> >>>> From this perspective, it is actually unfortunate that these >>>> non-Control classes actually live in javafx-ui-control, as they may be >>>> totally suitable in the abstract sense that Jim discusses. >>>> >>>> -- >>>> -- Jonathan >>>> >>>> >>>> >>>> On Saturday, 10 December 2011 10:19:00 a.m., Jim Graham wrote: >>>> >>>>> If this was simply a skinning technique of "moving the Stage's menubar >>>>> to the screen's menubar" that works if you have a window open, but it >>>>> doesn't solve the problem of what happens when you have no windows >>>>> open when Mac applications typically still manifest menus in the >>>>> screen menubar. >>>>> >>>>> Sticking a "separate but equal" menubar somewhere would lead to >>>>> applications failing to look like native Mac apps until the developers >>>>> are made aware of the issues and require "extra" coding to deal with >>>>> Mac deployment. >>>>> >>>>> If we could provide a way to specify: >>>>> >>>>> - Here are the menubar items that apply to all windows. >>>>> - Here are the additional menubar items that apply to a specific window. >>>>> - To be most flexible, the "additional items" might have to be >>>>> additional items in the top-level menus that were specified for all >>>>> windows >>>>> - Would there also be a need to specify "but not these items" for some >>>>> windows to delete some items that only make sense when no windows are >>>>> open? >>>>> >>>>> Then it would be both an API for letting the runtime know which >>>>> menubar items should remain after the last window closes on Mac, and a >>>>> way to be able to populate lots of window menubars when an application >>>>> has multiple windows. >>>>> >>>>> The actual manifestation of the menubar would be a control, but the >>>>> specification of what items are needed could be in an independent >>>>> format that doesn't bring in a whole new package. We could create >>>>> skeleton "menu-ish-bar-ish-item" classes in the application package >>>>> and those could be the data that the Menu* controls take, but one >>>>> could attach a list of those to an Application object without having >>>>> Application depend on controls. A Stage could then take an additional >>>>> list and combine it with the list on the Application to make the full >>>>> menu bar list which is then skinned by the controls. >>>>> >>>>> When no windows are open, then the Mac-specific application could >>>>> still skin them in a native skin and deploy them on the screen >>>>> menubar, or have a hidden dependency on the controls for that platform >>>>> only. >>>>> >>>>> That's a fairly loose conceptual hand-waving outline, but maybe it >>>>> could dislodge a more concrete design from someone more familiar with >>>>> how all of those objects interact? >>>>> >>>>> ...jim >>>>> >>>>> On 12/9/2011 3:46 PM, steve.x.northover at oracle.com wrote: >>>>> >>>>>> Many toolkits have supported portabilitly between Mac and Windows (and >>>>>> other operating systems that put the menu bar in the window) by >>>>>> swapping >>>>>> the menu bar on stage focus in and out. This is what SWT does. >>>>>> Recently, >>>>>> an app wide menu bar was added to support the Mac. >>>>>> >>>>>> Steve >>>>>> >>>>>> On 09/12/2011 6:34 PM, Tom Schindl wrote: >>>>>> >>>>>>> [...] >>>>>>> >>>>>>> >>>>>>>> Another place to specify a MenuBar would be on Stage, rather than >>>>>>>> (or in >>>>>>>> addition to), Application. Having a MenuBar property on Stage would >>>>>>>> allow for the MenuBar to change based on the currently focused Stage >>>>>>>> - >>>>>>>> but I'm not certain this is desirable or even the expected >>>>>>>> behaviour of >>>>>>>> Mac OS. Therefore, I'm thinking that this is not likely to happen >>>>>>>> unless >>>>>>>> we hear otherwise. >>>>>>>> >>>>>>> Well the menu changes definately based upon the focused top-level >>>>>>> window. So I'm quite sure the MenuBar has to be specified on the Stage >>>>>>> not? >>>>>>> >>>>>>> I'm wondering though how you'd like to support all the themeing stuff >>>>>>> one is able to apply on menus/menuitems on OS-X. >>>>>>> >>>>>>> IIRC I recently read in a mail from Mike Swingler that one can >>>>>>> implement >>>>>>> arbitary Java Drawing post-Leopard but I'm not sure that matches the >>>>>>> OS-X Menubar idea and all the fancy things one can do with JavaFX. >>>>>>> >>>>>>> Tom >>>>>>> -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From sven.reimers at gmail.com Sun Dec 11 06:17:30 2011 From: sven.reimers at gmail.com (Sven Reimers) Date: Sun, 11 Dec 2011 15:17:30 +0100 Subject: Supporting the Mac OS menubar in JavaFX In-Reply-To: <4EE34357.8020109@jugs.org> References: <4EE29218.4090305@oracle.com> <4EE29AF5.5010608@bestsolution.at> <4EE29DBB.6030706@oracle.com> <4EE2A574.9080709@oracle.com> <4EE2AA23.8060902@oracle.com> <8E8F7400-AAD1-4984-B7FD-C511482077B5@oracle.com> <4EE2CA26.6010108@oracle.com> <4EE34357.8020109@jugs.org> Message-ID: Hi, this may well be off topic, but Mac OS is not the only system using now a MenuBar at the top - Ubuntu does this as well in latest release. So is this effort only for Mac OS or should we take other systems into account as well? Thanks Sven On Sat, Dec 10, 2011 at 12:32 PM, Dr. Michael Paus wrote: > Hi, > I agree with Zonski that there is more to look at than just the menu bar. In > order > to get some ideas it might be interesting to look at what apple or others > recommend now for making Swing apps look more native on MacOS. > > A good introduction can be found here: > > > Going through this document you will see that there are more things that we > should > consider which go beyond the pure placement of the menu bar. > > Michael > > > Am 10.12.2011 05:46, schrieb Daniel Zwolenski: > >> Can I throw a few more bigger picture things into the murky puddle of OS >> menu bars and integration. I'm not saying these are all directly related >> to >> the problem at hand or even are things JFX should be solving, but I think >> floating them past the think tank in the context of this conversation is >> not an unhealthy thing to do: >> >> * In windows 7 (and possibly other versions, not sure), if I right click >> on >> the icon in the task bar it gives me an application-specific menu, which I >> think is not completely dissimilar in usage to the application-level Mac >> toolbar options (i.e. the ones that are left after you close all the >> windows). >> >> * Windows also has the 'system tray' thing for 'background-style' >> applications. Right-clicking on an icon in this brings up another menu >> that >> is application related. >> >> * OS variations are not the only issue. There is Applet vs Application to >> think about. This whole toolbar thing is only relevant in true desktop >> apps >> (as far as I can see) so Applets (even on Mac) need to have their rules >> defined. >> >> * iPhone/iPad and Android all have their own 'os' specific menu systems >> that are similar but not completely the same as the mac window. If the >> mobile support for JavaFX happens (please, please, please), then a menu >> API >> will be needed for this that doesn't look totally dissimilar to the mac >> one >> again. Over-future proofing can be a problem, but being generally aware of >> likely future directions can be healthy. In Android it is the 'options >> menu' http://developer.android.com/guide/topics/ui/menus.html and in >> iPhone/iPad it is the 'navigation toolbar' >> >> http://developer.apple.com/library/IOs/#featuredarticles/ViewControllerPGforiPhoneOS/NavigationControllers/NavigationControllers.html#//apple_ref/doc/uid/TP40007457-CH103-SW4 >> >> >> >> As I said, just food for thought rather than direct issues in need of >> solutions. >> >> >> On Sat, Dec 10, 2011 at 1:55 PM, Jim Graham >> ?wrote: >> >>> Could the classes be copied to javafx.application, the old classes made >>> into empty subclasses of the copies, and then the signatures on the >>> methods >>> that accepted them be relaxed to the supertype? ?(Possibly might have to >>> have duplicate methods if that isn't binary compatible?) >>> >>> ? ? ? ? ? ? ? ? ? ? ? ?...jim >>> >>> >>> On 12/9/2011 5:57 PM, Richard Bair wrote: >>> >>>> Ya, that's the bummer. We exactly designed the menus for the exact usage >>>> Jim describes, but didn't put them in a suitable package for >>>> modularization. Drat!!! >>>> >>>> On Dec 9, 2011, at 4:38 PM, Jonathan Giles wrote: >>>> >>>> ?Just as a further data point to what Jim is saying: the >>>>> >>>>> javafx.scene.control.Menu* classes (MenuItem, and subclasses Menu, >>>>> RadioMenuItem, CheckMenuItem, CustomMenuItem and SeparatorMenuItem) are >>>>> not >>>>> actually Controls. The only Menu* class that is a Control is MenuBar. >>>>> >>>>> ?From this perspective, it is actually unfortunate that these >>>>> non-Control classes actually live in javafx-ui-control, as they may be >>>>> totally suitable in the abstract sense that Jim discusses. >>>>> >>>>> -- >>>>> -- Jonathan >>>>> >>>>> >>>>> >>>>> On Saturday, 10 December 2011 10:19:00 a.m., Jim Graham wrote: >>>>> >>>>>> If this was simply a skinning technique of "moving the Stage's menubar >>>>>> to the screen's menubar" that works if you have a window open, but it >>>>>> doesn't solve the problem of what happens when you have no windows >>>>>> open when Mac applications typically still manifest menus in the >>>>>> screen menubar. >>>>>> >>>>>> Sticking a "separate but equal" menubar somewhere would lead to >>>>>> applications failing to look like native Mac apps until the developers >>>>>> are made aware of the issues and require "extra" coding to deal with >>>>>> Mac deployment. >>>>>> >>>>>> If we could provide a way to specify: >>>>>> >>>>>> - Here are the menubar items that apply to all windows. >>>>>> - Here are the additional menubar items that apply to a specific >>>>>> window. >>>>>> - To be most flexible, the "additional items" might have to be >>>>>> additional items in the top-level menus that were specified for all >>>>>> windows >>>>>> - Would there also be a need to specify "but not these items" for some >>>>>> windows to delete some items that only make sense when no windows are >>>>>> open? >>>>>> >>>>>> Then it would be both an API for letting the runtime know which >>>>>> menubar items should remain after the last window closes on Mac, and a >>>>>> way to be able to populate lots of window menubars when an application >>>>>> has multiple windows. >>>>>> >>>>>> The actual manifestation of the menubar would be a control, but the >>>>>> specification of what items are needed could be in an independent >>>>>> format that doesn't bring in a whole new package. We could create >>>>>> skeleton "menu-ish-bar-ish-item" classes in the application package >>>>>> and those could be the data that the Menu* controls take, but one >>>>>> could attach a list of those to an Application object without having >>>>>> Application depend on controls. A Stage could then take an additional >>>>>> list and combine it with the list on the Application to make the full >>>>>> menu bar list which is then skinned by the controls. >>>>>> >>>>>> When no windows are open, then the Mac-specific application could >>>>>> still skin them in a native skin and deploy them on the screen >>>>>> menubar, or have a hidden dependency on the controls for that platform >>>>>> only. >>>>>> >>>>>> That's a fairly loose conceptual hand-waving outline, but maybe it >>>>>> could dislodge a more concrete design from someone more familiar with >>>>>> how all of those objects interact? >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 12/9/2011 3:46 PM, steve.x.northover at oracle.com wrote: >>>>>> >>>>>>> Many toolkits have supported portabilitly between Mac and Windows >>>>>>> (and >>>>>>> other operating systems that put the menu bar in the window) by >>>>>>> swapping >>>>>>> the menu bar on stage focus in and out. This is what SWT does. >>>>>>> Recently, >>>>>>> an app wide menu bar was added to support the Mac. >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> On 09/12/2011 6:34 PM, Tom Schindl wrote: >>>>>>> >>>>>>>> [...] >>>>>>>> >>>>>>>> >>>>>>>>> Another place to specify a MenuBar would be on Stage, rather than >>>>>>>>> (or in >>>>>>>>> addition to), Application. Having a MenuBar property on Stage would >>>>>>>>> allow for the MenuBar to change based on the currently focused >>>>>>>>> Stage >>>>>>>>> - >>>>>>>>> but I'm not certain this is desirable or even the expected >>>>>>>>> behaviour of >>>>>>>>> Mac OS. Therefore, I'm thinking that this is not likely to happen >>>>>>>>> unless >>>>>>>>> we hear otherwise. >>>>>>>>> >>>>>>>> Well the menu changes definately based upon the focused top-level >>>>>>>> window. So I'm quite sure the MenuBar has to be specified on the >>>>>>>> Stage >>>>>>>> not? >>>>>>>> >>>>>>>> I'm wondering though how you'd like to support all the themeing >>>>>>>> stuff >>>>>>>> one is able to apply on menus/menuitems on OS-X. >>>>>>>> >>>>>>>> IIRC I recently read in a mail from Mike Swingler that one can >>>>>>>> implement >>>>>>>> arbitary Java Drawing post-Leopard but I'm not sure that matches the >>>>>>>> OS-X Menubar idea and all the fancy things one can do with JavaFX. >>>>>>>> >>>>>>>> Tom >>>>>>>> > > > -- > -------------------------------------------------------------------------------------- > Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). > For more information visit www.jugs.de. > -- Sven Reimers * Senior System Engineer and Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * Community Leader? NetBeans: http://community.java.net/netbeans ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 ? ? ? ? ? ? ? ? ?? http://www.linkedin.com/groups?gid=107402 ? ? ? ? ? ? ? ? ?? http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From jonathan.giles at oracle.com Sun Dec 11 16:33:04 2011 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 12 Dec 2011 10:33:04 +1000 Subject: Supporting the Mac OS menubar in JavaFX In-Reply-To: <4EE34357.8020109@jugs.org> References: <4EE29218.4090305@oracle.com> <4EE29AF5.5010608@bestsolution.at> <4EE29DBB.6030706@oracle.com> <4EE2A574.9080709@oracle.com> <4EE2AA23.8060902@oracle.com> <8E8F7400-AAD1-4984-B7FD-C511482077B5@oracle.com> <4EE2CA26.6010108@oracle.com> <4EE34357.8020109@jugs.org> Message-ID: <4EE54BC0.7010606@oracle.com> @Zonski, @Michael, @Sven: I agree that there are a number of places where integration with the operating system can be stronger. I'm also very keen to see these areas improved upon. As is always the case, if you don't see the features you've mentioned in our Jira tracker, I highly recommend that you go ahead and file these feature requests. For JavaFX 2.1, which is already fairly far into development, the goal is just to have Mac OS menubar integration. As you can imagine there is a lot of work exposing this native integration in API - it requires work down the entire JavaFX stack. This is being developed for 2.1 directly based on feedback from consumers of the JavaFX 2.0 API. Future releases will certainly take into account feedback you provide in much the same way (so please get it into Jira!!) :-) The main information I'm after right now is the implications of the decisions we make now with regard to native Mac OS menubar support. From where I'm sitting, I can't see anything we will come to regret in 2.2 and future releases. The same API can be used in a future Ubuntu scenario, and entirely different API will need to be developed for features such as system tray support and Windows 7 task list support. I don't get any feeling of concern about regretting this general approach....am I missing anything? -- Jonathan On 10/12/2011 9:32 p.m., Dr. Michael Paus wrote: > Hi, > I agree with Zonski that there is more to look at than just the menu > bar. In order > to get some ideas it might be interesting to look at what apple or others > recommend now for making Swing apps look more native on MacOS. > > A good introduction can be found here: > > > > Going through this document you will see that there are more things > that we should > consider which go beyond the pure placement of the menu bar. > > Michael > > > Am 10.12.2011 05:46, schrieb Daniel Zwolenski: >> Can I throw a few more bigger picture things into the murky puddle of OS >> menu bars and integration. I'm not saying these are all directly >> related to >> the problem at hand or even are things JFX should be solving, but I >> think >> floating them past the think tank in the context of this conversation is >> not an unhealthy thing to do: >> >> * In windows 7 (and possibly other versions, not sure), if I right >> click on >> the icon in the task bar it gives me an application-specific menu, >> which I >> think is not completely dissimilar in usage to the application-level Mac >> toolbar options (i.e. the ones that are left after you close all the >> windows). >> >> * Windows also has the 'system tray' thing for 'background-style' >> applications. Right-clicking on an icon in this brings up another >> menu that >> is application related. >> >> * OS variations are not the only issue. There is Applet vs >> Application to >> think about. This whole toolbar thing is only relevant in true >> desktop apps >> (as far as I can see) so Applets (even on Mac) need to have their rules >> defined. >> >> * iPhone/iPad and Android all have their own 'os' specific menu systems >> that are similar but not completely the same as the mac window. If the >> mobile support for JavaFX happens (please, please, please), then a >> menu API >> will be needed for this that doesn't look totally dissimilar to the >> mac one >> again. Over-future proofing can be a problem, but being generally >> aware of >> likely future directions can be healthy. In Android it is the 'options >> menu' http://developer.android.com/guide/topics/ui/menus.html and in >> iPhone/iPad it is the 'navigation toolbar' >> http://developer.apple.com/library/IOs/#featuredarticles/ViewControllerPGforiPhoneOS/NavigationControllers/NavigationControllers.html#//apple_ref/doc/uid/TP40007457-CH103-SW4 >> >> >> >> >> As I said, just food for thought rather than direct issues in need of >> solutions. >> >> >> On Sat, Dec 10, 2011 at 1:55 PM, Jim Graham >> wrote: >> >>> Could the classes be copied to javafx.application, the old classes made >>> into empty subclasses of the copies, and then the signatures on the >>> methods >>> that accepted them be relaxed to the supertype? (Possibly might >>> have to >>> have duplicate methods if that isn't binary compatible?) >>> >>> ...jim >>> >>> >>> On 12/9/2011 5:57 PM, Richard Bair wrote: >>> >>>> Ya, that's the bummer. We exactly designed the menus for the exact >>>> usage >>>> Jim describes, but didn't put them in a suitable package for >>>> modularization. Drat!!! >>>> >>>> On Dec 9, 2011, at 4:38 PM, Jonathan Giles wrote: >>>> >>>> Just as a further data point to what Jim is saying: the >>>>> javafx.scene.control.Menu* classes (MenuItem, and subclasses Menu, >>>>> RadioMenuItem, CheckMenuItem, CustomMenuItem and >>>>> SeparatorMenuItem) are not >>>>> actually Controls. The only Menu* class that is a Control is MenuBar. >>>>> >>>>> From this perspective, it is actually unfortunate that these >>>>> non-Control classes actually live in javafx-ui-control, as they >>>>> may be >>>>> totally suitable in the abstract sense that Jim discusses. >>>>> >>>>> -- >>>>> -- Jonathan >>>>> >>>>> >>>>> >>>>> On Saturday, 10 December 2011 10:19:00 a.m., Jim Graham wrote: >>>>> >>>>>> If this was simply a skinning technique of "moving the Stage's >>>>>> menubar >>>>>> to the screen's menubar" that works if you have a window open, >>>>>> but it >>>>>> doesn't solve the problem of what happens when you have no windows >>>>>> open when Mac applications typically still manifest menus in the >>>>>> screen menubar. >>>>>> >>>>>> Sticking a "separate but equal" menubar somewhere would lead to >>>>>> applications failing to look like native Mac apps until the >>>>>> developers >>>>>> are made aware of the issues and require "extra" coding to deal with >>>>>> Mac deployment. >>>>>> >>>>>> If we could provide a way to specify: >>>>>> >>>>>> - Here are the menubar items that apply to all windows. >>>>>> - Here are the additional menubar items that apply to a specific >>>>>> window. >>>>>> - To be most flexible, the "additional items" might have to be >>>>>> additional items in the top-level menus that were specified for all >>>>>> windows >>>>>> - Would there also be a need to specify "but not these items" for >>>>>> some >>>>>> windows to delete some items that only make sense when no windows >>>>>> are >>>>>> open? >>>>>> >>>>>> Then it would be both an API for letting the runtime know which >>>>>> menubar items should remain after the last window closes on Mac, >>>>>> and a >>>>>> way to be able to populate lots of window menubars when an >>>>>> application >>>>>> has multiple windows. >>>>>> >>>>>> The actual manifestation of the menubar would be a control, but the >>>>>> specification of what items are needed could be in an independent >>>>>> format that doesn't bring in a whole new package. We could create >>>>>> skeleton "menu-ish-bar-ish-item" classes in the application package >>>>>> and those could be the data that the Menu* controls take, but one >>>>>> could attach a list of those to an Application object without having >>>>>> Application depend on controls. A Stage could then take an >>>>>> additional >>>>>> list and combine it with the list on the Application to make the >>>>>> full >>>>>> menu bar list which is then skinned by the controls. >>>>>> >>>>>> When no windows are open, then the Mac-specific application could >>>>>> still skin them in a native skin and deploy them on the screen >>>>>> menubar, or have a hidden dependency on the controls for that >>>>>> platform >>>>>> only. >>>>>> >>>>>> That's a fairly loose conceptual hand-waving outline, but maybe it >>>>>> could dislodge a more concrete design from someone more familiar >>>>>> with >>>>>> how all of those objects interact? >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 12/9/2011 3:46 PM, steve.x.northover at oracle.com wrote: >>>>>> >>>>>>> Many toolkits have supported portabilitly between Mac and >>>>>>> Windows (and >>>>>>> other operating systems that put the menu bar in the window) by >>>>>>> swapping >>>>>>> the menu bar on stage focus in and out. This is what SWT does. >>>>>>> Recently, >>>>>>> an app wide menu bar was added to support the Mac. >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> On 09/12/2011 6:34 PM, Tom Schindl wrote: >>>>>>> >>>>>>>> [...] >>>>>>>> >>>>>>>> >>>>>>>>> Another place to specify a MenuBar would be on Stage, rather than >>>>>>>>> (or in >>>>>>>>> addition to), Application. Having a MenuBar property on Stage >>>>>>>>> would >>>>>>>>> allow for the MenuBar to change based on the currently focused >>>>>>>>> Stage >>>>>>>>> - >>>>>>>>> but I'm not certain this is desirable or even the expected >>>>>>>>> behaviour of >>>>>>>>> Mac OS. Therefore, I'm thinking that this is not likely to happen >>>>>>>>> unless >>>>>>>>> we hear otherwise. >>>>>>>>> >>>>>>>> Well the menu changes definately based upon the focused top-level >>>>>>>> window. So I'm quite sure the MenuBar has to be specified on >>>>>>>> the Stage >>>>>>>> not? >>>>>>>> >>>>>>>> I'm wondering though how you'd like to support all the themeing >>>>>>>> stuff >>>>>>>> one is able to apply on menus/menuitems on OS-X. >>>>>>>> >>>>>>>> IIRC I recently read in a mail from Mike Swingler that one can >>>>>>>> implement >>>>>>>> arbitary Java Drawing post-Leopard but I'm not sure that >>>>>>>> matches the >>>>>>>> OS-X Menubar idea and all the fancy things one can do with JavaFX. >>>>>>>> >>>>>>>> Tom >>>>>>>> > > From zonski at googlemail.com Sun Dec 11 17:45:53 2011 From: zonski at googlemail.com (Daniel Zwolenski) Date: Mon, 12 Dec 2011 12:45:53 +1100 Subject: Supporting the Mac OS menubar in JavaFX In-Reply-To: <4EE54BC0.7010606@oracle.com> References: <4EE29218.4090305@oracle.com> <4EE29AF5.5010608@bestsolution.at> <4EE29DBB.6030706@oracle.com> <4EE2A574.9080709@oracle.com> <4EE2AA23.8060902@oracle.com> <8E8F7400-AAD1-4984-B7FD-C511482077B5@oracle.com> <4EE2CA26.6010108@oracle.com> <4EE34357.8020109@jugs.org> <4EE54BC0.7010606@oracle.com> Message-ID: > > The main information I'm after right now is the implications of the > decisions we make now with regard to native Mac OS menubar support. From > where I'm sitting, I can't see anything we will come to regret in 2.2 and > future releases. The same API can be used in a future Ubuntu scenario, and > entirely different API will need to be developed for features such as > system tray support and Windows 7 task list support. I don't get any > feeling of concern about regretting this general approach....am I missing > anything? I guess one of my points was that I suspect there is a high chance the *same API* would likely want to be used for Win7 task list support, a medium chance it would be used for Windows 7 system tray support, and a medium chance it would be used for the future Android and iPhone menus. I don't see anything obvious in your proposal (looking at it from a very high level), that would stop this though. I like the idea of Application having a single Menu associated with it for the application. If a Stage feels the need to customise the Menu items to be specific to it, it can just get hold of that menu and manipulate the contents to match it - onBroughtToFront it would add its custom items, onNoLongerInFront it would remove those items (I don't think we have z-layer change callbacks on Window yet though?). This same mechanism would allow menus to change not just on the stage that is visible but on custom app logic (e.g. a Person is selected show the Person options). This will probably be controversial but I personally think we will run ourselves into trouble if we say that this Application menu bar is the one that appears on the top of a Stage for non-Mac OS systems. The whole File|Edit|Help menu bar thing is a slowly dying concept on Windows (look at Chrome, IE, Windows Explorer, MS Office 2008, etc), and in the cases where it does still exist, the location is not standard between applications. I personally think that on non-Mac OS's the Application menu is *not* the traditional top-level Stage menu bar thing. At best it more closely fits with the right-click Task bar menu and/por the system tray (there's no other way to have menus available when all the windows are closed). Either that or it is a concept that just doesn't get mapped to the other OS's with your original option that it is just totally ignored. For me I don't see it as a good idea to have JFX show the application menu bar at the top of the scene on windows, etc. If people want to add traditional menu bars to their stages they can use the normal mechanism of adding a MenuBar to the top of their scene's root (and then define custom CSS to hide it or style it on Mac, etc). I don't reckon they should do this though - they should look at modern GUIs and do something more nouveau-contemporary-funk that then works just as well on Windows as it does on Mac. My 2 cents, and based on market trends probably worth less than that by it time it gets to you :) From igor.nekrestyanov at oracle.com Tue Dec 6 13:04:42 2011 From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov) Date: Tue, 06 Dec 2011 13:04:42 -0800 Subject: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls. In-Reply-To: References: <20111206182834.BE46A475A5@hg.openjdk.java.net> <4EDE6C28.1060301@tbee.org> <4EDE745E.30306@tbee.org> Message-ID: <4EDE836A.8060608@oracle.com> On 12/6/11 12:39 PM, Richard Bair wrote: >>> We use Ant for all the builds, although there is some concern about how we'll go about doing things when we get integrated into the JDK (where they use make... yikes!). We use a little make as well for building the native parts (media, webkit, glass). >> Basically you're building one big monolitic jar. From a startup speed perspective that may not be the best choice. > I'm not sure of the current numbers, but I know that previously we did comparisons and the monolithic jar was faster at startup (and smaller at download since we pack200 the whole thing), but that analysis may have been with WebStart (since that is how the 1.x platform shipped), and not with the installer variety. Igor do you know? yes, for webstart based deployment single jar is clearly superior from the startup standpoint. I am not sure that splitting into multiple jars helps startup much unless a lot of these jars are not used. You mostly save on reading fewer data from zip directory but reading multiple files may be more expensive as you do not benefit from disk prefetching. I am not sure what is current size of zip directory for jfxrt.jar but it is likely to be couple of hundreds Kb i think. -igor > >> Is the JDK modularization (Jigsaw) going to influence your structure? > Definitely. From a project perspective I think we're more or less there (ie: our source "modules" already exist and are fairly well decoupled and so forth), so when Java 8 modularity is far enough along and we're past 2.2 and working on 3.0 we'll start using Java 8 modularity. > >> I think there are people enough who can, and would be willing to, help out with Maven / OSGi modularisation (since we know diddly about Jigsaw, I can't comment on that). > That would be good! > > Richard From stardrive.engineering at gmail.com Wed Dec 7 18:37:24 2011 From: stardrive.engineering at gmail.com (Stardrive Engineering) Date: Wed, 7 Dec 2011 20:37:24 -0600 Subject: JavaFX Desktop deployment (offshoot from: JavaFX Maven support) In-Reply-To: References: Message-ID: <7E7C5647-9744-4B8F-89FE-03DB93CD12E8@gmail.com> Very much love the very hard but powerful feature you describe. I would extend that a bit further if possible to include the following. Lets say we have an app to create drawings, then that this app can publish those drawings as HTML5/SVG web pages. Then as web users discover the published web pages via the built in meta-tags the users can simply click on a button on the web page to auto download the drawing (which is referenced by the web page and published to a the same host or even linked to lets say a Lucene/Solr index somewhere). Then if the clicking user does not have the drawing app it is first auto downloaded then the running app auto loads the drawing. If the user does not have JavaFX it first installs that then the app then loads the drawing. Consider the published drawing to be an advanced form of landing pages. So, if the maker of the drawing app wanted to publish 1000 cool drawings with different meta-tags each they would have 1000 web agents at their service serving them very well. Another consideration for the optimal smart installer (that JavaFX can then use to dominate the world :-) would be licensing. Having optional hooks to build in something like the Nalpeiron solution would be very nice. See http://www.nalpeiron.com Stardrive On 2011-12-07, at 5:50 PM, Daniel Zwolenski wrote: > Thanks for the in-depth info Igor. The pieces of the puzzle are starting to > become clear to me, sorry it takes my head a while to get in gear :) > > I've renamed the thread (again) to reflect the direction this conversation > is taking. I think the Maven conversation is now separate and should be > continued off on its own. If this thread is not a correct conversation for > this forum, please let me know and I can take it to the forums, or wherever > you think it should belong. > > Summing up: the deployment complexities seem to be mostly centered around > embedding JFX within a Browser, which makes a lot of sense (it's fairly > amazing this can be achieved at all). Additionally there are some > challenges with maintaining a 'current' JFX install and auto-updating this > when new releases are made. The focus of the install+plugin is mostly in > solving these two issues. > > The reason I was simplifying the deployment in my head is because the two > issues are not features that I use in my deployment. The end result being > that I am having to jump hurdles that don't make sense in my scenario. > > My apps are mostly desktop business apps, often used in the 'back-office'. > It is rare for me to use Applets or have a need to embed my application in > a Browser. I also often don't want auto-updates of JFX (or the JRE for that > matter) as there is often corporate policy/control over this, which > mandates installation privileges and tries to ensure all desktops in the > organisation are running the same version of things, etc. The sys admins > would want to know about and control any updates, especially security > holes. > > Perhaps the end result is that the current webstart deployment mechanism is > not actually for pure desktop apps, and we instead need to look at an > alternate mechanism like the ones you have suggested. What desktop app > developers really need is something like a (free) InstallShield for JavaFX, > that also includes automatic updates. For desktop apps, the web is a > distribution mechanism, not the application platform/runtime. > > As a thought-experiment I've tried to come up with the perfect deployment > user experience for a pure desktop app, ignoring the fact that applets even > exist. It would be nice to work backwards from this to see what can be > achieved, whether it is a case of updating the deployment tools, creating > new ones in JFX, or this feature being left to third-party tools (like Java > installshield, but it is currently not in a good state). > > *Background* > > Lisa is a business user at ACME mining, responsible for determining its > carbon footprint in order to reduce greenhouse gas emissions. Lisa has just > learnt of a new product called FootprintFX, a desktop application for > calculating carbon footprints, built in JavaFX. Lisa is a Windows 7 user > with basic technical skills. She has no Java installed on her machine and > has no idea what Java or JavaFX really are. > > *Installation steps* > > 1. Using her favourite web browser and google, Lisa finds the home page > for FootprintFX and clicks the 'download for Windows7 now' button > 2. The browser downloads an exe to Lisa's computer, which she then runs > 3. Windows security pops up a message (as it likes to do) saying "do you > want to let this program make changes". Lisa hits yes. > 4. The executable detects that Java is not installed. It shows a screen > asking the user if they would like to install it and the directory to > install to. Lisa leaves it at the default directory (c:\Program Files\java) > 5. The executable shows a combined T&C for using Java, JavaFX. Lisa does > the usual - ticks 'I agree' without reading it and hits 'next' > 6. The executable installs Java and JavaFX to the location specified > (JFX is installed in the same directory as the JRE). Lisa just sees a > single progress bar for all this, with no dialogs popping up, etc. > 7. Once Java and JFX are installed the system then asks Lisa where to > install FootprintFX and whether she wants a Start Menu and Desktop link. > Lisa leaves it at the default settings (c:/Program Files/FootprintFX) > 8. The install is complete (an icon has been added to the Start Menu and > Desktop - as per Lisa's selection) and Lisa has the option to 'Run Now' > > *Running * > > > > 1. Lisa clicks the desktop shortcut or start menu link > 2. The application shows the custom splash screen for FootprintFX while > behind the scenes Java is loading and the FootprintFX main window is being > created. > 3. On startup a check is made back to the FootprintFX for any updates. > If an update is found, Lisa is given the option to update to this new > version automatically. If Lisa clicks yes, then the new jars/resources are > downloaded and the JVM is restarted with the new details. > 4. Once the latest code has been loaded, the splash screen is hidden and > the application is run. Although the jars are not signed, the application > has all permissions (i.e. no sandbox). > > *Variations and comments: * > > - If the user already has Java and/or JavaFX installed the installer > should just use these and skip this whole step. > - If the user has Java installed but not JavaFX, the step should just be > the install of this > - If the user has an older version of these, it should give the user the > option to upgrade the current install, or install a seperate version > - Auto updates (of Java, JFX and/or the app) should be configurable by > the creator of the installation package > - The installer should be able to map file types to the installed > Application - i.e. I should be able to make files of type .cfp (carbon > footprint) get directed directly to FootprintFX. > > There is one very hard feature but very powerful feature that would be > awesome to have. It would be incredibly useful to be able to have something > like an 'application url', where we can embed this url inside an email or > web page, and when a user clicks on it, it opens the local desktop > application but passes in parameters to it. This is the same idea (and > would be used in the same way) as web browser URLs, which launch the local > web browser and pass an address to it. > > Being able to embed a link in an email to a page on the web has been > incredibly useful for web apps. Being able to embed a link in an email to a > 'place' within an application (e.g. open FootprintFX and point it to the > 'flights calculation page' with flight details prepoluated) would be > amazing. > > I don't know how this would be achieved however. The only way I can think > of is to use a URL that opens a web page that then triggers the launcher to > be run passing in parameters, i.e. hijack the browser way of doing it and > then hook in a Java trigger. Not ideal, but otherwise both the operating > system and the email browsers (and web browsers) would need to support an > 'application URL' and I'm not sure that's achievable. Something like this > would be the place to start looking I guess: > http://msdn.microsoft.com/en-us/library/aa767914(v=vs.85).aspx Each OS > would do this differently if it does it at all. > > > Interested in hearing a variety of thoughts on this topic. What do other > people see as the key deployment issues/models/options for JavaFX? > > > > On Wed, Dec 7, 2011 at 5:56 PM, Igor Nekrestyanov < > igor.nekrestyanov at oracle.com> wrote: > >> Hi, >> >> >> To be able to launch JavaFX application embedded in the browser or using >> >>> Webstart we need to have JavaFX aware plugin/deployment stack to be >>>> registered in the browser. >>>> >>>> The plugin to run Java makes sense, and this has been around for a while >>> now. Improving it is nice, but this should be done back in the core JRE >>> area I would have thought? It's the 'install' of JavaFX that I am confused >>> about. I'm possibly over simplifying things but if JavaFX is just a jar >>> and >>> some native DLLs then isn't it just another library that gets added to the >>> classpath like everything else? >>> >> No, unfortunately it is not that simple. >> >> First of all plugin and webstart code used to be inherently Swing/AWT >> based. >> To get most of JavaFX (at least performance wise) you do not want to run >> it in the heavyweight AWT container or load Swing/AWT classes. >> >> Browser integration is not that simple if you want to use hardware >> acceleration in browser window. >> There is special code in JavaFX to attach stage to window handle provided >> by the browser. >> >> Obviously Java plugin in JRE6 has no idea of JavaFX existence as it was >> implemented years before it. >> Hence to be able to support users who stuck with JRE6 and can not switch >> to latest JRE7 (or 8) we >> are shipping updated copy of deployment with JavaFX. >> >> JavaFX-specific changes are merged back into JRE source base. E.g. JRE7 >> update 2 has (almost) the same deployment stack as JavaFX 2.0.2. >> But deployment code need to be in sync with JavaFX code and dependencies >> are tight. So, as we march to support new platforms (Mac/Linux) >> source bases will again be different for some more time. >> >> Eventually JRE will include full JavaFX capable plugin and there will be >> no need to include it into JavaFX (assuming most of the users will migrate >> to >> new version of JRE). But this likely will take time. >> >> >>> Ideally installing the plugin(s) really needs to be simple (1 or 2 click >> install). Currently the Java one takes me off to another page and makes me >> jump through a lot more hoops and then the > JFX one has another go at me. >> It would be great if we could work out ways to avoid these hoops. Maybe the >> co-bundling will fix all this, but it would be nice to just streamline >> everything as >>> soon as possible. >> >> Cobundling should improve things a little but in general i agree user >> experience could be improved. >> We would be happy to hear about possible ideas of how to improve the >> process (and yet satisfy legal requirements such as accepting the license). >> >> >>> We also assume that JavaFX runtime is shared install per system (or >> >>> eventually per user) and then we want to be able to keep track of what >>>> users have installed/use and autoupdate it when important updates are >>>> available (e.g. security). >>>> >>>> This is a risky approach, especially for developers. I often have >>> multiple >>> JDKs and JVMs installed on my machine which means I need the correct JFX >>> install in each. >>> >> There is a difference between developer who needs SDK to build app and >> user who only needs runtime to run app. >> We are not autoupdating SDK as it can not be used by attacker. >> Like with JDK you may still have multiple JavaFX SDK installed (at least i >> do not see why not). >> >> Runtime is different. Whenever you open web page with javafx application >> it will be launched using installed runtime. >> And if this runtime is vulnerable then user is in trouble. Keeping it up >> to data and secure is important. >> >> If you really need to test with older version of runtime then you can >> install it and decline offers to autoupdate it. >> >> >>> I currently have a system where it thinks I don't have JFX installed but >> I do, but not in the JRE the browser is using, but the deployment tool >> won't let me install it because it thinks I have it >>> already installed. In fact each of the computers I use (3 of them) seem >> to do something slightly different when I try to run an applet and >> something different again when I run a webstart app > (and rarely do they >> work, and never with any real message on why they failed). >> >> Sorry to hear that. >> Would you mind filing issues on this and providing us with trace/log files? >> >> >>> My best guess is that the multiple versions of stuff is confusing the >> deployer. I have 64 bit and 32 bit versions on my machine at the same time >> too, as some of the native libraries (e.g. finger print scanner) that I use >> need this. >> >> Well, in theory both plugin and webstart are supposed to use one "latest" >> version as it should supersede others. >> If you have both 32 and 64 bit versions then there are 2 "latest" versions >> and they are selected depending on whether your browser is 32 or 64 bit. >> (Most of the browsers are still 32 bit). >> >> Typical source of the issues right now is that JRE6 is not fully updated >> to be JavaFX aware and if JRE6 is installed/uninstalled/upgraded while >> JavaFX runtime is installed then it can corrupt registry. Also, before >> 2.0.2 installer had nasty bug and if JavaFX runtime was installed by one >> user then another user could neither install it nor use it i think. >> >> We are solving these issues as we learn about them. Please report bugs to >> JIRA and we will do our best to make it more robust. >> >> >>> When we have multiple versions of JFX out there, we will end up with >> JNLP files specifying specific specific versions to use (as we see now with >> Swing and JRE versions). If a jnlp file sepcifies an older version of JFX >> is required (i.e. I don't want my code to run on the latest because it >> causes me problems, etc), then what will the install tools do in this case? >> >> Current thinking is that we will only allow to specify minimal version >> assuming all JavaFX version in the same family are backward compatible. >> I.e. you can request 2.0.2+ but if user has 2.0.3 installed you can not >> request him to install 2.0.2. >> >> >>> What exactly are the security risks associated with JavaFX? How does >> this differ to say me using another display library like SWT or any toolkit >> like GWT, or hibernate, or spring. >> >> The biggest difference is that JavaFX will likely be preinstalled on large >> number of systems and shared between different applications. >> It does not come as private part of the application (by default). >> >> >>> We also use the fact that JavaFX runtime is installed to be able to >> autodetect runtime install path when standalone application is being >> launched >> >>> >>> Can you elaborate on why standalone apps would need this and how they can >>> work this out? The problem we have at the moment is exactly that the >>> standalone app can't find the installation path (and hence the native >>> files) without being told where it is via the system path, which is not >>> setup by the installer. I'd be interested to understand more about this >>> autodetect mechanism, how it is used currently, and how I might be able to >>> make use of it. >>> >> If you follow JavaFX application packaging guidelines (see deployment >> guide on javafx.com) then result application jar will contain small >> launcher program >> that will be used as default entry point (e.g. when you double click on >> jar) and it is capable of checking system requirements (e.g. presence of >> JRE) >> and detecting where JavaFX runtime is installed. Then it will setup >> classpath to include required.jars and instantiate main Application class. >> >> >> What is it >>> that JFX does above beyond what standard JRE/JNLP has been doing for a >>> while? >>> >> E.g. embedded launcher can check this without JNLP. >> I.e. you can ship just jar file and user will be guided how to run it as >> long as it has java. >> >> -igor >> >> From richard.bair at oracle.com Mon Dec 12 09:45:35 2011 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 12 Dec 2011 09:45:35 -0800 Subject: ImageView should have shorthand creation function In-Reply-To: <4EE13C10.2080709@ga2.so-net.ne.jp> References: <4EE07F98.5070207@oracle.com> <4EE13C10.2080709@ga2.so-net.ne.jp> Message-ID: <4FB19256-5A4E-4D0F-B63E-FF65D90DD789@oracle.com> I think that sounds good, Lubo lets go ahead with that option if you agree. Thanks Richard On Dec 8, 2011, at 2:37 PM, Tadashi Ohmura wrote: > Dear members of OpenFX > > I think that we need a shorthand creation function of ImageView. > > I agree with Option 1 > > Thanks > Tadashi Ohmura > > (2011/12/08 18:12), Lubomir Nerad wrote: >> Hi, >> >> I am looking at http://javafx-jira.kenai.com/browse/RT-6554. It requests to add a possibility to create image view and its image from url in one step. What I think should be discussed is whether to add this as a new constructor to the ImageView class or as a static factory method. >> >> So the options are: >> >> 1) public ImageView(String url) { ... } >> 2) public static ImageView image(String url) { ... } (or another name) >> >> Unless we expect that we will need more possibilities for image specification (more shorthand creation methods) in the future, I am leaning towards option 1. >> >> What do you think? >> >> Thanks, >> Lubo >> >> >> > From richard.bair at oracle.com Mon Dec 12 09:50:54 2011 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 12 Dec 2011 09:50:54 -0800 Subject: Bidirectional binding with conversion In-Reply-To: References: Message-ID: <519A4725-EA4F-4CFA-9B53-D9E8892E0E02@oracle.com> OK, so is this the design? ============================================================ The class javafx.beans.binding.Bindings will get three new methods: public static void bindBidirectional(Property stringProperty, Property otherProperty, Format format); public static void bindBidirectional(Property stringProperty, Property otherProperty, StringConverter converter); public static void unbindBidirectional(Object property1, Object property2); The class javafx.beans.property.StringProperty will also get three new methods: public void bindBidirectional(Property other, Format format); public void bindBidirectional(Property other, StringConverter converter); public void unbindBidirectional(Object other); If parsing the StringProperty fails, the other property will be set to the default value. If formatting the arbitraty property fails, the StringProperty will be set to the empty String. ============================================================ Sounds good to me! Richard (Hopefully I got the generics on the StringConverter variant correct) From kevin.rushforth at oracle.com Mon Dec 12 10:12:11 2011 From: kevin.rushforth at oracle.com (kevin.rushforth at oracle.com) Date: Mon, 12 Dec 2011 18:12:11 +0000 Subject: hg: openjfx/2.1/master/rt: 13 new changesets Message-ID: <20111212181213.BE1FC47676@hg.openjdk.java.net> Changeset: d06073f52116 Author: jgiles Date: 2011-12-08 18:03 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/d06073f52116 RT-18339: [ListView/TableView/TreeView] Editing index property changes, when Space press. ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: 1b515bf64da6 Author: jgiles Date: 2011-12-09 07:43 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/1b515bf64da6 RT-18430: [TableView] Lost focus in multi-cell selection mode ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java Changeset: 88dc0c2f404e Author: jgiles Date: 2011-12-09 08:07 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/88dc0c2f404e RT-18437: TableRow is incorrect height initially when default height is not desired ! javafx-ui-controls/src/javafx/scene/control/TableCell.java Changeset: a75cdc37b987 Author: jgiles Date: 2011-12-09 08:45 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/a75cdc37b987 RT-18441: TreeItem.equals() calls TreeItem.getChildren(), which is too expensive ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! javafx-ui-controls/src/javafx/scene/control/TreeItem.java Changeset: 8d6e25f7e160 Author: jgiles Date: 2011-12-09 15:13 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/8d6e25f7e160 RT-18442: Remove mostly redundant Runnable* and Function* classes ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PositionMapper.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/VirtualFlowTest.java Changeset: 2053e699ee06 Author: jgiles Date: 2011-12-09 15:16 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/2053e699ee06 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.1/scrum/controls/jfx/rt Changeset: 3ec084f7363e Author: jgiles Date: 2011-12-09 15:45 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/3ec084f7363e RT-14451: TableView: Shift-Home and Shift-End do not work as expected ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: 0d10aa415470 Author: jgiles Date: 2011-12-09 16:32 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/0d10aa415470 RT-18412: [ListView] Shift+end doesn't select the last element. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java Changeset: 78c10cd8a4f8 Author: jgiles Date: 2011-12-09 16:44 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/78c10cd8a4f8 RT-18416: [ListView] Shift+PageDown lose selection. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java Changeset: 0c5ec026b7ad Author: jgiles Date: 2011-12-09 16:53 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/0c5ec026b7ad RT-18413: [ListView] focused index is not proper, when shift+home pressed. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java Changeset: fbbfe5a37fa1 Author: leifs Date: 2011-12-09 13:23 -0800 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/fbbfe5a37fa1 RT-18455: TextField, TextArea: Incorrect MacOS key bindings ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java Changeset: d5ba659414cd Author: jgiles Date: 2011-12-12 16:22 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/d5ba659414cd RT-18344: TreeItem footprint increase (37% regression) in fx2.1-controls-scrum build b92 (b02) ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TreeItem.java Changeset: b094b6a7ca18 Author: jgiles Date: 2011-12-12 16:25 +1000 URL: http://hg.openjdk.java.net/openjfx/2.1/master/rt/rev/b094b6a7ca18 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.1/scrum/controls/jfx/rt From richard.bair at oracle.com Mon Dec 12 10:12:18 2011 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 12 Dec 2011 10:12:18 -0800 Subject: request for API change approval: ObservableSet In-Reply-To: <4EE1CF66.1010308@oracle.com> References: <4EDF7F83.2070909@oracle.com> <4EE07EAA.8060708@oracle.com> <4EE08E19.3090209@oracle.com> <4EE1CF66.1010308@oracle.com> Message-ID: Looks good to me! On Dec 9, 2011, at 1:05 AM, Martin Soch wrote: > OK, Jira is updated with the patch now. > JIRA: http://javafx-jira.kenai.com/browse/RT-14664 > > Thanks > Martin > > On 12/08/2011 08:52 PM, Richard Bair wrote: >> Cool. Can you create a new patch with the latest proposal and attach it to the JIRA issue? >> >> Thanks! >> Richard >> >> On Dec 8, 2011, at 2:14 AM, Martin Soch wrote: >> >>> Hi Richard, >>> >>> after discussion with Martin Sladecek he suggested to remove ObservableSetWrapper from public API so it will be consistent for now. >>> >>> Thanks >>> Martin >>> >>> On 12/08/2011 10:08 AM, Martin Soch wrote: >>>> Hi Richard, >>>> >>>> thanks for your comments. >>>> >>>> - public wrappers: Martin Sladecek is recently (in a separate request) >>>> moving wrapper classes to the javafx.collection package as well; I don't >>>> know the motivation behind but Michael Heinrichs (on CC) might know more >>>> - var-arg factory method: will add it unless anyone has any objections >>>> >>>> Thanks >>>> Martin >>>> >>>> On 12/07/2011 08:09 PM, Richard Bair wrote: >>>>> Hi Martin, >>>>> >>>>> Generally I would suggest that we move this conversation to the >>>>> openjfx-dev mailing list. I'm wanting to start moving as many of these >>>>> sorts of design approval requests there as we can. >>>>> >>>>> However, my first thoughts: >>>>> - Yay! >>>>> - Why is ObservableSetWrapper public? We don't have any other Wrappers >>>>> for the other collections public, do we? Are we sure we want to do >>>>> this now? >>>>> - I would suggest adding a var-args factory method to FXCollections >>>>> for creating a set, as well as a Collections version for convenience >>>>> >>>>> Otherwise looks consistent with our other Observable collections as >>>>> far as I can see. >>>>> >>>>> Thanks >>>>> Richard >>>>> >>>>> On Dec 7, 2011, at 7:00 AM, Martin Soch wrote: >>>>> >>>>>> Hi team, >>>>>> >>>>>> I would like to ask you for approval for a new API to be pushed to >>>>>> 2.1 repository. This new API is adding ObservableSet interface into >>>>>> javafx.collection package with basic wrapper implementation. This >>>>>> change is not modifying any current API; just adding new functionality. >>>>>> >>>>>> JIRA: http://javafx-jira.kenai.com/browse/RT-14664 >>>>>> WebRev: http://javame-linux.cz.oracle.com/r/1334/ >>>>>> >>>>>> Thanks >>>>>> Martin >>>>> >>>> >>> >> > From richard.bair at oracle.com Mon Dec 12 10:32:36 2011 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 12 Dec 2011 10:32:36 -0800 Subject: Controls with Values [was Possible additions to JavaFX to facilitate forms and validations] In-Reply-To: References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> <4EDE4972.8030205@broadpark.no> <67E8E7BD-24DB-4242-81FD-6C35389A7699@oracle.com> <4EDEA518.5090102@oracle.com> <4EDEB118.6010702@bestsolution.at> <4EDFB020.3060005@broadpark.no> <424E6A89-D6CD-4A71-87CE-98F14B66AA94@oracle.com> Message-ID: <3F758C91-05D1-404C-BA13-8371E3A23E79@oracle.com> On Dec 8, 2011, at 5:50 PM, Daniel Zwolenski wrote: > Can't I just do: > > PersonView { > WritableValue getFirstNameField(); > WritableValue getLastNameField(); > WritableValue getGenderField(); > } > > I should be able to do this today, and implement it trivially (the PersonViewImpl for getFirstNameField() would return textField.textProperty(), for example). I don't think it really adds an argument for HasValue itself, which still seems to be really only beneficial to tools and frameworks (which is still a good thing). > > Yea, nice, although WritableValue isn't observable and doesn't support binding. Doh! However if we had a Bindable interface (as Knut proposed on the Bidirectional binding thread) or just use Property instead of WritableValue, it would still work. The point being you don't need a HasValue for the PersonViewImpl interface to still decouple the view completely from the controller. Is that right? It still seems the primary benefit to a HasValue is in the framework code. As I see it, right now we have two leading ideas to solving this: - HasValue: an interface with a valueProperty() (and maybe getValue() and setValue() methods). Every control which "has a value" will implement this interface to delegate the "value property" to an existing property. For example TextField would delegate "value" to the "text" property. - Bindable: an interface. Basically "Property" but with a different name. Indeed, you would have Bindable implement everything in Property, and then have Property inherit from both ReadOnlyProperty and Bindable. The reasons I don't like HasValue: - We will for the first time define "aliased" properties in our API: the "value" property and the "text" property on TextField will be exactly the same property. This will complicate tooling (for example, Scene Builder) because it will either show both properties to the user who will wonder what the difference is, or it will only show one to the user and the user will be left wondering which they should use. Drat. - The "HasFoo" name is a new naming convention for JavaFX. Do we want to do this? It usually takes a pretty compelling argument to go down the road of a new naming convention (in fact, if we'd have just used "value" consistently everywhere: ListView.value instead of ListView.items, TextField.value instead of TextField.text, and so forth, then this would have been a much easier decision!) The reasons I don't like Bindable: - Complicates the already complex property inheritance matrix. Plus, there are other bind methods (like bindBidirectional(Property other, StringConverter sc)) that are on the specific property types rather than on the generic Property, and the generic Bindable couldn't use those. So it becomes less useful. I'm not too terribly bothered by the conceptual difference (a control has a property vs. a control is bindable). I think both concepts are equally valid and useful and it is just a matter of preference one way or the other. I wonder if there is some other solution to the problem? Could we instead use an annotation to indicate what property on a control is the "data model" for the control? Annotations are by far the easiest reflection API to use IMO, so it isn't unreasonable for tools to resort to annotations (in fact, toolability is one of the primary use cases for an annotation). So what about something like @ValueProperty in javafx.scene.control, and we can then apply it to whatever property on the control is to be considered the "value" of the control? > Also implementing it 'trivially' for a ChoiceBox is not quite true because of the whole selection model not being writable thing, but this is back to the ChoiceBox API debate, rather than the HasValue debate. Right. > There is another problem though, with a ChoiceBox the "value" is supposed to be limited strictly to those items contained in the selection list. It isn't a ComboBox -- there is no possibility to add custom items. Yet when you add a "value" property to ChoiceBox, as the ChoiceBox author, you have to accept that sometimes people will set something that isn't in the list. SO basically to make ChoiceBox usable with binding, we have to give up the invariant that the selected item is always one of the items in the list. Unavoidable it seems. > > I think the same argument on the value not being in the list applies to selectionModel.select(T), so whatever rules are being used there should carry over. > > Looks like Jonathan has already put something in place for the ComboBox free-type text issue. He's got a 'StringConverter' in there that maps the entered text to a 'value' (and there's a valueProperty already there for us). I haven't quite worked out what happens if the text doesn't map to a value but I'm guessing a null value in this case. > > *

Because a ComboBox can be {@link #editableProperty() editable}, and the > * default means of allowing user input is via a {@link TextField}, a > * {@link #converterProperty() string converter} property is provided to allow > * for developers to specify how to translate a users string into an object of > * type T, such that the {@link #valueProperty() value} property may contain it. > * By default the converter simply returns the String input as the user typed it, > * which therefore assumes that the type of the editable ComboBox is String. If > * a different type is specified and the ComboBox is to be editable, it is > * necessary to specify a custom {@link StringConverter}. I don't see an issue in JIRA about the ChoiceBox needing to support bidirectional binding -- is there one already I'm missing? I think we should break that out into a separate discussion from the HasValue proposal. I think we can discuss a solution and get a fix in for ChoiceBox independently. What do you think? Thanks Richard From richard.bair at oracle.com Mon Dec 12 11:03:25 2011 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 12 Dec 2011 11:03:25 -0800 Subject: Could FXML use an interface and dynamic proxy for the passive view interface? Message-ID: I was just reading through another excellent Zonski post (http://www.zenjava.com/2011/12/11/javafx-and-mvp-a-smorgasbord-of-design-patterns/). I actually have never liked the idea that a GUI tool had to compromise best-practices for development (in fact, it seems that a good GUI tool would encourage and promote best practices), so the following got my attention: ================================================ So if FXML provides the controls and visual layout for our screen it is obviously a prime candidate for replacing the Java-based View?s we?ve defined in our previous options. This is good news, but it?s not all roses however. FXML has been designed with RAD tooling in mind (i.e. visual screen design tools), and seems to draw from backgrounds that are a little less rigorous in their design patterns than Java normally encourages. As a result there are a number of areas where using FXML forces us to compromise on our pure MVP pattern. Here?s a few of them: ? You have to specify your presenter (which FXML directly calls a controller) implementation inside your FXML. This breaks a fundamental concept of MVP, that the view and presenter should be decoupled as much as possible, and means you cannot reuse your view with another controller without copying the whole view again. ? You can?t use interfaces for your presenter (as per option 2 above), since FXML needs a concrete class to instantiate. ? The FXML loader instantiates the controller in internal code that we have no access to, so to make this work with a DI framework you have to jump through hoops to get setter injection to work (and constructor injection doesn?t work at all). ? In order to access the fields of your view within your presenter (i.e. to show data on the screen), you have to expose the fields directly to the presenter using @FXML annotations. This means your presenter ends up knowing far too much intimate detail about your view. ================================================ Which got me thinking. Can't we have FXMLLoader use dynamic proxies to allow the FXML file to refer to a passive view interface rather than a concrete controller implementation? That at least would allow for the "Passive View" design pattern to apply extremely cleanly. It still would mean, from the developer's perspective, 2 classes instead of 1 (an interface for the view and a controller which talks to that interface). I would have to think through this a little more (I guess the controller is still required, so that the FXML document has something to call for event handlers and such, but that the controller would only talk to the view via this Passive View interface rather than by grabbing nodes and binding things directly??) Richard From tom.schindl at bestsolution.at Mon Dec 12 11:27:24 2011 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 12 Dec 2011 20:27:24 +0100 Subject: Could FXML use an interface and dynamic proxy for the passive view interface? In-Reply-To: References: Message-ID: <4EE6559C.9010405@bestsolution.at> Am 12.12.11 20:03, schrieb Richard Bair: > I was just reading through another excellent Zonski post (http://www.zenjava.com/2011/12/11/javafx-and-mvp-a-smorgasbord-of-design-patterns/). I actually have never liked the idea that a GUI tool had to compromise best-practices for development (in fact, it seems that a good GUI tool would encourage and promote best practices), so the following got my attention: > > ================================================ > > So if FXML provides the controls and visual layout for our screen it is obviously a prime candidate for replacing the Java-based View?s we?ve defined in our previous options. This is good news, but it?s not all roses however. FXML has been designed with RAD tooling in mind (i.e. visual screen design tools), and seems to draw from backgrounds that are a little less rigorous in their design patterns than Java normally encourages. > > As a result there are a number of areas where using FXML forces us to compromise on our pure MVP pattern. Here?s a few of them: > > ? You have to specify your presenter (which FXML directly calls a controller) implementation inside your FXML. This breaks a fundamental concept of MVP, that the view and presenter should be decoupled as much as possible, and means you cannot reuse your view with another controller without copying the whole view again. > ? You can?t use interfaces for your presenter (as per option 2 above), since FXML needs a concrete class to instantiate. > ? The FXML loader instantiates the controller in internal code that we have no access to, so to make this work with a DI framework you have to jump through hoops to get setter injection to work (and constructor injection doesn?t work at all). In 2.1 with http://javafx-jira.kenai.com/browse/RT-17268 this is not true any more you can pass a factory which knows how to create the controller instance. > ? In order to access the fields of your view within your presenter (i.e. to show data on the screen), you have to expose the fields directly to the presenter using @FXML annotations. This means your presenter ends up knowing far too much intimate detail about your view. > > ================================================ > > Which got me thinking. Can't we have FXMLLoader use dynamic proxies to allow the FXML file to refer to a passive view interface rather than a concrete controller implementation? That at least would allow for the "Passive View" design pattern to apply extremely cleanly. It still would mean, from the developer's perspective, 2 classes instead of 1 (an interface for the view and a controller which talks to that interface). I would have to think through this a little more (I guess the controller is still required, so that the FXML document has something to call for event handlers and such, but that the controller would only talk to the view via this Passive View interface rather than by grabbing nodes and binding things directly??) > See RT-17268 did I get you wrong? 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 roman at kennke.org Mon Dec 12 11:28:58 2011 From: roman at kennke.org (Roman Kennke) Date: Mon, 12 Dec 2011 20:28:58 +0100 Subject: Could FXML use an interface and dynamic proxy for the passive view interface? In-Reply-To: References: Message-ID: <1323718138.3003.31.camel@moonlight> Hi Richard, > Which got me thinking. Can't we have FXMLLoader use dynamic proxies to allow the FXML file to refer to a passive view interface rather than a concrete controller implementation? That at least would allow for the "Passive View" design pattern to apply extremely cleanly. It still would mean, from the developer's perspective, 2 classes instead of 1 (an interface for the view and a controller which talks to that interface). I would have to think through this a little more (I guess the controller is still required, so that the FXML document has something to call for event handlers and such, but that the controller would only talk to the view via this Passive View interface rather than by grabbing nodes and binding things directly??) Yeah I am thinking the same. The FXML should generate a class that implements an interface that would need to be defined by the developer. I think it's fine (and actually clean/best practice) to require a passive view interface in addition to the presenter class. Regards, Roman From richard.bair at oracle.com Mon Dec 12 11:39:03 2011 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 12 Dec 2011 11:39:03 -0800 Subject: Could FXML use an interface and dynamic proxy for the passive view interface? In-Reply-To: <4EE6559C.9010405@bestsolution.at> References: <4EE6559C.9010405@bestsolution.at> Message-ID: <16239202-4EEF-49C1-8DD4-71C82DF5CBA4@oracle.com> >> Which got me thinking. Can't we have FXMLLoader use dynamic proxies to allow the FXML file to refer to a passive view interface rather than a concrete controller implementation? That at least would allow for the "Passive View" design pattern to apply extremely cleanly. It still would mean, from the developer's perspective, 2 classes instead of 1 (an interface for the view and a controller which talks to that interface). I would have to think through this a little more (I guess the controller is still required, so that the FXML document has something to call for event handlers and such, but that the controller would only talk to the view via this Passive View interface rather than by grabbing nodes and binding things directly??) >> > > See RT-17268 did I get you wrong? I think this covers the ControllerFactory -- ie delegate controller construction to the developer -- but is separate from dynamically generating an implementation of a Passive View interface. Cheers Richard From tom.schindl at bestsolution.at Mon Dec 12 11:46:14 2011 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 12 Dec 2011 20:46:14 +0100 Subject: Could FXML use an interface and dynamic proxy for the passive view interface? In-Reply-To: <16239202-4EEF-49C1-8DD4-71C82DF5CBA4@oracle.com> References: <4EE6559C.9010405@bestsolution.at> <16239202-4EEF-49C1-8DD4-71C82DF5CBA4@oracle.com> Message-ID: <4EE65A06.6020809@bestsolution.at> Am 12.12.11 20:39, schrieb Richard Bair: > >>> Which got me thinking. Can't we have FXMLLoader use dynamic proxies to allow the FXML file to refer to a passive view interface rather than a concrete controller implementation? That at least would allow for the "Passive View" design pattern to apply extremely cleanly. It still would mean, from the developer's perspective, 2 classes instead of 1 (an interface for the view and a controller which talks to that interface). I would have to think through this a little more (I guess the controller is still required, so that the FXML document has something to call for event handlers and such, but that the controller would only talk to the view via this Passive View interface rather than by grabbing nodes and binding things directly??) >>> >> >> See RT-17268 did I get you wrong? > > I think this covers the ControllerFactory -- ie delegate controller construction to the developer -- but is separate from dynamically generating an implementation of a Passive View interface. > > Cheers > Richard You are right but to seperate the controller from the view this is most important one. I'm having a hard time making up in my mind how you would envision your passive dynamic view interface to work. Could you show us/me some pseudo code? 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 zonski at googlemail.com Mon Dec 12 13:07:49 2011 From: zonski at googlemail.com (Daniel Zwolenski) Date: Tue, 13 Dec 2011 08:07:49 +1100 Subject: Maven JavaFx native libraries and OSGi In-Reply-To: References: <4EE12C6F.8080106@tbee.org> <4EE1A362.9080303@tbee.org> Message-ID: Just in case the people who could answer this one tuned out because of all the other Maven stuff in the previous email, I'm just bumping this one: > Co-bundling jfx+jre will be an interesting addition to this whole problem. > Where will the dlls live then and will that mean just cause I have java > installed, I'll have the jfxrt.jar automatically on my classpath and it > will then have access to the dlls? If so all of this will be academic, we > won't need a maven dependency, anymore than we need one for java.util or > java.swing, etc. Can anyone elaborate on this and also the expected > timeframe for co-bundling? > I'm particularly interested in the timeframe for the co-bundling? I've heard vague rumours ranging from first quarter next year to somewhere in 2013. From roman at kennke.org Mon Dec 12 13:17:43 2011 From: roman at kennke.org (Roman Kennke) Date: Mon, 12 Dec 2011 22:17:43 +0100 Subject: Maven JavaFx native libraries and OSGi In-Reply-To: References: <4EE12C6F.8080106@tbee.org> <4EE1A362.9080303@tbee.org> Message-ID: <1323724663.3003.56.camel@moonlight> > Just in case the people who could answer this one tuned out because of all > the other Maven stuff in the previous email, I'm just bumping this one: > > > > Co-bundling jfx+jre will be an interesting addition to this whole problem. > > Where will the dlls live then and will that mean just cause I have java > > installed, I'll have the jfxrt.jar automatically on my classpath and it > > will then have access to the dlls? If so all of this will be academic, we > > won't need a maven dependency, anymore than we need one for java.util or > > java.swing, etc. Can anyone elaborate on this and also the expected > > timeframe for co-bundling? > > > > I'm particularly interested in the timeframe for the co-bundling? I've > heard vague rumours ranging from first quarter next year to somewhere in > 2013. I still don't understand why this would be necessary in the first place. A JavaFX as library, available as Maven artifact/dependency (ideally via Maven central for maximum availability), with the dll/so embedded in the JAR, with proper versioning, seems to be the best option to me. This way, as a developer (or release manager or whatever) I have most control over which version of what goes into an application, i.e. JRE version X with JavaFX version Y. Imagine that I need JavaFX version Y which is cobundled with JRE version Z which has a bug that makes it impossible for me to use, but the JavaFX that is cobundled with JRE version X doesn't yet have a feature that's introduced in JavaFX Y. And no, that's not contrived. Keeping it separate also has the additional advantage that there's less (or no) chance that dependencies on internal stuff in the JRE creep into the JavaFX code (as has happened with Swing and many other cobundled former-external libs before). Regards, Roman From zonski at googlemail.com Mon Dec 12 13:18:16 2011 From: zonski at googlemail.com (Daniel Zwolenski) Date: Tue, 13 Dec 2011 08:18:16 +1100 Subject: Controls with Values [was Possible additions to JavaFX to facilitate forms and validations] In-Reply-To: <3F758C91-05D1-404C-BA13-8371E3A23E79@oracle.com> References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> <4EDE4972.8030205@broadpark.no> <67E8E7BD-24DB-4242-81FD-6C35389A7699@oracle.com> <4EDEA518.5090102@oracle.com> <4EDEB118.6010702@bestsolution.at> <4EDFB020.3060005@broadpark.no> <424E6A89-D6CD-4A71-87CE-98F14B66AA94@oracle.com> <3F758C91-05D1-404C-BA13-8371E3A23E79@oracle.com> Message-ID: > I don't see an issue in JIRA about the ChoiceBox needing to support > bidirectional binding -- is there one already I'm missing? I think we > should break that out into a separate discussion from the HasValue > proposal. I think we can discuss a solution and get a fix in for ChoiceBox > independently. What do you think? > I was just thinking the same thing. It was actually the ChoiceBox that really made my form framework difficult to implement and that spilled over to the other guys. I think getting ChoiceBox sorted is the first, simple thing to do and this might make the rest of it start to look simple again. I have raised this: http://javafx-jira.kenai.com/browse/RT-18475 I really like your annotation idea. Makes a lot of sense! When I get some time (if only there was more of it!) I will play around with my form stuff and see if that would make it easy, or if I can find any shortcomings to this approach. I suspect it will work nicely. From tom.schindl at bestsolution.at Mon Dec 12 13:49:56 2011 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 12 Dec 2011 22:49:56 +0100 Subject: Maven JavaFx native libraries and OSGi In-Reply-To: <1323724663.3003.56.camel@moonlight> References: <4EE12C6F.8080106@tbee.org> <4EE1A362.9080303@tbee.org> <1323724663.3003.56.camel@moonlight> Message-ID: <4EE67704.10306@bestsolution.at> Am 12.12.11 22:17, schrieb Roman Kennke: >> Just in case the people who could answer this one tuned out because of all >> the other Maven stuff in the previous email, I'm just bumping this one: >> >> >>> Co-bundling jfx+jre will be an interesting addition to this whole problem. >>> Where will the dlls live then and will that mean just cause I have java >>> installed, I'll have the jfxrt.jar automatically on my classpath and it >>> will then have access to the dlls? If so all of this will be academic, we >>> won't need a maven dependency, anymore than we need one for java.util or >>> java.swing, etc. Can anyone elaborate on this and also the expected >>> timeframe for co-bundling? >>> >> >> I'm particularly interested in the timeframe for the co-bundling? I've >> heard vague rumours ranging from first quarter next year to somewhere in >> 2013. > > I still don't understand why this would be necessary in the first place. > A JavaFX as library, available as Maven artifact/dependency (ideally via > Maven central for maximum availability), with the dll/so embedded in the > JAR, with proper versioning, seems to be the best option to me. This > way, as a developer (or release manager or whatever) I have most control > over which version of what goes into an application, i.e. JRE version X > with JavaFX version Y. Imagine that I need JavaFX version Y which is > cobundled with JRE version Z which has a bug that makes it impossible > for me to use, but the JavaFX that is cobundled with JRE version X > doesn't yet have a feature that's introduced in JavaFX Y. And no, that's > not contrived. > > Keeping it separate also has the additional advantage that there's less > (or no) chance that dependencies on internal stuff in the JRE creep into > the JavaFX code (as has happened with Swing and many other cobundled > former-external libs before). > > Regards, Roman > > Isn't that what you describe exactly what jigsaw is good for? I can only hope that jigsaw allows me to have different version of a library and I as an application developer can define through version ranges which one is loaded. 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 knut.arne.vedaa at broadpark.no Mon Dec 12 13:54:16 2011 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Mon, 12 Dec 2011 22:54:16 +0100 Subject: Controls with Values [was Possible additions to JavaFX to facilitate forms and validations] In-Reply-To: <3F758C91-05D1-404C-BA13-8371E3A23E79@oracle.com> References: <3A0756CE-73A8-4623-ADB9-0CDAEBB3B24B@oracle.com> <4EDE4972.8030205@broadpark.no> <67E8E7BD-24DB-4242-81FD-6C35389A7699@oracle.com> <4EDEA518.5090102@oracle.com> <4EDEB118.6010702@bestsolution.at> <4EDFB020.3060005@broadpark.no> <424E6A89-D6CD-4A71-87CE-98F14B66AA94@oracle.com> <3F758C91-05D1-404C-BA13-8371E3A23E79@oracle.com> Message-ID: <4EE67808.1070901@broadpark.no> On 12.12.2011 19:32, Richard Bair wrote: > I wonder if there is some other solution to the problem? Could we instead use an annotation to indicate what property on a control is the "data model" for the control? Annotations are by far the easiest reflection API to use IMO, so it isn't unreasonable for tools to resort to annotations (in fact, toolability is one of the primary use cases for an annotation). So what about something like @ValueProperty in javafx.scene.control, and we can then apply it to whatever property on the control is to be considered the "value" of the control? If you're only going to use this for tooling, I think it looks like a clean solution. However, it won't let you abstract over the controls' "valuePropoperty"'s common methods, as in: InvalidationListener il = new InvalidationListener { ... } List controls = Arrays.asList(textField1, textField2, choiceBox, toggleGroup, listView) for (ValueControl control : controls) { control.valueProperty.addListener(il) } It can of course be discussed whether there is a good use-case for this. (Yes, I know ToggleGroup is not a Control, but I think conceptually it should be.) Knut Arne From zonski at googlemail.com Mon Dec 12 14:03:27 2011 From: zonski at googlemail.com (Daniel Zwolenski) Date: Tue, 13 Dec 2011 09:03:27 +1100 Subject: Could FXML use an interface and dynamic proxy for the passive view interface? In-Reply-To: <4EE65A06.6020809@bestsolution.at> References: <4EE6559C.9010405@bestsolution.at> <16239202-4EEF-49C1-8DD4-71C82DF5CBA4@oracle.com> <4EE65A06.6020809@bestsolution.at> Message-ID: Check out my last post on this page of this forum discussion: https://forums.oracle.com/forums/thread.jspa?threadID=2299217&start=15&tstart=0 I started that whole forum topic when I was first using FXML and was trying to put together a clean MVP pattern in my code (before I had fully resigned myself to the 'FXML Compromise' outlined in my latest post). In the post I give an example of injecting the controller, I don't see why it couldn't be done with everything (including resource bundles), so anything that is a setFoo(Foo myFoo) could be accessed in the FXML via a ${foo.bar}. This could be for assigning values such as