From zonski at gmail.com Sat Dec 1 02:57:37 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sat, 1 Dec 2012 21:57:37 +1100 Subject: Layouts with constraint classes In-Reply-To: <50B9B5FD.5020501@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> <50B87AF8.3050200@tbee.org> <50B88858.4080500@tbee.org> <50B9AF27.6040903@tbee.org> <50B9B5FD.5020501@tbee.org> Message-ID: I've slapped up two examples for you - they are pretty rough and could be cleaned up, but it's just to demonstrate. *Example 1* is basically how you requested it. The FXML looks like this: For the full FXML see: http://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/resources/fxml/example1.fxml (Note that I defined the Animation in the FXML, but this is totally optional, you could define it in the controller). This needed a fair few support classes because you have to create new builders for the layout manager. If this was a common use case then you could put all the customised builders and constraint classes in something like JFXtras for shared reuse. Main support class is the HBoxBuilder: http://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/example1/CustomHBoxBuilder.java (strangely extending the default HBoxBuilder didn't work with FXML - not sure if I was just doing something dumb, I didn't look into it deeper) Other support classes are all in the same package: http://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/example1/ *Example 2* is where the animation itself defines the constraints (as per my suggestion). This one feels more natural to me as the animation knows context and could decide to use a different layout depending on what action was picked. In the animation dance there is the source parent, the target parent and the node being moved. All of these are 'passive' and only the animation does the "action" and really knows that there is a move happening and why it is happening so in my book it is the one that should make decisions about how the node looks when it is moved. That's a subjective opinion though and you have both options to choose from. The FXML looks like this There are considerably fewer/simpler support classes for this. The only really interesting one is this: http://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/example2/MoveAnimation.java As a side note, the JFX animation/transition classes being final make the code a little messier. This is one area where I would vote for relaxing the use of 'final' - extending transitions makes as much sense as extending Nodes in my book. We can already extend Transition so I don't see why we can't extend SequentialTransition for example. I hope this time I got it right and that solves your use case. My main point though is that pretty much all of this sort of stuff *should* be possible through the use of builders and support classes. The glue may not always be the nicest but the driving force should be to keep the FXML and Java clean without compromising each other - the mess should be in the glue because only the glue author sees that, not the end user of the API, that's why the glue exists in the first place. On Sat, Dec 1, 2012 at 6:47 PM, Tom Eugelink wrote: > Yes, correct :-) > > The approach where the constraint is set in the animation feels procedural > and not declarative to me. Like you say yourself, I think it should be > define like: when node X is part of this layout, use these constraints. In > this way it is not relevant where the animation is defined or how the node > got there. > > Tom > > > > On 2012-12-01 08:38, Daniel Zwolenski wrote: > >> Ah ok, so in the first hbox you are saying when the "arrow" node is moved >> into here use these new constraints. I think I've got you now. >> >> That should be do-able using some more helper classes. I can knock some >> up but my first thought would be to do it as part of the animation since >> its the thing that has the most knowledge about what's going on and why. >> >> How/where do you define and trigger your animation - are you specifying >> it in the FXML? If so the constraints could be part of that eg. (made up >> pseudo FXML): >> >> >> >> >>> >>> >> >> >> >> (also slightly confusing is that the constraints you are using aren't >> applicable to HBox) >> >> If you don't like that approach I can knock up the alternative? >> >> >> >> On 01/12/2012, at 6:17 PM, Tom Eugelink wrote: >> >> Because of animation the label may move from one HBox to the other. This >>> is the reason why the current approach stores constraints inside the node, >>> so that when it moves from layout A to B, the constraints also move. My >>> approach allows to specify different constraints for the same node in each >>> layout. >>> >>> You are right that there should be a parent layout, I left it out to not >>> confuse things, but apparently that is confusing :-) >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On 2012-12-01 08:01, Daniel Zwolenski wrote: >>> >>>> You've lost me. What are you expecting the actual view to look like >>>> with this FXML? >>>> >>>> If I interpret it literally you've defined two HBox's one after the >>>> other. The first one has no children and an unused constraint, the second >>>> one has a Label in it with a constraint on it. I'm guessing you are trying >>>> to do something more but it's not real clear what that more is? >>>> >>>> >>>> >>>> On 01/12/2012, at 5:28 PM, Tom Eugelink wrote: >>>> >>>> Not variables, but references. There are constraints specified for >>>>> nodes that are not yet part of a layout (or even exist at that time, >>>>> because they are declared further down). Note the absense of a label in the >>>>> first HBox.C. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Tom >>>>> >>>>> >>>>> On 2012-11-30 14:11, Daniel Zwolenski wrote: >>>>> >>>>>> Ah ok, from your example code it looks like you want to use variables >>>>>> in FXML to define your constraints - getting into that territory of >>>>>> CSS-like style definitions that Richard was talking about? >>>>>> >>>>>> Assuming this is what you want, this can be done in the current setup >>>>>> using the ridiculously under-documented thing. >>>>>> >>>>>> I knocked up a very rough sample for you quickly. The FXML looks like >>>>>> this: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>
>>>>>> >>>>>> >>>>>>
>>>>>> >>>>>> >>>>>> >>>>>> (see https://code.google.com/p/**zenjava-playtime/source/** >>>>>> browse/trunk/layouts/src/main/**resources/fxml/example.fxml >>>>>> ) >>>>>> >>>>>> I made a base Constraints class with a static helper method on it >>>>>> (called via "Constraints.constraints" in the FXML above): >>>>>> https://code.google.com/p/**zenjava-playtime/source/** >>>>>> browse/trunk/layouts/src/main/**java/com/playtime/layouts/** >>>>>> Constraints.java >>>>>> >>>>>> And then a specific instance of HBoxConstraints: >>>>>> https://code.google.com/p/**zenjava-playtime/source/** >>>>>> browse/trunk/layouts/src/main/**java/com/playtime/layouts/** >>>>>> HBoxConstraints.java >>>>>> >>>>>> Obviously you would add others, like VBoxConstraints, >>>>>> GridPaneConstraints, etc. All pretty trivial. These helper classes could >>>>>> easily be included in something like JFXtras. >>>>>> >>>>>> So I stick with the stance that FXML is more or less OK here (not to >>>>>> say I wouldn't improve it lots in other areas), and really your >>>>>> conversation is about the Java API which is nicely decoupled to what >>>>>> can/can't be done in FXML. Kudos to Richard and the JFX team for designing >>>>>> the builders right. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Nov 30, 2012 at 9:20 PM, Tom Eugelink >>>>> tbee at tbee.org>> wrote: >>>>>> >>>>>> On 2012-11-30 10:59, Daniel Zwolenski wrote: >>>>>> >>>>>> It just doesn't do it the exact way you suggest where you >>>>>> specify multiple possibilities directly in the child in case it ends up in >>>>>> a different parent - not an approach I agree with anyway (see my previous >>>>>> comments), but that's just my opinion. >>>>>> >>>>>> >>>>>> Just to make sure my suggestion is not misunderstood, it does not >>>>>> specify multiple possibilities in the child, but in the layout. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> > From tom.schindl at bestsolution.at Sat Dec 1 03:58:17 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sat, 01 Dec 2012 12:58:17 +0100 Subject: Layouts with constraint classes In-Reply-To: References: <4FFEDD3B.6030109@oracle.com> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> <50B87AF8.3050200@tbee.org> <50B88858.4080500@tbee.org> <50B9AF27.6040903@tbee.org> <50B9B5FD.5020501@tbee.org> Message-ID: <50B9F0D9.6090608@bestsolution.at> I agree predefining the constraint for a node that might get added somewhere feels wrong (=> your 2nd sample looks good!). That's why I think it makes no sense to store to constraint on the container but it should be stored on the node itself and when you move the Node you update the constraint. BTW: I think the samples would be more interesting if the source and target container are of different type. e.g. HBox => VBox Tom Am 01.12.12 11:57, schrieb Daniel Zwolenski: > I've slapped up two examples for you - they are pretty rough and could be > cleaned up, but it's just to demonstrate. > > > *Example 1* is basically how you requested it. > > The FXML looks like this: > > > > > > > > > > > > > > > > > For the full FXML see: > http://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/resources/fxml/example1.fxml > (Note > that I defined the Animation in the FXML, but this is totally optional, you > could define it in the controller). > > This needed a fair few support classes because you have to create new > builders for the layout manager. If this was a common use case then you > could put all the customised builders and constraint classes in something > like JFXtras for shared reuse. > > Main support class is the HBoxBuilder: > http://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/example1/CustomHBoxBuilder.java > > (strangely extending the default HBoxBuilder didn't work with FXML - not > sure if I was just doing something dumb, I didn't look into it deeper) > > Other support classes are all in the same package: > http://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/example1/ > > > *Example 2* is where the animation itself defines the constraints (as per > my suggestion). This one feels more natural to me as the animation knows > context and could decide to use a different layout depending on what action > was picked. In the animation dance there is the source parent, the target > parent and the node being moved. All of these are 'passive' and only the > animation does the "action" and really knows that there is a move happening > and why it is happening so in my book it is the one that should make > decisions about how the node looks when it is moved. That's a subjective > opinion though and you have both options to choose from. > > The FXML looks like this > > > > > > > > > > newParent="$hbox2"> > > > newParent="$hbox1"> > > > > > There are considerably fewer/simpler support classes for this. The only > really interesting one is this: > > http://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/example2/MoveAnimation.java > > As a side note, the JFX animation/transition classes being final make the > code a little messier. This is one area where I would vote for relaxing the > use of 'final' - extending transitions makes as much sense as extending > Nodes in my book. We can already extend Transition so I don't see why we > can't extend SequentialTransition for example. > > I hope this time I got it right and that solves your use case. My main > point though is that pretty much all of this sort of stuff *should* be > possible through the use of builders and support classes. The glue may not > always be the nicest but the driving force should be to keep the FXML and > Java clean without compromising each other - the mess should be in the glue > because only the glue author sees that, not the end user of the API, that's > why the glue exists in the first place. > > > > > > On Sat, Dec 1, 2012 at 6:47 PM, Tom Eugelink wrote: > >> Yes, correct :-) >> >> The approach where the constraint is set in the animation feels procedural >> and not declarative to me. Like you say yourself, I think it should be >> define like: when node X is part of this layout, use these constraints. In >> this way it is not relevant where the animation is defined or how the node >> got there. >> >> Tom >> >> >> >> On 2012-12-01 08:38, Daniel Zwolenski wrote: >> >>> Ah ok, so in the first hbox you are saying when the "arrow" node is moved >>> into here use these new constraints. I think I've got you now. >>> >>> That should be do-able using some more helper classes. I can knock some >>> up but my first thought would be to do it as part of the animation since >>> its the thing that has the most knowledge about what's going on and why. >>> >>> How/where do you define and trigger your animation - are you specifying >>> it in the FXML? If so the constraints could be part of that eg. (made up >>> pseudo FXML): >>> >>> >>> >>> >>>> >>>> >>> >>> >>> >>> (also slightly confusing is that the constraints you are using aren't >>> applicable to HBox) >>> >>> If you don't like that approach I can knock up the alternative? >>> >>> >>> >>> On 01/12/2012, at 6:17 PM, Tom Eugelink wrote: >>> >>> Because of animation the label may move from one HBox to the other. This >>>> is the reason why the current approach stores constraints inside the node, >>>> so that when it moves from layout A to B, the constraints also move. My >>>> approach allows to specify different constraints for the same node in each >>>> layout. >>>> >>>> You are right that there should be a parent layout, I left it out to not >>>> confuse things, but apparently that is confusing :-) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 2012-12-01 08:01, Daniel Zwolenski wrote: >>>> >>>>> You've lost me. What are you expecting the actual view to look like >>>>> with this FXML? >>>>> >>>>> If I interpret it literally you've defined two HBox's one after the >>>>> other. The first one has no children and an unused constraint, the second >>>>> one has a Label in it with a constraint on it. I'm guessing you are trying >>>>> to do something more but it's not real clear what that more is? >>>>> >>>>> >>>>> >>>>> On 01/12/2012, at 5:28 PM, Tom Eugelink wrote: >>>>> >>>>> Not variables, but references. There are constraints specified for >>>>>> nodes that are not yet part of a layout (or even exist at that time, >>>>>> because they are declared further down). Note the absense of a label in the >>>>>> first HBox.C. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Tom >>>>>> >>>>>> >>>>>> On 2012-11-30 14:11, Daniel Zwolenski wrote: >>>>>> >>>>>>> Ah ok, from your example code it looks like you want to use variables >>>>>>> in FXML to define your constraints - getting into that territory of >>>>>>> CSS-like style definitions that Richard was talking about? >>>>>>> >>>>>>> Assuming this is what you want, this can be done in the current setup >>>>>>> using the ridiculously under-documented thing. >>>>>>> >>>>>>> I knocked up a very rough sample for you quickly. The FXML looks like >>>>>>> this: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>
>>>>>>> >>>>>>> >>>>>>>
>>>>>>> >>>>>>> >>>>>>> >>>>>>> (see https://code.google.com/p/**zenjava-playtime/source/** >>>>>>> browse/trunk/layouts/src/main/**resources/fxml/example.fxml >>>>>>> ) >>>>>>> >>>>>>> I made a base Constraints class with a static helper method on it >>>>>>> (called via "Constraints.constraints" in the FXML above): >>>>>>> https://code.google.com/p/**zenjava-playtime/source/** >>>>>>> browse/trunk/layouts/src/main/**java/com/playtime/layouts/** >>>>>>> Constraints.java >>>>>>> >>>>>>> And then a specific instance of HBoxConstraints: >>>>>>> https://code.google.com/p/**zenjava-playtime/source/** >>>>>>> browse/trunk/layouts/src/main/**java/com/playtime/layouts/** >>>>>>> HBoxConstraints.java >>>>>>> >>>>>>> Obviously you would add others, like VBoxConstraints, >>>>>>> GridPaneConstraints, etc. All pretty trivial. These helper classes could >>>>>>> easily be included in something like JFXtras. >>>>>>> >>>>>>> So I stick with the stance that FXML is more or less OK here (not to >>>>>>> say I wouldn't improve it lots in other areas), and really your >>>>>>> conversation is about the Java API which is nicely decoupled to what >>>>>>> can/can't be done in FXML. Kudos to Richard and the JFX team for designing >>>>>>> the builders right. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Nov 30, 2012 at 9:20 PM, Tom Eugelink >>>>>> tbee at tbee.org>> wrote: >>>>>>> >>>>>>> On 2012-11-30 10:59, Daniel Zwolenski wrote: >>>>>>> >>>>>>> It just doesn't do it the exact way you suggest where you >>>>>>> specify multiple possibilities directly in the child in case it ends up in >>>>>>> a different parent - not an approach I agree with anyway (see my previous >>>>>>> comments), but that's just my opinion. >>>>>>> >>>>>>> >>>>>>> Just to make sure my suggestion is not misunderstood, it does not >>>>>>> specify multiple possibilities in the child, but in the layout. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >> -- 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 randahl at rockit.dk Sat Dec 1 05:26:31 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Sat, 1 Dec 2012 14:26:31 +0100 Subject: The competition In-Reply-To: <3DB35A93-2FD8-4440-8C1C-1CDA45CC4859@gmail.com> References: <3DB35A93-2FD8-4440-8C1C-1CDA45CC4859@gmail.com> Message-ID: Dan, I completely disagree with your analysis. Richard has already asked you to provide documentation to back up your performance claims, and I have the following to add: Your claim: Web is [?] a deployment model that is seamless across more platforms. ? My input: You are right that deployment of web apps feels easy, but truly ensuring that the deployment actually works for all users on all platforms is all but a trivial task. There are literally hundreds of different web browser brands and versions out there, and the fact that you tested your latest web app on the two latest versions of a couple of browsers, gives you no guarantee that the web app works for all of the target audience. Have a look at this list, that documents the insanity of the web deployment challenge: http://www.useragentstring.com/pages/Browserlist/. The truth is that some web developers close their eyes to the heterogeneous nature of the deployment environment, and simply define their target audience as "users who use the latest version of Internet Explorer on Windows". That may give you a warm and fuzzy feeling of simplicity and ease of deployment, but in reality it just means that your web app is most likely broken for everyone who falls outside your defined target audience. Knowing that all of your desktop users run Oracle's version of Java is a way better than knowing that all of your users run either Internet Explorer or Chrome or Safari or Firefox or yet another browser. Your claim: [JavaFX is] based on established, type-safe java [?] However there is little benefit to users [in this]. ? My input: Everyone who has tried debugging a web application with more than 20.000 lines of JavaScript code knows that the lack of compile-time checks and type safety means JavaScript is more error prone. More errors means more time spent on debugging and less time spent on providing new features or improving the overall product quality. I hope you agree that users prefer robust, feature rich, high quality applications. Your claim: Should [JavaFX] not gain market space before the [HTML5] era truly establishes itself then [JavaFX] is unlikely to ever make it [?]. ? My input: On the one hand you are saying that HTML 5 has not truly established itself, even though it was first published 5 years ago, but still you claim HTML5 is the likely winner. Then on the other hand you move on to claiming that Java based JavaFX (meaning JavaFX 2.x) has to win the race in its first 2 years of existence in order to make it. I think it is worth noting that new software projects start every day, and many of them will choose the technology that best suits their needs. Remember when Windows was the all dominating operating system and people thought no one else had a chance? What happened? Remember when Internet Explorer was the all dominating browser and people thought no one else had a chance? What happened? Remember when Nokia was the all dominating cell phone manufacturer in Europe and Apple had not even made a phone yet? What happened? Remember when gasoline was the all dominating propellant for cars and people thought electric cars had no chance? What is happening right now? All in all, I believe time will show that both HTML5 and JavaFX will have huge success. It all comes down to understanding the strengths of each technology, and knowing which technology best matches the exact requirements of the app you are building. Randahl On Nov 30, 2012, at 16:42 , Daniel Zwolenski wrote: > It's the space that oracle doesn't care about but just for reference here's some stuff that web are doing: > > http://blog.alexmaccaw.com/the-next-web > > My analysis of this market segment, for what it is worth: > > Web is moving faster than jfx, with a head start in a lot of areas, with big backing from all vendors and a deployment model that is seamless across more platforms. > > Jfx being based on established, type-safe java and having all the java libraries/tools makes it a big draw card for developers compared to jscript. However there is little benefit to users and it is users who will drive the choice of technology. Feature wise jfx and web are generally on par - in many cases web is better but generally in areas not fully standardized yet so limited to certain browsers etc. Standardization is happening quickly in web unlike the days of old. In general web is improving faster than the current jfx road map. > > In JFX's favour is the java brand and libraries from java's dominance in the server space. Java's reputation plus one-language/WORA end to end are the key selling points for jfx. > > One-language/WORA is currently a perceived advantage only since jfx does not work on as many platforms as web and it is only server side that jscript does not currently compete. Developers are starting to realize that jfx is not delivering on wora and business decision makers are unlikely to be convinced by developers without WORA as a selling point. > > Several early forays of jscript into the server space have already happened with some minor success. Expect this to be a growth area and the wora/one-language advantage could switch, making it one of the draw cards of jscript over jfx within the next 12 months (though java on the server is likely to dominate for many years still through pure momentum and market position). Jscript is also being enhanced to have more appeal to developers, however it has a lot of legacy perceptions to overcome before it will appeal to traditional server developers. > > Performance is also a perceived advantage of jfx (web is currently perceived as slow, whereas as 'desktop' is seen as fast) however in practice jfx is no faster than modern browsers and web is increasingly improving performance. The perceived advantage will be short lived especially with windows 8 driving more pc upgrades and the inevitable drop off of ie7 and ie8 (responsible for most of the negative performance opinions). Web is rapidly addressing its perceived performance issues. > > The mobile space is currently still open. The technology that provides good cross-mobile development will dominate here. Existing solutions like phone gap have had mixed success. WORA is the selling point but poor user experience and performance are the main complaints. Jscript based solutions are improving however and there are a number of vendors targeting this space. Phones typically have a 2 to 3 year life cycle so as we start to see the drop off of older android devices, jscript solutions will become more performant and user friendly. > > Javafx has a small window, maybe 12 months at most, of opportunity to capture some of the consumer market space. Mobile is particularly open but web is also in a transition state and some aggressive positioning could see jfx capitalize on the java brand to establish itself before web achieves its current trajectory. Claiming some market space now coupled with java server dominance could see jfx survive the onslaught of html5 frenzy. > > Deployment is currently the number one inhibitor to both the web and mobile space. A good deployment model is needed on major platforms to have broad range appeal. > > Should javafx not gain market space before the "html5" era truly establishes itself then jfx is unlikely to ever make it into the consumer space in its current form. It is likely to continue to have some market share in select back-office environments (particularly those that oracle is directly working with) and may spread a little wider if alternate deployment solutions such as running javafx ontop of jscript, or compiling to jscript are implemented. > > In the embedded space, java and javafx is well positioned with hardware/technology at the sweet point for embedded jre usage. Expect this to be a growth area over the next few years with javafx likely to dominate this space. > > > > From tom.schindl at bestsolution.at Sat Dec 1 05:58:33 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sat, 01 Dec 2012 14:58:33 +0100 Subject: *PropertyBase vs Simple*Property Message-ID: <50BA0D09.2050005@bestsolution.at> Hi, I'm just working on a patch for a control and I'm so I'm browsing through the code a bit and find there all of the pattern that you are creating an instance of *PropertyBase for all stuff instead of using the Simple.... , which creates a whole lot of new $1,$2,$.... class files. Would it be from a size point of view better to create an instance of Simple*Property? I guess there's a reason but I'm not sure I know which one it is. Could it be garbage collection - property points to Bean and Bean points to property? If this the reason I think anyone who use uses Simple*Property has the same problem and the right fix would be to store the bean instance in Simple*Property in a WeakReference? Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From tbee at tbee.org Sat Dec 1 06:00:06 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 01 Dec 2012 15:00:06 +0100 Subject: Layouts with constraint classes In-Reply-To: References: <4FFEDD3B.6030109@oracle.com> <50B074CB.6010807@tbee.org> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> <50B87AF8.3050200@tbee.org> <50B88858.4080500@tbee.org> <50B9AF27.6040903@tbee.org> <50B9B5FD.5020501@tbee.org> Message-ID: <50BA0D66.40608@tbee.org> I'm impressed with how close you come with just builders. The only remark I have is that with example 1, when the node is part of the layout, the constraint should ideally be a child of the node so a reference is not needed. On 2012-12-01 11:57, Daniel Zwolenski wrote: > I've slapped up two examples for you - they are pretty rough and could be cleaned up, but it's just to demonstrate. > > > *Example 1* is basically how you requested it. > > The FXML looks like this: > > > > > > > > > > > > > > > > > For the full FXML see: http://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/resources/fxml/example1.fxml (Note that I defined the Animation in the FXML, but this is totally optional, you could define it in the controller). > > This needed a fair few support classes because you have to create new builders for the layout manager. If this was a common use case then you could put all the customised builders and constraint classes in something like JFXtras for shared reuse. > > Main support class is the HBoxBuilder: http://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/example1/CustomHBoxBuilder.java > > (strangely extending the default HBoxBuilder didn't work with FXML - not sure if I was just doing something dumb, I didn't look into it deeper) > > Other support classes are all in the same package: http://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/example1/ > > > *Example 2* is where the animation itself defines the constraints (as per my suggestion). This one feels more natural to me as the animation knows context and could decide to use a different layout depending on what action was picked. In the animation dance there is the source parent, the target parent and the node being moved. All of these are 'passive' and only the animation does the "action" and really knows that there is a move happening and why it is happening so in my book it is the one that should make decisions about how the node looks when it is moved. That's a subjective opinion though and you have both options to choose from. > > The FXML looks like this > > > > > > > > > > > > > > > > > > There are considerably fewer/simpler support classes for this. The only really interesting one is this: > http://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/example2/MoveAnimation.java > > As a side note, the JFX animation/transition classes being final make the code a little messier. This is one area where I would vote for relaxing the use of 'final' - extending transitions makes as much sense as extending Nodes in my book. We can already extend Transition so I don't see why we can't extend SequentialTransition for example. > > I hope this time I got it right and that solves your use case. My main point though is that pretty much all of this sort of stuff *should* be possible through the use of builders and support classes. The glue may not always be the nicest but the driving force should be to keep the FXML and Java clean without compromising each other - the mess should be in the glue because only the glue author sees that, not the end user of the API, that's why the glue exists in the first place. > > > > > > On Sat, Dec 1, 2012 at 6:47 PM, Tom Eugelink > wrote: > > Yes, correct :-) > > The approach where the constraint is set in the animation feels procedural and not declarative to me. Like you say yourself, I think it should be define like: when node X is part of this layout, use these constraints. In this way it is not relevant where the animation is defined or how the node got there. > > Tom > > > > On 2012-12-01 08:38, Daniel Zwolenski wrote: > > Ah ok, so in the first hbox you are saying when the "arrow" node is moved into here use these new constraints. I think I've got you now. > > That should be do-able using some more helper classes. I can knock some up but my first thought would be to do it as part of the animation since its the thing that has the most knowledge about what's going on and why. > > How/where do you define and trigger your animation - are you specifying it in the FXML? If so the constraints could be part of that eg. (made up pseudo FXML): > > > > > > > > > > (also slightly confusing is that the constraints you are using aren't applicable to HBox) > > If you don't like that approach I can knock up the alternative? > > > > On 01/12/2012, at 6:17 PM, Tom Eugelink > wrote: > > Because of animation the label may move from one HBox to the other. This is the reason why the current approach stores constraints inside the node, so that when it moves from layout A to B, the constraints also move. My approach allows to specify different constraints for the same node in each layout. > > You are right that there should be a parent layout, I left it out to not confuse things, but apparently that is confusing :-) > > > > > > > > > > > > > On 2012-12-01 08:01, Daniel Zwolenski wrote: > > You've lost me. What are you expecting the actual view to look like with this FXML? > > If I interpret it literally you've defined two HBox's one after the other. The first one has no children and an unused constraint, the second one has a Label in it with a constraint on it. I'm guessing you are trying to do something more but it's not real clear what that more is? > > > > On 01/12/2012, at 5:28 PM, Tom Eugelink > wrote: > > Not variables, but references. There are constraints specified for nodes that are not yet part of a layout (or even exist at that time, because they are declared further down). Note the absense of a label in the first HBox.C. > > > > > > > > > > Tom > > > On 2012-11-30 14:11, Daniel Zwolenski wrote: > > Ah ok, from your example code it looks like you want to use variables in FXML to define your constraints - getting into that territory of CSS-like style definitions that Richard was talking about? > > Assuming this is what you want, this can be done in the current setup using the ridiculously under-documented thing. > > I knocked up a very rough sample for you quickly. The FXML looks like this: > > > > > > > > >
> > >
> > > > (see https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/resources/fxml/example.fxml) > > I made a base Constraints class with a static helper method on it (called via "Constraints.constraints" in the FXML above): > https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/Constraints.java > > And then a specific instance of HBoxConstraints: > https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/HBoxConstraints.java > > Obviously you would add others, like VBoxConstraints, GridPaneConstraints, etc. All pretty trivial. These helper classes could easily be included in something like JFXtras. > > So I stick with the stance that FXML is more or less OK here (not to say I wouldn't improve it lots in other areas), and really your conversation is about the Java API which is nicely decoupled to what can/can't be done in FXML. Kudos to Richard and the JFX team for designing the builders right. > > > > > On Fri, Nov 30, 2012 at 9:20 PM, Tom Eugelink >> wrote: > > On 2012-11-30 10:59, Daniel Zwolenski wrote: > > It just doesn't do it the exact way you suggest where you specify multiple possibilities directly in the child in case it ends up in a different parent - not an approach I agree with anyway (see my previous comments), but that's just my opinion. > > > Just to make sure my suggestion is not misunderstood, it does not specify multiple possibilities in the child, but in the layout. > > > > > > > > > > > From tom.schindl at bestsolution.at Sat Dec 1 06:41:23 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sat, 01 Dec 2012 15:41:23 +0100 Subject: StyleManager#reloadStylesheets(Scene) replacement in FX8 Message-ID: <50BA1713.7050607@bestsolution.at> Hi, To force reloading of stylesheets I used in FX2.2 StyleManager.getInstance().reloadStylesheets(scene). What is the replacement of this in FX8. 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 Sat Dec 1 06:49:58 2012 From: richard.bair at oracle.com (Richard Bair) Date: Sat, 1 Dec 2012 06:49:58 -0800 Subject: *PropertyBase vs Simple*Property In-Reply-To: <50BA0D09.2050005@bestsolution.at> References: <50BA0D09.2050005@bestsolution.at> Message-ID: Hi Tom, The tradeoff between Simple* and *PropertyBase is dynamic vs. static footprint (heap size vs. class size). The Simple* guys have references to the bean & property name, and so require additional heap space to store this data, whereas the *PropertyBase guys don't, but require a subclass to override the getBean() & getName() methods. Generally we should be using the Simple* guys, unless we already had to override the property for the sake of the invalidated() method. In that case, since we're already paying the static footprint cost, it makes sense to use the *PropertyBase instead and save on dynamic footprint. With Lambda's, I was hoping to be able to extend the Simple* property implementations to also take a lambda to a method which represents the invalidated method. In this case, we could remove most of the anonymous sub classes, and make quite an impact on our static footprint (at the cost of making each object a little heavier in memory). Richard On Dec 1, 2012, at 5:58 AM, Tom Schindl wrote: > Hi, > > I'm just working on a patch for a control and I'm so I'm browsing > through the code a bit and find there all of the pattern that you are > creating an instance of *PropertyBase for all stuff instead of using the > Simple.... , which creates a whole lot of new $1,$2,$.... class files. > > Would it be from a size point of view better to create an instance of > Simple*Property? I guess there's a reason but I'm not sure I know which > one it is. Could it be garbage collection - property points to Bean and > Bean points to property? > > If this the reason I think anyone who use uses Simple*Property has the > same problem and the right fix would be to store the bean instance in > Simple*Property in a WeakReference? > > Tom > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From tbee at tbee.org Sat Dec 1 11:00:36 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 01 Dec 2012 20:00:36 +0100 Subject: Layouts with constraint classes In-Reply-To: <50B9F0D9.6090608@bestsolution.at> References: <4FFEDD3B.6030109@oracle.com> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> <50B87AF8.3050200@tbee.org> <50B88858.4080500@tbee.org> <50B9AF27.6040903@tbee.org> <50B9B5FD.5020501@tbee.org> <50B9F0D9.6090608@bestsolut ion.at> Message-ID: <50BA53D4.7090504@tbee.org> Since it is an equal relationship, it is defend-able to set all constraints on the node. That would be a matter of taste. I prefer it the other way around, because a layout is complicated enough without additional constraints of another layout. Tom On 2012-12-01 12:58, Tom Schindl wrote: > I agree predefining the constraint for a node that might get added > somewhere feels wrong (=> your 2nd sample looks good!). That's why I > think it makes no sense to store to constraint on the container but it > should be stored on the node itself and when you move the Node you > update the constraint. > > BTW: I think the samples would be more interesting if the source and > target container are of different type. e.g. HBox => VBox > > Tom > > Am 01.12.12 11:57, schrieb Daniel Zwolenski: >> I've slapped up two examples for you - they are pretty rough and could be >> cleaned up, but it's just to demonstrate. >> >> >> *Example 1* is basically how you requested it. >> >> The FXML looks like this: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> For the full FXML see: >> http://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/resources/fxml/example1.fxml >> (Note >> that I defined the Animation in the FXML, but this is totally optional, you >> could define it in the controller). >> >> This needed a fair few support classes because you have to create new >> builders for the layout manager. If this was a common use case then you >> could put all the customised builders and constraint classes in something >> like JFXtras for shared reuse. >> >> Main support class is the HBoxBuilder: >> http://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/example1/CustomHBoxBuilder.java >> >> (strangely extending the default HBoxBuilder didn't work with FXML - not >> sure if I was just doing something dumb, I didn't look into it deeper) >> >> Other support classes are all in the same package: >> http://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/example1/ >> >> >> *Example 2* is where the animation itself defines the constraints (as per >> my suggestion). This one feels more natural to me as the animation knows >> context and could decide to use a different layout depending on what action >> was picked. In the animation dance there is the source parent, the target >> parent and the node being moved. All of these are 'passive' and only the >> animation does the "action" and really knows that there is a move happening >> and why it is happening so in my book it is the one that should make >> decisions about how the node looks when it is moved. That's a subjective >> opinion though and you have both options to choose from. >> >> The FXML looks like this >> >> >> >> >> >> >> >> >> >> > newParent="$hbox2"> >> >> >> > newParent="$hbox1"> >> >> >> >> >> There are considerably fewer/simpler support classes for this. The only >> really interesting one is this: >> >> http://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/example2/MoveAnimation.java >> >> As a side note, the JFX animation/transition classes being final make the >> code a little messier. This is one area where I would vote for relaxing the >> use of 'final' - extending transitions makes as much sense as extending >> Nodes in my book. We can already extend Transition so I don't see why we >> can't extend SequentialTransition for example. >> >> I hope this time I got it right and that solves your use case. My main >> point though is that pretty much all of this sort of stuff *should* be >> possible through the use of builders and support classes. The glue may not >> always be the nicest but the driving force should be to keep the FXML and >> Java clean without compromising each other - the mess should be in the glue >> because only the glue author sees that, not the end user of the API, that's >> why the glue exists in the first place. >> >> >> >> >> >> On Sat, Dec 1, 2012 at 6:47 PM, Tom Eugelink wrote: >> >>> Yes, correct :-) >>> >>> The approach where the constraint is set in the animation feels procedural >>> and not declarative to me. Like you say yourself, I think it should be >>> define like: when node X is part of this layout, use these constraints. In >>> this way it is not relevant where the animation is defined or how the node >>> got there. >>> >>> Tom >>> >>> >>> >>> On 2012-12-01 08:38, Daniel Zwolenski wrote: >>> >>>> Ah ok, so in the first hbox you are saying when the "arrow" node is moved >>>> into here use these new constraints. I think I've got you now. >>>> >>>> That should be do-able using some more helper classes. I can knock some >>>> up but my first thought would be to do it as part of the animation since >>>> its the thing that has the most knowledge about what's going on and why. >>>> >>>> How/where do you define and trigger your animation - are you specifying >>>> it in the FXML? If so the constraints could be part of that eg. (made up >>>> pseudo FXML): >>>> >>>> >>>> >>>> >>>>> >>>>> >>>> >>>> >>>> >>>> (also slightly confusing is that the constraints you are using aren't >>>> applicable to HBox) >>>> >>>> If you don't like that approach I can knock up the alternative? >>>> >>>> >>>> >>>> On 01/12/2012, at 6:17 PM, Tom Eugelink wrote: >>>> >>>> Because of animation the label may move from one HBox to the other. This >>>>> is the reason why the current approach stores constraints inside the node, >>>>> so that when it moves from layout A to B, the constraints also move. My >>>>> approach allows to specify different constraints for the same node in each >>>>> layout. >>>>> >>>>> You are right that there should be a parent layout, I left it out to not >>>>> confuse things, but apparently that is confusing :-) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2012-12-01 08:01, Daniel Zwolenski wrote: >>>>> >>>>>> You've lost me. What are you expecting the actual view to look like >>>>>> with this FXML? >>>>>> >>>>>> If I interpret it literally you've defined two HBox's one after the >>>>>> other. The first one has no children and an unused constraint, the second >>>>>> one has a Label in it with a constraint on it. I'm guessing you are trying >>>>>> to do something more but it's not real clear what that more is? >>>>>> >>>>>> >>>>>> >>>>>> On 01/12/2012, at 5:28 PM, Tom Eugelink wrote: >>>>>> >>>>>> Not variables, but references. There are constraints specified for >>>>>>> nodes that are not yet part of a layout (or even exist at that time, >>>>>>> because they are declared further down). Note the absense of a label in the >>>>>>> first HBox.C. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Tom >>>>>>> >>>>>>> >>>>>>> On 2012-11-30 14:11, Daniel Zwolenski wrote: >>>>>>> >>>>>>>> Ah ok, from your example code it looks like you want to use variables >>>>>>>> in FXML to define your constraints - getting into that territory of >>>>>>>> CSS-like style definitions that Richard was talking about? >>>>>>>> >>>>>>>> Assuming this is what you want, this can be done in the current setup >>>>>>>> using the ridiculously under-documented thing. >>>>>>>> >>>>>>>> I knocked up a very rough sample for you quickly. The FXML looks like >>>>>>>> this: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>
>>>>>>>> >>>>>>>> >>>>>>>>
>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> (see https://code.google.com/p/**zenjava-playtime/source/** >>>>>>>> browse/trunk/layouts/src/main/**resources/fxml/example.fxml >>>>>>>> ) >>>>>>>> >>>>>>>> I made a base Constraints class with a static helper method on it >>>>>>>> (called via "Constraints.constraints" in the FXML above): >>>>>>>> https://code.google.com/p/**zenjava-playtime/source/** >>>>>>>> browse/trunk/layouts/src/main/**java/com/playtime/layouts/** >>>>>>>> Constraints.java >>>>>>>> >>>>>>>> And then a specific instance of HBoxConstraints: >>>>>>>> https://code.google.com/p/**zenjava-playtime/source/** >>>>>>>> browse/trunk/layouts/src/main/**java/com/playtime/layouts/** >>>>>>>> HBoxConstraints.java >>>>>>>> >>>>>>>> Obviously you would add others, like VBoxConstraints, >>>>>>>> GridPaneConstraints, etc. All pretty trivial. These helper classes could >>>>>>>> easily be included in something like JFXtras. >>>>>>>> >>>>>>>> So I stick with the stance that FXML is more or less OK here (not to >>>>>>>> say I wouldn't improve it lots in other areas), and really your >>>>>>>> conversation is about the Java API which is nicely decoupled to what >>>>>>>> can/can't be done in FXML. Kudos to Richard and the JFX team for designing >>>>>>>> the builders right. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Nov 30, 2012 at 9:20 PM, Tom Eugelink >>>>>>> tbee at tbee.org>> wrote: >>>>>>>> >>>>>>>> On 2012-11-30 10:59, Daniel Zwolenski wrote: >>>>>>>> >>>>>>>> It just doesn't do it the exact way you suggest where you >>>>>>>> specify multiple possibilities directly in the child in case it ends up in >>>>>>>> a different parent - not an approach I agree with anyway (see my previous >>>>>>>> comments), but that's just my opinion. >>>>>>>> >>>>>>>> >>>>>>>> Just to make sure my suggestion is not misunderstood, it does not >>>>>>>> specify multiple possibilities in the child, but in the layout. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > From randahl at rockit.dk Sat Dec 1 12:18:22 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Sat, 1 Dec 2012 21:18:22 +0100 Subject: =?windows-1252?Q?Request_for_comments_=96_interface_Rectangular?= Message-ID: <92E5C77A-7E97-43A8-9D63-FD066FFE3AF6@rockit.dk> I have on a few occasions had to determine the width and height of a Node. It turns out, that this is not that easy, because JavaFX does not yet have a common interface for all nodes that have a width and a height. Consequently, I suggest an interface Rectangular to be added: interface Rectangular { double getWidth(); double getHeight(); } This interface would have the benefit of making measuring node size considerably simpler. Before: if(node instanceof Region || node instanceof Control || node instanceof Rectangle [?]) { double width = -1; double height = -1; if(node instanceof Region) { width = ((Region) node).getWidth(); height = ((Region) node).getHeight(); } else if(node instanceof Control) { width = ((Control) node).getWidth(); height = ((Control) node).getHeight(); } else if(node instanceof Rectangle) { width = ((Rectangle) node).getWidth(); height = ((Rectangle) node).getHeight(); } // do something with the width and height } And after if(node instanceof of Rectangular) { double width = ((Rectangular) node).getWidth(); double height = ((Rectangular) node).getHeight(); // do something with the width and height } I would very much like to discuss if this concept could be helpful for all of us. Thanks Randahl From zonski at gmail.com Sat Dec 1 13:56:50 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sun, 2 Dec 2012 08:56:50 +1100 Subject: The competition In-Reply-To: References: <3DB35A93-2FD8-4440-8C1C-1CDA45CC4859@gmail.com> Message-ID: <30169C4D-FA68-497E-8FB7-23858018E87B@gmail.com> Hi Randahl, Thanks for your comments I appreciate hearing an alternative point of view. One thing to keep in mind is that all of my comments are within the context of the web/consumer space (unfortunately this space doesn't have a good name so it's harder to define). > Richard has already asked you to provide documentation to back up your performance claims, I responded to this. There is another thread on performance where someone (I think Michael) made the claim that jfx was slow (in some cases 2-3 times slower than awt) and my own experiences have shown problems. I'd suggest continuing that conversation on that thread if needed since the original poster of that question made a good attempt at phrasing these questions (and in my opinion leaving that thread unanswered was far worse for perception than leaving this one unanswered - surprised Richard let it unrebuked based on his stance on performance). I look forward to seeing Richard's documentation on benchmarks when he has a chance to release them. > Your claim: Web is [?] a deployment model that is seamless across more platforms. > ? My input: You are right that deployment of web apps feels easy, but truly ensuring that the deployment actually works for all users on all platforms is all but a trivial task. There are literally hundreds of different web browser brands and versions out there, and the fact that you tested your latest web app on the two latest versions of a couple of browsers, gives you no guarantee that the web app works for all of the target audience. Have a look at this list, that documents the insanity of the web deployment challenge: http://www.useragentstring.com/pages/Browserlist/. > The truth is that some web developers close their eyes to the heterogeneous nature of the deployment environment, and simply define their target audience as "users who use the latest version of Internet Explorer on Windows". That may give you a warm and fuzzy feeling of simplicity and ease of deployment, but in reality it just means that your web app is most likely broken for everyone who falls outside your defined target audience. Knowing that all of your desktop users run Oracle's version of Java is a way better than knowing that all of your users run either Internet Explorer or Chrome or Safari or Firefox or yet another browser. Agreed there are challenges with supporting lots of different browsers. My comment was that the user experience for "deployment" (ie getting a webapp running) is seamless (go to this URL). Once running, bug free cross-platform "consistency" is harder to achieve but the onus for this is on the developer (you have to test and run on every platform and tweak as needed). To me your argument here is that jfx having a single platform is the better "developer" experience and I totally agree. I hate debugging and fixing cross browser problems as much as the next developer but my users don't care that I hate doing it. My users would care however, if I told them that to run my app they have to first go to an oracle site and install java. A single platform for jfx is definitely a huge selling point for it and good that you added that to the analysis, but it is a selling point to the developers, not end users. You argue that the kick-on effect (ie developer is happy so they can do a better/quicker job) is a selling point to the user but your user would be weighing this somewhat unquantifiable benefit against the very comprehensible drawback of having to install java and the problems that come with that. As a side note the web space is traditionally horrid for x-browser but is improving rapidly and many frameworks like jquery and twitter bootstrap are making x-browser support much, much easier to achieve. I just released a webapp with moderate level of jscript that needed less than a week of testing/tweaking to work on IE7 - IE10, Firefox, chrome, safari, on WinXP - Win7 and Mac. I was pretty shocked myself that it worked based on my previous experiences (had braced myself for pain). IE10 still has some of the usual ms quirks but it is a far cry from the old days of ie 6 and ie 7. Also worth noting is that even with one platform, jfx has its own win vs mac vs Linux issues and you need to test and tweak on everyone (and build if you're using native installers). As a developer though the idea of one platform is one of the big selling points to me, as it sounds like it is for you. > Your claim: [JavaFX is] based on established, type-safe java [?] However there is little benefit to users [in this]. > ? My input: Everyone who has tried debugging a web application with more than 20.000 lines of JavaScript code knows that the lack of compile-time checks and type safety means JavaScript is more error prone. More errors means more time spent on debugging and less time spent on providing new features or improving the overall product quality. I hope you agree that users prefer robust, feature rich, high quality applications. Again, this is a (big) selling point to developers. You can argue the kick on benefits of more features and less bugs but that's hard to quantify and stack up against quantifiable things like installation and even availability and cost of jfx developers in the market vs web. In terms of getting features out quicker web developers would argue that they can get more features out in less time than a java app and this would be the established perception out there - how do you prove you are right and they are wrong (and the proliferation of rapidly released webapps and lack of jfx apps would put the burden of proof on the jfx developer)? It certainly is possible to build a robust, bug free webapp too. Atlassian tool suite, google analytics, Facebook, gmail, etc, etc - when we are telling our users that jfx will be less buggy than a webapp, how do we convince them of that when they are already using plenty of robust webapps in their daily lives? > Your claim: Should [JavaFX] not gain market space before the [HTML5] era truly establishes itself then [JavaFX] is unlikely to ever make it [?]. You snipped just before the important bit: "in it's current form". Also we're talking about the web space and competing with HTML. As I go on to say there are other areas where jfx can continue to be a contender but those areas were not the focus of my email. My opinion is that once the html5 era stabilizes it will be unlikely that jfx will offer much to that will allow it to break into the web space unless it innovates. Browser plugins will be dead so webstart and applets will be out, leaving no true web deployment option. I do not say that jfx will be dead only that it's current strategies for operating in the web will never work and new ones will be needed *if* jfx ever does want to try and compete in the web space (ie if oracle change their mind about not being interested in this space). One way this could happen for example is to not compete directly but to run ontop of jscript either at runtime or by precompiling the java/jfx app to jscript (ie like gwt does, in fact jfx-for-gwt would be a good avenue to look at though I suspect gwt is on the technology down curve with html5 rendering it somewhat obsolete). Alternatively the trend towards app stores may actually open more doors for jfx. In essence the OS vendors are potentially providing us with a deployment solution (yay!). In terms of the space I am looking at, keeping an eye on these app stores and there challenges regarding legals and technical restrictions is very high on the list. It's a good example of why I feel this sort of analysis is needed - what are the trends, opportunities, risks and what's our strategy as a result. Basically my analysis is that there is a small window of opportunity now to get jfx in its current form (but improving the current deployment options) to have some web market space but once html5 settles I believe it will be a case of reinvention rather than improvement to then get any web market space. > ? My input: On the one hand you are saying that HTML 5 has not truly established itself, even though it was first published 5 years ago, but still you claim HTML5 is the likely winner. Then on the other hand you move on to claiming that Java based JavaFX (meaning JavaFX 2.x) has to win the race in its first 2 years of existence in order to make it. I think it is worth noting that new software projects start every day, and many of them will choose the technology that best suits their needs. Remember when Windows was the all dominating operating system and people thought no one else had a chance? What happened? Remember when Internet Explorer was the all dominating browser and people thought no one else had a chance? What happened? Remember when Nokia was the all dominating cell phone manufacturer in Europe and Apple had not even made a phone yet? What happened? Remember when gasoline was the all dominating propellant for cars and people thought electric cars had no chance? What is happening right now? > > All in all, I believe time will show that both HTML5 and JavaFX will have huge success. It all comes down to understanding the strengths of each technology, and knowing which technology best matches the exact requirements of the app you are building. Yep. I'm talking about competiting in the web space. Oracle is backing html5 in this space, I'm trying to ascertain if and how javafx can compete instead. Thanks for your comments, Dan From randahl at rockit.dk Sat Dec 1 14:44:47 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Sat, 1 Dec 2012 23:44:47 +0100 Subject: The competition In-Reply-To: <30169C4D-FA68-497E-8FB7-23858018E87B@gmail.com> References: <3DB35A93-2FD8-4440-8C1C-1CDA45CC4859@gmail.com> <30169C4D-FA68-497E-8FB7-23858018E87B@gmail.com> Message-ID: <09A10678-F0D6-4688-BE68-57F5897A85AA@rockit.dk> Dan, I am certainly not oblivious to the fact that downloading and installing Java has felt burdensome to many users historically, but I think you need to acknowledge that A. Java installation will become considerably faster with project Jigsaw. I am aware that this modularisation system has been postponed to Java 9 (2015), but nevertheless it shows where we are heading. B. Ten years ago low bandwidth meant that downloading Java was slow and painful. With high bandwidth connections rolling out in many countries, that part of the problem is gradually disappearing. The last ten years, my own home bandwidth has increased by a factor of 60, meaning that downloading Java now takes only 7 seconds. C. With the modern autoupdate features of most operating systems the installation is only done manually once per computer, after which point the autoupdate feature takes over. If the user reinstalls his computer once every two years, then Java is a less than a minute download every two years. I think many users consider that quite bearable. D. Many users already have the latest installation of Java. In Denmark in Scandinavia where I live, the latest version of Java has a 100.0% penetration among all 5.6 million residents. Why? Because our nationwide common login system called NemID is based on it. In Denmark you cannot log in to your home banking system or the tax authorities' website without it. I am not saying that Denmark is a typical example in this regard, but do not forget that many users in other countries might have already installed Java for accessing their home banking system, for gaming, or for using all sorts of Java based application services. I believe this is a way better situation than what Flash had ? Java is a requirement for many need-to-have applications, whereas flash often only was a requirement for accessing non-need-to-have content. Finally, please also realise that while there are things that HTML5 does better than JavaFX, there are also things JavaFX does best. It will never be a winner-takes-all competition. If your next application is a product catalog consisting mainly of pages of content for the user to browse, who in their right mind would not choose HTML5 for this? On the other hand, if your next application is a home interior design application allowing users to visualise prefabricated kitchen cupboards in a virtual model of their own home, who would not choose JavaFX over HTML5? Randahl. On Dec 1, 2012, at 22:56 , Daniel Zwolenski wrote: > Hi Randahl, > > Thanks for your comments I appreciate hearing an alternative point of view. > > One thing to keep in mind is that all of my comments are within the context of the web/consumer space (unfortunately this space doesn't have a good name so it's harder to define). > >> Richard has already asked you to provide documentation to back up your performance claims, > > I responded to this. There is another thread on performance where someone (I think Michael) made the claim that jfx was slow (in some cases 2-3 times slower than awt) and my own experiences have shown problems. I'd suggest continuing that conversation on that thread if needed since the original poster of that question made a good attempt at phrasing these questions (and in my opinion leaving that thread unanswered was far worse for perception than leaving this one unanswered - surprised Richard let it unrebuked based on his stance on performance). > > I look forward to seeing Richard's documentation on benchmarks when he has a chance to release them. > > >> Your claim: Web is [?] a deployment model that is seamless across more platforms. >> ? My input: You are right that deployment of web apps feels easy, but truly ensuring that the deployment actually works for all users on all platforms is all but a trivial task. There are literally hundreds of different web browser brands and versions out there, and the fact that you tested your latest web app on the two latest versions of a couple of browsers, gives you no guarantee that the web app works for all of the target audience. Have a look at this list, that documents the insanity of the web deployment challenge: http://www.useragentstring.com/pages/Browserlist/. >> The truth is that some web developers close their eyes to the heterogeneous nature of the deployment environment, and simply define their target audience as "users who use the latest version of Internet Explorer on Windows". That may give you a warm and fuzzy feeling of simplicity and ease of deployment, but in reality it just means that your web app is most likely broken for everyone who falls outside your defined target audience. Knowing that all of your desktop users run Oracle's version of Java is a way better than knowing that all of your users run either Internet Explorer or Chrome or Safari or Firefox or yet another browser. > > Agreed there are challenges with supporting lots of different browsers. > > My comment was that the user experience for "deployment" (ie getting a webapp running) is seamless (go to this URL). Once running, bug free cross-platform "consistency" is harder to achieve but the onus for this is on the developer (you have to test and run on every platform and tweak as needed). > > To me your argument here is that jfx having a single platform is the better "developer" experience and I totally agree. I hate debugging and fixing cross browser problems as much as the next developer but my users don't care that I hate doing it. My users would care however, if I told them that to run my app they have to first go to an oracle site and install java. > > A single platform for jfx is definitely a huge selling point for it and good that you added that to the analysis, but it is a selling point to the developers, not end users. You argue that the kick-on effect (ie developer is happy so they can do a better/quicker job) is a selling point to the user but your user would be weighing this somewhat unquantifiable benefit against the very comprehensible drawback of having to install java and the problems that come with that. > > As a side note the web space is traditionally horrid for x-browser but is improving rapidly and many frameworks like jquery and twitter bootstrap are making x-browser support much, much easier to achieve. I just released a webapp with moderate level of jscript that needed less than a week of testing/tweaking to work on IE7 - IE10, Firefox, chrome, safari, on WinXP - Win7 and Mac. I was pretty shocked myself that it worked based on my previous experiences (had braced myself for pain). IE10 still has some of the usual ms quirks but it is a far cry from the old days of ie 6 and ie 7. > > Also worth noting is that even with one platform, jfx has its own win vs mac vs Linux issues and you need to test and tweak on everyone (and build if you're using native installers). > > As a developer though the idea of one platform is one of the big selling points to me, as it sounds like it is for you. > > >> Your claim: [JavaFX is] based on established, type-safe java [?] However there is little benefit to users [in this]. >> ? My input: Everyone who has tried debugging a web application with more than 20.000 lines of JavaScript code knows that the lack of compile-time checks and type safety means JavaScript is more error prone. More errors means more time spent on debugging and less time spent on providing new features or improving the overall product quality. I hope you agree that users prefer robust, feature rich, high quality applications. > > Again, this is a (big) selling point to developers. You can argue the kick on benefits of more features and less bugs but that's hard to quantify and stack up against quantifiable things like installation and even availability and cost of jfx developers in the market vs web. > > In terms of getting features out quicker web developers would argue that they can get more features out in less time than a java app and this would be the established perception out there - how do you prove you are right and they are wrong (and the proliferation of rapidly released webapps and lack of jfx apps would put the burden of proof on the jfx developer)? > > It certainly is possible to build a robust, bug free webapp too. Atlassian tool suite, google analytics, Facebook, gmail, etc, etc - when we are telling our users that jfx will be less buggy than a webapp, how do we convince them of that when they are already using plenty of robust webapps in their daily lives? > >> Your claim: Should [JavaFX] not gain market space before the [HTML5] era truly establishes itself then [JavaFX] is unlikely to ever make it [?]. > > You snipped just before the important bit: "in it's current form". > > Also we're talking about the web space and competing with HTML. As I go on to say there are other areas where jfx can continue to be a contender but those areas were not the focus of my email. > > My opinion is that once the html5 era stabilizes it will be unlikely that jfx will offer much to that will allow it to break into the web space unless it innovates. Browser plugins will be dead so webstart and applets will be out, leaving no true web deployment option. > > I do not say that jfx will be dead only that it's current strategies for operating in the web will never work and new ones will be needed *if* jfx ever does want to try and compete in the web space (ie if oracle change their mind about not being interested in this space). > > One way this could happen for example is to not compete directly but to run ontop of jscript either at runtime or by precompiling the java/jfx app to jscript (ie like gwt does, in fact jfx-for-gwt would be a good avenue to look at though I suspect gwt is on the technology down curve with html5 rendering it somewhat obsolete). > > Alternatively the trend towards app stores may actually open more doors for jfx. In essence the OS vendors are potentially providing us with a deployment solution (yay!). In terms of the space I am looking at, keeping an eye on these app stores and there challenges regarding legals and technical restrictions is very high on the list. It's a good example of why I feel this sort of analysis is needed - what are the trends, opportunities, risks and what's our strategy as a result. > > Basically my analysis is that there is a small window of opportunity now to get jfx in its current form (but improving the current deployment options) to have some web market space but once html5 settles I believe it will be a case of reinvention rather than improvement to then get any web market space. > > >> ? My input: On the one hand you are saying that HTML 5 has not truly established itself, even though it was first published 5 years ago, but still you claim HTML5 is the likely winner. Then on the other hand you move on to claiming that Java based JavaFX (meaning JavaFX 2.x) has to win the race in its first 2 years of existence in order to make it. I think it is worth noting that new software projects start every day, and many of them will choose the technology that best suits their needs. Remember when Windows was the all dominating operating system and people thought no one else had a chance? What happened? Remember when Internet Explorer was the all dominating browser and people thought no one else had a chance? What happened? Remember when Nokia was the all dominating cell phone manufacturer in Europe and Apple had not even made a phone yet? What happened? Remember when gasoline was the all dominating propellant for cars and people thought electric cars had no chance? What is happening right now? >> >> All in all, I believe time will show that both HTML5 and JavaFX will have huge success. It all comes down to understanding the strengths of each technology, and knowing which technology best matches the exact requirements of the app you are building. > > Yep. I'm talking about competiting in the web space. Oracle is backing html5 in this space, I'm trying to ascertain if and how javafx can compete instead. > > Thanks for your comments, > Dan > From zonski at gmail.com Sat Dec 1 15:38:42 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sun, 2 Dec 2012 10:38:42 +1100 Subject: The competition In-Reply-To: <09A10678-F0D6-4688-BE68-57F5897A85AA@rockit.dk> References: <3DB35A93-2FD8-4440-8C1C-1CDA45CC4859@gmail.com> <30169C4D-FA68-497E-8FB7-23858018E87B@gmail.com> <09A10678-F0D6-4688-BE68-57F5897A85AA@rockit.dk> Message-ID: > On the other hand, if your next application is a home interior design application allowing users to visualise prefabricated kitchen cupboards in a virtual model of their own home, who would not choose JavaFX over HTML5? Right now, how would you build such an application in JFX (putting aside the issue of deployment, JFX doesn't yet have 3d support)? I don't believe it would be possible, certainly not easy? Web on the other hand does have some visually impressive 3D support, though it is in its early stages (but much further along than JFX). For example check out: http://www.ambiera.com/copperlicht/demos.html http://joostn.github.com/OpenJsCad/ I don't know of any existing examples of doing that sort of stuff in JFX? You will need a webGL enabled browser (chrome, firefox work, but IE will need a plugin, much like the one needed to run JFX). If we are saying it's ok to demand that our users go through the hassle of installing Java/JFX to run our rich apps, then we have to allow that its ok for a web developer to demand that a user goes through the (smaller) hassle of upgrading or even switching their browser to use their rich apps. I don't think there's any denying that the process of installing Google Chrome or Firefox is significantly more user friendly and intuitive than the process of installing Java. As I said there is a very small window of opportunity for JFX to compete in the web space while this "html5" stuff is still new and unsettled. That window is rapidly closing however, as things like webGL become more standard and robust. Once html5 settles, my prediction that the answer to your question of who would choose JavaFX over HTML5 for home-modelling software would be "very few people". Plenty of developers would rather not write the JScript code for it, I give you that, but the deciding factor will be the fact that if they do they can then simply send out a URL and it will all just instantly work on their client's machines. To managers, sales people and even system admins choosing JScript over JFX for your home modelling software will be a no-brainer, it will be only the developer having a bit of a grumble about "not liking" JScript and as track record has shown it's not the developer who will be making this decision (otherwise we'd all be using linux). Just to be clear as a developer, I am sold on JFX as the better "developer" platform and I want to use it (or I wouldn't be spending my weekends working on all this). The problem I have is that my users don't care about JFX or JScript or type safe vs not, they care about being able to do their business with minimal fuss. The platform that delivers that is the one I will have to use whether I like it or not. And just to clearly re-state I am talking about JFX competing in the webapp space (i.e. the space currently dominated by web). On Sun, Dec 2, 2012 at 9:44 AM, Randahl Fink Isaksen wrote: > Dan, > > I am certainly not oblivious to the fact that downloading and installing > Java has felt burdensome to many users historically, but I think you need > to acknowledge that > > A. Java installation will become considerably faster with project Jigsaw. > I am aware that this modularisation system has been postponed to Java 9 > (2015), but nevertheless it shows where we are heading. > > B. Ten years ago low bandwidth meant that downloading Java was slow and > painful. With high bandwidth connections rolling out in many countries, > that part of the problem is gradually disappearing. The last ten years, my > own home bandwidth has increased by a factor of 60, meaning that > downloading Java now takes only 7 seconds. > > C. With the modern autoupdate features of most operating systems the > installation is only done manually once per computer, after which point the > autoupdate feature takes over. If the user reinstalls his computer once > every two years, then Java is a less than a minute download every two > years. I think many users consider that quite bearable. > > D. Many users already have the latest installation of Java. In Denmark in > Scandinavia where I live, the latest version of Java has a 100.0% > penetration among all 5.6 million residents. Why? Because our nationwide > common login system called NemID is based on it. In Denmark you cannot log > in to your home banking system or the tax authorities' website without it. > I am not saying that Denmark is a typical example in this regard, but do > not forget that many users in other countries might have already installed > Java for accessing their home banking system, for gaming, or for using all > sorts of Java based application services. I believe this is a way better > situation than what Flash had ? Java is a requirement for many need-to-have > applications, whereas flash often only was a requirement for accessing > non-need-to-have content. > > Finally, please also realise that while there are things that HTML5 does > better than JavaFX, there are also things JavaFX does best. It will never > be a winner-takes-all competition. If your next application is a product > catalog consisting mainly of pages of content for the user to browse, who > in their right mind would not choose HTML5 for this? On the other hand, if > your next application is a home interior design application allowing users > to visualise prefabricated kitchen cupboards in a virtual model of their > own home, who would not choose JavaFX over HTML5? > > Randahl. > > > On Dec 1, 2012, at 22:56 , Daniel Zwolenski wrote: > > Hi Randahl, > > Thanks for your comments I appreciate hearing an alternative point of > view. > > One thing to keep in mind is that all of my comments are within the > context of the web/consumer space (unfortunately this space doesn't have a > good name so it's harder to define). > > Richard has already asked you to provide documentation to back up your > performance claims, > > > I responded to this. There is another thread on performance where someone > (I think Michael) made the claim that jfx was slow (in some cases 2-3 times > slower than awt) and my own experiences have shown problems. I'd suggest > continuing that conversation on that thread if needed since the original > poster of that question made a good attempt at phrasing these questions > (and in my opinion leaving that thread unanswered was far worse for > perception than leaving this one unanswered - surprised Richard let it > unrebuked based on his stance on performance). > > I look forward to seeing Richard's documentation on benchmarks when he has > a chance to release them. > > > Your claim: *Web is [?] a deployment model that is seamless across more > platforms.* > ? My input: You are right that deployment of web apps *feels* easy, but > truly ensuring that the deployment actually works for all users on all > platforms is all but a trivial task. There are literally hundreds of > different web browser brands and versions out there, and the fact that you > tested your latest web app on the two latest versions of a couple of > browsers, gives you no guarantee that the web app works for all of the > target audience. Have a look at this list, that documents the insanity of > the web deployment challenge: > http://www.useragentstring.com/pages/Browserlist/. > The truth is that some web developers close their eyes to the > heterogeneous nature of the deployment environment, and simply define their > target audience as *"users who use the latest version of Internet > Explorer on Windows"*. That may give you a warm and fuzzy feeling of > simplicity and ease of deployment, but in reality it just means that your > web app is most likely broken for everyone who falls outside your defined > target audience. Knowing that all of your desktop users run Oracle's > version of Java is a way better than knowing that all of your users run > either Internet Explorer or Chrome or Safari or Firefox or yet another > browser. > > > Agreed there are challenges with supporting lots of different browsers. > > My comment was that the user experience for "deployment" (ie getting a > webapp running) is seamless (go to this URL). Once running, bug free > cross-platform "consistency" is harder to achieve but the onus for this is > on the developer (you have to test and run on every platform and tweak as > needed). > > To me your argument here is that jfx having a single platform is the > better "developer" experience and I totally agree. I hate debugging and > fixing cross browser problems as much as the next developer but my users > don't care that I hate doing it. My users would care however, if I told > them that to run my app they have to first go to an oracle site and install > java. > > A single platform for jfx is definitely a huge selling point for it and > good that you added that to the analysis, but it is a selling point to the > developers, not end users. You argue that the kick-on effect (ie developer > is happy so they can do a better/quicker job) is a selling point to the > user but your user would be weighing this somewhat unquantifiable benefit > against the very comprehensible drawback of having to install java and the > problems that come with that. > > As a side note the web space is traditionally horrid for x-browser but is > improving rapidly and many frameworks like jquery and twitter bootstrap are > making x-browser support much, much easier to achieve. I just released a > webapp with moderate level of jscript that needed less than a week of > testing/tweaking to work on IE7 - IE10, Firefox, chrome, safari, on WinXP - > Win7 and Mac. I was pretty shocked myself that it worked based on my > previous experiences (had braced myself for pain). IE10 still has some of > the usual ms quirks but it is a far cry from the old days of ie 6 and ie 7. > > Also worth noting is that even with one platform, jfx has its own win vs > mac vs Linux issues and you need to test and tweak on everyone (and build > if you're using native installers). > > As a developer though the idea of one platform is one of the big selling > points to me, as it sounds like it is for you. > > > Your claim:* [JavaFX is] based on established, type-safe java [?] However > there is little benefit to users [in this].* > ? My input: Everyone who has tried debugging a web application with more > than 20.000 lines of JavaScript code knows that the lack of compile-time > checks and type safety means JavaScript is more error prone. More errors > means more time spent on debugging and less time spent on providing new > features or improving the overall product quality. I hope you agree that > users prefer robust, feature rich, high quality applications. > > > Again, this is a (big) selling point to developers. You can argue the kick > on benefits of more features and less bugs but that's hard to quantify and > stack up against quantifiable things like installation and even > availability and cost of jfx developers in the market vs web. > > In terms of getting features out quicker web developers would argue that > they can get more features out in less time than a java app and this would > be the established perception out there - how do you prove you are right > and they are wrong (and the proliferation of rapidly released webapps and > lack of jfx apps would put the burden of proof on the jfx developer)? > > It certainly is possible to build a robust, bug free webapp too. Atlassian > tool suite, google analytics, Facebook, gmail, etc, etc - when we are > telling our users that jfx will be less buggy than a webapp, how do we > convince them of that when they are already using plenty of robust webapps > in their daily lives? > > Your claim: *Should [JavaFX] not gain market space before the [HTML5] era > truly establishes itself then [JavaFX] is unlikely to ever make it [?].* > > > You snipped just before the important bit: "in it's current form". > > Also we're talking about the web space and competing with HTML. As I go on > to say there are other areas where jfx can continue to be a contender but > those areas were not the focus of my email. > > My opinion is that once the html5 era stabilizes it will be unlikely that > jfx will offer much to that will allow it to break into the web space > unless it innovates. Browser plugins will be dead so webstart and applets > will be out, leaving no true web deployment option. > > I do not say that jfx will be dead only that it's current strategies for > operating in the web will never work and new ones will be needed *if* jfx > ever does want to try and compete in the web space (ie if oracle change > their mind about not being interested in this space). > > One way this could happen for example is to not compete directly but to > run ontop of jscript either at runtime or by precompiling the java/jfx app > to jscript (ie like gwt does, in fact jfx-for-gwt would be a good avenue to > look at though I suspect gwt is on the technology down curve with html5 > rendering it somewhat obsolete). > > Alternatively the trend towards app stores may actually open more doors > for jfx. In essence the OS vendors are potentially providing us with a > deployment solution (yay!). In terms of the space I am looking at, keeping > an eye on these app stores and there challenges regarding legals and > technical restrictions is very high on the list. It's a good example of why > I feel this sort of analysis is needed - what are the trends, > opportunities, risks and what's our strategy as a result. > > Basically my analysis is that there is a small window of opportunity now > to get jfx in its current form (but improving the current deployment > options) to have some web market space but once html5 settles I believe it > will be a case of reinvention rather than improvement to then get any web > market space. > > > ? My input: On the one hand you are saying that HTML 5 has not truly > established itself, even though it was first published 5 years ago, but > still you claim HTML5 is the likely winner. Then on the other hand you move > on to claiming that Java based JavaFX (meaning JavaFX 2.x) has to win the > race in its first 2 years of existence in order to make it. I think it is > worth noting that new software projects start every day, and many of them > will choose the technology that best suits their needs. Remember when > Windows was the all dominating operating system and people thought no one > else had a chance? What happened? Remember when Internet Explorer was the > all dominating browser and people thought no one else had a chance? What > happened? Remember when Nokia was the all dominating cell phone > manufacturer in Europe and Apple had not even made a phone yet? What > happened? Remember when gasoline was the all dominating propellant for cars > and people thought electric cars had no chance? What is happening right now? > > All in all, I believe time will show that both HTML5 and JavaFX will have > huge success. It all comes down to understanding the strengths of each > technology, and knowing which technology best matches the exact > requirements of the app you are building. > > > Yep. I'm talking about competiting in the web space. Oracle is backing > html5 in this space, I'm trying to ascertain if and how javafx can compete > instead. > > Thanks for your comments, > Dan > > > From zonski at gmail.com Sat Dec 1 15:49:11 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sun, 2 Dec 2012 10:49:11 +1100 Subject: Layouts with constraint classes In-Reply-To: <50BA53D4.7090504@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> <50B87AF8.3050200@tbee.org> <50B88858.4080500@tbee.org> <50B9AF27.6040903@tbee.org> <50B9B5FD.5020501@tbee.org> <50B9F0D9.6090608@bestsolution.at> <50BA53D4.7090504@tbee.org> Message-ID: Which could also be achieved with builders and listeners - I'll leave that as an exercise for the reader :) This whole thread is a great example where a clean underlying Java API with good separation of concerns between domains (in this case FXML and Java API) with appropriate glue in between can allow for the most flexibility and future variations and extensions. If only this same philosophy had been taken with CSS... On Sun, Dec 2, 2012 at 6:00 AM, Tom Eugelink wrote: > Since it is an equal relationship, it is defend-able to set all > constraints on the node. > > > > > > > > > > > That would be a matter of taste. I prefer it the other way around, because > a layout is complicated enough without additional constraints of another > layout. > > Tom > > > > > On 2012-12-01 12:58, Tom Schindl wrote: > >> I agree predefining the constraint for a node that might get added >> somewhere feels wrong (=> your 2nd sample looks good!). That's why I >> think it makes no sense to store to constraint on the container but it >> should be stored on the node itself and when you move the Node you >> update the constraint. >> >> BTW: I think the samples would be more interesting if the source and >> target container are of different type. e.g. HBox => VBox >> >> Tom >> >> Am 01.12.12 11:57, schrieb Daniel Zwolenski: >> >>> I've slapped up two examples for you - they are pretty rough and could be >>> cleaned up, but it's just to demonstrate. >>> >>> >>> *Example 1* is basically how you requested it. >>> >>> The FXML looks like this: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> For the full FXML see: >>> http://code.google.com/p/**zenjava-playtime/source/** >>> browse/trunk/layouts/src/main/**resources/fxml/example1.fxml >>> (Note >>> that I defined the Animation in the FXML, but this is totally optional, >>> you >>> could define it in the controller). >>> >>> This needed a fair few support classes because you have to create new >>> builders for the layout manager. If this was a common use case then you >>> could put all the customised builders and constraint classes in something >>> like JFXtras for shared reuse. >>> >>> Main support class is the HBoxBuilder: >>> http://code.google.com/p/**zenjava-playtime/source/** >>> browse/trunk/layouts/src/main/**java/com/playtime/layouts/** >>> example1/CustomHBoxBuilder.**java >>> >>> (strangely extending the default HBoxBuilder didn't work with FXML - not >>> sure if I was just doing something dumb, I didn't look into it deeper) >>> >>> Other support classes are all in the same package: >>> http://code.google.com/p/**zenjava-playtime/source/** >>> browse/trunk/layouts/src/main/**java/com/playtime/layouts/**example1/ >>> >>> >>> *Example 2* is where the animation itself defines the constraints (as per >>> my suggestion). This one feels more natural to me as the animation knows >>> context and could decide to use a different layout depending on what >>> action >>> was picked. In the animation dance there is the source parent, the target >>> parent and the node being moved. All of these are 'passive' and only the >>> animation does the "action" and really knows that there is a move >>> happening >>> and why it is happening so in my book it is the one that should make >>> decisions about how the node looks when it is moved. That's a subjective >>> opinion though and you have both options to choose from. >>> >>> The FXML looks like this >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> newParent="$hbox2"> >>> >>> >>> >> newParent="$hbox1"> >>> >>> >>> >>> >>> There are considerably fewer/simpler support classes for this. The only >>> really interesting one is this: >>> >>> http://code.google.com/p/**zenjava-playtime/source/** >>> browse/trunk/layouts/src/main/**java/com/playtime/layouts/** >>> example2/MoveAnimation.java >>> >>> As a side note, the JFX animation/transition classes being final make the >>> code a little messier. This is one area where I would vote for relaxing >>> the >>> use of 'final' - extending transitions makes as much sense as extending >>> Nodes in my book. We can already extend Transition so I don't see why we >>> can't extend SequentialTransition for example. >>> >>> I hope this time I got it right and that solves your use case. My main >>> point though is that pretty much all of this sort of stuff *should* be >>> possible through the use of builders and support classes. The glue may >>> not >>> always be the nicest but the driving force should be to keep the FXML and >>> Java clean without compromising each other - the mess should be in the >>> glue >>> because only the glue author sees that, not the end user of the API, >>> that's >>> why the glue exists in the first place. >>> >>> >>> >>> >>> >>> On Sat, Dec 1, 2012 at 6:47 PM, Tom Eugelink wrote: >>> >>> Yes, correct :-) >>>> >>>> The approach where the constraint is set in the animation feels >>>> procedural >>>> and not declarative to me. Like you say yourself, I think it should be >>>> define like: when node X is part of this layout, use these constraints. >>>> In >>>> this way it is not relevant where the animation is defined or how the >>>> node >>>> got there. >>>> >>>> Tom >>>> >>>> >>>> >>>> On 2012-12-01 08:38, Daniel Zwolenski wrote: >>>> >>>> Ah ok, so in the first hbox you are saying when the "arrow" node is >>>>> moved >>>>> into here use these new constraints. I think I've got you now. >>>>> >>>>> That should be do-able using some more helper classes. I can knock some >>>>> up but my first thought would be to do it as part of the animation >>>>> since >>>>> its the thing that has the most knowledge about what's going on and >>>>> why. >>>>> >>>>> How/where do you define and trigger your animation - are you specifying >>>>> it in the FXML? If so the constraints could be part of that eg. (made >>>>> up >>>>> pseudo FXML): >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> (also slightly confusing is that the constraints you are using aren't >>>>> applicable to HBox) >>>>> >>>>> If you don't like that approach I can knock up the alternative? >>>>> >>>>> >>>>> >>>>> On 01/12/2012, at 6:17 PM, Tom Eugelink wrote: >>>>> >>>>> Because of animation the label may move from one HBox to the other. >>>>> This >>>>> >>>>>> is the reason why the current approach stores constraints inside the >>>>>> node, >>>>>> so that when it moves from layout A to B, the constraints also move. >>>>>> My >>>>>> approach allows to specify different constraints for the same node in >>>>>> each >>>>>> layout. >>>>>> >>>>>> You are right that there should be a parent layout, I left it out to >>>>>> not >>>>>> confuse things, but apparently that is confusing :-) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 2012-12-01 08:01, Daniel Zwolenski wrote: >>>>>> >>>>>> You've lost me. What are you expecting the actual view to look like >>>>>>> with this FXML? >>>>>>> >>>>>>> If I interpret it literally you've defined two HBox's one after the >>>>>>> other. The first one has no children and an unused constraint, the >>>>>>> second >>>>>>> one has a Label in it with a constraint on it. I'm guessing you are >>>>>>> trying >>>>>>> to do something more but it's not real clear what that more is? >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 01/12/2012, at 5:28 PM, Tom Eugelink wrote: >>>>>>> >>>>>>> Not variables, but references. There are constraints specified for >>>>>>> >>>>>>>> nodes that are not yet part of a layout (or even exist at that time, >>>>>>>> because they are declared further down). Note the absense of a >>>>>>>> label in the >>>>>>>> first HBox.C. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Tom >>>>>>>> >>>>>>>> >>>>>>>> On 2012-11-30 14:11, Daniel Zwolenski wrote: >>>>>>>> >>>>>>>> Ah ok, from your example code it looks like you want to use >>>>>>>>> variables >>>>>>>>> in FXML to define your constraints - getting into that territory of >>>>>>>>> CSS-like style definitions that Richard was talking about? >>>>>>>>> >>>>>>>>> Assuming this is what you want, this can be done in the current >>>>>>>>> setup >>>>>>>>> using the ridiculously under-documented thing. >>>>>>>>> >>>>>>>>> I knocked up a very rough sample for you quickly. The FXML looks >>>>>>>>> like >>>>>>>>> this: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> (see https://code.google.com/p/****zenjava-playtime/source/** >>>>>>>>> browse/trunk/layouts/src/main/****resources/fxml/example.fxml<** >>>>>>>>> https://code.google.com/p/**zenjava-playtime/source/** >>>>>>>>> browse/trunk/layouts/src/main/**resources/fxml/example.fxml >>>>>>>>> > >>>>>>>>> ) >>>>>>>>> >>>>>>>>> I made a base Constraints class with a static helper method on it >>>>>>>>> (called via "Constraints.constraints" in the FXML above): >>>>>>>>> https://code.google.com/p/****zenjava-playtime/source/** >>>>>>>>> browse/trunk/layouts/src/main/****java/com/playtime/layouts/** >>>>>>>>> Constraints.java>>>>>>>> source/browse/trunk/layouts/**src/main/java/com/playtime/** >>>>>>>>> layouts/Constraints.java >>>>>>>>> > >>>>>>>>> >>>>>>>>> And then a specific instance of HBoxConstraints: >>>>>>>>> https://code.google.com/p/****zenjava-playtime/source/** >>>>>>>>> browse/trunk/layouts/src/main/****java/com/playtime/layouts/** >>>>>>>>> HBoxConstraints.java>>>>>>>> playtime/source/browse/trunk/**layouts/src/main/java/com/** >>>>>>>>> playtime/layouts/**HBoxConstraints.java >>>>>>>>> > >>>>>>>>> >>>>>>>>> Obviously you would add others, like VBoxConstraints, >>>>>>>>> GridPaneConstraints, etc. All pretty trivial. These helper classes >>>>>>>>> could >>>>>>>>> easily be included in something like JFXtras. >>>>>>>>> >>>>>>>>> So I stick with the stance that FXML is more or less OK here (not >>>>>>>>> to >>>>>>>>> say I wouldn't improve it lots in other areas), and really your >>>>>>>>> conversation is about the Java API which is nicely decoupled to >>>>>>>>> what >>>>>>>>> can/can't be done in FXML. Kudos to Richard and the JFX team for >>>>>>>>> designing >>>>>>>>> the builders right. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Nov 30, 2012 at 9:20 PM, Tom Eugelink >>>>>>>> tbee at tbee.org>> wrote: >>>>>>>>> >>>>>>>>> On 2012-11-30 10:59, Daniel Zwolenski wrote: >>>>>>>>> >>>>>>>>> It just doesn't do it the exact way you suggest where you >>>>>>>>> specify multiple possibilities directly in the child in case it >>>>>>>>> ends up in >>>>>>>>> a different parent - not an approach I agree with anyway (see my >>>>>>>>> previous >>>>>>>>> comments), but that's just my opinion. >>>>>>>>> >>>>>>>>> >>>>>>>>> Just to make sure my suggestion is not misunderstood, it does >>>>>>>>> not >>>>>>>>> specify multiple possibilities in the child, but in the layout. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> > From randahl at rockit.dk Sat Dec 1 16:18:06 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Sun, 2 Dec 2012 01:18:06 +0100 Subject: The competition In-Reply-To: References: <3DB35A93-2FD8-4440-8C1C-1CDA45CC4859@gmail.com> <30169C4D-FA68-497E-8FB7-23858018E87B@gmail.com> <09A10678-F0D6-4688-BE68-57F5897A85AA@rockit.dk> Message-ID: While JavaFX does have 3D support (see the Ensemble demo under "Highlights"), the demos you provided to prove that HTML is better, do not work in Safari, the dominant browser on Mac. You state that the demos only work in Internet Explorer if you install a plugin, but that is still way better than a JavaFX solution, because JavaFX requires? a plugin. Forgive me, but I think we should end the debate here. Randahl On Dec 2, 2012, at 0:38 , Daniel Zwolenski wrote: > > On the other hand, if your next application is a home interior design application allowing users to visualise prefabricated kitchen cupboards in a virtual model of their own home, who would not choose JavaFX over HTML5? > > Right now, how would you build such an application in JFX (putting aside the issue of deployment, JFX doesn't yet have 3d support)? I don't believe it would be possible, certainly not easy? > > Web on the other hand does have some visually impressive 3D support, though it is in its early stages (but much further along than JFX). > > For example check out: > http://www.ambiera.com/copperlicht/demos.html > http://joostn.github.com/OpenJsCad/ > > I don't know of any existing examples of doing that sort of stuff in JFX? > > You will need a webGL enabled browser (chrome, firefox work, but IE will need a plugin, much like the one needed to run JFX). If we are saying it's ok to demand that our users go through the hassle of installing Java/JFX to run our rich apps, then we have to allow that its ok for a web developer to demand that a user goes through the (smaller) hassle of upgrading or even switching their browser to use their rich apps. I don't think there's any denying that the process of installing Google Chrome or Firefox is significantly more user friendly and intuitive than the process of installing Java. > > As I said there is a very small window of opportunity for JFX to compete in the web space while this "html5" stuff is still new and unsettled. That window is rapidly closing however, as things like webGL become more standard and robust. > > Once html5 settles, my prediction that the answer to your question of who would choose JavaFX over HTML5 for home-modelling software would be "very few people". Plenty of developers would rather not write the JScript code for it, I give you that, but the deciding factor will be the fact that if they do they can then simply send out a URL and it will all just instantly work on their client's machines. To managers, sales people and even system admins choosing JScript over JFX for your home modelling software will be a no-brainer, it will be only the developer having a bit of a grumble about "not liking" JScript and as track record has shown it's not the developer who will be making this decision (otherwise we'd all be using linux). > > Just to be clear as a developer, I am sold on JFX as the better "developer" platform and I want to use it (or I wouldn't be spending my weekends working on all this). The problem I have is that my users don't care about JFX or JScript or type safe vs not, they care about being able to do their business with minimal fuss. The platform that delivers that is the one I will have to use whether I like it or not. > > And just to clearly re-state I am talking about JFX competing in the webapp space (i.e. the space currently dominated by web). > > > > On Sun, Dec 2, 2012 at 9:44 AM, Randahl Fink Isaksen wrote: > Dan, > > I am certainly not oblivious to the fact that downloading and installing Java has felt burdensome to many users historically, but I think you need to acknowledge that > > A. Java installation will become considerably faster with project Jigsaw. I am aware that this modularisation system has been postponed to Java 9 (2015), but nevertheless it shows where we are heading. > > B. Ten years ago low bandwidth meant that downloading Java was slow and painful. With high bandwidth connections rolling out in many countries, that part of the problem is gradually disappearing. The last ten years, my own home bandwidth has increased by a factor of 60, meaning that downloading Java now takes only 7 seconds. > > C. With the modern autoupdate features of most operating systems the installation is only done manually once per computer, after which point the autoupdate feature takes over. If the user reinstalls his computer once every two years, then Java is a less than a minute download every two years. I think many users consider that quite bearable. > > D. Many users already have the latest installation of Java. In Denmark in Scandinavia where I live, the latest version of Java has a 100.0% penetration among all 5.6 million residents. Why? Because our nationwide common login system called NemID is based on it. In Denmark you cannot log in to your home banking system or the tax authorities' website without it. I am not saying that Denmark is a typical example in this regard, but do not forget that many users in other countries might have already installed Java for accessing their home banking system, for gaming, or for using all sorts of Java based application services. I believe this is a way better situation than what Flash had ? Java is a requirement for many need-to-have applications, whereas flash often only was a requirement for accessing non-need-to-have content. > > Finally, please also realise that while there are things that HTML5 does better than JavaFX, there are also things JavaFX does best. It will never be a winner-takes-all competition. If your next application is a product catalog consisting mainly of pages of content for the user to browse, who in their right mind would not choose HTML5 for this? On the other hand, if your next application is a home interior design application allowing users to visualise prefabricated kitchen cupboards in a virtual model of their own home, who would not choose JavaFX over HTML5? > > Randahl. > > > On Dec 1, 2012, at 22:56 , Daniel Zwolenski wrote: > >> Hi Randahl, >> >> Thanks for your comments I appreciate hearing an alternative point of view. >> >> One thing to keep in mind is that all of my comments are within the context of the web/consumer space (unfortunately this space doesn't have a good name so it's harder to define). >> >>> Richard has already asked you to provide documentation to back up your performance claims, >> >> I responded to this. There is another thread on performance where someone (I think Michael) made the claim that jfx was slow (in some cases 2-3 times slower than awt) and my own experiences have shown problems. I'd suggest continuing that conversation on that thread if needed since the original poster of that question made a good attempt at phrasing these questions (and in my opinion leaving that thread unanswered was far worse for perception than leaving this one unanswered - surprised Richard let it unrebuked based on his stance on performance). >> >> I look forward to seeing Richard's documentation on benchmarks when he has a chance to release them. >> >> >>> Your claim: Web is [?] a deployment model that is seamless across more platforms. >>> ? My input: You are right that deployment of web apps feels easy, but truly ensuring that the deployment actually works for all users on all platforms is all but a trivial task. There are literally hundreds of different web browser brands and versions out there, and the fact that you tested your latest web app on the two latest versions of a couple of browsers, gives you no guarantee that the web app works for all of the target audience. Have a look at this list, that documents the insanity of the web deployment challenge: http://www.useragentstring.com/pages/Browserlist/. >>> The truth is that some web developers close their eyes to the heterogeneous nature of the deployment environment, and simply define their target audience as "users who use the latest version of Internet Explorer on Windows". That may give you a warm and fuzzy feeling of simplicity and ease of deployment, but in reality it just means that your web app is most likely broken for everyone who falls outside your defined target audience. Knowing that all of your desktop users run Oracle's version of Java is a way better than knowing that all of your users run either Internet Explorer or Chrome or Safari or Firefox or yet another browser. >> >> Agreed there are challenges with supporting lots of different browsers. >> >> My comment was that the user experience for "deployment" (ie getting a webapp running) is seamless (go to this URL). Once running, bug free cross-platform "consistency" is harder to achieve but the onus for this is on the developer (you have to test and run on every platform and tweak as needed). >> >> To me your argument here is that jfx having a single platform is the better "developer" experience and I totally agree. I hate debugging and fixing cross browser problems as much as the next developer but my users don't care that I hate doing it. My users would care however, if I told them that to run my app they have to first go to an oracle site and install java. >> >> A single platform for jfx is definitely a huge selling point for it and good that you added that to the analysis, but it is a selling point to the developers, not end users. You argue that the kick-on effect (ie developer is happy so they can do a better/quicker job) is a selling point to the user but your user would be weighing this somewhat unquantifiable benefit against the very comprehensible drawback of having to install java and the problems that come with that. >> >> As a side note the web space is traditionally horrid for x-browser but is improving rapidly and many frameworks like jquery and twitter bootstrap are making x-browser support much, much easier to achieve. I just released a webapp with moderate level of jscript that needed less than a week of testing/tweaking to work on IE7 - IE10, Firefox, chrome, safari, on WinXP - Win7 and Mac. I was pretty shocked myself that it worked based on my previous experiences (had braced myself for pain). IE10 still has some of the usual ms quirks but it is a far cry from the old days of ie 6 and ie 7. >> >> Also worth noting is that even with one platform, jfx has its own win vs mac vs Linux issues and you need to test and tweak on everyone (and build if you're using native installers). >> >> As a developer though the idea of one platform is one of the big selling points to me, as it sounds like it is for you. >> >> >>> Your claim: [JavaFX is] based on established, type-safe java [?] However there is little benefit to users [in this]. >>> ? My input: Everyone who has tried debugging a web application with more than 20.000 lines of JavaScript code knows that the lack of compile-time checks and type safety means JavaScript is more error prone. More errors means more time spent on debugging and less time spent on providing new features or improving the overall product quality. I hope you agree that users prefer robust, feature rich, high quality applications. >> >> Again, this is a (big) selling point to developers. You can argue the kick on benefits of more features and less bugs but that's hard to quantify and stack up against quantifiable things like installation and even availability and cost of jfx developers in the market vs web. >> >> In terms of getting features out quicker web developers would argue that they can get more features out in less time than a java app and this would be the established perception out there - how do you prove you are right and they are wrong (and the proliferation of rapidly released webapps and lack of jfx apps would put the burden of proof on the jfx developer)? >> >> It certainly is possible to build a robust, bug free webapp too. Atlassian tool suite, google analytics, Facebook, gmail, etc, etc - when we are telling our users that jfx will be less buggy than a webapp, how do we convince them of that when they are already using plenty of robust webapps in their daily lives? >> >>> Your claim: Should [JavaFX] not gain market space before the [HTML5] era truly establishes itself then [JavaFX] is unlikely to ever make it [?]. >> >> You snipped just before the important bit: "in it's current form". >> >> Also we're talking about the web space and competing with HTML. As I go on to say there are other areas where jfx can continue to be a contender but those areas were not the focus of my email. >> >> My opinion is that once the html5 era stabilizes it will be unlikely that jfx will offer much to that will allow it to break into the web space unless it innovates. Browser plugins will be dead so webstart and applets will be out, leaving no true web deployment option. >> >> I do not say that jfx will be dead only that it's current strategies for operating in the web will never work and new ones will be needed *if* jfx ever does want to try and compete in the web space (ie if oracle change their mind about not being interested in this space). >> >> One way this could happen for example is to not compete directly but to run ontop of jscript either at runtime or by precompiling the java/jfx app to jscript (ie like gwt does, in fact jfx-for-gwt would be a good avenue to look at though I suspect gwt is on the technology down curve with html5 rendering it somewhat obsolete). >> >> Alternatively the trend towards app stores may actually open more doors for jfx. In essence the OS vendors are potentially providing us with a deployment solution (yay!). In terms of the space I am looking at, keeping an eye on these app stores and there challenges regarding legals and technical restrictions is very high on the list. It's a good example of why I feel this sort of analysis is needed - what are the trends, opportunities, risks and what's our strategy as a result. >> >> Basically my analysis is that there is a small window of opportunity now to get jfx in its current form (but improving the current deployment options) to have some web market space but once html5 settles I believe it will be a case of reinvention rather than improvement to then get any web market space. >> >> >>> ? My input: On the one hand you are saying that HTML 5 has not truly established itself, even though it was first published 5 years ago, but still you claim HTML5 is the likely winner. Then on the other hand you move on to claiming that Java based JavaFX (meaning JavaFX 2.x) has to win the race in its first 2 years of existence in order to make it. I think it is worth noting that new software projects start every day, and many of them will choose the technology that best suits their needs. Remember when Windows was the all dominating operating system and people thought no one else had a chance? What happened? Remember when Internet Explorer was the all dominating browser and people thought no one else had a chance? What happened? Remember when Nokia was the all dominating cell phone manufacturer in Europe and Apple had not even made a phone yet? What happened? Remember when gasoline was the all dominating propellant for cars and people thought electric cars had no chance? What is happening right now? >>> >>> All in all, I believe time will show that both HTML5 and JavaFX will have huge success. It all comes down to understanding the strengths of each technology, and knowing which technology best matches the exact requirements of the app you are building. >> >> Yep. I'm talking about competiting in the web space. Oracle is backing html5 in this space, I'm trying to ascertain if and how javafx can compete instead. >> >> Thanks for your comments, >> Dan >> > > From zonski at gmail.com Sat Dec 1 17:53:07 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sun, 2 Dec 2012 12:53:07 +1100 Subject: The competition In-Reply-To: References: <3DB35A93-2FD8-4440-8C1C-1CDA45CC4859@gmail.com> <30169C4D-FA68-497E-8FB7-23858018E87B@gmail.com> <09A10678-F0D6-4688-BE68-57F5897A85AA@rockit.dk> Message-ID: > > While JavaFX does have 3D support (see the Ensemble demo under > "Highlights"), > As I understand it, it is limited, psuedo-3D (also called 2.5D). Full 3D is on the roadmap: http://www.oracle.com/technetwork/java/javafx/overview/roadmap-1446331.html > the demos you provided to prove that HTML is better, do not work in > Safari, the dominant browser on Mac. > Have you enabled webGL? https://discussions.apple.com/thread/3300585?start=0&tstart=0 > You state that the demos only work in Internet Explorer if you install a > plugin, but that is still way better than a JavaFX solution, because JavaFX > requires? a plugin. > I state that web 3D (like most "html5" features) is new and raw and there is a window of opportunity for JFX to get in while MS and the others still argue over stuff like this (IE will have a built-in 3D solution soon - the exact form has not been revealed and there is obvious vendor posturing going on). I state that this window is closing. Forgive me, but I think we should end the debate here. > No worries. Thanks for the discussion. > > Randahl > > > > > On Dec 2, 2012, at 0:38 , Daniel Zwolenski wrote: > > > On the other hand, if your next application is a home interior design > application allowing users to visualise prefabricated kitchen cupboards in > a virtual model of their own home, who would not choose JavaFX over HTML5? > > Right now, how would you build such an application in JFX (putting aside > the issue of deployment, JFX doesn't yet have 3d support)? I don't believe > it would be possible, certainly not easy? > > Web on the other hand does have some visually impressive 3D support, > though it is in its early stages (but much further along than JFX). > > For example check out: > http://www.ambiera.com/copperlicht/demos.html > http://joostn.github.com/OpenJsCad/ > > I don't know of any existing examples of doing that sort of stuff in JFX? > > You will need a webGL enabled browser (chrome, firefox work, but IE will > need a plugin, much like the one needed to run JFX). If we are saying it's > ok to demand that our users go through the hassle of installing Java/JFX to > run our rich apps, then we have to allow that its ok for a web developer to > demand that a user goes through the (smaller) hassle of upgrading or even > switching their browser to use their rich apps. I don't think there's any > denying that the process of installing Google Chrome or Firefox is > significantly more user friendly and intuitive than the process of > installing Java. > > As I said there is a very small window of opportunity for JFX to compete > in the web space while this "html5" stuff is still new and unsettled. That > window is rapidly closing however, as things like webGL become more > standard and robust. > > Once html5 settles, my prediction that the answer to your question of who > would choose JavaFX over HTML5 for home-modelling software would be "very > few people". Plenty of developers would rather not write the JScript code > for it, I give you that, but the deciding factor will be the fact that if > they do they can then simply send out a URL and it will all just instantly > work on their client's machines. To managers, sales people and even system > admins choosing JScript over JFX for your home modelling software will be a > no-brainer, it will be only the developer having a bit of a grumble about > "not liking" JScript and as track record has shown it's not the developer > who will be making this decision (otherwise we'd all be using linux). > > Just to be clear as a developer, I am sold on JFX as the better > "developer" platform and I want to use it (or I wouldn't be spending my > weekends working on all this). The problem I have is that my users don't > care about JFX or JScript or type safe vs not, they care about being able > to do their business with minimal fuss. The platform that delivers that is > the one I will have to use whether I like it or not. > > And just to clearly re-state I am talking about JFX competing in the > webapp space (i.e. the space currently dominated by web). > > > > On Sun, Dec 2, 2012 at 9:44 AM, Randahl Fink Isaksen wrote: > >> Dan, >> >> I am certainly not oblivious to the fact that downloading and installing >> Java has felt burdensome to many users historically, but I think you need >> to acknowledge that >> >> A. Java installation will become considerably faster with project Jigsaw. >> I am aware that this modularisation system has been postponed to Java 9 >> (2015), but nevertheless it shows where we are heading. >> >> B. Ten years ago low bandwidth meant that downloading Java was slow and >> painful. With high bandwidth connections rolling out in many countries, >> that part of the problem is gradually disappearing. The last ten years, my >> own home bandwidth has increased by a factor of 60, meaning that >> downloading Java now takes only 7 seconds. >> >> C. With the modern autoupdate features of most operating systems the >> installation is only done manually once per computer, after which point the >> autoupdate feature takes over. If the user reinstalls his computer once >> every two years, then Java is a less than a minute download every two >> years. I think many users consider that quite bearable. >> >> D. Many users already have the latest installation of Java. In Denmark in >> Scandinavia where I live, the latest version of Java has a 100.0% >> penetration among all 5.6 million residents. Why? Because our nationwide >> common login system called NemID is based on it. In Denmark you cannot log >> in to your home banking system or the tax authorities' website without it. >> I am not saying that Denmark is a typical example in this regard, but do >> not forget that many users in other countries might have already installed >> Java for accessing their home banking system, for gaming, or for using all >> sorts of Java based application services. I believe this is a way better >> situation than what Flash had ? Java is a requirement for many need-to-have >> applications, whereas flash often only was a requirement for accessing >> non-need-to-have content. >> >> Finally, please also realise that while there are things that HTML5 does >> better than JavaFX, there are also things JavaFX does best. It will never >> be a winner-takes-all competition. If your next application is a product >> catalog consisting mainly of pages of content for the user to browse, who >> in their right mind would not choose HTML5 for this? On the other hand, if >> your next application is a home interior design application allowing users >> to visualise prefabricated kitchen cupboards in a virtual model of their >> own home, who would not choose JavaFX over HTML5? >> >> Randahl. >> >> >> On Dec 1, 2012, at 22:56 , Daniel Zwolenski wrote: >> >> Hi Randahl, >> >> Thanks for your comments I appreciate hearing an alternative point of >> view. >> >> One thing to keep in mind is that all of my comments are within the >> context of the web/consumer space (unfortunately this space doesn't have a >> good name so it's harder to define). >> >> Richard has already asked you to provide documentation to back up your >> performance claims, >> >> >> I responded to this. There is another thread on performance where someone >> (I think Michael) made the claim that jfx was slow (in some cases 2-3 times >> slower than awt) and my own experiences have shown problems. I'd suggest >> continuing that conversation on that thread if needed since the original >> poster of that question made a good attempt at phrasing these questions >> (and in my opinion leaving that thread unanswered was far worse for >> perception than leaving this one unanswered - surprised Richard let it >> unrebuked based on his stance on performance). >> >> I look forward to seeing Richard's documentation on benchmarks when he >> has a chance to release them. >> >> >> Your claim: *Web is [?] a deployment model that is seamless across more >> platforms.* >> ? My input: You are right that deployment of web apps *feels* easy, but >> truly ensuring that the deployment actually works for all users on all >> platforms is all but a trivial task. There are literally hundreds of >> different web browser brands and versions out there, and the fact that you >> tested your latest web app on the two latest versions of a couple of >> browsers, gives you no guarantee that the web app works for all of the >> target audience. Have a look at this list, that documents the insanity of >> the web deployment challenge: >> http://www.useragentstring.com/pages/Browserlist/. >> The truth is that some web developers close their eyes to the >> heterogeneous nature of the deployment environment, and simply define their >> target audience as *"users who use the latest version of Internet >> Explorer on Windows"*. That may give you a warm and fuzzy feeling of >> simplicity and ease of deployment, but in reality it just means that your >> web app is most likely broken for everyone who falls outside your defined >> target audience. Knowing that all of your desktop users run Oracle's >> version of Java is a way better than knowing that all of your users run >> either Internet Explorer or Chrome or Safari or Firefox or yet another >> browser. >> >> >> Agreed there are challenges with supporting lots of different browsers. >> >> My comment was that the user experience for "deployment" (ie getting a >> webapp running) is seamless (go to this URL). Once running, bug free >> cross-platform "consistency" is harder to achieve but the onus for this is >> on the developer (you have to test and run on every platform and tweak as >> needed). >> >> To me your argument here is that jfx having a single platform is the >> better "developer" experience and I totally agree. I hate debugging and >> fixing cross browser problems as much as the next developer but my users >> don't care that I hate doing it. My users would care however, if I told >> them that to run my app they have to first go to an oracle site and install >> java. >> >> A single platform for jfx is definitely a huge selling point for it and >> good that you added that to the analysis, but it is a selling point to the >> developers, not end users. You argue that the kick-on effect (ie developer >> is happy so they can do a better/quicker job) is a selling point to the >> user but your user would be weighing this somewhat unquantifiable benefit >> against the very comprehensible drawback of having to install java and the >> problems that come with that. >> >> As a side note the web space is traditionally horrid for x-browser but >> is improving rapidly and many frameworks like jquery and twitter bootstrap >> are making x-browser support much, much easier to achieve. I just released >> a webapp with moderate level of jscript that needed less than a week of >> testing/tweaking to work on IE7 - IE10, Firefox, chrome, safari, on WinXP - >> Win7 and Mac. I was pretty shocked myself that it worked based on my >> previous experiences (had braced myself for pain). IE10 still has some of >> the usual ms quirks but it is a far cry from the old days of ie 6 and ie 7. >> >> Also worth noting is that even with one platform, jfx has its own win vs >> mac vs Linux issues and you need to test and tweak on everyone (and build >> if you're using native installers). >> >> As a developer though the idea of one platform is one of the big selling >> points to me, as it sounds like it is for you. >> >> >> Your claim:* [JavaFX is] based on established, type-safe java [?] >> However there is little benefit to users [in this].* >> ? My input: Everyone who has tried debugging a web application with more >> than 20.000 lines of JavaScript code knows that the lack of compile-time >> checks and type safety means JavaScript is more error prone. More errors >> means more time spent on debugging and less time spent on providing new >> features or improving the overall product quality. I hope you agree that >> users prefer robust, feature rich, high quality applications. >> >> >> Again, this is a (big) selling point to developers. You can argue the >> kick on benefits of more features and less bugs but that's hard to quantify >> and stack up against quantifiable things like installation and even >> availability and cost of jfx developers in the market vs web. >> >> In terms of getting features out quicker web developers would argue that >> they can get more features out in less time than a java app and this would >> be the established perception out there - how do you prove you are right >> and they are wrong (and the proliferation of rapidly released webapps and >> lack of jfx apps would put the burden of proof on the jfx developer)? >> >> It certainly is possible to build a robust, bug free webapp too. >> Atlassian tool suite, google analytics, Facebook, gmail, etc, etc - when we >> are telling our users that jfx will be less buggy than a webapp, how do we >> convince them of that when they are already using plenty of robust webapps >> in their daily lives? >> >> Your claim: *Should [JavaFX] not gain market space before the [HTML5] >> era truly establishes itself then [JavaFX] is unlikely to ever make it [?]. >> * >> >> >> You snipped just before the important bit: "in it's current form". >> >> Also we're talking about the web space and competing with HTML. As I go >> on to say there are other areas where jfx can continue to be a contender >> but those areas were not the focus of my email. >> >> My opinion is that once the html5 era stabilizes it will be unlikely that >> jfx will offer much to that will allow it to break into the web space >> unless it innovates. Browser plugins will be dead so webstart and applets >> will be out, leaving no true web deployment option. >> >> I do not say that jfx will be dead only that it's current strategies for >> operating in the web will never work and new ones will be needed *if* jfx >> ever does want to try and compete in the web space (ie if oracle change >> their mind about not being interested in this space). >> >> One way this could happen for example is to not compete directly but to >> run ontop of jscript either at runtime or by precompiling the java/jfx app >> to jscript (ie like gwt does, in fact jfx-for-gwt would be a good avenue to >> look at though I suspect gwt is on the technology down curve with html5 >> rendering it somewhat obsolete). >> >> Alternatively the trend towards app stores may actually open more doors >> for jfx. In essence the OS vendors are potentially providing us with a >> deployment solution (yay!). In terms of the space I am looking at, keeping >> an eye on these app stores and there challenges regarding legals and >> technical restrictions is very high on the list. It's a good example of why >> I feel this sort of analysis is needed - what are the trends, >> opportunities, risks and what's our strategy as a result. >> >> Basically my analysis is that there is a small window of opportunity now >> to get jfx in its current form (but improving the current deployment >> options) to have some web market space but once html5 settles I believe it >> will be a case of reinvention rather than improvement to then get any web >> market space. >> >> >> ? My input: On the one hand you are saying that HTML 5 has not truly >> established itself, even though it was first published 5 years ago, but >> still you claim HTML5 is the likely winner. Then on the other hand you move >> on to claiming that Java based JavaFX (meaning JavaFX 2.x) has to win the >> race in its first 2 years of existence in order to make it. I think it is >> worth noting that new software projects start every day, and many of them >> will choose the technology that best suits their needs. Remember when >> Windows was the all dominating operating system and people thought no one >> else had a chance? What happened? Remember when Internet Explorer was the >> all dominating browser and people thought no one else had a chance? What >> happened? Remember when Nokia was the all dominating cell phone >> manufacturer in Europe and Apple had not even made a phone yet? What >> happened? Remember when gasoline was the all dominating propellant for cars >> and people thought electric cars had no chance? What is happening right now? >> >> All in all, I believe time will show that both HTML5 and JavaFX will have >> huge success. It all comes down to understanding the strengths of each >> technology, and knowing which technology best matches the exact >> requirements of the app you are building. >> >> >> Yep. I'm talking about competiting in the web space. Oracle is backing >> html5 in this space, I'm trying to ascertain if and how javafx can compete >> instead. >> >> Thanks for your comments, >> Dan >> >> >> > > From richard.bair at oracle.com Sat Dec 1 18:21:44 2012 From: richard.bair at oracle.com (Richard Bair) Date: Sat, 1 Dec 2012 18:21:44 -0800 Subject: The competition In-Reply-To: <30169C4D-FA68-497E-8FB7-23858018E87B@gmail.com> References: <3DB35A93-2FD8-4440-8C1C-1CDA45CC4859@gmail.com> <30169C4D-FA68-497E-8FB7-23858018E87B@gmail.com> Message-ID: <8A8A7FA6-8F8C-4EFF-BE01-16ABAD30B9E1@oracle.com> > I responded to this. There is another thread on performance where someone (I think Michael) made the claim that jfx was slow (in some cases 2-3 times slower than awt) and my own experiences have shown problems. I'd suggest continuing that conversation on that thread if needed since the original poster of that question made a good attempt at phrasing these questions (and in my opinion leaving that thread unanswered was far worse for perception than leaving this one unanswered - surprised Richard let it unrebuked based on his stance on performance). I didn't see the other thread say we were slower than the browser, if they did, that would have got my attention :-) From richard.bair at oracle.com Sat Dec 1 18:26:36 2012 From: richard.bair at oracle.com (Richard Bair) Date: Sat, 1 Dec 2012 18:26:36 -0800 Subject: Layouts with constraint classes In-Reply-To: References: <4FFEDD3B.6030109@oracle.com> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> <50B87AF8.3050200@tbee.org> <50B88858.4080500@tbee.org> <50B9AF27.6040903@tbee.org> <50B9B5FD.5020501@tbee.org> <50B9F0D9.6090608@bestsolu! tion.at> <50BA53D4.7090504@tbee.org> Message-ID: <58D54348-32FF-4895-87BF-95C423011303@oracle.com> > This whole thread is a great example where a clean underlying Java API with > good separation of concerns between domains (in this case FXML and Java > API) with appropriate glue in between can allow for the most flexibility > and future variations and extensions. > > If only this same philosophy had been taken with CSS... You mean not being able to style the UI controls except from CSS? From richard.bair at oracle.com Sat Dec 1 18:38:43 2012 From: richard.bair at oracle.com (Richard Bair) Date: Sat, 1 Dec 2012 18:38:43 -0800 Subject: =?windows-1252?Q?Re=3A_Request_for_comments_=96_interface_Rectan?= =?windows-1252?Q?gular?= In-Reply-To: <92E5C77A-7E97-43A8-9D63-FD066FFE3AF6@rockit.dk> References: <92E5C77A-7E97-43A8-9D63-FD066FFE3AF6@rockit.dk> Message-ID: <997372A7-51C8-4FCB-B2EF-FB35EFE6A9B4@oracle.com> I think that is a great question. Another thing that is always bothering me is that I want to be able to resize rectangular things in a regular manner. That would imply the interface should have more than just getters. That also gives another reason why interfaces are difficult to work with -- if we'd have just shipped such an interface (with only getters) and then realized we wanted setters, we'd be stuck (if we can't take advantage of default methods in 8, anyway). Anyway, I digress. If Java had mixins, we'd have used them to great effect in many of these cases. Unfortunately it doesn't, and interfaces are poor for API evolution (they're great for defining the boundaries between systems, but not so great for defining the characteristics of something). There are a couple JIRAs actually (at least one or two I filed) that say something to the effect of "add such and such an interface when we know what it should look like". So, we should list the use cases for when you want to work with something as though it is rectangular. I'm assuming in your case boundsInLocal doesn't cut it (because you want to know the width / height before the clip is applied)? Richard On Dec 1, 2012, at 12:18 PM, Randahl Fink Isaksen wrote: > I have on a few occasions had to determine the width and height of a Node. It turns out, that this is not that easy, because JavaFX does not yet have a common interface for all nodes that have a width and a height. Consequently, I suggest an interface Rectangular to be added: > > interface Rectangular { > double getWidth(); > double getHeight(); > } > > This interface would have the benefit of making measuring node size considerably simpler. Before: > > if(node instanceof Region || node instanceof Control || node instanceof Rectangle [?]) { > double width = -1; > double height = -1; > if(node instanceof Region) { > width = ((Region) node).getWidth(); > height = ((Region) node).getHeight(); > } > else if(node instanceof Control) { > width = ((Control) node).getWidth(); > height = ((Control) node).getHeight(); > } > else if(node instanceof Rectangle) { > width = ((Rectangle) node).getWidth(); > height = ((Rectangle) node).getHeight(); > } > // do something with the width and height > } > > And after > > if(node instanceof of Rectangular) { > double width = ((Rectangular) node).getWidth(); > double height = ((Rectangular) node).getHeight(); > // do something with the width and height > } > > I would very much like to discuss if this concept could be helpful for all of us. > > Thanks > > Randahl From zonski at gmail.com Sat Dec 1 19:06:32 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sun, 2 Dec 2012 14:06:32 +1100 Subject: Layouts with constraint classes In-Reply-To: <58D54348-32FF-4895-87BF-95C423011303@oracle.com> References: <4FFEDD3B.6030109@oracle.com> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> <50B87AF8.3050200@tbee.org> <50B88858.4080500@tbee.org> <50B9AF27.6040903@tbee.org> <50B9B5FD.5020501@tbee.org> <50B9F0D9.6090608@bestsolu! tion.at> <50BA53D4.7090504@tbee.org> <58D54348-32FF-4895-87BF-95C423011303@oracle.com> Message-ID: <2D86AE01-DDF5-4CF7-AF47-34BA4C1CFD48@gmail.com> More or less. I would have liked a really nice type safe Style Java API much like the really nice type safe Node API and Animation API, etc. Then CSS would be more of a higher level way of interacting with it (like FXML is to Nodes). This would allow nicer styling direct in java code eg something like: Style myStyle = new ButtonStyleBuilder().border(2).padding(10) And querying styles: ButtonStyle style = StyleSheet.resolveStyleFor(my button); style.getBorder().getWidth(); Or whatever, you get the gist. It would obviously be a lot more complex than I imply here but I'm tapping on my phone. This would also open the door to people building their own non-CSS style languages that map onto the java (eg json) or I could even put my styles in XML along side the FXML files, etc. I have use cases, but the main thing is its easier for developers to get creative when it's in java (as we just saw with Tom's unique FXML use case). This is an old conversation though, I've kicked it around many times. I don't think it's something likely to change so maybe not worth burning your time on? I'd rather see that blog post you were talking about on how you got jfx working on android :) On 02/12/2012, at 1:26 PM, Richard Bair wrote: >> This whole thread is a great example where a clean underlying Java API with >> good separation of concerns between domains (in this case FXML and Java >> API) with appropriate glue in between can allow for the most flexibility >> and future variations and extensions. >> >> If only this same philosophy had been taken with CSS... > > You mean not being able to style the UI controls except from CSS? > > From jonathan.giles at oracle.com Sat Dec 1 19:30:20 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Sun, 02 Dec 2012 16:30:20 +1300 Subject: Layouts with constraint classes In-Reply-To: <2D86AE01-DDF5-4CF7-AF47-34BA4C1CFD48@gmail.com> References: <4FFEDD3B.6030109@oracle.com> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> <50B87AF8.3050200@tbee.org> <50B88858.4080500@tbee.org> <50B9AF27.6040903@tbee.org> <50B9B5FD.5020501@tbee.org> <50B9F0D9.6090608@bestsolu! tion.at> <50BA53D4.7090504@tbee.org> <58D54348-32FF-4895-87BF-95C423011303@oracle.com> <2D86AE01-DDF5-4CF7-AF47-34BA4C1CFD48@gmail.c! om> Message-ID: <50BACB4C.1080800@oracle.com> There are a whole bunch of cool things we plan to do in JavaFX CSS, one of which is having a public API for read/write access to the CSS state of each Node (see [1], although note that it is no longer targeted at 8.0, I believe). Some other things planned for future releases include support for custom CSS properties / pseudoclass states (8.0) and animation support (untargeted), etc. I keep on telling people that this is in the plans - but no one seems to believe me :-) Personally this is something I've been wanting to get done for a long time now, so I'm very keen on seeing it too. I would recommend any further technical discussion be moved on to [1] though, as we're (as always) straying very far from the original topic. [1] http://javafx-jira.kenai.com/browse/RT-24214 -- Jonathan On 2/12/2012 4:06 p.m., Daniel Zwolenski wrote: > More or less. I would have liked a really nice type safe Style Java API much like the really nice type safe Node API and Animation API, etc. Then CSS would be more of a higher level way of interacting with it (like FXML is to Nodes). This would allow nicer styling direct in java code eg something like: > > Style myStyle = new ButtonStyleBuilder().border(2).padding(10) > > And querying styles: > > ButtonStyle style = StyleSheet.resolveStyleFor(my button); > style.getBorder().getWidth(); > > Or whatever, you get the gist. It would obviously be a lot more complex than I imply here but I'm tapping on my phone. > > This would also open the door to people building their own non-CSS style languages that map onto the java (eg json) or I could even put my styles in XML along side the FXML files, etc. I have use cases, but the main thing is its easier for developers to get creative when it's in java (as we just saw with Tom's unique FXML use case). > > This is an old conversation though, I've kicked it around many times. I don't think it's something likely to change so maybe not worth burning your time on? I'd rather see that blog post you were talking about on how you got jfx working on android :) > > > > On 02/12/2012, at 1:26 PM, Richard Bair wrote: > >>> This whole thread is a great example where a clean underlying Java API with >>> good separation of concerns between domains (in this case FXML and Java >>> API) with appropriate glue in between can allow for the most flexibility >>> and future variations and extensions. >>> >>> If only this same philosophy had been taken with CSS... >> You mean not being able to style the UI controls except from CSS? >> >> From tbee at tbee.org Sat Dec 1 23:24:37 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 02 Dec 2012 08:24:37 +0100 Subject: The competition In-Reply-To: References: <3DB35A93-2FD8-4440-8C1C-1CDA45CC4859@gmail.com> <30169C4D-FA68-497E-8FB7-23858018E87B@gmail.com> <09A10678-F0D6-4688-BE68-57F5897A85AA@rockit.dk> Message-ID: <50BB0235.1060808@tbee.org> On 2012-12-02 00:38, Daniel Zwolenski wrote: >> On the other hand, if your next application is a home interior design > application allowing users to visualise prefabricated kitchen cupboards in > a virtual model of their own home, who would not choose JavaFX over HTML5? > Actually, after having done the Google Calendar control, I'm all fan of coding this in JavaFX. Once you've got a good "operating mode", coding absolute layout is a breeze in JFX. So I would seriously consider JFX, yes. But that is based on the fact that JFX is from experience a good developer platform to do this in, plus the experience I have in the last 8 years or so of maintaining my hour entry applet. Since I have not investigated WebGL or similar I cannot be sure. All I can say is that the Swing applet has not caused me much problems, and startup time actually is pretty good, after the initial download when all jars are cached. But of course this is in an professional setting (consumers do not often need to keep track of where they've spent their hours on), so I do not know what I'll run into with all the consumers and their plugins. Tom From tbee at tbee.org Sat Dec 1 23:26:13 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 02 Dec 2012 08:26:13 +0100 Subject: Layouts with constraint classes In-Reply-To: References: <4FFEDD3B.6030109@oracle.com> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> <50B87AF8.3050200@tbee.org> <50B88858.4080500@tbee.org> <50B9AF27.6040903@tbee.org> <50B9B5FD.5020501@tbee.org> <50B9F0D9.6090608@bestsolution.at> <50BA53D4.7090504@tbee.org> Message-ID: <50BB0295.7020407@tbee.org> Sinterklaas is back to spain, my new project is starting to roll, "the reader" should be getting some time to spent on his hobby again. On 2012-12-02 00:49, Daniel Zwolenski wrote: > Which could also be achieved with builders and listeners - I'll leave that as an exercise for the reader :) > > This whole thread is a great example where a clean underlying Java API with good separation of concerns between domains (in this case FXML and Java API) with appropriate glue in between can allow for the most flexibility and future variations and extensions. > > If only this same philosophy had been taken with CSS... > From tbee at tbee.org Sat Dec 1 23:38:12 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 02 Dec 2012 08:38:12 +0100 Subject: Layouts with constraint classes In-Reply-To: <50BACB4C.1080800@oracle.com> References: <4FFEDD3B.6030109@oracle.com> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> <50B87AF8.3050200@tbee.org> <50B88858.4080500@tbee.org> <50B9AF27.6040903@tbee.org> <50B9B5FD.5020501@tbee.org> <50B9F0D9.6090608@bestsolu! tion.at> <50BA53D4.7090504@tbee.org> <58D54348-32FF-4895-87BF-95C423011303@oracle.com> <2D86AE01-DDF5-4CF7-AF47-34BA4C1CFD48@gmail.c! om> <50BACB4C.1080800@oracl e.com> Message-ID: <50BB0564.7030006@tbee.org> On 2012-12-02 04:30, Jonathan Giles wrote: > I keep on telling people that this is in the plans - but no one seems to believe me :-) Personally this is something I've been wanting to get done for a long time now, so I'm very keen on seeing it too. I would recommend any further technical discussion be moved on to [1] though, as we're (as always) straying very far from the original topic. LOL. I believe you, but it's like "seeing is believing" http://www.youtube.com/watch?v=mBS0OWGUidc :-) Tom From randahl at rockit.dk Sun Dec 2 04:15:32 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Sun, 2 Dec 2012 13:15:32 +0100 Subject: =?windows-1252?Q?Re=3A_Request_for_comments_=96_interface_Rectan?= =?windows-1252?Q?gular?= In-Reply-To: <997372A7-51C8-4FCB-B2EF-FB35EFE6A9B4@oracle.com> References: <92E5C77A-7E97-43A8-9D63-FD066FFE3AF6@rockit.dk> <997372A7-51C8-4FCB-B2EF-FB35EFE6A9B4@oracle.com> Message-ID: Richard, In that case, I think we should consider if Rectangulars are always resizable. If they are not, I would suggest this hierarchy class Region ----- implements -----> interface Resizable ----- extends -----> interface Rectangular You also touch on the problem with the brittleness of interfaces. If you ensure that all relevant JavaFX node classes implement Resizable and Rectangular, you can easily add methods to theses interfaces as long as you add default implementations in the JavaFX node classes. E.g. com.mycompany.MyOwnControl ----- extends -----> Region ----- implements -----> Resizable ? I would never be affected by you adding methods to interface Resizable as long as you add a default implementation in class Region. Randahl On Dec 2, 2012, at 3:38 , Richard Bair wrote: > I think that is a great question. Another thing that is always bothering me is that I want to be able to resize rectangular things in a regular manner. That would imply the interface should have more than just getters. That also gives another reason why interfaces are difficult to work with -- if we'd have just shipped such an interface (with only getters) and then realized we wanted setters, we'd be stuck (if we can't take advantage of default methods in 8, anyway). Anyway, I digress. > > If Java had mixins, we'd have used them to great effect in many of these cases. Unfortunately it doesn't, and interfaces are poor for API evolution (they're great for defining the boundaries between systems, but not so great for defining the characteristics of something). There are a couple JIRAs actually (at least one or two I filed) that say something to the effect of "add such and such an interface when we know what it should look like". > > So, we should list the use cases for when you want to work with something as though it is rectangular. I'm assuming in your case boundsInLocal doesn't cut it (because you want to know the width / height before the clip is applied)? > > Richard > > > On Dec 1, 2012, at 12:18 PM, Randahl Fink Isaksen wrote: > >> I have on a few occasions had to determine the width and height of a Node. It turns out, that this is not that easy, because JavaFX does not yet have a common interface for all nodes that have a width and a height. Consequently, I suggest an interface Rectangular to be added: >> >> interface Rectangular { >> double getWidth(); >> double getHeight(); >> } >> >> This interface would have the benefit of making measuring node size considerably simpler. Before: >> >> if(node instanceof Region || node instanceof Control || node instanceof Rectangle [?]) { >> double width = -1; >> double height = -1; >> if(node instanceof Region) { >> width = ((Region) node).getWidth(); >> height = ((Region) node).getHeight(); >> } >> else if(node instanceof Control) { >> width = ((Control) node).getWidth(); >> height = ((Control) node).getHeight(); >> } >> else if(node instanceof Rectangle) { >> width = ((Rectangle) node).getWidth(); >> height = ((Rectangle) node).getHeight(); >> } >> // do something with the width and height >> } >> >> And after >> >> if(node instanceof of Rectangular) { >> double width = ((Rectangular) node).getWidth(); >> double height = ((Rectangular) node).getHeight(); >> // do something with the width and height >> } >> >> I would very much like to discuss if this concept could be helpful for all of us. >> >> Thanks >> >> Randahl > From daniel at lotsovcookiez.com Sun Dec 2 07:11:59 2012 From: daniel at lotsovcookiez.com (Daniel Opitz) Date: Sun, 02 Dec 2012 16:11:59 +0100 Subject: TableView FXML problems Message-ID: <50BB6FBF.4010000@lotsovcookiez.com> Hello, I'm currently trying to learn some FXML and have at least 4 problems with the TableView component: 1) TableView shows some strange behavior after maximizing the window: https://dl.dropbox.com/u/1030857/maximized.PNG and minimizing it afterwards: https://dl.dropbox.com/u/1030857/normalaftermax.PNG When resizing (particularily making the window bigger) the unstyled table is visible too: https://dl.dropbox.com/u/1030857/resizing.PNG I set some some constraints on the columns and I am using the CONSTRAINED_RESIZE_POLICY and here is the FXML: The TableView Control sits in a VBox which sits in the center of a BorderPane. 2) I have found some code to hide the table header: |Pane header = (Pane) table.lookup("TableHeaderRow"); header.setVisible(*false*); table.setLayoutY(-header.getHeight()); table.autosize();| but I don't know where I can call it. I have a controller for the Main Window and if I use the Initializable interface I obviously get NullPointerException, because the TableView isn't created yet. 3) Is it possible to remove the resize lines / column borders? I tried changing CSS of the column-resize-line substructure of the TableView, but with no success... 4) I haven't found anything reliable on the net: How can I set a Checkbox Cell Factory in the table using FXML? I did it earlier using DataFX cell factories, but only in pure Java. Kind regards, Daniel Opitz From zonski at gmail.com Sun Dec 2 12:37:35 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Mon, 3 Dec 2012 07:37:35 +1100 Subject: [Review request] TreeTableView In-Reply-To: <50B51C2B.2040607@oracle.com> References: <50B3EB05.6000406@oracle.com> <696269E8-EB6D-47EF-AAC8-054FA5916861@gmail.com> <50B51C2B.2040607@oracle.com> Message-ID: Filed as: http://javafx-jira.kenai.com/browse/RT-26631 Thought I had an old one in there for table and list but couldn't find it - maybe it had just been an email conversation. Might be a duplicate lurking in there somewhere though. On Wed, Nov 28, 2012 at 7:01 AM, Jonathan Giles wrote: > Thanks. > > Regarding disabling scrolling: it sounds like a reasonable request, and > I'm not sure that there is a jira feature / tweak request logged yet. It > would be great if you might consider creating one. > > -- Jonathan > > > On 28/11/2012 8:49 a.m., Daniel Zwolenski wrote: > >> Consistently awesome work Jonathan. >> >> I haven't had a chance to dig into all the finer details of this but on >> the surface it looks fantastic. >> >> One very small thing for me would be the ability to disable scrolling? I >> tend to mimic the web style ui where there is one big scroll bar for the >> whole page. The fact that I couldn't turn off scrolling on lists and tables >> meant I often couldn't use these cool controls in my app and had to roll my >> own crude ones. Probably lowish on the list though. >> >> >> On 27/11/2012, at 9:19 AM, Jonathan Giles >> wrote: >> >> Hi all, >>> >>> I'm planning to relocate the TreeTableView control I've been developing >>> in the OpenJFX 8.0 controls sandbox over into the proper OpenJFX 8.0 >>> controls repo. Before that happens there is a gate here that we need to go >>> through related to having an early API review. To make understanding the >>> control easier, I've written up an overview of the TreeTableView control >>> here: >>> >>> https://wikis.oracle.com/**display/OpenJDK/TreeTableView >>> >>> This documentation covers the core concepts of the API, it includes >>> examples of how the API is used, and finally I've put up a brief paragraph >>> detailing the implementation (although I may add more detail in here as >>> time passes and questions come in). My colleage Jindra Dinga, who is >>> responsible for the UX design of the TreeTableView control, has posted his >>> UX documentation for it at the same link above, so hopefully this too will >>> prove useful for people to fully understand precisely what a TreeTableView >>> is, and is not. >>> >>> To get a slightly more in-depth understanding of the path TreeTableView >>> has taken to where it is today, you may also be interested in the following >>> Jira issue, and perhaps you may choose to follow it and / or offer feedback >>> directly into the Jira issue: >>> >>> http://javafx-jira.kenai.com/**browse/RT-17288 >>> >>> The TreeTableView control that is in the sandbox repo is far superior to >>> the prototype that is in the 8.0 controls repo (in the com.preview.* >>> package). It is my intention to completely remove the old TreeTableView >>> control and replace it with the new implementation, and even go so far as >>> to place it in the correct packages so that I can make use of package >>> protected API. However, it is important to note that the API _is not final_ >>> - I'm only going through the first gate here to get the code into the >>> correct repo and packages - there will be further discussion in the future >>> regarding API design, missing / incorrect functionality, and straight out >>> bugs. >>> >>> I hope that you are all excited about getting a TreeTableView control >>> into JavaFX 8.0, and I hope you can all help guide the control towards an >>> API that meets your requirements and use cases. I think what we have now is >>> good, but API design can not be done in a vacuum so I look forward to your >>> feedback. I would recommend that discussion regarding moving TreeTableView >>> into the official OpenJFX 8.0 controls repo take place here, and that >>> discussion around API design and functionality be posted on the Jira issue >>> linked above (rather than here), to try to prevent the amount of noise on >>> this list. >>> >>> Thanks! >>> -- Jonathan >>> >> > From zonski at gmail.com Sun Dec 2 13:04:51 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Mon, 3 Dec 2012 08:04:51 +1100 Subject: Layouts with constraint classes In-Reply-To: <50BB0564.7030006@tbee.org> References: <4FFEDD3B.6030109@oracle.com> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> <50B87AF8.3050200@tbee.org> <50B88858.4080500@tbee.org> <50B9AF27.6040903@tbee.org> <50B9B5FD.5020501@tbee.org> <50BA53D4.7090504@tbee.org> <58D54348-32FF-4895-87BF-95C423011303@oracle.com> <50BACB4C.1080800@oracle.com> <50BB0564.7030006@tbee.org> Message-ID: Just one last one on the topic of builders, while the builder architecture was good for separating the Java API from the FXML, it wasn't very easy to add in new Builder methods that cut across all nodes (i.e. AOP-style injection of a cross-cutting concern, etc) such as Tom's setConstraints method. I raised this feature enhancement: http://javafx-jira.kenai.com/browse/RT-26632 My suggestions for implementation are just ideas, there are likely better ways. More just logging the goal. On Sun, Dec 2, 2012 at 6:38 PM, Tom Eugelink wrote: > > > On 2012-12-02 04:30, Jonathan Giles wrote: > >> I keep on telling people that this is in the plans - but no one seems to >> believe me :-) Personally this is something I've been wanting to get done >> for a long time now, so I'm very keen on seeing it too. I would recommend >> any further technical discussion be moved on to [1] though, as we're (as >> always) straying very far from the original topic. >> > > LOL. I believe you, but it's like "seeing is believing" > http://www.youtube.com/watch?**v=mBS0OWGUidc:-) > > Tom > > > > From jonathan.giles at oracle.com Sun Dec 2 18:14:00 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 03 Dec 2012 15:14:00 +1300 Subject: [Review request] TreeTableView In-Reply-To: <50B3EB05.6000406@oracle.com> References: <50B3EB05.6000406@oracle.com> Message-ID: <50BC0AE8.6030308@oracle.com> I have just pushed the TreeTableView code to JavaFX UI controls repo, and it will shortly arrive in the openjfx UI controls repo. The big change is that the classes have moved (and have been totally rewritten). Now the main classes are in javafx.scene.control, rather than the previously-used com.preview.javafx.scene.control package. The other thing to note is that there are still bugs and performance issues - fixing them comes up next. However, please file jira issues if you think you've found something that needs fixing. That's all - have at it! :-) -- Jonathan On 27/11/2012 11:19 a.m., Jonathan Giles wrote: > Hi all, > > I'm planning to relocate the TreeTableView control I've been > developing in the OpenJFX 8.0 controls sandbox over into the proper > OpenJFX 8.0 controls repo. Before that happens there is a gate here > that we need to go through related to having an early API review. To > make understanding the control easier, I've written up an overview of > the TreeTableView control here: > > https://wikis.oracle.com/display/OpenJDK/TreeTableView > > This documentation covers the core concepts of the API, it includes > examples of how the API is used, and finally I've put up a brief > paragraph detailing the implementation (although I may add more detail > in here as time passes and questions come in). My colleage Jindra > Dinga, who is responsible for the UX design of the TreeTableView > control, has posted his UX documentation for it at the same link > above, so hopefully this too will prove useful for people to fully > understand precisely what a TreeTableView is, and is not. > > To get a slightly more in-depth understanding of the path > TreeTableView has taken to where it is today, you may also be > interested in the following Jira issue, and perhaps you may choose to > follow it and / or offer feedback directly into the Jira issue: > > http://javafx-jira.kenai.com/browse/RT-17288 > > The TreeTableView control that is in the sandbox repo is far superior > to the prototype that is in the 8.0 controls repo (in the > com.preview.* package). It is my intention to completely remove the > old TreeTableView control and replace it with the new implementation, > and even go so far as to place it in the correct packages so that I > can make use of package protected API. However, it is important to > note that the API _is not final_ - I'm only going through the first > gate here to get the code into the correct repo and packages - there > will be further discussion in the future regarding API design, missing > / incorrect functionality, and straight out bugs. > > I hope that you are all excited about getting a TreeTableView control > into JavaFX 8.0, and I hope you can all help guide the control towards > an API that meets your requirements and use cases. I think what we > have now is good, but API design can not be done in a vacuum so I look > forward to your feedback. I would recommend that discussion regarding > moving TreeTableView into the official OpenJFX 8.0 controls repo take > place here, and that discussion around API design and functionality be > posted on the Jira issue linked above (rather than here), to try to > prevent the amount of noise on this list. > > Thanks! > -- Jonathan From hang.vo at oracle.com Sun Dec 2 18:19:08 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 03 Dec 2012 02:19:08 +0000 Subject: hg: openjfx/8/controls/rt: 10 new changesets Message-ID: <20121203021923.B09F947CBB@hg.openjdk.java.net> Changeset: f9919f8e02d7 Author: jgiles Date: 2012-09-17 13:22 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f9919f8e02d7 Small improvements to TreeTableView implementation. ! javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableRow.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java Changeset: 7e64b82fa22c Author: jgiles Date: 2012-09-17 15:21 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7e64b82fa22c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: a0feb76fb5a1 Author: jgiles Date: 2012-09-20 08:29 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a0feb76fb5a1 Small TreeTableRow cleanup. ! javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableRow.java Changeset: 686deb763e24 Author: jgiles Date: 2012-09-20 08:39 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/686deb763e24 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 969bc24c7dc8 Author: jgiles Date: 2012-10-08 08:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/969bc24c7dc8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: ec59f4a357e3 Author: jgiles Date: 2012-11-10 12:07 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ec59f4a357e3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: a819d671e276 Author: jgiles Date: 2012-11-19 10:13 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a819d671e276 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 56426964368a Author: jgiles Date: 2012-12-03 14:18 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/56426964368a RT-17288: Initial import of a completely new TreeTableView implementation (and removal of the old one). - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableColumn.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableRow.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/TableColumnComparator.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableCellSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableCellSkinBase.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/TableRowSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css + javafx-ui-controls/src/javafx/scene/control/CellSpan.java ! javafx-ui-controls/src/javafx/scene/control/FocusModel.java ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java + javafx-ui-controls/src/javafx/scene/control/ResizeFeaturesBase.java + javafx-ui-controls/src/javafx/scene/control/SpanModel.java ! javafx-ui-controls/src/javafx/scene/control/TableCell.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java + javafx-ui-controls/src/javafx/scene/control/TableColumnBase.java + javafx-ui-controls/src/javafx/scene/control/TableFocusModel.java ! javafx-ui-controls/src/javafx/scene/control/TablePosition.java + javafx-ui-controls/src/javafx/scene/control/TablePositionBase.java + javafx-ui-controls/src/javafx/scene/control/TableSelectionModel.java + javafx-ui-controls/src/javafx/scene/control/TableUtil.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeItem.java + javafx-ui-controls/src/javafx/scene/control/TreeSortMode.java + javafx-ui-controls/src/javafx/scene/control/TreeTableCell.java + javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java + javafx-ui-controls/src/javafx/scene/control/TreeTablePosition.java + javafx-ui-controls/src/javafx/scene/control/TreeTableRow.java + javafx-ui-controls/src/javafx/scene/control/TreeTableView.java + javafx-ui-controls/src/javafx/scene/control/TreeUtil.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java + javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeTableCell.java + javafx-ui-controls/src/javafx/scene/control/cell/ChoiceBoxTreeTableCell.java + javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxTreeTableCell.java + javafx-ui-controls/src/javafx/scene/control/cell/ProgressBarTreeTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/PropertyValueFactory.java + javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeTableCell.java + javafx-ui-controls/src/javafx/scene/control/cell/TreeItemPropertyValueFactory.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/behavior/TableViewAnchorRetriever.java ! javafx-ui-controls/test/javafx/scene/control/MultipleSelectionModelImplTest.java ! javafx-ui-controls/test/javafx/scene/control/TableColumnTest.java + javafx-ui-controls/test/javafx/scene/control/TreeTableColumnTest.java Changeset: 20667075f80a Author: jgiles Date: 2012-12-03 14:22 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/20667075f80a Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableColumn.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableRow.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableView.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 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/javafx/scene/control/TableCell.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java Changeset: 5b9d072ea84c Author: jgiles Date: 2012-12-03 15:06 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5b9d072ea84c Fixing TreeTableView merge errors due to being out in a sandbox for so long. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/javafx/scene/control/TreeTableCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableRow.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/behavior/TableViewAnchorRetriever.java From danno.ferrin at shemnon.com Sun Dec 2 21:20:04 2012 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Sun, 2 Dec 2012 22:20:04 -0700 Subject: TextFlow and Min vs. Pref size Message-ID: I was playing with the TextFlow bits in the JDK8 ea and was wondering about the handling of min vs pref sizing. The TextFlow can return some very small min sizes which are much smaller than the contained text elements. For example, I have a text with min/pref/max all of 269.85 x 30.62 while the min/pref/max of the parent TextFlow (which contains just the text node) of 0.0 x 17.2 / 269.85 x 48.62 / maxValuexmaxValue. This is problematic when place in a scroll pane, as all the text flows tend to bunch up on each other. Is this a design intent or an oversight? For a workaround I've wrapped then TextFlows in panes that report minHeight as PrefHeight, so I don't see the bunching in scrollpane problem. For an interactive example of this behavior I have a toy app at bitbucket: https://bitbucket.org/shemnon/flowdown From sven.reimers at gmail.com Sun Dec 2 22:34:32 2012 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 3 Dec 2012 07:34:32 +0100 Subject: JavaFX 2.2.6-ea in JDK 1.7u12 Message-ID: Is there a corresponding hg repository available? Thanks Sven From hang.vo at oracle.com Mon Dec 3 01:03:27 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 03 Dec 2012 09:03:27 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121203090331.93E9447CC9@hg.openjdk.java.net> Changeset: ad9bea38bfbe Author: tb115823 Date: 2012-12-03 09:53 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ad9bea38bfbe fix build failure. Reference to nonexisting classes after rename of test classes ! javafx-fxml/test/javafx/fxml/RT_22971Controller.java ! javafx-fxml/test/javafx/fxml/RT_23413Test.java Changeset: 8e88ab8b8bcc Author: tb115823 Date: 2012-12-03 09:55 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8e88ab8b8bcc Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt From randahl at rockit.dk Mon Dec 3 01:15:34 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Mon, 3 Dec 2012 10:15:34 +0100 Subject: Are hidden animations costless? Message-ID: Say, I have two panes each one showing a bouncing beach ball, and one showing a bouncing tennis ball, and a button for switching between them (by setting visible to true and false). Then, when the bouncing beach ball pane is shown, and the bouncing tennis ball is hidden, does JavaFX then automatically save the resources otherwise spent on animating the tennis ball? In other words: Do timelines of things that are invisible consume CPU? Randahl From tobi at ultramixer.com Mon Dec 3 01:36:29 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Mon, 3 Dec 2012 10:36:29 +0100 Subject: JavaFX 2 fully open sourced? Message-ID: <503EF77D-6492-4209-99AF-1D41BCC82B91@ultramixer.com> Hi guys from Oracle, could you tell something about the roadmap for open sourcing JavaFX2? Especially the prism/glass layer? Best regards, Tobi From artem.ananiev at oracle.com Mon Dec 3 01:46:30 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 03 Dec 2012 13:46:30 +0400 Subject: Porting from Swing - JavaFX 2 for JDK 6 for Mac needed In-Reply-To: <7BAA6D69-B4AD-41B1-8D69-3202E302235F@ultramixer.com> References: <7BAA6D69-B4AD-41B1-8D69-3202E302235F@ultramixer.com> Message-ID: <50BC74F6.9050402@oracle.com> Hi, Tobi, if I read you email correctly, you're saying that you can't migrate your Swing applications from JDK6 to JDK7, because JDK7 has bugs on OS X. Well, fair enough, but I still encourage everybody to try every next JDK7 update release to check if their favorite bug is fixed. Then you said you need JDK6 for JavaFX development. Could you provide more details about it, please? JavaFX does not depend on AWT, Swing, or Java2D, unless you use JFXPanel or Java2D graphics pipeline. Therefore AWT/Swing/Java2D issues in JDK7 should not prevent you from writing JavaFX apps on Mac. Thanks, Artem On 12/1/2012 12:58 AM, Tobias Bley wrote: > Hi, > > we plan to develop new module for our current Swing based software in > JavaFX 2. Our commercial swing apps are based on JDK6 because > OpenJDK7 for mac is not really ready for production use (graphical > issues, no retina support, no 32bit support, ?) > > So currently we can't port our swing apps to OpenJDK 7 on Mac (JDK7 > for windows is good). To develop new peaces of our swing based apps > in JavaFX 2 we need JFX for JDK6 on mac! Currently there is only JFX2 > for JDK6 on windows available. > > Is it possible to use JFX2 on (32bit) JDK6 on mac? > > Best regards, > Tobi From tobi at ultramixer.com Mon Dec 3 02:02:28 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Mon, 3 Dec 2012 11:02:28 +0100 Subject: Porting from Swing - JavaFX 2 for JDK 6 for Mac needed In-Reply-To: <50BC74F6.9050402@oracle.com> References: <7BAA6D69-B4AD-41B1-8D69-3202E302235F@ultramixer.com> <50BC74F6.9050402@oracle.com> Message-ID: Hi Artem, thanks for your answer. 1) We try all new releases of JDK7 and it's quality increases from update to update! Thanks for your great efforts! The biggest problem currently is the lack of Retina support and the minimum requirement of Mac 10.7.3 ?. 2) On the other side we can't use JavaFX2 on Mac because of the missing Retina support too? I think it would not be a big problem to support HiDPI on JavaFX2 (scale 2.0??) the other big point for us is the lack of "native looking skins". So with Swing we are able to produce high quality Mac apps with Java. They feel and look like native mac applications. With JavaFX2, currently we can "only" build "nice looking apps" (like 5 years ago with Flash/Flex) but these apps doesn't look like a real Mac app because of the caspian skin. So what we need are two things: 1) Retina support, 2) native looking skins. Best regards, Tobi Am 03.12.2012 um 10:46 schrieb Artem Ananiev : > Hi, Tobi, > > if I read you email correctly, you're saying that you can't migrate your Swing applications from JDK6 to JDK7, because JDK7 has bugs on OS X. Well, fair enough, but I still encourage everybody to try every next JDK7 update release to check if their favorite bug is fixed. > > Then you said you need JDK6 for JavaFX development. Could you provide more details about it, please? JavaFX does not depend on AWT, Swing, or Java2D, unless you use JFXPanel or Java2D graphics pipeline. Therefore AWT/Swing/Java2D issues in JDK7 should not prevent you from writing JavaFX apps on Mac. > > Thanks, > > Artem > > On 12/1/2012 12:58 AM, Tobias Bley wrote: >> Hi, >> >> we plan to develop new module for our current Swing based software in >> JavaFX 2. Our commercial swing apps are based on JDK6 because >> OpenJDK7 for mac is not really ready for production use (graphical >> issues, no retina support, no 32bit support, ?) >> >> So currently we can't port our swing apps to OpenJDK 7 on Mac (JDK7 >> for windows is good). To develop new peaces of our swing based apps >> in JavaFX 2 we need JFX for JDK6 on mac! Currently there is only JFX2 >> for JDK6 on windows available. >> >> Is it possible to use JFX2 on (32bit) JDK6 on mac? >> >> Best regards, >> Tobi From martin.sladecek at oracle.com Mon Dec 3 02:10:59 2012 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Mon, 03 Dec 2012 11:10:59 +0100 Subject: Fwd: Re: Are hidden animations costless? In-Reply-To: <50BC783B.9080903@oracle.com> References: <50BC783B.9080903@oracle.com> Message-ID: <50BC7AB3.8000708@oracle.com> Forwarding to the list, as I accidentally replied only to Randahl. -Martin -------- Original Message -------- Subject: Re: Are hidden animations costless? Date: Mon, 03 Dec 2012 11:00:27 +0100 From: Martin Sladecek To: Randahl Fink Isaksen Hi Randahl, yes, partially, but not the timeline itself. While the animation will be still ongoing (if you don't stop it explicitly), there are many optimizations that save CPU time. First, the affected nodes are not synchronized with the render graph, so the only thing that changes is the animated property. Also, the invisible sub-trees are skipped in the render graph when rendering, so you'd save up same time by making some nodes/groups invisible even if there wasn't any animation at all. Regards, -Martin On 12/03/2012 10:15 AM, Randahl Fink Isaksen wrote: > Say, I have two panes each one showing a bouncing beach ball, and one showing a bouncing tennis ball, and a button for switching between them (by setting visible to true and false). Then, when the bouncing beach ball pane is shown, and the bouncing tennis ball is hidden, does JavaFX then automatically save the resources otherwise spent on animating the tennis ball? > > In other words: Do timelines of things that are invisible consume CPU? > > Randahl From eva.krejcirova at oracle.com Mon Dec 3 06:40:25 2012 From: eva.krejcirova at oracle.com (Eva Krejcirova) Date: Mon, 03 Dec 2012 15:40:25 +0100 Subject: Heads up: fix for RT-24272 (reference to create() in builders is ambiguous) Message-ID: <50BCB9D9.7020301@oracle.com> Hi all, I plan to push a fix for RT-24272 (TableView reference to create is ambiguous) soon. This is a source incompatible change and might will change of the source code which uses affected builders (hence the heads-up). What's the fix for: due to some changes in Java 7 compiler, builders for generic classes (e.g. TableViewBuilder) are currently unusable - there is no way to call their create() method. The fix will add another create method to parametrized builders which will take the type as an argument e.g. public static javafx.scene.control.TableViewBuilder create(final Class type1) { return new javafx.scene.control.TableViewBuilder(); } and make the create() without arguments non-generic, so it hides the create in Region: public static javafx.scene.control.TableViewBuilder create() { return new javafx.scene.control.TableViewBuilder(); } This way, the user can create the builder like this: TableViewBuilder.create(Job.class); Regards, Eva From franck.wolff at graniteds.org Mon Dec 3 08:44:37 2012 From: franck.wolff at graniteds.org (Franck Wolff) Date: Mon, 3 Dec 2012 11:44:37 -0500 Subject: Granite Data Services 3.0.0.M1 introduces JavaFX 2.2 support In-Reply-To: References: <96044219-3E2C-4B59-B1BB-AB1872E4592E@oracle.com> Message-ID: Daniel, Thanks for your feedback. We will definitely provide a "test drive" in the next 3.0.0.M2 release, hopefully by the end of the year. It should be based on a Jetty or Tomcat server (Tomcat can be more complicated because of native APR libraries), packaged together with few binary sample applications and their sources. Testing the release would then be only a matter of downloading the so-called "test drive", starting it and then running the JavaFX applications (java -jar ... or double-click). Is it roughly what you are looking for when saying "if users could run them with a couple of clicks"? Franck. 2012/11/30 Daniel Zwolenski > Websockets are a powerful emerging option. Nice use of them in this > project and nice fallback onto polling given the newness of Websockets. > > Imagine how much more powerful those demos would be if users could run > them with a couple of clicks - sorry, couldn't resist. > > > On 01/12/2012, at 1:01 AM, Franck Wolff > wrote: > > > (sorry for the double post, I first replied to Richard without the forum > in > > copy and then tried today to forward my answer, which is not in the same > > thread, my fault, first time in this forum, won't do it again...) > > > > -------------------- > > > > The features and the samples you are looking for exist and are available > > through tutorials: > > > > > http://granitedataservices.com/blog/2012/11/26/real-time-messaging-tutorial-with-javafx-2-2/ > > > > > http://granitedataservices.com/blog/2012/11/26/data-management-tutorial-with-javafx-2-2/ > > > > We don't have any other material right now (such as videos or a test > > drive), but we did our best to make things as clear and easy as possible. > > > > And yes, if you open each application described in those tutorials twice, > > your changes in one of them will be reflected in the other one "in real > > time". > > -------------------- > > > > More on the subject: Richard has tried to run the 2nd tutorial on a Mac > > (Mountain Lion, java 1.7.0_09 64 bits) and it's causing some ugly random > > crashes of the JVM: > > > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # SIGSEGV (0xb) at pc=0x00007fff900dc250, pid=366, tid=9991 > > # > > # JRE version: 7.0_09-b05 > > # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.5-b02 mixed mode > bsd-amd64 > > compressed oops) > > # Problematic frame: > > # C [libobjc.A.dylib+0x6250] objc_msgSend+0x10 > > # > > # Failed to write core dump. Core dumps have been disabled. To enable > core > > dumping, try "ulimit -c unlimited" before starting Java again > > # > > # An error report file with more information is saved as: > > # > /Users/franckwolff/shop-admin/shop-admin-javafx/javafx/hs_err_pid366.log > > # > > # If you would like to submit a bug report, please visit: > > # http://bugreport.sun.com/bugreport/crash.jsp > > # The crash happened outside the Java Virtual Machine in native code. > > # See problematic frame for where to report the bug. > > # > > Abort trap: 6 > > > > I have been able to reproduce the issue (same environment) and I really > > don't know what to do with this error ("outside the Java Virtual Machine > in > > native code")... > > > > You shouldn't experience this problem on Windows, and hopefully on Linux. > > > > Franck. > > > > 2012/11/29 Richard Bair > > > >> Cool! Are there any online samples? BlazeDS I remember had some great > >> sample pages or videos (I don't remember which) that showed things such > as > >> two browser windows open, writing in one and auto-updating the UI in the > >> other, etc. I'm wondering if graniteds has anything of that kind? > >> > >> Thanks > >> Richard > >> > >> On Nov 29, 2012, at 8:21 AM, Franck Wolff > >> wrote: > >> > >>> Hi all, > >>> > >>> We have long been providing a solution to Flex developers, and have > >>> recently released a version of our product that supports JavaFX 2.2: > >> Granite > >>> Data Services (GraniteDS) is a > comprehensive > >>> development and integration solution for building Flex (and now > JavaFX) / > >>> JavaEE RIA applications. The entire framework is open-source and > released > >>> under the LGPL v2 license. > >>> > >>> To know more about what GraniteDS provides to JavaFX developers, see a > >>> comprehensive documentation > >>> here< > >> > http://www.graniteds.org/public/docs/3.0.0/docs/reference/java/en-US/html/index.html > >>> > >>> . > >>> > >>> The full announcement about this new 3.0.0.M1 version is available > >>> here< > >> > http://granitedataservices.com/blog/2012/11/26/granite-data-services-3-0-0-m1-is-out/ > >>> , > >>> together with several links to tutorials and resources. This first > public > >>> release of a GraniteDS for JavaFX is clearly in a beta stage at this > >> time, > >>> but with the help of your feedback, we hope to be able to provide new > >>> milestones and a stable 3.0.0.GA within the coming months. > >>> > >>> Here are some additional links: > >>> > >>> > >>> - Community Site: http://www.graniteds.org/ > >>> - Blog: http://granitedataservices.com/blog/ > >>> - Forum: https://groups.google.com/forum/?fromgroups#!forum/graniteds > >>> - Bug Tracking System (Jira): > >>> > >> > http://www.graniteds.org/jira/browse/GDS?report=com.atlassian.jira.plugin.system.project:roadmap-panel > >>> - Nightly Builds (Bamboo): > >>> http://www.graniteds.org/bamboo/allPlans.action > >>> - Source Repository: https://github.com/graniteds > >>> - Maven Repository: http://repo2.maven.org/maven2/org/graniteds/ > >>> > >>> Your feedback will be greatly appreciated, > >>> > >>> Franck Wolff > >> > >> > > > > > > -- > > Franck Wolff > > Granite Data Services Inc. > > CEO & Founder > -- Franck Wolff Granite Data Services Inc. CEO & Founder From kevin.rushforth at oracle.com Mon Dec 3 08:49:05 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 03 Dec 2012 08:49:05 -0800 Subject: JavaFX 2.2.6-ea in JDK 1.7u12 In-Reply-To: References: Message-ID: <50BCD801.7030408@oracle.com> This is in progress and should be available this week. Look for it here: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/ I'll send e-mail when ready. -- Kevin Sven Reimers wrote: > Is there a corresponding hg repository available? > > Thanks > > Sven > From david.grieve at oracle.com Mon Dec 3 09:13:30 2012 From: david.grieve at oracle.com (David Grieve) Date: Mon, 3 Dec 2012 12:13:30 -0500 Subject: StyleManager#reloadStylesheets(Scene) replacement in FX8 In-Reply-To: <50BA1713.7050607@bestsolution.at> References: <50BA1713.7050607@bestsolution.at> Message-ID: Remove and re-add the stylesheet. On Dec 1, 2012, at 9:41 AM, Tom Schindl wrote: > Hi, > > To force reloading of stylesheets I used in FX2.2 > StyleManager.getInstance().reloadStylesheets(scene). What is the > replacement of this in FX8. > > Tom > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From tom.schindl at bestsolution.at Mon Dec 3 09:28:52 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 3 Dec 2012 18:28:52 +0100 Subject: StyleManager#reloadStylesheets(Scene) replacement in FX8 In-Reply-To: References: <50BA1713.7050607@bestsolution.at> Message-ID: <458C66E9-BAFF-4AC8-9614-E750E28693D5@bestsolution.at> So they are not cached anymore, like in previous versions, great! Ton Von meinem iPhone gesendet Am 03.12.2012 um 18:13 schrieb David Grieve : > Remove and re-add the stylesheet. > > On Dec 1, 2012, at 9:41 AM, Tom Schindl wrote: > >> Hi, >> >> To force reloading of stylesheets I used in FX2.2 >> StyleManager.getInstance().reloadStylesheets(scene). What is the >> replacement of this in FX8. >> >> 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 swpalmer at gmail.com Mon Dec 3 09:33:03 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 3 Dec 2012 12:33:03 -0500 Subject: Where is the 2.2.4 repo? Message-ID: The main page at http://openjdk.java.net/projects/openjfx/ lists URLs for 2.1, not even 2.2.0. Where can I see the changes in 2.2.4? I had a clone of http://hg.openjdk.java.net/openjfx/2.2/master/rt but the tags in it only show 2.2-b21. There are no tags for 2.2.x maintenance releases. I tried browsing to http://hg.openjdk.java.net/openjfx/ but that just leads to a Python error on the server :-) I tried browsing to http://hg.openjdk.java.net/openjfx/2.2.4/ but that just leads to a "dummy repository" that has the description "OpenJFX 2.2.2" instead of "2.2.4" I tried browsing to http://hg.openjdk.java.net/openjfx/2.2.4/master and the log shows that three months ago the URL for 2.2.2 was fixed (still not 2.2.4) It looks like 7u10 is out the door? (jdk7.java.net has a download marked FCS, even though the main pages at Oracle are still offering 7u9) ? which includes JavaFX 2.2.4 ? and I wanted to know what changed. Scott From felipe.heidrich at oracle.com Mon Dec 3 10:13:17 2012 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Mon, 3 Dec 2012 10:13:17 -0800 Subject: TextFlow and Min vs. Pref size In-Reply-To: References: Message-ID: Hi, It was not an oversight but not something I play around all that much. The behavior is described in the javadoc: preferred size is ideal size where no line needs to wrap. minimal size is the for padding, nothing more. When the width is between min size and pref size lines will wrap. maximum size is unbounded. I think the problem was I couldn't define minimal size any another way ? What else could it be, lines just wrap "a little bit" ? In my tests when I made minimal equals to preferred what happened was that I could not longer resize the parent container so that lines would wrap. I'm out of town this week but I'll do my best to try your snippet, please feel free to file a jira if you preferred. I'm more than glad helping out or even modifying the behavior. Regards, Felipe On Dec 2, 2012, at 9:20 PM, Danno Ferrin wrote: > I was playing with the TextFlow bits in the JDK8 ea and was wondering about > the handling of min vs pref sizing. The TextFlow can return some very > small min sizes which are much smaller than the contained text elements. > For example, I have a text with min/pref/max all of 269.85 x 30.62 while > the min/pref/max of the parent TextFlow (which contains just the text node) > of 0.0 x 17.2 / 269.85 x 48.62 / maxValuexmaxValue. This is problematic > when place in a scroll pane, as all the text flows tend to bunch up on each > other. > > Is this a design intent or an oversight? > > For a workaround I've wrapped then TextFlows in panes that report minHeight > as PrefHeight, so I don't see the bunching in scrollpane problem. > > For an interactive example of this behavior I have a toy app at bitbucket: > https://bitbucket.org/shemnon/flowdown From kevin.rushforth at oracle.com Mon Dec 3 10:27:59 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 03 Dec 2012 10:27:59 -0800 Subject: Where is the 2.2.4 repo? In-Reply-To: References: Message-ID: <50BCEF2F.3050205@oracle.com> The correct URL would be http://hg.openjdk.java.net/openjfx/2.2.4/master/rt except that the JDK 7u10 / FX 2.2.4 release was done as a limited, closed update release, so what is there right now is not accurate (the 2.2.4 forest will be renamed to 2.2.6 on openjdk this week...we had planned to do it several weeks ago, but it fell through the cracks). The following JIRA query will give you a list of issues fixed in the 2.2.4 release: http://javafx-jira.kenai.com/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+RT+AND+resolution+%3D+Fixed+AND+fixVersion+%3D+%222.2.4%22 -- Kevin Scott Palmer wrote: > The main page at http://openjdk.java.net/projects/openjfx/ lists URLs for 2.1, not even 2.2.0. Where can I see the changes in 2.2.4? > > I had a clone of http://hg.openjdk.java.net/openjfx/2.2/master/rt but the tags in it only show 2.2-b21. There are no tags for 2.2.x maintenance releases. > > I tried browsing to http://hg.openjdk.java.net/openjfx/ but that just leads to a Python error on the server :-) > I tried browsing to http://hg.openjdk.java.net/openjfx/2.2.4/ but that just leads to a "dummy repository" that has the description "OpenJFX 2.2.2" instead of "2.2.4" > I tried browsing to http://hg.openjdk.java.net/openjfx/2.2.4/master and the log shows that three months ago the URL for 2.2.2 was fixed (still not 2.2.4) > > It looks like 7u10 is out the door? (jdk7.java.net has a download marked FCS, even though the main pages at Oracle are still offering 7u9) > ? which includes JavaFX 2.2.4 ? and I wanted to know what changed. > > > Scott > > From richard.bair at oracle.com Mon Dec 3 10:57:15 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 3 Dec 2012 10:57:15 -0800 Subject: Porting JavaFX Message-ID: The post is intended to lay out the different activities that need to be undertaken in order to do a port from JavaFX to any platform, but with special emphasis on iOS. There are many, many details which will only be discoverable and actionable once the code is all open sourced, so this post itself is necessarily only high level and intended as some kind of guide to ensuing discussions. There are, essentially, 3 things that must be done to port JavaFX to any platform: * Port a JVM and the Java class libraries * Port JavaFX (Glass, and to some minimal extent, Prism) * Provide a toolchain for building apps for the target environment In the existing desktop ports, #3 is sort of taken for granted because you have javac and such available to you. However as you attempt to target app stores, the jfxpackager & app bundling becomes much more important. On iOS, there is a lot here that has to be done, providing "entitlements", code signing with an Apple certificate, proper bundle generation, etc. There will most likely need to be some toolchain interop with Xcode for example. *Port A JVM and the Java Class Libraries* This is the first major body of work. Getting a JVM that will run on the target device is the first order of business. There are several options available, although no official HotSpot support (yet) for iOS. Some open source VM options might include XMLVM or Avian. Any VM that wants to have acceptable performance on iOS and WinRT will need to support ahead-of-time (AOT) compilation since just-in-time (JIT) compilation is prohibited on these platforms. [Aside: on iOS for example it simply *is not possible* to mark a memory segment as executable. That means that there is no way to have runtime code generation. This is done for security reasons -- JIT security bugs in fact do exist, the Safari JIT having had such bug publicly exposed a year or so ago. Note that Apple allows Safari to JIT, but they aren't going to let 3rd parties do the same). The next step is getting a port of the Java class libraries. Some things will just work -- anything that the JVM was responsible for implementing, such as threading, or anything that is just plain Java code. But many other things such as networking and imageIO, for example, will need to be implemented. For iOS, starting from the OpenJDK Mac code base might be a good start. You don't have to worry about Swing / AWT since the basis we would use to target these devices is JavaSE Embedded, not JavaSE itself, and I do not believe that Swing/AWT are required for SE Embedded. But if you are really adventurous, there is no reason (that I know of) that you couldn't get all of JavaSE working since the Mac OS port of SE uses a lightweight AWT (AWT components are emulated using Swing -- let that swirl in your noodle for a while ;-)). For a quick and dirty hack, you can cut all kinds of corners here. For an actual GA release, porting all the required SE libraries over is an absolute necessity. This is, in my estimation, the most difficult part of doing a port to iOS, but maybe that is just because I'm not as familiar with what needs porting on SE vs. FX. *Port JavaFX* Porting JavaFX to a platform mostly involves a new port of Glass. On all ports that we have now (and most of them that we've prototyped), we reuse Prism and Glass and simply provide a new port of Glass. At one point in the past, when Prism & Glass were still not GA quality, we maintained a completely separate Toolkit implementation (com.sun.javafx.tk.Toolkit) which was based on Swing / AWT. This level of abstraction we want to remove from the platform, such that the Scene Graph classes (what I often call "the top half" -- meaning, the top part of our cake diagram) will refer directly to Glass / Prism classes ("the bottom half"), whereas now there are a series of interfaces that separate the two. At this point, every port we're looking at will be a port of Glass / Prism. Most of the work is in Glass. Glass is the "windowing layer", and has all the code for handling the event queue, windows, views (areas inside the window that get rendered), etc. There is a boundary between Prism & Glass that is kind of messy which is responsible for negotiating the creation of the View surface so that it is established correctly for OpenGL. Otherwise Prism pretty much just works, because we use OpenGL ES 2 for both desktop and mobile, and we have a pretty good implementation that we use everywhere else. Of course, you could also provide a stylesheet that gave native looks to iOS controls (not hard to do), and would be quite a nice addition to the platform (now that Jasper has added public API for setting the user agent stylesheet). Right now, Glass is designed such that there is a non-trivial amount of native code involved in doing a port. Anybody with experience with Objective-C and iOS should feel reasonably well at home in it. Ideally we'd use a heck of a lot less native code to do a port, but for now, what we have is what we have. *Toolchain* I've about mentioned as much as I wanted to mention on toolchain. It is an important part of the story, so as to make developers productive. Ideally we want to allow people to develop on any platform for any platform. Some work will need to be done to see if that is even possible for iOS. Today every toolchain I know of for iOS requires Xcode. Maybe you can figure out how to do the cryptographic signing from Linux or Windows instead, and not require Xcode at all. Also, of course, creating a co-bundled application using a subset of the JRE is critical to get sizes down to something respectable. I believe 50mb is the limit for an application that wants to be downloadable over-the-air. Obviously we want to keep the runtime to a reasonable fraction of that to allow room for the application itself. *Performance* On iOS, our existing prototypes don't have AOT. This has proven to be a big barrier to performance. I actually was blown away at how fast the hotspot interpreter was on iOS -- but no matter how fast it was, it is really (*really*) hard to get smooth graphics performance without AOT. We did do an amazing amount of performance work in this area a few months ago which has benefited desktop & embedded as well (often to a surprising degree). However there is only so much you can do in an interpreter. On the other hand, AOT, we believe, when used on everything will balloon the size of the application. So AOT needs to have some kind of control of what is AOT'd. Critical sections of Prism and the Scene Graph would need to be AOT'd to get optimal performance. We had an example where we ran FX on normal iPhone and on a jail broken iPod with JIT, and it was very fast on the iPod with JIT. We got to the point where the interpreted JVM on iPhone was quite good even for the schedule builder (which is reasonably complicated) -- the performance (on interpreter!) was indistinguishable from native, but required various performance tweaks and hacks in the application code. So although without a JIT with FX we could get good performance with effort on the application developer's part (requiring some extensive knowledge of the platform), with AOT, performance is good by default. Android was interesting. We had two ports, one that used the Android graphics APIs and one that used Prism / Glass. The Prism/ Glass version was at least as fast as the one using Android APIs. This validated our notion of using Glass / Prism everywhere and removing the Toolkit APIs as it was our feeling that we would not any longer need this level of abstraction. *GWT Port* For what it is worth, a few years ago we prototyped several ports of JavaFX using GWT to be able to run in a web browser without a plugin. This is not likely to be something that *we* will do, because any non-plugin solution for the web will not be "real" Java -- it cannot properly support threading and many other things that are integral to a real WORA solution around Java. Some solutions such as Emscripten are very interesting to me, which basically is a VM that JIT's into JavaScript (!!). I've long dreamt about having a JVM implemented in JavaScript such that we could run real Java in the browser without a plugin. Of course, performance is generally abysmal because you are interpreting Java in JavaScript. However with something like Emscripten, if we were very, very clever, you might get "browser native" performance by translating Java byte codes into JavaScript code which would then be handled natively by the browser. Key problems: threading & memory management (missing PhantomReference, WeakReference, etc support in JavaScript). However, even if *we* are not going to support GWT-like solution, there is no reason that the open source community could not do so. Our solution for this explored a few options. The idea was that much of the public API would be able to translate directly to JavaScript via GWT. Also the idea was that the Toolkit interface allowed us to virtualize the threading rules, such that you could have an implementation where the UI thread and render thread were the same thing, or different things. And in fact we will try to preserve this as we remove the Toolkit abstraction, such that a JavaME port (for example) or a GWT port could continue to work. Since there is not good threading support in JavaScript, we need all of the FX code to run in the same thread. There would no doubt need to be patches to enable this kind of implementation, and I'd be view such attempts very favorably. We had an implementation that used SVG for rendering, an implementation using DOM + Canvas, and DOM + WebGL. There were problems with all attempts, but I think each worked reasonably well for many things. Typical problem areas are effects, editable text, and media. If you could run most of Glass / Prism then using WebGL at the very bottom might work, but performance isn't going to be all that grand. Performance of animations is going to be problematic unless you can leverage CSS animations in some way. There are a lot of issues here. That's it for now. Richard From richard.bair at oracle.com Mon Dec 3 11:05:45 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 3 Dec 2012 11:05:45 -0800 Subject: Porting JavaFX Message-ID: The post is intended to lay out the different activities that need to be undertaken in order to do a port from JavaFX to any platform, but with special emphasis on iOS. There are many, many details which will only be discoverable and actionable once the code is all open sourced, so this post itself is necessarily only high level and intended as some kind of guide to ensuing discussions. There are, essentially, 3 things that must be done to port JavaFX to any platform: * Port a JVM and the Java class libraries * Port JavaFX (Glass, and to some minimal extent, Prism) * Provide a toolchain for building apps for the target environment In the existing desktop ports, #3 is sort of taken for granted because you have javac and such available to you. However as you attempt to target app stores, the jfxpackager & app bundling becomes much more important. On iOS, there is a lot here that has to be done, providing "entitlements", code signing with an Apple certificate, proper bundle generation, etc. There will most likely need to be some toolchain interop with Xcode for example. *Port A JVM and the Java Class Libraries* This is the first major body of work. Getting a JVM that will run on the target device is the first order of business. There are several options available, although no official HotSpot support (yet) for iOS. Some open source VM options might include XMLVM or Avian. Any VM that wants to have acceptable performance on iOS and WinRT will need to support ahead-of-time (AOT) compilation since just-in-time (JIT) compilation is prohibited on these platforms. [Aside: on iOS for example it simply *is not possible* to mark a memory segment as executable. That means that there is no way to have runtime code generation. This is done for security reasons -- JIT security bugs in fact do exist, the Safari JIT having had such bug publicly exposed a year or so ago. Note that Apple allows Safari to JIT, but they aren't going to let 3rd parties do the same). The next step is getting a port of the Java class libraries. Some things will just work -- anything that the JVM was responsible for implementing, such as threading, or anything that is just plain Java code. But many other things such as networking and imageIO, for example, will need to be implemented. For iOS, starting from the OpenJDK Mac code base might be a good start. You don't have to worry about Swing / AWT since the basis we would use to target these devices is JavaSE Embedded, not JavaSE itself, and I do not believe that Swing/AWT are required for SE Embedded. But if you are really adventurous, there is no reason (that I know of) that you couldn't get all of JavaSE working since the Mac OS port of SE uses a lightweight AWT (AWT components are emulated using Swing -- let that swirl in your noodle for a while ;-)). For a quick and dirty hack, you can cut all kinds of corners here. For an actual GA release, porting all the required SE libraries over is an absolute necessity. This is, in my estimation, the most difficult part of doing a port to iOS, but maybe that is just because I'm not as familiar with what needs porting on SE vs. FX. *Port JavaFX* Porting JavaFX to a platform mostly involves a new port of Glass. On all ports that we have now (and most of them that we've prototyped), we reuse Prism and Glass and simply provide a new port of Glass. At one point in the past, when Prism & Glass were still not GA quality, we maintained a completely separate Toolkit implementation (com.sun.javafx.tk.Toolkit) which was based on Swing / AWT. This level of abstraction we want to remove from the platform, such that the Scene Graph classes (what I often call "the top half" -- meaning, the top part of our cake diagram) will refer directly to Glass / Prism classes ("the bottom half"), whereas now there are a series of interfaces that separate the two. At this point, every port we're looking at will be a port of Glass / Prism. Most of the work is in Glass. Glass is the "windowing layer", and has all the code for handling the event queue, windows, views (areas inside the window that get rendered), etc. There is a boundary between Prism & Glass that is kind of messy which is responsible for negotiating the creation of the View surface so that it is established correctly for OpenGL. Otherwise Prism pretty much just works, because we use OpenGL ES 2 for both desktop and mobile, and we have a pretty good implementation that we use everywhere else. Of course, you could also provide a stylesheet that gave native looks to iOS controls (not hard to do), and would be quite a nice addition to the platform (now that Jasper has added public API for setting the user agent stylesheet). Right now, Glass is designed such that there is a non-trivial amount of native code involved in doing a port. Anybody with experience with Objective-C and iOS should feel reasonably well at home in it. Ideally we'd use a heck of a lot less native code to do a port, but for now, what we have is what we have. *Toolchain* I've about mentioned as much as I wanted to mention on toolchain. It is an important part of the story, so as to make developers productive. Ideally we want to allow people to develop on any platform for any platform. Some work will need to be done to see if that is even possible for iOS. Today every toolchain I know of for iOS requires Xcode. Maybe you can figure out how to do the cryptographic signing from Linux or Windows instead, and not require Xcode at all. Also, of course, creating a co-bundled application using a subset of the JRE is critical to get sizes down to something respectable. I believe 50mb is the limit for an application that wants to be downloadable over-the-air. Obviously we want to keep the runtime to a reasonable fraction of that to allow room for the application itself. *Performance* On iOS, our existing prototypes don't have AOT. This has proven to be a big barrier to performance. I actually was blown away at how fast the hotspot interpreter was on iOS -- but no matter how fast it was, it is really (*really*) hard to get smooth graphics performance without AOT. We did do an amazing amount of performance work in this area a few months ago which has benefited desktop & embedded as well (often to a surprising degree). However there is only so much you can do in an interpreter. On the other hand, AOT, we believe, when used on everything will balloon the size of the application. So AOT needs to have some kind of control of what is AOT'd. Critical sections of Prism and the Scene Graph would need to be AOT'd to get optimal performance. We had an example where we ran FX on normal iPhone and on a jail broken iPod with JIT, and it was very fast on the iPod with JIT. We got to the point where the interpreted JVM on iPhone was quite good even for the schedule builder (which is reasonably complicated) -- the performance (on interpreter!) was indistinguishable from native, but required various performance tweaks and hacks in the application code. So although without a JIT with FX we could get good performance with effort on the application developer's part (requiring some extensive knowledge of the platform), with AOT, performance is good by default. Android was interesting. We had two ports, one that used the Android graphics APIs and one that used Prism / Glass. The Prism/ Glass version was at least as fast as the one using Android APIs. This validated our notion of using Glass / Prism everywhere and removing the Toolkit APIs as it was our feeling that we would not any longer need this level of abstraction. *GWT Port* For what it is worth, a few years ago we prototyped several ports of JavaFX using GWT to be able to run in a web browser without a plugin. This is not likely to be something that *we* will do, because any non-plugin solution for the web will not be "real" Java -- it cannot properly support threading and many other things that are integral to a real WORA solution around Java. Some solutions such as Emscripten are very interesting to me, which basically is a VM that JIT's into JavaScript (!!). I've long dreamt about having a JVM implemented in JavaScript such that we could run real Java in the browser without a plugin. Of course, performance is generally abysmal because you are interpreting Java in JavaScript. However with something like Emscripten, if we were very, very clever, you might get "browser native" performance by translating Java byte codes into JavaScript code which would then be handled natively by the browser. Key problems: threading & memory management (missing PhantomReference, WeakReference, etc support in JavaScript). However, even if *we* are not going to support GWT-like solution, there is no reason that the open source community could not do so. Our solution for this explored a few options. The idea was that much of the public API would be able to translate directly to JavaScript via GWT. Also the idea was that the Toolkit interface allowed us to virtualize the threading rules, such that you could have an implementation where the UI thread and render thread were the same thing, or different things. And in fact we will try to preserve this as we remove the Toolkit abstraction, such that a JavaME port (for example) or a GWT port could continue to work. Since there is not good threading support in JavaScript, we need all of the FX code to run in the same thread. There would no doubt need to be patches to enable this kind of implementation, and I'd be view such attempts very favorably. We had an implementation that used SVG for rendering, an implementation using DOM + Canvas, and DOM + WebGL. There were problems with all attempts, but I think each worked reasonably well for many things. Typical problem areas are effects, editable text, and media. If you could run most of Glass / Prism then using WebGL at the very bottom might work, but performance isn't going to be all that grand. Performance of animations is going to be problematic unless you can leverage CSS animations in some way. There are a lot of issues here. That's it for now. Richard From philip.race at oracle.com Mon Dec 3 11:11:38 2012 From: philip.race at oracle.com (Phil Race) Date: Mon, 03 Dec 2012 11:11:38 -0800 Subject: Porting JavaFX In-Reply-To: References: Message-ID: <50BCF96A.4020505@oracle.com> On 12/3/12 10:57 AM, Richard Bair wrote: > For iOS, starting from the OpenJDK Mac code base might be a good start. You don't have to worry about Swing / AWT since the basis we would use to target these devices is JavaSE Embedded, not JavaSE itself, and I do not believe that Swing/AWT are required for SE Embedded. But if you are really adventurous, there is no reason (that I know of) that you couldn't get all of JavaSE working since the Mac OS port of SE uses a lightweight AWT (AWT components are emulated using Swing -- let that swirl in your noodle for a while ;-)). > SE uses a number of APIs that Apple provided on OS X specifically for OpenJDK as the JavaRuntimeSupport framework and those won't exist on iOS, so it won't be quite that easy to do a full SE port. -phil. From hang.vo at oracle.com Mon Dec 3 11:47:35 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 03 Dec 2012 19:47:35 +0000 Subject: hg: openjfx/8/graphics/rt: 3 new changesets Message-ID: <20121203194740.8622F47CFE@hg.openjdk.java.net> Changeset: 1a0cf70decaf Author: Seeon Birger Date: 2012-11-26 20:01 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1a0cf70decaf RT-26478: Restored call to fxvk.setPrefWidth(VK_WIDTH) that was removed by a fix to RT-25181. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java Changeset: 496c1bca757f Author: David Hill Date: 2012-11-28 13:40 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/496c1bca757f Automated merge with ssh://javafxsrc.us.oracle.com//javafx/8.0/scrum//graphics/jfx/rt Changeset: fa1ad3d3186a Author: David Hill Date: 2012-12-03 10:53 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fa1ad3d3186a Automated merge with ssh://javafxsrc.us.oracle.com//javafx/8.0/scrum//embedded/jfx/rt - javafx-fxml/test/javafx/fxml/RT_14880.java - javafx-fxml/test/javafx/fxml/RT_15524.java - javafx-fxml/test/javafx/fxml/RT_16722.java - javafx-fxml/test/javafx/fxml/RT_16724.java - javafx-fxml/test/javafx/fxml/RT_16815.java - javafx-fxml/test/javafx/fxml/RT_16977.java - javafx-fxml/test/javafx/fxml/RT_17646.java - javafx-fxml/test/javafx/fxml/RT_17714.java - javafx-fxml/test/javafx/fxml/RT_18046.java - javafx-fxml/test/javafx/fxml/RT_18218.java - javafx-fxml/test/javafx/fxml/RT_18680.java - javafx-fxml/test/javafx/fxml/RT_18933.java - javafx-fxml/test/javafx/fxml/RT_19008.java - javafx-fxml/test/javafx/fxml/RT_19112.java - javafx-fxml/test/javafx/fxml/RT_19139.java - javafx-fxml/test/javafx/fxml/RT_19228.java - javafx-fxml/test/javafx/fxml/RT_19329.java - javafx-fxml/test/javafx/fxml/RT_19870.java - javafx-fxml/test/javafx/fxml/RT_20082.java - javafx-fxml/test/javafx/fxml/RT_20471.java - javafx-fxml/test/javafx/fxml/RT_21559.java - javafx-fxml/test/javafx/fxml/RT_22864.java - javafx-fxml/test/javafx/fxml/RT_22971.java - javafx-fxml/test/javafx/fxml/RT_23244.java - javafx-fxml/test/javafx/fxml/RT_23413.java - javafx-fxml/test/javafx/fxml/RT_24380.java From ozemale at ozemail.com.au Mon Dec 3 11:49:50 2012 From: ozemale at ozemail.com.au (ozemale at ozemail.com.au) Date: Tue, 04 Dec 2012 03:49:50 +0800 Subject: Porting JavaFX In-Reply-To: Message-ID: <808f8478418acfcb310ab8310a07c1a7caf32e1f@webmail.iinet.net.au> Thanks for the detailed info Richard. Are you in a position to state where you are up to in the iOS port?? It sounds like there's a long way to go or have you got many of these areas working already? Thanks, -jct ----- Original Message ----- From: "Richard Bair" To:"OpenJFX Mailing List" Cc: Sent:Mon, 3 Dec 2012 11:05:45 -0800 Subject:Porting JavaFX The post is intended to lay out the different activities that need to be undertaken in order to do a port from JavaFX to any platform, but with special emphasis on iOS. There are many, many details which will only be discoverable and actionable once the code is all open sourced, so this post itself is necessarily only high level and intended as some kind of guide to ensuing discussions. There are, essentially, 3 things that must be done to port JavaFX to any platform: * Port a JVM and the Java class libraries * Port JavaFX (Glass, and to some minimal extent, Prism) * Provide a toolchain for building apps for the target environment In the existing desktop ports, #3 is sort of taken for granted because you have javac and such available to you. However as you attempt to target app stores, the jfxpackager & app bundling becomes much more important. On iOS, there is a lot here that has to be done, providing "entitlements", code signing with an Apple certificate, proper bundle generation, etc. There will most likely need to be some toolchain interop with Xcode for example. *Port A JVM and the Java Class Libraries* This is the first major body of work. Getting a JVM that will run on the target device is the first order of business. There are several options available, although no official HotSpot support (yet) for iOS Some open source VM options might include XMLVM or Avian. Any VM that wants to have acceptable performance on iOS and WinRT will need to support ahead-of-time (AOT) compilation since just-in-time (JIT) compilation is prohibited on these platforms. [Aside: on iOS for example it simply *is not possible* to mark a memory segment as executable. That means that there is no way to have runtime code generation. This is done for security reasons -- JIT security bugs in fact do exist, the Safari JIT having had such bug publicly exposed a year or so ago. Note that Apple allows Safari to JIT, but they aren't going to let 3rd parties do the same). The next step is getting a port of the Java class libraries. Some things will just work -- anything that the JVM was responsible for implementing, such as threading, or anything that is just plain Java code. But many other things such as networking and imageIO, for example, will need to be implemented. For iOS, starting from the OpenJDK Mac code base might be a good start. You don't have to worry about Swing / AWT since the basis we would use to target these devices is JavaSE Embedded, not JavaSE itself, and I do not believe that Swing/AWT are required for SE Embedded. But if you are really adventurous, there is no reason (that I know of) that you couldn't get all of JavaSE working since the Mac OS port of SE uses a lightweight AWT (AWT components are emulated using Swing -- let that swirl in your noodle for a while ;-)). For a quick and dirty hack, you can cut all kinds of corners here. For an actual GA release, porting all the required SE libraries over is an absolute necessity. This is, in my estimation, the most difficult part of doing a port to iOS, but maybe that is just because I'm not as familiar with what needs porting on SE vs. FX. *Port JavaFX* Porting JavaFX to a platform mostly involves a new port of Glass. On all ports that we have now (and most of them that we've prototyped), we reuse Prism and Glass and simply provide a new port of Glass. At one point in the past, when Prism & Glass were still not GA quality, we maintained a completely separate Toolkit implementation (com.sun.javafx.tk.Toolkit) which was based on Swing / AWT This level of abstraction we want to remove from the platform, such that the Scene Graph classes (what I often call "the top half" -- meaning, the top part of our cake diagram) will refer directly to Glass / Prism classes ("the bottom half"), whereas now there are a series of interfaces that separate the two. At this point, every port we're looking at will be a port of Glass / Prism. Most of the work is in Glass. Glass is the "windowing layer", and has all the code for handling the event queue, windows, views (areas inside the window that get rendered), etc. There is a boundary between Prism & Glass that is kind of messy which is responsible for negotiating the creation of the View surface so that it is established correctly for OpenGL. Otherwise Prism pretty much just works, because we use OpenGL ES 2 for both desktop and mobile, and we have a pretty good implementation that we use everywhere else. Of course, you could also provide a stylesheet that gave native looks to iOS controls (not hard to do), and would be quite a nice addition to the platform (now that Jasper has added public API for setting the user agent stylesheet). Right now, Glass is designed such that there is a non-trivial amount of native code involved in doing a port. Anybody with experience with Objective-C and iOS should feel reasonably well at home in it. Ideally we'd use a heck of a lot less native code to do a port, but for now, what we have is what we have. *Toolchain* I've about mentioned as much as I wanted to mention on toolchain. It is an important part of the story, so as to make developers productive. Ideally we want to allow people to develop on any platform for any platform. Some work will need to be done to see if that is even possible for iOS. Today every toolchain I know of for iOS requires Xcode. Maybe you can figure out how to do the cryptographic signing from Linux or Windows instead, and not require Xcode at all. Also, of course, creating a co-bundled application using a subset of the JRE is critical to get sizes down to something respectable. I believe 50mb is the limit for an application that wants to be downloadable over-the-air. Obviously we want to keep the runtime to a reasonable fraction of that to allow room for the application itself. *Performance* On iOS, our existing prototypes don't have AOT. This has proven to be a big barrier to performance. I actually was blown away at how fast the hotspot interpreter was on iOS -- but no matter how fast it was, it is really (*really*) hard to get smooth graphics performance without AOT. We did do an amazing amount of performance work in this area a few months ago which has benefited desktop & embedded as well (often to a surprising degree). However there is only so much you can do in an interpreter. On the other hand, AOT, we believe, when used on everything will balloon the size of the application. So AOT needs to have some kind of control of what is AOT'd. Critical sections of Prism and the Scene Graph would need to be AOT'd to get optimal performance. We had an example where we ran FX on normal iPhone and on a jail broken iPod with JIT, and it was very fast on the iPod with JIT. We got to the point where the interpreted JVM on iPhone was quite good even for the schedule builder (which is reasonably complicated) -- the performance (on interpreter!) was indistinguishable from native, but required various performance tweaks and hacks in the application code. So although without a JIT with FX we could get good performance with effort on the application developer's part (requiring some extensive knowledge of the platform), with AOT, performance is good by default. Android was interesting. We had two ports, one that used the Android graphics APIs and one that used Prism / Glass. The Prism/ Glass version was at least as fast as the one using Android APIs. This validated our notion of using Glass / Prism everywhere and removing the Toolkit APIs as it was our feeling that we would not any longer need this level of abstraction. *GWT Port* For what it is worth, a few years ago we prototyped several ports of JavaFX using GWT to be able to run in a web browser without a plugin. This is not likely to be something that *we* will do, because any non-plugin solution for the web will not be "real" Java -- it cannot properly support threading and many other things that are integral to a real WORA solution around Java. Some solutions such as Emscripten are very interesting to me, which basically is a VM that JIT's into JavaScript (!!) I've long dreamt about having a JVM implemented in JavaScript such that we could run real Java in the browser without a plugin. Of course, performance is generally abysmal because you are interpreting Java in JavaScript. However with something like Emscripten, if we were very, very clever, you might get "browser native" performance by translating Java byte codes into JavaScript code which would then be handled natively by the browser. Key problems: threading & memory management (missing PhantomReference, WeakReference, etc support in JavaScript). However, even if *we* are not going to support GWT-like solution, there is no reason that the open source community could not do so. Our solution for this explored a few options. The idea was that much of the public API would be able to translate directly to JavaScript via GWT. Also the idea was that the Toolkit interface allowed us to virtualize the threading rules, such that you could have an implementation where the UI thread and render thread were the same thing, or different things. And in fact we will try to preserve this as we remove the Toolkit abstraction, such that a JavaME port (for example) or a GWT port could continue to work. Since there is not good threading support in JavaScript, we need all of the FX code to run in the same thread. There would no doubt need to be patches to enable this kind of implementation, and I'd be view such attempts very favorably. We had an implementation that used SVG for rendering, an implementation using DOM + Canvas, and DOM + WebGL. There were problems with all attempts, but I think each worked reasonably well for many things. Typical problem areas are effects, editable text, and media. If you could run most of Glass / Prism then using WebGL at the very bottom might work, but performance isn't going to be all that grand. Performance of animations is going to be problematic unless you can leverage CSS animations in some way. There are a lot of issues here. That's it for now. Richard From richard.bair at oracle.com Mon Dec 3 11:56:10 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 3 Dec 2012 11:56:10 -0800 Subject: Porting JavaFX In-Reply-To: <808f8478418acfcb310ab8310a07c1a7caf32e1f@webmail.iinet.net.au> References: <808f8478418acfcb310ab8310a07c1a7caf32e1f@webmail.iinet.net.au> Message-ID: We haven't done anything for toolchain (beyond the app bundling we're currently doing for desktop). We have a port of FX on Android & iOS, but I cannot comment publicly much more on those. And I don't have any news on the JDK side of the port (I don't know what that status is or plans around it). Richard On Dec 3, 2012, at 11:49 AM, ozemale at ozemail.com.au wrote: > Thanks for the detailed info Richard. > > Are you in a position to state where you are up to in the iOS port? It sounds like there's a long way to go or have you got many of these areas working already? > > Thanks, > > -jct > > ----- Original Message ----- > From: > "Richard Bair" > > To: > "OpenJFX Mailing List" > Cc: > > Sent: > Mon, 3 Dec 2012 11:05:45 -0800 > Subject: > Porting JavaFX > > > > The post is intended to lay out the different activities that need to be undertaken in order to do a port from JavaFX to any platform, but with special emphasis on iOS. There are many, many details which will only be discoverable and actionable once the code is all open sourced, so this post itself is necessarily only high level and intended as some kind of guide to ensuing discussions. > > There are, essentially, 3 things that must be done to port JavaFX to any platform: > * Port a JVM and the Java class libraries > * Port JavaFX (Glass, and to some minimal extent, Prism) > * Provide a toolchain for building apps for the target environment > > In the existing desktop ports, #3 is sort of taken for granted because you have javac and such available to you. However as you attempt to target app stores, the jfxpackager & app bundling becomes much more important. On iOS, there is a lot here that has to be done, providing "entitlements", code signing with an Apple certificate, proper bundle generation, etc. There will most likely need to be some toolchain interop with Xcode for example. > > *Port A JVM and the Java Class Libraries* > > This is the first major body of work. Getting a JVM that will run on the target device is the first order of business. There are several options available, although no official HotSpot support (yet) for iOS. Some open source VM options might include XMLVM or Avian. Any VM that wants to have acceptable performance on iOS and WinRT will need to support ahead-of-time (AOT) compilation since just-in-time (JIT) compilation is prohibited on these platforms. [Aside: on iOS for example it simply *is not possible* to mark a memory segment as executable. That means that there is no way to have runtime code generation. This is done for security reasons -- JIT security bugs in fact do exist, the Safari JIT having had such bug publicly exposed a year or so ago. Note that Apple allows Safari to JIT, but they aren't going to let 3rd parties do the same). > > The next step is getting a port of the Java class libraries. Some things will just work -- anything that the JVM was responsible for implementing, such as threading, or anything that is just plain Java code. But many other things such as networking and imageIO, for example, will need to be implemented. For iOS, starting from the OpenJDK Mac code base might be a good start. You don't have to worry about Swing / AWT since the basis we would use to target these devices is JavaSE Embedded, not JavaSE itself, and I do not believe that Swing/AWT are required for SE Embedded. But if you are really adventurous, there is no reason (that I know of) that you couldn't get all of JavaSE working since the Mac OS port of SE uses a lightweight AWT (AWT components are emulated using Swing -- let that swirl in your noodle for a while ;-)). > > For a quick and dirty hack, you can cut all kinds of corners here. For an actual GA release, porting all the required SE libraries over is an absolute necessity. This is, in my estimation, the most difficult part of doing a port to iOS, but maybe that is just because I'm not as familiar with what needs porting on SE vs. FX. > > *Port JavaFX* > > Porting JavaFX to a platform mostly involves a new port of Glass. On all ports that we have now (and most of them that we've prototyped), we reuse Prism and Glass and simply provide a new port of Glass. At one point in the past, when Prism & Glass were still not GA quality, we maintained a completely separate Toolkit implementation (com.sunjavafx.tk.Toolkit) which was based on Swing / AWT. This level of abstraction we want to remove from the platform, such that the Scene Graph classes (what I often call "the top half" -- meaning, the top part of our cake diagram) will refer directly to Glass / Prism classes ("the bottom half"), whereas now there are a series of interfaces that separate the two. > > At this point, every port we're looking at will be a port of Glass / Prism. Most of the work is in Glass. Glass is the "windowing layer", and has all the code for handling the event queue, windows, views (areas inside the window that get rendered), etc. There is a boundary between Prism & Glass that is kind of messy which is responsible for negotiating the creation of the View surface so that it is established correctly for OpenGL. Otherwise Prism pretty much just works, because we use OpenGL ES 2 for both desktop and mobile, and we have a pretty good implementation that we use everywhere else. > > Of course, you could also provide a stylesheet that gave native looks to iOS controls (not hard to do), and would be quite a nice addition to the platform (now that Jasper has added public API for setting the user agent stylesheet). > > Right now, Glass is designed such that there is a non-trivial amount of native code involved in doing a port. Anybody with experience with Objective-C and iOS should feel reasonably well at home in it. Ideally we'd use a heck of a lot less native code to do a port, but for now, what we have is what we have. > > *Toolchain* > > I've about mentioned as much as I wanted to mention on toolchain. It is an important part of the story, so as to make developers productive. Ideally we want to allow people to develop on any platform for any platform. Some work will need to be done to see if that is even possible for iOS. Today every toolchain I know of for iOS requires Xcode. Maybe you can figure out how to do the cryptographic signing from Linux or Windows instead, and not require Xcode at all. > > Also, of course, creating a co-bundled application using a subset of the JRE is critical to get sizes down to something respectable. I believe 50mb is the limit for an application that wants to be downloadable over-the-air Obviously we want to keep the runtime to a reasonable fraction of that to allow room for the application itself. > > *Performance* > > On iOS, our existing prototypes don't have AOT. This has proven to be a big barrier to performance. I actually was blown away at how fast the hotspot interpreter was on iOS -- but no matter how fast it was, it is really (*really*) hard to get smooth graphics performance without AOT. We did do an amazing amount of performance work in this area a few months ago which has benefited desktop & embedded as well (often to a surprising degree). However there is only so much you can do in an interpreter. > > On the other hand, AOT, we believe, when used on everything will balloon the size of the application. So AOT needs to have some kind of control of what is AOT'd. Critical sections of Prism and the Scene Graph would need to be AOT'd to get optimal performance We had an example where we ran FX on normal iPhone and on a jail broken iPod with JIT, and it was very fast on the iPod with JIT. We got to the point where the interpreted JVM on iPhone was quite good even for the schedule builder (which is reasonably complicated) -- the performance (on interpreter!) was indistinguishable from native, but required various performance tweaks and hacks in the application code. > > So although without a JIT with FX we could get good performance with effort on the application developer's part (requiring some extensive knowledge of the platform), with AOT, performance is good by default. > > Android was interesting. We had two ports, one that used the Android graphics APIs and one that used Prism / Glass. The Prism/ Glass version was at least as fast as the one using Android APIs. This validated our notion of using Glass / Prism everywhere and removing the Toolkit APIs as it was our feeling that we would not any longer need this level of abstraction. > > *GWT Port* > > For what it is worth, a few years ago we prototyped several ports of JavaFX using GWT to be able to run in a web browser without a plugin. This is not likely to be something that *we* will do, because any non-plugin solution for the web will not be "real" Java -- it cannot properly support threading and many other things that are integral to a real WORA solution around Java. Some solutions such as Emscripten are very interesting to me, which basically is a VM that JIT's into JavaScript (!!). I've long dreamt about having a JVM implemented in JavaScript such that we could run real Java in the browser without a plugin. Of course, performance is generally abysmal because you are interpreting Java in JavaScript. However with something like Emscripten, if we were very, very clever, you might get "browser native" performance by translating Java byte codes into JavaScript code which would then be handled natively by the browser. Key problems: threading & memory management (missing PhantomReference, WeakReference, etc support in JavaScript). > > However, even if *we* are not going to support GWT-like solution, there is no reason that the open source community could not do so. > > Our solution for this explored a few options. The idea was that much of the public API would be able to translate directly to JavaScript via GWT. Also the idea was that the Toolkit interface allowed us to virtualize the threading rules, such that you could have an implementation where the UI thread and render thread were the same thing, or different things. And in fact we will try to preserve this as we remove the Toolkit abstraction, such that a JavaME port (for example) or a GWT port could continue to work. Since there is not good threading support in JavaScript, we need all of the FX code to run in the same thread. > > There would no doubt need to be patches to enable this kind of implementation, and I'd be view such attempts very favorably. > > We had an implementation that used SVG for rendering, an implementation using DOM + Canvas, and DOM + WebGL. There were problems with all attempts, but I think each worked reasonably well for many things. Typical problem areas are effects, editable text, and media. If you could run most of Glass / Prism then using WebGL at the very bottom might work, but performance isn't going to be all that grand. Performance of animations is going to be problematic unless you can leverage CSS animations in some way. There are a lot of issues here. > > That's it for now. > Richard From philip.race at oracle.com Mon Dec 3 11:59:39 2012 From: philip.race at oracle.com (Phil Race) Date: Mon, 03 Dec 2012 11:59:39 -0800 Subject: Printing for JavaFX In-Reply-To: <50B91967.7000300@oracle.com> References: <50B91967.7000300@oracle.com> Message-ID: <50BD04AB.9080708@oracle.com> I have posted some notes and a link to the javadoc for an API proposal which adds printing support to the JavaFX platform. Interested parties please see : https://wikis.oracle.com/display/OpenJDK/Printing+for+JavaFX The API is not going to be committed for a while as there's some implementation work that needs to happen even if the API so far gets approved pretty much as proposed, so there's time for comments and revisions and many minor details are bound to change anyway before release. The JIRA for this feature is http://javafx-jira.kenai.com/browse/RT-17383 So if after reading the notes and the javadoc, you have comments on this API please add them to the JIRA. -phil. From pedro.duquevieira at gmail.com Mon Dec 3 12:08:24 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 3 Dec 2012 20:08:24 +0000 Subject: The competition Message-ID: Hi, I agree with practically everything Daniel said. I've previously stated that deployment is seriously jeopardizing the adoptance of JavaFX. Let me give 3 use-cases I've experienced in which JavaFX wasn't a choice because of this: 1- An hobby project of mine (called Modellus) in which students and teachers can create simulations of math phenomenon. Animation, charts, tables, etc can than be used to better illustrate this. I'm still using JavaFX here but some features will not be possible because of this. *The problem*: Users want to share their models (Modellus files) on the internet via a web site with other users. They don't want this to require other users to download and install Modellus, at least not in a explicit way *The possible solution*: If applets were working this could be feasible. 2- A wallpaper (as in for actual walls) internet shop wants to provide a service to their customers in which they can create their own custom wallpapers. For this, customers can upload images and assemble them in the way they want. *The problem*: Ideally this should require zero install and zero hassle for the customers. The zero install part is not possible with javafx. HTML5 might be the solution however if at all possible one would face serious technical difficulties. *The possible solution*: If applets were working this could be feasible. 3- A Content Management System for mobile phones (initially android and iphone). Through a site an administrator manages the content that should appear in a mobile phone app. *The problem*: JavaFX isn't available for mobile phones. The client has decided to use phone gap for this, however development with this technology is sub optimal and performance is also an issue. *The solution*: Have JavaFX run on mobile phones. Thanks for your time, cheers, -- Pedro Duque Vieira From zonski at gmail.com Mon Dec 3 12:26:15 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 4 Dec 2012 07:26:15 +1100 Subject: Granite Data Services 3.0.0.M1 introduces JavaFX 2.2 support In-Reply-To: References: <96044219-3E2C-4B59-B1BB-AB1872E4592E@oracle.com> Message-ID: Sorry Frank, I was being cheeky. That comment was aimed more at the JavaFX team and was about giving the users a way to easily run your demos, i.e. wouldn't it be cool if you could just send out a URL and a couple of simple, user friendly clicks later your users are running your demo and can see it in action? This issue of deployment is a bit of an on going crusade of mine and the JavaFX guys don't rank it nearly as highly as I do in the priority list so I couldn't resist a chance to highlight a situation where a good deployment option would help win people over to JFX. Regarding your "test drive" for developers a good way to do this might be a Maven archetype - basically a way of creating quick "template" projects (not sure if you guys use Maven for your stuff at all?). I have written a Maven plugin for JavaFX (https://github.com/zonski/javafx-maven-plugin) and also added a simple Maven archetype for a quick starter client-only JFX project (see: http://www.zenjava.com/2012/11/24/from-zero-to-javafx-in-5-minutes/). Last night I also finished a kickstarter archetype for doing a simple REST client-server setup (based on SpringMVC for the server, and JavaFX plus Spring REST templates for the client). It's here: https://github.com/zonski/javafx-rest-archetype We have to wait until Sunday for it to get synched to the main Maven repo at which point I'll write a blog post on how to use it. If you want to have a look before then you can check out a sample generated project at: http://code.google.com/p/zenjava-playtime/source/browse/trunk/javafx-simple-rest-app/ Something like this for your Granite project could well reduce the barrier to entry, giving developers a way to be up and running with a client-server skeleton project in just 5 minutes or so. I intend to add a spring-remoting client-server using HttpInvoker archetype (much better than REST but REST was a good starting point from a marketing angle because web is so popular) that also includes Spring Security and Spring Data (hopefully by xmas or early Jan). Your project is not a bad option for the space I am targeting so if you guys wanted to work together on getting an example skeleton app converted into a Maven archetype I be willing to explore that. Probably best to email me directly. Cheers, Dan On Tue, Dec 4, 2012 at 3:44 AM, Franck Wolff wrote: > Daniel, > > Thanks for your feedback. We will definitely provide a "test drive" in the > next 3.0.0.M2 release, hopefully by the end of the year. It should be based > on a Jetty or Tomcat server (Tomcat can be more complicated because of > native APR libraries), packaged together with few binary sample > applications and their sources. Testing the release would then be only a > matter of downloading the so-called "test drive", starting it and then > running the JavaFX applications (java -jar ... or double-click). > > Is it roughly what you are looking for when saying "if users could run > them with a couple of clicks"? > > Franck. > > > 2012/11/30 Daniel Zwolenski > >> Websockets are a powerful emerging option. Nice use of them in this >> project and nice fallback onto polling given the newness of Websockets. >> >> Imagine how much more powerful those demos would be if users could run >> them with a couple of clicks - sorry, couldn't resist. >> >> >> On 01/12/2012, at 1:01 AM, Franck Wolff >> wrote: >> >> > (sorry for the double post, I first replied to Richard without the >> forum in >> > copy and then tried today to forward my answer, which is not in the same >> > thread, my fault, first time in this forum, won't do it again...) >> > >> > -------------------- >> > >> > The features and the samples you are looking for exist and are available >> > through tutorials: >> > >> > >> http://granitedataservices.com/blog/2012/11/26/real-time-messaging-tutorial-with-javafx-2-2/ >> > >> > >> http://granitedataservices.com/blog/2012/11/26/data-management-tutorial-with-javafx-2-2/ >> > >> > We don't have any other material right now (such as videos or a test >> > drive), but we did our best to make things as clear and easy as >> possible. >> > >> > And yes, if you open each application described in those tutorials >> twice, >> > your changes in one of them will be reflected in the other one "in real >> > time". >> > -------------------- >> > >> > More on the subject: Richard has tried to run the 2nd tutorial on a Mac >> > (Mountain Lion, java 1.7.0_09 64 bits) and it's causing some ugly random >> > crashes of the JVM: >> > >> > # >> > # A fatal error has been detected by the Java Runtime Environment: >> > # >> > # SIGSEGV (0xb) at pc=0x00007fff900dc250, pid=366, tid=9991 >> > # >> > # JRE version: 7.0_09-b05 >> > # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.5-b02 mixed mode >> bsd-amd64 >> > compressed oops) >> > # Problematic frame: >> > # C [libobjc.A.dylib+0x6250] objc_msgSend+0x10 >> > # >> > # Failed to write core dump. Core dumps have been disabled. To enable >> core >> > dumping, try "ulimit -c unlimited" before starting Java again >> > # >> > # An error report file with more information is saved as: >> > # >> /Users/franckwolff/shop-admin/shop-admin-javafx/javafx/hs_err_pid366.log >> > # >> > # If you would like to submit a bug report, please visit: >> > # http://bugreport.sun.com/bugreport/crash.jsp >> > # The crash happened outside the Java Virtual Machine in native code. >> > # See problematic frame for where to report the bug. >> > # >> > Abort trap: 6 >> > >> > I have been able to reproduce the issue (same environment) and I really >> > don't know what to do with this error ("outside the Java Virtual >> Machine in >> > native code")... >> > >> > You shouldn't experience this problem on Windows, and hopefully on >> Linux. >> > >> > Franck. >> > >> > 2012/11/29 Richard Bair >> > >> >> Cool! Are there any online samples? BlazeDS I remember had some great >> >> sample pages or videos (I don't remember which) that showed things >> such as >> >> two browser windows open, writing in one and auto-updating the UI in >> the >> >> other, etc. I'm wondering if graniteds has anything of that kind? >> >> >> >> Thanks >> >> Richard >> >> >> >> On Nov 29, 2012, at 8:21 AM, Franck Wolff >> >> wrote: >> >> >> >>> Hi all, >> >>> >> >>> We have long been providing a solution to Flex developers, and have >> >>> recently released a version of our product that supports JavaFX 2.2: >> >> Granite >> >>> Data Services (GraniteDS) is a >> comprehensive >> >>> development and integration solution for building Flex (and now >> JavaFX) / >> >>> JavaEE RIA applications. The entire framework is open-source and >> released >> >>> under the LGPL v2 license. >> >>> >> >>> To know more about what GraniteDS provides to JavaFX developers, see a >> >>> comprehensive documentation >> >>> here< >> >> >> http://www.graniteds.org/public/docs/3.0.0/docs/reference/java/en-US/html/index.html >> >>> >> >>> . >> >>> >> >>> The full announcement about this new 3.0.0.M1 version is available >> >>> here< >> >> >> http://granitedataservices.com/blog/2012/11/26/granite-data-services-3-0-0-m1-is-out/ >> >>> , >> >>> together with several links to tutorials and resources. This first >> public >> >>> release of a GraniteDS for JavaFX is clearly in a beta stage at this >> >> time, >> >>> but with the help of your feedback, we hope to be able to provide new >> >>> milestones and a stable 3.0.0.GA within the coming months. >> >>> >> >>> Here are some additional links: >> >>> >> >>> >> >>> - Community Site: http://www.graniteds.org/ >> >>> - Blog: http://granitedataservices.com/blog/ >> >>> - Forum: >> https://groups.google.com/forum/?fromgroups#!forum/graniteds >> >>> - Bug Tracking System (Jira): >> >>> >> >> >> http://www.graniteds.org/jira/browse/GDS?report=com.atlassian.jira.plugin.system.project:roadmap-panel >> >>> - Nightly Builds (Bamboo): >> >>> http://www.graniteds.org/bamboo/allPlans.action >> >>> - Source Repository: https://github.com/graniteds >> >>> - Maven Repository: http://repo2.maven.org/maven2/org/graniteds/ >> >>> >> >>> Your feedback will be greatly appreciated, >> >>> >> >>> Franck Wolff >> >> >> >> >> > >> > >> > -- >> > Franck Wolff >> > Granite Data Services Inc. >> > CEO & Founder >> > > > > -- > Franck Wolff > Granite Data Services Inc. > CEO & Founder > > From zonski at gmail.com Mon Dec 3 12:34:15 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 4 Dec 2012 07:34:15 +1100 Subject: Porting JavaFX In-Reply-To: References: <808f8478418acfcb310ab8310a07c1a7caf32e1f@webmail.iinet.net.au> Message-ID: If the Maven plugin can be used for tool-chaining then I'm all ready and willing to do that - just need you guys to set concrete direction on what's needed to make it happen. From franck.wolff at graniteds.org Mon Dec 3 13:14:02 2012 From: franck.wolff at graniteds.org (Franck Wolff) Date: Mon, 3 Dec 2012 16:14:02 -0500 Subject: Granite Data Services 3.0.0.M1 introduces JavaFX 2.2 support In-Reply-To: References: <96044219-3E2C-4B59-B1BB-AB1872E4592E@oracle.com> Message-ID: Daniel, We do use Maven in one of our tutorials: http://granitedataservices.com/blog/2012/11/26/data-management-tutorial-with-javafx-2-2/ The only difference with your REST client-server setup is the way we are starting the JavaFX client application (ie. "java -jar ..." instead of "mvn jfx:run"). Using jfx:run could be an improvement. The best, of course, would be a reliable WebStart solution with an easy one-click startup (we have been used to this kind of instant/no install demos with Flex). But while I agree with you about the importance of this feature, I definitely prefer to see the JavaFX team working on the core features first: a not-so-friendly (or even tedious) startup process of a very good and stable framework is much better than the opposite ;) Franck. 2012/12/3 Daniel Zwolenski > Sorry Frank, I was being cheeky. That comment was aimed more at the JavaFX > team and was about giving the users a way to easily run your demos, i.e. > wouldn't it be cool if you could just send out a URL and a couple of > simple, user friendly clicks later your users are running your demo and can > see it in action? This issue of deployment is a bit of an on going crusade > of mine and the JavaFX guys don't rank it nearly as highly as I do in the > priority list so I couldn't resist a chance to highlight a situation where > a good deployment option would help win people over to JFX. > > Regarding your "test drive" for developers a good way to do this might be > a Maven archetype - basically a way of creating quick "template" projects > (not sure if you guys use Maven for your stuff at all?). I have written a > Maven plugin for JavaFX (https://github.com/zonski/javafx-maven-plugin) > and also added a simple Maven archetype for a quick starter client-only JFX > project (see: > http://www.zenjava.com/2012/11/24/from-zero-to-javafx-in-5-minutes/). > > Last night I also finished a kickstarter archetype for doing a simple REST > client-server setup (based on SpringMVC for the server, and JavaFX plus > Spring REST templates for the client). It's here: > > https://github.com/zonski/javafx-rest-archetype > > We have to wait until Sunday for it to get synched to the main Maven repo > at which point I'll write a blog post on how to use it. If you want to have > a look before then you can check out a sample generated project at: > http://code.google.com/p/zenjava-playtime/source/browse/trunk/javafx-simple-rest-app/ > > Something like this for your Granite project could well reduce the barrier > to entry, giving developers a way to be up and running with a client-server > skeleton project in just 5 minutes or so. > > I intend to add a spring-remoting client-server using > HttpInvoker archetype (much better than REST but REST was a good starting > point from a marketing angle because web is so popular) that also includes > Spring Security and Spring Data (hopefully by xmas or early Jan). Your > project is not a bad option for the space I am targeting so if you guys > wanted to work together on getting an example skeleton app converted into a > Maven archetype I be willing to explore that. Probably best to email me > directly. > > Cheers, > Dan > > > > > > On Tue, Dec 4, 2012 at 3:44 AM, Franck Wolff wrote: > >> Daniel, >> >> Thanks for your feedback. We will definitely provide a "test drive" in >> the next 3.0.0.M2 release, hopefully by the end of the year. It should be >> based on a Jetty or Tomcat server (Tomcat can be more complicated because >> of native APR libraries), packaged together with few binary sample >> applications and their sources. Testing the release would then be only a >> matter of downloading the so-called "test drive", starting it and then >> running the JavaFX applications (java -jar ... or double-click). >> >> Is it roughly what you are looking for when saying "if users could run >> them with a couple of clicks"? >> >> Franck. >> >> >> 2012/11/30 Daniel Zwolenski >> >>> Websockets are a powerful emerging option. Nice use of them in this >>> project and nice fallback onto polling given the newness of Websockets. >>> >>> Imagine how much more powerful those demos would be if users could run >>> them with a couple of clicks - sorry, couldn't resist. >>> >>> >>> On 01/12/2012, at 1:01 AM, Franck Wolff >>> wrote: >>> >>> > (sorry for the double post, I first replied to Richard without the >>> forum in >>> > copy and then tried today to forward my answer, which is not in the >>> same >>> > thread, my fault, first time in this forum, won't do it again...) >>> > >>> > -------------------- >>> > >>> > The features and the samples you are looking for exist and are >>> available >>> > through tutorials: >>> > >>> > >>> http://granitedataservices.com/blog/2012/11/26/real-time-messaging-tutorial-with-javafx-2-2/ >>> > >>> > >>> http://granitedataservices.com/blog/2012/11/26/data-management-tutorial-with-javafx-2-2/ >>> > >>> > We don't have any other material right now (such as videos or a test >>> > drive), but we did our best to make things as clear and easy as >>> possible. >>> > >>> > And yes, if you open each application described in those tutorials >>> twice, >>> > your changes in one of them will be reflected in the other one "in real >>> > time". >>> > -------------------- >>> > >>> > More on the subject: Richard has tried to run the 2nd tutorial on a Mac >>> > (Mountain Lion, java 1.7.0_09 64 bits) and it's causing some ugly >>> random >>> > crashes of the JVM: >>> > >>> > # >>> > # A fatal error has been detected by the Java Runtime Environment: >>> > # >>> > # SIGSEGV (0xb) at pc=0x00007fff900dc250, pid=366, tid=9991 >>> > # >>> > # JRE version: 7.0_09-b05 >>> > # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.5-b02 mixed mode >>> bsd-amd64 >>> > compressed oops) >>> > # Problematic frame: >>> > # C [libobjc.A.dylib+0x6250] objc_msgSend+0x10 >>> > # >>> > # Failed to write core dump. Core dumps have been disabled. To enable >>> core >>> > dumping, try "ulimit -c unlimited" before starting Java again >>> > # >>> > # An error report file with more information is saved as: >>> > # >>> /Users/franckwolff/shop-admin/shop-admin-javafx/javafx/hs_err_pid366.log >>> > # >>> > # If you would like to submit a bug report, please visit: >>> > # http://bugreport.sun.com/bugreport/crash.jsp >>> > # The crash happened outside the Java Virtual Machine in native code. >>> > # See problematic frame for where to report the bug. >>> > # >>> > Abort trap: 6 >>> > >>> > I have been able to reproduce the issue (same environment) and I really >>> > don't know what to do with this error ("outside the Java Virtual >>> Machine in >>> > native code")... >>> > >>> > You shouldn't experience this problem on Windows, and hopefully on >>> Linux. >>> > >>> > Franck. >>> > >>> > 2012/11/29 Richard Bair >>> > >>> >> Cool! Are there any online samples? BlazeDS I remember had some great >>> >> sample pages or videos (I don't remember which) that showed things >>> such as >>> >> two browser windows open, writing in one and auto-updating the UI in >>> the >>> >> other, etc. I'm wondering if graniteds has anything of that kind? >>> >> >>> >> Thanks >>> >> Richard >>> >> >>> >> On Nov 29, 2012, at 8:21 AM, Franck Wolff >> > >>> >> wrote: >>> >> >>> >>> Hi all, >>> >>> >>> >>> We have long been providing a solution to Flex developers, and have >>> >>> recently released a version of our product that supports JavaFX 2.2: >>> >> Granite >>> >>> Data Services (GraniteDS) is a >>> comprehensive >>> >>> development and integration solution for building Flex (and now >>> JavaFX) / >>> >>> JavaEE RIA applications. The entire framework is open-source and >>> released >>> >>> under the LGPL v2 license. >>> >>> >>> >>> To know more about what GraniteDS provides to JavaFX developers, see >>> a >>> >>> comprehensive documentation >>> >>> here< >>> >> >>> http://www.graniteds.org/public/docs/3.0.0/docs/reference/java/en-US/html/index.html >>> >>> >>> >>> . >>> >>> >>> >>> The full announcement about this new 3.0.0.M1 version is available >>> >>> here< >>> >> >>> http://granitedataservices.com/blog/2012/11/26/granite-data-services-3-0-0-m1-is-out/ >>> >>> , >>> >>> together with several links to tutorials and resources. This first >>> public >>> >>> release of a GraniteDS for JavaFX is clearly in a beta stage at this >>> >> time, >>> >>> but with the help of your feedback, we hope to be able to provide new >>> >>> milestones and a stable 3.0.0.GA within the coming months. >>> >>> >>> >>> Here are some additional links: >>> >>> >>> >>> >>> >>> - Community Site: http://www.graniteds.org/ >>> >>> - Blog: http://granitedataservices.com/blog/ >>> >>> - Forum: >>> https://groups.google.com/forum/?fromgroups#!forum/graniteds >>> >>> - Bug Tracking System (Jira): >>> >>> >>> >> >>> http://www.graniteds.org/jira/browse/GDS?report=com.atlassian.jira.plugin.system.project:roadmap-panel >>> >>> - Nightly Builds (Bamboo): >>> >>> http://www.graniteds.org/bamboo/allPlans.action >>> >>> - Source Repository: https://github.com/graniteds >>> >>> - Maven Repository: http://repo2.maven.org/maven2/org/graniteds/ >>> >>> >>> >>> Your feedback will be greatly appreciated, >>> >>> >>> >>> Franck Wolff >>> >> >>> >> >>> >> From zonski at gmail.com Mon Dec 3 13:31:41 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Tue, 4 Dec 2012 08:31:41 +1100 Subject: Granite Data Services 3.0.0.M1 introduces JavaFX 2.2 support In-Reply-To: References: <96044219-3E2C-4B59-B1BB-AB1872E4592E@oracle.com> Message-ID: <09B96BBF-0994-40C6-A896-658C9AFB6D8F@gmail.com> Reliable "core" features I'm all for. It's more a question of whether things like charts, 3d, node orientation, etc are higher priority than simple distribution to users. Subjective of course and you will get arguments both ways - best not to get me going on this topic :) The jfx:run option is just a quick convenience as a starting point for developers. In that same project, if you run jfx:build-jar it will build an executable jar for you that you can send around. If you run jfx:build-webstart it will build a webstart bundle you can upload to your server. If you run jfx:build-native it will create a native installer for you (eg MSI on windows) - though this last option still needs work. Basically it provides a project that is instantly all setup and ready to go so a developer (especially one new to jfx) doesn't have to wade through all the setup steps of the ANT tasks. The Maven philosophy of minimal config. If you open the Pom file in an IDE you will also have a working project with the classpath setup etc. Takes about 5 minutes for a developer to go from nothing to having a working project with WAR distribution and JFX client distribution. Enjoy, Dan On 04/12/2012, at 8:14 AM, Franck Wolff wrote: > Daniel, > > We do use Maven in one of our tutorials: http://granitedataservices.com/blog/2012/11/26/data-management-tutorial-with-javafx-2-2/ > > The only difference with your REST client-server setup is the way we are starting the JavaFX client application (ie. "java -jar ..." instead of "mvn jfx:run"). Using jfx:run could be an improvement. > > The best, of course, would be a reliable WebStart solution with an easy one-click startup (we have been used to this kind of instant/no install demos with Flex). But while I agree with you about the importance of this feature, I definitely prefer to see the JavaFX team working on the core features first: a not-so-friendly (or even tedious) startup process of a very good and stable framework is much better than the opposite ;) > > Franck. > > 2012/12/3 Daniel Zwolenski > Sorry Frank, I was being cheeky. That comment was aimed more at the JavaFX team and was about giving the users a way to easily run your demos, i.e. wouldn't it be cool if you could just send out a URL and a couple of simple, user friendly clicks later your users are running your demo and can see it in action? This issue of deployment is a bit of an on going crusade of mine and the JavaFX guys don't rank it nearly as highly as I do in the priority list so I couldn't resist a chance to highlight a situation where a good deployment option would help win people over to JFX. > > Regarding your "test drive" for developers a good way to do this might be a Maven archetype - basically a way of creating quick "template" projects (not sure if you guys use Maven for your stuff at all?). I have written a Maven plugin for JavaFX (https://github.com/zonski/javafx-maven-plugin) and also added a simple Maven archetype for a quick starter client-only JFX project (see: http://www.zenjava.com/2012/11/24/from-zero-to-javafx-in-5-minutes/). > > Last night I also finished a kickstarter archetype for doing a simple REST client-server setup (based on SpringMVC for the server, and JavaFX plus Spring REST templates for the client). It's here: > > https://github.com/zonski/javafx-rest-archetype > > We have to wait until Sunday for it to get synched to the main Maven repo at which point I'll write a blog post on how to use it. If you want to have a look before then you can check out a sample generated project at: http://code.google.com/p/zenjava-playtime/source/browse/trunk/javafx-simple-rest-app/ > > Something like this for your Granite project could well reduce the barrier to entry, giving developers a way to be up and running with a client-server skeleton project in just 5 minutes or so. > > I intend to add a spring-remoting client-server using HttpInvoker archetype (much better than REST but REST was a good starting point from a marketing angle because web is so popular) that also includes Spring Security and Spring Data (hopefully by xmas or early Jan). Your project is not a bad option for the space I am targeting so if you guys wanted to work together on getting an example skeleton app converted into a Maven archetype I be willing to explore that. Probably best to email me directly. > > Cheers, > Dan > > > > > > On Tue, Dec 4, 2012 at 3:44 AM, Franck Wolff wrote: > Daniel, > > Thanks for your feedback. We will definitely provide a "test drive" in the next 3.0.0.M2 release, hopefully by the end of the year. It should be based on a Jetty or Tomcat server (Tomcat can be more complicated because of native APR libraries), packaged together with few binary sample applications and their sources. Testing the release would then be only a matter of downloading the so-called "test drive", starting it and then running the JavaFX applications (java -jar ... or double-click). > > Is it roughly what you are looking for when saying "if users could run them with a couple of clicks"? > > Franck. > > > 2012/11/30 Daniel Zwolenski > Websockets are a powerful emerging option. Nice use of them in this project and nice fallback onto polling given the newness of Websockets. > > Imagine how much more powerful those demos would be if users could run them with a couple of clicks - sorry, couldn't resist. > > > On 01/12/2012, at 1:01 AM, Franck Wolff wrote: > > > (sorry for the double post, I first replied to Richard without the forum in > > copy and then tried today to forward my answer, which is not in the same > > thread, my fault, first time in this forum, won't do it again...) > > > > -------------------- > > > > The features and the samples you are looking for exist and are available > > through tutorials: > > > > http://granitedataservices.com/blog/2012/11/26/real-time-messaging-tutorial-with-javafx-2-2/ > > > > http://granitedataservices.com/blog/2012/11/26/data-management-tutorial-with-javafx-2-2/ > > > > We don't have any other material right now (such as videos or a test > > drive), but we did our best to make things as clear and easy as possible. > > > > And yes, if you open each application described in those tutorials twice, > > your changes in one of them will be reflected in the other one "in real > > time". > > -------------------- > > > > More on the subject: Richard has tried to run the 2nd tutorial on a Mac > > (Mountain Lion, java 1.7.0_09 64 bits) and it's causing some ugly random > > crashes of the JVM: > > > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # SIGSEGV (0xb) at pc=0x00007fff900dc250, pid=366, tid=9991 > > # > > # JRE version: 7.0_09-b05 > > # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.5-b02 mixed mode bsd-amd64 > > compressed oops) > > # Problematic frame: > > # C [libobjc.A.dylib+0x6250] objc_msgSend+0x10 > > # > > # Failed to write core dump. Core dumps have been disabled. To enable core > > dumping, try "ulimit -c unlimited" before starting Java again > > # > > # An error report file with more information is saved as: > > # /Users/franckwolff/shop-admin/shop-admin-javafx/javafx/hs_err_pid366.log > > # > > # If you would like to submit a bug report, please visit: > > # http://bugreport.sun.com/bugreport/crash.jsp > > # The crash happened outside the Java Virtual Machine in native code. > > # See problematic frame for where to report the bug. > > # > > Abort trap: 6 > > > > I have been able to reproduce the issue (same environment) and I really > > don't know what to do with this error ("outside the Java Virtual Machine in > > native code")... > > > > You shouldn't experience this problem on Windows, and hopefully on Linux. > > > > Franck. > > > > 2012/11/29 Richard Bair > > > >> Cool! Are there any online samples? BlazeDS I remember had some great > >> sample pages or videos (I don't remember which) that showed things such as > >> two browser windows open, writing in one and auto-updating the UI in the > >> other, etc. I'm wondering if graniteds has anything of that kind? > >> > >> Thanks > >> Richard > >> > >> On Nov 29, 2012, at 8:21 AM, Franck Wolff > >> wrote: > >> > >>> Hi all, > >>> > >>> We have long been providing a solution to Flex developers, and have > >>> recently released a version of our product that supports JavaFX 2.2: > >> Granite > >>> Data Services (GraniteDS) is a comprehensive > >>> development and integration solution for building Flex (and now JavaFX) / > >>> JavaEE RIA applications. The entire framework is open-source and released > >>> under the LGPL v2 license. > >>> > >>> To know more about what GraniteDS provides to JavaFX developers, see a > >>> comprehensive documentation > >>> here< > >> http://www.graniteds.org/public/docs/3.0.0/docs/reference/java/en-US/html/index.html > >>> > >>> . > >>> > >>> The full announcement about this new 3.0.0.M1 version is available > >>> here< > >> http://granitedataservices.com/blog/2012/11/26/granite-data-services-3-0-0-m1-is-out/ > >>> , > >>> together with several links to tutorials and resources. This first public > >>> release of a GraniteDS for JavaFX is clearly in a beta stage at this > >> time, > >>> but with the help of your feedback, we hope to be able to provide new > >>> milestones and a stable 3.0.0.GA within the coming months. > >>> > >>> Here are some additional links: > >>> > >>> > >>> - Community Site: http://www.graniteds.org/ > >>> - Blog: http://granitedataservices.com/blog/ > >>> - Forum: https://groups.google.com/forum/?fromgroups#!forum/graniteds > >>> - Bug Tracking System (Jira): > >>> > >> http://www.graniteds.org/jira/browse/GDS?report=com.atlassian.jira.plugin.system.project:roadmap-panel > >>> - Nightly Builds (Bamboo): > >>> http://www.graniteds.org/bamboo/allPlans.action > >>> - Source Repository: https://github.com/graniteds > >>> - Maven Repository: http://repo2.maven.org/maven2/org/graniteds/ > >>> > >>> Your feedback will be greatly appreciated, > >>> > >>> Franck Wolff > >> > >> From hang.vo at oracle.com Mon Dec 3 13:32:53 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 03 Dec 2012 21:32:53 +0000 Subject: hg: openjfx/8/controls/rt: fix RT-26413 Menu blinks when cursor is moved from menu to menuBar. Message-ID: <20121203213300.61AC947D05@hg.openjdk.java.net> Changeset: 1ae5f7425065 Author: Paru Somashekar Date: 2012-12-03 13:31 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1ae5f7425065 fix RT-26413 Menu blinks when cursor is moved from menu to menuBar. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java From richard.bair at oracle.com Mon Dec 3 14:43:21 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 3 Dec 2012 14:43:21 -0800 Subject: JavaFX 2 fully open sourced? In-Reply-To: <503EF77D-6492-4209-99AF-1D41BCC82B91@ultramixer.com> References: <503EF77D-6492-4209-99AF-1D41BCC82B91@ultramixer.com> Message-ID: There are a number of additional projects that are going to go out in a couple weeks. I know some portions of Glass & Prism won't be open sourced until Feb next year, but other portions may be open sourced sooner. I'm trying to get concrete dates from the managers of the various teams. Richard On Dec 3, 2012, at 1:36 AM, Tobias Bley wrote: > Hi guys from Oracle, > > could you tell something about the roadmap for open sourcing JavaFX2? Especially the prism/glass layer? > > Best regards, > Tobi > From danno.ferrin at shemnon.com Mon Dec 3 14:50:52 2012 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Mon, 3 Dec 2012 15:50:52 -0700 Subject: TextFlow and Min vs. Pref size In-Reply-To: References: Message-ID: Perhaps the approach FlowPane takes should be done. The contentBias for the text node depends on the principal character set, horizontal for western/european fonts and vertical for eastern/asian fonts (gross overgeneralization). Whether this is autodetected or set as a property is up for discussion. Mixed layouts cause a problem. Then the minWidth/Height depends on the bias. For western fonts calculateMinHeight returns calculatePrefHeight, vice versa for vertical fonts. A Bias of null has the current behavior. The other dimension's calculation does the same thing it does currently. This is what I do to workaround in my toy app. I make a custom VBox that returns the pref height for the minHeight. On Mon, Dec 3, 2012 at 11:13 AM, Felipe Heidrich wrote: > Hi, > > > It was not an oversight but not something I play around all that much. > > The behavior is described in the javadoc: > preferred size is ideal size where no line needs to wrap. > minimal size is the for padding, nothing more. When the width is between > min size and pref size lines will wrap. > maximum size is unbounded. > > I think the problem was I couldn't define minimal size any another way ? > What else could it be, lines just wrap "a little bit" ? > > In my tests when I made minimal equals to preferred what happened was that > I could not longer resize the parent container so that lines would wrap. > > I'm out of town this week but I'll do my best to try your snippet, please > feel free to file a jira if you preferred. I'm more than glad helping out > or even modifying the behavior. > > Regards, > Felipe > > > On Dec 2, 2012, at 9:20 PM, Danno Ferrin wrote: > > > I was playing with the TextFlow bits in the JDK8 ea and was wondering > about > > the handling of min vs pref sizing. The TextFlow can return some very > > small min sizes which are much smaller than the contained text elements. > > For example, I have a text with min/pref/max all of 269.85 x 30.62 while > > the min/pref/max of the parent TextFlow (which contains just the text > node) > > of 0.0 x 17.2 / 269.85 x 48.62 / maxValuexmaxValue. This is problematic > > when place in a scroll pane, as all the text flows tend to bunch up on > each > > other. > > > > Is this a design intent or an oversight? > > > > For a workaround I've wrapped then TextFlows in panes that report > minHeight > > as PrefHeight, so I don't see the bunching in scrollpane problem. > > > > For an interactive example of this behavior I have a toy app at > bitbucket: > > https://bitbucket.org/shemnon/flowdown > > -- There is nothing that will hold me back. I know who I am.... I remember wher I came from, and I feel stronger for knowing. Zane, Ninja of Ice. Ninjago S01E07 From hang.vo at oracle.com Mon Dec 3 21:18:16 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 04 Dec 2012 05:18:16 +0000 Subject: hg: openjfx/8/controls/rt: 4 new changesets Message-ID: <20121204051824.C8FB247D4D@hg.openjdk.java.net> Changeset: 3e8a2f562097 Author: jgiles Date: 2012-12-04 12:05 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3e8a2f562097 Partial implementation of RT-21597: 'Move SkinBase into public API'. Namely, removing all references of BehaviorBase from SkinBase, as SkinBase will be public API in 8.0, but BehaviorBase will remain private API for now. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/AccordionSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/BehaviorSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ChoiceBoxSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxBaseSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuButtonSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SeparatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SliderSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SplitPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualContainerBase.java ! javafx-ui-controls/src/javafx/scene/control/SkinBase.java Changeset: 06a8b0af9d46 Author: jgiles Date: 2012-12-04 12:19 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/06a8b0af9d46 RT-21597: 'Move SkinBase into public API': Calling super.dispose(). ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/BehaviorSkinBase.java Changeset: c8452a11548d Author: jgiles Date: 2012-12-04 18:10 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c8452a11548d Updating unit tests related to SkinBase / BehaviorSkinBase + javafx-ui-controls/test/com/sun/javafx/scene/control/skin/BehaviorSkinBaseTest.java ! javafx-ui-controls/test/javafx/scene/control/SkinBaseTest.java Changeset: e17bfdb2019b Author: jgiles Date: 2012-12-04 18:10 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e17bfdb2019b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java From hang.vo at oracle.com Mon Dec 3 21:47:32 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 04 Dec 2012 05:47:32 +0000 Subject: hg: openjfx/8/controls/rt: add AccessibleMenuButton Message-ID: <20121204054733.AD6E747D56@hg.openjdk.java.net> Changeset: fefcbba9f15c Author: Paru Somashekar Date: 2012-12-03 21:42 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fefcbba9f15c add AccessibleMenuButton ! javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleButton.java + javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleMenuButton.java From hang.vo at oracle.com Tue Dec 4 01:17:35 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 04 Dec 2012 09:17:35 +0000 Subject: hg: openjfx/8/graphics/rt: Fix no runnable method errors in tests. Disable test RT-23413 Message-ID: <20121204091738.71D9F47D5E@hg.openjdk.java.net> Changeset: 501088150d56 Author: tb115823 Date: 2012-12-04 10:01 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/501088150d56 Fix no runnable method errors in tests. Disable test RT-23413 + javafx-fxml/test/javafx/fxml/RT_21559.java - javafx-fxml/test/javafx/fxml/RT_21559Test.java + javafx-fxml/test/javafx/fxml/RT_22864.java - javafx-fxml/test/javafx/fxml/RT_22864Test.java + javafx-fxml/test/javafx/fxml/RT_23244.java - javafx-fxml/test/javafx/fxml/RT_23244Test.java ! javafx-fxml/test/javafx/fxml/RT_23413Test.java From felipe.heidrich at oracle.com Tue Dec 4 05:57:57 2012 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Tue, 4 Dec 2012 05:57:57 -0800 Subject: TextFlow and Min vs. Pref size In-Reply-To: References: Message-ID: <057F4B84-B854-4007-92BD-FE4C2DD437FA@oracle.com> In the FlowPane the children are Nodes that can have well defined min and pref width. So the wrapping algorithm can run asking the children for their min width when the min width of the FlowPane is requested, and asking the children's pref width when the FlowPane's pref width is requested. The TextFlow, on the other hand, the content is text, where the width is the sum of the advance width of the glyphs. It doesn't have the notion of min width and pref width. Not sure how the same approach could be used. Currently TextFlow doesn't not support vertical text, so the content bias is always horizontal, height depends on the width. Felipe On Dec 3, 2012, at 2:50 PM, Danno Ferrin wrote: > Perhaps the approach FlowPane takes should be done. > > The contentBias for the text node depends on the principal character set, horizontal for western/european fonts and vertical for eastern/asian fonts (gross overgeneralization). Whether this is autodetected or set as a property is up for discussion. Mixed layouts cause a problem. > > Then the minWidth/Height depends on the bias. For western fonts calculateMinHeight returns calculatePrefHeight, vice versa for vertical fonts. A Bias of null has the current behavior. The other dimension's calculation does the same thing it does currently. > > This is what I do to workaround in my toy app. I make a custom VBox that returns the pref height for the minHeight. > > On Mon, Dec 3, 2012 at 11:13 AM, Felipe Heidrich wrote: > Hi, > > > It was not an oversight but not something I play around all that much. > > The behavior is described in the javadoc: > preferred size is ideal size where no line needs to wrap. > minimal size is the for padding, nothing more. When the width is between min size and pref size lines will wrap. > maximum size is unbounded. > > I think the problem was I couldn't define minimal size any another way ? What else could it be, lines just wrap "a little bit" ? > > In my tests when I made minimal equals to preferred what happened was that I could not longer resize the parent container so that lines would wrap. > > I'm out of town this week but I'll do my best to try your snippet, please feel free to file a jira if you preferred. I'm more than glad helping out or even modifying the behavior. > > Regards, > Felipe > > > On Dec 2, 2012, at 9:20 PM, Danno Ferrin wrote: > > > I was playing with the TextFlow bits in the JDK8 ea and was wondering about > > the handling of min vs pref sizing. The TextFlow can return some very > > small min sizes which are much smaller than the contained text elements. > > For example, I have a text with min/pref/max all of 269.85 x 30.62 while > > the min/pref/max of the parent TextFlow (which contains just the text node) > > of 0.0 x 17.2 / 269.85 x 48.62 / maxValuexmaxValue. This is problematic > > when place in a scroll pane, as all the text flows tend to bunch up on each > > other. > > > > Is this a design intent or an oversight? > > > > For a workaround I've wrapped then TextFlows in panes that report minHeight > > as PrefHeight, so I don't see the bunching in scrollpane problem. > > > > For an interactive example of this behavior I have a toy app at bitbucket: > > https://bitbucket.org/shemnon/flowdown > > > > > -- > There is nothing that will hold me back. I know who I am.... > I remember wher I came from, and I feel stronger for knowing. > Zane, Ninja of Ice. Ninjago S01E07 > From hang.vo at oracle.com Tue Dec 4 07:17:34 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 04 Dec 2012 15:17:34 +0000 Subject: hg: openjfx/8/graphics/rt: fix fxml test RT-23413. Added warmup before actual performance comparison Message-ID: <20121204151740.DCD8447D82@hg.openjdk.java.net> Changeset: fbce04284f89 Author: tb115823 Date: 2012-12-04 16:04 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fbce04284f89 fix fxml test RT-23413. Added warmup before actual performance comparison ! javafx-fxml/test/javafx/fxml/RT_23413Test.java From richard.bair at oracle.com Tue Dec 4 08:23:45 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 4 Dec 2012 08:23:45 -0800 Subject: TextField Document model In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> <50836C4C.6050407@oracle.com> <50854843.3000602@oracle.com> <7393107B-49B2-4E80-A94B-CB995EAADE27@oracle.com> <94AAF79B-01B5-442C-9270-D9705DB6454D@oracle.com> Message-ID: <28959B7C-18E3-444E-91CF-BEF3F2ED652D@oracle.com> Hi Mark, Sorry for being slow -- you will at least be glad to know you are in such auspicious company as Jonathan Giles, who has to regularly bribe (or threaten) me to get timely responses :-) On first read, this seems very nice. The Filter interface is a single-abstract-method interface, so it will play perfectly well with Lambda's. It can be reused among multiple controls and types of text input controls which seems ideal. It seems to plug into the pipeline quite naturally. One question is, should the filter start off as null and have an additional filter (newlines and such) always applied, or should it start out as non-null where the built in filter handles newlines (and such) and new filters also will have to either wrap the existing filter or add support for newlines (and such!) or not as necessary? The safest thing for an implementor would be to delegate in case we change the built-in behavior. The next step would be to create a diff and attach it to the JIRA issue (and make sure you have signed the Oracle Contributor Agreement (OCA)). I think we can then integrate the patch and start the discussion around formatted text field. Jonathan, what do you think? Have you had a chance to review? Thanks Richard On Nov 26, 2012, at 7:44 PM, Mark Claassen wrote: > I sent a potential API change to Richard Bair a few weeks ago. He has not > responded to me, which makes me think it was too complicated at this point > and wasn't going to fly. I think for a good InputMaskField, the Content > and the eventual caret position and selection needs to be controlled by the > "model". This makes the solution a bit complex. > > However, for filtering, this is not the case. Doing both of these in one > shot is, perhaps, a mistake. Here is another idea which takes care of the > easy cases...easily. A more complex InputMask control I will save for > later. > > So, here is the simplified idea: Add the ability to "filter". And by > filter, I mean the ability to modify the input and only the input: > > Add the following sub-interface to the Content interface. No methods are > added to the Content interface. > interface Filter { > String filter(int index, String text, String currentContent); > } > > Add the following to TextFieldContent and TextAreaContent: > private Content.Filter filter; > public void setContentFilter(Content.Filter filter) { > this.filter = filter; > } > > Change the "insert" method of TextFieldContent and TextAreaContent to start > with: > @Override public void insert(int index, String text, boolean > notifyListeners) { > text = TextInputControl.filterInput(text, [boolean], [boolean]); > if (filter != null) > text = filter.filter(index, text, get()); > > Add a method in TextField: > public void setContentFilter(Content.Filter filter) { > ((TextFieldContent)getContent()).setContentFilter(filter); > } > > Add a method in TextArea: > public void setContentFilter(Content.Filter filter) { > ((TextAreaContent)getContent()).setContentFilter(filter); > } > > This would do a few things: > 1) Use the current "TextInputControl.filterInput" mechanisms of TextField > and TextArea (like to strip out special chars and newlines). > 2) By specifying the Filter interface outside of TextField and TextArea, it > allows the same filter to be used for TextField and TextArea > 3) Makes it simple to do things like translate all input to upper case or > limit the overall length > 4) By not adding a method to Content directly, something like the > InputMaskContent would not be forced to deal with the Filter interface at > all. > > This implementation would allow someone creating a filter to "filter" the > text to have illegal characters. I thought it was more validate this > first, so that the implementer would only have to deal with proper input. > However, TextInputControl.filterInput could be done both before and after > the Filter.filter() call. > text = TextInputControl.filterInput(text, [boolean], [boolean]); > if (filter != null) { > text = filter.filter(index, text, get()); > text = TextInputControl.filterInput(text, [boolean], > [boolean]); > } > > Another possible addition to this may be to allow the filter to return > null, signifying an error input and causing the system to "beep". > > Thanks for your consideration, > Mark From richard.bair at oracle.com Tue Dec 4 08:32:29 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 4 Dec 2012 08:32:29 -0800 Subject: TextField Document model In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> <50836C4C.6050407@oracle.com> <50854843.3000602@oracle.com> <7393107B-49B2-4E80-A94B-CB995EAADE27@oracle.com> <94AAF79B-01B5-442C-9270-D9705DB6454D@oracle.com> Message-ID: <07160623-FA62-4FAE-AA49-53C8292788FD@oracle.com> It has been a long time since I last worked in TextInputControl, so I am familiarizing myself with it again. Earlier it was asked whether getContent() could be made public, along with a setContent etc. One other problem I think we'd see if we did this, is that it is possible to get the caret out of sync with the text. That is, if you call getContent().delete(0, 20, true), for example, and the caret was at index 15 (say), then the caret would remain out of range. This is because the content does not call back into the text input control to readjust the caret -- rather, each of the methods on TextInputControl that manipulates the text also repositions the caret as required. Just something to be aware of, when it comes to making Content public. The present design is around Content being an implementation detail of a specific control (although it is protected so that any custom text-input-based control can customize the content). What this means in the context of the larger question of "how do we handle a formatted text field", is that if we decide to make Content public, then we will need to either document this or rewrite the code so that any change to content automatically repositions the caret correctly. I'm not sure whether this is feasible, as text has a bazillion corner cases and we'd have to first analyze each of these and see if it works. I see there are a number of other things that would be impacted as well. For example, the getText(start, end) method of TextInputControl does range validation, and if Content were meant to be used by developers (rather than control authors) then we would have to move those checks into Content. Another potential issue here is that the Content interface defines a delete and an insert method, and is observable. So when we replace text, there are actually two change notifications which are going to happen -- a delete followed by an insert (and I believe this bleeds out through the interface, such that if you have a listener or binding on the "text" property of a TextInputControl, you will get two notifications). This is unfortunate, it would have been better to get a single notification (much like the ObservableList manages). However, because Content is an interface (!!) we cannot now add a replace method to it. Well, at least yet. In Java 8 maybe we can, which would be nice. Richard From richard.bair at oracle.com Tue Dec 4 09:15:48 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 4 Dec 2012 09:15:48 -0800 Subject: TextField Document model In-Reply-To: References: <507ef547.41c5ec0a.2e1f.7e39@mx.google.com> <71937D8F-E326-455D-9E24-669F4D223AFB@oracle.com> <0CFE919A-7CA9-4B24-8527-E42B2B6D7C1E@oracle.com> <50836C4C.6050407@oracle.com> <50854843.3000602@oracle.com> <7393107B-49B2-4E80-A94B-CB995EAADE27@oracle.com> <94AAF79B-01B5-442C-9270-D9705DB6454D@oracle.com> Message-ID: <71699B91-D6A8-4BB8-BB31-26201104ABB1@oracle.com> Hi Mark, Sorry for being slow -- you will at least be glad to know you are in such auspicious company as Jonathan Giles, who has to regularly bribe (or threaten) me to get timely responses :-) On first read, this seems very nice. The Filter interface is a single-abstract-method interface, so it will play perfectly well with Lambda's. It can be reused among multiple controls and types of text input controls which seems ideal. It seems to plug into the pipeline quite naturally. One question is, should the filter start off as null and have an additional filter (newlines and such) always applied, or should it start out as non-null where the built in filter handles newlines (and such) and new filters also will have to either wrap the existing filter or add support for newlines (and such!) or not as necessary? The safest thing for an implementor would be to delegate in case we change the built-in behavior. The next step would be to create a diff and attach it to the JIRA issue (and make sure you have signed the Oracle Contributor Agreement (OCA)). I think we can then integrate the patch and start the discussion around formatted text field. Jonathan, what do you think? Have you had a chance to review? Thanks Richard On Nov 26, 2012, at 7:44 PM, Mark Claassen wrote: > I sent a potential API change to Richard Bair a few weeks ago. He has not > responded to me, which makes me think it was too complicated at this point > and wasn't going to fly. I think for a good InputMaskField, the Content > and the eventual caret position and selection needs to be controlled by the > "model". This makes the solution a bit complex. > > However, for filtering, this is not the case. Doing both of these in one > shot is, perhaps, a mistake. Here is another idea which takes care of the > easy cases...easily. A more complex InputMask control I will save for > later. > > So, here is the simplified idea: Add the ability to "filter". And by > filter, I mean the ability to modify the input and only the input: > > Add the following sub-interface to the Content interface. No methods are > added to the Content interface. > interface Filter { > String filter(int index, String text, String currentContent); > } > > Add the following to TextFieldContent and TextAreaContent: > private Content.Filter filter; > public void setContentFilter(Content.Filter filter) { > this.filter = filter; > } > > Change the "insert" method of TextFieldContent and TextAreaContent to start > with: > @Override public void insert(int index, String text, boolean > notifyListeners) { > text = TextInputControl.filterInput(text, [boolean], [boolean]); > if (filter != null) > text = filter.filter(index, text, get()); > > Add a method in TextField: > public void setContentFilter(Content.Filter filter) { > ((TextFieldContent)getContent()).setContentFilter(filter); > } > > Add a method in TextArea: > public void setContentFilter(Content.Filter filter) { > ((TextAreaContent)getContent()).setContentFilter(filter); > } > > This would do a few things: > 1) Use the current "TextInputControl.filterInput" mechanisms of TextField > and TextArea (like to strip out special chars and newlines). > 2) By specifying the Filter interface outside of TextField and TextArea, it > allows the same filter to be used for TextField and TextArea > 3) Makes it simple to do things like translate all input to upper case or > limit the overall length > 4) By not adding a method to Content directly, something like the > InputMaskContent would not be forced to deal with the Filter interface at > all. > > This implementation would allow someone creating a filter to "filter" the > text to have illegal characters. I thought it was more validate this > first, so that the implementer would only have to deal with proper input. > However, TextInputControl.filterInput could be done both before and after > the Filter.filter() call. > text = TextInputControl.filterInput(text, [boolean], [boolean]); > if (filter != null) { > text = filter.filter(index, text, get()); > text = TextInputControl.filterInput(text, [boolean], > [boolean]); > } > > Another possible addition to this may be to allow the filter to return > null, signifying an error input and causing the system to "beep". > > Thanks for your consideration, > Mark From hang.vo at oracle.com Tue Dec 4 09:47:33 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 04 Dec 2012 17:47:33 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121204174740.D7F2047D95@hg.openjdk.java.net> Changeset: 12cce04e7847 Author: hudson Date: 2012-11-29 22:12 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/12cce04e7847 Added tag 8.0-b66 ! .hgtags Changeset: 9353d8ea7c4b Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-12-04 09:37 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9353d8ea7c4b Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-fxml/test/javafx/fxml/RT_14880.java - javafx-fxml/test/javafx/fxml/RT_15524.java - javafx-fxml/test/javafx/fxml/RT_16722.java - javafx-fxml/test/javafx/fxml/RT_16724.java - javafx-fxml/test/javafx/fxml/RT_16815.java - javafx-fxml/test/javafx/fxml/RT_16977.java - javafx-fxml/test/javafx/fxml/RT_17646.java - javafx-fxml/test/javafx/fxml/RT_17714.java - javafx-fxml/test/javafx/fxml/RT_18046.java - javafx-fxml/test/javafx/fxml/RT_18218.java - javafx-fxml/test/javafx/fxml/RT_18680.java - javafx-fxml/test/javafx/fxml/RT_18933.java - javafx-fxml/test/javafx/fxml/RT_19008.java - javafx-fxml/test/javafx/fxml/RT_19112.java - javafx-fxml/test/javafx/fxml/RT_19139.java - javafx-fxml/test/javafx/fxml/RT_19228.java - javafx-fxml/test/javafx/fxml/RT_19329.java - javafx-fxml/test/javafx/fxml/RT_19870.java - javafx-fxml/test/javafx/fxml/RT_20082.java - javafx-fxml/test/javafx/fxml/RT_20471.java ! javafx-fxml/test/javafx/fxml/RT_21559.java ! javafx-fxml/test/javafx/fxml/RT_22864.java - javafx-fxml/test/javafx/fxml/RT_22971.java ! javafx-fxml/test/javafx/fxml/RT_23244.java - javafx-fxml/test/javafx/fxml/RT_23413.java - javafx-fxml/test/javafx/fxml/RT_24380.java From richard.bair at oracle.com Tue Dec 4 11:57:01 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 4 Dec 2012 11:57:01 -0800 Subject: Layouts with constraint classes In-Reply-To: <2D86AE01-DDF5-4CF7-AF47-34BA4C1CFD48@gmail.com> References: <4FFEDD3B.6030109@oracle.com> <50B7588E.6060101@bestsolution.at> <40F23285-1E86-4EDF-90C2-052C7276AA7A@oracle.com> <50B7A38D.60608@bestsolution.at> <36CB524E-19D1-45E8-B1A0-5C348470F6EA@oracle.com> <50B7B9BF.6010008@bestsolution.at> <50B7BDDB.6040001@tbee.org> <50B7CA88.7000408@bestsolution.at> <3D87565A-1A5F-4DCB-AA6E-3FAF6445A7B2@gmail.com> <50B7D34F.8090904@tbee.org> <50B867F8.2060609@tbee.org> <50B86A97.4010500@bestsolution.at> <50B86DD5.7040603@tbee.org> <50B87AF8.3050200@tbee.org> <50B88858.4080500@tbee.org> <50B9AF27.6040903@tbee.org> <50B9B5FD.5020501@tbee.org> <50B9F0D9.6090608@bestsolu! ! ! tion.at> <50BA53D4.7090504@tbee.org> <58D54348-32FF-4895-87BF-95C423011303@oracle.com> <2D86AE01-DDF5-4CF7-AF47-34BA4C1CFD48@gmail.com> Message-ID: <63F96E27-357C-45F3-A7A3-8C98E1F5CC37@oracle.com> On Dec 1, 2012, at 7:06 PM, Daniel Zwolenski wrote: > More or less. I would have liked a really nice type safe Style Java API much like the really nice type safe Node API and Animation API, etc. Then CSS would be more of a higher level way of interacting with it (like FXML is to Nodes). This would allow nicer styling direct in java code eg something like: > > Style myStyle = new ButtonStyleBuilder().border(2).padding(10) > > And querying styles: > > ButtonStyle style = StyleSheet.resolveStyleFor(my button); > style.getBorder().getWidth(); > > Or whatever, you get the gist. It would obviously be a lot more complex than I imply here but I'm tapping on my phone. > > This would also open the door to people building their own non-CSS style languages that map onto the java (eg json) or I could even put my styles in XML along side the FXML files, etc. I have use cases, but the main thing is its easier for developers to get creative when it's in java (as we just saw with Tom's unique FXML use case). > > This is an old conversation though, I've kicked it around many times. I don't think it's something likely to change so maybe not worth burning your time on? I'd rather see that blog post you were talking about on how you got jfx working on android :) Actually we added API to Region in 8 that defines the backgrounds, borders, etc. The goal has always been to have CSS map directly onto public API on nodes, unless I'm not remembering rightly (always possible). I think we're fairly close now to having public API for everything that is settable now. You might have to do: button.lookup("Text").setBackground(foo); or whatnot, in order to set the style on some inner node of the skin of a control (equivalent of using ".button Text" selector in CSS), but all the state that could be set from CSS should be settable in code. Its just that some plans take time to mature, and thankfully too, because our previous private API for this state on the Region was not what we would want longer term (hopefully the new API is!) so it was wiser to skip adding the public API in the 2.0 release and wait until it was ready. When in doubt leave it out! Richard From randahl at rockit.dk Tue Dec 4 12:06:27 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Tue, 4 Dec 2012 21:06:27 +0100 Subject: What contributes to a labels width? Message-ID: <58C25092-DC58-48DE-8F6E-4FE0D8050528@rockit.dk> I am trying to calculate the width of a label before it has been laid out by simulating its width as follows: Text text = new Text(); text.setFont(label.getFont()); text.setText(label.getText()); Bounds bounds = text.getLayoutBounds(); double labelWidth = Math.ceil(bounds.getWidth()); Unfortunately, it seems the label width I am predicting is a little less than the actual width of the label after layout (69 vs. 71). Could anyone enlighten me here ? what else contributes to the width of the label than the font and the text? (or could this be attributed to rounding differences inside label and text?) Thanks Randahl From richard.bair at oracle.com Tue Dec 4 12:24:22 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 4 Dec 2012 12:24:22 -0800 Subject: JavaFX performance for complex visualisations In-Reply-To: <004f01cdc3da$c8fd1b10$5af75130$@com.au> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> Message-ID: <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> Hi John, Just getting through my email and have had this one flagged since Devoxx :-). I respond below to individual points but most of these are probably not worth you responding back on (they're just informational on my part) -- rather, down at the end is the real question I want to have a discussion on (and will be a lot of fun to solve while we're at it). > 1. Do any such games, animations or visualisations exist yet? Yes. Much like Swing, JavaFX is seeing a lot of adoption in the heavy enterprise desktop sorts of use cases -- not the kind of thing you will find when browsing the internet. Most of these folks don't advertise the technology they're using, and most of them are not interested in letting their competitors know what they're doing or what technology they're using. Which basically means, if we haven't built a demo for it, there isn't anything you will find in your travels. > 2. If not, how does Oracle or anyone else actually know that JavaFX is > capable of supporting such applications? That is a good question. Many of the folks I've talked to building such applications have done incredible work + proof of concepts long before I even knew they were using JavaFX. Now, each year we do pretty graphically intense demos for JavaOne, so we have a pretty good feel for it. We have a bunch of benchmarks where we crank the number of nodes up to pretty high numbers, and we know from these benchmarks (at least) that we scale very well compared to other technologies. But I know neither the samples nor the results are publicly available. But at least I can answer the "how does Oracle ? know" part of the question. We have had a performance team from the get-go who were solely dedicated to writing benchmarks, running benchmarks, and analyzing results. This has been incredibly helpful. We have results that come not just from the weekly integrations but even from intra-week builds on specific scrum repositories. We have benchmarks and analysis for both desktop and embedded and take performance very seriously. Now, there are a lot of ways to use the platform. Some things are better tuned than others. Performance work is driven by tuning and benchmarks. So when we run into issues we have to (a) determine how likely that is to be an issue to the broader development community (b) figure out what the tradeoffs are (usually performance & quality are directly in contradiction with each other), and ( c) schedule & implement the fix. Of course, the same few people (Jim, mostly) are involved in many of the performance fixes and features (like Canvas), so scheduling is an issue and feedback from customers as to what they are actually running into (vs. what a theoretical issue is) has priority. > 3. Do I have the wrong understanding that JavaFX is supposed to support such > applications? We expect that JavaFX will be usable for casual games, but we are not building a gaming platform to compete with Unity and the like. If we happen to be just as good, then that's awesome, but it isn't our primary goal. Advanced visualizations, on the other hand, are part of our target market (medical, pharma, enterprise desktop, etc) > 4. Is it possible that, for whatever reason, JavaFX is simply not capable of > supporting such applications? There are natural trade-offs between an immediate mode (like Canvas) API and a retained mode (like Scene Graph) API. Now that we have both (plus Java2D + ImageWriter and such for the really crazy cases) we should be capable of a wide range of use cases. However, some things are not yet optimized. But there is no technical reason why we shouldn't be quite capable. Another area we have not yet exposed API which is problematic for some people is in the area of custom shaders. It may be that without some kind of custom shader support (which would have to be made to work on D3D as well as OpenGL) certain use cases cannot be easily fulfilled. > My feeling that JavaFX can indeed support such applications is based on the > fact that it is hardware accelerated and therefore it should be limited > mostly by the capabilities of the graphics card and also because it is often > talked about in this way. However, I have observed varying levels of > performance that don't quite follow these principles such as JavaFX > performing poorly with choppy/jittery animations and transitions on my most > powerful machine with an NVIDIA GeForce GTX 690 (the current fastest > graphics card in the world) but performing quite well on machines with much > lower specifications. It is highly unlikely that this is due to performance issues. As mentioned in the last few days on another thread, there are smoothness issues that are completely separate from performance (although both are often talked about together). We're working on the smoothness. Sometimes this is an application problem as opposed to a platform problem (one such example is the DisplayShelf sample, which needs to be rewritten). > So I guess I am curious to know what kinds of testing and evaluations Oracle > has undertaken to determine the performance characteristics of JavaFX and > exactly what kinds of applications it is actually suitable for. For > example, I am yet to see any JavaFX application with even the sophistication > of a Flash electronic greeting card or banner ad and yet I assume JavaFX > will be used for such purposes eventually. I would imagine any of our demos from the last 3-4 years of JavaOne would demonstrate much more complicated use cases than that! But, instead of me just complaining -- lets build one! We'll add it both to Ensemble and our test suite. We can start with something simple (like a greeting card) and expand it out to something wildly complex. What would you like to see? One thing I've wanted to build for years but haven't found the time for was a tower defense game. But what would you think would be a good example of graphics performance that would tell you "hey, this platform is great for visualizations"? Richard From phidias51 at gmail.com Tue Dec 4 12:33:04 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Tue, 4 Dec 2012 12:33:04 -0800 Subject: What contributes to a labels width? In-Reply-To: <58C25092-DC58-48DE-8F6E-4FE0D8050528@rockit.dk> References: <58C25092-DC58-48DE-8F6E-4FE0D8050528@rockit.dk> Message-ID: I think the Label has an inset which may account for the difference between the Text width and the Label width. Mark Cheers, Mark On Tue, Dec 4, 2012 at 12:06 PM, Randahl Fink Isaksen wrote: > I am trying to calculate the width of a label before it has been laid out > by simulating its width as follows: > > Text text = new Text(); > text.setFont(label.getFont()); > text.setText(label.getText()); > Bounds bounds = text.getLayoutBounds(); > double labelWidth = Math.ceil(bounds.getWidth()); > > Unfortunately, it seems the label width I am predicting is a little less > than the actual width of the label after layout (69 vs. 71). Could anyone > enlighten me here ? what else contributes to the width of the label than > the font and the text? > > (or could this be attributed to rounding differences inside label and > text?) > > Thanks > > Randahl From felipe.heidrich at oracle.com Tue Dec 4 12:37:15 2012 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Tue, 4 Dec 2012 12:37:15 -0800 Subject: What contributes to a labels width? In-Reply-To: <58C25092-DC58-48DE-8F6E-4FE0D8050528@rockit.dk> References: <58C25092-DC58-48DE-8F6E-4FE0D8050528@rockit.dk> Message-ID: <27D8B702-6420-4425-A624-F49C2398D6D3@oracle.com> Hi Randahl, It is possible that is bug, but I would need to know the font, text, and platform before I can determine that. If the font is italic, it is possible the width you are missing is the width of the over hanging. Try using text.getBoundsInLocal() and see if that works. Regards Felipe On Dec 4, 2012, at 12:06 PM, Randahl Fink Isaksen wrote: > I am trying to calculate the width of a label before it has been laid out by simulating its width as follows: > > Text text = new Text(); > text.setFont(label.getFont()); > text.setText(label.getText()); > Bounds bounds = text.getLayoutBounds(); > double labelWidth = Math.ceil(bounds.getWidth()); > > Unfortunately, it seems the label width I am predicting is a little less than the actual width of the label after layout (69 vs. 71). Could anyone enlighten me here ? what else contributes to the width of the label than the font and the text? > > (or could this be attributed to rounding differences inside label and text?) > > Thanks > > Randahl From richard.bair at oracle.com Tue Dec 4 12:41:24 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 4 Dec 2012 12:41:24 -0800 Subject: JavaFX performance for complex visualisations In-Reply-To: <50A62AE4.7030309@jugs.org> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> Message-ID: <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> Hi Michael, The thrust of your argument here I think is sound -- that lines are a lot faster than paths, and that the 3D Mesh should be quite a bit faster. There are just a couple minor things I wanted to clarify. > According to my experience JavaFX is currently not able to handle graphically intensive > applications. Depends on what you are doing that is "graphically intense" -- if it is a lot of paths (thousands) then yes, this is slow. If it is a lot of images and lines and effects and such, then actually you can do a heck of a lot with FX (which is graphically intense!) > One reason for this is that all drawing of path based primitives is done > in software and not in hardware. There are a couple reasons for this which are sound. First, general path drawing in shaders is not entirely possible. There are algorithms or proofs of concept that do a pretty good job of it in most cases but not in the general case (at least, we haven't seen it). Second, on mobile / embedded you would die if you depended on the GPU to do these things (the CPU is way, WAY more powerful than the GPU). In fact, we found that on embedded the GPU was the major bottleneck and we needed to move more stuff onto the CPU. Incidentally, Android does the same thing (for the same reason). Another thing is that we limit ourselves to certain shader levels that are available on OpenGL ES 2 for the sake of embedded. With higher shader level support, we could do more. There is also a quality / speed tradeoff involved here. The way we do our antialiasing produces very high quality output, but requires that we upload a mask. On iOS, the highest MSAA level you can support is 4. Our Antialiasing is several orders of magnitude better in terms of the final results. Fundamentally, 2D applications are very different from 3D. GPU's (even mobile GPU's) are fantastic at 3D because that's what they're designed for. We're doing the state of the art when it comes to representing 2D on 3D hardware. The problem is that in some cases, you would like to dial down the performance and have more of a 3D like experience in your application, and in those cases, today, there isn't anything available. Of course we aim to fix this with our 3D support that we're adding. > But a polygon is a path and thus is rendered in software > and this software renderer is in many cases even 2-3 times slower than the one > used in AWT. Just out of curiosity, when is the last time you measured this? By our own benchmarks FX is faster than Ductus (Java2D) now. We did a bunch of performance work in the rasterizer a few months ago. I wonder if your test is available and works on the dev builds of 8 such that this could be reanalyzed? I'm keen to make sure we are faster. > I hope this will change with the upcoming 3D support where we will also get more > hardware accelerated drawing primitives which will hopefully also be usable in 2D. When you say "also usable in 2D", what do you mean? For example, we can have a node that contains all the 3D mesh stuff, and "flatten" it for inclusion in the 2D scene. Is that what you mean? Richard From tobi at ultramixer.com Tue Dec 4 12:50:41 2012 From: tobi at ultramixer.com (Tobi) Date: Tue, 4 Dec 2012 21:50:41 +0100 Subject: How to reach retina support Message-ID: Hi, I would like to start the discussion about the technical requirements for retina support in javaFX. Java6 and flash supports already retina Displays (aka HiDPI) There seams to be two Important Points: 1. prevent MacOSX from switching The JavaFX app to the magnifying mode so that not all rendering is scaled by 2.0 2. Scale all javaFX rendering by factor 2.0 What do we have to do besides these points? Best regard, Tobi From randahl at rockit.dk Tue Dec 4 13:03:42 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Tue, 4 Dec 2012 22:03:42 +0100 Subject: What contributes to a labels width? In-Reply-To: <27D8B702-6420-4425-A624-F49C2398D6D3@oracle.com> References: <58C25092-DC58-48DE-8F6E-4FE0D8050528@rockit.dk> <27D8B702-6420-4425-A624-F49C2398D6D3@oracle.com> Message-ID: <34F5373A-C127-4BBD-8172-A6CBD33E5F6C@rockit.dk> Font is open sans regular. Both getLayoutBounds() and getBoundsInLocal() return the same from text. R. On Dec 4, 2012, at 21:37 , Felipe Heidrich wrote: > Hi Randahl, > > It is possible that is bug, but I would need to know the font, text, and platform before I can determine that. > > If the font is italic, it is possible the width you are missing is the width of the over hanging. Try using text.getBoundsInLocal() and see if that works. > > Regards > Felipe > > > On Dec 4, 2012, at 12:06 PM, Randahl Fink Isaksen wrote: > >> I am trying to calculate the width of a label before it has been laid out by simulating its width as follows: >> >> Text text = new Text(); >> text.setFont(label.getFont()); >> text.setText(label.getText()); >> Bounds bounds = text.getLayoutBounds(); >> double labelWidth = Math.ceil(bounds.getWidth()); >> >> Unfortunately, it seems the label width I am predicting is a little less than the actual width of the label after layout (69 vs. 71). Could anyone enlighten me here ? what else contributes to the width of the label than the font and the text? >> >> (or could this be attributed to rounding differences inside label and text?) >> >> Thanks >> >> Randahl > From randahl at rockit.dk Tue Dec 4 13:11:19 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Tue, 4 Dec 2012 22:11:19 +0100 Subject: How to reach retina support In-Reply-To: References: Message-ID: Hi Tobi I am not sure what you mean by "Scale all javaFX rendering by factor 2.0". Since JavaFX is primarily vector based, I cannot see why you would do that. As long as JavaFX prevents Mac OS from switching a JavaFX app to the magnifying mode, I can ensure that my app looks great, as long as I bring fine enough images along with it. ImageView is already able to scale my images, so why do you need more than bullet 1? Randahl On Dec 4, 2012, at 21:50 , Tobi wrote: > Hi, > > I would like to start the discussion about the technical requirements for retina support in javaFX. Java6 and flash supports already retina Displays (aka HiDPI) > > There seams to be two Important Points: > > 1. prevent MacOSX from switching The JavaFX app to the magnifying mode so that not all rendering is scaled by 2.0 > > 2. Scale all javaFX rendering by factor 2.0 > > What do we have to do besides these points? > > Best regard, > Tobi > From philip.race at oracle.com Tue Dec 4 13:18:05 2012 From: philip.race at oracle.com (Phil Race) Date: Tue, 04 Dec 2012 13:18:05 -0800 Subject: What contributes to a labels width? In-Reply-To: References: <58C25092-DC58-48DE-8F6E-4FE0D8050528@rockit.dk> Message-ID: <50BE688D.7070607@oracle.com> Yes. Take a look at LabeledSkinBase.java where you'll find that there are a few items that are added on to get its preferred width. The comment there says to "add on the graphic, gap and padding as appropriate". -phil. On 12/4/2012 12:33 PM, Mark Fortner wrote: > I think the Label has an inset which may account for the difference between > the Text width and the Label width. > > Mark > > Cheers, > > Mark > > > > > On Tue, Dec 4, 2012 at 12:06 PM, Randahl Fink Isaksenwrote: > >> I am trying to calculate the width of a label before it has been laid out >> by simulating its width as follows: >> >> Text text = new Text(); >> text.setFont(label.getFont()); >> text.setText(label.getText()); >> Bounds bounds = text.getLayoutBounds(); >> double labelWidth = Math.ceil(bounds.getWidth()); >> >> Unfortunately, it seems the label width I am predicting is a little less >> than the actual width of the label after layout (69 vs. 71). Could anyone >> enlighten me here ? what else contributes to the width of the label than >> the font and the text? >> >> (or could this be attributed to rounding differences inside label and >> text?) >> >> Thanks >> >> Randahl From zonski at gmail.com Tue Dec 4 13:54:07 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Wed, 5 Dec 2012 08:54:07 +1100 Subject: JavaFX Community Game project In-Reply-To: <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> Message-ID: <0850157A-4BA7-4D51-B1FF-04760ED0E4CA@gmail.com> I'd be interested in potentially being involved with that collaborative game development effort. I've got buckets to do on improving deployment/maven but one reason I'd be interested in this is because it will nicely raise the issue of how do we deploy and distribute such a game, can we get it in the app stores, etc (and after that, how do we get it on android and iOS). I promise not to make noise about deployment until the end though. Tower defender seems like a good, simple starting point. I'll have a look around later for an existing OSS java one - maybe we can get away with just skinning it. Longer term I think a potential game market for jfx could be along the space of Club Penguin: http://www.clubpenguin.com/ This is a hugely popular platform and is flash based. Jfx should be able to compete with that (if it had a good deployment option and mobile/tablet support), especially since the server is java based so you can use the same devs on front and backend. Quite a bit more complex to build but I built Coinland (effectively Penguin with much less bells and whistles) with a team of 4 devs in 3 months so it's not out of the realm of feasability. https://coinland.com.au/ On 05/12/2012, at 7:24 AM, Richard Bair wrote: > Hi John, > > Just getting through my email and have had this one flagged since Devoxx :-). I respond below to individual points but most of these are probably not worth you responding back on (they're just informational on my part) -- rather, down at the end is the real question I want to have a discussion on (and will be a lot of fun to solve while we're at it). > >> 1. Do any such games, animations or visualisations exist yet? > > Yes. Much like Swing, JavaFX is seeing a lot of adoption in the heavy enterprise desktop sorts of use cases -- not the kind of thing you will find when browsing the internet. Most of these folks don't advertise the technology they're using, and most of them are not interested in letting their competitors know what they're doing or what technology they're using. Which basically means, if we haven't built a demo for it, there isn't anything you will find in your travels. > >> 2. If not, how does Oracle or anyone else actually know that JavaFX is >> capable of supporting such applications? > > That is a good question. Many of the folks I've talked to building such applications have done incredible work + proof of concepts long before I even knew they were using JavaFX. Now, each year we do pretty graphically intense demos for JavaOne, so we have a pretty good feel for it. We have a bunch of benchmarks where we crank the number of nodes up to pretty high numbers, and we know from these benchmarks (at least) that we scale very well compared to other technologies. But I know neither the samples nor the results are publicly available. But at least I can answer the "how does Oracle ? know" part of the question. > > We have had a performance team from the get-go who were solely dedicated to writing benchmarks, running benchmarks, and analyzing results. This has been incredibly helpful. We have results that come not just from the weekly integrations but even from intra-week builds on specific scrum repositories. We have benchmarks and analysis for both desktop and embedded and take performance very seriously. > > Now, there are a lot of ways to use the platform. Some things are better tuned than others. Performance work is driven by tuning and benchmarks. So when we run into issues we have to (a) determine how likely that is to be an issue to the broader development community (b) figure out what the tradeoffs are (usually performance & quality are directly in contradiction with each other), and ( c) schedule & implement the fix. Of course, the same few people (Jim, mostly) are involved in many of the performance fixes and features (like Canvas), so scheduling is an issue and feedback from customers as to what they are actually running into (vs. what a theoretical issue is) has priority. > >> 3. Do I have the wrong understanding that JavaFX is supposed to support such >> applications? > > We expect that JavaFX will be usable for casual games, but we are not building a gaming platform to compete with Unity and the like. If we happen to be just as good, then that's awesome, but it isn't our primary goal. Advanced visualizations, on the other hand, are part of our target market (medical, pharma, enterprise desktop, etc) > >> 4. Is it possible that, for whatever reason, JavaFX is simply not capable of >> supporting such applications? > > There are natural trade-offs between an immediate mode (like Canvas) API and a retained mode (like Scene Graph) API. Now that we have both (plus Java2D + ImageWriter and such for the really crazy cases) we should be capable of a wide range of use cases. However, some things are not yet optimized. But there is no technical reason why we shouldn't be quite capable. > > Another area we have not yet exposed API which is problematic for some people is in the area of custom shaders. It may be that without some kind of custom shader support (which would have to be made to work on D3D as well as OpenGL) certain use cases cannot be easily fulfilled. > >> My feeling that JavaFX can indeed support such applications is based on the >> fact that it is hardware accelerated and therefore it should be limited >> mostly by the capabilities of the graphics card and also because it is often >> talked about in this way. However, I have observed varying levels of >> performance that don't quite follow these principles such as JavaFX >> performing poorly with choppy/jittery animations and transitions on my most >> powerful machine with an NVIDIA GeForce GTX 690 (the current fastest >> graphics card in the world) but performing quite well on machines with much >> lower specifications. > > It is highly unlikely that this is due to performance issues. As mentioned in the last few days on another thread, there are smoothness issues that are completely separate from performance (although both are often talked about together). We're working on the smoothness. Sometimes this is an application problem as opposed to a platform problem (one such example is the DisplayShelf sample, which needs to be rewritten). > >> So I guess I am curious to know what kinds of testing and evaluations Oracle >> has undertaken to determine the performance characteristics of JavaFX and >> exactly what kinds of applications it is actually suitable for. For >> example, I am yet to see any JavaFX application with even the sophistication >> of a Flash electronic greeting card or banner ad and yet I assume JavaFX >> will be used for such purposes eventually. > > I would imagine any of our demos from the last 3-4 years of JavaOne would demonstrate much more complicated use cases than that! But, instead of me just complaining -- lets build one! We'll add it both to Ensemble and our test suite. We can start with something simple (like a greeting card) and expand it out to something wildly complex. What would you like to see? One thing I've wanted to build for years but haven't found the time for was a tower defense game. But what would you think would be a good example of graphics performance that would tell you "hey, this platform is great for visualizations"? > > Richard > From richard.bair at oracle.com Tue Dec 4 14:20:00 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 4 Dec 2012 14:20:00 -0800 Subject: JavaFX Community Game project In-Reply-To: <0850157A-4BA7-4D51-B1FF-04760ED0E4CA@gmail.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <0850157A-4BA7-4D51-B1FF-04760ED0E4CA@gmail.com> Message-ID: <53FC4B9B-FE17-4818-AA2E-F131832FC2CD@oracle.com> We did the "Fossil Game" app -- I don't know if you've all seen it? It is pretty simple and not very graphically intense but we own all the images and everything. Richard On Dec 4, 2012, at 1:54 PM, Daniel Zwolenski wrote: > I'd be interested in potentially being involved with that collaborative game development effort. > > I've got buckets to do on improving deployment/maven but one reason I'd be interested in this is because it will nicely raise the issue of how do we deploy and distribute such a game, can we get it in the app stores, etc (and after that, how do we get it on android and iOS). I promise not to make noise about deployment until the end though. > > Tower defender seems like a good, simple starting point. I'll have a look around later for an existing OSS java one - maybe we can get away with just skinning it. > > Longer term I think a potential game market for jfx could be along the space of Club Penguin: http://www.clubpenguin.com/ > > This is a hugely popular platform and is flash based. Jfx should be able to compete with that (if it had a good deployment option and mobile/tablet support), especially since the server is java based so you can use the same devs on front and backend. > > Quite a bit more complex to build but I built Coinland (effectively Penguin with much less bells and whistles) with a team of 4 devs in 3 months so it's not out of the realm of feasability. > > https://coinland.com.au/ > > > > On 05/12/2012, at 7:24 AM, Richard Bair wrote: > >> Hi John, >> >> Just getting through my email and have had this one flagged since Devoxx :-). I respond below to individual points but most of these are probably not worth you responding back on (they're just informational on my part) -- rather, down at the end is the real question I want to have a discussion on (and will be a lot of fun to solve while we're at it). >> >>> 1. Do any such games, animations or visualisations exist yet? >> >> Yes. Much like Swing, JavaFX is seeing a lot of adoption in the heavy enterprise desktop sorts of use cases -- not the kind of thing you will find when browsing the internet. Most of these folks don't advertise the technology they're using, and most of them are not interested in letting their competitors know what they're doing or what technology they're using. Which basically means, if we haven't built a demo for it, there isn't anything you will find in your travels. >> >>> 2. If not, how does Oracle or anyone else actually know that JavaFX is >>> capable of supporting such applications? >> >> That is a good question. Many of the folks I've talked to building such applications have done incredible work + proof of concepts long before I even knew they were using JavaFX. Now, each year we do pretty graphically intense demos for JavaOne, so we have a pretty good feel for it. We have a bunch of benchmarks where we crank the number of nodes up to pretty high numbers, and we know from these benchmarks (at least) that we scale very well compared to other technologies. But I know neither the samples nor the results are publicly available. But at least I can answer the "how does Oracle ? know" part of the question. >> >> We have had a performance team from the get-go who were solely dedicated to writing benchmarks, running benchmarks, and analyzing results. This has been incredibly helpful. We have results that come not just from the weekly integrations but even from intra-week builds on specific scrum repositories. We have benchmarks and analysis for both desktop and embedded and take performance very seriously. >> >> Now, there are a lot of ways to use the platform. Some things are better tuned than others. Performance work is driven by tuning and benchmarks. So when we run into issues we have to (a) determine how likely that is to be an issue to the broader development community (b) figure out what the tradeoffs are (usually performance & quality are directly in contradiction with each other), and ( c) schedule & implement the fix. Of course, the same few people (Jim, mostly) are involved in many of the performance fixes and features (like Canvas), so scheduling is an issue and feedback from customers as to what they are actually running into (vs. what a theoretical issue is) has priority. >> >>> 3. Do I have the wrong understanding that JavaFX is supposed to support such >>> applications? >> >> We expect that JavaFX will be usable for casual games, but we are not building a gaming platform to compete with Unity and the like. If we happen to be just as good, then that's awesome, but it isn't our primary goal. Advanced visualizations, on the other hand, are part of our target market (medical, pharma, enterprise desktop, etc) >> >>> 4. Is it possible that, for whatever reason, JavaFX is simply not capable of >>> supporting such applications? >> >> There are natural trade-offs between an immediate mode (like Canvas) API and a retained mode (like Scene Graph) API. Now that we have both (plus Java2D + ImageWriter and such for the really crazy cases) we should be capable of a wide range of use cases. However, some things are not yet optimized. But there is no technical reason why we shouldn't be quite capable. >> >> Another area we have not yet exposed API which is problematic for some people is in the area of custom shaders. It may be that without some kind of custom shader support (which would have to be made to work on D3D as well as OpenGL) certain use cases cannot be easily fulfilled. >> >>> My feeling that JavaFX can indeed support such applications is based on the >>> fact that it is hardware accelerated and therefore it should be limited >>> mostly by the capabilities of the graphics card and also because it is often >>> talked about in this way. However, I have observed varying levels of >>> performance that don't quite follow these principles such as JavaFX >>> performing poorly with choppy/jittery animations and transitions on my most >>> powerful machine with an NVIDIA GeForce GTX 690 (the current fastest >>> graphics card in the world) but performing quite well on machines with much >>> lower specifications. >> >> It is highly unlikely that this is due to performance issues. As mentioned in the last few days on another thread, there are smoothness issues that are completely separate from performance (although both are often talked about together). We're working on the smoothness. Sometimes this is an application problem as opposed to a platform problem (one such example is the DisplayShelf sample, which needs to be rewritten). >> >>> So I guess I am curious to know what kinds of testing and evaluations Oracle >>> has undertaken to determine the performance characteristics of JavaFX and >>> exactly what kinds of applications it is actually suitable for. For >>> example, I am yet to see any JavaFX application with even the sophistication >>> of a Flash electronic greeting card or banner ad and yet I assume JavaFX >>> will be used for such purposes eventually. >> >> I would imagine any of our demos from the last 3-4 years of JavaOne would demonstrate much more complicated use cases than that! But, instead of me just complaining -- lets build one! We'll add it both to Ensemble and our test suite. We can start with something simple (like a greeting card) and expand it out to something wildly complex. What would you like to see? One thing I've wanted to build for years but haven't found the time for was a tower defense game. But what would you think would be a good example of graphics performance that would tell you "hey, this platform is great for visualizations"? >> >> Richard >> From zonski at gmail.com Tue Dec 4 15:00:48 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Wed, 5 Dec 2012 10:00:48 +1100 Subject: JavaFX Community Game project In-Reply-To: <53FC4B9B-FE17-4818-AA2E-F131832FC2CD@oracle.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <0850157A-4BA7-4D51-B1FF-04760ED0E4CA@gmail.com> <53FC4B9B-FE17-4818-AA2E-F131832FC2CD@oracle.com> Message-ID: I've heard mention of it, where can I get a copy to run? On Wed, Dec 5, 2012 at 9:20 AM, Richard Bair wrote: > Fossil Game From John_Smith at symantec.com Tue Dec 4 15:07:57 2012 From: John_Smith at symantec.com (John Smith) Date: Tue, 4 Dec 2012 15:07:57 -0800 Subject: How to reach retina support In-Reply-To: References: Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D22160AD6A2AC@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> What is desirable is likely: 1. A glass implementation which takes advantages of OS API level optimizations for Retina. 2. An ability to support apps spanning retina and non-retina windows. 3. Image loaders which are aware of whether to use retina or non-retina images 4. Ensuring that retina aware apps work when embedded in Swing and Browsers 5. Identifying to the OS that the app is retina aware, so that the OS doesn't try to double up the applications pixels. 6. A conditional feature which identifies to the app writer that they are running on a retina so they can take special action if they want to. 7. High quality text support in retina mode with correct font sizing. 8. The ability, perhaps at a node level, to indicate that a 1x or a 4x backing store should be used. 9. The ability to specify co-ordinates in a device resolution independent way (e.g. measurement facilities like font ems and percentage values). ----------------------------------- If interested, there is some further background info below: There are some comments by Mike Swingler on developing Retina support for Swing. They won't all apply to JavaFX, and I don't understand them all either ;-) But they are very interesting to read. See: http://prod.lists.apple.com/archives/java-dev/2012/Oct/msg00144.html 1. History of retina in Swing. It seems that Apple got retina support working in Apple JDK6 by hacking the graphics pipeline pretty severely and that that work can't be directly ported to OpenJDK, so getting Retina support for Swing is an open item and I don't know if it is scheduled at any time. If Swing for the JDK7+ does not get Retina support, then the impact that has on embedding JFXPanels in Swing will need to be assessed. Regarding potential OpenJDK AWT support for Retina, Mike comments: "In order to render at a Retina resolution, the OpenGL pipeline will have to create a 4x sized backing store for the pixels, and apply a 2x affine transform to all graphics operations going from the API layer to the graphics context layer. Just that easy (I am, of course joking, the work is actually very hard and is littered with corner cases)." Perhaps this is also relevant for supporting Retina in JavaFX. 2. What to do if your app window spans multiple screens, one Retina and one not. Mike comments: "handling Retina *well* will also include tearing down and recreating the backing store dynamically as window is dragged across displays of varying resolution, and getting the app to redraw a the right times to make this transition smooth." 3. Apple's OS allows embedding some retina scaled panels inside some panels which are not retina scaled. There is a very good overview of the user facing issues of software running on Retina here: http://www.anandtech.com/show/6023/the-nextgen-macbook-pro-with-retina-display-review/6. From the linked article about Retina support in Aperture: "Here Apple is scaling the UI elements like the menus and widgets on the screen (backing scale factor = 2.0), but displaying the open image unscaled (backing scale factor = 1.0). As a result we can fit almost an entire 2880 x 1800 image on the screen without zooming out. Remember the backing scale factor isn't global, individual elements on the screen can be scaled independently depending on their purpose." 4. There is a whole range of things which apple recommends when developing apps for Retina: https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html#//apple_ref/doc/uid/TP40012302-CH4-SW4 Providing @2x graphics in addition to "standard" resolution images and adopting an @2x graphics naming convention. Including high resolution icons. Packaging your app with meta data which indicates to the OS that it is retina capable. Loading images using methods which seamlessly lookup the appropriate retina or non-retina images. Use higher point fonts for retina displays. Make use of advanced apple APIs for high performance rendering of pixels and queries of pixel data. Retina support for Apple devices is a probably easier than hi-dpi support in non-apple devices. For instance, Apple really only target a limited set of screen resolutions, whereby retina seems to mean double the "standard" resolution. There are currently a bunch of non-apple devices which have high resolution displays (e.g. 1920x1080 13 inch laptops) that are near retina, but not quite and the pixels on these devices become so small that it is hard to make stuff out and use the devices unless your eyes are really young. What might be optimal for JavaFX is display resolution and zoom level independent support. e.g. image lookup routines which choose from bitmapped graphics at @0.75x @1x @1.5x @2x, rather than just @1x and @2x. Such resolution independent apps is useful for accessibility applications. Perhaps there is a link between the Hi-DPI discussion and support for high quality display of resolution and zoom level independent applications. Hopefully good support for display resolution and zoom level independent JavaFX will not prove difficult. JavaFX has a thin native porting layer in Glass. Most of the JavaFX system is vector based. JavaFX already includes scaling and zooming primitives and a pipeline which supports these at independent levels for different Scene Graph nodes. JavaFX also already features resizable controls supported by sophisticated layout managers. -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Randahl Fink Isaksen Sent: Tuesday, December 04, 2012 1:11 PM To: Tobi Cc: Mailing List openjfx-dev at openjdk.java.net Subject: Re: How to reach retina support Hi Tobi I am not sure what you mean by "Scale all javaFX rendering by factor 2.0". Since JavaFX is primarily vector based, I cannot see why you would do that. As long as JavaFX prevents Mac OS from switching a JavaFX app to the magnifying mode, I can ensure that my app looks great, as long as I bring fine enough images along with it. ImageView is already able to scale my images, so why do you need more than bullet 1? Randahl On Dec 4, 2012, at 21:50 , Tobi wrote: > Hi, > > I would like to start the discussion about the technical requirements for retina support in javaFX. Java6 and flash supports already retina Displays (aka HiDPI) > > There seams to be two Important Points: > > 1. prevent MacOSX from switching The JavaFX app to the magnifying mode so that not all rendering is scaled by 2.0 > > 2. Scale all javaFX rendering by factor 2.0 > > What do we have to do besides these points? > > Best regard, > Tobi > From danno.ferrin at shemnon.com Tue Dec 4 15:09:03 2012 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Tue, 4 Dec 2012 16:09:03 -0700 Subject: JavaFX Community Game project In-Reply-To: References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <0850157A-4BA7-4D51-B1FF-04760ED0E4CA@gmail.com> Message-ID: Obligatory rant on pedantic reply-all to list standards. On Dec 4, 2012 4:06 PM, "Danno Ferrin" wrote: > > Club penguin in JFX is exactly the same thought I had. Except having it run not just in the browser but also on iOS and Android from the same codebase would be the competitive value. There have been many times where getting the kids out the door for long trips would have been easier if I could just get them to switch over to club penguin on the kindle. > > On Dec 4, 2012 3:11 PM, "Daniel Zwolenski" wrote: >> >> I'd be interested in potentially being involved with that collaborative game development effort. >> >> I've got buckets to do on improving deployment/maven but one reason I'd be interested in this is because it will nicely raise the issue of how do we deploy and distribute such a game, can we get it in the app stores, etc (and after that, how do we get it on android and iOS). I promise not to make noise about deployment until the end though. >> >> Tower defender seems like a good, simple starting point. I'll have a look around later for an existing OSS java one - maybe we can get away with just skinning it. >> >> Longer term I think a potential game market for jfx could be along the space of Club Penguin: http://www.clubpenguin.com/ >> >> This is a hugely popular platform and is flash based. Jfx should be able to compete with that (if it had a good deployment option and mobile/tablet support), especially since the server is java based so you can use the same devs on front and backend. >> >> Quite a bit more complex to build but I built Coinland (effectively Penguin with much less bells and whistles) with a team of 4 devs in 3 months so it's not out of the realm of feasability. >> >> https://coinland.com.au/ >> >> >> >> On 05/12/2012, at 7:24 AM, Richard Bair wrote: >> >> > Hi John, >> > >> > Just getting through my email and have had this one flagged since Devoxx :-). I respond below to individual points but most of these are probably not worth you responding back on (they're just informational on my part) -- rather, down at the end is the real question I want to have a discussion on (and will be a lot of fun to solve while we're at it). >> > >> >> 1. Do any such games, animations or visualisations exist yet? >> > >> > Yes. Much like Swing, JavaFX is seeing a lot of adoption in the heavy enterprise desktop sorts of use cases -- not the kind of thing you will find when browsing the internet. Most of these folks don't advertise the technology they're using, and most of them are not interested in letting their competitors know what they're doing or what technology they're using. Which basically means, if we haven't built a demo for it, there isn't anything you will find in your travels. >> > >> >> 2. If not, how does Oracle or anyone else actually know that JavaFX is >> >> capable of supporting such applications? >> > >> > That is a good question. Many of the folks I've talked to building such applications have done incredible work + proof of concepts long before I even knew they were using JavaFX. Now, each year we do pretty graphically intense demos for JavaOne, so we have a pretty good feel for it. We have a bunch of benchmarks where we crank the number of nodes up to pretty high numbers, and we know from these benchmarks (at least) that we scale very well compared to other technologies. But I know neither the samples nor the results are publicly available. But at least I can answer the "how does Oracle ? know" part of the question. >> > >> > We have had a performance team from the get-go who were solely dedicated to writing benchmarks, running benchmarks, and analyzing results. This has been incredibly helpful. We have results that come not just from the weekly integrations but even from intra-week builds on specific scrum repositories. We have benchmarks and analysis for both desktop and embedded and take performance very seriously. >> > >> > Now, there are a lot of ways to use the platform. Some things are better tuned than others. Performance work is driven by tuning and benchmarks. So when we run into issues we have to (a) determine how likely that is to be an issue to the broader development community (b) figure out what the tradeoffs are (usually performance & quality are directly in contradiction with each other), and ( c) schedule & implement the fix. Of course, the same few people (Jim, mostly) are involved in many of the performance fixes and features (like Canvas), so scheduling is an issue and feedback from customers as to what they are actually running into (vs. what a theoretical issue is) has priority. >> > >> >> 3. Do I have the wrong understanding that JavaFX is supposed to support such >> >> applications? >> > >> > We expect that JavaFX will be usable for casual games, but we are not building a gaming platform to compete with Unity and the like. If we happen to be just as good, then that's awesome, but it isn't our primary goal. Advanced visualizations, on the other hand, are part of our target market (medical, pharma, enterprise desktop, etc) >> > >> >> 4. Is it possible that, for whatever reason, JavaFX is simply not capable of >> >> supporting such applications? >> > >> > There are natural trade-offs between an immediate mode (like Canvas) API and a retained mode (like Scene Graph) API. Now that we have both (plus Java2D + ImageWriter and such for the really crazy cases) we should be capable of a wide range of use cases. However, some things are not yet optimized. But there is no technical reason why we shouldn't be quite capable. >> > >> > Another area we have not yet exposed API which is problematic for some people is in the area of custom shaders. It may be that without some kind of custom shader support (which would have to be made to work on D3D as well as OpenGL) certain use cases cannot be easily fulfilled. >> > >> >> My feeling that JavaFX can indeed support such applications is based on the >> >> fact that it is hardware accelerated and therefore it should be limited >> >> mostly by the capabilities of the graphics card and also because it is often >> >> talked about in this way. However, I have observed varying levels of >> >> performance that don't quite follow these principles such as JavaFX >> >> performing poorly with choppy/jittery animations and transitions on my most >> >> powerful machine with an NVIDIA GeForce GTX 690 (the current fastest >> >> graphics card in the world) but performing quite well on machines with much >> >> lower specifications. >> > >> > It is highly unlikely that this is due to performance issues. As mentioned in the last few days on another thread, there are smoothness issues that are completely separate from performance (although both are often talked about together). We're working on the smoothness. Sometimes this is an application problem as opposed to a platform problem (one such example is the DisplayShelf sample, which needs to be rewritten). >> > >> >> So I guess I am curious to know what kinds of testing and evaluations Oracle >> >> has undertaken to determine the performance characteristics of JavaFX and >> >> exactly what kinds of applications it is actually suitable for. For >> >> example, I am yet to see any JavaFX application with even the sophistication >> >> of a Flash electronic greeting card or banner ad and yet I assume JavaFX >> >> will be used for such purposes eventually. >> > >> > I would imagine any of our demos from the last 3-4 years of JavaOne would demonstrate much more complicated use cases than that! But, instead of me just complaining -- lets build one! We'll add it both to Ensemble and our test suite. We can start with something simple (like a greeting card) and expand it out to something wildly complex. What would you like to see? One thing I've wanted to build for years but haven't found the time for was a tower defense game. But what would you think would be a good example of graphics performance that would tell you "hey, this platform is great for visualizations"? >> > >> > Richard >> > From John_Smith at symantec.com Tue Dec 4 15:25:50 2012 From: John_Smith at symantec.com (John Smith) Date: Tue, 4 Dec 2012 15:25:50 -0800 Subject: JavaFX performance for complex visualisations In-Reply-To: <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D22160AD6A2E3@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> > In fact, we found that on embedded the GPU was the major bottleneck and we needed to move more stuff onto the CPU. Seeing as a lot of the rendering work is done on the CPU and not the GPU, is it (or can it) be optimized to make use of multi-core CPUs, or must the rendering be single threaded? Michael asked me this question in a forum thread and I didn't have any answer for it. -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Richard Bair Sent: Tuesday, December 04, 2012 12:41 PM To: Dr. Michael Paus Cc: openjfx-dev at openjdk.java.net Subject: Re: JavaFX performance for complex visualisations Hi Michael, The thrust of your argument here I think is sound -- that lines are a lot faster than paths, and that the 3D Mesh should be quite a bit faster. There are just a couple minor things I wanted to clarify. > According to my experience JavaFX is currently not able to handle > graphically intensive applications. Depends on what you are doing that is "graphically intense" -- if it is a lot of paths (thousands) then yes, this is slow. If it is a lot of images and lines and effects and such, then actually you can do a heck of a lot with FX (which is graphically intense!) > One reason for this is that all drawing of path based primitives is > done in software and not in hardware. There are a couple reasons for this which are sound. First, general path drawing in shaders is not entirely possible. There are algorithms or proofs of concept that do a pretty good job of it in most cases but not in the general case (at least, we haven't seen it). Second, on mobile / embedded you would die if you depended on the GPU to do these things (the CPU is way, WAY more powerful than the GPU). In fact, we found that on embedded the GPU was the major bottleneck and we needed to move more stuff onto the CPU. Incidentally, Android does the same thing (for the same reason). Another thing is that we limit ourselves to certain shader levels that are available on OpenGL ES 2 for the sake of embedded. With higher shader level support, we could do more. There is also a quality / speed tradeoff involved here. The way we do our antialiasing produces very high quality output, but requires that we upload a mask. On iOS, the highest MSAA level you can support is 4. Our Antialiasing is several orders of magnitude better in terms of the final results. Fundamentally, 2D applications are very different from 3D. GPU's (even mobile GPU's) are fantastic at 3D because that's what they're designed for. We're doing the state of the art when it comes to representing 2D on 3D hardware. The problem is that in some cases, you would like to dial down the performance and have more of a 3D like experience in your application, and in those cases, today, there isn't anything available. Of course we aim to fix this with our 3D support that we're adding. > But a polygon is a path and thus is rendered in software and this > software renderer is in many cases even 2-3 times slower than the one > used in AWT. Just out of curiosity, when is the last time you measured this? By our own benchmarks FX is faster than Ductus (Java2D) now. We did a bunch of performance work in the rasterizer a few months ago. I wonder if your test is available and works on the dev builds of 8 such that this could be reanalyzed? I'm keen to make sure we are faster. > I hope this will change with the upcoming 3D support where we will > also get more hardware accelerated drawing primitives which will hopefully also be usable in 2D. When you say "also usable in 2D", what do you mean? For example, we can have a node that contains all the 3D mesh stuff, and "flatten" it for inclusion in the 2D scene. Is that what you mean? Richard From richard.bair at oracle.com Tue Dec 4 15:54:04 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 4 Dec 2012 15:54:04 -0800 Subject: JavaFX performance for complex visualisations In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D22160AD6A2E3@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D22160AD6A2E3@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <985B648E-5276-44F9-8A1C-72D441EEEF94@oracle.com> >> In fact, we found that on embedded the GPU was the major bottleneck and we needed to move more stuff onto the CPU. > > Seeing as a lot of the rendering work is done on the CPU and not the GPU, is it (or can it) be optimized to make use of multi-core CPUs, or must the rendering be single threaded? Yes, in fact this use for multithreaded rendering has been part of our design from the 1.0 days. It is going to be some work to enable (as our rendering uses static variables to reduce garbage generation for temporary objects), also I don't know if our native loops are ready for it. But this is definitely a goal. No use letting a pile of cores sit idle while we melt the unlucky ones. However on mobile most of the time is spent moving the masks (textures) from CPU to GPU, so I don't have a good feel for the overall performance impact there. From richard.bair at oracle.com Tue Dec 4 16:00:33 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 4 Dec 2012 16:00:33 -0800 Subject: How to reach retina support In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D22160AD6A2AC@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <411E73D23DEC4C46BA48F2B6D8BF3D22160AD6A2AC@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <81230380-97BD-4951-9CE2-9E2254103456@oracle.com> In fact, we've implemented retina once already for the iOS prototype. I'm hoping adding the support to Mac desktop isn't terribly hard. Good question about level of support though -- so far we have been thinking only of the 2x retina case. One reason for this is that aligning to pixel boundaries for crisp controls etc is a PAIN if we don't simply double, but start doing fractional scaling. You position at 100 thinking it will be crisp but it ends up at some fractional position instead. On Dec 4, 2012, at 3:07 PM, John Smith wrote: > What is desirable is likely: > 1. A glass implementation which takes advantages of OS API level optimizations for Retina. > 2. An ability to support apps spanning retina and non-retina windows. > 3. Image loaders which are aware of whether to use retina or non-retina images > 4. Ensuring that retina aware apps work when embedded in Swing and Browsers > 5. Identifying to the OS that the app is retina aware, so that the OS doesn't try to double up the applications pixels. > 6. A conditional feature which identifies to the app writer that they are running on a retina so they can take special action if they want to. > 7. High quality text support in retina mode with correct font sizing. > 8. The ability, perhaps at a node level, to indicate that a 1x or a 4x backing store should be used. > 9. The ability to specify co-ordinates in a device resolution independent way (e.g. measurement facilities like font ems and percentage values). > > ----------------------------------- > > If interested, there is some further background info below: > > There are some comments by Mike Swingler on developing Retina support for Swing. They won't all apply to JavaFX, and I don't understand them all either ;-) But they are very interesting to read. See: http://prod.lists.apple.com/archives/java-dev/2012/Oct/msg00144.html > > 1. History of retina in Swing. > > It seems that Apple got retina support working in Apple JDK6 by hacking the graphics pipeline pretty severely and that that work can't be directly ported to OpenJDK, so getting Retina support for Swing is an open item and I don't know if it is scheduled at any time. If Swing for the JDK7+ does not get Retina support, then the impact that has on embedding JFXPanels in Swing will need to be assessed. > > Regarding potential OpenJDK AWT support for Retina, Mike comments: "In order to render at a Retina resolution, the OpenGL pipeline will have to create a 4x sized backing store for the pixels, and apply a 2x affine transform to all graphics operations going from the API layer to the graphics context layer. Just that easy (I am, of course joking, the work is actually very hard and is littered with corner cases)." > > Perhaps this is also relevant for supporting Retina in JavaFX. > > 2. What to do if your app window spans multiple screens, one Retina and one not. > > Mike comments: "handling Retina *well* will also include tearing down and recreating the backing store dynamically as window is dragged across displays of varying resolution, and getting the app to redraw a the right times to make this transition smooth." > > 3. Apple's OS allows embedding some retina scaled panels inside some panels which are not retina scaled. There is a very good overview of the user facing issues of software running on Retina here: http://www.anandtech.com/show/6023/the-nextgen-macbook-pro-with-retina-display-review/6. From the linked article about Retina support in Aperture: > > "Here Apple is scaling the UI elements like the menus and widgets on the screen (backing scale factor = 2.0), but displaying the open image unscaled (backing scale factor = 1.0). As a result we can fit almost an entire 2880 x 1800 image on the screen without zooming out. Remember the backing scale factor isn't global, individual elements on the screen can be scaled independently depending on their purpose." > > 4. There is a whole range of things which apple recommends when developing apps for Retina: https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html#//apple_ref/doc/uid/TP40012302-CH4-SW4 > Providing @2x graphics in addition to "standard" resolution images and adopting an @2x graphics naming convention. > Including high resolution icons. > Packaging your app with meta data which indicates to the OS that it is retina capable. > Loading images using methods which seamlessly lookup the appropriate retina or non-retina images. > Use higher point fonts for retina displays. > Make use of advanced apple APIs for high performance rendering of pixels and queries of pixel data. > > Retina support for Apple devices is a probably easier than hi-dpi support in non-apple devices. For instance, Apple really only target a limited set of screen resolutions, whereby retina seems to mean double the "standard" resolution. There are currently a bunch of non-apple devices which have high resolution displays (e.g. 1920x1080 13 inch laptops) that are near retina, but not quite and the pixels on these devices become so small that it is hard to make stuff out and use the devices unless your eyes are really young. What might be optimal for JavaFX is display resolution and zoom level independent support. e.g. image lookup routines which choose from bitmapped graphics at @0.75x @1x @1.5x @2x, rather than just @1x and @2x. Such resolution independent apps is useful for accessibility applications. Perhaps there is a link between the Hi-DPI discussion and support for high quality display of resolution and zoom level independent applications. > > Hopefully good support for display resolution and zoom level independent JavaFX will not prove difficult. JavaFX has a thin native porting layer in Glass. Most of the JavaFX system is vector based. JavaFX already includes scaling and zooming primitives and a pipeline which supports these at independent levels for different Scene Graph nodes. JavaFX also already features resizable controls supported by sophisticated layout managers. > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Randahl Fink Isaksen > Sent: Tuesday, December 04, 2012 1:11 PM > To: Tobi > Cc: Mailing List openjfx-dev at openjdk.java.net > Subject: Re: How to reach retina support > > Hi Tobi > > I am not sure what you mean by "Scale all javaFX rendering by factor 2.0". Since JavaFX is primarily vector based, I cannot see why you would do that. > > As long as JavaFX prevents Mac OS from switching a JavaFX app to the magnifying mode, I can ensure that my app looks great, as long as I bring fine enough images along with it. ImageView is already able to scale my images, so why do you need more than bullet 1? > > Randahl > > > > On Dec 4, 2012, at 21:50 , Tobi wrote: > >> Hi, >> >> I would like to start the discussion about the technical requirements for retina support in javaFX. Java6 and flash supports already retina Displays (aka HiDPI) >> >> There seams to be two Important Points: >> >> 1. prevent MacOSX from switching The JavaFX app to the magnifying mode so that not all rendering is scaled by 2.0 >> >> 2. Scale all javaFX rendering by factor 2.0 >> >> What do we have to do besides these points? >> >> Best regard, >> Tobi > From tbee at tbee.org Tue Dec 4 22:06:13 2012 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 05 Dec 2012 07:06:13 +0100 Subject: JavaFX Community Game project In-Reply-To: <0850157A-4BA7-4D51-B1FF-04760ED0E4CA@gmail.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <0850157A-4BA7-4D51-B1FF-04760ED0E4CA@gmail.com> Message-ID: <50BEE455.3080403@tbee.org> On 2012-12-04 22:54, Daniel Zwolenski wrote: > Quite a bit more complex to build but I built Coinland (effectively Penguin with much less bells and whistles) with a team of 4 devs in 3 months so it's not out of the realm of feasability. Is that full FTE? Because if I spread those hours over my hobby time available... Tom From tom.schindl at bestsolution.at Wed Dec 5 03:08:37 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 05 Dec 2012 12:08:37 +0100 Subject: StyleManager#reloadStylesheets(Scene) replacement in FX8 In-Reply-To: References: <50BA1713.7050607@bestsolution.at> Message-ID: <50BF2B35.7000502@bestsolution.at> Hi David, I tested with the latest JRE8 and unfortunately this is not working. The CSS is only reloaded from the filesystem when the JVM is restarted, so the same caching as in 2.x is happening. Tom Am 03.12.12 18:13, schrieb David Grieve: > Remove and re-add the stylesheet. > > On Dec 1, 2012, at 9:41 AM, Tom Schindl wrote: > >> Hi, >> >> To force reloading of stylesheets I used in FX2.2 >> StyleManager.getInstance().reloadStylesheets(scene). What is the >> replacement of this in FX8. >> >> Tom >> >> -- >> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >> ------------------------------------------------------------------------ >> tom schindl gesch?ftsf?hrer/CEO >> ------------------------------------------------------------------------ >> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >> http://www.BestSolution.at phone ++43 512 935834 > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From zonski at gmail.com Wed Dec 5 03:50:07 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Wed, 5 Dec 2012 22:50:07 +1100 Subject: JavaFX Community Game project In-Reply-To: <50BEE455.3080403@tbee.org> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <0850157A-4BA7-4D51-B1FF-04760ED0E4CA@gmail.com> <50BEE455.3080403@tbee.org> Message-ID: Maybe we should start with tower defender first and work our way up to a Club Penguin clone? :) A quick search of the web - looks like the oss tower defender games are pretty rough. The code is pretty simple to write so we might be best creating our own. It should be a pretty basic tiled map for the background, and then a fairly simple sprite engine with bounding circles for collisions. Not exactly rocket science. I'd be quite curious to see the code for this Fossil game to see if there's anything we can leverage (not sure "Fossil" is something you want to include in your branding when trying to make Java have modern appeal, but anyway). The main concern I would have is some nice slick graphics. For a showcase product, if the graphics aren't good then we are better off not bothering. I have the usual design skills of a programmer (i.e. I know magenta and green don't go together but that's about my limit). Does anyone have good (and I mean pro) design skills, or know someone who does? Are there any graphic designers available through Oracle who could be available to work on this? I have some awesome designers I use, but none of them care about JFX so they sure won't be doing this sort of stuff pro-bono. For my money, the themes that work best are the cutesy-fun graphic themes, not the nerdy ones with dragons or space ships (unless they are cute or funny). Angry Birds, Plants vs Zombies, Cut the Rope, etc. http://www.reigndesign.com/blog/what-do-all-top-selling-iphone-games-have-in-common-its-the-controls-stupid/ We could even start simpler than tower defender and do something like Fruit Ninja. That would be ridiculously easy to code but maybe not quite as engaging if you're on a PC using a mouse. I'm pretty easy on the game selection so long as it's simple to start so we can get some quick results (and simple "sells" better, complexity is only fun for us nerds). On Wed, Dec 5, 2012 at 5:06 PM, Tom Eugelink wrote: > On 2012-12-04 22:54, Daniel Zwolenski wrote: > >> Quite a bit more complex to build but I built Coinland (effectively >> Penguin with much less bells and whistles) with a team of 4 devs in 3 >> months so it's not out of the realm of feasability. >> > > Is that full FTE? Because if I spread those hours over my hobby time > available... > > Tom > > From tbee at tbee.org Wed Dec 5 04:07:22 2012 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 05 Dec 2012 13:07:22 +0100 Subject: JavaFX Community Game project In-Reply-To: References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <0850157A-4BA7-4D51-B1FF-04760ED0E4CA@gmail.com> <50BEE455.3080403@tbee.org> Message-ID: <50BF38FA.7000105@tbee.org> On 2012-12-05 12:50, Daniel Zwolenski wrote: > The main concern I would have is some nice slick graphics. There are some freely available graphics packages, like here: http://www.lostgarden.com/2007/04/free-game-graphics-tyrian-ships-and.html http://hasgraphics.com/remastered-tyrian-graphics/ Or here: http://www.lostgarden.com/2005/03/download-complete-set-of-sweet-8-bit.html Or for some semi 3D: http://hasgraphics.com/danc-planet-cute-tileset/ Tom From mark.bulthuis at nedap.com Wed Dec 5 04:36:05 2012 From: mark.bulthuis at nedap.com (Mark Bulthuis) Date: Wed, 5 Dec 2012 13:36:05 +0100 Subject: how to use fxml? Message-ID: <03230006CA5E1B4D89CCC1DC0BF2209C04725438A2@NVS0192.nedap.local> Hi, If I take a look at the javafx examples, the application is once defined in a fxml file. Why not use this construction for each node? For example creating a custom node: Parent customNode = (Parent) fxmlLoader.load(getClass().getResource("customNode.fxml").openStream()); MyController controller = (MyController) fxmlLoader.getController(); controller.setDataModel(person); Isn't this a better way? More MVC? Greetz, Mark From david.grieve at oracle.com Wed Dec 5 05:47:05 2012 From: david.grieve at oracle.com (David Grieve) Date: Wed, 5 Dec 2012 08:47:05 -0500 Subject: StyleManager#reloadStylesheets(Scene) replacement in FX8 In-Reply-To: <50BF2B35.7000502@bestsolution.at> References: <50BA1713.7050607@bestsolution.at> <50BF2B35.7000502@bestsolution.at> Message-ID: <4CEF19C1-2B9F-4C85-A0BC-AC4F19735338@oracle.com> Must be a bug. The code is intended to re-parse a stylesheet if it has been removed and re-added to the Scene (or Parent) stylesheets. If you would create a bug, I will fix it ASAP. On Dec 5, 2012, at 6:08 AM, Tom Schindl wrote: > Hi David, > > I tested with the latest JRE8 and unfortunately this is not working. The > CSS is only reloaded from the filesystem when the JVM is restarted, so > the same caching as in 2.x is happening. > > Tom > > Am 03.12.12 18:13, schrieb David Grieve: >> Remove and re-add the stylesheet. >> >> On Dec 1, 2012, at 9:41 AM, Tom Schindl wrote: >> >>> Hi, >>> >>> To force reloading of stylesheets I used in FX2.2 >>> StyleManager.getInstance().reloadStylesheets(scene). What is the >>> replacement of this in FX8. >>> >>> Tom >>> >>> -- >>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>> ------------------------------------------------------------------------ >>> tom schindl gesch?ftsf?hrer/CEO >>> ------------------------------------------------------------------------ >>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>> http://www.BestSolution.at phone ++43 512 935834 >> > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From jmartine_1026 at yahoo.com Wed Dec 5 06:45:08 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Wed, 5 Dec 2012 06:45:08 -0800 (PST) Subject: JavaFX Community Game project In-Reply-To: <50BF38FA.7000105@tbee.org> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <0850157A-4BA7-4D51-B1FF-04760ED0E4CA@gmail.com> <50BEE455.3080403@tbee.org> <50BF38FA.7000105@tbee.org> Message-ID: <1354718708.17474.YahooMailNeo@web161504.mail.bf1.yahoo.com> I have experience in this realm and would enjoy helping out and can learn a lot in the process. ?What it requires is a leader to head this. Besides the free graphics that Tom pointed out we might be able to get graphics donated in exchange for some free advertisement. ? thanks jose ________________________________ From: Tom Eugelink To: "openjfx-dev at openjdk.java.net" Sent: Wednesday, December 5, 2012 7:07 AM Subject: Re: JavaFX Community Game project On 2012-12-05 12:50, Daniel Zwolenski wrote: > The main concern I would have is some nice slick graphics. There are some freely available graphics packages, like here: http://www.lostgarden.com/2007/04/free-game-graphics-tyrian-ships-and.html http://hasgraphics.com/remastered-tyrian-graphics/ Or here: http://www.lostgarden.com/2005/03/download-complete-set-of-sweet-8-bit.html Or for some semi 3D: http://hasgraphics.com/danc-planet-cute-tileset/ Tom From jmartine_1026 at yahoo.com Wed Dec 5 07:58:55 2012 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Wed, 5 Dec 2012 07:58:55 -0800 (PST) Subject: JavaFX performance for complex visualisations In-Reply-To: <004f01cdc3da$c8fd1b10$5af75130$@com.au> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> Message-ID: <1354723135.3096.YahooMailNeo@web161503.mail.bf1.yahoo.com> John, I do have some complex graphics and the performance is not perfect but pretty good. ?On the Intel i series CPU's they work great without jitter. ?Currently developing on AMD Turon laptop with a decent graphics card ATI4560 and I do see some jitter. ?I am hopeful that I will be able to work through them. ?Currently buying a MAC mini to try it out on there. ?Looking for people to give feedback and maybe help identify where the jitter is coming from. ?I can send a copy, but it is only packaged for Windows but can send you the jar to execute yourself on other platforms. Overall I am happy with JavaFX performance, while not perfect I have trust in the platform to deliver on newer CPU's. thanks jose ________________________________ From: John C. Turnbull To: openjfx-dev at openjdk.java.net Sent: Friday, November 16, 2012 4:14 AM Subject: JavaFX performance for complex visualisations I am under the impression that JavaFX 2.x can be used to develop reasonably complex and demanding visualisations including games, animations etc. and that JavaFX 8+ will enable such visualisations to be 3D. However, as of yet, I have not seen any such advanced visualisations anywhere.? The animation samples in Ensemble are obviously very rudimentary (probably intentionally) and I have not been able to find anything that I would classify as complex, demanding or advanced anywhere on the internet. And this brings me to ask a few questions: 1. Do any such games, animations or visualisations exist yet? 2. If not, how does Oracle or anyone else actually know that JavaFX is capable of supporting such applications? 3. Do I have the wrong understanding that JavaFX is supposed to support such applications? 4. Is it possible that, for whatever reason, JavaFX is simply not capable of supporting such applications? My feeling that JavaFX can indeed support such applications is based on the fact that it is hardware accelerated and therefore it should be limited mostly by the capabilities of the graphics card and also because it is often talked about in this way.? However, I have observed varying levels of performance that don't quite follow these principles such as JavaFX performing poorly with choppy/jittery animations and transitions on my most powerful machine with an NVIDIA GeForce GTX 690 (the current fastest graphics card in the world) but performing quite well on machines with much lower specifications. So I guess I am curious to know what kinds of testing and evaluations Oracle has undertaken to determine the performance characteristics of JavaFX and exactly what kinds of applications it is actually suitable for.? For example, I am yet to see any JavaFX application with even the sophistication of a Flash electronic greeting card or banner ad and yet I assume JavaFX will be used for such purposes eventually. I'd appreciate comments from Oracle and anyone who has in fact developed more complex visualisations/animations/games with JavaFX that aren't publicly accessible. Thanks, -jct From swpalmer at gmail.com Wed Dec 5 09:00:32 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 5 Dec 2012 12:00:32 -0500 Subject: JavaFX performance for complex visualisations In-Reply-To: <1354723135.3096.YahooMailNeo@web161503.mail.bf1.yahoo.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <1354723135.3096.YahooMailNeo@web161503.mail.bf1.yahoo.com> Message-ID: I have what amounts to something that looks like a complex UML diagram and at times the performance can be abysmal when I drag a node. I think it is the Path objects that make up the connections. Scott On 2012-12-05, at 10:58 AM, Jose Martinez wrote: > John, > > I do have some complex graphics and the performance is not perfect but pretty good. On the Intel i series CPU's they work great without jitter. Currently developing on AMD Turon laptop with a decent graphics card ATI4560 and I do see some jitter. I am hopeful that I will be able to work through them. Currently buying a MAC mini to try it out on there. Looking for people to give feedback and maybe help identify where the jitter is coming from. I can send a copy, but it is only packaged for Windows but can send you the jar to execute yourself on other platforms. > > Overall I am happy with JavaFX performance, while not perfect I have trust in the platform to deliver on newer CPU's. > > thanks > jose > > > ________________________________ > From: John C. Turnbull > To: openjfx-dev at openjdk.java.net > Sent: Friday, November 16, 2012 4:14 AM > Subject: JavaFX performance for complex visualisations > > I am under the impression that JavaFX 2.x can be used to develop reasonably > complex and demanding visualisations including games, animations etc. and > that JavaFX 8+ will enable such visualisations to be 3D. > > > > However, as of yet, I have not seen any such advanced visualisations > anywhere. The animation samples in Ensemble are obviously very rudimentary > (probably intentionally) and I have not been able to find anything that I > would classify as complex, demanding or advanced anywhere on the internet. > > > > And this brings me to ask a few questions: > > > > 1. Do any such games, animations or visualisations exist yet? > > 2. If not, how does Oracle or anyone else actually know that JavaFX is > capable of supporting such applications? > > 3. Do I have the wrong understanding that JavaFX is supposed to support such > applications? > > 4. Is it possible that, for whatever reason, JavaFX is simply not capable of > supporting such applications? > > > > My feeling that JavaFX can indeed support such applications is based on the > fact that it is hardware accelerated and therefore it should be limited > mostly by the capabilities of the graphics card and also because it is often > talked about in this way. However, I have observed varying levels of > performance that don't quite follow these principles such as JavaFX > performing poorly with choppy/jittery animations and transitions on my most > powerful machine with an NVIDIA GeForce GTX 690 (the current fastest > graphics card in the world) but performing quite well on machines with much > lower specifications. > > > > So I guess I am curious to know what kinds of testing and evaluations Oracle > has undertaken to determine the performance characteristics of JavaFX and > exactly what kinds of applications it is actually suitable for. For > example, I am yet to see any JavaFX application with even the sophistication > of a Flash electronic greeting card or banner ad and yet I assume JavaFX > will be used for such purposes eventually. > > > > I'd appreciate comments from Oracle and anyone who has in fact developed > more complex visualisations/animations/games with JavaFX that aren't > publicly accessible. > > > > Thanks, > > > > -jct From richard.bair at oracle.com Wed Dec 5 09:29:39 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 5 Dec 2012 09:29:39 -0800 Subject: JavaFX Community Game project In-Reply-To: <1354718708.17474.YahooMailNeo@web161504.mail.bf1.yahoo.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <0850157A-4BA7-4D51-B1FF-04760ED0E4CA@gmail.com> <50BEE455.3080403@tbee.org> <50BF38FA.7000105@tbee.org> <1354718708.17474.YahooMailNeo@web161504.mail.bf1.yahoo.com> Message-ID: <71E06485-ED6E-45E9-9E15-83A6C83BE14E@oracle.com> I created a bitbucket repo: https://bitbucket.org/rbair/fx-games/overview I've invited Daniel & Jose as both have expressed interest, anybody else who wants to commit to it let me know. So at least we have somewhere to build the thing. As far as graphics, the easy thing is to go with bitmaps to start with. Oh, another option I thought about last night was we could build off of Dueling Dudes rather than a tower defense if you wanted. Whichever. Richard On Dec 5, 2012, at 6:45 AM, Jose Martinez wrote: > I have experience in this realm and would enjoy helping out and can learn a lot in the process. What it requires is a leader to head this. > > Besides the free graphics that Tom pointed out we might be able to get graphics donated in exchange for some free advertisement. > > thanks > jose > > > ________________________________ > From: Tom Eugelink > To: "openjfx-dev at openjdk.java.net" > Sent: Wednesday, December 5, 2012 7:07 AM > Subject: Re: JavaFX Community Game project > > On 2012-12-05 12:50, Daniel Zwolenski wrote: >> The main concern I would have is some nice slick graphics. > > There are some freely available graphics packages, like here: > http://www.lostgarden.com/2007/04/free-game-graphics-tyrian-ships-and.html > http://hasgraphics.com/remastered-tyrian-graphics/ > > Or here: > http://www.lostgarden.com/2005/03/download-complete-set-of-sweet-8-bit.html > > Or for some semi 3D: > http://hasgraphics.com/danc-planet-cute-tileset/ > > Tom From richard.bair at oracle.com Wed Dec 5 09:35:30 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 5 Dec 2012 09:35:30 -0800 Subject: JavaFX Community Game project In-Reply-To: <50BF38FA.7000105@tbee.org> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <0850157A-4BA7-4D51-B1FF-04760ED0E4CA@gmail.com> <50BEE455.3080403@tbee.org> <50BF38FA.7000105@tbee.org> Message-ID: <5E44E9F2-8AD6-441A-B096-E39FD5B60071@oracle.com> Quick google search brought up http://hasgraphics.com Interesting site, has links to explosion generators and such. On Dec 5, 2012, at 4:07 AM, Tom Eugelink wrote: > On 2012-12-05 12:50, Daniel Zwolenski wrote: >> The main concern I would have is some nice slick graphics. > > There are some freely available graphics packages, like here: > http://www.lostgarden.com/2007/04/free-game-graphics-tyrian-ships-and.html > http://hasgraphics.com/remastered-tyrian-graphics/ > > Or here: > http://www.lostgarden.com/2005/03/download-complete-set-of-sweet-8-bit.html > > Or for some semi 3D: > http://hasgraphics.com/danc-planet-cute-tileset/ > > Tom > From swpalmer at gmail.com Wed Dec 5 10:51:44 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 5 Dec 2012 13:51:44 -0500 Subject: JavaFX Community Game project In-Reply-To: <71E06485-ED6E-45E9-9E15-83A6C83BE14E@oracle.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <0850157A-4BA7-4D51-B1FF-04760ED0E4CA@gmail.com> <50BEE455.3080403@tbee.org> <50BF38FA.7000105@tbee.org> <1354718708.17474.YahooMailNeo@web161504.mail.bf1.yahoo.com> <71E06485-ED6E-45E9-9E15-83A6C83BE14E@oracle.com> Message-ID: <888006E6-D690-4962-80A4-3082A8793655@gmail.com> On 2012-12-05, at 12:29 PM, Richard Bair wrote: > I created a bitbucket repo: https://bitbucket.org/rbair/fx-games/overview > > I've invited Daniel & Jose as both have expressed interest, anybody else who wants to commit to it let me know. I'm interested. Scott From hang.vo at oracle.com Wed Dec 5 11:03:17 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 05 Dec 2012 19:03:17 +0000 Subject: hg: openjfx/8/graphics/rt: [JavaDoc] Added some missing doc comments on methods in TextInputControl Message-ID: <20121205190322.EB6E447E4B@hg.openjdk.java.net> Changeset: e941ae1fb3e5 Author: rbair Date: 2012-12-05 10:49 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e941ae1fb3e5 [JavaDoc] Added some missing doc comments on methods in TextInputControl ! javafx-ui-controls/src/javafx/scene/control/TextInputControl.java From swpalmer at gmail.com Wed Dec 5 11:35:11 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 5 Dec 2012 14:35:11 -0500 Subject: JavaFX Community Game project In-Reply-To: <71E06485-ED6E-45E9-9E15-83A6C83BE14E@oracle.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <0850157A-4BA7-4D51-B1FF-04760ED0E4CA@gmail.com> <50BEE455.3080403@tbee.org> <50BF38FA.7000105@tbee.org> <1354718708.17474.YahooMailNeo@web161504.mail.bf1.yahoo.com> <71E06485-ED6E-45E9-9E15-83A6C83BE14E@oracle.com> Message-ID: <7E7AE63D-5AC0-4FD2-B710-21E972D9D181@gmail.com> On 2012-12-05, at 12:29 PM, Richard Bair wrote: > I created a bitbucket repo: https://bitbucket.org/rbair/fx-games/overview > > I've invited Daniel & Jose as both have expressed interest, anybody else who wants to commit to it let me know. So at least we have somewhere to build the thing. > > As far as graphics, the easy thing is to go with bitmaps to start with. > > Oh, another option I thought about last night was we could build off of Dueling Dudes rather than a tower defense if you wanted. Whichever. > > Richard Since I'm interested in Path performance, I suggest an old-school vector-based Asteroids clone :-). No artistic skills required, the scene graph & transforms map nicely for all the animation, and we should see jet how smooth such a simple game will run as the number of objects on the screen increases. If we can't handle an old 8-bit game from the early 80's with nice fluid animations then we can give up and go home :-) Scott From hang.vo at oracle.com Wed Dec 5 12:17:09 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 05 Dec 2012 20:17:09 +0000 Subject: hg: openjfx/8/controls/rt: RT-24930: Add RTL support to ProgressIndicator and ProgressBar Message-ID: <20121205201713.E2C3947E64@hg.openjdk.java.net> Changeset: e76b08812540 Author: leifs Date: 2012-12-05 12:04 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e76b08812540 RT-24930: Add RTL support to ProgressIndicator and ProgressBar ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/javafx/scene/control/ProgressBar.java ! javafx-ui-controls/src/javafx/scene/control/ProgressIndicator.java From tom.schindl at bestsolution.at Wed Dec 5 16:38:04 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 06 Dec 2012 01:38:04 +0100 Subject: StyleManager#reloadStylesheets(Scene) replacement in FX8 In-Reply-To: <4CEF19C1-2B9F-4C85-A0BC-AC4F19735338@oracle.com> References: <50BA1713.7050607@bestsolution.at> <50BF2B35.7000502@bestsolution.at> <4CEF19C1-2B9F-4C85-A0BC-AC4F19735338@oracle.com> Message-ID: <50BFE8EC.7010202@bestsolution.at> Hi David, Interesting I think my problem is very special because when ever I reload my FXML-Preview I'm constructing a completely new scene and simply set a new scene on the Stage (well in my case it is an FXCanvas but that's not the real problem). I reduced the problem to the following: > public class MyCSSReloadTest extends Application { > > public static void main(String[] args) { > MyCSSReloadTest.launch(args); > } > > private Scene createScene(final Stage primaryStage) { > BorderPane p = new BorderPane(); > final Scene s = new Scene(p,400,400); > final String stylesheet = MyCSSReloadTest.class.getResource("my.css").toExternalForm(); > s.getStylesheets().add(stylesheet); > Button b = new Button("Reload "+ System.currentTimeMillis()); > b.setOnAction(new EventHandler() { > > @Override > public void handle(ActionEvent event) { > // s.getStylesheets().clear(); > primaryStage.setScene(createScene(primaryStage)); > } > }); > p.setCenter(b); > return s; > } > > @Override > public void start(Stage primaryStage) throws Exception { > primaryStage.setScene(createScene(primaryStage)); > primaryStage.show(); > } > > } if you uncomment thje s.getStylesheets().clear() the reloading works as expected. I'm not sure now if this is expected behavior for performance optimization you are not parsing the CSS when it is already on another although soon to be GC'ed scene. Tom Am 05.12.12 14:47, schrieb David Grieve: > Must be a bug. The code is intended to re-parse a stylesheet if it has been removed and re-added to the Scene (or Parent) stylesheets. > If you would create a bug, I will fix it ASAP. > > On Dec 5, 2012, at 6:08 AM, Tom Schindl wrote: > >> Hi David, >> >> I tested with the latest JRE8 and unfortunately this is not working. The >> CSS is only reloaded from the filesystem when the JVM is restarted, so >> the same caching as in 2.x is happening. >> >> Tom >> >> Am 03.12.12 18:13, schrieb David Grieve: >>> Remove and re-add the stylesheet. >>> >>> On Dec 1, 2012, at 9:41 AM, Tom Schindl wrote: >>> >>>> Hi, >>>> >>>> To force reloading of stylesheets I used in FX2.2 >>>> StyleManager.getInstance().reloadStylesheets(scene). What is the >>>> replacement of this in FX8. >>>> >>>> Tom >>>> >>>> -- >>>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>>> ------------------------------------------------------------------------ >>>> tom schindl gesch?ftsf?hrer/CEO >>>> ------------------------------------------------------------------------ >>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>>> http://www.BestSolution.at phone ++43 512 935834 >>> >> >> >> -- >> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >> ------------------------------------------------------------------------ >> tom schindl gesch?ftsf?hrer/CEO >> ------------------------------------------------------------------------ >> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >> http://www.BestSolution.at phone ++43 512 935834 > -- 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 Wed Dec 5 16:57:06 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 06 Dec 2012 01:57:06 +0100 Subject: [REVIEW REQUEST] RT-24088 Add API to JavaFX to allow vetoing the closing of a Tab in a TabPane Message-ID: <50BFED62.1070804@bestsolution.at> Hi, On behalf of Jonathan Giles and myself I'd like to request the review for a new api we'd like to add to javafx.scene.control.Tab. The API we propose is to allow developers to veto the closing of a Tab we'd like you to comment also on our naming pattern the new API we propose is: + ObjectProperty> onClosingVetoHandlerProperty() + Callback getOnClosingVetoHandler() + void setOnClosingVetoHandler(Callback callback) Usage of the API would look like this: Tab tab1 = new Tab("Hello"); tab1.setOnClosingVetoHandler(new Callback() { @Override public Boolean call(Tab param) { // Veto the closing return Boolean.TRUE; } }); Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From hang.vo at oracle.com Wed Dec 5 17:03:04 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 06 Dec 2012 01:03:04 +0000 Subject: hg: openjfx/8/controls/rt: 16 new changesets Message-ID: <20121206010327.1624247EE3@hg.openjdk.java.net> Changeset: 73632e466060 Author: jgiles Date: 2012-12-06 12:16 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/73632e466060 Removing redundant com.sun.javafx.scene.control.WeakEventHandler, and replacing usages with javafx.event.WeakEventHandler instances. - javafx-ui-controls/src/com/sun/javafx/scene/control/WeakEventHandler.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java Changeset: eefd03e1ae97 Author: jgiles Date: 2012-12-06 12:18 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/eefd03e1ae97 Fixing issue in MultipleSelectionModelBase where a boolean test was being duplicated needlessly. ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java Changeset: 96c299db643a Author: jgiles Date: 2012-12-06 12:20 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/96c299db643a Findbugs: Redundant nullcheck of value known to be non-null in TableView. ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: bdd29e62d47c Author: jgiles Date: 2012-12-06 12:22 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bdd29e62d47c Findbugs: Boxed value is unboxed and then immediately reboxed in CheckBoxTreeItem. ! javafx-ui-controls/src/javafx/scene/control/CheckBoxTreeItem.java Changeset: 3294d1b3ce3d Author: jgiles Date: 2012-12-06 12:32 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3294d1b3ce3d Findbugs: Unwritten field in TextField*Cell classes for textField field. ! javafx-ui-controls/src/javafx/scene/control/cell/CellUtils.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeTableCell.java Changeset: a8a1dfc873f4 Author: jgiles Date: 2012-12-06 12:41 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a8a1dfc873f4 Findbugs: Redundant nullcheck of value known to be non-null in TreeTableView ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java Changeset: 152535ac19aa Author: jgiles Date: 2012-12-06 12:42 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/152535ac19aa Findbugs: Unused fields in TabPane ! javafx-ui-controls/src/javafx/scene/control/TabPane.java Changeset: 078fb6f86f96 Author: jgiles Date: 2012-12-06 12:43 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/078fb6f86f96 Findbugs: Redundant nullcheck of value known to be non-null in TableView ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: 19e297131c24 Author: jgiles Date: 2012-12-06 13:00 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/19e297131c24 Findbugs: Dead store to local variable in ChoiceBoxSelectionModel ! javafx-ui-controls/src/javafx/scene/control/ChoiceBox.java Changeset: 242d2e2f26f6 Author: jgiles Date: 2012-12-06 13:12 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/242d2e2f26f6 Findbugs: Method call passes null for nonnull parameter in ContextMenu ! javafx-ui-controls/src/javafx/scene/control/ContextMenu.java Changeset: 2d9fb12395eb Author: jgiles Date: 2012-12-06 13:14 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2d9fb12395eb Findbugs: Redundant nullcheck of value known to be non-null in TreeTableView ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java Changeset: 5a40381a4c3d Author: jgiles Date: 2012-12-06 13:15 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5a40381a4c3d Findbugs: Dead store to local variable in TextArea ! javafx-ui-controls/src/javafx/scene/control/TextArea.java Changeset: fda395cfc7d6 Author: jgiles Date: 2012-12-06 13:17 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fda395cfc7d6 Findbugs: Dead store to local variable in PopupControl. ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 1a1d89cf5390 Author: jgiles Date: 2012-12-06 13:40 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1a1d89cf5390 Findbugs: Redundant nullcheck of value known to be non-null in TreeCellSkin. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java Changeset: ed94b6913f66 Author: jgiles Date: 2012-12-06 13:51 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ed94b6913f66 Findbugs: Redundant nullcheck of value known to be non-null in VirtualFlow. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 8a90d8a34b74 Author: jgiles Date: 2012-12-06 13:57 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8a90d8a34b74 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt - javafx-ui-controls/src/com/sun/javafx/scene/control/WeakEventHandler.java From richard.bair at oracle.com Wed Dec 5 17:23:41 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 5 Dec 2012 17:23:41 -0800 Subject: [REVIEW REQUEST] RT-24088 Add API to JavaFX to allow vetoing the closing of a Tab in a TabPane In-Reply-To: <50BFED62.1070804@bestsolution.at> References: <50BFED62.1070804@bestsolution.at> Message-ID: <1E18CAA8-E016-4A5F-8B5D-2285D465B980@oracle.com> +1 to the API, not sure on the name. I'm just looking at http://docs.oracle.com/javafx/2/api/javafx/scene/web/WebEngine.html, where there are callbacks with "Handler" in the name. I wonder if just "closeVetoHandler" would be more consistent with this naming convention? Are there any other places in the API where we have this kind of callback? We have callbacks that are used as factories, and in WebEngine we have callbacks that are used as responses to "events". Are there other such places we can draw from to find a consistent nomenclature / convention? Richard On Dec 5, 2012, at 4:57 PM, Tom Schindl wrote: > Hi, > > On behalf of Jonathan Giles and myself I'd like to request the review > for a new api we'd like to add to javafx.scene.control.Tab. > > The API we propose is to allow developers to veto the closing of a Tab > we'd like you to comment also on our naming pattern the new API we > propose is: > > + ObjectProperty> onClosingVetoHandlerProperty() > + Callback getOnClosingVetoHandler() > + void setOnClosingVetoHandler(Callback callback) > > Usage of the API would look like this: > > Tab tab1 = new Tab("Hello"); > tab1.setOnClosingVetoHandler(new Callback() { > > @Override > public Boolean call(Tab param) { > // Veto the closing > return Boolean.TRUE; > } > }); > > > 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 david.grieve at oracle.com Wed Dec 5 18:10:35 2012 From: david.grieve at oracle.com (David Grieve) Date: Wed, 5 Dec 2012 21:10:35 -0500 Subject: Soliciting comments on CSS API to support custom UI Controls Message-ID: <459639E8-9231-49A3-ACE2-4C15B01CBA40@oracle.com> Relative to http://javafx-jira.kenai.com/browse/RT-21709, I have posted a proposed CSS API to support the development of custom UI Controls. The proposal covers the API needed to make a JavaFX property styleable through CSS and the API for creating pseudo-class state. The proposal may be found at https://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls. Please take a moment to review the document and provide feedback. Thank you. From david.dehaven at oracle.com Wed Dec 5 19:23:11 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 5 Dec 2012 19:23:11 -0800 Subject: JavaFX Community Game project In-Reply-To: <71E06485-ED6E-45E9-9E15-83A6C83BE14E@oracle.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <0850157A-4BA7-4D51-B1FF-04760ED0E4CA@gmail.com> <50BEE455.3080403@tbee.org> <50BF38FA.7000105@tbee.org> <1354718708.17474.YahooMailNeo@web161504.mail.bf1.yahoo.com> <71E06485-ED6E-45E9-9E15-83A6C83BE14E@oracle.com> Message-ID: <3AC27171-197E-46B5-A915-AA27B0C2D85C@oracle.com> > I created a bitbucket repo: https://bitbucket.org/rbair/fx-games/overview > > I've invited Daniel & Jose as both have expressed interest, anybody else who wants to commit to it let me know. So at least we have somewhere to build the thing. > > As far as graphics, the easy thing is to go with bitmaps to start with. > > Oh, another option I thought about last night was we could build off of Dueling Dudes rather than a tower defense if you wanted. Whichever. YADFC! (Yet Another Dwarf Fortress Clone) -DrD- From david.dehaven at oracle.com Wed Dec 5 19:25:20 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 5 Dec 2012 19:25:20 -0800 Subject: JavaFX Community Game project In-Reply-To: <3AC27171-197E-46B5-A915-AA27B0C2D85C@oracle.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <0850157A-4BA7-4D51-B1FF-04760ED0E4CA@gmail.com> <50BEE455.3080403@tbee.org> <50BF38FA.7000105@tbee.org> <1354718708.17474.YahooMailNeo@web161504.mail.bf1.yahoo.com> <71E06485-ED6E-45E9-9E15-83A6C83BE14E@oracle.com> <3AC27171-197E-46B5-A915-AA27B0C2D85C@oracle.com> Message-ID: <901F3581-4BF8-4A0F-87D4-BB94A9C885A4@oracle.com> >> I created a bitbucket repo: https://bitbucket.org/rbair/fx-games/overview >> >> I've invited Daniel & Jose as both have expressed interest, anybody else who wants to commit to it let me know. So at least we have somewhere to build the thing. >> >> As far as graphics, the easy thing is to go with bitmaps to start with. >> >> Oh, another option I thought about last night was we could build off of Dueling Dudes rather than a tower defense if you wanted. Whichever. > > YADFC! > > (Yet Another Dwarf Fortress Clone) Or simply: Duke Fortress! -Dr "bring on the trolls!" D- From tbee at tbee.org Wed Dec 5 22:08:22 2012 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 06 Dec 2012 07:08:22 +0100 Subject: [REVIEW REQUEST] RT-24088 Add API to JavaFX to allow vetoing the closing of a Tab in a TabPane In-Reply-To: <50BFED62.1070804@bestsolution.at> References: <50BFED62.1070804@bestsolution.at> Message-ID: <50C03656.6020903@tbee.org> Just a remark to see if we can make this more reusable; would it be an idea to actually veto the close action? Like veto the removal of a tab from a list? In that way veto-ing would be available to other usages of such lists as well, a uniform API. Tom On 2012-12-06 01:57, Tom Schindl wrote: > Hi, > > On behalf of Jonathan Giles and myself I'd like to request the review > for a new api we'd like to add to javafx.scene.control.Tab. > > The API we propose is to allow developers to veto the closing of a Tab > we'd like you to comment also on our naming pattern the new API we > propose is: > > + ObjectProperty> onClosingVetoHandlerProperty() > + Callback getOnClosingVetoHandler() > + void setOnClosingVetoHandler(Callback callback) > > Usage of the API would look like this: > > Tab tab1 = new Tab("Hello"); > tab1.setOnClosingVetoHandler(new Callback() { > > @Override > public Boolean call(Tab param) { > // Veto the closing > return Boolean.TRUE; > } > }); > > > Tom > From ozemale at ozemail.com.au Thu Dec 6 00:34:13 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Thu, 6 Dec 2012 19:34:13 +1100 Subject: JavaFX performance for complex visualisations In-Reply-To: <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> Message-ID: <001501cdd38c$790782f0$6b1688d0$@com.au> Thanks for responding to this Richard. The smoothness issue is a bit baffling. On my desktop PC (which is virtually a super computer and includes the world's fastest GPU), all the animations in Ensemble are very "unsmooth", that is to say that even the simple Translate transition demo displays a jumpy red ball moving from side to side. It's so jumpy that it looks like I am actually running it on a hand-held calculator or similar! Conversely, the same demo on my 5-year-old laptop is "super smooth" and indeed all the Ensemble demos run extremely impressively on this machine. Do you have any ideas on what is causing this and/or suggestions on how to improve things? Anyway, I am very excited by the question you posed at the end of your reply in relation to building a graphics intensive demo application with JavaFX. Another thread has started dealing with the type of game or application that would be suitable but the thing for me which is most important is that this demo *not* be a clone of some simple existing game but rather be truly graphics intensive and demanding. One suggestion was to re-implement Asteroids because "If we can't handle an old 8-bit game from the early 80's with nice fluid animations then we can give up and go home" but to me this would be exactly what *not* to do. The idea that JavaFX should be capable of fluid animations for an old style game is fine but what have we proved if the app does indeed run smoothly using JavaFX? Nothing really. We *must* focus on something which would not have run on an old 8-bit computer. Something that would test Flash today on reasonably powered modern machines. Something that actually *requires* a UI toolkit as powerful and advanced as JavaFX (or is supposed to be). Otherwise we have not achieved anything. Whatever is chosen, I will contribute in any way I can :-) -jct -----Original Message----- From: Richard Bair [mailto:richard.bair at oracle.com] Sent: Wednesday, 5 December 2012 07:24 To: John C. Turnbull Cc: openjfx-dev at openjdk.java.net Subject: Re: JavaFX performance for complex visualisations Hi John, Just getting through my email and have had this one flagged since Devoxx :-). I respond below to individual points but most of these are probably not worth you responding back on (they're just informational on my part) -- rather, down at the end is the real question I want to have a discussion on (and will be a lot of fun to solve while we're at it). > 1. Do any such games, animations or visualisations exist yet? Yes. Much like Swing, JavaFX is seeing a lot of adoption in the heavy enterprise desktop sorts of use cases -- not the kind of thing you will find when browsing the internet. Most of these folks don't advertise the technology they're using, and most of them are not interested in letting their competitors know what they're doing or what technology they're using. Which basically means, if we haven't built a demo for it, there isn't anything you will find in your travels. > 2. If not, how does Oracle or anyone else actually know that JavaFX is > capable of supporting such applications? That is a good question. Many of the folks I've talked to building such applications have done incredible work + proof of concepts long before I even knew they were using JavaFX. Now, each year we do pretty graphically intense demos for JavaOne, so we have a pretty good feel for it. We have a bunch of benchmarks where we crank the number of nodes up to pretty high numbers, and we know from these benchmarks (at least) that we scale very well compared to other technologies. But I know neither the samples nor the results are publicly available. But at least I can answer the "how does Oracle . know" part of the question. We have had a performance team from the get-go who were solely dedicated to writing benchmarks, running benchmarks, and analyzing results. This has been incredibly helpful. We have results that come not just from the weekly integrations but even from intra-week builds on specific scrum repositories. We have benchmarks and analysis for both desktop and embedded and take performance very seriously. Now, there are a lot of ways to use the platform. Some things are better tuned than others. Performance work is driven by tuning and benchmarks. So when we run into issues we have to (a) determine how likely that is to be an issue to the broader development community (b) figure out what the tradeoffs are (usually performance & quality are directly in contradiction with each other), and ( c) schedule & implement the fix. Of course, the same few people (Jim, mostly) are involved in many of the performance fixes and features (like Canvas), so scheduling is an issue and feedback from customers as to what they are actually running into (vs. what a theoretical issue is) has priority. > 3. Do I have the wrong understanding that JavaFX is supposed to > support such applications? We expect that JavaFX will be usable for casual games, but we are not building a gaming platform to compete with Unity and the like. If we happen to be just as good, then that's awesome, but it isn't our primary goal. Advanced visualizations, on the other hand, are part of our target market (medical, pharma, enterprise desktop, etc) > 4. Is it possible that, for whatever reason, JavaFX is simply not > capable of supporting such applications? There are natural trade-offs between an immediate mode (like Canvas) API and a retained mode (like Scene Graph) API. Now that we have both (plus Java2D + ImageWriter and such for the really crazy cases) we should be capable of a wide range of use cases. However, some things are not yet optimized. But there is no technical reason why we shouldn't be quite capable. Another area we have not yet exposed API which is problematic for some people is in the area of custom shaders. It may be that without some kind of custom shader support (which would have to be made to work on D3D as well as OpenGL) certain use cases cannot be easily fulfilled. > My feeling that JavaFX can indeed support such applications is based > on the fact that it is hardware accelerated and therefore it should be > limited mostly by the capabilities of the graphics card and also > because it is often talked about in this way. However, I have > observed varying levels of performance that don't quite follow these > principles such as JavaFX performing poorly with choppy/jittery > animations and transitions on my most powerful machine with an NVIDIA > GeForce GTX 690 (the current fastest graphics card in the world) but > performing quite well on machines with much lower specifications. It is highly unlikely that this is due to performance issues. As mentioned in the last few days on another thread, there are smoothness issues that are completely separate from performance (although both are often talked about together). We're working on the smoothness. Sometimes this is an application problem as opposed to a platform problem (one such example is the DisplayShelf sample, which needs to be rewritten). > So I guess I am curious to know what kinds of testing and evaluations > Oracle has undertaken to determine the performance characteristics of > JavaFX and exactly what kinds of applications it is actually suitable > for. For example, I am yet to see any JavaFX application with even > the sophistication of a Flash electronic greeting card or banner ad > and yet I assume JavaFX will be used for such purposes eventually. I would imagine any of our demos from the last 3-4 years of JavaOne would demonstrate much more complicated use cases than that! But, instead of me just complaining -- lets build one! We'll add it both to Ensemble and our test suite. We can start with something simple (like a greeting card) and expand it out to something wildly complex. What would you like to see? One thing I've wanted to build for years but haven't found the time for was a tower defense game. But what would you think would be a good example of graphics performance that would tell you "hey, this platform is great for visualizations"? Richard From hang.vo at oracle.com Thu Dec 6 01:04:33 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 06 Dec 2012 09:04:33 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121206090439.9B8BE47EFE@hg.openjdk.java.net> Changeset: 4daba9576a3b Author: Martin Sladecek Date: 2012-12-06 09:48 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4daba9576a3b RT-26518 Children of Sequential and Parallel Transition should be controlled only through their parent + Sequential Transition test & fixes ! javafx-ui-common/nbproject/project.xml ! javafx-ui-common/src/javafx/animation/ParallelTransition.java ! javafx-ui-common/src/javafx/animation/SequentialTransition.java ! javafx-ui-common/src/javafx/animation/Transition.java + javafx-ui-common/test/unit/javafx/animation/AbstractMasterTimerMock.java + javafx-ui-common/test/unit/javafx/animation/SequentialTransitionPlayTest.java Changeset: 218967f4a7a7 Author: Martin Sladecek Date: 2012-12-06 09:49 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/218967f4a7a7 merge From lehmann at media-interactive.de Thu Dec 6 03:20:41 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Thu, 6 Dec 2012 12:20:41 +0100 Subject: How to reach retina support In-Reply-To: <81230380-97BD-4951-9CE2-9E2254103456@oracle.com> References: <411E73D23DEC4C46BA48F2B6D8BF3D22160AD6A2AC@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <81230380-97BD-4951-9CE2-9E2254103456@oracle.com> Message-ID: <50C07F89.8050908@media-interactive.de> Well, that is a problem we were facing on Windows even without retina. I remember one case when a togglebutton with width=150px would have a 2px gray border when it should have been 1px black. SnapToPixel did not help. Changing the width to 151px did the trick. There were other cases, too (which I don't remember exactly). Werner On 05.12.2012 01:00, Richard Bair wrote: > You position at 100 thinking it will be crisp but it ends up at some fractional position instead. From lehmann at media-interactive.de Thu Dec 6 03:32:23 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Thu, 6 Dec 2012 12:32:23 +0100 Subject: [REVIEW REQUEST] RT-24088 Add API to JavaFX to allow vetoing the closing of a Tab in a TabPane In-Reply-To: <50C03656.6020903@tbee.org> References: <50BFED62.1070804@bestsolution.at> <50C03656.6020903@tbee.org> Message-ID: <50C08247.2060600@media-interactive.de> Would it also be possible to have a simple onClosing event and require a handler to Event.consume() it? Maybe slightly less obvious than an explicit "*veto*" but more flexible/resuable, too (as a general pattern in similar situations). Werner On 06.12.2012 07:08, Tom Eugelink wrote: > Just a remark to see if we can make this more reusable; would it be > an idea to actually veto the close action? Like veto the removal of a > tab from a list? In that way veto-ing would be available to other > usages of such lists as well, a uniform API. > > Tom From alexandre.iline at oracle.com Thu Dec 6 04:16:35 2012 From: alexandre.iline at oracle.com (alexandre.iline at oracle.com) Date: Thu, 06 Dec 2012 12:16:35 +0000 Subject: hg: openjfx/2.2/master/tests: 6 new changesets Message-ID: <20121206121636.5582047F0A@hg.openjdk.java.net> Changeset: ea44b6b5db42 Author: Oleg Barbashov Date: 2012-10-16 21:11 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/ea44b6b5db42 JemmyFX: WebView wrap + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/webview/WebViewApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/webview/WebViewSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/webview/button.html ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrapper.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebNodeParent.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebNodeWrap.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebViewWrap.java + tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/WebViewApp.java + tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/WebViewTest.java + tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/button.html Changeset: d6cb0fee1422 Author: Oleg Barbashov Date: 2012-10-16 21:17 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/d6cb0fee1422 JemmyFX: version update ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/jemmy.properties Changeset: 49816bcead4f Author: Oleg Barbashov Date: 2012-10-23 14:26 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/49816bcead4f JemmyFX: WebNodeWrap ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/webview/WebViewSample.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebNodeParent.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebNodeWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebViewWrap.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/WebViewTest.java Changeset: 527f9a799850 Author: Oleg Barbashov Date: 2012-10-23 16:18 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/527f9a799850 JemmyFX: WebWiew wrap ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/webview/WebViewSample.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebNodeWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebViewWrap.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/WebViewTest.java Changeset: 12daa64a9797 Author: Andrey Nazarov Date: 2012-10-26 13:35 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/12daa64a9797 Added SceneBuilderTets + bigapps/SceneBuilderTest/README + bigapps/SceneBuilderTest/build.xml + bigapps/SceneBuilderTest/manifest.mf + bigapps/SceneBuilderTest/nbproject/build-impl.xml + bigapps/SceneBuilderTest/nbproject/configs/Run_as_WebStart.properties + bigapps/SceneBuilderTest/nbproject/configs/Run_in_Browser.properties + bigapps/SceneBuilderTest/nbproject/genfiles.properties + bigapps/SceneBuilderTest/nbproject/jfx-impl.xml + bigapps/SceneBuilderTest/nbproject/project.properties + bigapps/SceneBuilderTest/nbproject/project.xml + bigapps/SceneBuilderTest/src/scenebuilder/RunGUIBrowser.java + bigapps/SceneBuilderTest/test/scenebuildertest/SceneBuilderTest.java Changeset: 855f5d687f73 Author: Stanislav Smirnov Date: 2012-11-09 16:45 +0400 URL: http://hg.openjdk.java.net/openjfx/2.2/master/tests/rev/855f5d687f73 JemmyFX: Update for embedded needs ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrapper.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/Root.java From alexandre.iline at oracle.com Thu Dec 6 04:43:47 2012 From: alexandre.iline at oracle.com (alexandre.iline at oracle.com) Date: Thu, 06 Dec 2012 12:43:47 +0000 Subject: hg: openjfx/8/master/tests: 36 new changesets Message-ID: <20121206124352.374E647F0C@hg.openjdk.java.net> Changeset: 7abb34b0a3a9 Author: Stanislav Smirnov Date: 2012-08-29 17:45 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/7abb34b0a3a9 robot buttons for 8.0 ! tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/DefaultGlassInputMap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/KnobTrackScrollerImpl.java Changeset: 66493126b628 Author: Alexandre (Shura) Iline Date: 2012-08-26 23:36 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/66493126b628 Using jfxrt.jar from where it is. Not copying the jar and the libs. ! tools/Jemmy/GlassImage/build.xml ! tools/Jemmy/GlassImage/nbproject/build-impl.xml ! tools/Jemmy/GlassImage/nbproject/genfiles.properties ! tools/Jemmy/GlassImage/nbproject/project.properties ! tools/Jemmy/GlassRobot/build.xml ! tools/Jemmy/GlassRobot/nbproject/project.properties ! tools/Jemmy/JemmyFX/build.xml ! tools/Jemmy/JemmyFX/depend.properties - tools/Jemmy/JemmyFX/fxclasspath.properties ! tools/Jemmy/JemmyFX/nbproject/build-impl.xml + tools/Jemmy/JemmyFX/nbproject/build-impl.xml~ ! tools/Jemmy/JemmyFX/nbproject/genfiles.properties ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFX/nbproject/project.xml ! tools/Jemmy/JemmyFXBrowser/build.xml ! tools/Jemmy/JemmyFXBrowser/nbproject/build-impl.xml ! tools/Jemmy/JemmyFXBrowser/nbproject/genfiles.properties ! tools/Jemmy/JemmyFXBrowser/nbproject/project.properties ! tools/Jemmy/README Changeset: 19e77063f2b2 Author: Alexandre (Shura) Iline Date: 2012-08-26 23:53 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/19e77063f2b2 missed script + tools/Jemmy/JemmyFX/detect_javafx.xml Changeset: 3c621ca78661 Author: Shura Date: 2012-08-26 13:24 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/3c621ca78661 removed the hardcode ! tools/Jemmy/JemmyFX/detect_javafx.xml ! tools/Jemmy/JemmyFX/nbproject/project.properties Changeset: 46a55e5fdb20 Author: Alexandre (Shura) Iline Date: 2012-08-27 00:31 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/46a55e5fdb20 fixed JemmyBrowser ! tools/Jemmy/JemmyFXBrowser/build.xml ! tools/Jemmy/JemmyFXBrowser/nbproject/project.properties Changeset: 64a5546ad0b7 Author: Alexandre (Shura) Iline Date: 2012-08-27 23:00 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/64a5546ad0b7 Saving fx home into private.properties ! tools/Jemmy/GlassImage/nbproject/project.properties ! tools/Jemmy/GlassRobot/nbproject/project.properties ! tools/Jemmy/JemmyFX/build.xml ! tools/Jemmy/JemmyFX/detect_javafx.xml ! tools/Jemmy/JemmyFX/nbproject/build-impl.xml - tools/Jemmy/JemmyFX/nbproject/build-impl.xml~ ! tools/Jemmy/JemmyFX/nbproject/genfiles.properties ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFX/nbproject/project.xml ! tools/Jemmy/JemmyFXBrowser/nbproject/project.properties ! tools/Jemmy/README Changeset: 7b7afbf80e99 Author: Alexandre (Shura) Iline Date: 2012-08-28 12:58 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/7b7afbf80e99 merge ! tools/Jemmy/JemmyFX/detect_javafx.xml ! tools/Jemmy/JemmyFX/nbproject/project.properties Changeset: 1ce7155686e9 Author: OGB at MacMiniAllInOne.ru.oracle.com Date: 2012-08-28 18:42 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/1ce7155686e9 Minor fixes ! tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/GlassInputFactory.java ! tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/GlassKeyboard.java ! tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/GlassMouse.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrapper.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/SceneWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/MenuButtonWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/MenuItemWrap.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/SplitMenuButtonWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TreeImpl.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TreeItemParent.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TreeItemWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TreeNodeParent.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TreeNodeWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TreeViewWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/CaspianDriverFactory.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/SplitMenuButton.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/TreeItem.java ! tools/Jemmy/JemmyFX/src/org/jemmy/input/ScrollTrack.java Changeset: 286f25fbe2e9 Author: Oleg Barbashov Date: 2012-08-29 02:10 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/286f25fbe2e9 Minor fixes ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/SplitMenuButtonWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ThemeDriverFactory.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TreeItemWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TreeNodeWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/CaspianDriverFactory.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/SplitMenuButtonImpl.java < tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/SplitMenuButton.java + tools/Jemmy/JemmyFX/src/org/jemmy/interfaces/SplitMenuButton.java Changeset: ca104b158385 Author: Oleg Barbashov Date: 2012-08-29 19:25 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/ca104b158385 Minor fixes ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/MenuButtonWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/SplitMenuButtonWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ThemeDriverFactory.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/CaspianDriverFactory.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/SplitMenuButtonImpl.java - tools/Jemmy/JemmyFX/src/org/jemmy/interfaces/SplitMenuButton.java Changeset: be3fa46e7761 Author: Oleg Barbashov Date: 2012-08-31 14:38 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/be3fa46e7761 Minor fixes ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/SplitMenuButtonWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ThemeDriverFactory.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/CaspianDriverFactory.java - tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/SplitMenuButtonImpl.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/jemmy.properties Changeset: 215165b18fa2 Author: Sergey Grinev Date: 2012-09-04 13:47 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/215165b18fa2 Automated merge with file:///export/WS/openjfx-2.2-master-tests Changeset: d2360ed626ae Author: Victor Shubov Date: 2012-09-19 17:08 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/d2360ed626ae fix http://javafx-jira.kenai.com/browse/JMY-189 ! tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/GlassMouse.java Changeset: 151777893b48 Author: Victor Shubov Date: 2012-10-08 19:00 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/151777893b48 I need the way to create GlassImage from Pixels (see http://javafx-jira.kenai.com/browse/RT-25537) ! tools/Jemmy/GlassImage/src/org/jemmy/image/GlassImage.java Changeset: 9ccc4ef07681 Author: Alexandre (Shura) Iline Date: 2012-09-14 08:41 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/9ccc4ef07681 minor javadoc fix ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/Lookups.java Changeset: 5a7f6570f942 Author: Oleg Barbashov Date: 2012-09-04 18:59 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/5a7f6570f942 Minor fix (FX 8.0 compatibility) ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/KnobTrackScrollerImpl.java Changeset: 459d925fe54b Author: Andrey Nazarov Date: 2012-09-07 10:59 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/459d925fe54b fixed NPE in text input control wrap ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TextInputControlWrap.java Changeset: e115d536da4a Author: Oleg Barbashov Date: 2012-09-03 19:48 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/e115d536da4a Minor fix ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/Root.java Changeset: 334de72d1d03 Author: Oleg Barbashov Date: 2012-09-05 18:05 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/334de72d1d03 Merge Changeset: 730bef31c198 Author: Oleg Barbashov Date: 2012-09-10 19:41 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/730bef31c198 JemmyFX: minor fixes ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/Root.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/AccordionApp.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/AccordionTest.java Changeset: a284d8c358bf Author: Oleg Barbashov Date: 2012-09-10 19:45 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/a284d8c358bf Merge Changeset: 07b6ebe91258 Author: Oleg Barbashov Date: 2012-09-10 20:05 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/07b6ebe91258 JemmyFX: reverting workaround ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/Root.java Changeset: 724a1b0f2314 Author: Oleg Barbashov Date: 2012-09-11 16:14 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/724a1b0f2314 JemmyFX: version increasing ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/jemmy.properties Changeset: 756a40f0a4f7 Author: Alexandre (Shura) Iline Date: 2012-09-14 08:43 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/756a40f0a4f7 merge Changeset: a0039f95811e Author: Alexandre (Shura) Iline Date: 2012-09-14 08:50 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/a0039f95811e E2E sample + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/explorer/E2ESample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/explorer/Explorer.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/explorer/ExplorerSampleBase.java Changeset: 3a8b7459ad0a Author: Alexandre (Shura) Iline Date: 2012-09-28 14:28 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/3a8b7459ad0a More samples. CriteriaSelectable ! tools/Jemmy/JemmyFX/depend.properties ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/combobox/ComboBoxSample.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/explorer/ExplorerSampleBase.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/index.html + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/listview/ListViewApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/listview/ListViewSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/tableview/TableViewApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/tableview/TableViewSample.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/SceneWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/ComboBoxWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/TableCellItemParent.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/jemmy.properties + tools/Jemmy/JemmyFX/src/org/jemmy/interfaces/CriteriaSelectable.java Changeset: 76955ba72ada Author: Victor Shubov Date: 2012-09-20 18:50 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/76955ba72ada fix http://javafx-jira.kenai.com/browse/JMY-189 ! tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/GlassMouse.java Changeset: ada1c4107f40 Author: Alexandre (Shura) Iline Date: 2012-09-29 08:11 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/ada1c4107f40 merge Changeset: ea44b6b5db42 Author: Oleg Barbashov Date: 2012-10-16 21:11 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/ea44b6b5db42 JemmyFX: WebView wrap + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/webview/WebViewApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/webview/WebViewSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/webview/button.html ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrapper.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebNodeParent.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebNodeWrap.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebViewWrap.java + tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/WebViewApp.java + tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/WebViewTest.java + tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/button.html Changeset: d6cb0fee1422 Author: Oleg Barbashov Date: 2012-10-16 21:17 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/d6cb0fee1422 JemmyFX: version update ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/jemmy.properties Changeset: 49816bcead4f Author: Oleg Barbashov Date: 2012-10-23 14:26 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/49816bcead4f JemmyFX: WebNodeWrap ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/webview/WebViewSample.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebNodeParent.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebNodeWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebViewWrap.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/WebViewTest.java Changeset: 527f9a799850 Author: Oleg Barbashov Date: 2012-10-23 16:18 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/527f9a799850 JemmyFX: WebWiew wrap ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/webview/WebViewSample.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebNodeWrap.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebViewWrap.java ! tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/WebViewTest.java Changeset: 12daa64a9797 Author: Andrey Nazarov Date: 2012-10-26 13:35 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/12daa64a9797 Added SceneBuilderTets + bigapps/SceneBuilderTest/README + bigapps/SceneBuilderTest/build.xml + bigapps/SceneBuilderTest/manifest.mf + bigapps/SceneBuilderTest/nbproject/build-impl.xml + bigapps/SceneBuilderTest/nbproject/configs/Run_as_WebStart.properties + bigapps/SceneBuilderTest/nbproject/configs/Run_in_Browser.properties + bigapps/SceneBuilderTest/nbproject/genfiles.properties + bigapps/SceneBuilderTest/nbproject/jfx-impl.xml + bigapps/SceneBuilderTest/nbproject/project.properties + bigapps/SceneBuilderTest/nbproject/project.xml + bigapps/SceneBuilderTest/src/scenebuilder/RunGUIBrowser.java + bigapps/SceneBuilderTest/test/scenebuildertest/SceneBuilderTest.java Changeset: 855f5d687f73 Author: Stanislav Smirnov Date: 2012-11-09 16:45 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/855f5d687f73 JemmyFX: Update for embedded needs ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrapper.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/Root.java Changeset: dac3c64731c4 Author: Alexandre (Shura) Iline Date: 2012-12-06 16:21 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/dac3c64731c4 merge ! tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/GlassMouse.java ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/caspian/KnobTrackScrollerImpl.java Changeset: c2a7fc65dc81 Author: Alexandre (Shura) Iline Date: 2012-12-06 16:39 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/c2a7fc65dc81 JSObject moved ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebNodeWrap.java From tom.schindl at bestsolution.at Thu Dec 6 05:24:45 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 06 Dec 2012 14:24:45 +0100 Subject: [REVIEW REQUEST] RT-24088 Add API to JavaFX to allow vetoing the closing of a Tab in a TabPane In-Reply-To: <50C03656.6020903@tbee.org> References: <50BFED62.1070804@bestsolution.at> <50C03656.6020903@tbee.org> Message-ID: <50C09C9D.3060006@bestsolution.at> Hi, The problem with having the veto on the ObservableList is that it is quite likely that most the cleanup code you run on the widget is most likely already run so that the widget would be left in an inconsitent state. Tom Am 06.12.12 07:08, schrieb Tom Eugelink: > Just a remark to see if we can make this more reusable; would it be an > idea to actually veto the close action? Like veto the removal of a tab > from a list? In that way veto-ing would be available to other usages of > such lists as well, a uniform API. > > Tom > > > > On 2012-12-06 01:57, Tom Schindl wrote: >> Hi, >> >> On behalf of Jonathan Giles and myself I'd like to request the review >> for a new api we'd like to add to javafx.scene.control.Tab. >> >> The API we propose is to allow developers to veto the closing of a Tab >> we'd like you to comment also on our naming pattern the new API we >> propose is: >> >> + ObjectProperty> onClosingVetoHandlerProperty() >> + Callback getOnClosingVetoHandler() >> + void setOnClosingVetoHandler(Callback callback) >> >> Usage of the API would look like this: >> >> Tab tab1 = new Tab("Hello"); >> tab1.setOnClosingVetoHandler(new Callback() { >> >> @Override >> public Boolean call(Tab param) { >> // Veto the closing >> return Boolean.TRUE; >> } >> }); >> >> >> 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 Thu Dec 6 05:33:02 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 06 Dec 2012 14:33:02 +0100 Subject: [REVIEW REQUEST] RT-24088 Add API to JavaFX to allow vetoing the closing of a Tab in a TabPane In-Reply-To: <50C08247.2060600@media-interactive.de> References: <50BFED62.1070804@bestsolution.at> <50C03656.6020903@tbee.org> <50C08247.2060600@media-interactive.de> Message-ID: <50C09E8E.1090909@bestsolution.at> Hi, This is an interesting idea. I'm not that deep in the FX-API to understand if this the advised way in other areas so. I let Richard and Jonathan comment on it. Tom Am 06.12.12 12:32, schrieb Werner Lehmann: > Would it also be possible to have a simple onClosing event and require a > handler to Event.consume() it? Maybe slightly less obvious than an > explicit "*veto*" but more flexible/resuable, too (as a general pattern > in similar situations). > > Werner > > On 06.12.2012 07:08, Tom Eugelink wrote: >> Just a remark to see if we can make this more reusable; would it be >> an idea to actually veto the close action? Like veto the removal of a >> tab from a list? In that way veto-ing would be available to other >> usages of such lists as well, a uniform API. >> >> Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From david.grieve at oracle.com Thu Dec 6 07:08:46 2012 From: david.grieve at oracle.com (David Grieve) Date: Thu, 6 Dec 2012 10:08:46 -0500 Subject: StyleManager#reloadStylesheets(Scene) replacement in FX8 In-Reply-To: <50BFE8EC.7010202@bestsolution.at> References: <50BA1713.7050607@bestsolution.at> <50BF2B35.7000502@bestsolution.at> <4CEF19C1-2B9F-4C85-A0BC-AC4F19735338@oracle.com> <50BFE8EC.7010202@bestsolution.at> Message-ID: <9FF76185-5DEC-468E-8313-6FB88A9A9454@oracle.com> There is a static map that keeps track of stylesheets that have been parsed. When a stylesheet is removed from the Scene's stylesheets, the corresponding map entry is supposed to be removed. If the stylesheet is added back in again it will be re-parsed since it is no longer in the map. The bug is in removing the stylesheet from the map. Apparently I'm not using the right key. On Dec 5, 2012, at 7:38 PM, Tom Schindl wrote: > Hi David, > > Interesting I think my problem is very special because when ever I > reload my FXML-Preview I'm constructing a completely new scene and > simply set a new scene on the Stage (well in my case it is an FXCanvas > but that's not the real problem). > > I reduced the problem to the following: > >> public class MyCSSReloadTest extends Application { >> >> public static void main(String[] args) { >> MyCSSReloadTest.launch(args); >> } >> >> private Scene createScene(final Stage primaryStage) { >> BorderPane p = new BorderPane(); >> final Scene s = new Scene(p,400,400); >> final String stylesheet = MyCSSReloadTest.class.getResource("my.css").toExternalForm(); >> s.getStylesheets().add(stylesheet); >> Button b = new Button("Reload "+ System.currentTimeMillis()); >> b.setOnAction(new EventHandler() { >> >> @Override >> public void handle(ActionEvent event) { >> // s.getStylesheets().clear(); >> primaryStage.setScene(createScene(primaryStage)); >> } >> }); >> p.setCenter(b); >> return s; >> } >> >> @Override >> public void start(Stage primaryStage) throws Exception { >> primaryStage.setScene(createScene(primaryStage)); >> primaryStage.show(); >> } >> >> } > > > if you uncomment thje s.getStylesheets().clear() the reloading works as > expected. I'm not sure now if this is expected behavior for performance > optimization you are not parsing the CSS when it is already on another > although soon to be GC'ed scene. > > Tom > > Am 05.12.12 14:47, schrieb David Grieve: >> Must be a bug. The code is intended to re-parse a stylesheet if it has been removed and re-added to the Scene (or Parent) stylesheets. >> If you would create a bug, I will fix it ASAP. >> >> On Dec 5, 2012, at 6:08 AM, Tom Schindl wrote: >> >>> Hi David, >>> >>> I tested with the latest JRE8 and unfortunately this is not working. The >>> CSS is only reloaded from the filesystem when the JVM is restarted, so >>> the same caching as in 2.x is happening. >>> >>> Tom >>> >>> Am 03.12.12 18:13, schrieb David Grieve: >>>> Remove and re-add the stylesheet. >>>> >>>> On Dec 1, 2012, at 9:41 AM, Tom Schindl wrote: >>>> >>>>> Hi, >>>>> >>>>> To force reloading of stylesheets I used in FX2.2 >>>>> StyleManager.getInstance().reloadStylesheets(scene). What is the >>>>> replacement of this in FX8. >>>>> >>>>> Tom >>>>> >>>>> -- >>>>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>>>> ------------------------------------------------------------------------ >>>>> tom schindl gesch?ftsf?hrer/CEO >>>>> ------------------------------------------------------------------------ >>>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>>>> http://www.BestSolution.at phone ++43 512 935834 >>>> >>> >>> >>> -- >>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>> ------------------------------------------------------------------------ >>> tom schindl gesch?ftsf?hrer/CEO >>> ------------------------------------------------------------------------ >>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>> http://www.BestSolution.at phone ++43 512 935834 >> > > > -- > 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 david.grieve at oracle.com Thu Dec 6 07:17:03 2012 From: david.grieve at oracle.com (David Grieve) Date: Thu, 6 Dec 2012 10:17:03 -0500 Subject: [REVIEW-REQUEST] RT-21709 Consider making available the CSS Styleable* classes as public API Message-ID: <8927902E-376B-40C1-BC9F-40086D0CFE7A@oracle.com> Relative to http://javafx-jira.kenai.com/browse/RT-21709, I have posted a proposed CSS API to support the development of custom UI Controls. The proposal covers the API needed to make a JavaFX property styleable through CSS and the API for creating pseudo-class state. The proposal may be found athttps://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls. Please take a moment to review the document and provide feedback. Thank you. From tom.schindl at bestsolution.at Thu Dec 6 07:21:00 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 06 Dec 2012 16:21:00 +0100 Subject: StyleManager#reloadStylesheets(Scene) replacement in FX8 In-Reply-To: <9FF76185-5DEC-468E-8313-6FB88A9A9454@oracle.com> References: <50BA1713.7050607@bestsolution.at> <50BF2B35.7000502@bestsolution.at> <4CEF19C1-2B9F-4C85-A0BC-AC4F19735338@oracle.com> <50BFE8EC.7010202@bestsolution.at> <9FF76185-5DEC-468E-8313-6FB88A9A9454@oracle.com> Message-ID: <50C0B7DC.3060801@bestsolution.at> Hi David, Like I said, if i call e.g. clear on the old scene things work as expected so for people who add/remove stuff from the same scene the reloading is working. So I'm not sure if you are really useing the wrong key, I assume it is desired that the stylesheets are cached and reused on a scene base not? The below example works like a charme: > public class MyCSSReloadTest extends Application { > > public static void main(String[] args) { > MyCSSReloadTest.launch(args); > } > > private Scene createScene(final Stage primaryStage) { > BorderPane p = new BorderPane(); > final Scene s = new Scene(p,400,400); > final String stylesheet = MyCSSReloadTest.class.getResource("my.css").toExternalForm(); > s.getStylesheets().add(stylesheet); > Button b = new Button("Reload "+ System.currentTimeMillis()); > b.setOnAction(new EventHandler() { > > @Override > public void handle(ActionEvent event) { > s.getStylesheets().clear(); > s.getStylesheets().add(stylesheet); > } > }); > p.setCenter(b); > return s; > } > > @Override > public void start(Stage primaryStage) throws Exception { > primaryStage.setScene(createScene(primaryStage)); > primaryStage.show(); > } > > } Tom Am 06.12.12 16:08, schrieb David Grieve: > There is a static map that keeps track of stylesheets that have been parsed. When a stylesheet is removed from the Scene's stylesheets, the corresponding map entry is supposed to be removed. If the stylesheet is added back in again it will be re-parsed since it is no longer in the map. The bug is in removing the stylesheet from the map. Apparently I'm not using the right key. > > On Dec 5, 2012, at 7:38 PM, Tom Schindl wrote: > >> Hi David, >> >> Interesting I think my problem is very special because when ever I >> reload my FXML-Preview I'm constructing a completely new scene and >> simply set a new scene on the Stage (well in my case it is an FXCanvas >> but that's not the real problem). >> >> I reduced the problem to the following: >> >>> public class MyCSSReloadTest extends Application { >>> >>> public static void main(String[] args) { >>> MyCSSReloadTest.launch(args); >>> } >>> >>> private Scene createScene(final Stage primaryStage) { >>> BorderPane p = new BorderPane(); >>> final Scene s = new Scene(p,400,400); >>> final String stylesheet = MyCSSReloadTest.class.getResource("my.css").toExternalForm(); >>> s.getStylesheets().add(stylesheet); >>> Button b = new Button("Reload "+ System.currentTimeMillis()); >>> b.setOnAction(new EventHandler() { >>> >>> @Override >>> public void handle(ActionEvent event) { >>> // s.getStylesheets().clear(); >>> primaryStage.setScene(createScene(primaryStage)); >>> } >>> }); >>> p.setCenter(b); >>> return s; >>> } >>> >>> @Override >>> public void start(Stage primaryStage) throws Exception { >>> primaryStage.setScene(createScene(primaryStage)); >>> primaryStage.show(); >>> } >>> >>> } >> >> >> if you uncomment thje s.getStylesheets().clear() the reloading works as >> expected. I'm not sure now if this is expected behavior for performance >> optimization you are not parsing the CSS when it is already on another >> although soon to be GC'ed scene. >> >> Tom >> >> Am 05.12.12 14:47, schrieb David Grieve: >>> Must be a bug. The code is intended to re-parse a stylesheet if it has been removed and re-added to the Scene (or Parent) stylesheets. >>> If you would create a bug, I will fix it ASAP. >>> >>> On Dec 5, 2012, at 6:08 AM, Tom Schindl wrote: >>> >>>> Hi David, >>>> >>>> I tested with the latest JRE8 and unfortunately this is not working. The >>>> CSS is only reloaded from the filesystem when the JVM is restarted, so >>>> the same caching as in 2.x is happening. >>>> >>>> Tom >>>> >>>> Am 03.12.12 18:13, schrieb David Grieve: >>>>> Remove and re-add the stylesheet. >>>>> >>>>> On Dec 1, 2012, at 9:41 AM, Tom Schindl wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> To force reloading of stylesheets I used in FX2.2 >>>>>> StyleManager.getInstance().reloadStylesheets(scene). What is the >>>>>> replacement of this in FX8. >>>>>> >>>>>> Tom >>>>>> >>>>>> -- >>>>>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>>>>> ------------------------------------------------------------------------ >>>>>> tom schindl gesch?ftsf?hrer/CEO >>>>>> ------------------------------------------------------------------------ >>>>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>>>>> http://www.BestSolution.at phone ++43 512 935834 >>>>> >>>> >>>> >>>> -- >>>> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >>>> ------------------------------------------------------------------------ >>>> tom schindl gesch?ftsf?hrer/CEO >>>> ------------------------------------------------------------------------ >>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >>>> http://www.BestSolution.at phone ++43 512 935834 >>> >> >> >> -- >> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >> ------------------------------------------------------------------------ >> tom schindl gesch?ftsf?hrer/CEO >> ------------------------------------------------------------------------ >> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >> http://www.BestSolution.at phone ++43 512 935834 > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From steve.x.northover at oracle.com Thu Dec 6 07:54:22 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Thu, 06 Dec 2012 10:54:22 -0500 Subject: [REVIEW REQUEST] RT-24088 Add API to JavaFX to allow vetoing the closing of a Tab in a TabPane In-Reply-To: <50C09E8E.1090909@bestsolution.at> References: <50BFED62.1070804@bestsolution.at> <50C03656.6020903@tbee.org> <50C08247.2060600@media-interactive.de> <50C09E8E.1090909@bestsolution.at> Message-ID: <50C0BFAE.8000808@oracle.com> Stage has the onCloseRequest property. Might make sense to have a similar API in Tab. Steve On 06/12/2012 8:33 AM, Tom Schindl wrote: > Hi, > > This is an interesting idea. I'm not that deep in the FX-API to > understand if this the advised way in other areas so. I let Richard and > Jonathan comment on it. > > Tom > > Am 06.12.12 12:32, schrieb Werner Lehmann: >> Would it also be possible to have a simple onClosing event and require a >> handler to Event.consume() it? Maybe slightly less obvious than an >> explicit "*veto*" but more flexible/resuable, too (as a general pattern >> in similar situations). >> >> Werner >> >> On 06.12.2012 07:08, Tom Eugelink wrote: >>> Just a remark to see if we can make this more reusable; would it be >>> an idea to actually veto the close action? Like veto the removal of a >>> tab from a list? In that way veto-ing would be available to other >>> usages of such lists as well, a uniform API. >>> >>> Tom > From richard.bair at oracle.com Thu Dec 6 08:04:51 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 6 Dec 2012 08:04:51 -0800 Subject: [REVIEW REQUEST] RT-24088 Add API to JavaFX to allow vetoing the closing of a Tab in a TabPane In-Reply-To: <50C0BFAE.8000808@oracle.com> References: <50BFED62.1070804@bestsolution.at> <50C03656.6020903@tbee.org> <50C08247.2060600@media-interactive.de> <50C09E8E.1090909@bestsolution.at> <50C0BFAE.8000808@oracle.com> Message-ID: Indeed, this sounds like the same idea Werner had. Good find. On Dec 6, 2012, at 7:54 AM, steve.x.northover at oracle.com wrote: > Stage has the onCloseRequest property. Might make sense to have a similar API in Tab. > > Steve > > On 06/12/2012 8:33 AM, Tom Schindl wrote: >> Hi, >> >> This is an interesting idea. I'm not that deep in the FX-API to >> understand if this the advised way in other areas so. I let Richard and >> Jonathan comment on it. >> >> Tom >> >> Am 06.12.12 12:32, schrieb Werner Lehmann: >>> Would it also be possible to have a simple onClosing event and require a >>> handler to Event.consume() it? Maybe slightly less obvious than an >>> explicit "*veto*" but more flexible/resuable, too (as a general pattern >>> in similar situations). >>> >>> Werner >>> >>> On 06.12.2012 07:08, Tom Eugelink wrote: >>>> Just a remark to see if we can make this more reusable; would it be >>>> an idea to actually veto the close action? Like veto the removal of a >>>> tab from a list? In that way veto-ing would be available to other >>>> usages of such lists as well, a uniform API. >>>> >>>> Tom >> From zonski at gmail.com Thu Dec 6 11:28:34 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 7 Dec 2012 06:28:34 +1100 Subject: JavaFX performance for complex visualisations In-Reply-To: <001501cdd38c$790782f0$6b1688d0$@com.au> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <001501cdd38c$790782f0$6b1688d0$@com.au> Message-ID: <9E16E89C-5753-4224-927E-268F626CEB89@gmail.com> Hi John, We've decided to go with Tower Defender as a starting point. I think we all recognize that it's a pretty humble beginning - the intention is to start with this, get something up and running quite quickly and then new projects with more complexity can seed off of it. Tower Defender can at least test lots of animated, interacting nodes on the screen at once and we can get as complex as we like with our BadGuys, etc. The BitBucket link is at: https://bitbucket.org/rbair/fx-games/overview You should be able to see it but I think at this stage Richard will have to 'invite' you to be able to contribute. Richard if you want to palm off that job, let me know. Cheers, Dan On 06/12/2012, at 7:34 PM, "John C. Turnbull" wrote: > Thanks for responding to this Richard. > > The smoothness issue is a bit baffling. On my desktop PC (which is > virtually a super computer and includes the world's fastest GPU), all the > animations in Ensemble are very "unsmooth", that is to say that even the > simple Translate transition demo displays a jumpy red ball moving from side > to side. It's so jumpy that it looks like I am actually running it on a > hand-held calculator or similar! Conversely, the same demo on my 5-year-old > laptop is "super smooth" and indeed all the Ensemble demos run extremely > impressively on this machine. Do you have any ideas on what is causing this > and/or suggestions on how to improve things? > > Anyway, I am very excited by the question you posed at the end of your reply > in relation to building a graphics intensive demo application with JavaFX. > Another thread has started dealing with the type of game or application that > would be suitable but the thing for me which is most important is that this > demo *not* be a clone of some simple existing game but rather be truly > graphics intensive and demanding. One suggestion was to re-implement > Asteroids because "If we can't handle an old 8-bit game from the early 80's > with nice fluid animations then we can give up and go home" but to me this > would be exactly what *not* to do. The idea that JavaFX should be capable > of fluid animations for an old style game is fine but what have we proved if > the app does indeed run smoothly using JavaFX? Nothing really. We *must* > focus on something which would not have run on an old 8-bit computer. > Something that would test Flash today on reasonably powered modern machines. > Something that actually *requires* a UI toolkit as powerful and advanced as > JavaFX (or is supposed to be). Otherwise we have not achieved anything. > > Whatever is chosen, I will contribute in any way I can :-) > > -jct > > -----Original Message----- > From: Richard Bair [mailto:richard.bair at oracle.com] > Sent: Wednesday, 5 December 2012 07:24 > To: John C. Turnbull > Cc: openjfx-dev at openjdk.java.net > Subject: Re: JavaFX performance for complex visualisations > > Hi John, > > Just getting through my email and have had this one flagged since Devoxx > :-). I respond below to individual points but most of these are probably not > worth you responding back on (they're just informational on my part) -- > rather, down at the end is the real question I want to have a discussion on > (and will be a lot of fun to solve while we're at it). > >> 1. Do any such games, animations or visualisations exist yet? > > Yes. Much like Swing, JavaFX is seeing a lot of adoption in the heavy > enterprise desktop sorts of use cases -- not the kind of thing you will find > when browsing the internet. Most of these folks don't advertise the > technology they're using, and most of them are not interested in letting > their competitors know what they're doing or what technology they're using. > Which basically means, if we haven't built a demo for it, there isn't > anything you will find in your travels. > >> 2. If not, how does Oracle or anyone else actually know that JavaFX is >> capable of supporting such applications? > > That is a good question. Many of the folks I've talked to building such > applications have done incredible work + proof of concepts long before I > even knew they were using JavaFX. Now, each year we do pretty graphically > intense demos for JavaOne, so we have a pretty good feel for it. We have a > bunch of benchmarks where we crank the number of nodes up to pretty high > numbers, and we know from these benchmarks (at least) that we scale very > well compared to other technologies. But I know neither the samples nor the > results are publicly available. But at least I can answer the "how does > Oracle . know" part of the question. > > We have had a performance team from the get-go who were solely dedicated to > writing benchmarks, running benchmarks, and analyzing results. This has been > incredibly helpful. We have results that come not just from the weekly > integrations but even from intra-week builds on specific scrum repositories. > We have benchmarks and analysis for both desktop and embedded and take > performance very seriously. > > Now, there are a lot of ways to use the platform. Some things are better > tuned than others. Performance work is driven by tuning and benchmarks. So > when we run into issues we have to (a) determine how likely that is to be an > issue to the broader development community (b) figure out what the tradeoffs > are (usually performance & quality are directly in contradiction with each > other), and ( c) schedule & implement the fix. Of course, the same few > people (Jim, mostly) are involved in many of the performance fixes and > features (like Canvas), so scheduling is an issue and feedback from > customers as to what they are actually running into (vs. what a theoretical > issue is) has priority. > >> 3. Do I have the wrong understanding that JavaFX is supposed to >> support such applications? > > We expect that JavaFX will be usable for casual games, but we are not > building a gaming platform to compete with Unity and the like. If we happen > to be just as good, then that's awesome, but it isn't our primary goal. > Advanced visualizations, on the other hand, are part of our target market > (medical, pharma, enterprise desktop, etc) > >> 4. Is it possible that, for whatever reason, JavaFX is simply not >> capable of supporting such applications? > > There are natural trade-offs between an immediate mode (like Canvas) API and > a retained mode (like Scene Graph) API. Now that we have both (plus Java2D + > ImageWriter and such for the really crazy cases) we should be capable of a > wide range of use cases. However, some things are not yet optimized. But > there is no technical reason why we shouldn't be quite capable. > > Another area we have not yet exposed API which is problematic for some > people is in the area of custom shaders. It may be that without some kind of > custom shader support (which would have to be made to work on D3D as well as > OpenGL) certain use cases cannot be easily fulfilled. > >> My feeling that JavaFX can indeed support such applications is based >> on the fact that it is hardware accelerated and therefore it should be >> limited mostly by the capabilities of the graphics card and also >> because it is often talked about in this way. However, I have >> observed varying levels of performance that don't quite follow these >> principles such as JavaFX performing poorly with choppy/jittery >> animations and transitions on my most powerful machine with an NVIDIA >> GeForce GTX 690 (the current fastest graphics card in the world) but >> performing quite well on machines with much lower specifications. > > It is highly unlikely that this is due to performance issues. As mentioned > in the last few days on another thread, there are smoothness issues that are > completely separate from performance (although both are often talked about > together). We're working on the smoothness. Sometimes this is an application > problem as opposed to a platform problem (one such example is the > DisplayShelf sample, which needs to be rewritten). > >> So I guess I am curious to know what kinds of testing and evaluations >> Oracle has undertaken to determine the performance characteristics of >> JavaFX and exactly what kinds of applications it is actually suitable >> for. For example, I am yet to see any JavaFX application with even >> the sophistication of a Flash electronic greeting card or banner ad >> and yet I assume JavaFX will be used for such purposes eventually. > > I would imagine any of our demos from the last 3-4 years of JavaOne would > demonstrate much more complicated use cases than that! But, instead of me > just complaining -- lets build one! We'll add it both to Ensemble and our > test suite. We can start with something simple (like a greeting card) and > expand it out to something wildly complex. What would you like to see? One > thing I've wanted to build for years but haven't found the time for was a > tower defense game. But what would you think would be a good example of > graphics performance that would tell you "hey, this platform is great for > visualizations"? > > Richard > From richard.bair at oracle.com Thu Dec 6 11:39:29 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 6 Dec 2012 11:39:29 -0800 Subject: JavaFX performance for complex visualisations In-Reply-To: <001501cdd38c$790782f0$6b1688d0$@com.au> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <001501cdd38c$790782f0$6b1688d0$@com.au> Message-ID: > The smoothness issue is a bit baffling. On my desktop PC (which is > virtually a super computer and includes the world's fastest GPU), all the > animations in Ensemble are very "unsmooth", that is to say that even the > simple Translate transition demo displays a jumpy red ball moving from side > to side. It's so jumpy that it looks like I am actually running it on a > hand-held calculator or similar! Conversely, the same demo on my 5-year-old > laptop is "super smooth" and indeed all the Ensemble demos run extremely > impressively on this machine. Do you have any ideas on what is causing this > and/or suggestions on how to improve things? It could be related to the accuracy of the timer mechanism being used to initiate pulses. Or maybe the drivers not handling vsync timing properly. But I think it is a good example of the problem we're seeing -- it isn't one of performance (i.e.: rendering is fine for your use case I would wager), but rather something else. For example, we've found that on Mac in some tests when profiling using low-level mac graphics tools, that we're easily getting 60fps, and yet some frames are simply not being rendered on the screen. We're not sure why yet. > Anyway, I am very excited by the question you posed at the end of your reply > in relation to building a graphics intensive demo application with JavaFX. > Another thread has started dealing with the type of game or application that > would be suitable but the thing for me which is most important is that this > demo *not* be a clone of some simple existing game but rather be truly > graphics intensive and demanding. One suggestion was to re-implement > Asteroids because "If we can't handle an old 8-bit game from the early 80's > with nice fluid animations then we can give up and go home" but to me this > would be exactly what *not* to do. The idea that JavaFX should be capable > of fluid animations for an old style game is fine but what have we proved if > the app does indeed run smoothly using JavaFX? Nothing really. We *must* > focus on something which would not have run on an old 8-bit computer. > Something that would test Flash today on reasonably powered modern machines. > Something that actually *requires* a UI toolkit as powerful and advanced as > JavaFX (or is supposed to be). Otherwise we have not achieved anything. As Daniel mentioned, I agree we need to do something much more complicated than a tower defender, but we gotta start somewhere and starting on something that requires less up front engineering is a good way to get our feet wet. I intend to host additional "games" in the workspace -- maybe I should have called them "fx-experiments" after the nature of Chrome Experiments. In fact, that is one thing that we could do is start hosting a bunch of ports of chrome experiments to see how they behave and that way have direct comparisons. But to start with, lets focus on the defender and see how that goes. Richard From richard.bair at oracle.com Thu Dec 6 11:41:04 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 6 Dec 2012 11:41:04 -0800 Subject: JavaFX performance for complex visualisations In-Reply-To: <6C97DCCC-CEE2-4F97-AF96-E83337860EE4@rockit.dk> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <001501cdd38c$790782f0$6b1688d0$@com.au> <6C97DCCC-CEE2-4F97-AF96-E83337860EE4@rockit.dk> Message-ID: <54534EA2-05DA-4FB8-98EE-A220B03F0201@oracle.com> I don't know of any reliable way to give our graphics threads any higher priority. My understanding (and experimentation) with thread priorities in Java is that they are completely ignored. There is probably some way in native to raise the priority? I have been interested in this question as well for some time. In some of our examples we have images downloaded in a background thread but they affected rendering performance, which was very frustrating. Richard On Dec 6, 2012, at 4:17 AM, Randahl Fink Isaksen wrote: > In my experience, the primary performance problem with JavaFX, is the fact that the JavaFX rendering thread does not get any special treatment. On my multicore Mac, I can easily get low JavaFX frame rates by simply increasing the CPU load. > > Has anyone tested if increasing the JavaFX thread priority can inspire the OS or the CPU to favour JavaFX rendering over everything else? I am aware that it depends on your app, but at least in some apps, smooth rendering is above everything else. > > Thanks > > Randahl > > > On Dec 6, 2012, at 9:34 , John C. Turnbull wrote: > >> Thanks for responding to this Richard. >> >> The smoothness issue is a bit baffling. On my desktop PC (which is >> virtually a super computer and includes the world's fastest GPU), all the >> animations in Ensemble are very "unsmooth", that is to say that even the >> simple Translate transition demo displays a jumpy red ball moving from side >> to side. It's so jumpy that it looks like I am actually running it on a >> hand-held calculator or similar! Conversely, the same demo on my 5-year-old >> laptop is "super smooth" and indeed all the Ensemble demos run extremely >> impressively on this machine. Do you have any ideas on what is causing this >> and/or suggestions on how to improve things? >> >> Anyway, I am very excited by the question you posed at the end of your reply >> in relation to building a graphics intensive demo application with JavaFX. >> Another thread has started dealing with the type of game or application that >> would be suitable but the thing for me which is most important is that this >> demo *not* be a clone of some simple existing game but rather be truly >> graphics intensive and demanding. One suggestion was to re-implement >> Asteroids because "If we can't handle an old 8-bit game from the early 80's >> with nice fluid animations then we can give up and go home" but to me this >> would be exactly what *not* to do. The idea that JavaFX should be capable >> of fluid animations for an old style game is fine but what have we proved if >> the app does indeed run smoothly using JavaFX? Nothing really. We *must* >> focus on something which would not have run on an old 8-bit computer. >> Something that would test Flash today on reasonably powered modern machines. >> Something that actually *requires* a UI toolkit as powerful and advanced as >> JavaFX (or is supposed to be). Otherwise we have not achieved anything. >> >> Whatever is chosen, I will contribute in any way I can :-) >> >> -jct >> >> -----Original Message----- >> From: Richard Bair [mailto:richard.bair at oracle.com] >> Sent: Wednesday, 5 December 2012 07:24 >> To: John C. Turnbull >> Cc: openjfx-dev at openjdk.java.net >> Subject: Re: JavaFX performance for complex visualisations >> >> Hi John, >> >> Just getting through my email and have had this one flagged since Devoxx >> :-). I respond below to individual points but most of these are probably not >> worth you responding back on (they're just informational on my part) -- >> rather, down at the end is the real question I want to have a discussion on >> (and will be a lot of fun to solve while we're at it). >> >>> 1. Do any such games, animations or visualisations exist yet? >> >> Yes. Much like Swing, JavaFX is seeing a lot of adoption in the heavy >> enterprise desktop sorts of use cases -- not the kind of thing you will find >> when browsing the internet. Most of these folks don't advertise the >> technology they're using, and most of them are not interested in letting >> their competitors know what they're doing or what technology they're using. >> Which basically means, if we haven't built a demo for it, there isn't >> anything you will find in your travels. >> >>> 2. If not, how does Oracle or anyone else actually know that JavaFX is >>> capable of supporting such applications? >> >> That is a good question. Many of the folks I've talked to building such >> applications have done incredible work + proof of concepts long before I >> even knew they were using JavaFX. Now, each year we do pretty graphically >> intense demos for JavaOne, so we have a pretty good feel for it. We have a >> bunch of benchmarks where we crank the number of nodes up to pretty high >> numbers, and we know from these benchmarks (at least) that we scale very >> well compared to other technologies. But I know neither the samples nor the >> results are publicly available. But at least I can answer the "how does >> Oracle . know" part of the question. >> >> We have had a performance team from the get-go who were solely dedicated to >> writing benchmarks, running benchmarks, and analyzing results. This has been >> incredibly helpful. We have results that come not just from the weekly >> integrations but even from intra-week builds on specific scrum repositories. >> We have benchmarks and analysis for both desktop and embedded and take >> performance very seriously. >> >> Now, there are a lot of ways to use the platform. Some things are better >> tuned than others. Performance work is driven by tuning and benchmarks. So >> when we run into issues we have to (a) determine how likely that is to be an >> issue to the broader development community (b) figure out what the tradeoffs >> are (usually performance & quality are directly in contradiction with each >> other), and ( c) schedule & implement the fix. Of course, the same few >> people (Jim, mostly) are involved in many of the performance fixes and >> features (like Canvas), so scheduling is an issue and feedback from >> customers as to what they are actually running into (vs. what a theoretical >> issue is) has priority. >> >>> 3. Do I have the wrong understanding that JavaFX is supposed to >>> support such applications? >> >> We expect that JavaFX will be usable for casual games, but we are not >> building a gaming platform to compete with Unity and the like. If we happen >> to be just as good, then that's awesome, but it isn't our primary goal. >> Advanced visualizations, on the other hand, are part of our target market >> (medical, pharma, enterprise desktop, etc) >> >>> 4. Is it possible that, for whatever reason, JavaFX is simply not >>> capable of supporting such applications? >> >> There are natural trade-offs between an immediate mode (like Canvas) API and >> a retained mode (like Scene Graph) API. Now that we have both (plus Java2D + >> ImageWriter and such for the really crazy cases) we should be capable of a >> wide range of use cases. However, some things are not yet optimized. But >> there is no technical reason why we shouldn't be quite capable. >> >> Another area we have not yet exposed API which is problematic for some >> people is in the area of custom shaders. It may be that without some kind of >> custom shader support (which would have to be made to work on D3D as well as >> OpenGL) certain use cases cannot be easily fulfilled. >> >>> My feeling that JavaFX can indeed support such applications is based >>> on the fact that it is hardware accelerated and therefore it should be >>> limited mostly by the capabilities of the graphics card and also >>> because it is often talked about in this way. However, I have >>> observed varying levels of performance that don't quite follow these >>> principles such as JavaFX performing poorly with choppy/jittery >>> animations and transitions on my most powerful machine with an NVIDIA >>> GeForce GTX 690 (the current fastest graphics card in the world) but >>> performing quite well on machines with much lower specifications. >> >> It is highly unlikely that this is due to performance issues. As mentioned >> in the last few days on another thread, there are smoothness issues that are >> completely separate from performance (although both are often talked about >> together). We're working on the smoothness. Sometimes this is an application >> problem as opposed to a platform problem (one such example is the >> DisplayShelf sample, which needs to be rewritten). >> >>> So I guess I am curious to know what kinds of testing and evaluations >>> Oracle has undertaken to determine the performance characteristics of >>> JavaFX and exactly what kinds of applications it is actually suitable >>> for. For example, I am yet to see any JavaFX application with even >>> the sophistication of a Flash electronic greeting card or banner ad >>> and yet I assume JavaFX will be used for such purposes eventually. >> >> I would imagine any of our demos from the last 3-4 years of JavaOne would >> demonstrate much more complicated use cases than that! But, instead of me >> just complaining -- lets build one! We'll add it both to Ensemble and our >> test suite. We can start with something simple (like a greeting card) and >> expand it out to something wildly complex. What would you like to see? One >> thing I've wanted to build for years but haven't found the time for was a >> tower defense game. But what would you think would be a good example of >> graphics performance that would tell you "hey, this platform is great for >> visualizations"? >> >> Richard >> > From jan.schenkel at quartam.com Thu Dec 6 12:10:53 2012 From: jan.schenkel at quartam.com (Quartam - Jan Schenkel) Date: Thu, 6 Dec 2012 21:10:53 +0100 Subject: [REVIEW REQUEST] RT-24088 Add API to JavaFX to allow vetoing the closing of a Tab in a TabPane In-Reply-To: References: <50BFED62.1070804@bestsolution.at> <50C03656.6020903@tbee.org> <50C08247.2060600@media-interactive.de> <50C09E8E.1090909@bestsolution.at> <50C0BFAE.8000808@oracle.com> Message-ID: <26D14191-C916-4989-A848-2A07F85F278D@quartam.com> (Long-time list reader but first post so Hi all!) I filed a Jira issue earlier today for a similar request regarding WebView/WebEngine navigation - allowing the developer to veto location changes. Thanks to this discussion I've amended my original idea to match the onCloseRequest approach. Love the open flow of ideas in OpenJFX :-) Jan. On 06 Dec 2012, at 17:04, Richard Bair wrote: > Indeed, this sounds like the same idea Werner had. Good find. > > On Dec 6, 2012, at 7:54 AM, steve.x.northover at oracle.com wrote: > >> Stage has the onCloseRequest property. Might make sense to have a similar API in Tab. >> >> Steve >> >> On 06/12/2012 8:33 AM, Tom Schindl wrote: >>> Hi, >>> >>> This is an interesting idea. I'm not that deep in the FX-API to >>> understand if this the advised way in other areas so. I let Richard and >>> Jonathan comment on it. >>> >>> Tom >>> >>> Am 06.12.12 12:32, schrieb Werner Lehmann: >>>> Would it also be possible to have a simple onClosing event and require a >>>> handler to Event.consume() it? Maybe slightly less obvious than an >>>> explicit "*veto*" but more flexible/resuable, too (as a general pattern >>>> in similar situations). >>>> >>>> Werner >>>> >>>> On 06.12.2012 07:08, Tom Eugelink wrote: >>>>> Just a remark to see if we can make this more reusable; would it be >>>>> an idea to actually veto the close action? Like veto the removal of a >>>>> tab from a list? In that way veto-ing would be available to other >>>>> usages of such lists as well, a uniform API. >>>>> >>>>> Tom >>> > From ozemale at ozemail.com.au Thu Dec 6 12:15:21 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Fri, 7 Dec 2012 07:15:21 +1100 Subject: JavaFX performance for complex visualisations In-Reply-To: References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <001501cdd38c$790782f0$6b1688d0$@com.au> Message-ID: <005701cdd3ee$6b6bb370$42431a50$@com.au> Yes, rendering itself is fine on the power machine. And I don't think it's a driver issue because OpenGL applications and other Direct3D applications perform blindingly quickly without any jumpiness. It's really just running JavaFX animations that makes the machine look like something from the 70s or 80s. As for the demo app, tower defence it is then. I think it will be very valuable to have a nice, impressive demo app/game as part of Ensemble or as a separate demo in itself. I fear that many potential JavaFX developers don't get past Ensemble because they see nothing there that resembles what they are trying to do with it. Eventually we really need to have a kick-arse graphics and sound demo that would be difficult to implement using any other technology. -----Original Message----- From: Richard Bair [mailto:richard.bair at oracle.com] Sent: Friday, 7 December 2012 06:39 To: John C. Turnbull Cc: openjfx-dev at openjdk.java.net Subject: Re: JavaFX performance for complex visualisations > The smoothness issue is a bit baffling. On my desktop PC (which is > virtually a super computer and includes the world's fastest GPU), all > the animations in Ensemble are very "unsmooth", that is to say that > even the simple Translate transition demo displays a jumpy red ball > moving from side to side. It's so jumpy that it looks like I am > actually running it on a hand-held calculator or similar! Conversely, > the same demo on my 5-year-old laptop is "super smooth" and indeed all > the Ensemble demos run extremely impressively on this machine. Do you > have any ideas on what is causing this and/or suggestions on how to improve things? It could be related to the accuracy of the timer mechanism being used to initiate pulses. Or maybe the drivers not handling vsync timing properly. But I think it is a good example of the problem we're seeing -- it isn't one of performance (i.e.: rendering is fine for your use case I would wager), but rather something else. For example, we've found that on Mac in some tests when profiling using low-level mac graphics tools, that we're easily getting 60fps, and yet some frames are simply not being rendered on the screen. We're not sure why yet. > Anyway, I am very excited by the question you posed at the end of your > reply in relation to building a graphics intensive demo application with JavaFX. > Another thread has started dealing with the type of game or > application that would be suitable but the thing for me which is most > important is that this demo *not* be a clone of some simple existing > game but rather be truly graphics intensive and demanding. One > suggestion was to re-implement Asteroids because "If we can't handle > an old 8-bit game from the early 80's with nice fluid animations then > we can give up and go home" but to me this would be exactly what *not* > to do. The idea that JavaFX should be capable of fluid animations for > an old style game is fine but what have we proved if the app does > indeed run smoothly using JavaFX? Nothing really. We *must* focus on something which would not have run on an old 8-bit computer. > Something that would test Flash today on reasonably powered modern machines. > Something that actually *requires* a UI toolkit as powerful and > advanced as JavaFX (or is supposed to be). Otherwise we have not achieved anything. As Daniel mentioned, I agree we need to do something much more complicated than a tower defender, but we gotta start somewhere and starting on something that requires less up front engineering is a good way to get our feet wet. I intend to host additional "games" in the workspace -- maybe I should have called them "fx-experiments" after the nature of Chrome Experiments. In fact, that is one thing that we could do is start hosting a bunch of ports of chrome experiments to see how they behave and that way have direct comparisons. But to start with, lets focus on the defender and see how that goes. Richard= From swpalmer at gmail.com Thu Dec 6 12:24:36 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 6 Dec 2012 15:24:36 -0500 Subject: JavaFX performance for complex visualisations In-Reply-To: <54534EA2-05DA-4FB8-98EE-A220B03F0201@oracle.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <001501cdd38c$790782f0$6b1688d0$@com.au> <6C97DCCC-CEE2-4F97-AF96-E83337860EE4@rockit.dk> <54534EA2-05DA-4FB8-98EE-A220B03F0201@oracle.com> Message-ID: On 2012-12-06, at 2:41 PM, Richard Bair wrote: > I don't know of any reliable way to give our graphics threads any higher priority. My understanding (and experimentation) with thread priorities in Java is that they are completely ignored. I don't think that true. At least not on Windows. Though on Windows there are different "classes" or priority, The full range of Java priorities is mapped to a narrow range of the native thread priorities. The highest we could go from the Java side still left room for higher native priorities. > There is probably some way in native to raise the priority? There is. We just had to do that in our product because we needed a specific thread to be TIME_CRITICAL thread priority on Windows and possibly have the process be in the REALTIME priority class. See: http://msdn.microsoft.com/en-us/library/windows/desktop/ms685100(v=vs.85).aspx Scott From richard.bair at oracle.com Thu Dec 6 13:16:23 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 6 Dec 2012 13:16:23 -0800 Subject: JavaFX performance for complex visualisations In-Reply-To: References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <001501cdd38c$790782f0$6b1688d0$@com.au> <6C97DCCC-CEE2-4F97-AF96-E83337860EE4@rockit.dk> <54534EA2-05DA-4FB8-98EE-A220B03F0201@oracle.com> Message-ID: <28582757-28AA-4435-B5C2-D35CD14C4C22@oracle.com> Lets file a JIRA on this and see how it behaves. On Dec 6, 2012, at 12:24 PM, Scott Palmer wrote: > > On 2012-12-06, at 2:41 PM, Richard Bair wrote: > >> I don't know of any reliable way to give our graphics threads any higher priority. My understanding (and experimentation) with thread priorities in Java is that they are completely ignored. > > I don't think that true. At least not on Windows. Though on Windows there are different "classes" or priority, The full range of Java priorities is mapped to a narrow range of the native thread priorities. The highest we could go from the Java side still left room for higher native priorities. > >> There is probably some way in native to raise the priority? > > There is. We just had to do that in our product because we needed a specific thread to be TIME_CRITICAL thread priority on Windows and possibly have the process be in the REALTIME priority class. > > > See: http://msdn.microsoft.com/en-us/library/windows/desktop/ms685100(v=vs.85).aspx > > > Scott > From randahl at wefend.com Thu Dec 6 12:41:48 2012 From: randahl at wefend.com (Randahl Fink Isaksen) Date: Thu, 6 Dec 2012 21:41:48 +0100 Subject: What is the priority of the JavaFX thread? Message-ID: <06CA53D9-C4EF-4547-9E5A-48BD584B48D8@rockit.dk> Does JavaFX intentionally set a priority for the JavaFX thread? I would very much like to hear what the decision behind setting or not setting such a priority is. The reason I am asking is, on my development Mac, it seems the JavaFX thread is easily starved by other CPU load, and I was thinking if the developers of JavaFX did or did not expect application developers to manage JavaFX thread priority. Thanks Randahl From richard.bair at oracle.com Thu Dec 6 13:29:46 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 6 Dec 2012 13:29:46 -0800 Subject: What is the priority of the JavaFX thread? In-Reply-To: <06CA53D9-C4EF-4547-9E5A-48BD584B48D8@rockit.dk> References: <06CA53D9-C4EF-4547-9E5A-48BD584B48D8@rockit.dk> Message-ID: <81F3CE81-A205-4A5C-A999-2546825A049D@oracle.com> I don't *think* we set any thread priorities. I have tried different thread priorities in apps in the past (such as lowering the priority of background threads) and it didn't make a difference. I should look at the concurrent APIs in javaFX and see if they still set the thread priority?in fact it does. But I haven't noticed any app behavior that changed by doing so. But I haven't tried to set the thread priority from anywhere but within Java, and I'm on a mac, so maybe it works differently (although I am pretty certain I've talked to VM engineers who have said thread priorities are ignored on HotSpot). Richard On Dec 6, 2012, at 12:41 PM, Randahl Fink Isaksen wrote: > Does JavaFX intentionally set a priority for the JavaFX thread? I would very much like to hear what the decision behind setting or not setting such a priority is. > > The reason I am asking is, on my development Mac, it seems the JavaFX thread is easily starved by other CPU load, and I was thinking if the developers of JavaFX did or did not expect application developers to manage JavaFX thread priority. > > Thanks > > Randahl From hang.vo at oracle.com Thu Dec 6 13:32:35 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 06 Dec 2012 21:32:35 +0000 Subject: hg: openjfx/8/controls/rt: RT-24225: Add RTL support to Menu / MenuItem / RadioMenuItem / CheckMenuItem / ContextMenu / MenuBar Message-ID: <20121206213240.4C66347F59@hg.openjdk.java.net> Changeset: 08a7980d8bc4 Author: leifs Date: 2012-12-06 13:22 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/08a7980d8bc4 RT-24225: Add RTL support to Menu / MenuItem / RadioMenuItem / CheckMenuItem / ContextMenu / MenuBar ! javafx-ui-common/src/com/sun/javafx/Utils.java ! javafx-ui-controls/src/javafx/scene/control/ContextMenu.java From tom.schindl at bestsolution.at Thu Dec 6 13:51:20 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 06 Dec 2012 22:51:20 +0100 Subject: [REVIEW REQUEST] RT-24088 Add API to JavaFX to allow vetoing the closing of a Tab in a TabPane In-Reply-To: References: <50BFED62.1070804@bestsolution.at> <50C03656.6020903@tbee.org> <50C08247.2060600@media-interactive.de> <50C09E8E.1090909@bestsolution.at> <50C0BFAE.8000808@oracle.com> Message-ID: <50C11358.8030700@bestsolution.at> Hi, I've uploaded a revised patch which now works using the event system sending out an TabEvent of type "TAB_CLOSE_REQUEST". So the revised API on Tab would now be: + ObjectProperty> onCloseRequestProperty() + EventHandler getOnCloseRequest() + setOnCloseRequests(EventHandler value) and vetoing a close would look like this: Tab tab1 = new Tab("Hello"); tab1.setOnCloseRequests(new EventHandler() { @Override public void handle(TabEvent event) { event.consume(); } }); Thanks for the input Werner, Steven and Richard. One thing I was not sure is who is supposed to deliver an event. I used the TabPaneBehavior maybe the Tab itself should send out this event? Tom Am 06.12.12 17:04, schrieb Richard Bair: > Indeed, this sounds like the same idea Werner had. Good find. > > On Dec 6, 2012, at 7:54 AM, steve.x.northover at oracle.com wrote: > >> Stage has the onCloseRequest property. Might make sense to have a similar API in Tab. >> >> Steve >> >> On 06/12/2012 8:33 AM, Tom Schindl wrote: >>> Hi, >>> >>> This is an interesting idea. I'm not that deep in the FX-API to >>> understand if this the advised way in other areas so. I let Richard and >>> Jonathan comment on it. >>> >>> Tom >>> >>> Am 06.12.12 12:32, schrieb Werner Lehmann: >>>> Would it also be possible to have a simple onClosing event and require a >>>> handler to Event.consume() it? Maybe slightly less obvious than an >>>> explicit "*veto*" but more flexible/resuable, too (as a general pattern >>>> in similar situations). >>>> >>>> Werner >>>> >>>> On 06.12.2012 07:08, Tom Eugelink wrote: >>>>> Just a remark to see if we can make this more reusable; would it be >>>>> an idea to actually veto the close action? Like veto the removal of a >>>>> tab from a list? In that way veto-ing would be available to other >>>>> usages of such lists as well, a uniform API. >>>>> >>>>> Tom >>> > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From kevin.rushforth at oracle.com Thu Dec 6 14:06:58 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 06 Dec 2012 14:06:58 -0800 Subject: What is the priority of the JavaFX thread? In-Reply-To: <81F3CE81-A205-4A5C-A999-2546825A049D@oracle.com> References: <06CA53D9-C4EF-4547-9E5A-48BD584B48D8@rockit.dk> <81F3CE81-A205-4A5C-A999-2546825A049D@oracle.com> Message-ID: <50C11702.4020203@oracle.com> I doubt this is related to thread priorities, but it would be worth verifying. More likely it's the interaction of thread scheduling, timers, and vsync. -- Kevin Richard Bair wrote: > I don't *think* we set any thread priorities. I have tried different thread priorities in apps in the past (such as lowering the priority of background threads) and it didn't make a difference. I should look at the concurrent APIs in javaFX and see if they still set the thread priority?in fact it does. But I haven't noticed any app behavior that changed by doing so. But I haven't tried to set the thread priority from anywhere but within Java, and I'm on a mac, so maybe it works differently (although I am pretty certain I've talked to VM engineers who have said thread priorities are ignored on HotSpot). > > Richard > > On Dec 6, 2012, at 12:41 PM, Randahl Fink Isaksen wrote: > > >> Does JavaFX intentionally set a priority for the JavaFX thread? I would very much like to hear what the decision behind setting or not setting such a priority is. >> >> The reason I am asking is, on my development Mac, it seems the JavaFX thread is easily starved by other CPU load, and I was thinking if the developers of JavaFX did or did not expect application developers to manage JavaFX thread priority. >> >> Thanks >> >> Randahl >> > > From jonathan.giles at oracle.com Thu Dec 6 14:09:06 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 07 Dec 2012 11:09:06 +1300 Subject: [REVIEW REQUEST] RT-24088 Add API to JavaFX to allow vetoing the closing of a Tab in a TabPane In-Reply-To: <50C11358.8030700@bestsolution.at> References: <50BFED62.1070804@bestsolution.at> <50C03656.6020903@tbee.org> <50C08247.2060600@media-interactive.de> <50C09E8E.1090909@bestsolution.at> <50C0BFAE.8000808@oracle.com> <50C11358.8030700@bestsolution.at> Message-ID: <50C11782.7090407@oracle.com> Richard and I were just chatting about this patch, and the general feeling is that it feels weird to consume an event and make that indicate the event has been vetoed (despite that being how it is already done in the Window case). It just feels like a bit of a side effect, rather than the actual intent of consume() (which is to prevent event propagation, not to pass on additional information such as the state of a veto command). An option is to add a new property to TabEvent that makes it clearer to developers that they are telling the tab not to be closed. Richard suggested having a 'vetoOnClose' property on TabEvent, and to use this rather than consume. Regarding the location from where the event is fired, the primary requirement is to ensure that this event is fired in all cases when a Tab is closed. If that requirement is met I don't think there is a massive concern about where the event itself fires from. Other than that the patch looks fine. -- Jonathan On 7/12/2012 10:51 a.m., Tom Schindl wrote: > Hi, > > I've uploaded a revised patch which now works using the event system > sending out an TabEvent of type "TAB_CLOSE_REQUEST". > > So the revised API on Tab would now be: > + ObjectProperty> onCloseRequestProperty() > + EventHandler getOnCloseRequest() > + setOnCloseRequests(EventHandler value) > > and vetoing a close would look like this: > > Tab tab1 = new Tab("Hello"); > tab1.setOnCloseRequests(new EventHandler() { > > @Override > public void handle(TabEvent event) { > event.consume(); > } > }); > > Thanks for the input Werner, Steven and Richard. > > One thing I was not sure is who is supposed to deliver an event. I used > the TabPaneBehavior maybe the Tab itself should send out this event? > > Tom > > Am 06.12.12 17:04, schrieb Richard Bair: >> Indeed, this sounds like the same idea Werner had. Good find. >> >> On Dec 6, 2012, at 7:54 AM, steve.x.northover at oracle.com wrote: >> >>> Stage has the onCloseRequest property. Might make sense to have a similar API in Tab. >>> >>> Steve >>> >>> On 06/12/2012 8:33 AM, Tom Schindl wrote: >>>> Hi, >>>> >>>> This is an interesting idea. I'm not that deep in the FX-API to >>>> understand if this the advised way in other areas so. I let Richard and >>>> Jonathan comment on it. >>>> >>>> Tom >>>> >>>> Am 06.12.12 12:32, schrieb Werner Lehmann: >>>>> Would it also be possible to have a simple onClosing event and require a >>>>> handler to Event.consume() it? Maybe slightly less obvious than an >>>>> explicit "*veto*" but more flexible/resuable, too (as a general pattern >>>>> in similar situations). >>>>> >>>>> Werner >>>>> >>>>> On 06.12.2012 07:08, Tom Eugelink wrote: >>>>>> Just a remark to see if we can make this more reusable; would it be >>>>>> an idea to actually veto the close action? Like veto the removal of a >>>>>> tab from a list? In that way veto-ing would be available to other >>>>>> usages of such lists as well, a uniform API. >>>>>> >>>>>> Tom > From richard.bair at oracle.com Thu Dec 6 14:09:30 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 6 Dec 2012 14:09:30 -0800 Subject: What is the priority of the JavaFX thread? In-Reply-To: <50C11702.4020203@oracle.com> References: <06CA53D9-C4EF-4547-9E5A-48BD584B48D8@rockit.dk> <81F3CE81-A205-4A5C-A999-2546825A049D@oracle.com> <50C11702.4020203@oracle.com> Message-ID: <2889E045-BF2F-4D97-8B9C-DE1DC8C68A5D@oracle.com> I think maybe there are similar manifestations from different sources. I agree timers, vsync, etc are likely the cause of much of the current stutter. However thread priorities could also be responsible for decreased frame rate when the system is under load (depends more on the OS thread scheduling and interaction with the VM I think). On Dec 6, 2012, at 2:06 PM, Kevin Rushforth wrote: > I doubt this is related to thread priorities, but it would be worth verifying. More likely it's the interaction of thread scheduling, timers, and vsync. > > -- Kevin > > > Richard Bair wrote: >> >> I don't *think* we set any thread priorities. I have tried different thread priorities in apps in the past (such as lowering the priority of background threads) and it didn't make a difference. I should look at the concurrent APIs in javaFX and see if they still set the thread priority?in fact it does. But I haven't noticed any app behavior that changed by doing so. But I haven't tried to set the thread priority from anywhere but within Java, and I'm on a mac, so maybe it works differently (although I am pretty certain I've talked to VM engineers who have said thread priorities are ignored on HotSpot). >> >> Richard >> >> On Dec 6, 2012, at 12:41 PM, Randahl Fink Isaksen wrote: >> >> >>> Does JavaFX intentionally set a priority for the JavaFX thread? I would very much like to hear what the decision behind setting or not setting such a priority is. >>> >>> The reason I am asking is, on my development Mac, it seems the JavaFX thread is easily starved by other CPU load, and I was thinking if the developers of JavaFX did or did not expect application developers to manage JavaFX thread priority. >>> >>> Thanks >>> >>> Randahl >>> >> >> From pedro.duquevieira at gmail.com Thu Dec 6 14:20:46 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Thu, 6 Dec 2012 22:20:46 +0000 Subject: JavaFX performance for complex visualisations Message-ID: Hi, *I'm sorry if this will sound overly critical, I'm just honestly trying to help. Kuddos for taking the initiative!* I don't think IMHO something as simple as tower defender will prove any point. Wasn't "dueling dudes" already showing whatever is meant to be shown with this? I think if you're into doing games than you should go with something 3D, it won't require that much of engineering to do something 3D that could make people impressed. Javafx 8 brings bump mapping, a lightning system, etc, all stuff that could wonder the user with not much of an effort. Also I guess the goal of this project should be clearly stated, I'm sorry if I missed it but from what I've read things seem to be a little vague, I heard porting the game to ios and android I also heard doing something like club penguin, a chrome experiments clone... Perhaps the goals should be clearly stated, what is it that you're trying to prove/accomplish with this? Thank you for your time, -- Pedro Duque Vieira From steve.x.northover at oracle.com Thu Dec 6 14:26:31 2012 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Thu, 06 Dec 2012 17:26:31 -0500 Subject: What is the priority of the JavaFX thread? In-Reply-To: <50C11702.4020203@oracle.com> References: <06CA53D9-C4EF-4547-9E5A-48BD584B48D8@rockit.dk> <81F3CE81-A205-4A5C-A999-2546825A049D@oracle.com> <50C11702.4020203@oracle.com> Message-ID: <50C11B97.1060909@oracle.com> At some point a while back, I played around with making operating system calls to boost thread priority. It did nothing to improve rendering, however, it could be sensitive to the example code. What platform are you on? Steve On 06/12/2012 5:06 PM, Kevin Rushforth wrote: > I doubt this is related to thread priorities, but it would be worth > verifying. More likely it's the interaction of thread scheduling, > timers, and vsync. > > -- Kevin > > > Richard Bair wrote: >> I don't *think* we set any thread priorities. I have tried different >> thread priorities in apps in the past (such as lowering the priority >> of background threads) and it didn't make a difference. I should look >> at the concurrent APIs in javaFX and see if they still set the thread >> priority?in fact it does. But I haven't noticed any app behavior that >> changed by doing so. But I haven't tried to set the thread priority >> from anywhere but within Java, and I'm on a mac, so maybe it works >> differently (although I am pretty certain I've talked to VM engineers >> who have said thread priorities are ignored on HotSpot). >> >> Richard >> >> On Dec 6, 2012, at 12:41 PM, Randahl Fink Isaksen >> wrote: >> >>> Does JavaFX intentionally set a priority for the JavaFX thread? I >>> would very much like to hear what the decision behind setting or not >>> setting such a priority is. >>> >>> The reason I am asking is, on my development Mac, it seems the >>> JavaFX thread is easily starved by other CPU load, and I was >>> thinking if the developers of JavaFX did or did not expect >>> application developers to manage JavaFX thread priority. >>> >>> Thanks >>> >>> Randahl >> From richard.bair at oracle.com Thu Dec 6 14:39:02 2012 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 6 Dec 2012 14:39:02 -0800 Subject: JavaFX performance for complex visualisations In-Reply-To: References: Message-ID: > I think if you're into doing games than you should go with something 3D, it > won't require that much of engineering to do something 3D that could make > people impressed. Javafx 8 brings bump mapping, a lightning system, etc, > all stuff that could wonder the user with not much of an effort. The problem with 3D is that it exercises *completely* different code paths from 2D rendering. So it would be good to do a 3D stress test as well, although that code is not yet available, and it doesn't tell us anything about the performance of the platform when doing Path, Line, Region, or any of the other 2D building blocks. From ozemale at ozemail.com.au Thu Dec 6 14:52:57 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Fri, 7 Dec 2012 09:52:57 +1100 Subject: JavaFX performance for complex visualisations In-Reply-To: References: Message-ID: <008601cdd404$6f9d2620$4ed77260$@com.au> Yes, whilst a 3D stress test is vital in the longer term, what we need right now is something that shows off the true capabilities of 2D JavaFX. Again though, I agree with Pedro in that we should be aiming for something as complex as possible. -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Richard Bair Sent: Friday, 7 December 2012 09:39 To: Pedro Duque Vieira Cc: OpenJFX Mailing List Subject: Re: JavaFX performance for complex visualisations > I think if you're into doing games than you should go with something > 3D, it won't require that much of engineering to do something 3D that > could make people impressed. Javafx 8 brings bump mapping, a lightning > system, etc, all stuff that could wonder the user with not much of an effort. The problem with 3D is that it exercises *completely* different code paths from 2D rendering. So it would be good to do a 3D stress test as well, although that code is not yet available, and it doesn't tell us anything about the performance of the platform when doing Path, Line, Region, or any of the other 2D building blocks.= From John_Smith at symantec.com Thu Dec 6 15:06:23 2012 From: John_Smith at symantec.com (John Smith) Date: Thu, 6 Dec 2012 15:06:23 -0800 Subject: JavaFX performance for complex visualisations In-Reply-To: <001501cdd38c$790782f0$6b1688d0$@com.au> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <001501cdd38c$790782f0$6b1688d0$@com.au> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D22160AF1BF7D@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> > The smoothness issue is a bit baffling. On my desktop PC (which is virtually a super computer and includes the world's fastest GPU), all the animations in Ensemble are very "unsmooth", that is to say that even the simple Translate transition demo displays a jumpy red ball moving from side to side. It's so jumpy that it looks like I am actually running it on a hand-held calculator or similar! ... Do you have any ideas on what is causing this and/or suggestions on how to improve things? I had exactly the same problem on a Quad core Windows XP machine with Radeon HD 4600. I tried upgrading drivers, JavaFX versions, logging jira issues, etc and never fixed it. Then I upgraded to Windows 7 and everything worked perfectly on the same machine - animations were super smooth. As it seemed related to an antiquated OS, I didn't worry about it after it was working. -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of John C. Turnbull Sent: Thursday, December 06, 2012 12:34 AM To: 'Richard Bair' Cc: openjfx-dev at openjdk.java.net Subject: RE: JavaFX performance for complex visualisations Thanks for responding to this Richard. The smoothness issue is a bit baffling. On my desktop PC (which is virtually a super computer and includes the world's fastest GPU), all the animations in Ensemble are very "unsmooth", that is to say that even the simple Translate transition demo displays a jumpy red ball moving from side to side. It's so jumpy that it looks like I am actually running it on a hand-held calculator or similar! Conversely, the same demo on my 5-year-old laptop is "super smooth" and indeed all the Ensemble demos run extremely impressively on this machine. Do you have any ideas on what is causing this and/or suggestions on how to improve things? Anyway, I am very excited by the question you posed at the end of your reply in relation to building a graphics intensive demo application with JavaFX. Another thread has started dealing with the type of game or application that would be suitable but the thing for me which is most important is that this demo *not* be a clone of some simple existing game but rather be truly graphics intensive and demanding. One suggestion was to re-implement Asteroids because "If we can't handle an old 8-bit game from the early 80's with nice fluid animations then we can give up and go home" but to me this would be exactly what *not* to do. The idea that JavaFX should be capable of fluid animations for an old style game is fine but what have we proved if the app does indeed run smoothly using JavaFX? Nothing really. We *must* focus on something which would not have run on an old 8-bit computer. Something that would test Flash today on reasonably powered modern machines. Something that actually *requires* a UI toolkit as powerful and advanced as JavaFX (or is supposed to be). Otherwise we have not achieved anything. Whatever is chosen, I will contribute in any way I can :-) -jct -----Original Message----- From: Richard Bair [mailto:richard.bair at oracle.com] Sent: Wednesday, 5 December 2012 07:24 To: John C. Turnbull Cc: openjfx-dev at openjdk.java.net Subject: Re: JavaFX performance for complex visualisations Hi John, Just getting through my email and have had this one flagged since Devoxx :-). I respond below to individual points but most of these are probably not worth you responding back on (they're just informational on my part) -- rather, down at the end is the real question I want to have a discussion on (and will be a lot of fun to solve while we're at it). > 1. Do any such games, animations or visualisations exist yet? Yes. Much like Swing, JavaFX is seeing a lot of adoption in the heavy enterprise desktop sorts of use cases -- not the kind of thing you will find when browsing the internet. Most of these folks don't advertise the technology they're using, and most of them are not interested in letting their competitors know what they're doing or what technology they're using. Which basically means, if we haven't built a demo for it, there isn't anything you will find in your travels. > 2. If not, how does Oracle or anyone else actually know that JavaFX is > capable of supporting such applications? That is a good question. Many of the folks I've talked to building such applications have done incredible work + proof of concepts long before I even knew they were using JavaFX. Now, each year we do pretty graphically intense demos for JavaOne, so we have a pretty good feel for it. We have a bunch of benchmarks where we crank the number of nodes up to pretty high numbers, and we know from these benchmarks (at least) that we scale very well compared to other technologies. But I know neither the samples nor the results are publicly available. But at least I can answer the "how does Oracle . know" part of the question. We have had a performance team from the get-go who were solely dedicated to writing benchmarks, running benchmarks, and analyzing results. This has been incredibly helpful. We have results that come not just from the weekly integrations but even from intra-week builds on specific scrum repositories. We have benchmarks and analysis for both desktop and embedded and take performance very seriously. Now, there are a lot of ways to use the platform. Some things are better tuned than others. Performance work is driven by tuning and benchmarks. So when we run into issues we have to (a) determine how likely that is to be an issue to the broader development community (b) figure out what the tradeoffs are (usually performance & quality are directly in contradiction with each other), and ( c) schedule & implement the fix. Of course, the same few people (Jim, mostly) are involved in many of the performance fixes and features (like Canvas), so scheduling is an issue and feedback from customers as to what they are actually running into (vs. what a theoretical issue is) has priority. > 3. Do I have the wrong understanding that JavaFX is supposed to > support such applications? We expect that JavaFX will be usable for casual games, but we are not building a gaming platform to compete with Unity and the like. If we happen to be just as good, then that's awesome, but it isn't our primary goal. Advanced visualizations, on the other hand, are part of our target market (medical, pharma, enterprise desktop, etc) > 4. Is it possible that, for whatever reason, JavaFX is simply not > capable of supporting such applications? There are natural trade-offs between an immediate mode (like Canvas) API and a retained mode (like Scene Graph) API. Now that we have both (plus Java2D + ImageWriter and such for the really crazy cases) we should be capable of a wide range of use cases. However, some things are not yet optimized. But there is no technical reason why we shouldn't be quite capable. Another area we have not yet exposed API which is problematic for some people is in the area of custom shaders. It may be that without some kind of custom shader support (which would have to be made to work on D3D as well as OpenGL) certain use cases cannot be easily fulfilled. > My feeling that JavaFX can indeed support such applications is based > on the fact that it is hardware accelerated and therefore it should be > limited mostly by the capabilities of the graphics card and also > because it is often talked about in this way. However, I have > observed varying levels of performance that don't quite follow these > principles such as JavaFX performing poorly with choppy/jittery > animations and transitions on my most powerful machine with an NVIDIA > GeForce GTX 690 (the current fastest graphics card in the world) but > performing quite well on machines with much lower specifications. It is highly unlikely that this is due to performance issues. As mentioned in the last few days on another thread, there are smoothness issues that are completely separate from performance (although both are often talked about together). We're working on the smoothness. Sometimes this is an application problem as opposed to a platform problem (one such example is the DisplayShelf sample, which needs to be rewritten). > So I guess I am curious to know what kinds of testing and evaluations > Oracle has undertaken to determine the performance characteristics of > JavaFX and exactly what kinds of applications it is actually suitable > for. For example, I am yet to see any JavaFX application with even > the sophistication of a Flash electronic greeting card or banner ad > and yet I assume JavaFX will be used for such purposes eventually. I would imagine any of our demos from the last 3-4 years of JavaOne would demonstrate much more complicated use cases than that! But, instead of me just complaining -- lets build one! We'll add it both to Ensemble and our test suite. We can start with something simple (like a greeting card) and expand it out to something wildly complex. What would you like to see? One thing I've wanted to build for years but haven't found the time for was a tower defense game. But what would you think would be a good example of graphics performance that would tell you "hey, this platform is great for visualizations"? Richard From zonski at gmail.com Thu Dec 6 15:24:36 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 7 Dec 2012 10:24:36 +1100 Subject: JavaFX performance for complex visualisations In-Reply-To: <008601cdd404$6f9d2620$4ed77260$@com.au> References: <008601cdd404$6f9d2620$4ed77260$@com.au> Message-ID: <3BFC16C1-0E69-4827-89A1-30D6B0203A70@gmail.com> In theory the same basic engine for tower defender is that of Warcraft or Command & Conquer, etc. And this could be 2D or 3D once we get the base in place. Ie you can make your maps, sprites and explosions as complex as you like with lots of shapes, sub animations, textures, shadings, etc. First we walk, then we run, then we flap our arms, jump off a cliff and see what happens. On 07/12/2012, at 9:52 AM, "John C. Turnbull" wrote: > Yes, whilst a 3D stress test is vital in the longer term, what we need right > now is something that shows off the true capabilities of 2D JavaFX. > > Again though, I agree with Pedro in that we should be aiming for something > as complex as possible. > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net > [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Richard Bair > Sent: Friday, 7 December 2012 09:39 > To: Pedro Duque Vieira > Cc: OpenJFX Mailing List > Subject: Re: JavaFX performance for complex visualisations > >> I think if you're into doing games than you should go with something >> 3D, it won't require that much of engineering to do something 3D that >> could make people impressed. Javafx 8 brings bump mapping, a lightning >> system, etc, all stuff that could wonder the user with not much of an > effort. > > The problem with 3D is that it exercises *completely* different code paths > from 2D rendering. So it would be good to do a 3D stress test as well, > although that code is not yet available, and it doesn't tell us anything > about the performance of the platform when doing Path, Line, Region, or any > of the other 2D building blocks.= > From hang.vo at oracle.com Thu Dec 6 15:32:40 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 06 Dec 2012 23:32:40 +0000 Subject: hg: openjfx/8/controls/rt: fix RT-18448 [Slider] label formatter is not applicable + unit test Message-ID: <20121206233241.D487147F5C@hg.openjdk.java.net> Changeset: ee46c5bb984f Author: Paru Somashekar Date: 2012-12-06 15:24 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ee46c5bb984f fix RT-18448 [Slider] label formatter is not applicable + unit test ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SliderSkin.java ! javafx-ui-controls/src/javafx/scene/chart/Axis.java ! javafx-ui-controls/src/javafx/scene/chart/ValueAxis.java ! javafx-ui-controls/test/javafx/scene/control/SliderTest.java From hang.vo at oracle.com Thu Dec 6 15:47:24 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 06 Dec 2012 23:47:24 +0000 Subject: hg: openjfx/8/controls/rt: RT-18448: cleaned up the previous patch. Message-ID: <20121206234725.3D67047F61@hg.openjdk.java.net> Changeset: e8d1d5ae5f78 Author: Paru Somashekar Date: 2012-12-06 15:51 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e8d1d5ae5f78 RT-18448: cleaned up the previous patch. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SliderSkin.java From hang.vo at oracle.com Thu Dec 6 16:17:29 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 07 Dec 2012 00:17:29 +0000 Subject: hg: openjfx/8/graphics/rt: Fix for RT-26100. This change should have no functional impact, but I changed the defaults to match with the multipliers hard-coded into NGRegion. Message-ID: <20121207001732.909D047F72@hg.openjdk.java.net> Changeset: ffd89bb359f1 Author: rbair Date: 2012-12-06 16:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ffd89bb359f1 Fix for RT-26100. This change should have no functional impact, but I changed the defaults to match with the multipliers hard-coded into NGRegion. ! javafx-ui-common/src/javafx/scene/layout/BorderStrokeStyle.java From hang.vo at oracle.com Thu Dec 6 16:26:21 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 07 Dec 2012 00:26:21 +0000 Subject: hg: openjfx/8/master/rt: 25 new changesets Message-ID: <20121207002650.8A7F747F76@hg.openjdk.java.net> Changeset: 54d464a6ade7 Author: Felipe Heidrich Date: 2012-11-27 15:31 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/54d464a6ade7 RT-23492: Text method(s) accept null, app blows up later ! javafx-ui-common/src/javafx/scene/text/Text.java Changeset: 573f5535e6a1 Author: Martin Sladecek Date: 2012-11-28 10:18 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/573f5535e6a1 RT-25776 Animation. Cycles are not equivalent in SequentialTransition ! javafx-ui-common/src/javafx/animation/ParallelTransition.java ! javafx-ui-common/src/javafx/animation/SequentialTransition.java ! javafx-ui-common/src/javafx/animation/Transition.java ! javafx-ui-common/test/unit/javafx/animation/TransitionTest.java Changeset: fc5cf98c8d33 Author: Martin Sladecek Date: 2012-11-28 10:19 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fc5cf98c8d33 merge Changeset: 3a6dcc5adb79 Author: Martin Sladecek Date: 2012-11-28 12:41 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3a6dcc5adb79 Fixed test failure ! javafx-ui-common/test/unit/javafx/animation/AnimationMock.java Changeset: b2e8a63feae9 Author: Martin Sladecek Date: 2012-11-28 12:41 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b2e8a63feae9 merge Changeset: 42c3818c5c85 Author: Milan Kubec Date: 2012-11-28 15:23 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/42c3818c5c85 adding QA related assertions to documentation ! javafx-fxml/src/javafx/fxml/doc-files/introduction_to_fxml.html Changeset: ef5f81064000 Author: Felipe Heidrich Date: 2012-11-28 16:51 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ef5f81064000 RT-26171: Add RTL support to Text node ! javafx-ui-common/src/com/sun/javafx/scene/text/TextLayout.java ! javafx-ui-common/src/javafx/scene/text/Text.java Changeset: 26d62927eb5b Author: Martin Sladecek Date: 2012-11-29 10:18 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/26d62927eb5b RT-26517, RT-26544 SequentialTransition and ParallelTransition fixes. ! javafx-ui-common/src/javafx/animation/ParallelTransition.java ! javafx-ui-common/src/javafx/animation/SequentialTransition.java Changeset: 535735e49872 Author: Martin Sladecek Date: 2012-11-29 10:18 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/535735e49872 merge Changeset: 5ad236b5f3ed Author: tb115823 Date: 2012-11-29 09:42 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5ad236b5f3ed Changed names of tests to enable junit test runner to pick them - javafx-fxml/test/javafx/fxml/RT_14880.java + javafx-fxml/test/javafx/fxml/RT_14880Test.java - javafx-fxml/test/javafx/fxml/RT_15524.java + javafx-fxml/test/javafx/fxml/RT_15524Test.java - javafx-fxml/test/javafx/fxml/RT_16722.java + javafx-fxml/test/javafx/fxml/RT_16722Test.java - javafx-fxml/test/javafx/fxml/RT_16724.java + javafx-fxml/test/javafx/fxml/RT_16724Test.java - javafx-fxml/test/javafx/fxml/RT_16815.java + javafx-fxml/test/javafx/fxml/RT_16815Test.java - javafx-fxml/test/javafx/fxml/RT_16977.java + javafx-fxml/test/javafx/fxml/RT_16977Test.java - javafx-fxml/test/javafx/fxml/RT_17646.java + javafx-fxml/test/javafx/fxml/RT_17646Test.java - javafx-fxml/test/javafx/fxml/RT_17714.java + javafx-fxml/test/javafx/fxml/RT_17714Test.java - javafx-fxml/test/javafx/fxml/RT_18046.java + javafx-fxml/test/javafx/fxml/RT_18046Test.java - javafx-fxml/test/javafx/fxml/RT_18218.java + javafx-fxml/test/javafx/fxml/RT_18218Test.java - javafx-fxml/test/javafx/fxml/RT_18680.java + javafx-fxml/test/javafx/fxml/RT_18680Test.java - javafx-fxml/test/javafx/fxml/RT_18933.java + javafx-fxml/test/javafx/fxml/RT_18933Test.java - javafx-fxml/test/javafx/fxml/RT_19008.java + javafx-fxml/test/javafx/fxml/RT_19008Test.java - javafx-fxml/test/javafx/fxml/RT_19112.java + javafx-fxml/test/javafx/fxml/RT_19112Test.java - javafx-fxml/test/javafx/fxml/RT_19139.java + javafx-fxml/test/javafx/fxml/RT_19139Test.java - javafx-fxml/test/javafx/fxml/RT_19228.java + javafx-fxml/test/javafx/fxml/RT_19228Test.java - javafx-fxml/test/javafx/fxml/RT_19329.java + javafx-fxml/test/javafx/fxml/RT_19329Test.java - javafx-fxml/test/javafx/fxml/RT_19870.java + javafx-fxml/test/javafx/fxml/RT_19870Test.java - javafx-fxml/test/javafx/fxml/RT_20082.java + javafx-fxml/test/javafx/fxml/RT_20082Test.java - javafx-fxml/test/javafx/fxml/RT_20471.java + javafx-fxml/test/javafx/fxml/RT_20471Test.java - javafx-fxml/test/javafx/fxml/RT_21559.java + javafx-fxml/test/javafx/fxml/RT_21559Test.java - javafx-fxml/test/javafx/fxml/RT_22864.java + javafx-fxml/test/javafx/fxml/RT_22864Test.java - javafx-fxml/test/javafx/fxml/RT_22971.java + javafx-fxml/test/javafx/fxml/RT_22971Test.java - javafx-fxml/test/javafx/fxml/RT_23244.java + javafx-fxml/test/javafx/fxml/RT_23244Test.java - javafx-fxml/test/javafx/fxml/RT_23413.java + javafx-fxml/test/javafx/fxml/RT_23413Test.java - javafx-fxml/test/javafx/fxml/RT_24380.java + javafx-fxml/test/javafx/fxml/RT_24380Test.java Changeset: 812543070c61 Author: tb115823 Date: 2012-11-29 10:09 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/812543070c61 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt - javafx-fxml/test/javafx/fxml/RT_14880.java - javafx-fxml/test/javafx/fxml/RT_15524.java - javafx-fxml/test/javafx/fxml/RT_16722.java - javafx-fxml/test/javafx/fxml/RT_16724.java - javafx-fxml/test/javafx/fxml/RT_16815.java - javafx-fxml/test/javafx/fxml/RT_16977.java - javafx-fxml/test/javafx/fxml/RT_17646.java - javafx-fxml/test/javafx/fxml/RT_17714.java - javafx-fxml/test/javafx/fxml/RT_18046.java - javafx-fxml/test/javafx/fxml/RT_18218.java - javafx-fxml/test/javafx/fxml/RT_18680.java - javafx-fxml/test/javafx/fxml/RT_18933.java - javafx-fxml/test/javafx/fxml/RT_19008.java - javafx-fxml/test/javafx/fxml/RT_19112.java - javafx-fxml/test/javafx/fxml/RT_19139.java - javafx-fxml/test/javafx/fxml/RT_19228.java - javafx-fxml/test/javafx/fxml/RT_19329.java - javafx-fxml/test/javafx/fxml/RT_19870.java - javafx-fxml/test/javafx/fxml/RT_20082.java - javafx-fxml/test/javafx/fxml/RT_20471.java - javafx-fxml/test/javafx/fxml/RT_21559.java - javafx-fxml/test/javafx/fxml/RT_22864.java - javafx-fxml/test/javafx/fxml/RT_22971.java - javafx-fxml/test/javafx/fxml/RT_23244.java - javafx-fxml/test/javafx/fxml/RT_23413.java - javafx-fxml/test/javafx/fxml/RT_24380.java Changeset: 99e8153aadac Author: tb115823 Date: 2012-11-29 12:27 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/99e8153aadac Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt - javafx-fxml/test/javafx/fxml/RT_14880.java - javafx-fxml/test/javafx/fxml/RT_15524.java - javafx-fxml/test/javafx/fxml/RT_16722.java - javafx-fxml/test/javafx/fxml/RT_16724.java - javafx-fxml/test/javafx/fxml/RT_16815.java - javafx-fxml/test/javafx/fxml/RT_16977.java - javafx-fxml/test/javafx/fxml/RT_17646.java - javafx-fxml/test/javafx/fxml/RT_17714.java - javafx-fxml/test/javafx/fxml/RT_18046.java - javafx-fxml/test/javafx/fxml/RT_18218.java - javafx-fxml/test/javafx/fxml/RT_18680.java - javafx-fxml/test/javafx/fxml/RT_18933.java - javafx-fxml/test/javafx/fxml/RT_19008.java - javafx-fxml/test/javafx/fxml/RT_19112.java - javafx-fxml/test/javafx/fxml/RT_19139.java - javafx-fxml/test/javafx/fxml/RT_19228.java - javafx-fxml/test/javafx/fxml/RT_19329.java - javafx-fxml/test/javafx/fxml/RT_19870.java - javafx-fxml/test/javafx/fxml/RT_20082.java - javafx-fxml/test/javafx/fxml/RT_20471.java - javafx-fxml/test/javafx/fxml/RT_21559.java - javafx-fxml/test/javafx/fxml/RT_22864.java - javafx-fxml/test/javafx/fxml/RT_22971.java - javafx-fxml/test/javafx/fxml/RT_23244.java - javafx-fxml/test/javafx/fxml/RT_23413.java - javafx-fxml/test/javafx/fxml/RT_24380.java Changeset: f41875afbcf6 Author: Felipe Heidrich Date: 2012-11-29 08:45 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f41875afbcf6 RT-26171- adding missing override tag ! javafx-ui-common/src/javafx/scene/text/Text.java Changeset: fcce9e4370aa Author: Felipe Heidrich Date: 2012-11-29 19:57 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fcce9e4370aa RT-26590: Text unit test failure after adding RTL support ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextLayout.java Changeset: 005267bc4e2e Author: rbair Date: 2012-11-30 13:25 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/005267bc4e2e Fix for RT-25973: BorderConverter should not be public API ! javafx-ui-common/src/javafx/scene/layout/BorderConverter.java Changeset: 204b00c41d61 Author: rbair Date: 2012-11-30 15:23 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/204b00c41d61 Removed unused property that was added in 8.0 erroneously. Fix for RT-25937 ! javafx-ui-common/src/javafx/scene/layout/Region.java Changeset: ad9bea38bfbe Author: tb115823 Date: 2012-12-03 09:53 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ad9bea38bfbe fix build failure. Reference to nonexisting classes after rename of test classes ! javafx-fxml/test/javafx/fxml/RT_22971Controller.java ! javafx-fxml/test/javafx/fxml/RT_23413Test.java Changeset: 8e88ab8b8bcc Author: tb115823 Date: 2012-12-03 09:55 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8e88ab8b8bcc Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt Changeset: 1a0cf70decaf Author: Seeon Birger Date: 2012-11-26 20:01 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1a0cf70decaf RT-26478: Restored call to fxvk.setPrefWidth(VK_WIDTH) that was removed by a fix to RT-25181. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java Changeset: 496c1bca757f Author: David Hill Date: 2012-11-28 13:40 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/496c1bca757f Automated merge with ssh://javafxsrc.us.oracle.com//javafx/8.0/scrum//graphics/jfx/rt Changeset: fa1ad3d3186a Author: David Hill Date: 2012-12-03 10:53 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fa1ad3d3186a Automated merge with ssh://javafxsrc.us.oracle.com//javafx/8.0/scrum//embedded/jfx/rt - javafx-fxml/test/javafx/fxml/RT_14880.java - javafx-fxml/test/javafx/fxml/RT_15524.java - javafx-fxml/test/javafx/fxml/RT_16722.java - javafx-fxml/test/javafx/fxml/RT_16724.java - javafx-fxml/test/javafx/fxml/RT_16815.java - javafx-fxml/test/javafx/fxml/RT_16977.java - javafx-fxml/test/javafx/fxml/RT_17646.java - javafx-fxml/test/javafx/fxml/RT_17714.java - javafx-fxml/test/javafx/fxml/RT_18046.java - javafx-fxml/test/javafx/fxml/RT_18218.java - javafx-fxml/test/javafx/fxml/RT_18680.java - javafx-fxml/test/javafx/fxml/RT_18933.java - javafx-fxml/test/javafx/fxml/RT_19008.java - javafx-fxml/test/javafx/fxml/RT_19112.java - javafx-fxml/test/javafx/fxml/RT_19139.java - javafx-fxml/test/javafx/fxml/RT_19228.java - javafx-fxml/test/javafx/fxml/RT_19329.java - javafx-fxml/test/javafx/fxml/RT_19870.java - javafx-fxml/test/javafx/fxml/RT_20082.java - javafx-fxml/test/javafx/fxml/RT_20471.java - javafx-fxml/test/javafx/fxml/RT_21559.java - javafx-fxml/test/javafx/fxml/RT_22864.java - javafx-fxml/test/javafx/fxml/RT_22971.java - javafx-fxml/test/javafx/fxml/RT_23244.java - javafx-fxml/test/javafx/fxml/RT_23413.java - javafx-fxml/test/javafx/fxml/RT_24380.java Changeset: 501088150d56 Author: tb115823 Date: 2012-12-04 10:01 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/501088150d56 Fix no runnable method errors in tests. Disable test RT-23413 + javafx-fxml/test/javafx/fxml/RT_21559.java - javafx-fxml/test/javafx/fxml/RT_21559Test.java + javafx-fxml/test/javafx/fxml/RT_22864.java - javafx-fxml/test/javafx/fxml/RT_22864Test.java + javafx-fxml/test/javafx/fxml/RT_23244.java - javafx-fxml/test/javafx/fxml/RT_23244Test.java ! javafx-fxml/test/javafx/fxml/RT_23413Test.java Changeset: fbce04284f89 Author: tb115823 Date: 2012-12-04 16:04 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fbce04284f89 fix fxml test RT-23413. Added warmup before actual performance comparison ! javafx-fxml/test/javafx/fxml/RT_23413Test.java Changeset: 9353d8ea7c4b Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-12-04 09:37 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9353d8ea7c4b Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-fxml/test/javafx/fxml/RT_14880.java - javafx-fxml/test/javafx/fxml/RT_15524.java - javafx-fxml/test/javafx/fxml/RT_16722.java - javafx-fxml/test/javafx/fxml/RT_16724.java - javafx-fxml/test/javafx/fxml/RT_16815.java - javafx-fxml/test/javafx/fxml/RT_16977.java - javafx-fxml/test/javafx/fxml/RT_17646.java - javafx-fxml/test/javafx/fxml/RT_17714.java - javafx-fxml/test/javafx/fxml/RT_18046.java - javafx-fxml/test/javafx/fxml/RT_18218.java - javafx-fxml/test/javafx/fxml/RT_18680.java - javafx-fxml/test/javafx/fxml/RT_18933.java - javafx-fxml/test/javafx/fxml/RT_19008.java - javafx-fxml/test/javafx/fxml/RT_19112.java - javafx-fxml/test/javafx/fxml/RT_19139.java - javafx-fxml/test/javafx/fxml/RT_19228.java - javafx-fxml/test/javafx/fxml/RT_19329.java - javafx-fxml/test/javafx/fxml/RT_19870.java - javafx-fxml/test/javafx/fxml/RT_20082.java - javafx-fxml/test/javafx/fxml/RT_20471.java ! javafx-fxml/test/javafx/fxml/RT_21559.java ! javafx-fxml/test/javafx/fxml/RT_22864.java - javafx-fxml/test/javafx/fxml/RT_22971.java ! javafx-fxml/test/javafx/fxml/RT_23244.java - javafx-fxml/test/javafx/fxml/RT_23413.java - javafx-fxml/test/javafx/fxml/RT_24380.java Changeset: 4fb083d0a750 Author: hudson Date: 2012-12-06 16:19 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4fb083d0a750 Added tag 8.0-b67 for changeset 9353d8ea7c4b ! .hgtags From ozemale at ozemail.com.au Thu Dec 6 18:10:49 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Fri, 7 Dec 2012 13:10:49 +1100 Subject: JavaFX performance for complex visualisations In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D22160AF1BF7D@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <907F4BF0-7067-4539-B88B-AD12D30E6D94@oracle.com> <001501cdd38c$790782f0$6b1688d0$@com.au> <411E73D23DEC4C46BA48F2B6D8BF3D22160AF1BF7D@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <00a601cdd420$14092cc0$3c1b8640$@com.au> Unfortunately I am already running Windows 7! So there must be another reason in my case. -----Original Message----- From: John Smith [mailto:John_Smith at symantec.com] Sent: Friday, 7 December 2012 10:06 To: John C. Turnbull; 'Richard Bair' Cc: openjfx-dev at openjdk.java.net Subject: RE: JavaFX performance for complex visualisations > The smoothness issue is a bit baffling. On my desktop PC (which is virtually a super computer and includes the world's fastest GPU), all the animations in Ensemble are very "unsmooth", that is to say that even the simple Translate transition demo displays a jumpy red ball moving from side to side. It's so jumpy that it looks like I am actually running it on a hand-held calculator or similar! ... Do you have any ideas on what is causing this and/or suggestions on how to improve things? I had exactly the same problem on a Quad core Windows XP machine with Radeon HD 4600. I tried upgrading drivers, JavaFX versions, logging jira issues, etc and never fixed it. Then I upgraded to Windows 7 and everything worked perfectly on the same machine - animations were super smooth. As it seemed related to an antiquated OS, I didn't worry about it after it was working. -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of John C. Turnbull Sent: Thursday, December 06, 2012 12:34 AM To: 'Richard Bair' Cc: openjfx-dev at openjdk.java.net Subject: RE: JavaFX performance for complex visualisations Thanks for responding to this Richard. The smoothness issue is a bit baffling. On my desktop PC (which is virtually a super computer and includes the world's fastest GPU), all the animations in Ensemble are very "unsmooth", that is to say that even the simple Translate transition demo displays a jumpy red ball moving from side to side. It's so jumpy that it looks like I am actually running it on a hand-held calculator or similar! Conversely, the same demo on my 5-year-old laptop is "super smooth" and indeed all the Ensemble demos run extremely impressively on this machine. Do you have any ideas on what is causing this and/or suggestions on how to improve things? Anyway, I am very excited by the question you posed at the end of your reply in relation to building a graphics intensive demo application with JavaFX. Another thread has started dealing with the type of game or application that would be suitable but the thing for me which is most important is that this demo *not* be a clone of some simple existing game but rather be truly graphics intensive and demanding. One suggestion was to re-implement Asteroids because "If we can't handle an old 8-bit game from the early 80's with nice fluid animations then we can give up and go home" but to me this would be exactly what *not* to do. The idea that JavaFX should be capable of fluid animations for an old style game is fine but what have we proved if the app does indeed run smoothly using JavaFX? Nothing really. We *must* focus on something which would not have run on an old 8-bit computer. Something that would test Flash today on reasonably powered modern machines. Something that actually *requires* a UI toolkit as powerful and advanced as JavaFX (or is supposed to be). Otherwise we have not achieved anything. Whatever is chosen, I will contribute in any way I can :-) -jct -----Original Message----- From: Richard Bair [mailto:richard.bair at oracle.com] Sent: Wednesday, 5 December 2012 07:24 To: John C. Turnbull Cc: openjfx-dev at openjdk.java.net Subject: Re: JavaFX performance for complex visualisations Hi John, Just getting through my email and have had this one flagged since Devoxx :-). I respond below to individual points but most of these are probably not worth you responding back on (they're just informational on my part) -- rather, down at the end is the real question I want to have a discussion on (and will be a lot of fun to solve while we're at it). > 1. Do any such games, animations or visualisations exist yet? Yes. Much like Swing, JavaFX is seeing a lot of adoption in the heavy enterprise desktop sorts of use cases -- not the kind of thing you will find when browsing the internet. Most of these folks don't advertise the technology they're using, and most of them are not interested in letting their competitors know what they're doing or what technology they're using. Which basically means, if we haven't built a demo for it, there isn't anything you will find in your travels. > 2. If not, how does Oracle or anyone else actually know that JavaFX is > capable of supporting such applications? That is a good question. Many of the folks I've talked to building such applications have done incredible work + proof of concepts long before I even knew they were using JavaFX. Now, each year we do pretty graphically intense demos for JavaOne, so we have a pretty good feel for it. We have a bunch of benchmarks where we crank the number of nodes up to pretty high numbers, and we know from these benchmarks (at least) that we scale very well compared to other technologies. But I know neither the samples nor the results are publicly available. But at least I can answer the "how does Oracle . know" part of the question. We have had a performance team from the get-go who were solely dedicated to writing benchmarks, running benchmarks, and analyzing results. This has been incredibly helpful. We have results that come not just from the weekly integrations but even from intra-week builds on specific scrum repositories. We have benchmarks and analysis for both desktop and embedded and take performance very seriously. Now, there are a lot of ways to use the platform. Some things are better tuned than others. Performance work is driven by tuning and benchmarks. So when we run into issues we have to (a) determine how likely that is to be an issue to the broader development community (b) figure out what the tradeoffs are (usually performance & quality are directly in contradiction with each other), and ( c) schedule & implement the fix. Of course, the same few people (Jim, mostly) are involved in many of the performance fixes and features (like Canvas), so scheduling is an issue and feedback from customers as to what they are actually running into (vs. what a theoretical issue is) has priority. > 3. Do I have the wrong understanding that JavaFX is supposed to > support such applications? We expect that JavaFX will be usable for casual games, but we are not building a gaming platform to compete with Unity and the like. If we happen to be just as good, then that's awesome, but it isn't our primary goal. Advanced visualizations, on the other hand, are part of our target market (medical, pharma, enterprise desktop, etc) > 4. Is it possible that, for whatever reason, JavaFX is simply not > capable of supporting such applications? There are natural trade-offs between an immediate mode (like Canvas) API and a retained mode (like Scene Graph) API. Now that we have both (plus Java2D + ImageWriter and such for the really crazy cases) we should be capable of a wide range of use cases. However, some things are not yet optimized. But there is no technical reason why we shouldn't be quite capable. Another area we have not yet exposed API which is problematic for some people is in the area of custom shaders. It may be that without some kind of custom shader support (which would have to be made to work on D3D as well as OpenGL) certain use cases cannot be easily fulfilled. > My feeling that JavaFX can indeed support such applications is based > on the fact that it is hardware accelerated and therefore it should be > limited mostly by the capabilities of the graphics card and also > because it is often talked about in this way. However, I have > observed varying levels of performance that don't quite follow these > principles such as JavaFX performing poorly with choppy/jittery > animations and transitions on my most powerful machine with an NVIDIA > GeForce GTX 690 (the current fastest graphics card in the world) but > performing quite well on machines with much lower specifications. It is highly unlikely that this is due to performance issues. As mentioned in the last few days on another thread, there are smoothness issues that are completely separate from performance (although both are often talked about together). We're working on the smoothness. Sometimes this is an application problem as opposed to a platform problem (one such example is the DisplayShelf sample, which needs to be rewritten). > So I guess I am curious to know what kinds of testing and evaluations > Oracle has undertaken to determine the performance characteristics of > JavaFX and exactly what kinds of applications it is actually suitable > for. For example, I am yet to see any JavaFX application with even > the sophistication of a Flash electronic greeting card or banner ad > and yet I assume JavaFX will be used for such purposes eventually. I would imagine any of our demos from the last 3-4 years of JavaOne would demonstrate much more complicated use cases than that! But, instead of me just complaining -- lets build one! We'll add it both to Ensemble and our test suite. We can start with something simple (like a greeting card) and expand it out to something wildly complex. What would you like to see? One thing I've wanted to build for years but haven't found the time for was a tower defense game. But what would you think would be a good example of graphics performance that would tell you "hey, this platform is great for visualizations"? Richard From jonathan.giles at oracle.com Thu Dec 6 23:13:14 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 07 Dec 2012 20:13:14 +1300 Subject: Survey: JavaFX on tablets and mobile devices Message-ID: <50C1970A.2030901@oracle.com> Hi all, If you're the least bit interested in JavaFX on mobile devices (and it seems a few of you are), I'd really appreciate you making your voice heard over at FX Experience: http://fxexperience.com/2012/12/javafx-for-tablets-mobile/ I know that the cynical among you will question why this is necessary, that your voices should have already been heard, and that it is 'too little, too late'. Please indulge me this one last time - I'd really appreciate it - and I promise that your feedback will be heard by all the right people. Thanks, -- Jonathan From Claus.Luethje at osys.ch Thu Dec 6 23:33:55 2012 From: Claus.Luethje at osys.ch (Claus Luethje) Date: Fri, 7 Dec 2012 07:33:55 +0000 Subject: JavaFX performance for complex visualisations In-Reply-To: <3BFC16C1-0E69-4827-89A1-30D6B0203A70@gmail.com> References: <008601cdd404$6f9d2620$4ed77260$@com.au>, <3BFC16C1-0E69-4827-89A1-30D6B0203A70@gmail.com> Message-ID: I'm interested in JavaFX in the enterprise, so a 3D game is Am 07.12.2012 um 00:26 schrieb "Daniel Zwolenski" : > In theory the same basic engine for tower defender is that of Warcraft or Command & Conquer, etc. And this could be 2D or 3D once we get the base in place. > > Ie you can make your maps, sprites and explosions as complex as you like with lots of shapes, sub animations, textures, shadings, etc. > > First we walk, then we run, then we flap our arms, jump off a cliff and see what happens. > > > > On 07/12/2012, at 9:52 AM, "John C. Turnbull" wrote: > >> Yes, whilst a 3D stress test is vital in the longer term, what we need right >> now is something that shows off the true capabilities of 2D JavaFX. >> >> Again though, I agree with Pedro in that we should be aiming for something >> as complex as possible. >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net >> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Richard Bair >> Sent: Friday, 7 December 2012 09:39 >> To: Pedro Duque Vieira >> Cc: OpenJFX Mailing List >> Subject: Re: JavaFX performance for complex visualisations >> >>> I think if you're into doing games than you should go with something >>> 3D, it won't require that much of engineering to do something 3D that >>> could make people impressed. Javafx 8 brings bump mapping, a lightning >>> system, etc, all stuff that could wonder the user with not much of an >> effort. >> >> The problem with 3D is that it exercises *completely* different code paths >> from 2D rendering. So it would be good to do a 3D stress test as well, >> although that code is not yet available, and it doesn't tell us anything >> about the performance of the platform when doing Path, Line, Region, or any >> of the other 2D building blocks.= >> From Claus.Luethje at osys.ch Thu Dec 6 23:50:02 2012 From: Claus.Luethje at osys.ch (Claus Luethje) Date: Fri, 7 Dec 2012 07:50:02 +0000 Subject: JavaFX performance for complex visualisations In-Reply-To: References: <008601cdd404$6f9d2620$4ed77260$@com.au>, <3BFC16C1-0E69-4827-89A1-30D6B0203A70@gmail.com>, Message-ID: My mobile finished this mail early ;-) What I wanted to say was, that although I see the sexyness of a 3D game for awareness, 2D is more what I see with our customers. Our customers want consistent speed and a versatile framework, which let's us adopt their wishes quickly (Many got burned with browser apps.) What we saw from JavaFX in the last year, it can handle the latter. A game is certainly not what our customers care much about, but if it shows speed and the ease of achieving it, we can position our JavaFX offerings. I'd go with a 2D game first and a tower defense game might be good, although I'd like to see full screen scrolling, with lots of shapes (think complex workflow diagrams). Just my 0.02$ Regards Claus Am 07.12.2012 um 08:35 schrieb "Claus Luethje" : > I'm interested in JavaFX in the enterprise, so a 3D game is > > > > Am 07.12.2012 um 00:26 schrieb "Daniel Zwolenski" : > >> In theory the same basic engine for tower defender is that of Warcraft or Command & Conquer, etc. And this could be 2D or 3D once we get the base in place. >> >> Ie you can make your maps, sprites and explosions as complex as you like with lots of shapes, sub animations, textures, shadings, etc. >> >> First we walk, then we run, then we flap our arms, jump off a cliff and see what happens. >> >> >> >> On 07/12/2012, at 9:52 AM, "John C. Turnbull" wrote: >> >>> Yes, whilst a 3D stress test is vital in the longer term, what we need right >>> now is something that shows off the true capabilities of 2D JavaFX. >>> >>> Again though, I agree with Pedro in that we should be aiming for something >>> as complex as possible. >>> >>> -----Original Message----- >>> From: openjfx-dev-bounces at openjdk.java.net >>> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Richard Bair >>> Sent: Friday, 7 December 2012 09:39 >>> To: Pedro Duque Vieira >>> Cc: OpenJFX Mailing List >>> Subject: Re: JavaFX performance for complex visualisations >>> >>>> I think if you're into doing games than you should go with something >>>> 3D, it won't require that much of engineering to do something 3D that >>>> could make people impressed. Javafx 8 brings bump mapping, a lightning >>>> system, etc, all stuff that could wonder the user with not much of an >>> effort. >>> >>> The problem with 3D is that it exercises *completely* different code paths >>> from 2D rendering. So it would be good to do a 3D stress test as well, >>> although that code is not yet available, and it doesn't tell us anything >>> about the performance of the platform when doing Path, Line, Region, or any >>> of the other 2D building blocks.= >>> From ozemale at ozemail.com.au Fri Dec 7 00:00:00 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Fri, 7 Dec 2012 19:00:00 +1100 Subject: Survey: JavaFX on tablets and mobile devices In-Reply-To: <50C1970A.2030901@oracle.com> References: <50C1970A.2030901@oracle.com> Message-ID: <00e501cdd450$db4ed020$91ec7060$@com.au> Jonathan, For me and for countless others getting JavaFX support for mobiles and tablets is way ahead of any other issue facing this technology. What's the point of investing all this time and effort into something that only runs on a platform which is in steep decline (i.e. the desktop)? I know I am stating the obvious but JavaFX will fizzle out into a niche product if it doesn't support these modern platforms (and *soon*). OK, so it seems you already get this but yes, I do wonder why we need to "tell you" again in this form :-) Whatever the reason, could you or someone else from Oracle please clearly outline exactly what it is going to take to get JavaFX onto these mobile and tablets: 1. How much will Oracle do? 2. How much is dependent on the community? 3. Who is going to coordinate the whole process? 4. When will it commence? 5. When will we be able to sell our iOS apps written in JavaFX? 6. Are there any issues (technical, political etc.) that are currently insurmountable? 7. Will iOS/Android/WP8 apps be indistinguishable from native apps (i.e. look and feel, performance)? 8. Has Oracle management committed to providing the funds to see this project through to the end? I am sure I am not the only one who would love to see definitive answers to these questions! -jct -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Jonathan Giles Sent: Friday, 7 December 2012 18:13 To: openjfx-dev at openjdk.java.net Subject: Survey: JavaFX on tablets and mobile devices Hi all, If you're the least bit interested in JavaFX on mobile devices (and it seems a few of you are), I'd really appreciate you making your voice heard over at FX Experience: http://fxexperience.com/2012/12/javafx-for-tablets-mobile/ I know that the cynical among you will question why this is necessary, that your voices should have already been heard, and that it is 'too little, too late'. Please indulge me this one last time - I'd really appreciate it - and I promise that your feedback will be heard by all the right people. Thanks, -- Jonathan From tobi at ultramixer.com Fri Dec 7 00:11:19 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Fri, 7 Dec 2012 09:11:19 +0100 Subject: Survey: JavaFX on tablets and mobile devices In-Reply-To: <00e501cdd450$db4ed020$91ec7060$@com.au> References: <50C1970A.2030901@oracle.com> <00e501cdd450$db4ed020$91ec7060$@com.au> Message-ID: <1C82AE0C-0E19-4CFF-9FD7-A8E08A6EAFDF@ultramixer.com> +1! Am 07.12.2012 um 09:00 schrieb "John C. Turnbull" : > Jonathan, > > For me and for countless others getting JavaFX support for mobiles and > tablets is way ahead of any other issue facing this technology. What's the > point of investing all this time and effort into something that only runs on > a platform which is in steep decline (i.e. the desktop)? I know I am > stating the obvious but JavaFX will fizzle out into a niche product if it > doesn't support these modern platforms (and *soon*). > > OK, so it seems you already get this but yes, I do wonder why we need to > "tell you" again in this form :-) > > Whatever the reason, could you or someone else from Oracle please clearly > outline exactly what it is going to take to get JavaFX onto these mobile and > tablets: > > 1. How much will Oracle do? > 2. How much is dependent on the community? > 3. Who is going to coordinate the whole process? > 4. When will it commence? > 5. When will we be able to sell our iOS apps written in JavaFX? > 6. Are there any issues (technical, political etc.) that are currently > insurmountable? > 7. Will iOS/Android/WP8 apps be indistinguishable from native apps (i.e. > look and feel, performance)? > 8. Has Oracle management committed to providing the funds to see this > project through to the end? > > I am sure I am not the only one who would love to see definitive answers to > these questions! > > -jct > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net > [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Jonathan Giles > Sent: Friday, 7 December 2012 18:13 > To: openjfx-dev at openjdk.java.net > Subject: Survey: JavaFX on tablets and mobile devices > > Hi all, > > If you're the least bit interested in JavaFX on mobile devices (and it seems > a few of you are), I'd really appreciate you making your voice heard over at > FX Experience: > > http://fxexperience.com/2012/12/javafx-for-tablets-mobile/ > > I know that the cynical among you will question why this is necessary, that > your voices should have already been heard, and that it is 'too little, too > late'. Please indulge me this one last time - I'd really appreciate it - and > I promise that your feedback will be heard by all the right people. > > Thanks, > -- Jonathan > From johan at lodgon.com Fri Dec 7 00:31:52 2012 From: johan at lodgon.com (Johan Vos) Date: Fri, 7 Dec 2012 09:31:52 +0100 Subject: Survey: JavaFX on tablets and mobile devices In-Reply-To: <00e501cdd450$db4ed020$91ec7060$@com.au> References: <50C1970A.2030901@oracle.com> <00e501cdd450$db4ed020$91ec7060$@com.au> Message-ID: Hi, I think Jonathan, Richard, Jasper and most/all Oracle developers on this mailinglist agree that JavaFX support for mobile/tablets is crucial. However, some people that make strategic decisions inside Oracle are probably not on this list and they don't hear our concerns. Our developer-concerns need to be turned into something that shows them there is added value in the market, business goals, increased adoption, blabla,... Strategic decisions will not (only) be based on what we discuss on this mailinglist, but rather on some concrete requests/use-cases Jonathan and others can show. So if filling in a form (with information I already provided a number of times, I agree that is boring) is what it takes to get official support for JavaFX on mobile/tablet, I'm more than happy to spend 10 minutes on it. We're all on the same side here, I believe. - Johan 2012/12/7 John C. Turnbull > Jonathan, > > For me and for countless others getting JavaFX support for mobiles and > tablets is way ahead of any other issue facing this technology. What's the > point of investing all this time and effort into something that only runs > on > a platform which is in steep decline (i.e. the desktop)? I know I am > stating the obvious but JavaFX will fizzle out into a niche product if it > doesn't support these modern platforms (and *soon*). > > OK, so it seems you already get this but yes, I do wonder why we need to > "tell you" again in this form :-) > > Whatever the reason, could you or someone else from Oracle please clearly > outline exactly what it is going to take to get JavaFX onto these mobile > and > tablets: > > 1. How much will Oracle do? > 2. How much is dependent on the community? > 3. Who is going to coordinate the whole process? > 4. When will it commence? > 5. When will we be able to sell our iOS apps written in JavaFX? > 6. Are there any issues (technical, political etc.) that are currently > insurmountable? > 7. Will iOS/Android/WP8 apps be indistinguishable from native apps (i.e. > look and feel, performance)? > 8. Has Oracle management committed to providing the funds to see this > project through to the end? > > I am sure I am not the only one who would love to see definitive answers to > these questions! > > -jct > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net > [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Jonathan Giles > Sent: Friday, 7 December 2012 18:13 > To: openjfx-dev at openjdk.java.net > Subject: Survey: JavaFX on tablets and mobile devices > > Hi all, > > If you're the least bit interested in JavaFX on mobile devices (and it > seems > a few of you are), I'd really appreciate you making your voice heard over > at > FX Experience: > > http://fxexperience.com/2012/12/javafx-for-tablets-mobile/ > > I know that the cynical among you will question why this is necessary, that > your voices should have already been heard, and that it is 'too little, too > late'. Please indulge me this one last time - I'd really appreciate it - > and > I promise that your feedback will be heard by all the right people. > > Thanks, > -- Jonathan > > From randahl at rockit.dk Fri Dec 7 00:59:20 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Fri, 7 Dec 2012 09:59:20 +0100 Subject: What is the priority of the JavaFX thread? In-Reply-To: <50C11B97.1060909@oracle.com> References: <06CA53D9-C4EF-4547-9E5A-48BD584B48D8@rockit.dk> <81F3CE81-A205-4A5C-A999-2546825A049D@oracle.com> <50C11702.4020203@oracle.com> <50C11B97.1060909@oracle.com> Message-ID: <61309309-6FDC-493C-B167-53C2494A72B2@rockit.dk> I am on Mac OS 10.8.2 using Java version: 1.7.0_12-ea Java vendor: Oracle Corporation JavaFX version: 2.2.6-ea-b01 Randahl On Dec 6, 2012, at 23:26 , steve.x.northover at oracle.com wrote: > At some point a while back, I played around with making operating system calls to boost thread priority. It did nothing to improve rendering, however, it could be sensitive to the example code. What platform are you on? > > Steve > > On 06/12/2012 5:06 PM, Kevin Rushforth wrote: >> I doubt this is related to thread priorities, but it would be worth verifying. More likely it's the interaction of thread scheduling, timers, and vsync. >> >> -- Kevin >> >> >> Richard Bair wrote: >>> I don't *think* we set any thread priorities. I have tried different thread priorities in apps in the past (such as lowering the priority of background threads) and it didn't make a difference. I should look at the concurrent APIs in javaFX and see if they still set the thread priority?in fact it does. But I haven't noticed any app behavior that changed by doing so. But I haven't tried to set the thread priority from anywhere but within Java, and I'm on a mac, so maybe it works differently (although I am pretty certain I've talked to VM engineers who have said thread priorities are ignored on HotSpot). >>> >>> Richard >>> >>> On Dec 6, 2012, at 12:41 PM, Randahl Fink Isaksen wrote: >>> >>>> Does JavaFX intentionally set a priority for the JavaFX thread? I would very much like to hear what the decision behind setting or not setting such a priority is. >>>> >>>> The reason I am asking is, on my development Mac, it seems the JavaFX thread is easily starved by other CPU load, and I was thinking if the developers of JavaFX did or did not expect application developers to manage JavaFX thread priority. >>>> >>>> Thanks >>>> >>>> Randahl >>> From hendrik.ebbers at me.com Fri Dec 7 00:59:59 2012 From: hendrik.ebbers at me.com (Hendrik Ebbers) Date: Fri, 07 Dec 2012 08:59:59 +0000 (GMT) Subject: Survey: JavaFX on tablets and mobile devices In-Reply-To: Message-ID: <7d1d3a4a-a139-41e9-aed4-b73a3b25a559@me.com> +1 Am 07. Dezember 2012 um 09:31 schrieb Johan Vos : Hi, I think Jonathan, Richard, Jasper and most/all Oracle developers on this mailinglist agree that JavaFX support for mobile/tablets is crucial. However, some people that make strategic decisions inside Oracle are probably not on this list and they don't hear our concerns. Our developer-concerns need to be turned into something that shows them there is added value in the market, business goals, increased adoption, blabla,... Strategic decisions will not (only) be based on what we discuss on this mailinglist, but rather on some concrete requests/use-cases Jonathan and others can show. So if filling in a form (with information I already provided a number of times, I agree that is boring) is what it takes to get official support for JavaFX on mobile/tablet, I'm more than happy to spend 10 minutes on it. We're all on the same side here, I believe. - Johan 2012/12/7 John C. Turnbull > Jonathan, > > For me and for countless others getting JavaFX support for mobiles and > tablets is way ahead of any other issue facing this technology. What's the > point of investing all this time and effort into something that only runs > on > a platform which is in steep decline (i.e. the desktop)? I know I am > stating the obvious but JavaFX will fizzle out into a niche product if it > doesn't support these modern platforms (and *soon*). > > OK, so it seems you already get this but yes, I do wonder why we need to > "tell you" again in this form :-) > > Whatever the reason, could you or someone else from Oracle please clearly > outline exactly what it is going to take to get JavaFX onto these mobile > and > tablets: > > 1. How much will Oracle do? > 2. How much is dependent on the community? > 3. Who is going to coordinate the whole process? > 4. When will it commence? > 5. When will we be able to sell our iOS apps written in JavaFX? > 6. Are there any issues (technical, political etc.) that are currently > insurmountable? > 7. Will iOS/Android/WP8 apps be indistinguishable from native apps (i.e. > look and feel, performance)? > 8. Has Oracle management committed to providing the funds to see this > project through to the end? > > I am sure I am not the only one who would love to see definitive answers to > these questions! > > -jct > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net > [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Jonathan Giles > Sent: Friday, 7 December 2012 18:13 > To: openjfx-dev at openjdk.java.net > Subject: Survey: JavaFX on tablets and mobile devices > > Hi all, > > If you're the least bit interested in JavaFX on mobile devices (and it > seems > a few of you are), I'd really appreciate you making your voice heard over > at > FX Experience: > > http://fxexperience.com/2012/12/javafx-for-tablets-mobile/ > > I know that the cynical among you will question why this is necessary, that > your voices should have already been heard, and that it is 'too little, too > late'. Please indulge me this one last time - I'd really appreciate it - > and > I promise that your feedback will be heard by all the right people. > > Thanks, > -- Jonathan > > From randahl at rockit.dk Fri Dec 7 01:00:33 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Fri, 7 Dec 2012 10:00:33 +0100 Subject: Request for comments: Styling precedence proposal Message-ID: Richard Bair and I had a useful discussion about the potential conflict between visual properties set by CSS and visual properties set in Java using properties (see RT-16395). I have pondered some more on this, because it really makes me cringe when I set a background color in Java by invoking setStyle("-fx-background-color:green"); Why? Because this can easily be misspelled, and is not type safe. I think this could be improved by adding real Java properties and introducing a precedence concept, and the following paragraphs explains my idea in detail. As developers we are already used to visual property precedence when working with CSS, where visual properties specified through style classes are applied first, and then the properties specified with the style attribute are applied ? in other words style ends up taking precedence over class (last applied wins). This is straight forward. JavaFX is also straight forward, in the sense that if you don't set a Java property, CSS wins, and if you do set a Java property, you win. That is a good system. The only problem is, not all visual properties have corresponding Java properties ? there is no setBackgroundColor on Region, for instance, even though the -fx-background-color sets it. What I am suggesting, is giving each visual property a real, type safe, Java property and a precedence rule, configurable through a map on each stylable Node in the scene graph. I suggest defining the precedence as follows: public enum Precedence { JAVA, //what we have today ? will be the default STYLE } Here, Precendence.JAVA, works just like JavaFX 2.2.6 does today, meaning that a visual property, such as the fill of a Text, takes on the value defined by 1. The value of a the Java property fill set using the setFill method, or if not set 2. The -fx-text-fill set using the style property, or if still not set 3. The -fx-text-fill defined using the assigned CSS classes. In other words: The Java value wins if it is set by the developer. I propose this will be the default, so that JavaFX remains backwards compatible. The other alternative, Precendence.STYLE means that a visual property, again exemplified by the fill of a Text, takes the value defined by 1. The -fx-text-fill set using the style property, or if not set 2. The -fx-text-fill defined using the assigned CSS classes, and if still not set 3. The value of a corresponding Java property fill of the Text set using setFill. The precedence concept would require substantial changes to the JavaFX API, but I think these changes are worthwhile because they ensure we can get real, type safe, good old Java properties for each and every visual property in JavaFX. The changes would entail 1. More properties: All visual properties of a stylable node would be exposed as real Java properties, through methods such as setBackgroundColor, or getBackgroundColor. Many of these already exists (getEffect, setTextAligment, etc.). 2. A precedences map: All stylable nodes would get a new map property called precedences, accessible through a getPrecedences() method, where each precedence is kept. Initially the map would be empty, which means all properties have Precedence.JAVA, but you could change this by invoking getPrecedences().put("backgroundColor", Precedence.STYLE). 3. An appearances map: All stylable nodes would get another new map property called appearances, accessible through a getAppearances() method, where JavaFX automatically puts the final rendered values. So, if you invoke setBackgroundColor(Color.RED) on a node which has no precedence set for the property, or which has a precedence of JAVA, everything works just like today: You set the color to RED and it ends up red on screen. The new thing is that it ends up red because JavaFX checks your precedence rules and sees that the JAVA value takes precedence, and sets the rendered value to red by automatically invoking getAppearances().put("backgroundColor", Color.RED) for you. Note that this means you can check the map and get a precise answer, if you want to know what it looks like to your application users (great for debugging). Now, if you continue and invoke setStyle("-fx-background-color: blue") and Precedence is still JAVA (the default), a call to getApperances().get("background-color") would yield Color.RED, because the JAVA property you set first still takes precedence. Finally, if you then invoked getPrecedences().put("backgroundColor", Precedence.STYLE) then JavaFX would automatically update the appearance and getAppearances().get("background-color") would return Color.BLUE. That is a lot of new API, so the obvious question is: Is it worth it? Personally, I think this approach is a huge benefit, because now developers can control which properties are locked to the value set by the developer (Precedence.JAVA) and which value is freely stylable by the designer (Precedence.STYLE). But most importantly, we now have a well-defined approach to adding real, type-safe, Java object properties for each and every visual property in JavaFX, which means we can get rid of the non-type-safe setStyle calls. I am very interested in hearing comments from people on this list before deciding wether to file or not to file a Jira issue for this. Thanks Randahl From randahl at rockit.dk Fri Dec 7 01:04:05 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Fri, 7 Dec 2012 10:04:05 +0100 Subject: Survey: JavaFX on tablets and mobile devices In-Reply-To: <50C1970A.2030901@oracle.com> References: <50C1970A.2030901@oracle.com> Message-ID: <54196C48-3FB5-433D-A873-FF51D09E6561@rockit.dk> Jonathan, have you posted the survey on Twitter with #javafx as well? I think it is very important, you are heard. Thanks for creating the survey Randahl On Dec 7, 2012, at 8:13 , Jonathan Giles wrote: > Hi all, > > If you're the least bit interested in JavaFX on mobile devices (and it seems a few of you are), I'd really appreciate you making your voice heard over at FX Experience: > > http://fxexperience.com/2012/12/javafx-for-tablets-mobile/ > > I know that the cynical among you will question why this is necessary, that your voices should have already been heard, and that it is 'too little, too late'. Please indulge me this one last time - I'd really appreciate it - and I promise that your feedback will be heard by all the right people. > > Thanks, > -- Jonathan From jonathan.giles at oracle.com Fri Dec 7 01:05:36 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 07 Dec 2012 22:05:36 +1300 Subject: Survey: JavaFX on tablets and mobile devices In-Reply-To: <54196C48-3FB5-433D-A873-FF51D09E6561@rockit.dk> References: <50C1970A.2030901@oracle.com> <54196C48-3FB5-433D-A873-FF51D09E6561@rockit.dk> Message-ID: <50C1B160.2070305@oracle.com> Yes, Twitter has been appropriately spammed. -- Jonathan On 7/12/2012 10:04 p.m., Randahl Fink Isaksen wrote: > Jonathan, have you posted the survey on Twitter with #javafx as well? I think it is very important, you are heard. > > Thanks for creating the survey > > Randahl > > > On Dec 7, 2012, at 8:13 , Jonathan Giles wrote: > >> Hi all, >> >> If you're the least bit interested in JavaFX on mobile devices (and it seems a few of you are), I'd really appreciate you making your voice heard over at FX Experience: >> >> http://fxexperience.com/2012/12/javafx-for-tablets-mobile/ >> >> I know that the cynical among you will question why this is necessary, that your voices should have already been heard, and that it is 'too little, too late'. Please indulge me this one last time - I'd really appreciate it - and I promise that your feedback will be heard by all the right people. >> >> Thanks, >> -- Jonathan From Claus.Luethje at osys.ch Fri Dec 7 00:42:07 2012 From: Claus.Luethje at osys.ch (Claus Luethje) Date: Fri, 7 Dec 2012 08:42:07 +0000 Subject: Survey: JavaFX on tablets and mobile devices In-Reply-To: References: <50C1970A.2030901@oracle.com> <00e501cdd450$db4ed020$91ec7060$@com.au>, Message-ID: +1 Am 07.12.2012 um 09:33 schrieb "Johan Vos" : > Hi, > > I think Jonathan, Richard, Jasper and most/all Oracle developers on this > mailinglist agree that JavaFX support for mobile/tablets is crucial. > > However, some people that make strategic decisions inside Oracle are > probably not on this list and they don't hear our concerns. > Our developer-concerns need to be turned into something that shows them > there is added value in the market, business goals, increased adoption, > blabla,... > Strategic decisions will not (only) be based on what we discuss on this > mailinglist, but rather on some concrete requests/use-cases Jonathan and > others can show. > > So if filling in a form (with information I already provided a number of > times, I agree that is boring) is what it takes to get official support for > JavaFX on mobile/tablet, I'm more than happy to spend 10 minutes on it. > > We're all on the same side here, I believe. > > - Johan > > > 2012/12/7 John C. Turnbull > >> Jonathan, >> >> For me and for countless others getting JavaFX support for mobiles and >> tablets is way ahead of any other issue facing this technology. What's the >> point of investing all this time and effort into something that only runs >> on >> a platform which is in steep decline (i.e. the desktop)? I know I am >> stating the obvious but JavaFX will fizzle out into a niche product if it >> doesn't support these modern platforms (and *soon*). >> >> OK, so it seems you already get this but yes, I do wonder why we need to >> "tell you" again in this form :-) >> >> Whatever the reason, could you or someone else from Oracle please clearly >> outline exactly what it is going to take to get JavaFX onto these mobile >> and >> tablets: >> >> 1. How much will Oracle do? >> 2. How much is dependent on the community? >> 3. Who is going to coordinate the whole process? >> 4. When will it commence? >> 5. When will we be able to sell our iOS apps written in JavaFX? >> 6. Are there any issues (technical, political etc.) that are currently >> insurmountable? >> 7. Will iOS/Android/WP8 apps be indistinguishable from native apps (i.e. >> look and feel, performance)? >> 8. Has Oracle management committed to providing the funds to see this >> project through to the end? >> >> I am sure I am not the only one who would love to see definitive answers to >> these questions! >> >> -jct >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net >> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Jonathan Giles >> Sent: Friday, 7 December 2012 18:13 >> To: openjfx-dev at openjdk.java.net >> Subject: Survey: JavaFX on tablets and mobile devices >> >> Hi all, >> >> If you're the least bit interested in JavaFX on mobile devices (and it >> seems >> a few of you are), I'd really appreciate you making your voice heard over >> at >> FX Experience: >> >> http://fxexperience.com/2012/12/javafx-for-tablets-mobile/ >> >> I know that the cynical among you will question why this is necessary, that >> your voices should have already been heard, and that it is 'too little, too >> late'. Please indulge me this one last time - I'd really appreciate it - >> and >> I promise that your feedback will be heard by all the right people. >> >> Thanks, >> -- Jonathan >> >> From neugens.limasoftware at gmail.com Fri Dec 7 01:10:22 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 7 Dec 2012 10:10:22 +0100 Subject: What is the priority of the JavaFX thread? In-Reply-To: <06CA53D9-C4EF-4547-9E5A-48BD584B48D8@rockit.dk> References: <06CA53D9-C4EF-4547-9E5A-48BD584B48D8@rockit.dk> Message-ID: I may be completely off, but in my experience Thread priorities only have any impact on realtime or quasi-realtime OS, and they need to be honoured by VM (which I believe is not the case for HotSpot, but I may be wrong). Cheers, Mario 2012/12/6 Randahl Fink Isaksen : > Does JavaFX intentionally set a priority for the JavaFX thread? I would very much like to hear what the decision behind setting or not setting such a priority is. > > The reason I am asking is, on my development Mac, it seems the JavaFX thread is easily starved by other CPU load, and I was thinking if the developers of JavaFX did or did not expect application developers to manage JavaFX thread priority. > > Thanks > > Randahl -- 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 ozemale at ozemail.com.au Fri Dec 7 02:09:01 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Fri, 7 Dec 2012 21:09:01 +1100 Subject: Survey: JavaFX on tablets and mobile devices In-Reply-To: References: <50C1970A.2030901@oracle.com> <00e501cdd450$db4ed020$91ec7060$@com.au> Message-ID: <011301cdd462$e1670100$a4350300$@com.au> Yes, it is patently clear that the people who actually do the development work for JavaFX are well aware of the need for it to run on mobiles and tablets for the technology to be a success. All of the people you mentioned are very passionate about what they do and that is very pleasing to see. We are definitely all on the same side! I guess I am just surprised that the people who make the funding decisions can't see what's going on and need surveys to form their opinion. But as you say, if that's all it's going to take then I'll do the survey 100 times. Probably like many other people, I am willing to do whatever it takes. -jct From: johanlodgon at gmail.com [mailto:johanlodgon at gmail.com] On Behalf Of Johan Vos Sent: Friday, 7 December 2012 19:32 To: John C. Turnbull Cc: jonathan.giles at oracle.com; openjfx-dev at openjdk.java.net Subject: Re: Survey: JavaFX on tablets and mobile devices Hi, I think Jonathan, Richard, Jasper and most/all Oracle developers on this mailinglist agree that JavaFX support for mobile/tablets is crucial. However, some people that make strategic decisions inside Oracle are probably not on this list and they don't hear our concerns. Our developer-concerns need to be turned into something that shows them there is added value in the market, business goals, increased adoption, blabla,... Strategic decisions will not (only) be based on what we discuss on this mailinglist, but rather on some concrete requests/use-cases Jonathan and others can show. So if filling in a form (with information I already provided a number of times, I agree that is boring) is what it takes to get official support for JavaFX on mobile/tablet, I'm more than happy to spend 10 minutes on it. We're all on the same side here, I believe. - Johan 2012/12/7 John C. Turnbull Jonathan, For me and for countless others getting JavaFX support for mobiles and tablets is way ahead of any other issue facing this technology. What's the point of investing all this time and effort into something that only runs on a platform which is in steep decline (i.e. the desktop)? I know I am stating the obvious but JavaFX will fizzle out into a niche product if it doesn't support these modern platforms (and *soon*). OK, so it seems you already get this but yes, I do wonder why we need to "tell you" again in this form :-) Whatever the reason, could you or someone else from Oracle please clearly outline exactly what it is going to take to get JavaFX onto these mobile and tablets: 1. How much will Oracle do? 2. How much is dependent on the community? 3. Who is going to coordinate the whole process? 4. When will it commence? 5. When will we be able to sell our iOS apps written in JavaFX? 6. Are there any issues (technical, political etc.) that are currently insurmountable? 7. Will iOS/Android/WP8 apps be indistinguishable from native apps (i.e. look and feel, performance)? 8. Has Oracle management committed to providing the funds to see this project through to the end? I am sure I am not the only one who would love to see definitive answers to these questions! -jct -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Jonathan Giles Sent: Friday, 7 December 2012 18:13 To: openjfx-dev at openjdk.java.net Subject: Survey: JavaFX on tablets and mobile devices Hi all, If you're the least bit interested in JavaFX on mobile devices (and it seems a few of you are), I'd really appreciate you making your voice heard over at FX Experience: http://fxexperience.com/2012/12/javafx-for-tablets-mobile/ I know that the cynical among you will question why this is necessary, that your voices should have already been heard, and that it is 'too little, too late'. Please indulge me this one last time - I'd really appreciate it - and I promise that your feedback will be heard by all the right people. Thanks, -- Jonathan From pedro.duquevieira at gmail.com Fri Dec 7 03:40:09 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Fri, 7 Dec 2012 11:40:09 +0000 Subject: Request for comments: Styling precedence proposal Message-ID: Hi, I think you should split this into 3 different requests: 1- add java properties to each visual property 2- enable setting precedence rules For point 1 I totally agree with you, but I was under the impression this was already on the roadmap and will be available on javafx 8 when skins become public. At least I started an argument about it a while back and one of the points I wanted to include was this and was under the impression it would be included. Thanks, cheers, -- Pedro Duque Vieira From hang.vo at oracle.com Fri Dec 7 04:17:58 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 07 Dec 2012 12:17:58 +0000 Subject: hg: openjfx/8/graphics/rt: RT-25494 Cycle detection in fxml includes Message-ID: <20121207121805.20B6547FB0@hg.openjdk.java.net> Changeset: 34ae31eab256 Author: tb115823 Date: 2012-12-07 12:56 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/34ae31eab256 RT-25494 Cycle detection in fxml includes ! javafx-fxml/src/javafx/fxml/FXMLLoader.java + javafx-fxml/test/javafx/fxml/RT_25494_Cycle_DetectionTest.java + javafx-fxml/test/javafx/fxml/cycle.fxml + javafx-fxml/test/javafx/fxml/dummy-cycle.fxml + javafx-fxml/test/javafx/fxml/leaf1.fxml + javafx-fxml/test/javafx/fxml/leaf2.fxml + javafx-fxml/test/javafx/fxml/leaf3.fxml + javafx-fxml/test/javafx/fxml/leaf4.fxml + javafx-fxml/test/javafx/fxml/one-2-one-cycle.fxml From randahl at rockit.dk Fri Dec 7 05:48:56 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Fri, 7 Dec 2012 14:48:56 +0100 Subject: Article: Supporting multiple screen resolutions Message-ID: <001FC65C-A8B0-4CF3-AE3E-B1BC551BB59A@rockit.dk> Reading the latest posts on this list about the challenges of supporting retina displays inspired me to publish a new article on how I achieved multiple screen resolution support with JavaFX. http://blog.randahl.dk/2012/12/javafx-designing-for-multiple-screen.html I hope others may save some time by reading about the techniques that proved useful in my JavaFX app. Randahl From tobi at ultramixer.com Fri Dec 7 06:15:17 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Fri, 7 Dec 2012 15:15:17 +0100 Subject: Article: Supporting multiple screen resolutions In-Reply-To: <001FC65C-A8B0-4CF3-AE3E-B1BC551BB59A@rockit.dk> References: <001FC65C-A8B0-4CF3-AE3E-B1BC551BB59A@rockit.dk> Message-ID: Did you find a solution to build a JavaFX2 app for MacBook Pro Retina? Am 07.12.2012 um 14:48 schrieb Randahl Fink Isaksen : > Reading the latest posts on this list about the challenges of supporting retina displays inspired me to publish a new article on how I achieved multiple screen resolution support with JavaFX. > > http://blog.randahl.dk/2012/12/javafx-designing-for-multiple-screen.html > > I hope others may save some time by reading about the techniques that proved useful in my JavaFX app. > > Randahl From david.grieve at oracle.com Fri Dec 7 06:36:21 2012 From: david.grieve at oracle.com (David Grieve) Date: Fri, 7 Dec 2012 09:36:21 -0500 Subject: Request for comments: Styling precedence proposal In-Reply-To: References: Message-ID: I find this all somewhat confusing and I'm not following how this ensures "real, type safe, good old Java properties for each and every visual property in JavaFX." I believe a consistent policy is best. From lowest to highest, importance being equal, the order of precedence is: 1. user agent stylesheet styles 2. values set by calls to setXXX, e.g., setFill 3. scene stylesheet styles 4. inline styles, i.e., styles from setStyle This order of precedence ensures that a call to setXXX won't be overridden by a user agent stylesheet, but can be overridden by an external or inline style. Imagine you have a stop-light widget and you use setFill to color the lights red, yellow and green. This proves difficult for your color blind friend who can't discern red-green. So your friend adds his own stylesheet to color the lights in a way that is easier to distinguish. This is they way it should work. In my opinion, setStyle should seldom, if ever, be used and then should be used to with lookup values so that the style can still be overridden, for example, setStyle("-fx-background-color: -my-background-color;") You may also be interested in providing input on http://javafx-jira.kenai.com/browse/RT-17293 http://javafx-jira.kenai.com/browse/RT-24214 and the proposed public API for CSS (https://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls). On Dec 7, 2012, at 4:00 AM, Randahl Fink Isaksen wrote: > Richard Bair and I had a useful discussion about the potential conflict between visual properties set by CSS and visual properties set in Java using properties (see RT-16395). > > I have pondered some more on this, because it really makes me cringe when I set a background color in Java by invoking > > setStyle("-fx-background-color:green"); > > Why? Because this can easily be misspelled, and is not type safe. > > I think this could be improved by adding real Java properties and introducing a precedence concept, and the following paragraphs explains my idea in detail. > > > As developers we are already used to visual property precedence when working with CSS, where visual properties specified through style classes are applied first, and then the properties specified with the style attribute are applied ? in other words style ends up taking precedence over class (last applied wins). > > This is straight forward. JavaFX is also straight forward, in the sense that if you don't set a Java property, CSS wins, and if you do set a Java property, you win. That is a good system. The only problem is, not all visual properties have corresponding Java properties ? there is no setBackgroundColor on Region, for instance, even though the -fx-background-color sets it. > > What I am suggesting, is giving each visual property a real, type safe, Java property and a precedence rule, configurable through a map on each stylable Node in the scene graph. I suggest defining the precedence as follows: > > public enum Precedence { > JAVA, //what we have today ? will be the default > STYLE > } > > Here, Precendence.JAVA, works just like JavaFX 2.2.6 does today, meaning that a visual property, such as the fill of a Text, takes on the value defined by > > 1. The value of a the Java property fill set using the setFill method, or if not set > 2. The -fx-text-fill set using the style property, or if still not set > 3. The -fx-text-fill defined using the assigned CSS classes. > > In other words: The Java value wins if it is set by the developer. I propose this will be the default, so that JavaFX remains backwards compatible. > > The other alternative, Precendence.STYLE means that a visual property, again exemplified by the fill of a Text, takes the value defined by > > 1. The -fx-text-fill set using the style property, or if not set > 2. The -fx-text-fill defined using the assigned CSS classes, and if still not set > 3. The value of a corresponding Java property fill of the Text set using setFill. > > > The precedence concept would require substantial changes to the JavaFX API, but I think these changes are worthwhile because they ensure we can get real, type safe, good old Java properties for each and every visual property in JavaFX. > > The changes would entail > > 1. More properties: All visual properties of a stylable node would be exposed as real Java properties, through methods such as setBackgroundColor, or getBackgroundColor. Many of these already exists (getEffect, setTextAligment, etc.). > 2. A precedences map: All stylable nodes would get a new map property called precedences, accessible through a getPrecedences() method, where each precedence is kept. Initially the map would be empty, which means all properties have Precedence.JAVA, but you could change this by invoking getPrecedences().put("backgroundColor", Precedence.STYLE). > 3. An appearances map: All stylable nodes would get another new map property called appearances, accessible through a getAppearances() method, where JavaFX automatically puts the final rendered values. > > So, if you invoke setBackgroundColor(Color.RED) on a node which has no precedence set for the property, or which has a precedence of JAVA, everything works just like today: You set the color to RED and it ends up red on screen. The new thing is that it ends up red because JavaFX checks your precedence rules and sees that the JAVA value takes precedence, and sets the rendered value to red by automatically invoking getAppearances().put("backgroundColor", Color.RED) for you. Note that this means you can check the map and get a precise answer, if you want to know what it looks like to your application users (great for debugging). > > Now, if you continue and invoke setStyle("-fx-background-color: blue") and Precedence is still JAVA (the default), a call to getApperances().get("background-color") would yield Color.RED, because the JAVA property you set first still takes precedence. > > Finally, if you then invoked getPrecedences().put("backgroundColor", Precedence.STYLE) then JavaFX would automatically update the appearance and getAppearances().get("background-color") would return Color.BLUE. > > That is a lot of new API, so the obvious question is: Is it worth it? Personally, I think this approach is a huge benefit, because now developers can control which properties are locked to the value set by the developer (Precedence.JAVA) and which value is freely stylable by the designer (Precedence.STYLE). But most importantly, we now have a well-defined approach to adding real, type-safe, Java object properties for each and every visual property in JavaFX, which means we can get rid of the non-type-safe setStyle calls. > > I am very interested in hearing comments from people on this list before deciding wether to file or not to file a Jira issue for this. > > Thanks > > Randahl From tomas.brandalik at oracle.com Fri Dec 7 06:49:11 2012 From: tomas.brandalik at oracle.com (tomas.brandalik) Date: Fri, 07 Dec 2012 15:49:11 +0100 Subject: Survey: JavaFX on tablets and mobile devices In-Reply-To: <011301cdd462$e1670100$a4350300$@com.au> References: <50C1970A.2030901@oracle.com> <00e501cdd450$db4ed020$91ec7060$@com.au> <011301cdd462$e1670100$a4350300$@com.au> Message-ID: <50C201E7.9030308@oracle.com> Hi jct, I can speak about Android only since I had been working on Android prototype for some time. iOS is surely another story. Android platform has become fragmented almost like good old j2me. Everyone is aware that development and testing would require significant resources. I think Richard is right that finishing opensourcing (glass and prism) is crucial and will help greatly in creating new ports. It will make Android port ideal for community to step in and start to participate in javafx development and testing too. Ideal because it already has some building blocks ready, at least a toolchain and a jvm with jit (dalvik). What concerns me is how easy/difficult can community developer start such complex thing like a new jfx port. Submitting a patch or even a new control seems to be a much simpler task in terms of existing infrastructure. There is a review process, hudson builds, functional and performance testing for supported platforms which simply processes stuff incoming from community. This is something that should Oracle help with and it should be clarified. -Tomas On 12/07/2012 11:09 AM, John C. Turnbull wrote: > Yes, it is patently clear that the people who actually do the development > work for JavaFX are well aware of the need for it to run on mobiles and > tablets for the technology to be a success. All of the people you mentioned > are very passionate about what they do and that is very pleasing to see. > > > > We are definitely all on the same side! I guess I am just surprised that > the people who make the funding decisions can't see what's going on and need > surveys to form their opinion. > > > > But as you say, if that's all it's going to take then I'll do the survey 100 > times. Probably like many other people, I am willing to do whatever it > takes. > > > > -jct > > > > From: johanlodgon at gmail.com [mailto:johanlodgon at gmail.com] On Behalf Of > Johan Vos > Sent: Friday, 7 December 2012 19:32 > To: John C. Turnbull > Cc: jonathan.giles at oracle.com; openjfx-dev at openjdk.java.net > Subject: Re: Survey: JavaFX on tablets and mobile devices > > > > Hi, > > I think Jonathan, Richard, Jasper and most/all Oracle developers on this > mailinglist agree that JavaFX support for mobile/tablets is crucial. > > However, some people that make strategic decisions inside Oracle are > probably not on this list and they don't hear our concerns. > Our developer-concerns need to be turned into something that shows them > there is added value in the market, business goals, increased adoption, > blabla,... > Strategic decisions will not (only) be based on what we discuss on this > mailinglist, but rather on some concrete requests/use-cases Jonathan and > others can show. > > So if filling in a form (with information I already provided a number of > times, I agree that is boring) is what it takes to get official support for > JavaFX on mobile/tablet, I'm more than happy to spend 10 minutes on it. > > We're all on the same side here, I believe. > > - Johan > > > > 2012/12/7 John C. Turnbull > > Jonathan, > > For me and for countless others getting JavaFX support for mobiles and > tablets is way ahead of any other issue facing this technology. What's the > point of investing all this time and effort into something that only runs on > a platform which is in steep decline (i.e. the desktop)? I know I am > stating the obvious but JavaFX will fizzle out into a niche product if it > doesn't support these modern platforms (and *soon*). > > OK, so it seems you already get this but yes, I do wonder why we need to > "tell you" again in this form :-) > > Whatever the reason, could you or someone else from Oracle please clearly > outline exactly what it is going to take to get JavaFX onto these mobile and > tablets: > > 1. How much will Oracle do? > 2. How much is dependent on the community? > 3. Who is going to coordinate the whole process? > 4. When will it commence? > 5. When will we be able to sell our iOS apps written in JavaFX? > 6. Are there any issues (technical, political etc.) that are currently > insurmountable? > 7. Will iOS/Android/WP8 apps be indistinguishable from native apps (i.e. > look and feel, performance)? > 8. Has Oracle management committed to providing the funds to see this > project through to the end? > > I am sure I am not the only one who would love to see definitive answers to > these questions! > > -jct > > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net > [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Jonathan Giles > Sent: Friday, 7 December 2012 18:13 > To: openjfx-dev at openjdk.java.net > Subject: Survey: JavaFX on tablets and mobile devices > > Hi all, > > If you're the least bit interested in JavaFX on mobile devices (and it seems > a few of you are), I'd really appreciate you making your voice heard over at > FX Experience: > > http://fxexperience.com/2012/12/javafx-for-tablets-mobile/ > > I know that the cynical among you will question why this is necessary, that > your voices should have already been heard, and that it is 'too little, too > late'. Please indulge me this one last time - I'd really appreciate it - and > I promise that your feedback will be heard by all the right people. > > Thanks, > -- Jonathan > > > From randahl at rockit.dk Fri Dec 7 07:34:43 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Fri, 7 Dec 2012 16:34:43 +0100 Subject: Request for comments: Styling precedence proposal In-Reply-To: References: Message-ID: <489A27D1-B92B-4C05-BB62-874B0F065CEF@rockit.dk> Hi David Thanks for reading my post. The comment on "real, type safe, good old Java properties" is meant to suggest that assigning a color by invoking a setStyle(String) method is not type safe and is not a traditional bean property. I agree with you that assigning styles using stylesheets and classes is best, and my suggestion adds complexity. Still, there are numerous situations where just using classes does not cut it. In fact, everywhere were the actual value of the style property is calculated at runtime, CSS does not cut it. For instance, I have Nodes that are white but fades to red depending on system state, and we are talking a gradual shift from full red to white with hundreds of colours in between. Theoretically I could create 100 style classes to switch between, but of course I am not going to do that ? hence the calls to setStyle(?). And another problem here is the fact that I cannot as a programmer set a visual property without ruining it for the designer who wishes to style it differently ? currently, the code always wins. I would like to be able to instantiate a red Rectangle, while still allowing designers to choose blue. That is especially important when writing reusable component libraries. Randahl On Dec 7, 2012, at 15:36 , David Grieve wrote: > real, type safe, good old Java properties From david.grieve at oracle.com Fri Dec 7 07:55:05 2012 From: david.grieve at oracle.com (David Grieve) Date: Fri, 7 Dec 2012 10:55:05 -0500 Subject: Request for comments: Styling precedence proposal In-Reply-To: <489A27D1-B92B-4C05-BB62-874B0F065CEF@rockit.dk> References: <489A27D1-B92B-4C05-BB62-874B0F065CEF@rockit.dk> Message-ID: <3C4D87F6-831D-4FE9-BEBE-B5B0C77BED8A@oracle.com> On Dec 7, 2012, at 10:34 AM, Randahl Fink Isaksen wrote: > Hi David > > Thanks for reading my post. The comment on "real, type safe, good old Java properties" is meant to suggest that assigning a color by invoking a setStyle(String) method is not type safe and is not a traditional bean property. > > I agree with you that assigning styles using stylesheets and classes is best, and my suggestion adds complexity. Still, there are numerous situations where just using classes does not cut it. In fact, everywhere were the actual value of the style property is calculated at runtime, CSS does not cut it. For instance, I have Nodes that are white but fades to red depending on system state, and we are talking a gradual shift from full red to white with hundreds of colours in between. Theoretically I could create 100 style classes to switch between, but of course I am not going to do that ? hence the calls to setStyle(?). In 2.x, the only way to style a Region was with CSS. In 8.x, you have access to the properties. In your example, then, you can animate the shift. There is also a feature request to add animation support to CSS. And then there are the bugs I pointed out that call for public access to the CSS structure which I invite you to comment on. > > And another problem here is the fact that I cannot as a programmer set a visual property without ruining it for the designer who wishes to style it differently ? currently, the code always wins. I would like to be able to instantiate a red Rectangle, while still allowing designers to choose blue. That is especially important when writing reusable component libraries. The code should only win over a style in a user-agent stylesheet. If this is not the case, then there is a bug. > > Randahl > > > On Dec 7, 2012, at 15:36 , David Grieve wrote: > >> real, type safe, good old Java properties > From randahl at rockit.dk Fri Dec 7 08:01:34 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Fri, 7 Dec 2012 17:01:34 +0100 Subject: Request for comments: Styling precedence proposal In-Reply-To: <3C4D87F6-831D-4FE9-BEBE-B5B0C77BED8A@oracle.com> References: <489A27D1-B92B-4C05-BB62-874B0F065CEF@rockit.dk> <3C4D87F6-831D-4FE9-BEBE-B5B0C77BED8A@oracle.com> Message-ID: <7CD46686-3F8A-4A2D-9ABC-4D3E6A0F3E31@rockit.dk> Very interesting. You would not happen to have a link to some early docs of what you describe as "In 8.x, you have access to the properties" Thanks Randahl On Dec 7, 2012, at 16:55 , David Grieve wrote: > CSS. In 8.x, you have access to the properties From david.grieve at oracle.com Fri Dec 7 08:08:54 2012 From: david.grieve at oracle.com (David Grieve) Date: Fri, 7 Dec 2012 11:08:54 -0500 Subject: Request for comments: Styling precedence proposal In-Reply-To: <7CD46686-3F8A-4A2D-9ABC-4D3E6A0F3E31@rockit.dk> References: <489A27D1-B92B-4C05-BB62-874B0F065CEF@rockit.dk> <3C4D87F6-831D-4FE9-BEBE-B5B0C77BED8A@oracle.com> <7CD46686-3F8A-4A2D-9ABC-4D3E6A0F3E31@rockit.dk> Message-ID: <0ADB6547-1220-4632-B6C6-9953E2D502F3@oracle.com> Any 8.0 SDK, look at the javadoc for Region. You will find, for example, set/getBackground On Dec 7, 2012, at 11:01 AM, Randahl Fink Isaksen wrote: > Very interesting. You would not happen to have a link to some early docs of what you describe as > > "In 8.x, you have access to the properties" > > Thanks > > Randahl > > > On Dec 7, 2012, at 16:55 , David Grieve wrote: > >> CSS. In 8.x, you have access to the properties > From fbrunnerlist at gmx.ch Fri Dec 7 09:52:23 2012 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Fri, 07 Dec 2012 18:52:23 +0100 Subject: Survey: JavaFX on tablets and mobile devices In-Reply-To: <50C1B160.2070305@oracle.com> References: <50C1970A.2030901@oracle.com> <54196C48-3FB5-433D-A873-FF51D09E6561@rockit.dk> <50C1B160.2070305@oracle.com> Message-ID: <4012713.QOatoVPahT@shire> Thanks, Jonathan. I also posted the request to the JavaFX groups of Linkedin and Xing (German): http://www.linkedin.com/groups/Survey-JavaFX-on-tablets- mobile-159873.S.193822225?qid=b5e6b76e-8544-408b- a0bb-1dfaf4ccbf09&trk=group_most_recent_rich-0-b-ttl&goback=.gmr_159873 https://www.xing.com/net/pric3b1afx/javafx/allgemeine- diskussionen-282120/umfrage-javafx-auf-tablets-und-smartphones-42885585/ - Florian Am Freitag, 7. Dezember 2012, 22.05:36 schrieb Jonathan Giles: > Yes, Twitter has been appropriately spammed. > > -- Jonathan > > On 7/12/2012 10:04 p.m., Randahl Fink Isaksen wrote: > > Jonathan, have you posted the survey on Twitter with #javafx as well? I > > think it is very important, you are heard. > > > > Thanks for creating the survey > > > > Randahl > > > > On Dec 7, 2012, at 8:13 , Jonathan Giles wrote: > >> Hi all, > >> > >> If you're the least bit interested in JavaFX on mobile devices (and it > >> seems a few of you are), I'd really appreciate you making your voice > >> heard over at FX Experience: > >> > >> http://fxexperience.com/2012/12/javafx-for-tablets-mobile/ > >> > >> I know that the cynical among you will question why this is necessary, > >> that your voices should have already been heard, and that it is 'too > >> little, too late'. Please indulge me this one last time - I'd really > >> appreciate it - and I promise that your feedback will be heard by all > >> the right people. > >> > >> Thanks, > >> -- Jonathan From mp at jugs.org Fri Dec 7 11:14:28 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Fri, 07 Dec 2012 20:14:28 +0100 Subject: JavaFX performance for complex visualisations In-Reply-To: <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> Message-ID: <50C24014.5000003@jugs.org> Hi Richard, first of all thank you for the feedback on my post. I've put some more comment inline. Am 04.12.2012 21:41, schrieb Richard Bair: > Hi Michael, > > The thrust of your argument here I think is sound -- that lines are a lot faster than paths, and that the 3D Mesh should be quite a bit faster. There are just a couple minor things I wanted to clarify. > >> According to my experience JavaFX is currently not able to handle graphically intensive >> applications. > Depends on what you are doing that is "graphically intense" -- if it is a lot of paths (thousands) then yes, this is slow. If it is a lot of images and lines and effects and such, then actually you can do a heck of a lot with FX (which is graphically intense!) This is of course true but tell me how far do you really get if you only have these elements available? You cannot even draw a simple filled triangle without creating a path and thus slowing down your application. A graphically intensive business application without paths seems to be a very specific corner case to me but maybe it is just me who feels so. What I have in mind when I talk about such applications are large diagrams, floor plans, vector maps with a lot of symbols on them and so on. >> One reason for this is that all drawing of path based primitives is done >> in software and not in hardware. > There are a couple reasons for this which are sound. First, general path drawing in shaders is not entirely possible. There are algorithms or proofs of concept that do a pretty good job of it in most cases but not in the general case (at least, we haven't seen it). Have you seen this? https://developer.nvidia.com/nv-path-rendering Ok, this is NVIDIA specific but maybe worth considering for a platform specific optimization. > Second, on mobile / embedded you would die if you depended on the GPU to do these things (the CPU is way, WAY more powerful than the GPU). In fact, we found that on embedded the GPU was the major bottleneck and we needed to move more stuff onto the CPU. Incidentally, Android does the same thing (for the same reason). > > Another thing is that we limit ourselves to certain shader levels that are available on OpenGL ES 2 for the sake of embedded. With higher shader level support, we could do more. > > There is also a quality / speed tradeoff involved here. The way we do our antialiasing produces very high quality output, but requires that we upload a mask. On iOS, the highest MSAA level you can support is 4. Our Antialiasing is several orders of magnitude better in terms of the final results. It is interesting that you mention Android and iOS here so often :-) although that does not help us so much on the desktop. > > Fundamentally, 2D applications are very different from 3D. GPU's (even mobile GPU's) are fantastic at 3D because that's what they're designed for. We're doing the state of the art when it comes to representing 2D on 3D hardware. The problem is that in some cases, you would like to dial down the performance and have more of a 3D like experience in your application, and in those cases, today, there isn't anything available. Of course we aim to fix this with our 3D support that we're adding. I am waiting for that. > >> But a polygon is a path and thus is rendered in software >> and this software renderer is in many cases even 2-3 times slower than the one >> used in AWT. > Just out of curiosity, when is the last time you measured this? By our own benchmarks FX is faster than Ductus (Java2D) now. We did a bunch of performance work in the rasterizer a few months ago. I wonder if your test is available and works on the dev builds of 8 such that this could be reanalyzed? I'm keen to make sure we are faster. It is true, that I did not reanalyze this particular case with the latest builds but if you say that the FX rasterizer is now on par with the old Java2D rasterizer then this is really good news. It is a pitty that I do not have the old test anymore and cannot easily reanalyze this. > >> I hope this will change with the upcoming 3D support where we will also get more >> hardware accelerated drawing primitives which will hopefully also be usable in 2D. > When you say "also usable in 2D", what do you mean? For example, we can have a node that contains all the 3D mesh stuff, and "flatten" it for inclusion in the 2D scene. Is that what you mean? I thought it might be possible to define a 3D mesh where all z-coordinates are zero and use that for more complicated shapes in order to avoid the paths. Ideally the API would even provide 2D specific variants of these 3D meshes. Michael -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From hang.vo at oracle.com Fri Dec 7 11:47:35 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 07 Dec 2012 19:47:35 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20121207194742.BAE8B47FC2@hg.openjdk.java.net> Changeset: bfebbf84081f Author: David Grieve Date: 2012-12-07 14:37 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bfebbf84081f RT-26622: apply linear-gradient patch to highcontrast.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/highcontrast.css Changeset: 4fd3e1bdb19b Author: David Grieve Date: 2012-12-07 14:38 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4fd3e1bdb19b RT-17607: -fx-font-weight: 600 parses as a NUMBER but the css parser expects an IDENT. Fix parser to accept a number. ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java ! javafx-ui-common/test/unit/com/sun/javafx/css/FontWeightTypeTest.java From joseph.andresen at oracle.com Fri Dec 7 11:49:27 2012 From: joseph.andresen at oracle.com (joe andresen) Date: Fri, 07 Dec 2012 11:49:27 -0800 Subject: JavaFX performance for complex visualisations In-Reply-To: <50C24014.5000003@jugs.org> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> Message-ID: <50C24847.1010302@oracle.com> On 12/7/2012 11:14 AM, Dr. Michael Paus wrote: > Have you seen this? > https://developer.nvidia.com/nv-path-rendering > Ok, this is NVIDIA specific but maybe worth considering for a platform > specific optimization. Indeed, the graphics team has been aware of this for quite a while. We don't feel great about hardware specific impl. though, which is why it hasn't really been a priority. -Joe From richard.bair at oracle.com Fri Dec 7 12:20:47 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 7 Dec 2012 12:20:47 -0800 Subject: JavaFX performance for complex visualisations In-Reply-To: <50C24014.5000003@jugs.org> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> Message-ID: <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> Hi Michael, >>> According to my experience JavaFX is currently not able to handle graphically intensive >>> applications. >> Depends on what you are doing that is "graphically intense" -- if it is a lot of paths (thousands) then yes, this is slow. If it is a lot of images and lines and effects and such, then actually you can do a heck of a lot with FX (which is graphically intense!) > This is of course true but tell me how far do you really get if you only have these elements available? > You cannot even draw a simple filled triangle without creating a path and thus slowing down your application. > A graphically intensive business application without paths seems to be a very specific corner case to me but > maybe it is just me who feels so. What I have in mind when I talk about such applications are large diagrams, > floor plans, vector maps with a lot of symbols on them and so on. If you're needing triangles, then you're in another class of application than the kind we've so far properly supported. Hopefully the 3D stuff will help bridge the gap. (I've not seen triangles in use except in 3D programming which may explain why I haven't considered that particular use case critical for our earlier releases, but hopefully we'll be able to handle your case properly now). Richard From hang.vo at oracle.com Fri Dec 7 15:47:13 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 07 Dec 2012 23:47:13 +0000 Subject: hg: openjfx/8/graphics/rt: Fixed RT-26814: Scrollbar buttons look bad where they meet the track Message-ID: <20121207234717.84F8E47FCE@hg.openjdk.java.net> Changeset: 698048c91224 Author: "Jasper Potts" Date: 2012-12-07 15:37 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/698048c91224 Fixed RT-26814: Scrollbar buttons look bad where they meet the track ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css From swpalmer at gmail.com Fri Dec 7 18:32:33 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 7 Dec 2012 21:32:33 -0500 Subject: Request for comments: Styling precedence proposal In-Reply-To: <0ADB6547-1220-4632-B6C6-9953E2D502F3@oracle.com> References: <489A27D1-B92B-4C05-BB62-874B0F065CEF@rockit.dk> <3C4D87F6-831D-4FE9-BEBE-B5B0C77BED8A@oracle.com> <7CD46686-3F8A-4A2D-9ABC-4D3E6A0F3E31@rockit.dk> <0ADB6547-1220-4632-B6C6-9953E2D502F3@oracle.com> Message-ID: <0058EF85-AD72-4564-B3B5-70C43E7E0E5B@gmail.com> If I call setBackground(Color.RED) and also use a style sheet with CSS rules for background colours of that node, using the hover or focused pseudo-classes for example, what happens? The idea of being able to change the precedence messes things up. Scott On 2012-12-07, at 11:08 AM, David Grieve wrote: > Any 8.0 SDK, look at the javadoc for Region. You will find, for example, set/getBackground > > On Dec 7, 2012, at 11:01 AM, Randahl Fink Isaksen wrote: > >> Very interesting. You would not happen to have a link to some early docs of what you describe as >> >> "In 8.x, you have access to the properties" >> >> Thanks >> >> Randahl >> >> >> On Dec 7, 2012, at 16:55 , David Grieve wrote: >> >>> CSS. In 8.x, you have access to the properties > From mp at jugs.org Sat Dec 8 00:37:37 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Sat, 08 Dec 2012 09:37:37 +0100 Subject: JavaFX performance for complex visualisations In-Reply-To: <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> Message-ID: <50C2FC51.80208@jugs.org> Am 07.12.2012 21:20, schrieb Richard Bair: > Hi Michael, > >>>> According to my experience JavaFX is currently not able to handle graphically intensive >>>> applications. >>> Depends on what you are doing that is "graphically intense" -- if it is a lot of paths (thousands) then yes, this is slow. If it is a lot of images and lines and effects and such, then actually you can do a heck of a lot with FX (which is graphically intense!) >> This is of course true but tell me how far do you really get if you only have these elements available? >> You cannot even draw a simple filled triangle without creating a path and thus slowing down your application. >> A graphically intensive business application without paths seems to be a very specific corner case to me but >> maybe it is just me who feels so. What I have in mind when I talk about such applications are large diagrams, >> floor plans, vector maps with a lot of symbols on them and so on. > If you're needing triangles, then you're in another class of application than the kind we've so far properly supported. Hopefully the 3D stuff will help bridge the gap. > > (I've not seen triangles in use except in 3D programming which may explain why I haven't considered that particular use case critical for our earlier releases, but hopefully we'll be able to handle your case properly now). Just to avoid some misunderstanding. I mentioned triangles only as an example for the most trivial geometry which cannot be created without using paths right now. In practice I have to create more complicated geometries of course. -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From zonski at gmail.com Sat Dec 8 01:01:34 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Sat, 8 Dec 2012 20:01:34 +1100 Subject: JavaFX performance for complex visualisations In-Reply-To: <50C2FC51.80208@jugs.org> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C2FC51.80208@jugs.org> Message-ID: And just for reference, I had business cases to show: * P&IDs like these http://www.creativeengineers.com/process-engineering/diagrams/pid.html * Site maps similar to this sort of thing: http://www.cegenvironmental.com/Services/Phase_II_ESA/Blueberry_Processing_Plant/topoDKWfsmall.gif And to include zooming with LOD (i.e. more detail zoomed in, less detail at birds eye view), selective layering/highlighting (i.e. turn on/off different pipes or sections), hyperlinking and mouse overs, and markers/annotations (i.e. put a flag on the map, or a semi-transparent overlay over a "hot" section). No animations at least. JFX wasn't up to the task performance wise as far as I could tell in 2.0. We scaled back to just showing blurry images and putting a few markers (e.g. triangles/arrows/dots) on them but this was still quite slow but that could well have been the logic behind it (things got ugly). This was for mining, chemical, manufacturing and general heavy industries (not unlike the cargo unloading thing from JavaOne). On Sat, Dec 8, 2012 at 7:37 PM, Dr. Michael Paus wrote: > Am 07.12.2012 21:20, schrieb Richard Bair: > > Hi Michael, >> >> According to my experience JavaFX is currently not able to handle >>>>> graphically intensive >>>>> applications. >>>>> >>>> Depends on what you are doing that is "graphically intense" -- if it is >>>> a lot of paths (thousands) then yes, this is slow. If it is a lot of images >>>> and lines and effects and such, then actually you can do a heck of a lot >>>> with FX (which is graphically intense!) >>>> >>> This is of course true but tell me how far do you really get if you only >>> have these elements available? >>> You cannot even draw a simple filled triangle without creating a path >>> and thus slowing down your application. >>> A graphically intensive business application without paths seems to be a >>> very specific corner case to me but >>> maybe it is just me who feels so. What I have in mind when I talk about >>> such applications are large diagrams, >>> floor plans, vector maps with a lot of symbols on them and so on. >>> >> If you're needing triangles, then you're in another class of application >> than the kind we've so far properly supported. Hopefully the 3D stuff will >> help bridge the gap. >> >> (I've not seen triangles in use except in 3D programming which may >> explain why I haven't considered that particular use case critical for our >> earlier releases, but hopefully we'll be able to handle your case properly >> now). >> > Just to avoid some misunderstanding. I mentioned triangles only as an > example for the most trivial geometry which cannot be > created without using paths right now. In practice I have to create more > complicated geometries of course. > > > -- > ------------------------------**------------------------------** > -------------------------- > Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). > For more information visit www.jugs.de. > > From richard.bair at oracle.com Sat Dec 8 08:55:18 2012 From: richard.bair at oracle.com (Richard Bair) Date: Sat, 8 Dec 2012 08:55:18 -0800 Subject: JavaFX performance for complex visualisations In-Reply-To: References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C2FC51.80208@jugs.org> Message-ID: <6B515693-B119-4853-BD71-C9F78917F93B@oracle.com> I think the first link is a great example of something we should be able to do, and the kind of thing that I think you and Michael are saying doesn't work well right now. The second one actually is probably a lot easier now, because of Canvas. Basically, all the typographic background information isn't interactive, so you can render it once and use it as an image thereafter (with Canvas), whereas the first example has what I would guess would be a lot of interactive content. Richard On Dec 8, 2012, at 1:01 AM, Daniel Zwolenski wrote: > And just for reference, I had business cases to show: > * P&IDs like these http://www.creativeengineers.com/process-engineering/diagrams/pid.html > * Site maps similar to this sort of thing: http://www.cegenvironmental.com/Services/Phase_II_ESA/Blueberry_Processing_Plant/topoDKWfsmall.gif > > And to include zooming with LOD (i.e. more detail zoomed in, less detail at birds eye view), selective layering/highlighting (i.e. turn on/off different pipes or sections), hyperlinking and mouse overs, and markers/annotations (i.e. put a flag on the map, or a semi-transparent overlay over a "hot" section). No animations at least. > > JFX wasn't up to the task performance wise as far as I could tell in 2.0. We scaled back to just showing blurry images and putting a few markers (e.g. triangles/arrows/dots) on them but this was still quite slow but that could well have been the logic behind it (things got ugly). > > This was for mining, chemical, manufacturing and general heavy industries (not unlike the cargo unloading thing from JavaOne). > > > > > On Sat, Dec 8, 2012 at 7:37 PM, Dr. Michael Paus wrote: > Am 07.12.2012 21:20, schrieb Richard Bair: > > Hi Michael, > > According to my experience JavaFX is currently not able to handle graphically intensive > applications. > Depends on what you are doing that is "graphically intense" -- if it is a lot of paths (thousands) then yes, this is slow. If it is a lot of images and lines and effects and such, then actually you can do a heck of a lot with FX (which is graphically intense!) > This is of course true but tell me how far do you really get if you only have these elements available? > You cannot even draw a simple filled triangle without creating a path and thus slowing down your application. > A graphically intensive business application without paths seems to be a very specific corner case to me but > maybe it is just me who feels so. What I have in mind when I talk about such applications are large diagrams, > floor plans, vector maps with a lot of symbols on them and so on. > If you're needing triangles, then you're in another class of application than the kind we've so far properly supported. Hopefully the 3D stuff will help bridge the gap. > > (I've not seen triangles in use except in 3D programming which may explain why I haven't considered that particular use case critical for our earlier releases, but hopefully we'll be able to handle your case properly now). > Just to avoid some misunderstanding. I mentioned triangles only as an example for the most trivial geometry which cannot be > created without using paths right now. In practice I have to create more complicated geometries of course. > > > -- > -------------------------------------------------------------------------------------- > Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). > For more information visit www.jugs.de. > > From swpalmer at gmail.com Sat Dec 8 09:43:01 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 8 Dec 2012 12:43:01 -0500 Subject: JavaFX performance for complex visualisations In-Reply-To: <6B515693-B119-4853-BD71-C9F78917F93B@oracle.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C2FC51.80208@jugs.org> <6B515693-B119-4853-BD71-C9F78917F93B@oracle.com> Message-ID: That first link is very close to what I am doing now with JavaFX... and yes, the performance is below what I was hoping. When there are many Paths performance drops substantially. Here's a link to info about our product: http://www.digitalrapids.com/en/Products/Kayak.aspx See Kayak Workflow Designer at 1:50 into the video. Scott On Sat, Dec 8, 2012 at 11:55 AM, Richard Bair wrote: > I think the first link is a great example of something we should be able > to do, and the kind of thing that I think you and Michael are saying > doesn't work well right now. The second one actually is probably a lot > easier now, because of Canvas. Basically, all the typographic background > information isn't interactive, so you can render it once and use it as an > image thereafter (with Canvas), whereas the first example has what I would > guess would be a lot of interactive content. > > Richard > > On Dec 8, 2012, at 1:01 AM, Daniel Zwolenski wrote: > > > And just for reference, I had business cases to show: > > * P&IDs like these > http://www.creativeengineers.com/process-engineering/diagrams/pid.html > > * Site maps similar to this sort of thing: > http://www.cegenvironmental.com/Services/Phase_II_ESA/Blueberry_Processing_Plant/topoDKWfsmall.gif > > > > And to include zooming with LOD (i.e. more detail zoomed in, less detail > at birds eye view), selective layering/highlighting (i.e. turn on/off > different pipes or sections), hyperlinking and mouse overs, and > markers/annotations (i.e. put a flag on the map, or a semi-transparent > overlay over a "hot" section). No animations at least. > > > > JFX wasn't up to the task performance wise as far as I could tell in > 2.0. We scaled back to just showing blurry images and putting a few markers > (e.g. triangles/arrows/dots) on them but this was still quite slow but that > could well have been the logic behind it (things got ugly). > > > > This was for mining, chemical, manufacturing and general heavy > industries (not unlike the cargo unloading thing from JavaOne). > > > > > > > > > > On Sat, Dec 8, 2012 at 7:37 PM, Dr. Michael Paus wrote: > > Am 07.12.2012 21:20, schrieb Richard Bair: > > > > Hi Michael, > > > > According to my experience JavaFX is currently not able to handle > graphically intensive > > applications. > > Depends on what you are doing that is "graphically intense" -- if it is > a lot of paths (thousands) then yes, this is slow. If it is a lot of images > and lines and effects and such, then actually you can do a heck of a lot > with FX (which is graphically intense!) > > This is of course true but tell me how far do you really get if you only > have these elements available? > > You cannot even draw a simple filled triangle without creating a path > and thus slowing down your application. > > A graphically intensive business application without paths seems to be a > very specific corner case to me but > > maybe it is just me who feels so. What I have in mind when I talk about > such applications are large diagrams, > > floor plans, vector maps with a lot of symbols on them and so on. > > If you're needing triangles, then you're in another class of application > than the kind we've so far properly supported. Hopefully the 3D stuff will > help bridge the gap. > > > > (I've not seen triangles in use except in 3D programming which may > explain why I haven't considered that particular use case critical for our > earlier releases, but hopefully we'll be able to handle your case properly > now). > > Just to avoid some misunderstanding. I mentioned triangles only as an > example for the most trivial geometry which cannot be > > created without using paths right now. In practice I have to create more > complicated geometries of course. > > > > > > -- > > > -------------------------------------------------------------------------------------- > > Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). > > For more information visit www.jugs.de. > > > > > > From mp at jugs.org Sat Dec 8 10:03:05 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Sat, 08 Dec 2012 19:03:05 +0100 Subject: JavaFX performance for complex visualisations In-Reply-To: References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C2FC51.80208@jugs.org> Message-ID: <50C380D9.7060803@jugs.org> Yes, these examples come close to what I was talking about. I can't show you any details about my own work but this link http://www.dfs-vfrebulletin.de/web20/index.htm gives you an impression of what I am after. In the upper right corner select ICAO Karte or Lower or Wallchart and then zoom in an out with the mouse-wheel and then imagine you could graphically select and edit all these items. You got the problem? Michael Am 08.12.2012 10:01, schrieb Daniel Zwolenski: > And just for reference, I had business cases to show: > * P&IDs like these > http://www.creativeengineers.com/process-engineering/diagrams/pid.html > * Site maps similar to this sort of thing: > http://www.cegenvironmental.com/Services/Phase_II_ESA/Blueberry_Processing_Plant/topoDKWfsmall.gif > From kevin.rushforth at oracle.com Sat Dec 8 16:28:24 2012 From: kevin.rushforth at oracle.com (kevin.rushforth at oracle.com) Date: Sun, 09 Dec 2012 00:28:24 +0000 Subject: hg: openjfx/2.2.6/graphics: Update URL for repo in README file to 2.2.6 Message-ID: <20121209002824.9D58247FEB@hg.openjdk.java.net> Changeset: 4f06f91bdcf4 Author: kcr Date: 2012-12-08 16:27 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rev/4f06f91bdcf4 Update URL for repo in README file to 2.2.6 ! README From kevin.rushforth at oracle.com Sat Dec 8 16:29:49 2012 From: kevin.rushforth at oracle.com (kevin.rushforth at oracle.com) Date: Sun, 09 Dec 2012 00:29:49 +0000 Subject: hg: openjfx/2.2.6/master: Update URL for repo in README file to 2.2.6 Message-ID: <20121209002949.9999847FEC@hg.openjdk.java.net> Changeset: 4f06f91bdcf4 Author: kcr Date: 2012-12-08 16:27 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rev/4f06f91bdcf4 Update URL for repo in README file to 2.2.6 ! README From kevin.rushforth at oracle.com Sat Dec 8 16:32:37 2012 From: kevin.rushforth at oracle.com (kevin.rushforth at oracle.com) Date: Sun, 09 Dec 2012 00:32:37 +0000 Subject: hg: openjfx/2.2.6/master/rt: 35 new changesets Message-ID: <20121209003308.552D747FED@hg.openjdk.java.net> Changeset: 866dd9865999 Author: hudson Date: 2012-06-28 07:07 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/866dd9865999 Added tag 2.2.1-b01 for changeset 00bc2ee17e47 ! .hgtags Changeset: 132f6c25f4b3 Author: kcr Date: 2012-07-12 06:23 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/132f6c25f4b3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt ! .hgtags Changeset: 69f5c94b4a3d Author: kcr Date: 2012-07-19 10:27 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/69f5c94b4a3d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt ! .hgtags Changeset: 42a29ad26a71 Author: kcr Date: 2012-07-28 07:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/42a29ad26a71 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt ! .hgtags Changeset: 91e85b55a3ee Author: hudson Date: 2012-08-08 15:15 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/91e85b55a3ee Added tag 2.2.1-b02 for changeset 42a29ad26a71 ! .hgtags Changeset: 1b48dfbd944c Author: hudson Date: 2012-09-07 13:29 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/1b48dfbd944c Added tag 2.2.1-b03 for changeset 91e85b55a3ee ! .hgtags Changeset: eb3438e74267 Author: hudson Date: 2012-09-07 17:41 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/eb3438e74267 Added tag 2.2.1-b04 for changeset 1b48dfbd944c ! .hgtags Changeset: 44f4a03ff92d Author: hudson Date: 2012-09-08 17:31 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/44f4a03ff92d Added tag 2.2.1-b05 for changeset eb3438e74267 ! .hgtags Changeset: 105d2b04b4ce Author: hudson Date: 2012-09-10 10:26 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/105d2b04b4ce Added tag 2.2.3-b02 ! .hgtags Changeset: f99798608d24 Author: hudson Date: 2012-09-12 16:29 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/f99798608d24 Added tag 2.2.3-b03 for changeset 105d2b04b4ce ! .hgtags Changeset: 46ea8d4fadd3 Author: hudson Date: 2012-09-20 14:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/46ea8d4fadd3 Added tag 2.2.3-b04 for changeset f99798608d24 ! .hgtags Changeset: 420285cc8db9 Author: hudson Date: 2012-09-25 13:45 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/420285cc8db9 Added tag 2.2.3-b05 for changeset 46ea8d4fadd3 ! .hgtags Changeset: 693dc811b166 Author: Paru Somashekar Date: 2012-08-15 15:03 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/693dc811b166 fix RT-24106 calling setLabelsVisible(false) on a PieChart causes the application to crash with a NPE at PieChart.layoutChartChildren() ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java Changeset: 264a190d4737 Author: hudson Date: 2012-09-29 21:55 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/264a190d4737 Added tag 2.2.4-b09 ! .hgtags Changeset: b819ec28c317 Author: hudson Date: 2012-10-03 15:10 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/b819ec28c317 Added tag 2.2.4-b10 for changeset 264a190d4737 ! .hgtags Changeset: 30710d0c5f30 Author: hudson Date: 2012-10-10 18:11 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/30710d0c5f30 Added tag 2.2.4-b11 for changeset b819ec28c317 ! .hgtags Changeset: 92938e0a1a53 Author: kcr Date: 2012-10-11 14:34 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/92938e0a1a53 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt ! .hgtags Changeset: 7dde672c2898 Author: kcr Date: 2012-10-16 16:08 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/7dde672c2898 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.4/MASTER/jfx/rt ! .hgtags Changeset: caa28b7ca651 Author: hudson Date: 2012-10-17 13:21 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/caa28b7ca651 Added tag 2.2.4-b12 for changeset 92938e0a1a53 ! .hgtags Changeset: 8b1111796760 Author: hudson Date: 2012-10-24 13:22 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/8b1111796760 Added tag 2.2.4-b13 for changeset caa28b7ca651 ! .hgtags Changeset: c3114e9f2215 Author: kcr Date: 2012-10-25 14:03 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/c3114e9f2215 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.4/MASTER/jfx/rt ! .hgtags Changeset: fb4d0e99bed7 Author: hudson Date: 2012-11-08 16:56 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/fb4d0e99bed7 Added tag 2.2.6-b01 for changeset c3114e9f2215 ! .hgtags Changeset: a763e336d0ed Author: hudson Date: 2012-11-15 20:35 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/a763e336d0ed Added tag 2.2.6-b02 for changeset fb4d0e99bed7 ! .hgtags Changeset: 868bef8eff55 Author: hudson Date: 2012-10-31 15:23 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/868bef8eff55 Added tag 2.2.4-b14 for changeset 8b1111796760 ! .hgtags Changeset: 4492579af767 Author: hudson Date: 2012-11-07 17:24 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/4492579af767 Added tag 2.2.4-b15 for changeset 868bef8eff55 ! .hgtags Changeset: c07a4dc990bb Author: hudson Date: 2012-11-14 18:53 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/c07a4dc990bb Added tag 2.2.4-b16 for changeset 4492579af767 ! .hgtags Changeset: c3fa08afde13 Author: hudson Date: 2012-11-21 14:10 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/c3fa08afde13 Added tag 2.2.4-b17 for changeset c07a4dc990bb ! .hgtags Changeset: 7d52ac515200 Author: kcr Date: 2012-11-26 19:28 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/7d52ac515200 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.4/MASTER/jfx/rt ! .hgtags Changeset: 66716f2089bf Author: hudson Date: 2012-11-29 16:47 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/66716f2089bf Added tag 2.2.6-b03 for changeset 7d52ac515200 ! .hgtags Changeset: 25445fc9f478 Author: hudson Date: 2012-11-28 15:56 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/25445fc9f478 Added tag 2.2.4-b18 for changeset c3fa08afde13 ! .hgtags Changeset: c891fe0269ef Author: kcr Date: 2012-11-29 18:13 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/c891fe0269ef Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.4/MASTER/jfx/rt ! .hgtags Changeset: 5de32c121f10 Author: Paru Somashekar Date: 2012-11-28 15:35 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/5de32c121f10 fix/backport RT-23812 StackedAreaChart ClassCastException on CategoryAxis ! javafx-ui-charts/src/javafx/scene/chart/StackedAreaChart.java ! javafx-ui-charts/test/javafx/scene/chart/StackedAreaChartTest.java Changeset: f87cb385192c Author: kcr Date: 2012-11-30 08:56 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/f87cb385192c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.6/MASTER/jfx/rt Changeset: 3617bc4b5d81 Author: Paru Somashekar Date: 2012-11-30 11:28 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/3617bc4b5d81 fix RT-23763 StackedBarChart does not work with autoranging category ! javafx-ui-charts/test/javafx/scene/chart/StackedBarChartTest.java ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java ! javafx-ui-controls/test/javafx/scene/chart/CategoryAxisTest.java Changeset: ebfca02fc014 Author: hudson Date: 2012-12-05 15:26 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/ebfca02fc014 Added tag 2.2.6-b04 for changeset 3617bc4b5d81 ! .hgtags From kevin.rushforth at oracle.com Sat Dec 8 16:40:40 2012 From: kevin.rushforth at oracle.com (kevin.rushforth at oracle.com) Date: Sun, 09 Dec 2012 00:40:40 +0000 Subject: hg: openjfx/2.2.6: update Message-ID: <20121209004040.A189B47FEE@hg.openjdk.java.net> Changeset: 05e847b7ed38 Author: kcr Date: 2012-12-08 16:39 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/rev/05e847b7ed38 update ! README From kevin.rushforth at oracle.com Sat Dec 8 16:44:29 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 08 Dec 2012 16:44:29 -0800 Subject: JavaFX 2.2.6-ea in JDK 1.7u12 In-Reply-To: <50BCD801.7030408@oracle.com> References: <50BCD801.7030408@oracle.com> Message-ID: <50C3DEED.1010501@oracle.com> The 2.2.6/master/rt repo is now ready and up to date. -- Kevin Kevin Rushforth wrote: > This is in progress and should be available this week. Look for it here: > > http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/ > > I'll send e-mail when ready. > > -- Kevin > > > Sven Reimers wrote: >> Is there a corresponding hg repository available? >> >> Thanks >> >> Sven >> From ozemale at ozemail.com.au Sat Dec 8 21:30:48 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Sun, 9 Dec 2012 16:30:48 +1100 Subject: JavaFX performance for complex visualisations In-Reply-To: References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C2FC51.80208@jugs.org> <6B515693-B119-4853-BD71-C9F78917F93B@oracle.com> Message-ID: <01a801cdd5ce$58e1e170$0aa5a450$@com.au> That looks very good Scott. But just to put it out there, what *I'd* like to see is that the presentation at that link be developed in JavaFX instead of Flash as it is currently (not just the product it describes). Why can't we do that? Well, the first question is whether JavaFX is capable of supporting such a visualisation. The second question is even if it was possible, how would it be developed without similar tools offered by Adobe Creative Suite? We basically have Scene Builder at the moment which clearly isn't going to cut it. -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Scott Palmer Sent: Sunday, 9 December 2012 04:43 To: Richard Bair Cc: openjfx-dev at openjdk.java.net Subject: Re: JavaFX performance for complex visualisations That first link is very close to what I am doing now with JavaFX... and yes, the performance is below what I was hoping. When there are many Paths performance drops substantially. Here's a link to info about our product: http://www.digitalrapids.com/en/Products/Kayak.aspx See Kayak Workflow Designer at 1:50 into the video. Scott On Sat, Dec 8, 2012 at 11:55 AM, Richard Bair wrote: > I think the first link is a great example of something we should be > able to do, and the kind of thing that I think you and Michael are > saying doesn't work well right now. The second one actually is > probably a lot easier now, because of Canvas. Basically, all the > typographic background information isn't interactive, so you can > render it once and use it as an image thereafter (with Canvas), > whereas the first example has what I would guess would be a lot of interactive content. > > Richard > > On Dec 8, 2012, at 1:01 AM, Daniel Zwolenski wrote: > > > And just for reference, I had business cases to show: > > * P&IDs like these > http://www.creativeengineers.com/process-engineering/diagrams/pid.html > > * Site maps similar to this sort of thing: > http://www.cegenvironmental.com/Services/Phase_II_ESA/Blueberry_Proces > sing_Plant/topoDKWfsmall.gif > > > > And to include zooming with LOD (i.e. more detail zoomed in, less > > detail > at birds eye view), selective layering/highlighting (i.e. turn on/off > different pipes or sections), hyperlinking and mouse overs, and > markers/annotations (i.e. put a flag on the map, or a semi-transparent > overlay over a "hot" section). No animations at least. > > > > JFX wasn't up to the task performance wise as far as I could tell in > 2.0. We scaled back to just showing blurry images and putting a few > markers (e.g. triangles/arrows/dots) on them but this was still quite > slow but that could well have been the logic behind it (things got ugly). > > > > This was for mining, chemical, manufacturing and general heavy > industries (not unlike the cargo unloading thing from JavaOne). > > > > > > > > > > On Sat, Dec 8, 2012 at 7:37 PM, Dr. Michael Paus wrote: > > Am 07.12.2012 21:20, schrieb Richard Bair: > > > > Hi Michael, > > > > According to my experience JavaFX is currently not able to handle > graphically intensive > > applications. > > Depends on what you are doing that is "graphically intense" -- if it > > is > a lot of paths (thousands) then yes, this is slow. If it is a lot of > images and lines and effects and such, then actually you can do a heck > of a lot with FX (which is graphically intense!) > > This is of course true but tell me how far do you really get if you > > only > have these elements available? > > You cannot even draw a simple filled triangle without creating a > > path > and thus slowing down your application. > > A graphically intensive business application without paths seems to > > be a > very specific corner case to me but > > maybe it is just me who feels so. What I have in mind when I talk > > about > such applications are large diagrams, > > floor plans, vector maps with a lot of symbols on them and so on. > > If you're needing triangles, then you're in another class of > > application > than the kind we've so far properly supported. Hopefully the 3D stuff > will help bridge the gap. > > > > (I've not seen triangles in use except in 3D programming which may > explain why I haven't considered that particular use case critical for > our earlier releases, but hopefully we'll be able to handle your case > properly now). > > Just to avoid some misunderstanding. I mentioned triangles only as > > an > example for the most trivial geometry which cannot be > > created without using paths right now. In practice I have to create > > more > complicated geometries of course. > > > > > > -- > > > ---------------------------------------------------------------------- > ---------------- > > 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 9 04:53:14 2012 From: sven.reimers at gmail.com (Sven Reimers) Date: Sun, 9 Dec 2012 13:53:14 +0100 Subject: JavaFX 2.2.6-ea in JDK 1.7u12 In-Reply-To: <50C3DEED.1010501@oracle.com> References: <50BCD801.7030408@oracle.com> <50C3DEED.1010501@oracle.com> Message-ID: Thanks for the notification -Sven On Sun, Dec 9, 2012 at 1:44 AM, Kevin Rushforth wrote: > The 2.2.6/master/rt repo is now ready and up to date. > > -- Kevin > > > > Kevin Rushforth wrote: > >> This is in progress and should be available this week. Look for it here: >> >> http://hg.openjdk.java.net/**openjfx/2.2.6/master/rt/ >> >> I'll send e-mail when ready. >> >> -- Kevin >> >> >> Sven Reimers wrote: >> >>> Is there a corresponding hg repository available? >>> >>> Thanks >>> >>> Sven >>> >>> >> -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From fbrunnerlist at gmx.ch Sun Dec 9 05:09:49 2012 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Sun, 09 Dec 2012 14:09:49 +0100 Subject: Drombler FX: building modular JavaFX applications with OSGi and Maven Message-ID: <1468973.LLaJQ6I9jc@shire> Hi everybody, I'm happy to announce the availabilty of a first Early Access version of Drombler FX. Drombler FX is a modular Rich Client Platform for JavaFX. You can read more about it here: http://puces- blog.blogspot.ch/2012/12/drombler-fx-building-modular-javafx.html There's a Getting Started page which explains how to create, build and run a Drombler FX sample application with a few simple steps: http://wiki.drombler.org/GettingStarted - Florian From fbrunnerlist at gmx.ch Sun Dec 9 06:27:42 2012 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Sun, 09 Dec 2012 15:27:42 +0100 Subject: JavaFX Maven Plugin In-Reply-To: <50A3711D.3010506@nosphere.org> References: <7A334C9E-0B87-49F5-97C7-5EEA413EEAFC@oracle.com> <50A3711D.3010506@nosphere.org> Message-ID: <1864270.5NfxFqxt4H@shire> Hi Daniel and Paul, Sorry for joining this discussion so late. As you might have seen in another thread I was quite busy releasing an Early Access version of Drombler FX, a Rich Client Platform for building modular JavaFX applications with OSGi and Maven. Drombler FX also includes a custom Maven Plugin (to be used as an extension with a custom packaging type) and a custom Maven Archetype to easily get started with Drombler FX. You can read more about the output the Drombler FX Maven Plugin generates here: https://sourceforge.net/p/drombler/wiki/GettingStarted/#drombler-fx-sample-application-the-binaries-explained The source code can be found here: https://sourceforge.net/p/drombler/drombler-fx (look for the drombler-fx-maven-plugin project). The main focus is of course to simplify OSGi based JavaFX applications. But I guess we have duplicated some efforts now and it would be great if we could consolidate our solutions at some point to save resources. You can read more about Drombler FX here: http://puces-blog.blogspot.ch/2012/12/drombler-fx-building-modular-javafx.html - Florian Am Mittwoch, 14. November 2012, 11.23:25 schrieb Paul Merlin: > Gents, > > I had to use JavaFX and Maven in a university course and for a company > project lately but the current plugin do not support maven enough for my > needs so I wrote another javafx plugin that don't rely on reflection and > has more maven features. > > Currently it does the following: > - support many configurations properties > - allow execution of JavaFX applications using exec-maven-plugin > - package and attach JNLP/Applet distributions > - package and attach images distributions > - package and attach installers distributions > > As produced distributions are attached to the build the plugin can be > used to roll releases using the maven mechanisms. > > All this was easier because it's not using reflection. The drawback here > is that my plugin force you to add dependencies to javafx artifacts to > your POM. > > https://github.com/eskatos/javafx-maven-plugin > > The README explain how to use the plugin. > > Daniel is aware of my work on this and we certainly will combine our > efforts at some point (this should occur when the build tools are > opensourced). For now developpers have the choice between the two > approaches. > > BTW I have one question. JavaFX will be included in JavaSE classpath at > some point (7uX, 8?). People building against Java versions published > before this change will still have to explicitely depend on JavaFX to > build their applications, don't they? > > Regards > > /Paul > > From swpalmer at gmail.com Sun Dec 9 07:31:59 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 9 Dec 2012 10:31:59 -0500 Subject: JavaFX performance for complex visualisations In-Reply-To: <01a801cdd5ce$58e1e170$0aa5a450$@com.au> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C2FC51.80208@jugs.org> <6B515693-B119-4853-BD71-C9F78917F93B@oracle.com> <01a801cdd5ce$58e1e170$0aa5a450$@com.au> Message-ID: <9EF244F8-AB86-4234-B2A7-6D672A601788@gmail.com> To be honest, I don't know if the presentation was done in Flash. The end result is MPEG4 video, not a Flash animation. I would be happy if the *tools* used to create the presentation could easily be made using JavaFX. I think JavaFX could do the visualization with a small framework written in JavaFX. Scott On 2012-12-09, at 12:30 AM, "John C. Turnbull" wrote: > That looks very good Scott. > > But just to put it out there, what *I'd* like to see is that the presentation at that link be developed in JavaFX instead of Flash as it is currently (not just the product it describes). Why can't we do that? Well, the first question is whether JavaFX is capable of supporting such a visualisation. The second question is even if it was possible, how would it be developed without similar tools offered by Adobe Creative Suite? We basically have Scene Builder at the moment which clearly isn't going to cut it. > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Scott Palmer > Sent: Sunday, 9 December 2012 04:43 > To: Richard Bair > Cc: openjfx-dev at openjdk.java.net > Subject: Re: JavaFX performance for complex visualisations > > That first link is very close to what I am doing now with JavaFX... and yes, the performance is below what I was hoping. When there are many Paths performance drops substantially. > Here's a link to info about our product: > http://www.digitalrapids.com/en/Products/Kayak.aspx > See Kayak Workflow Designer at 1:50 into the video. > > Scott > > > On Sat, Dec 8, 2012 at 11:55 AM, Richard Bair wrote: > >> I think the first link is a great example of something we should be >> able to do, and the kind of thing that I think you and Michael are >> saying doesn't work well right now. The second one actually is >> probably a lot easier now, because of Canvas. Basically, all the >> typographic background information isn't interactive, so you can >> render it once and use it as an image thereafter (with Canvas), >> whereas the first example has what I would guess would be a lot of interactive content. >> >> Richard >> >> On Dec 8, 2012, at 1:01 AM, Daniel Zwolenski wrote: >> >>> And just for reference, I had business cases to show: >>> * P&IDs like these >> http://www.creativeengineers.com/process-engineering/diagrams/pid.html >>> * Site maps similar to this sort of thing: >> http://www.cegenvironmental.com/Services/Phase_II_ESA/Blueberry_Proces >> sing_Plant/topoDKWfsmall.gif >>> >>> And to include zooming with LOD (i.e. more detail zoomed in, less >>> detail >> at birds eye view), selective layering/highlighting (i.e. turn on/off >> different pipes or sections), hyperlinking and mouse overs, and >> markers/annotations (i.e. put a flag on the map, or a semi-transparent >> overlay over a "hot" section). No animations at least. >>> >>> JFX wasn't up to the task performance wise as far as I could tell in >> 2.0. We scaled back to just showing blurry images and putting a few >> markers (e.g. triangles/arrows/dots) on them but this was still quite >> slow but that could well have been the logic behind it (things got ugly). >>> >>> This was for mining, chemical, manufacturing and general heavy >> industries (not unlike the cargo unloading thing from JavaOne). >>> >>> >>> >>> >>> On Sat, Dec 8, 2012 at 7:37 PM, Dr. Michael Paus wrote: >>> Am 07.12.2012 21:20, schrieb Richard Bair: >>> >>> Hi Michael, >>> >>> According to my experience JavaFX is currently not able to handle >> graphically intensive >>> applications. >>> Depends on what you are doing that is "graphically intense" -- if it >>> is >> a lot of paths (thousands) then yes, this is slow. If it is a lot of >> images and lines and effects and such, then actually you can do a heck >> of a lot with FX (which is graphically intense!) >>> This is of course true but tell me how far do you really get if you >>> only >> have these elements available? >>> You cannot even draw a simple filled triangle without creating a >>> path >> and thus slowing down your application. >>> A graphically intensive business application without paths seems to >>> be a >> very specific corner case to me but >>> maybe it is just me who feels so. What I have in mind when I talk >>> about >> such applications are large diagrams, >>> floor plans, vector maps with a lot of symbols on them and so on. >>> If you're needing triangles, then you're in another class of >>> application >> than the kind we've so far properly supported. Hopefully the 3D stuff >> will help bridge the gap. >>> >>> (I've not seen triangles in use except in 3D programming which may >> explain why I haven't considered that particular use case critical for >> our earlier releases, but hopefully we'll be able to handle your case >> properly now). >>> Just to avoid some misunderstanding. I mentioned triangles only as >>> an >> example for the most trivial geometry which cannot be >>> created without using paths right now. In practice I have to create >>> more >> complicated geometries of course. >>> >>> >>> -- >>> >> ---------------------------------------------------------------------- >> ---------------- >>> Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). >>> For more information visit www.jugs.de. >>> >>> >> >> > From hang.vo at oracle.com Sun Dec 9 23:40:23 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 10 Dec 2012 07:40:23 +0000 Subject: hg: openjfx/2.2.6/graphics/rt: 38 new changesets Message-ID: <20121210074057.483BF47006@hg.openjdk.java.net> Changeset: 4c1ca708e1b5 Author: hudson Date: 2012-09-26 11:39 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/4c1ca708e1b5 Added tag 2.2.4-b09 for changeset 54c678a9f9b6 ! .hgtags Changeset: 866dd9865999 Author: hudson Date: 2012-06-28 07:07 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/866dd9865999 Added tag 2.2.1-b01 for changeset 00bc2ee17e47 ! .hgtags Changeset: 132f6c25f4b3 Author: kcr Date: 2012-07-12 06:23 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/132f6c25f4b3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt ! .hgtags Changeset: 69f5c94b4a3d Author: kcr Date: 2012-07-19 10:27 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/69f5c94b4a3d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt ! .hgtags Changeset: 42a29ad26a71 Author: kcr Date: 2012-07-28 07:53 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/42a29ad26a71 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt ! .hgtags Changeset: 91e85b55a3ee Author: hudson Date: 2012-08-08 15:15 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/91e85b55a3ee Added tag 2.2.1-b02 for changeset 42a29ad26a71 ! .hgtags Changeset: 1b48dfbd944c Author: hudson Date: 2012-09-07 13:29 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/1b48dfbd944c Added tag 2.2.1-b03 for changeset 91e85b55a3ee ! .hgtags Changeset: eb3438e74267 Author: hudson Date: 2012-09-07 17:41 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/eb3438e74267 Added tag 2.2.1-b04 for changeset 1b48dfbd944c ! .hgtags Changeset: 44f4a03ff92d Author: hudson Date: 2012-09-08 17:31 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/44f4a03ff92d Added tag 2.2.1-b05 for changeset eb3438e74267 ! .hgtags Changeset: 105d2b04b4ce Author: hudson Date: 2012-09-10 10:26 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/105d2b04b4ce Added tag 2.2.3-b02 ! .hgtags Changeset: f99798608d24 Author: hudson Date: 2012-09-12 16:29 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/f99798608d24 Added tag 2.2.3-b03 for changeset 105d2b04b4ce ! .hgtags Changeset: 46ea8d4fadd3 Author: hudson Date: 2012-09-20 14:00 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/46ea8d4fadd3 Added tag 2.2.3-b04 for changeset f99798608d24 ! .hgtags Changeset: 420285cc8db9 Author: hudson Date: 2012-09-25 13:45 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/420285cc8db9 Added tag 2.2.3-b05 for changeset 46ea8d4fadd3 ! .hgtags Changeset: 693dc811b166 Author: Paru Somashekar Date: 2012-08-15 15:03 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/693dc811b166 fix RT-24106 calling setLabelsVisible(false) on a PieChart causes the application to crash with a NPE at PieChart.layoutChartChildren() ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java Changeset: 264a190d4737 Author: hudson Date: 2012-09-29 21:55 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/264a190d4737 Added tag 2.2.4-b09 ! .hgtags Changeset: b819ec28c317 Author: hudson Date: 2012-10-03 15:10 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/b819ec28c317 Added tag 2.2.4-b10 for changeset 264a190d4737 ! .hgtags Changeset: 30710d0c5f30 Author: hudson Date: 2012-10-10 18:11 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/30710d0c5f30 Added tag 2.2.4-b11 for changeset b819ec28c317 ! .hgtags Changeset: 92938e0a1a53 Author: kcr Date: 2012-10-11 14:34 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/92938e0a1a53 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2/MASTER/jfx/rt ! .hgtags Changeset: 7dde672c2898 Author: kcr Date: 2012-10-16 16:08 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/7dde672c2898 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.4/MASTER/jfx/rt ! .hgtags Changeset: caa28b7ca651 Author: hudson Date: 2012-10-17 13:21 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/caa28b7ca651 Added tag 2.2.4-b12 for changeset 92938e0a1a53 ! .hgtags Changeset: 8b1111796760 Author: hudson Date: 2012-10-24 13:22 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/8b1111796760 Added tag 2.2.4-b13 for changeset caa28b7ca651 ! .hgtags Changeset: c3114e9f2215 Author: kcr Date: 2012-10-25 14:03 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/c3114e9f2215 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.4/MASTER/jfx/rt ! .hgtags Changeset: fb4d0e99bed7 Author: hudson Date: 2012-11-08 16:56 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/fb4d0e99bed7 Added tag 2.2.6-b01 for changeset c3114e9f2215 ! .hgtags Changeset: a763e336d0ed Author: hudson Date: 2012-11-15 20:35 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/a763e336d0ed Added tag 2.2.6-b02 for changeset fb4d0e99bed7 ! .hgtags Changeset: 868bef8eff55 Author: hudson Date: 2012-10-31 15:23 -0700 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/868bef8eff55 Added tag 2.2.4-b14 for changeset 8b1111796760 ! .hgtags Changeset: 4492579af767 Author: hudson Date: 2012-11-07 17:24 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/4492579af767 Added tag 2.2.4-b15 for changeset 868bef8eff55 ! .hgtags Changeset: c07a4dc990bb Author: hudson Date: 2012-11-14 18:53 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/c07a4dc990bb Added tag 2.2.4-b16 for changeset 4492579af767 ! .hgtags Changeset: c3fa08afde13 Author: hudson Date: 2012-11-21 14:10 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/c3fa08afde13 Added tag 2.2.4-b17 for changeset c07a4dc990bb ! .hgtags Changeset: 7d52ac515200 Author: kcr Date: 2012-11-26 19:28 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/7d52ac515200 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.4/MASTER/jfx/rt ! .hgtags Changeset: 5de32c121f10 Author: Paru Somashekar Date: 2012-11-28 15:35 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/5de32c121f10 fix/backport RT-23812 StackedAreaChart ClassCastException on CategoryAxis ! javafx-ui-charts/src/javafx/scene/chart/StackedAreaChart.java ! javafx-ui-charts/test/javafx/scene/chart/StackedAreaChartTest.java Changeset: 66716f2089bf Author: hudson Date: 2012-11-29 16:47 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/66716f2089bf Added tag 2.2.6-b03 for changeset 7d52ac515200 ! .hgtags Changeset: 25445fc9f478 Author: hudson Date: 2012-11-28 15:56 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/25445fc9f478 Added tag 2.2.4-b18 for changeset c3fa08afde13 ! .hgtags Changeset: c891fe0269ef Author: kcr Date: 2012-11-29 18:13 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/c891fe0269ef Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.4/MASTER/jfx/rt ! .hgtags Changeset: f87cb385192c Author: kcr Date: 2012-11-30 08:56 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/f87cb385192c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.6/MASTER/jfx/rt Changeset: 3617bc4b5d81 Author: Paru Somashekar Date: 2012-11-30 11:28 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/3617bc4b5d81 fix RT-23763 StackedBarChart does not work with autoranging category ! javafx-ui-charts/test/javafx/scene/chart/StackedBarChartTest.java ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java ! javafx-ui-controls/test/javafx/scene/chart/CategoryAxisTest.java Changeset: 0f987c50cd0f Author: David Grieve Date: 2012-12-06 13:16 -0500 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/0f987c50cd0f RT-24606: backport fix from 8.0 ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java + javafx-ui-common/test/unit/com/sun/javafx/css/StyleTest.java Changeset: fd9fd56f3be9 Author: David Grieve Date: 2012-12-06 13:34 -0500 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/fd9fd56f3be9 RT-24598: backport patch from 8.0 ! javafx-ui-common/src/com/sun/javafx/css/Declaration.java + javafx-ui-common/test/unit/com/sun/javafx/css/DeclarationTest.java Changeset: d95501d73070 Author: David Grieve Date: 2012-12-06 15:54 -0500 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/d95501d73070 RT-25016: backport from 8.0 ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java From ozemale at ozemail.com.au Mon Dec 10 00:29:47 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Mon, 10 Dec 2012 19:29:47 +1100 Subject: Survey: JavaFX on tablets and mobile devices In-Reply-To: <50C1970A.2030901@oracle.com> References: <50C1970A.2030901@oracle.com> Message-ID: <002701cdd6b0$83c079f0$8b416dd0$@com.au> Are you going to publish the results after a week or so? (And more importantly, how is Oracle going to respond? ;-) -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Jonathan Giles Sent: Friday, 7 December 2012 18:13 To: openjfx-dev at openjdk.java.net Subject: Survey: JavaFX on tablets and mobile devices Hi all, If you're the least bit interested in JavaFX on mobile devices (and it seems a few of you are), I'd really appreciate you making your voice heard over at FX Experience: http://fxexperience.com/2012/12/javafx-for-tablets-mobile/ I know that the cynical among you will question why this is necessary, that your voices should have already been heard, and that it is 'too little, too late'. Please indulge me this one last time - I'd really appreciate it - and I promise that your feedback will be heard by all the right people. Thanks, -- Jonathan From jonathan.giles at oracle.com Mon Dec 10 01:29:06 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 10 Dec 2012 22:29:06 +1300 Subject: Survey: JavaFX on tablets and mobile devices In-Reply-To: <002701cdd6b0$83c079f0$8b416dd0$@com.au> References: <50C1970A.2030901@oracle.com> <002701cdd6b0$83c079f0$8b416dd0$@com.au> Message-ID: <50C5AB62.8090104@oracle.com> I haven't spoken to anyone about how or if the results are to be published, but I've sent all the relevant people all the necessary nags to hope that it happens (with all data scrubbed of private details, obviously). Personally I'd love to see a JavaFX app be written to visualise and analyse the results :-) I'm but a lowly engineer, so I can't answer the second question (or indeed, most of the questions posed as a result of posting this survey). Let's just see what happens. Finally, since posting the survey a few days ago, we're pushing near to 500 responses. I'd love to see double that - at least! But, of course, I don't want people taking the survey ten times as mentioned previously :-) -- Jonathan On Monday, 10 December 2012 9:29:47 p.m., John C. Turnbull wrote: > Are you going to publish the results after a week or so? > > (And more importantly, how is Oracle going to respond? ;-) > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net > [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Jonathan Giles > Sent: Friday, 7 December 2012 18:13 > To: openjfx-dev at openjdk.java.net > Subject: Survey: JavaFX on tablets and mobile devices > > Hi all, > > If you're the least bit interested in JavaFX on mobile devices (and it seems > a few of you are), I'd really appreciate you making your voice heard over at > FX Experience: > > http://fxexperience.com/2012/12/javafx-for-tablets-mobile/ > > I know that the cynical among you will question why this is necessary, that > your voices should have already been heard, and that it is 'too little, too > late'. Please indulge me this one last time - I'd really appreciate it - and > I promise that your feedback will be heard by all the right people. > > Thanks, > -- Jonathan > From hang.vo at oracle.com Mon Dec 10 04:48:00 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 10 Dec 2012 12:48:00 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121210124807.DCD324700D@hg.openjdk.java.net> Changeset: d33ae5444ad0 Author: Martin Sladecek Date: 2012-12-10 13:41 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d33ae5444ad0 More tests & fixes for SequentialTransition. ! javafx-ui-common/src/javafx/animation/SequentialTransition.java ! javafx-ui-common/test/unit/javafx/animation/SequentialTransitionPlayTest.java Changeset: e4f650594652 Author: Martin Sladecek Date: 2012-12-10 13:42 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e4f650594652 merge From hang.vo at oracle.com Mon Dec 10 07:34:11 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 10 Dec 2012 15:34:11 +0000 Subject: hg: openjfx/8/controls/rt: 3 new changesets Message-ID: <20121210153419.078DF47017@hg.openjdk.java.net> Changeset: bf75ca4caf36 Author: David Grieve Date: 2012-12-07 14:41 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bf75ca4caf36 RT-21709 [partial]: prepare to make CSS Styleable* properites public ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java ! javafx-ui-charts/src/javafx/scene/chart/Chart.java ! javafx-ui-charts/src/javafx/scene/chart/LineChart.java ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java ! javafx-ui-charts/src/javafx/scene/chart/StackedAreaChart.java ! javafx-ui-charts/src/javafx/scene/chart/StackedBarChart.java ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java ! javafx-ui-charts/test/javafx/scene/chart/XYChartTest.java ! javafx-ui-common/src/com/sun/javafx/css/CascadingStyle.java ! javafx-ui-common/src/com/sun/javafx/css/CssError.java ! javafx-ui-common/src/com/sun/javafx/css/Declaration.java + javafx-ui-common/src/com/sun/javafx/css/Origin.java - javafx-ui-common/src/com/sun/javafx/css/Property.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Style.java ! javafx-ui-common/src/com/sun/javafx/css/StyleConverter.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/com/sun/javafx/css/Styleable.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableBooleanProperty.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableDoubleProperty.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableFloatProperty.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableIntegerProperty.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableLongProperty.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableObjectProperty.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableProperty.java + javafx-ui-common/src/com/sun/javafx/css/StyleablePropertyMetaData.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableStringProperty.java ! javafx-ui-common/src/com/sun/javafx/css/Stylesheet.java + javafx-ui-common/src/com/sun/javafx/css/SubCSSProperty.java - javafx-ui-common/src/com/sun/javafx/css/SubStyleableProperty.java ! javafx-ui-common/src/com/sun/javafx/css/converters/FontConverter.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/src/javafx/scene/layout/Background.java ! javafx-ui-common/src/javafx/scene/layout/BackgroundConverter.java ! javafx-ui-common/src/javafx/scene/layout/Border.java ! javafx-ui-common/src/javafx/scene/layout/BorderConverter.java ! javafx-ui-common/src/javafx/scene/layout/FlowPane.java ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/src/javafx/scene/layout/HBox.java ! javafx-ui-common/src/javafx/scene/layout/Region.java ! javafx-ui-common/src/javafx/scene/layout/StackPane.java ! javafx-ui-common/src/javafx/scene/layout/TilePane.java ! javafx-ui-common/src/javafx/scene/layout/VBox.java ! javafx-ui-common/src/javafx/scene/shape/Line.java ! javafx-ui-common/src/javafx/scene/shape/Path.java ! javafx-ui-common/src/javafx/scene/shape/Polyline.java ! javafx-ui-common/src/javafx/scene/shape/Rectangle.java ! javafx-ui-common/src/javafx/scene/shape/Shape.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/src/javafx/scene/text/TextFlow.java ! javafx-ui-common/test/unit/com/sun/javafx/css/DeclarationTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/RuleTest.java + javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyMetaDataTest.java - javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StylesheetTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/TestNode.java ! javafx-ui-common/test/unit/com/sun/javafx/css/TestNodeBase.java ! javafx-ui-common/test/unit/com/sun/javafx/css/TypeTest.java ! javafx-ui-common/test/unit/com/sun/javafx/scene/layout/RegionTest.java ! javafx-ui-common/test/unit/com/sun/javafx/scene/layout/region/BackgroundFillConverterTest.java ! javafx-ui-common/test/unit/com/sun/javafx/test/CssMethodsTestBase.java ! javafx-ui-common/test/unit/com/sun/javafx/test/OnInvalidateMethodsTestBase.java ! javafx-ui-common/test/unit/javafx/scene/CSSNode.java ! javafx-ui-common/test/unit/javafx/scene/Node_onInvalidate_Test.java ! javafx-ui-common/test/unit/javafx/scene/layout/TilePaneTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/ShapeTest.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CellSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVK.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledImpl.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/javafx/scene/chart/Axis.java ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java ! javafx-ui-controls/src/javafx/scene/chart/NumberAxis.java ! javafx-ui-controls/src/javafx/scene/chart/ValueAxis.java ! javafx-ui-controls/src/javafx/scene/control/Accordion.java ! javafx-ui-controls/src/javafx/scene/control/Cell.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/Hyperlink.java ! javafx-ui-controls/src/javafx/scene/control/Label.java ! 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/MenuBar.java ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/ProgressBar.java ! javafx-ui-controls/src/javafx/scene/control/ProgressIndicator.java ! javafx-ui-controls/src/javafx/scene/control/RadioButton.java ! javafx-ui-controls/src/javafx/scene/control/ScrollBar.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java ! javafx-ui-controls/src/javafx/scene/control/Separator.java ! javafx-ui-controls/src/javafx/scene/control/SkinBase.java ! javafx-ui-controls/src/javafx/scene/control/Slider.java ! javafx-ui-controls/src/javafx/scene/control/SplitPane.java ! javafx-ui-controls/src/javafx/scene/control/Tab.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TextField.java ! javafx-ui-controls/src/javafx/scene/control/TitledPane.java ! javafx-ui-controls/src/javafx/scene/control/ToggleButton.java ! javafx-ui-controls/src/javafx/scene/control/ToolBar.java ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTableCell.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabeledImplTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabeledImplTestOther.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabeledTextTest.java ! javafx-ui-controls/test/javafx/scene/chart/AxisTest.java ! javafx-ui-controls/test/javafx/scene/chart/CategoryAxisTest.java ! javafx-ui-controls/test/javafx/scene/chart/NumberAxisTest.java ! javafx-ui-controls/test/javafx/scene/chart/ValueAxisTest.java ! javafx-ui-controls/test/javafx/scene/control/ControlSkinTest.java ! javafx-ui-controls/test/javafx/scene/control/ControlTest.java ! javafx-ui-controls/test/javafx/scene/control/HyperlinkTest.java ! javafx-ui-controls/test/javafx/scene/control/LabelTest.java ! javafx-ui-controls/test/javafx/scene/control/LabeledTest.java ! javafx-ui-controls/test/javafx/scene/control/PaginationTest.java ! javafx-ui-controls/test/javafx/scene/control/ScrollBarTest.java ! javafx-ui-controls/test/javafx/scene/control/ScrollPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/SeparatorTest.java ! javafx-ui-controls/test/javafx/scene/control/SliderTest.java ! javafx-ui-controls/test/javafx/scene/control/SplitPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/TextInputControlTest.java ! javafx-ui-controls/test/javafx/scene/control/TitledPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/ToolbarTest.java ! javafx-ui-controls/test/javafx/scene/control/TooltipTest.java Changeset: 382ea952840d Author: David Grieve Date: 2012-12-07 15:13 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/382ea952840d merge - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableColumn.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableRow.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableView.java - javafx-ui-controls/src/com/sun/javafx/scene/control/WeakEventHandler.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/javafx/scene/chart/Axis.java ! javafx-ui-controls/src/javafx/scene/chart/ValueAxis.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/ProgressBar.java ! javafx-ui-controls/src/javafx/scene/control/ProgressIndicator.java ! javafx-ui-controls/src/javafx/scene/control/SkinBase.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/test/javafx/scene/control/SliderTest.java Changeset: 55b52b24b94d Author: David Grieve Date: 2012-12-10 10:26 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/55b52b24b94d RT-21709 [partial]: fix merge errors after pulling changes onto bf75ca4caf36 ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeTableCell.java From david.grieve at oracle.com Mon Dec 10 10:18:28 2012 From: david.grieve at oracle.com (David Grieve) Date: Mon, 10 Dec 2012 13:18:28 -0500 Subject: Need help choosing a class name for CSS public API Message-ID: In the CSS public API proposal (https://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls), I have a class name that is rather cumbersome and I'm trying to find another name. The class name in the proposal is StyleablePropertyMetaData and, to some extent, that is what the class is since this is where the node's property and the css property come together. The meta-data for Node's opacityProperty is shown below. As you can see, there is some information about the css property name (-fx-opacity), the type of value (a ) and the initial property value. There are also two methods that are used by CSS so that CSS can set the property value. So, I'm looking for a name for this thing thinking that there must be something better than StyleablePropertyMetaData. I was thinking StyleAgent since this class takes an active role in interacting with the node property. But "agent" has the connotation of something running in the background. Maybe StyleLiaison? private static final StyleablePropertyMetaData OPACITY = new StyleablePropertyMetaData ("-fx-opacity", SizeConverter.getInstance(), 1.0) { @Override public boolean isSettable(Node node) { return node.opacity == null || !node.opacity.isBound(); } @Override public WritableValue getWritableValue(Node node) { return node.opacityProperty(); } }; Does anyone have a suggestion? From randahl at rockit.dk Mon Dec 10 10:23:53 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Mon, 10 Dec 2012 19:23:53 +0100 Subject: Need help choosing a class name for CSS public API In-Reply-To: References: Message-ID: Top of my mind: StyleMedium ? since it is the medium through which the style is communicated to the node. Randahl On Dec 10, 2012, at 19:18 , David Grieve wrote: > In the CSS public API proposal (https://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls), I have a class name that is rather cumbersome and I'm trying to find another name. The class name in the proposal is StyleablePropertyMetaData and, to some extent, that is what the class is since this is where the node's property and the css property come together. The meta-data for Node's opacityProperty is shown below. As you can see, there is some information about the css property name (-fx-opacity), the type of value (a ) and the initial property value. There are also two methods that are used by CSS so that CSS can set the property value. > > So, I'm looking for a name for this thing thinking that there must be something better than StyleablePropertyMetaData. I was thinking StyleAgent since this class takes an active role in interacting with the node property. But "agent" has the connotation of something running in the background. Maybe StyleLiaison? > > private static final StyleablePropertyMetaData OPACITY = > new StyleablePropertyMetaData ("-fx-opacity", > SizeConverter.getInstance(), 1.0) { > > @Override > public boolean isSettable(Node node) { > return node.opacity == null || !node.opacity.isBound(); > } > > @Override > public WritableValue getWritableValue(Node node) { > return node.opacityProperty(); > } > }; > > Does anyone have a suggestion? From randahl at rockit.dk Mon Dec 10 10:25:05 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Mon, 10 Dec 2012 19:25:05 +0100 Subject: Need help choosing a class name for CSS public API In-Reply-To: References: Message-ID: <29731E2D-0184-437C-9FC2-19526E349E67@rockit.dk> Alternatively, "StyleBridge". But that name will probably open up a Java patterns discussion :-) Randahl On Dec 10, 2012, at 19:23 , Randahl Fink Isaksen wrote: > Top of my mind: StyleMedium > > ? since it is the medium through which the style is communicated to the node. > > Randahl > > > > On Dec 10, 2012, at 19:18 , David Grieve wrote: > >> In the CSS public API proposal (https://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls), I have a class name that is rather cumbersome and I'm trying to find another name. The class name in the proposal is StyleablePropertyMetaData and, to some extent, that is what the class is since this is where the node's property and the css property come together. The meta-data for Node's opacityProperty is shown below. As you can see, there is some information about the css property name (-fx-opacity), the type of value (a ) and the initial property value. There are also two methods that are used by CSS so that CSS can set the property value. >> >> So, I'm looking for a name for this thing thinking that there must be something better than StyleablePropertyMetaData. I was thinking StyleAgent since this class takes an active role in interacting with the node property. But "agent" has the connotation of something running in the background. Maybe StyleLiaison? >> >> private static final StyleablePropertyMetaData OPACITY = >> new StyleablePropertyMetaData ("-fx-opacity", >> SizeConverter.getInstance(), 1.0) { >> >> @Override >> public boolean isSettable(Node node) { >> return node.opacity == null || !node.opacity.isBound(); >> } >> >> @Override >> public WritableValue getWritableValue(Node node) { >> return node.opacityProperty(); >> } >> }; >> >> Does anyone have a suggestion? > From tbee at tbee.org Mon Dec 10 11:41:02 2012 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 10 Dec 2012 20:41:02 +0100 Subject: Need help choosing a class name for CSS public API In-Reply-To: <29731E2D-0184-437C-9FC2-19526E349E67@rockit.dk> References: <29731E2D-0184-437C-9FC2-19526E349E67@rockit.dk> Message-ID: <50C63ACE.2030508@tbee.org> Ahhh, yes, in light of the recent layout discussions, how about CSSGlue? Or CSSPropertyGlue? Since it glues stuff together. :-) Tom On 2012-12-10 19:25, Randahl Fink Isaksen wrote: > Alternatively, "StyleBridge". But that name will probably open up a Java patterns discussion :-) > > Randahl > > > On Dec 10, 2012, at 19:23 , Randahl Fink Isaksen wrote: > >> Top of my mind: StyleMedium >> >> ? since it is the medium through which the style is communicated to the node. >> >> Randahl >> >> >> >> On Dec 10, 2012, at 19:18 , David Grieve wrote: >> >>> In the CSS public API proposal (https://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls), I have a class name that is rather cumbersome and I'm trying to find another name. The class name in the proposal is StyleablePropertyMetaData and, to some extent, that is what the class is since this is where the node's property and the css property come together. The meta-data for Node's opacityProperty is shown below. As you can see, there is some information about the css property name (-fx-opacity), the type of value (a ) and the initial property value. There are also two methods that are used by CSS so that CSS can set the property value. >>> >>> So, I'm looking for a name for this thing thinking that there must be something better than StyleablePropertyMetaData. I was thinking StyleAgent since this class takes an active role in interacting with the node property. But "agent" has the connotation of something running in the background. Maybe StyleLiaison? >>> >>> private static final StyleablePropertyMetaData OPACITY = >>> new StyleablePropertyMetaData ("-fx-opacity", >>> SizeConverter.getInstance(), 1.0) { >>> >>> @Override >>> public boolean isSettable(Node node) { >>> return node.opacity == null || !node.opacity.isBound(); >>> } >>> >>> @Override >>> public WritableValue getWritableValue(Node node) { >>> return node.opacityProperty(); >>> } >>> }; >>> >>> Does anyone have a suggestion? From james.weaver at oracle.com Mon Dec 10 11:59:03 2012 From: james.weaver at oracle.com (Jim Weaver) Date: Mon, 10 Dec 2012 14:59:03 -0500 Subject: Need help choosing a class name for CSS public API In-Reply-To: <50C63ACE.2030508@tbee.org> References: <29731E2D-0184-437C-9FC2-19526E349E67@rockit.dk> <50C63ACE.2030508@tbee.org> Message-ID: <50C63F07.1030600@oracle.com> I was going to suggest StyleGlue Regards, Jim Weaver On 12/10/12 2:41 PM, Tom Eugelink wrote: > Ahhh, yes, in light of the recent layout discussions, how about > CSSGlue? Or CSSPropertyGlue? Since it glues stuff together. :-) > > Tom > > > > On 2012-12-10 19:25, Randahl Fink Isaksen wrote: >> Alternatively, "StyleBridge". But that name will probably open up a >> Java patterns discussion :-) >> >> Randahl >> >> >> On Dec 10, 2012, at 19:23 , Randahl Fink Isaksen >> wrote: >> >>> Top of my mind: StyleMedium >>> >>> ? since it is the medium through which the style is communicated to >>> the node. >>> >>> Randahl >>> >>> >>> >>> On Dec 10, 2012, at 19:18 , David Grieve >>> wrote: >>> >>>> In the CSS public API proposal >>>> (https://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls), >>>> I have a class name that is rather cumbersome and I'm trying to >>>> find another name. The class name in the proposal is >>>> StyleablePropertyMetaData and, to some extent, that is what the >>>> class is since this is where the node's property and the css >>>> property come together. The meta-data for Node's opacityProperty is >>>> shown below. As you can see, there is some information about the >>>> css property name (-fx-opacity), the type of value (a ) and >>>> the initial property value. There are also two methods that are >>>> used by CSS so that CSS can set the property value. >>>> >>>> So, I'm looking for a name for this thing thinking that there must >>>> be something better than StyleablePropertyMetaData. I was thinking >>>> StyleAgent since this class takes an active role in interacting >>>> with the node property. But "agent" has the connotation of >>>> something running in the background. Maybe StyleLiaison? >>>> >>>> private static final StyleablePropertyMetaData >>>> OPACITY = >>>> new StyleablePropertyMetaData ("-fx-opacity", >>>> SizeConverter.getInstance(), 1.0) { >>>> >>>> @Override >>>> public boolean isSettable(Node node) { >>>> return node.opacity == null || >>>> !node.opacity.isBound(); >>>> } >>>> >>>> @Override >>>> public WritableValue getWritableValue(Node >>>> node) { >>>> return node.opacityProperty(); >>>> } >>>> }; >>>> >>>> Does anyone have a suggestion? > -- Regards, Jim Weaver Java Technology Ambassador Oracle Corporation james.weaver at oracle.com From Adrian.Raybould at theice.com Mon Dec 10 11:59:56 2012 From: Adrian.Raybould at theice.com (Adrian Raybould) Date: Mon, 10 Dec 2012 14:59:56 -0500 Subject: How to JNLP launch OpenJFX when customer is using Java 7u6 or later Message-ID: <054953771B79D14DA8211D79BA755EC540E381788F@at-bp-ixmx-03.CPEX.com> We are looking to use OpenJFX for some new UI development but have come across an issue. We use web-start to deploy our product to customers, with Java 1.6 and earlier 1.7 versions everything was fine. Now though, Java 7u6 and later has the jfxrt.jar already deployed and so it overrides our jfxrt.jar deployment - is there any way to turn off the pick-up from the JVM location ? Note - in a local install you can you -Xbootclasspath/p but you can't use this in a web-start environment (for obvious security reasons). ________________________________ This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. From hang.vo at oracle.com Mon Dec 10 12:04:22 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 10 Dec 2012 20:04:22 +0000 Subject: hg: openjfx/8/controls/rt: fix RT-26820 ChoiceBox with no items throws exception when added to live scene. Message-ID: <20121210200425.5B09D4701B@hg.openjdk.java.net> Changeset: a867b54962e3 Author: Paru Somashekar Date: 2012-12-10 11:57 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a867b54962e3 fix RT-26820 ChoiceBox with no items throws exception when added to live scene. + unit test. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/test/javafx/scene/control/ChoiceBoxTest.java From joe.mcglynn at oracle.com Mon Dec 10 12:11:08 2012 From: joe.mcglynn at oracle.com (Joe McGlynn) Date: Mon, 10 Dec 2012 12:11:08 -0800 Subject: How to JNLP launch OpenJFX when customer is using Java 7u6 or later In-Reply-To: <054953771B79D14DA8211D79BA755EC540E381788F@at-bp-ixmx-03.CPEX.com> References: <054953771B79D14DA8211D79BA755EC540E381788F@at-bp-ixmx-03.CPEX.com> Message-ID: <405C8983-684E-456F-91DA-2DE3DF5BF60F@oracle.com> No, the version of FX that is used with JDK 7+ is intended to be fixed -- in the same way that Swing or any other part of the JRE is locked. From randahl at rockit.dk Mon Dec 10 12:18:25 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Mon, 10 Dec 2012 21:18:25 +0100 Subject: Need help choosing a class name for CSS public API In-Reply-To: <50C63F07.1030600@oracle.com> References: <29731E2D-0184-437C-9FC2-19526E349E67@rockit.dk> <50C63ACE.2030508@tbee.org> <50C63F07.1030600@oracle.com> Message-ID: +1 on StyleGlue. On Dec 10, 2012, at 20:59 , Jim Weaver wrote: > I was going to suggest StyleGlue > > Regards, > Jim Weaver > > On 12/10/12 2:41 PM, Tom Eugelink wrote: >> Ahhh, yes, in light of the recent layout discussions, how about CSSGlue? Or CSSPropertyGlue? Since it glues stuff together. :-) >> >> Tom >> >> >> >> On 2012-12-10 19:25, Randahl Fink Isaksen wrote: >>> Alternatively, "StyleBridge". But that name will probably open up a Java patterns discussion :-) >>> >>> Randahl >>> >>> >>> On Dec 10, 2012, at 19:23 , Randahl Fink Isaksen wrote: >>> >>>> Top of my mind: StyleMedium >>>> >>>> ? since it is the medium through which the style is communicated to the node. >>>> >>>> Randahl >>>> >>>> >>>> >>>> On Dec 10, 2012, at 19:18 , David Grieve wrote: >>>> >>>>> In the CSS public API proposal (https://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls), I have a class name that is rather cumbersome and I'm trying to find another name. The class name in the proposal is StyleablePropertyMetaData and, to some extent, that is what the class is since this is where the node's property and the css property come together. The meta-data for Node's opacityProperty is shown below. As you can see, there is some information about the css property name (-fx-opacity), the type of value (a ) and the initial property value. There are also two methods that are used by CSS so that CSS can set the property value. >>>>> >>>>> So, I'm looking for a name for this thing thinking that there must be something better than StyleablePropertyMetaData. I was thinking StyleAgent since this class takes an active role in interacting with the node property. But "agent" has the connotation of something running in the background. Maybe StyleLiaison? >>>>> >>>>> private static final StyleablePropertyMetaData OPACITY = >>>>> new StyleablePropertyMetaData ("-fx-opacity", >>>>> SizeConverter.getInstance(), 1.0) { >>>>> >>>>> @Override >>>>> public boolean isSettable(Node node) { >>>>> return node.opacity == null || !node.opacity.isBound(); >>>>> } >>>>> >>>>> @Override >>>>> public WritableValue getWritableValue(Node node) { >>>>> return node.opacityProperty(); >>>>> } >>>>> }; >>>>> >>>>> Does anyone have a suggestion? >> > > > -- > Regards, > Jim Weaver > Java Technology Ambassador > Oracle Corporation > james.weaver at oracle.com > From pedro.duquevieira at gmail.com Mon Dec 10 12:19:34 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 10 Dec 2012 20:19:34 +0000 Subject: Need help styling context menu Message-ID: Hi, Need help styling context menu using CSS. First the CSS reference guide has nothing on this, second consulting caspian.css won't help because there's very little code for this class. What I'm struggling with right now is in defining an alternate look for the separator line (on the context menu), from what I've seen so far I can say that it is not consistent with the other separators because with the same lines of CSS I can't get it to have the same black colored solid look. Can someone give me some guidelines on this? Thanks in advance, :) -- Pedro Duque Vieira From jan.schenkel at quartam.com Mon Dec 10 12:35:17 2012 From: jan.schenkel at quartam.com (Quartam - Jan Schenkel) Date: Mon, 10 Dec 2012 21:35:17 +0100 Subject: Need help choosing a class name for CSS public API In-Reply-To: References: Message-ID: <6798E676-1F95-49A5-87F0-26E937F86D53@quartam.com> How about CSSMetaData? If it's not already used elsewhere, it would seem reasonably short and to-the-point. Jan. On 10 Dec 2012, at 19:18, David Grieve wrote: > In the CSS public API proposal (https://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls), I have a class name that is rather cumbersome and I'm trying to find another name. The class name in the proposal is StyleablePropertyMetaData and, to some extent, that is what the class is since this is where the node's property and the css property come together. The meta-data for Node's opacityProperty is shown below. As you can see, there is some information about the css property name (-fx-opacity), the type of value (a ) and the initial property value. There are also two methods that are used by CSS so that CSS can set the property value. > > So, I'm looking for a name for this thing thinking that there must be something better than StyleablePropertyMetaData. I was thinking StyleAgent since this class takes an active role in interacting with the node property. But "agent" has the connotation of something running in the background. Maybe StyleLiaison? > > private static final StyleablePropertyMetaData OPACITY = > new StyleablePropertyMetaData ("-fx-opacity", > SizeConverter.getInstance(), 1.0) { > > @Override > public boolean isSettable(Node node) { > return node.opacity == null || !node.opacity.isBound(); > } > > @Override > public WritableValue getWritableValue(Node node) { > return node.opacityProperty(); > } > }; > > Does anyone have a suggestion? From jonathan.giles at oracle.com Mon Dec 10 12:38:40 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 11 Dec 2012 09:38:40 +1300 Subject: Need help styling context menu In-Reply-To: References: Message-ID: <50C64850.3040703@oracle.com> There are plenty of references to .separator in caspian.css - I wouldn't discount how useful referring to these would be. If you continue to have trouble definitely file a bug report and we'll take a look. -- Jonathan On 11/12/2012 9:19 a.m., Pedro Duque Vieira wrote: > Hi, > > Need help styling context menu using CSS. First the CSS reference guide has > nothing on this, second consulting caspian.css won't help because there's > very little code for this class. > > What I'm struggling with right now is in defining an alternate look for the > separator line (on the context menu), from what I've seen so far I can say > that it is not consistent with the other separators because with the same > lines of CSS I can't get it to have the same black colored solid look. > > Can someone give me some guidelines on this? > > Thanks in advance, :) > From richard.bair at oracle.com Mon Dec 10 13:03:56 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 10 Dec 2012 13:03:56 -0800 Subject: Need help choosing a class name for CSS public API In-Reply-To: <6798E676-1F95-49A5-87F0-26E937F86D53@quartam.com> References: <6798E676-1F95-49A5-87F0-26E937F86D53@quartam.com> Message-ID: <050175C2-7B8A-4057-9F4C-D9798C8669EF@oracle.com> We started off with StyleablePropertyMetaData -- but it is really long. CSSMetaData is certainly shorter. I'm not really a fan of "Glue", I get sticky fingers just thinking about it! :-) Richard On Dec 10, 2012, at 12:35 PM, Quartam - Jan Schenkel wrote: > How about CSSMetaData? > If it's not already used elsewhere, it would seem reasonably short and to-the-point. > > Jan. > > On 10 Dec 2012, at 19:18, David Grieve wrote: > >> In the CSS public API proposal (https://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls), I have a class name that is rather cumbersome and I'm trying to find another name. The class name in the proposal is StyleablePropertyMetaData and, to some extent, that is what the class is since this is where the node's property and the css property come together. The meta-data for Node's opacityProperty is shown below. As you can see, there is some information about the css property name (-fx-opacity), the type of value (a ) and the initial property value. There are also two methods that are used by CSS so that CSS can set the property value. >> >> So, I'm looking for a name for this thing thinking that there must be something better than StyleablePropertyMetaData. I was thinking StyleAgent since this class takes an active role in interacting with the node property. But "agent" has the connotation of something running in the background. Maybe StyleLiaison? >> >> private static final StyleablePropertyMetaData OPACITY = >> new StyleablePropertyMetaData ("-fx-opacity", >> SizeConverter.getInstance(), 1.0) { >> >> @Override >> public boolean isSettable(Node node) { >> return node.opacity == null || !node.opacity.isBound(); >> } >> >> @Override >> public WritableValue getWritableValue(Node node) { >> return node.opacityProperty(); >> } >> }; >> >> Does anyone have a suggestion? From david.grieve at oracle.com Mon Dec 10 13:21:14 2012 From: david.grieve at oracle.com (David Grieve) Date: Mon, 10 Dec 2012 16:21:14 -0500 Subject: Need help choosing a class name for CSS public API In-Reply-To: <050175C2-7B8A-4057-9F4C-D9798C8669EF@oracle.com> References: <6798E676-1F95-49A5-87F0-26E937F86D53@quartam.com> <050175C2-7B8A-4057-9F4C-D9798C8669EF@oracle.com> Message-ID: <1BDA2A82-E374-4419-99B2-2C560F92A281@oracle.com> How about CssIntermediary? I'm thinking that any name that starts with Style might be a bad idea since I can see us wanting to have a Style class somewhere down the road. On Dec 10, 2012, at 4:03 PM, Richard Bair wrote: > We started off with StyleablePropertyMetaData -- but it is really long. CSSMetaData is certainly shorter. > > I'm not really a fan of "Glue", I get sticky fingers just thinking about it! :-) > > Richard > > On Dec 10, 2012, at 12:35 PM, Quartam - Jan Schenkel wrote: > >> How about CSSMetaData? >> If it's not already used elsewhere, it would seem reasonably short and to-the-point. >> >> Jan. >> >> On 10 Dec 2012, at 19:18, David Grieve wrote: >> >>> In the CSS public API proposal (https://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls), I have a class name that is rather cumbersome and I'm trying to find another name. The class name in the proposal is StyleablePropertyMetaData and, to some extent, that is what the class is since this is where the node's property and the css property come together. The meta-data for Node's opacityProperty is shown below. As you can see, there is some information about the css property name (-fx-opacity), the type of value (a ) and the initial property value. There are also two methods that are used by CSS so that CSS can set the property value. >>> >>> So, I'm looking for a name for this thing thinking that there must be something better than StyleablePropertyMetaData. I was thinking StyleAgent since this class takes an active role in interacting with the node property. But "agent" has the connotation of something running in the background. Maybe StyleLiaison? >>> >>> private static final StyleablePropertyMetaData OPACITY = >>> new StyleablePropertyMetaData ("-fx-opacity", >>> SizeConverter.getInstance(), 1.0) { >>> >>> @Override >>> public boolean isSettable(Node node) { >>> return node.opacity == null || !node.opacity.isBound(); >>> } >>> >>> @Override >>> public WritableValue getWritableValue(Node node) { >>> return node.opacityProperty(); >>> } >>> }; >>> >>> Does anyone have a suggestion? > From tom.schindl at bestsolution.at Mon Dec 10 13:27:39 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 10 Dec 2012 22:27:39 +0100 Subject: Need help choosing a class name for CSS public API In-Reply-To: <1BDA2A82-E374-4419-99B2-2C560F92A281@oracle.com> References: <6798E676-1F95-49A5-87F0-26E937F86D53@quartam.com> <050175C2-7B8A-4057-9F4C-D9798C8669EF@oracle.com> <1BDA2A82-E374-4419-99B2-2C560F92A281@oracle.com> Message-ID: <50C653CB.40503@bestsolution.at> CSSPropertyMediator? Tom Am 10.12.12 22:21, schrieb David Grieve: > How about CssIntermediary? > > I'm thinking that any name that starts with Style might be a bad idea since I can see us wanting to have a Style class somewhere down the road. > > On Dec 10, 2012, at 4:03 PM, Richard Bair wrote: > >> We started off with StyleablePropertyMetaData -- but it is really long. CSSMetaData is certainly shorter. >> >> I'm not really a fan of "Glue", I get sticky fingers just thinking about it! :-) >> >> Richard >> >> On Dec 10, 2012, at 12:35 PM, Quartam - Jan Schenkel wrote: >> >>> How about CSSMetaData? >>> If it's not already used elsewhere, it would seem reasonably short and to-the-point. >>> >>> Jan. >>> >>> On 10 Dec 2012, at 19:18, David Grieve wrote: >>> >>>> In the CSS public API proposal (https://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls), I have a class name that is rather cumbersome and I'm trying to find another name. The class name in the proposal is StyleablePropertyMetaData and, to some extent, that is what the class is since this is where the node's property and the css property come together. The meta-data for Node's opacityProperty is shown below. As you can see, there is some information about the css property name (-fx-opacity), the type of value (a ) and the initial property value. There are also two methods that are used by CSS so that CSS can set the property value. >>>> >>>> So, I'm looking for a name for this thing thinking that there must be something better than StyleablePropertyMetaData. I was thinking StyleAgent since this class takes an active role in interacting with the node property. But "agent" has the connotation of something running in the background. Maybe StyleLiaison? >>>> >>>> private static final StyleablePropertyMetaData OPACITY = >>>> new StyleablePropertyMetaData ("-fx-opacity", >>>> SizeConverter.getInstance(), 1.0) { >>>> >>>> @Override >>>> public boolean isSettable(Node node) { >>>> return node.opacity == null || !node.opacity.isBound(); >>>> } >>>> >>>> @Override >>>> public WritableValue getWritableValue(Node node) { >>>> return node.opacityProperty(); >>>> } >>>> }; >>>> >>>> Does anyone have a suggestion? >> > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From pedro.duquevieira at gmail.com Mon Dec 10 15:24:29 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Mon, 10 Dec 2012 23:24:29 +0000 Subject: Need help styling context menu In-Reply-To: <50C64850.3040703@oracle.com> References: <50C64850.3040703@oracle.com> Message-ID: I've solved the issue with the separator. Sorry for bothering you, it was something I mistakenly overlooked. The issue that there is no documentation on styling Context Menu througth CSS still remains though, Thanks, best regards, On Mon, Dec 10, 2012 at 8:38 PM, Jonathan Giles wrote: > There are plenty of references to .separator in caspian.css - I wouldn't > discount how useful referring to these would be. > > If you continue to have trouble definitely file a bug report and we'll > take a look. > > -- Jonathan > > > On 11/12/2012 9:19 a.m., Pedro Duque Vieira wrote: > >> Hi, >> >> Need help styling context menu using CSS. First the CSS reference guide >> has >> nothing on this, second consulting caspian.css won't help because there's >> very little code for this class. >> >> What I'm struggling with right now is in defining an alternate look for >> the >> separator line (on the context menu), from what I've seen so far I can say >> that it is not consistent with the other separators because with the same >> lines of CSS I can't get it to have the same black colored solid look. >> >> Can someone give me some guidelines on this? >> >> Thanks in advance, :) >> >> > -- Pedro Duque Vieira From jonathan.giles at oracle.com Mon Dec 10 15:26:23 2012 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 11 Dec 2012 12:26:23 +1300 Subject: Need help styling context menu In-Reply-To: References: <50C64850.3040703@oracle.com> Message-ID: <50C66F9F.1020807@oracle.com> Certainly we have a long way to go in improving our technical documentation. I will try to do a big push prior to 8.0 shipping to improve it as much as possible. -- Jonathan On 11/12/2012 12:24 p.m., Pedro Duque Vieira wrote: > I've solved the issue with the separator. Sorry for bothering you, it > was something I mistakenly overlooked. > > The issue that there is no documentation on styling Context Menu > througth CSS still remains though, > > Thanks, best regards, > > On Mon, Dec 10, 2012 at 8:38 PM, Jonathan Giles > > wrote: > > There are plenty of references to .separator in caspian.css - I > wouldn't discount how useful referring to these would be. > > If you continue to have trouble definitely file a bug report and > we'll take a look. > > -- Jonathan > > > On 11/12/2012 9:19 a.m., Pedro Duque Vieira wrote: > > Hi, > > Need help styling context menu using CSS. First the CSS > reference guide has > nothing on this, second consulting caspian.css won't help > because there's > very little code for this class. > > What I'm struggling with right now is in defining an alternate > look for the > separator line (on the context menu), from what I've seen so > far I can say > that it is not consistent with the other separators because > with the same > lines of CSS I can't get it to have the same black colored > solid look. > > Can someone give me some guidelines on this? > > Thanks in advance, :) > > > > > > -- > Pedro Duque Vieira From John_Smith at symantec.com Mon Dec 10 16:35:14 2012 From: John_Smith at symantec.com (John Smith) Date: Mon, 10 Dec 2012 16:35:14 -0800 Subject: Need help styling context menu In-Reply-To: <50C66F9F.1020807@oracle.com> References: <50C64850.3040703@oracle.com> <50C66F9F.1020807@oracle.com> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D22160B0D773F@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> I think it would be beneficial to have something that visually shows the css classes of the elements which can be styled. See here for a sample from the ZK style guide on the kind of visual callout of style classes I am thinking of: http://books.zkoss.org/wiki/ZK%20Style%20Guide/XUL%20Component%20Specification/Column/Default http://books.zkoss.org/wiki/ZK_Style_Guide/XUL_Component_Specification/Colorbox/Default -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Jonathan Giles Sent: Monday, December 10, 2012 3:26 PM To: Pedro Duque Vieira Cc: OpenJFX Mailing List Subject: Re: Need help styling context menu Certainly we have a long way to go in improving our technical documentation. I will try to do a big push prior to 8.0 shipping to improve it as much as possible. -- Jonathan On 11/12/2012 12:24 p.m., Pedro Duque Vieira wrote: > I've solved the issue with the separator. Sorry for bothering you, it > was something I mistakenly overlooked. > > The issue that there is no documentation on styling Context Menu > througth CSS still remains though, > > Thanks, best regards, > > On Mon, Dec 10, 2012 at 8:38 PM, Jonathan Giles > > wrote: > > There are plenty of references to .separator in caspian.css - I > wouldn't discount how useful referring to these would be. > > If you continue to have trouble definitely file a bug report and > we'll take a look. > > -- Jonathan > > > On 11/12/2012 9:19 a.m., Pedro Duque Vieira wrote: > > Hi, > > Need help styling context menu using CSS. First the CSS > reference guide has > nothing on this, second consulting caspian.css won't help > because there's > very little code for this class. > > What I'm struggling with right now is in defining an alternate > look for the > separator line (on the context menu), from what I've seen so > far I can say > that it is not consistent with the other separators because > with the same > lines of CSS I can't get it to have the same black colored > solid look. > > Can someone give me some guidelines on this? > > Thanks in advance, :) > > > > > > -- > Pedro Duque Vieira From han.solo at muenster.de Mon Dec 10 20:51:39 2012 From: han.solo at muenster.de (Gerrit Grunwald) Date: Tue, 11 Dec 2012 05:51:39 +0100 Subject: Need help choosing a class name for CSS public API In-Reply-To: <050175C2-7B8A-4057-9F4C-D9798C8669EF@oracle.com> References: <6798E676-1F95-49A5-87F0-26E937F86D53@quartam.com> <050175C2-7B8A-4057-9F4C-D9798C8669EF@oracle.com> Message-ID: +1 CSSMetaData Gerrit Grunwald Am 10.12.2012 um 22:03 schrieb Richard Bair : > We started off with StyleablePropertyMetaData -- but it is really long. CSSMetaData is certainly shorter. > > I'm not really a fan of "Glue", I get sticky fingers just thinking about it! :-) > > Richard > > On Dec 10, 2012, at 12:35 PM, Quartam - Jan Schenkel wrote: > >> How about CSSMetaData? >> If it's not already used elsewhere, it would seem reasonably short and to-the-point. >> >> Jan. >> >> On 10 Dec 2012, at 19:18, David Grieve wrote: >> >>> In the CSS public API proposal (https://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls), I have a class name that is rather cumbersome and I'm trying to find another name. The class name in the proposal is StyleablePropertyMetaData and, to some extent, that is what the class is since this is where the node's property and the css property come together. The meta-data for Node's opacityProperty is shown below. As you can see, there is some information about the css property name (-fx-opacity), the type of value (a ) and the initial property value. There are also two methods that are used by CSS so that CSS can set the property value. >>> >>> So, I'm looking for a name for this thing thinking that there must be something better than StyleablePropertyMetaData. I was thinking StyleAgent since this class takes an active role in interacting with the node property. But "agent" has the connotation of something running in the background. Maybe StyleLiaison? >>> >>> private static final StyleablePropertyMetaData OPACITY = >>> new StyleablePropertyMetaData ("-fx-opacity", >>> SizeConverter.getInstance(), 1.0) { >>> >>> @Override >>> public boolean isSettable(Node node) { >>> return node.opacity == null || !node.opacity.isBound(); >>> } >>> >>> @Override >>> public WritableValue getWritableValue(Node node) { >>> return node.opacityProperty(); >>> } >>> }; >>> >>> Does anyone have a suggestion? > From tbee at tbee.org Mon Dec 10 22:11:42 2012 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 11 Dec 2012 07:11:42 +0100 Subject: Need help styling context menu In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D22160B0D773F@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <50C64850.3040703@oracle.com> <50C66F9F.1020807@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D22160B0D773F@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <50C6CE9E.5090802@tbee.org> That would certainly be an improvement. On 2012-12-11 01:35, John Smith wrote: > I think it would be beneficial to have something that visually shows the css classes of the elements which can be styled. > > See here for a sample from the ZK style guide on the kind of visual callout of style classes I am thinking of: > http://books.zkoss.org/wiki/ZK%20Style%20Guide/XUL%20Component%20Specification/Column/Default > http://books.zkoss.org/wiki/ZK_Style_Guide/XUL_Component_Specification/Colorbox/Default > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Jonathan Giles > Sent: Monday, December 10, 2012 3:26 PM > To: Pedro Duque Vieira > Cc: OpenJFX Mailing List > Subject: Re: Need help styling context menu > > Certainly we have a long way to go in improving our technical documentation. I will try to do a big push prior to 8.0 shipping to improve it as much as possible. > > -- Jonathan > > On 11/12/2012 12:24 p.m., Pedro Duque Vieira wrote: >> I've solved the issue with the separator. Sorry for bothering you, it >> was something I mistakenly overlooked. >> >> The issue that there is no documentation on styling Context Menu >> througth CSS still remains though, >> >> Thanks, best regards, >> >> On Mon, Dec 10, 2012 at 8:38 PM, Jonathan Giles >> > wrote: >> >> There are plenty of references to .separator in caspian.css - I >> wouldn't discount how useful referring to these would be. >> >> If you continue to have trouble definitely file a bug report and >> we'll take a look. >> >> -- Jonathan >> >> >> On 11/12/2012 9:19 a.m., Pedro Duque Vieira wrote: >> >> Hi, >> >> Need help styling context menu using CSS. First the CSS >> reference guide has >> nothing on this, second consulting caspian.css won't help >> because there's >> very little code for this class. >> >> What I'm struggling with right now is in defining an alternate >> look for the >> separator line (on the context menu), from what I've seen so >> far I can say >> that it is not consistent with the other separators because >> with the same >> lines of CSS I can't get it to have the same black colored >> solid look. >> >> Can someone give me some guidelines on this? >> >> Thanks in advance, :) >> >> >> >> >> >> -- >> Pedro Duque Vieira From hang.vo at oracle.com Tue Dec 11 00:04:18 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 11 Dec 2012 08:04:18 +0000 Subject: hg: openjfx/8/controls/rt: 7 new changesets Message-ID: <20121211080429.2291847041@hg.openjdk.java.net> Changeset: 8dc0b2132350 Author: jgiles Date: 2012-12-07 14:05 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8dc0b2132350 RT-26659: Rename impl_ treeItemCount property in TreeView and TreeTableView (it is now called expandedItemCount and is fully public API). ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! javafx-ui-controls/src/javafx/scene/control/TreeCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeItem.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableRow.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeUtil.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java Changeset: 076a80df7218 Author: jgiles Date: 2012-12-07 17:55 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/076a80df7218 RT-26787: TreeTableView: Key combinations with PgDn and PgUp throw an exception ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java Changeset: 322deaa43d9e Author: jgiles Date: 2012-12-11 09:47 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/322deaa43d9e RT-26656: All functionality that is available on Desktop should also be available on Embedded Touch ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java Changeset: 230b3d48a7a9 Author: jgiles Date: 2012-12-11 10:57 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/230b3d48a7a9 RT-26185: application freeze on focusing combobox (a.k.a RT-26802: Endless loop with multiple focus-traversable ComboBoxes) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 723b6b7fb579 Author: jgiles Date: 2012-12-11 12:06 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/723b6b7fb579 RT-24917: [TreeView] Editing is broken in 8.0 ! javafx-ui-controls/src/javafx/scene/control/ListCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeCell.java Changeset: 28782b36e141 Author: jgiles Date: 2012-12-11 20:52 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/28782b36e141 Fixing unit test to use latest TreeView API. ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: 28aeebda6a0b Author: jgiles Date: 2012-12-11 20:52 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/28aeebda6a0b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java From jerome.cambon at oracle.com Tue Dec 11 00:58:28 2012 From: jerome.cambon at oracle.com (Jerome Cambon) Date: Tue, 11 Dec 2012 09:58:28 +0100 Subject: Need help styling context menu In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D22160B0D773F@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <50C64850.3040703@oracle.com> <50C66F9F.1020807@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D22160B0D773F@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <50C6F5B4.90100@oracle.com> Alternatively you can try the new CSS Analyzer from Scene Builder 1.1. It shows all the CSS properties available for a selected node, with a link from each property on the JavaFX CSS Reference Guide . You can have an idea on how to use it from here . Jerome On 12/11/12 1:35 AM, John Smith wrote: > I think it would be beneficial to have something that visually shows the css classes of the elements which can be styled. > > See here for a sample from the ZK style guide on the kind of visual callout of style classes I am thinking of: > http://books.zkoss.org/wiki/ZK%20Style%20Guide/XUL%20Component%20Specification/Column/Default > http://books.zkoss.org/wiki/ZK_Style_Guide/XUL_Component_Specification/Colorbox/Default > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Jonathan Giles > Sent: Monday, December 10, 2012 3:26 PM > To: Pedro Duque Vieira > Cc: OpenJFX Mailing List > Subject: Re: Need help styling context menu > > Certainly we have a long way to go in improving our technical documentation. I will try to do a big push prior to 8.0 shipping to improve it as much as possible. > > -- Jonathan > > On 11/12/2012 12:24 p.m., Pedro Duque Vieira wrote: >> I've solved the issue with the separator. Sorry for bothering you, it >> was something I mistakenly overlooked. >> >> The issue that there is no documentation on styling Context Menu >> througth CSS still remains though, >> >> Thanks, best regards, >> >> On Mon, Dec 10, 2012 at 8:38 PM, Jonathan Giles >> > wrote: >> >> There are plenty of references to .separator in caspian.css - I >> wouldn't discount how useful referring to these would be. >> >> If you continue to have trouble definitely file a bug report and >> we'll take a look. >> >> -- Jonathan >> >> >> On 11/12/2012 9:19 a.m., Pedro Duque Vieira wrote: >> >> Hi, >> >> Need help styling context menu using CSS. First the CSS >> reference guide has >> nothing on this, second consulting caspian.css won't help >> because there's >> very little code for this class. >> >> What I'm struggling with right now is in defining an alternate >> look for the >> separator line (on the context menu), from what I've seen so >> far I can say >> that it is not consistent with the other separators because >> with the same >> lines of CSS I can't get it to have the same black colored >> solid look. >> >> Can someone give me some guidelines on this? >> >> Thanks in advance, :) >> >> >> >> >> >> -- >> Pedro Duque Vieira From randahl at rockit.dk Tue Dec 11 02:11:47 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Tue, 11 Dec 2012 11:11:47 +0100 Subject: Need help choosing a class name for CSS public API In-Reply-To: References: <6798E676-1F95-49A5-87F0-26E937F86D53@quartam.com> <050175C2-7B8A-4057-9F4C-D9798C8669EF@oracle.com> Message-ID: In that case, CssMetaData would be more readable. It is the old HTTPURL vs. HttpUrl readability issue. Randahl On Dec 11, 2012, at 5:51 , Gerrit Grunwald wrote: > +1 CSSMetaData > > Gerrit Grunwald > > Am 10.12.2012 um 22:03 schrieb Richard Bair : > >> We started off with StyleablePropertyMetaData -- but it is really long. CSSMetaData is certainly shorter. >> >> I'm not really a fan of "Glue", I get sticky fingers just thinking about it! :-) >> >> Richard >> >> On Dec 10, 2012, at 12:35 PM, Quartam - Jan Schenkel wrote: >> >>> How about CSSMetaData? >>> If it's not already used elsewhere, it would seem reasonably short and to-the-point. >>> >>> Jan. >>> >>> On 10 Dec 2012, at 19:18, David Grieve wrote: >>> >>>> In the CSS public API proposal (https://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls), I have a class name that is rather cumbersome and I'm trying to find another name. The class name in the proposal is StyleablePropertyMetaData and, to some extent, that is what the class is since this is where the node's property and the css property come together. The meta-data for Node's opacityProperty is shown below. As you can see, there is some information about the css property name (-fx-opacity), the type of value (a ) and the initial property value. There are also two methods that are used by CSS so that CSS can set the property value. >>>> >>>> So, I'm looking for a name for this thing thinking that there must be something better than StyleablePropertyMetaData. I was thinking StyleAgent since this class takes an active role in interacting with the node property. But "agent" has the connotation of something running in the background. Maybe StyleLiaison? >>>> >>>> private static final StyleablePropertyMetaData OPACITY = >>>> new StyleablePropertyMetaData ("-fx-opacity", >>>> SizeConverter.getInstance(), 1.0) { >>>> >>>> @Override >>>> public boolean isSettable(Node node) { >>>> return node.opacity == null || !node.opacity.isBound(); >>>> } >>>> >>>> @Override >>>> public WritableValue getWritableValue(Node node) { >>>> return node.opacityProperty(); >>>> } >>>> }; >>>> >>>> Does anyone have a suggestion? >> From pedro.duquevieira at gmail.com Tue Dec 11 03:14:14 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 11 Dec 2012 11:14:14 +0000 Subject: Need help styling context menu In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D22160B0D773F@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <50C64850.3040703@oracle.com> <50C66F9F.1020807@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D22160B0D773F@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: Thank you for that Jonathan! I think the CSS documentation can improve significantly, it hasn't got the quality of other documentation you can see on JavaFX. Thank you, best regards, On Tue, Dec 11, 2012 at 12:35 AM, John Smith wrote: > I think it would be beneficial to have something that visually shows the > css classes of the elements which can be styled. > > See here for a sample from the ZK style guide on the kind of visual > callout of style classes I am thinking of: > > http://books.zkoss.org/wiki/ZK%20Style%20Guide/XUL%20Component%20Specification/Column/Default > > http://books.zkoss.org/wiki/ZK_Style_Guide/XUL_Component_Specification/Colorbox/Default > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto: > openjfx-dev-bounces at openjdk.java.net] On Behalf Of Jonathan Giles > Sent: Monday, December 10, 2012 3:26 PM > To: Pedro Duque Vieira > Cc: OpenJFX Mailing List > Subject: Re: Need help styling context menu > > Certainly we have a long way to go in improving our technical > documentation. I will try to do a big push prior to 8.0 shipping to improve > it as much as possible. > > -- Jonathan > > On 11/12/2012 12:24 p.m., Pedro Duque Vieira wrote: > > I've solved the issue with the separator. Sorry for bothering you, it > > was something I mistakenly overlooked. > > > > The issue that there is no documentation on styling Context Menu > > througth CSS still remains though, > > > > Thanks, best regards, > > > > On Mon, Dec 10, 2012 at 8:38 PM, Jonathan Giles > > > wrote: > > > > There are plenty of references to .separator in caspian.css - I > > wouldn't discount how useful referring to these would be. > > > > If you continue to have trouble definitely file a bug report and > > we'll take a look. > > > > -- Jonathan > > > > > > On 11/12/2012 9:19 a.m., Pedro Duque Vieira wrote: > > > > Hi, > > > > Need help styling context menu using CSS. First the CSS > > reference guide has > > nothing on this, second consulting caspian.css won't help > > because there's > > very little code for this class. > > > > What I'm struggling with right now is in defining an alternate > > look for the > > separator line (on the context menu), from what I've seen so > > far I can say > > that it is not consistent with the other separators because > > with the same > > lines of CSS I can't get it to have the same black colored > > solid look. > > > > Can someone give me some guidelines on this? > > > > Thanks in advance, :) > > > > > > > > > > > > -- > > Pedro Duque Vieira > > -- Pedro Duque Vieira From lehmann at media-interactive.de Tue Dec 11 03:19:52 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Tue, 11 Dec 2012 12:19:52 +0100 Subject: Need help styling context menu In-Reply-To: References: Message-ID: <50C716D8.7020103@media-interactive.de> While we're at it, is it still necessary to do the following to get a contextmenu styled? contextmenu.getScene().getRoot().getStylesheets().addAll(...mystylesheet...); It's not very obvious and there's always extra code required when defining a contextmenu in FXML. Werner On 10.12.2012 21:19, Pedro Duque Vieira wrote: > Hi, > > Need help styling context menu using CSS. First the CSS reference guide has > nothing on this, second consulting caspian.css won't help because there's > very little code for this class. > > What I'm struggling with right now is in defining an alternate look for the > separator line (on the context menu), from what I've seen so far I can say > that it is not consistent with the other separators because with the same > lines of CSS I can't get it to have the same black colored solid look. > > Can someone give me some guidelines on this? > > Thanks in advance, :) From james.weaver at oracle.com Tue Dec 11 04:49:26 2012 From: james.weaver at oracle.com (Jim Weaver) Date: Tue, 11 Dec 2012 07:49:26 -0500 Subject: Need help choosing a class name for CSS public API In-Reply-To: References: <6798E676-1F95-49A5-87F0-26E937F86D53@quartam.com> <050175C2-7B8A-4057-9F4C-D9798C8669EF@oracle.com> Message-ID: <50C72BD6.7000007@oracle.com> +1 CSSMetaData On 12/11/12 5:11 AM, Randahl Fink Isaksen wrote: > In that case, CssMetaData would be more readable. It is the old HTTPURL vs. HttpUrl readability issue. > > Randahl > > On Dec 11, 2012, at 5:51 , Gerrit Grunwald wrote: > >> +1 CSSMetaData >> >> Gerrit Grunwald >> >> Am 10.12.2012 um 22:03 schrieb Richard Bair : >> >>> We started off with StyleablePropertyMetaData -- but it is really long. CSSMetaData is certainly shorter. >>> >>> I'm not really a fan of "Glue", I get sticky fingers just thinking about it! :-) >>> >>> Richard >>> >>> On Dec 10, 2012, at 12:35 PM, Quartam - Jan Schenkel wrote: >>> >>>> How about CSSMetaData? >>>> If it's not already used elsewhere, it would seem reasonably short and to-the-point. >>>> >>>> Jan. >>>> >>>> On 10 Dec 2012, at 19:18, David Grieve wrote: >>>> >>>>> In the CSS public API proposal (https://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls), I have a class name that is rather cumbersome and I'm trying to find another name. The class name in the proposal is StyleablePropertyMetaData and, to some extent, that is what the class is since this is where the node's property and the css property come together. The meta-data for Node's opacityProperty is shown below. As you can see, there is some information about the css property name (-fx-opacity), the type of value (a ) and the initial property value. There are also two methods that are used by CSS so that CSS can set the property value. >>>>> >>>>> So, I'm looking for a name for this thing thinking that there must be something better than StyleablePropertyMetaData. I was thinking StyleAgent since this class takes an active role in interacting with the node property. But "agent" has the connotation of something running in the background. Maybe StyleLiaison? >>>>> >>>>> private static final StyleablePropertyMetaData OPACITY = >>>>> new StyleablePropertyMetaData ("-fx-opacity", >>>>> SizeConverter.getInstance(), 1.0) { >>>>> >>>>> @Override >>>>> public boolean isSettable(Node node) { >>>>> return node.opacity == null || !node.opacity.isBound(); >>>>> } >>>>> >>>>> @Override >>>>> public WritableValue getWritableValue(Node node) { >>>>> return node.opacityProperty(); >>>>> } >>>>> }; >>>>> >>>>> Does anyone have a suggestion? -- Regards, Jim Weaver Java Technology Ambassador Oracle Corporation james.weaver at oracle.com From sven.reimers at gmail.com Tue Dec 11 05:58:13 2012 From: sven.reimers at gmail.com (Sven Reimers) Date: Tue, 11 Dec 2012 14:58:13 +0100 Subject: Need help choosing a class name for CSS public API In-Reply-To: References: <6798E676-1F95-49A5-87F0-26E937F86D53@quartam.com> <050175C2-7B8A-4057-9F4C-D9798C8669EF@oracle.com> Message-ID: +1 CSSMetaData (or CssMetaData) Sven On Tue, Dec 11, 2012 at 5:51 AM, Gerrit Grunwald wrote: > +1 CSSMetaData > > Gerrit Grunwald > > Am 10.12.2012 um 22:03 schrieb Richard Bair : > > > We started off with StyleablePropertyMetaData -- but it is really long. > CSSMetaData is certainly shorter. > > > > I'm not really a fan of "Glue", I get sticky fingers just thinking about > it! :-) > > > > Richard > > > > On Dec 10, 2012, at 12:35 PM, Quartam - Jan Schenkel < > jan.schenkel at quartam.com> wrote: > > > >> How about CSSMetaData? > >> If it's not already used elsewhere, it would seem reasonably short and > to-the-point. > >> > >> Jan. > >> > >> On 10 Dec 2012, at 19:18, David Grieve wrote: > >> > >>> In the CSS public API proposal ( > https://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls), > I have a class name that is rather cumbersome and I'm trying to find > another name. The class name in the proposal is StyleablePropertyMetaData > and, to some extent, that is what the class is since this is where the > node's property and the css property come together. The meta-data for > Node's opacityProperty is shown below. As you can see, there is some > information about the css property name (-fx-opacity), the type of value (a > ) and the initial property value. There are also two methods that are > used by CSS so that CSS can set the property value. > >>> > >>> So, I'm looking for a name for this thing thinking that there must be > something better than StyleablePropertyMetaData. I was thinking StyleAgent > since this class takes an active role in interacting with the node > property. But "agent" has the connotation of something running in the > background. Maybe StyleLiaison? > >>> > >>> private static final StyleablePropertyMetaData > OPACITY = > >>> new StyleablePropertyMetaData ("-fx-opacity", > >>> SizeConverter.getInstance(), 1.0) { > >>> > >>> @Override > >>> public boolean isSettable(Node node) { > >>> return node.opacity == null || > !node.opacity.isBound(); > >>> } > >>> > >>> @Override > >>> public WritableValue getWritableValue(Node node) { > >>> return node.opacityProperty(); > >>> } > >>> }; > >>> > >>> Does anyone have a suggestion? > > > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From david.grieve at oracle.com Tue Dec 11 06:48:58 2012 From: david.grieve at oracle.com (David Grieve) Date: Tue, 11 Dec 2012 09:48:58 -0500 Subject: Need help styling context menu In-Reply-To: References: <50C64850.3040703@oracle.com> <50C66F9F.1020807@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D22160B0D773F@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: <976F7C94-A629-49D4-BE11-6362FEEACAA5@oracle.com> I created http://javafx-jira.kenai.com/browse/RT-26878 to track the lack of documentation for styling context menu. On Dec 11, 2012, at 6:14 AM, Pedro Duque Vieira wrote: > Thank you for that Jonathan! I think the CSS documentation can improve > significantly, it hasn't got the quality of other documentation you can see > on JavaFX. > > Thank you, best regards, > > On Tue, Dec 11, 2012 at 12:35 AM, John Smith wrote: > >> I think it would be beneficial to have something that visually shows the >> css classes of the elements which can be styled. >> >> See here for a sample from the ZK style guide on the kind of visual >> callout of style classes I am thinking of: >> >> http://books.zkoss.org/wiki/ZK%20Style%20Guide/XUL%20Component%20Specification/Column/Default >> >> http://books.zkoss.org/wiki/ZK_Style_Guide/XUL_Component_Specification/Colorbox/Default >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net [mailto: >> openjfx-dev-bounces at openjdk.java.net] On Behalf Of Jonathan Giles >> Sent: Monday, December 10, 2012 3:26 PM >> To: Pedro Duque Vieira >> Cc: OpenJFX Mailing List >> Subject: Re: Need help styling context menu >> >> Certainly we have a long way to go in improving our technical >> documentation. I will try to do a big push prior to 8.0 shipping to improve >> it as much as possible. >> >> -- Jonathan >> >> On 11/12/2012 12:24 p.m., Pedro Duque Vieira wrote: >>> I've solved the issue with the separator. Sorry for bothering you, it >>> was something I mistakenly overlooked. >>> >>> The issue that there is no documentation on styling Context Menu >>> througth CSS still remains though, >>> >>> Thanks, best regards, >>> >>> On Mon, Dec 10, 2012 at 8:38 PM, Jonathan Giles >>> > wrote: >>> >>> There are plenty of references to .separator in caspian.css - I >>> wouldn't discount how useful referring to these would be. >>> >>> If you continue to have trouble definitely file a bug report and >>> we'll take a look. >>> >>> -- Jonathan >>> >>> >>> On 11/12/2012 9:19 a.m., Pedro Duque Vieira wrote: >>> >>> Hi, >>> >>> Need help styling context menu using CSS. First the CSS >>> reference guide has >>> nothing on this, second consulting caspian.css won't help >>> because there's >>> very little code for this class. >>> >>> What I'm struggling with right now is in defining an alternate >>> look for the >>> separator line (on the context menu), from what I've seen so >>> far I can say >>> that it is not consistent with the other separators because >>> with the same >>> lines of CSS I can't get it to have the same black colored >>> solid look. >>> >>> Can someone give me some guidelines on this? >>> >>> Thanks in advance, :) >>> >>> >>> >>> >>> >>> -- >>> Pedro Duque Vieira >> >> > > > -- > Pedro Duque Vieira From hang.vo at oracle.com Tue Dec 11 06:48:55 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 11 Dec 2012 14:48:55 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121211144901.21A254705A@hg.openjdk.java.net> Changeset: 6ad8578c9044 Author: Milan Kubec Date: 2012-12-11 15:39 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6ad8578c9044 additional asserts; patch applied in behalf of QA ! javafx-fxml/src/javafx/fxml/doc-files/introduction_to_fxml.html Changeset: d42c1ae9369a Author: Milan Kubec Date: 2012-12-11 14:40 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d42c1ae9369a Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx////rt From david.grieve at oracle.com Tue Dec 11 06:52:15 2012 From: david.grieve at oracle.com (David Grieve) Date: Tue, 11 Dec 2012 09:52:15 -0500 Subject: Need help styling context menu In-Reply-To: <50C716D8.7020103@media-interactive.de> References: <50C716D8.7020103@media-interactive.de> Message-ID: <43B7D72C-DAA9-45BF-B40E-37A97A2D0104@oracle.com> http://javafx-jira.kenai.com/browse/RT-19435 deals with popups not getting stylesheets from a Parent. This may or may not be the same issue you mention here. It would be helpful if you could add your comments to RT-19435, if that is the appropriate bug, or you can create a new bug. On Dec 11, 2012, at 6:19 AM, Werner Lehmann wrote: > While we're at it, is it still necessary to do the following to get a contextmenu styled? > > contextmenu.getScene().getRoot().getStylesheets().addAll(...mystylesheet...); > > It's not very obvious and there's always extra code required when defining a contextmenu in FXML. > > Werner > > On 10.12.2012 21:19, Pedro Duque Vieira wrote: >> Hi, >> >> Need help styling context menu using CSS. First the CSS reference guide has >> nothing on this, second consulting caspian.css won't help because there's >> very little code for this class. >> >> What I'm struggling with right now is in defining an alternate look for the >> separator line (on the context menu), from what I've seen so far I can say >> that it is not consistent with the other separators because with the same >> lines of CSS I can't get it to have the same black colored solid look. >> >> Can someone give me some guidelines on this? >> >> Thanks in advance, :) From hendrik.ebbers at me.com Tue Dec 11 07:00:33 2012 From: hendrik.ebbers at me.com (Hendrik Ebbers) Date: Tue, 11 Dec 2012 15:00:33 +0000 (GMT) Subject: Need help choosing a class name for CSS public API In-Reply-To: Message-ID: +1 CSSMetaData Am 11. Dezember 2012 um 14:58 schrieb Sven Reimers : +1 CSSMetaData (or CssMetaData) Sven On Tue, Dec 11, 2012 at 5:51 AM, Gerrit Grunwald wrote: > +1 CSSMetaData > > Gerrit Grunwald > > Am 10.12.2012 um 22:03 schrieb Richard Bair : > > > We started off with StyleablePropertyMetaData -- but it is really long. > CSSMetaData is certainly shorter. > > > > I'm not really a fan of "Glue", I get sticky fingers just thinking about > it! :-) > > > > Richard > > > > On Dec 10, 2012, at 12:35 PM, Quartam - Jan Schenkel < > jan.schenkel at quartam.com> wrote: > > > >> How about CSSMetaData? > >> If it's not already used elsewhere, it would seem reasonably short and > to-the-point. > >> > >> Jan. > >> > >> On 10 Dec 2012, at 19:18, David Grieve wrote: > >> > >>> In the CSS public API proposal ( > https://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls), > I have a class name that is rather cumbersome and I'm trying to find > another name. The class name in the proposal is StyleablePropertyMetaData > and, to some extent, that is what the class is since this is where the > node's property and the css property come together. The meta-data for > Node's opacityProperty is shown below. As you can see, there is some > information about the css property name (-fx-opacity), the type of value (a > ) and the initial property value. There are also two methods that are > used by CSS so that CSS can set the property value. > >>> > >>> So, I'm looking for a name for this thing thinking that there must be > something better than StyleablePropertyMetaData. I was thinking StyleAgent > since this class takes an active role in interacting with the node > property. But "agent" has the connotation of something running in the > background. Maybe StyleLiaison? > >>> > >>> private static final StyleablePropertyMetaData > OPACITY = > >>> new StyleablePropertyMetaData ("-fx-opacity", > >>> SizeConverter.getInstance(), 1.0) { > >>> > >>> @Override > >>> public boolean isSettable(Node node) { > >>> return node.opacity == null || > !node.opacity.isBound(); > >>> } > >>> > >>> @Override > >>> public WritableValue getWritableValue(Node node) { > >>> return node.opacityProperty(); > >>> } > >>> }; > >>> > >>> Does anyone have a suggestion? > > > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From david.grieve at oracle.com Tue Dec 11 07:07:13 2012 From: david.grieve at oracle.com (David Grieve) Date: Tue, 11 Dec 2012 10:07:13 -0500 Subject: Need help choosing a class name for CSS public API In-Reply-To: References: Message-ID: <75135EF4-A45D-4B6D-AA12-130D61C11FDB@oracle.com> CssMetaData it is. Thanks, everyone, for your input. On Dec 11, 2012, at 10:00 AM, Hendrik Ebbers wrote: > +1 CSSMetaData > > Am 11. Dezember 2012 um 14:58 schrieb Sven Reimers : > > +1 CSSMetaData (or CssMetaData) > > > Sven > > > On Tue, Dec 11, 2012 at 5:51 AM, Gerrit Grunwald wrote: > >> +1 CSSMetaData >> >> Gerrit Grunwald >> >> Am 10.12.2012 um 22:03 schrieb Richard Bair : >> >> > We started off with StyleablePropertyMetaData -- but it is really long. >> CSSMetaData is certainly shorter. >> > >> > I'm not really a fan of "Glue", I get sticky fingers just thinking about >> it! :-) >> > >> > Richard >> > >> > On Dec 10, 2012, at 12:35 PM, Quartam - Jan Schenkel < >> jan.schenkel at quartam.com> wrote: >> > >> >> How about CSSMetaData? >> >> If it's not already used elsewhere, it would seem reasonably short and >> to-the-point. >> >> >> >> Jan. >> >> >> >> On 10 Dec 2012, at 19:18, David Grieve wrote: >> >> >> >>> In the CSS public API proposal ( >> https://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls), >> I have a class name that is rather cumbersome and I'm trying to find >> another name. The class name in the proposal is StyleablePropertyMetaData >> and, to some extent, that is what the class is since this is where the >> node's property and the css property come together. The meta-data for >> Node's opacityProperty is shown below. As you can see, there is some >> information about the css property name (-fx-opacity), the type of value (a >> ) and the initial property value. There are also two methods that are >> used by CSS so that CSS can set the property value. >> >>> >> >>> So, I'm looking for a name for this thing thinking that there must be >> something better than StyleablePropertyMetaData. I was thinking StyleAgent >> since this class takes an active role in interacting with the node >> property. But "agent" has the connotation of something running in the >> background. Maybe StyleLiaison? >> >>> >> >>> private static final StyleablePropertyMetaData >> OPACITY = >> >>> new StyleablePropertyMetaData ("-fx-opacity", >> >>> SizeConverter.getInstance(), 1.0) { >> >>> >> >>> @Override >> >>> public boolean isSettable(Node node) { >> >>> return node.opacity == null || >> !node.opacity.isBound(); >> >>> } >> >>> >> >>> @Override >> >>> public WritableValue getWritableValue(Node node) { >> >>> return node.opacityProperty(); >> >>> } >> >>> }; >> >>> >> >>> Does anyone have a suggestion? >> > >> > > > > -- > Sven Reimers > > * Senior Expert Software Architect > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * NetBeans Governance Board Member: > http://netbeans.org/about/os/governance.html > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * Duke's Choice Award Winner 2009 > * Blog: http://nbguru.blogspot.com > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 From lehmann at media-interactive.de Tue Dec 11 07:15:43 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Tue, 11 Dec 2012 16:15:43 +0100 Subject: Need help styling context menu In-Reply-To: <43B7D72C-DAA9-45BF-B40E-37A97A2D0104@oracle.com> References: <50C716D8.7020103@media-interactive.de> <43B7D72C-DAA9-45BF-B40E-37A97A2D0104@oracle.com> Message-ID: <50C74E1F.2070507@media-interactive.de> Hi David, same bug I would say. For ContextMenu I commented a workaround on that ticket which should help people using the contextmenu via FXML on 2.2. Rgds Werner On 11.12.2012 15:52, David Grieve wrote: > http://javafx-jira.kenai.com/browse/RT-19435 deals with popups not > getting stylesheets from a Parent. This may or may not be the same > issue you mention here. It would be helpful if you could add your > comments to RT-19435, if that is the appropriate bug, or you can > create a new bug. From mark.heckler at oracle.com Tue Dec 11 07:18:37 2012 From: mark.heckler at oracle.com (Mark Heckler) Date: Tue, 11 Dec 2012 07:18:37 -0800 (PST) Subject: Need help choosing a class name for CSS public API In-Reply-To: References: Message-ID: +1 on CSSMetaData as well. Thanks, Mark -----Original Message----- From: Hendrik Ebbers [mailto:hendrik.ebbers at me.com] Sent: Tuesday, December 11, 2012 9:01 AM To: Sven Reimers Cc: openjfx-dev at openjdk.java.net openjfx-dev at openjdk.java.net Subject: Re: Need help choosing a class name for CSS public API +1 CSSMetaData Am 11. Dezember 2012 um 14:58 schrieb Sven Reimers : +1 CSSMetaData (or CssMetaData) Sven On Tue, Dec 11, 2012 at 5:51 AM, Gerrit Grunwald wrote: > +1 CSSMetaData > > Gerrit Grunwald > > Am 10.12.2012 um 22:03 schrieb Richard Bair : > > > We started off with StyleablePropertyMetaData -- but it is really long. > CSSMetaData is certainly shorter. > > > > I'm not really a fan of "Glue", I get sticky fingers just thinking > > about > it! :-) > > > > Richard > > > > On Dec 10, 2012, at 12:35 PM, Quartam - Jan Schenkel < > jan.schenkel at quartam.com> wrote: > > > >> How about CSSMetaData? > >> If it's not already used elsewhere, it would seem reasonably short > >> and > to-the-point. > >> > >> Jan. > >> > >> On 10 Dec 2012, at 19:18, David Grieve wrote: > >> > >>> In the CSS public API proposal ( > https://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+ > Controls), I have a class name that is rather cumbersome and I'm > trying to find another name. The class name in the proposal is > StyleablePropertyMetaData and, to some extent, that is what the class > is since this is where the node's property and the css property come > together. The meta-data for Node's opacityProperty is shown below. As > you can see, there is some information about the css property name > (-fx-opacity), the type of value (a > ) and the initial property value. There are also two methods > that are used by CSS so that CSS can set the property value. > >>> > >>> So, I'm looking for a name for this thing thinking that there must > >>> be > something better than StyleablePropertyMetaData. I was thinking > StyleAgent since this class takes an active role in interacting with > the node property. But "agent" has the connotation of something > running in the background. Maybe StyleLiaison? > >>> > >>> private static final StyleablePropertyMetaData > OPACITY = > >>> new StyleablePropertyMetaData ("-fx-opacity", > >>> SizeConverter.getInstance(), 1.0) { > >>> > >>> @Override > >>> public boolean isSettable(Node node) { return node.opacity == null > >>> || > !node.opacity.isBound(); > >>> } > >>> > >>> @Override > >>> public WritableValue getWritableValue(Node node) { return > >>> node.opacityProperty(); } }; > >>> > >>> Does anyone have a suggestion? > > > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From pedro.duquevieira at gmail.com Tue Dec 11 08:43:42 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 11 Dec 2012 16:43:42 +0000 Subject: Need help styling context menu In-Reply-To: <976F7C94-A629-49D4-BE11-6362FEEACAA5@oracle.com> References: <50C64850.3040703@oracle.com> <50C66F9F.1020807@oracle.com> <411E73D23DEC4C46BA48F2B6D8BF3D22160B0D773F@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <976F7C94-A629-49D4-BE11-6362FEEACAA5@oracle.com> Message-ID: Thanks for your help David, I was about to do it but you beat me to it. :) Best regards, On Tue, Dec 11, 2012 at 2:48 PM, David Grieve wrote: > I created http://javafx-jira.kenai.com/browse/RT-26878 to track the lack > of documentation for styling context menu. > > On Dec 11, 2012, at 6:14 AM, Pedro Duque Vieira < > pedro.duquevieira at gmail.com> wrote: > > > Thank you for that Jonathan! I think the CSS documentation can improve > > significantly, it hasn't got the quality of other documentation you can > see > > on JavaFX. > > > > Thank you, best regards, > > > > On Tue, Dec 11, 2012 at 12:35 AM, John Smith >wrote: > > > >> I think it would be beneficial to have something that visually shows the > >> css classes of the elements which can be styled. > >> > >> See here for a sample from the ZK style guide on the kind of visual > >> callout of style classes I am thinking of: > >> > >> > http://books.zkoss.org/wiki/ZK%20Style%20Guide/XUL%20Component%20Specification/Column/Default > >> > >> > http://books.zkoss.org/wiki/ZK_Style_Guide/XUL_Component_Specification/Colorbox/Default > >> > >> -----Original Message----- > >> From: openjfx-dev-bounces at openjdk.java.net [mailto: > >> openjfx-dev-bounces at openjdk.java.net] On Behalf Of Jonathan Giles > >> Sent: Monday, December 10, 2012 3:26 PM > >> To: Pedro Duque Vieira > >> Cc: OpenJFX Mailing List > >> Subject: Re: Need help styling context menu > >> > >> Certainly we have a long way to go in improving our technical > >> documentation. I will try to do a big push prior to 8.0 shipping to > improve > >> it as much as possible. > >> > >> -- Jonathan > >> > >> On 11/12/2012 12:24 p.m., Pedro Duque Vieira wrote: > >>> I've solved the issue with the separator. Sorry for bothering you, it > >>> was something I mistakenly overlooked. > >>> > >>> The issue that there is no documentation on styling Context Menu > >>> througth CSS still remains though, > >>> > >>> Thanks, best regards, > >>> > >>> On Mon, Dec 10, 2012 at 8:38 PM, Jonathan Giles > >>> > wrote: > >>> > >>> There are plenty of references to .separator in caspian.css - I > >>> wouldn't discount how useful referring to these would be. > >>> > >>> If you continue to have trouble definitely file a bug report and > >>> we'll take a look. > >>> > >>> -- Jonathan > >>> > >>> > >>> On 11/12/2012 9:19 a.m., Pedro Duque Vieira wrote: > >>> > >>> Hi, > >>> > >>> Need help styling context menu using CSS. First the CSS > >>> reference guide has > >>> nothing on this, second consulting caspian.css won't help > >>> because there's > >>> very little code for this class. > >>> > >>> What I'm struggling with right now is in defining an alternate > >>> look for the > >>> separator line (on the context menu), from what I've seen so > >>> far I can say > >>> that it is not consistent with the other separators because > >>> with the same > >>> lines of CSS I can't get it to have the same black colored > >>> solid look. > >>> > >>> Can someone give me some guidelines on this? > >>> > >>> Thanks in advance, :) > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Pedro Duque Vieira > >> > >> > > > > > > -- > > Pedro Duque Vieira > > -- Pedro Duque Vieira From hang.vo at oracle.com Tue Dec 11 08:48:30 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 11 Dec 2012 16:48:30 +0000 Subject: hg: openjfx/8/controls/rt: 28 new changesets Message-ID: <20121211164907.0139C47069@hg.openjdk.java.net> Changeset: 12cce04e7847 Author: hudson Date: 2012-11-29 22:12 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/12cce04e7847 Added tag 8.0-b66 ! .hgtags Changeset: 54d464a6ade7 Author: Felipe Heidrich Date: 2012-11-27 15:31 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/54d464a6ade7 RT-23492: Text method(s) accept null, app blows up later ! javafx-ui-common/src/javafx/scene/text/Text.java Changeset: 573f5535e6a1 Author: Martin Sladecek Date: 2012-11-28 10:18 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/573f5535e6a1 RT-25776 Animation. Cycles are not equivalent in SequentialTransition ! javafx-ui-common/src/javafx/animation/ParallelTransition.java ! javafx-ui-common/src/javafx/animation/SequentialTransition.java ! javafx-ui-common/src/javafx/animation/Transition.java ! javafx-ui-common/test/unit/javafx/animation/TransitionTest.java Changeset: fc5cf98c8d33 Author: Martin Sladecek Date: 2012-11-28 10:19 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fc5cf98c8d33 merge Changeset: 3a6dcc5adb79 Author: Martin Sladecek Date: 2012-11-28 12:41 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3a6dcc5adb79 Fixed test failure ! javafx-ui-common/test/unit/javafx/animation/AnimationMock.java Changeset: b2e8a63feae9 Author: Martin Sladecek Date: 2012-11-28 12:41 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b2e8a63feae9 merge Changeset: 42c3818c5c85 Author: Milan Kubec Date: 2012-11-28 15:23 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/42c3818c5c85 adding QA related assertions to documentation ! javafx-fxml/src/javafx/fxml/doc-files/introduction_to_fxml.html Changeset: ef5f81064000 Author: Felipe Heidrich Date: 2012-11-28 16:51 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ef5f81064000 RT-26171: Add RTL support to Text node ! javafx-ui-common/src/com/sun/javafx/scene/text/TextLayout.java ! javafx-ui-common/src/javafx/scene/text/Text.java Changeset: 26d62927eb5b Author: Martin Sladecek Date: 2012-11-29 10:18 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/26d62927eb5b RT-26517, RT-26544 SequentialTransition and ParallelTransition fixes. ! javafx-ui-common/src/javafx/animation/ParallelTransition.java ! javafx-ui-common/src/javafx/animation/SequentialTransition.java Changeset: 535735e49872 Author: Martin Sladecek Date: 2012-11-29 10:18 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/535735e49872 merge Changeset: 5ad236b5f3ed Author: tb115823 Date: 2012-11-29 09:42 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5ad236b5f3ed Changed names of tests to enable junit test runner to pick them - javafx-fxml/test/javafx/fxml/RT_14880.java + javafx-fxml/test/javafx/fxml/RT_14880Test.java - javafx-fxml/test/javafx/fxml/RT_15524.java + javafx-fxml/test/javafx/fxml/RT_15524Test.java - javafx-fxml/test/javafx/fxml/RT_16722.java + javafx-fxml/test/javafx/fxml/RT_16722Test.java - javafx-fxml/test/javafx/fxml/RT_16724.java + javafx-fxml/test/javafx/fxml/RT_16724Test.java - javafx-fxml/test/javafx/fxml/RT_16815.java + javafx-fxml/test/javafx/fxml/RT_16815Test.java - javafx-fxml/test/javafx/fxml/RT_16977.java + javafx-fxml/test/javafx/fxml/RT_16977Test.java - javafx-fxml/test/javafx/fxml/RT_17646.java + javafx-fxml/test/javafx/fxml/RT_17646Test.java - javafx-fxml/test/javafx/fxml/RT_17714.java + javafx-fxml/test/javafx/fxml/RT_17714Test.java - javafx-fxml/test/javafx/fxml/RT_18046.java + javafx-fxml/test/javafx/fxml/RT_18046Test.java - javafx-fxml/test/javafx/fxml/RT_18218.java + javafx-fxml/test/javafx/fxml/RT_18218Test.java - javafx-fxml/test/javafx/fxml/RT_18680.java + javafx-fxml/test/javafx/fxml/RT_18680Test.java - javafx-fxml/test/javafx/fxml/RT_18933.java + javafx-fxml/test/javafx/fxml/RT_18933Test.java - javafx-fxml/test/javafx/fxml/RT_19008.java + javafx-fxml/test/javafx/fxml/RT_19008Test.java - javafx-fxml/test/javafx/fxml/RT_19112.java + javafx-fxml/test/javafx/fxml/RT_19112Test.java - javafx-fxml/test/javafx/fxml/RT_19139.java + javafx-fxml/test/javafx/fxml/RT_19139Test.java - javafx-fxml/test/javafx/fxml/RT_19228.java + javafx-fxml/test/javafx/fxml/RT_19228Test.java - javafx-fxml/test/javafx/fxml/RT_19329.java + javafx-fxml/test/javafx/fxml/RT_19329Test.java - javafx-fxml/test/javafx/fxml/RT_19870.java + javafx-fxml/test/javafx/fxml/RT_19870Test.java - javafx-fxml/test/javafx/fxml/RT_20082.java + javafx-fxml/test/javafx/fxml/RT_20082Test.java - javafx-fxml/test/javafx/fxml/RT_20471.java + javafx-fxml/test/javafx/fxml/RT_20471Test.java - javafx-fxml/test/javafx/fxml/RT_21559.java + javafx-fxml/test/javafx/fxml/RT_21559Test.java - javafx-fxml/test/javafx/fxml/RT_22864.java + javafx-fxml/test/javafx/fxml/RT_22864Test.java - javafx-fxml/test/javafx/fxml/RT_22971.java + javafx-fxml/test/javafx/fxml/RT_22971Test.java - javafx-fxml/test/javafx/fxml/RT_23244.java + javafx-fxml/test/javafx/fxml/RT_23244Test.java - javafx-fxml/test/javafx/fxml/RT_23413.java + javafx-fxml/test/javafx/fxml/RT_23413Test.java - javafx-fxml/test/javafx/fxml/RT_24380.java + javafx-fxml/test/javafx/fxml/RT_24380Test.java Changeset: 812543070c61 Author: tb115823 Date: 2012-11-29 10:09 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/812543070c61 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt - javafx-fxml/test/javafx/fxml/RT_14880.java - javafx-fxml/test/javafx/fxml/RT_15524.java - javafx-fxml/test/javafx/fxml/RT_16722.java - javafx-fxml/test/javafx/fxml/RT_16724.java - javafx-fxml/test/javafx/fxml/RT_16815.java - javafx-fxml/test/javafx/fxml/RT_16977.java - javafx-fxml/test/javafx/fxml/RT_17646.java - javafx-fxml/test/javafx/fxml/RT_17714.java - javafx-fxml/test/javafx/fxml/RT_18046.java - javafx-fxml/test/javafx/fxml/RT_18218.java - javafx-fxml/test/javafx/fxml/RT_18680.java - javafx-fxml/test/javafx/fxml/RT_18933.java - javafx-fxml/test/javafx/fxml/RT_19008.java - javafx-fxml/test/javafx/fxml/RT_19112.java - javafx-fxml/test/javafx/fxml/RT_19139.java - javafx-fxml/test/javafx/fxml/RT_19228.java - javafx-fxml/test/javafx/fxml/RT_19329.java - javafx-fxml/test/javafx/fxml/RT_19870.java - javafx-fxml/test/javafx/fxml/RT_20082.java - javafx-fxml/test/javafx/fxml/RT_20471.java - javafx-fxml/test/javafx/fxml/RT_21559.java - javafx-fxml/test/javafx/fxml/RT_22864.java - javafx-fxml/test/javafx/fxml/RT_22971.java - javafx-fxml/test/javafx/fxml/RT_23244.java - javafx-fxml/test/javafx/fxml/RT_23413.java - javafx-fxml/test/javafx/fxml/RT_24380.java Changeset: 99e8153aadac Author: tb115823 Date: 2012-11-29 12:27 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/99e8153aadac Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt - javafx-fxml/test/javafx/fxml/RT_14880.java - javafx-fxml/test/javafx/fxml/RT_15524.java - javafx-fxml/test/javafx/fxml/RT_16722.java - javafx-fxml/test/javafx/fxml/RT_16724.java - javafx-fxml/test/javafx/fxml/RT_16815.java - javafx-fxml/test/javafx/fxml/RT_16977.java - javafx-fxml/test/javafx/fxml/RT_17646.java - javafx-fxml/test/javafx/fxml/RT_17714.java - javafx-fxml/test/javafx/fxml/RT_18046.java - javafx-fxml/test/javafx/fxml/RT_18218.java - javafx-fxml/test/javafx/fxml/RT_18680.java - javafx-fxml/test/javafx/fxml/RT_18933.java - javafx-fxml/test/javafx/fxml/RT_19008.java - javafx-fxml/test/javafx/fxml/RT_19112.java - javafx-fxml/test/javafx/fxml/RT_19139.java - javafx-fxml/test/javafx/fxml/RT_19228.java - javafx-fxml/test/javafx/fxml/RT_19329.java - javafx-fxml/test/javafx/fxml/RT_19870.java - javafx-fxml/test/javafx/fxml/RT_20082.java - javafx-fxml/test/javafx/fxml/RT_20471.java - javafx-fxml/test/javafx/fxml/RT_21559.java - javafx-fxml/test/javafx/fxml/RT_22864.java - javafx-fxml/test/javafx/fxml/RT_22971.java - javafx-fxml/test/javafx/fxml/RT_23244.java - javafx-fxml/test/javafx/fxml/RT_23413.java - javafx-fxml/test/javafx/fxml/RT_24380.java Changeset: f41875afbcf6 Author: Felipe Heidrich Date: 2012-11-29 08:45 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f41875afbcf6 RT-26171- adding missing override tag ! javafx-ui-common/src/javafx/scene/text/Text.java Changeset: fcce9e4370aa Author: Felipe Heidrich Date: 2012-11-29 19:57 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fcce9e4370aa RT-26590: Text unit test failure after adding RTL support ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextLayout.java Changeset: 005267bc4e2e Author: rbair Date: 2012-11-30 13:25 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/005267bc4e2e Fix for RT-25973: BorderConverter should not be public API ! javafx-ui-common/src/javafx/scene/layout/BorderConverter.java Changeset: 204b00c41d61 Author: rbair Date: 2012-11-30 15:23 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/204b00c41d61 Removed unused property that was added in 8.0 erroneously. Fix for RT-25937 ! javafx-ui-common/src/javafx/scene/layout/Region.java Changeset: ad9bea38bfbe Author: tb115823 Date: 2012-12-03 09:53 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ad9bea38bfbe fix build failure. Reference to nonexisting classes after rename of test classes ! javafx-fxml/test/javafx/fxml/RT_22971Controller.java ! javafx-fxml/test/javafx/fxml/RT_23413Test.java Changeset: 8e88ab8b8bcc Author: tb115823 Date: 2012-12-03 09:55 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8e88ab8b8bcc Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx//rt Changeset: 1a0cf70decaf Author: Seeon Birger Date: 2012-11-26 20:01 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1a0cf70decaf RT-26478: Restored call to fxvk.setPrefWidth(VK_WIDTH) that was removed by a fix to RT-25181. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java Changeset: 496c1bca757f Author: David Hill Date: 2012-11-28 13:40 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/496c1bca757f Automated merge with ssh://javafxsrc.us.oracle.com//javafx/8.0/scrum//graphics/jfx/rt Changeset: fa1ad3d3186a Author: David Hill Date: 2012-12-03 10:53 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fa1ad3d3186a Automated merge with ssh://javafxsrc.us.oracle.com//javafx/8.0/scrum//embedded/jfx/rt - javafx-fxml/test/javafx/fxml/RT_14880.java - javafx-fxml/test/javafx/fxml/RT_15524.java - javafx-fxml/test/javafx/fxml/RT_16722.java - javafx-fxml/test/javafx/fxml/RT_16724.java - javafx-fxml/test/javafx/fxml/RT_16815.java - javafx-fxml/test/javafx/fxml/RT_16977.java - javafx-fxml/test/javafx/fxml/RT_17646.java - javafx-fxml/test/javafx/fxml/RT_17714.java - javafx-fxml/test/javafx/fxml/RT_18046.java - javafx-fxml/test/javafx/fxml/RT_18218.java - javafx-fxml/test/javafx/fxml/RT_18680.java - javafx-fxml/test/javafx/fxml/RT_18933.java - javafx-fxml/test/javafx/fxml/RT_19008.java - javafx-fxml/test/javafx/fxml/RT_19112.java - javafx-fxml/test/javafx/fxml/RT_19139.java - javafx-fxml/test/javafx/fxml/RT_19228.java - javafx-fxml/test/javafx/fxml/RT_19329.java - javafx-fxml/test/javafx/fxml/RT_19870.java - javafx-fxml/test/javafx/fxml/RT_20082.java - javafx-fxml/test/javafx/fxml/RT_20471.java - javafx-fxml/test/javafx/fxml/RT_21559.java - javafx-fxml/test/javafx/fxml/RT_22864.java - javafx-fxml/test/javafx/fxml/RT_22971.java - javafx-fxml/test/javafx/fxml/RT_23244.java - javafx-fxml/test/javafx/fxml/RT_23413.java - javafx-fxml/test/javafx/fxml/RT_24380.java Changeset: 501088150d56 Author: tb115823 Date: 2012-12-04 10:01 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/501088150d56 Fix no runnable method errors in tests. Disable test RT-23413 + javafx-fxml/test/javafx/fxml/RT_21559.java - javafx-fxml/test/javafx/fxml/RT_21559Test.java + javafx-fxml/test/javafx/fxml/RT_22864.java - javafx-fxml/test/javafx/fxml/RT_22864Test.java + javafx-fxml/test/javafx/fxml/RT_23244.java - javafx-fxml/test/javafx/fxml/RT_23244Test.java ! javafx-fxml/test/javafx/fxml/RT_23413Test.java Changeset: fbce04284f89 Author: tb115823 Date: 2012-12-04 16:04 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fbce04284f89 fix fxml test RT-23413. Added warmup before actual performance comparison ! javafx-fxml/test/javafx/fxml/RT_23413Test.java Changeset: 9353d8ea7c4b Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-12-04 09:37 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9353d8ea7c4b Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-fxml/test/javafx/fxml/RT_14880.java - javafx-fxml/test/javafx/fxml/RT_15524.java - javafx-fxml/test/javafx/fxml/RT_16722.java - javafx-fxml/test/javafx/fxml/RT_16724.java - javafx-fxml/test/javafx/fxml/RT_16815.java - javafx-fxml/test/javafx/fxml/RT_16977.java - javafx-fxml/test/javafx/fxml/RT_17646.java - javafx-fxml/test/javafx/fxml/RT_17714.java - javafx-fxml/test/javafx/fxml/RT_18046.java - javafx-fxml/test/javafx/fxml/RT_18218.java - javafx-fxml/test/javafx/fxml/RT_18680.java - javafx-fxml/test/javafx/fxml/RT_18933.java - javafx-fxml/test/javafx/fxml/RT_19008.java - javafx-fxml/test/javafx/fxml/RT_19112.java - javafx-fxml/test/javafx/fxml/RT_19139.java - javafx-fxml/test/javafx/fxml/RT_19228.java - javafx-fxml/test/javafx/fxml/RT_19329.java - javafx-fxml/test/javafx/fxml/RT_19870.java - javafx-fxml/test/javafx/fxml/RT_20082.java - javafx-fxml/test/javafx/fxml/RT_20471.java ! javafx-fxml/test/javafx/fxml/RT_21559.java ! javafx-fxml/test/javafx/fxml/RT_22864.java - javafx-fxml/test/javafx/fxml/RT_22971.java ! javafx-fxml/test/javafx/fxml/RT_23244.java - javafx-fxml/test/javafx/fxml/RT_23413.java - javafx-fxml/test/javafx/fxml/RT_24380.java Changeset: 4fb083d0a750 Author: hudson Date: 2012-12-06 16:19 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4fb083d0a750 Added tag 8.0-b67 for changeset 9353d8ea7c4b ! .hgtags Changeset: 16381e29f371 Author: David Grieve Date: 2012-12-11 11:23 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/16381e29f371 resolve merge conflict - javafx-fxml/test/javafx/fxml/RT_14880.java - javafx-fxml/test/javafx/fxml/RT_15524.java - javafx-fxml/test/javafx/fxml/RT_16722.java - javafx-fxml/test/javafx/fxml/RT_16724.java - javafx-fxml/test/javafx/fxml/RT_16815.java - javafx-fxml/test/javafx/fxml/RT_16977.java - javafx-fxml/test/javafx/fxml/RT_17646.java - javafx-fxml/test/javafx/fxml/RT_17714.java - javafx-fxml/test/javafx/fxml/RT_18046.java - javafx-fxml/test/javafx/fxml/RT_18218.java - javafx-fxml/test/javafx/fxml/RT_18680.java - javafx-fxml/test/javafx/fxml/RT_18933.java - javafx-fxml/test/javafx/fxml/RT_19008.java - javafx-fxml/test/javafx/fxml/RT_19112.java - javafx-fxml/test/javafx/fxml/RT_19139.java - javafx-fxml/test/javafx/fxml/RT_19228.java - javafx-fxml/test/javafx/fxml/RT_19329.java - javafx-fxml/test/javafx/fxml/RT_19870.java - javafx-fxml/test/javafx/fxml/RT_20082.java - javafx-fxml/test/javafx/fxml/RT_20471.java - javafx-fxml/test/javafx/fxml/RT_22971.java - javafx-fxml/test/javafx/fxml/RT_23413.java - javafx-fxml/test/javafx/fxml/RT_24380.java ! javafx-ui-common/src/javafx/scene/layout/BorderConverter.java ! javafx-ui-common/src/javafx/scene/layout/Region.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java Changeset: 8749547f90e5 Author: David Grieve Date: 2012-12-11 11:42 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8749547f90e5 RT-26694: gatherParentStylesheets in StyleManager might return null. ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java From mp at jugs.org Tue Dec 11 09:21:30 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Tue, 11 Dec 2012 18:21:30 +0100 Subject: Provide source files of JavaFX for JDK8 preview builds In-Reply-To: <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> Message-ID: <50C76B9A.9000300@jugs.org> Hi, I wonder whether it would be possible to distribute the corresponding JavaFX source code as a zip-file together with each new JDK8 preview build in a way similar to the standard Java sources or the javadoc files. This would make debugging and error reporting a lot easier because you could step right into the code when you encounter a problem. LG, Michael From richard.bair at oracle.com Tue Dec 11 10:21:41 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 11 Dec 2012 10:21:41 -0800 Subject: Provide source files of JavaFX for JDK8 preview builds In-Reply-To: <50C76B9A.9000300@jugs.org> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C76B9A.9000300@jugs.org> Message-ID: Kevin, don't we have a JIRA for this? Richard On Dec 11, 2012, at 9:21 AM, Dr. Michael Paus wrote: > Hi, > I wonder whether it would be possible to distribute the corresponding JavaFX source > code as a zip-file together with each new JDK8 preview build in a way similar to the standard > Java sources or the javadoc files. This would make debugging and error reporting a lot > easier because you could step right into the code when you encounter a problem. > LG, Michael From hang.vo at oracle.com Tue Dec 11 10:33:50 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 11 Dec 2012 18:33:50 +0000 Subject: hg: openjfx/8/graphics/rt: 61 new changesets Message-ID: <20121211183506.8272B47071@hg.openjdk.java.net> Changeset: 4fb083d0a750 Author: hudson Date: 2012-12-06 16:19 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4fb083d0a750 Added tag 8.0-b67 for changeset 9353d8ea7c4b ! .hgtags Changeset: dd45fc2ac4ba Author: "Jasper Potts" Date: 2012-11-27 16:09 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dd45fc2ac4ba Fixed RT-19713 & RT-26435 Add API to JavaFX to allow for setting preferred user agent stylesheet. Also add system property for setting the user agent styles. ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/javafx/application/Application.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java - javafx-ui-controls/src/javafx/scene/control/UAStylesheetLoader.java Changeset: 5d5dddfa1a60 Author: "Jasper Potts" Date: 2012-11-27 16:11 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5d5dddfa1a60 Added new experimental application as a playground for prototyping a new look and feel for JavaFX + apps/experiments/Modena/build.xml + apps/experiments/Modena/manifest.mf + apps/experiments/Modena/nbproject/build-impl.xml + apps/experiments/Modena/nbproject/configs/Run_as_WebStart.properties + apps/experiments/Modena/nbproject/configs/Run_in_Browser.properties + apps/experiments/Modena/nbproject/genfiles.properties + apps/experiments/Modena/nbproject/jfx-impl.xml + apps/experiments/Modena/nbproject/jfx-impl_backup.xml + apps/experiments/Modena/nbproject/project.properties + apps/experiments/Modena/nbproject/project.xml + apps/experiments/Modena/src/modena/Modena.css + apps/experiments/Modena/src/modena/Modena.java + apps/experiments/Modena/src/modena/SamplePage.java + apps/experiments/Modena/src/modena/TestApp.css Changeset: b4fe87e55747 Author: David Grieve Date: 2012-11-28 09:14 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b4fe87e55747 branch merge Changeset: c578bb6b90f4 Author: leifs Date: 2012-11-28 07:48 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c578bb6b90f4 Fixed RT-23878: -fx-ellipsis-string doesn't apply after setStyle ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java Changeset: 1ea2d63fa876 Author: David Grieve Date: 2012-11-28 11:19 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1ea2d63fa876 RT-26554: if an inline style changes, clear the style cache so new styles will be recalculated. ! apps/experiments/Modena/src/modena/Modena.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/com/sun/javafx/scene/CSSFlags.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/test/unit/javafx/scene/CSSNode.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: b1f6d7efb9f2 Author: David Grieve Date: 2012-11-28 11:20 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b1f6d7efb9f2 branch merge Changeset: b354819486c6 Author: leifs Date: 2012-11-28 10:06 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b354819486c6 RT-26245: FXML-LoginDemo text field doesn't show characters ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java Changeset: 0ce17489970d Author: David Grieve Date: 2012-11-28 14:11 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0ce17489970d RT-26484: looping on invalidated method of fontProperty in Labeled caused indirectly by ObjectProperty having no check for equals. Override set method to check equals. ! javafx-ui-controls/src/javafx/scene/control/Labeled.java Changeset: f9919f8e02d7 Author: jgiles Date: 2012-09-17 13:22 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f9919f8e02d7 Small improvements to TreeTableView implementation. ! javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableRow.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java Changeset: 7e64b82fa22c Author: jgiles Date: 2012-09-17 15:21 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7e64b82fa22c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: a0feb76fb5a1 Author: jgiles Date: 2012-09-20 08:29 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a0feb76fb5a1 Small TreeTableRow cleanup. ! javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableRow.java Changeset: 686deb763e24 Author: jgiles Date: 2012-09-20 08:39 +1200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/686deb763e24 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 969bc24c7dc8 Author: jgiles Date: 2012-10-08 08:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/969bc24c7dc8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: ec59f4a357e3 Author: jgiles Date: 2012-11-10 12:07 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ec59f4a357e3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: a819d671e276 Author: jgiles Date: 2012-11-19 10:13 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a819d671e276 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 56426964368a Author: jgiles Date: 2012-12-03 14:18 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/56426964368a RT-17288: Initial import of a completely new TreeTableView implementation (and removal of the old one). - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableColumn.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableRow.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/TableColumnComparator.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableCellSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableCellSkinBase.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/TableRowSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css + javafx-ui-controls/src/javafx/scene/control/CellSpan.java ! javafx-ui-controls/src/javafx/scene/control/FocusModel.java ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java + javafx-ui-controls/src/javafx/scene/control/ResizeFeaturesBase.java + javafx-ui-controls/src/javafx/scene/control/SpanModel.java ! javafx-ui-controls/src/javafx/scene/control/TableCell.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java + javafx-ui-controls/src/javafx/scene/control/TableColumnBase.java + javafx-ui-controls/src/javafx/scene/control/TableFocusModel.java ! javafx-ui-controls/src/javafx/scene/control/TablePosition.java + javafx-ui-controls/src/javafx/scene/control/TablePositionBase.java + javafx-ui-controls/src/javafx/scene/control/TableSelectionModel.java + javafx-ui-controls/src/javafx/scene/control/TableUtil.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeItem.java + javafx-ui-controls/src/javafx/scene/control/TreeSortMode.java + javafx-ui-controls/src/javafx/scene/control/TreeTableCell.java + javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java + javafx-ui-controls/src/javafx/scene/control/TreeTablePosition.java + javafx-ui-controls/src/javafx/scene/control/TreeTableRow.java + javafx-ui-controls/src/javafx/scene/control/TreeTableView.java + javafx-ui-controls/src/javafx/scene/control/TreeUtil.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java + javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeTableCell.java + javafx-ui-controls/src/javafx/scene/control/cell/ChoiceBoxTreeTableCell.java + javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxTreeTableCell.java + javafx-ui-controls/src/javafx/scene/control/cell/ProgressBarTreeTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/PropertyValueFactory.java + javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeTableCell.java + javafx-ui-controls/src/javafx/scene/control/cell/TreeItemPropertyValueFactory.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/behavior/TableViewAnchorRetriever.java ! javafx-ui-controls/test/javafx/scene/control/MultipleSelectionModelImplTest.java ! javafx-ui-controls/test/javafx/scene/control/TableColumnTest.java + javafx-ui-controls/test/javafx/scene/control/TreeTableColumnTest.java Changeset: 20667075f80a Author: jgiles Date: 2012-12-03 14:22 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/20667075f80a Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableColumn.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableRow.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableView.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 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/javafx/scene/control/TableCell.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java Changeset: 5b9d072ea84c Author: jgiles Date: 2012-12-03 15:06 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5b9d072ea84c Fixing TreeTableView merge errors due to being out in a sandbox for so long. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/javafx/scene/control/TreeTableCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableRow.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/behavior/TableViewAnchorRetriever.java Changeset: 1ae5f7425065 Author: Paru Somashekar Date: 2012-12-03 13:31 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1ae5f7425065 fix RT-26413 Menu blinks when cursor is moved from menu to menuBar. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java Changeset: 3e8a2f562097 Author: jgiles Date: 2012-12-04 12:05 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3e8a2f562097 Partial implementation of RT-21597: 'Move SkinBase into public API'. Namely, removing all references of BehaviorBase from SkinBase, as SkinBase will be public API in 8.0, but BehaviorBase will remain private API for now. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/AccordionSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/BehaviorSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ChoiceBoxSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxBaseSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuButtonSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SeparatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SliderSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SplitPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualContainerBase.java ! javafx-ui-controls/src/javafx/scene/control/SkinBase.java Changeset: 06a8b0af9d46 Author: jgiles Date: 2012-12-04 12:19 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/06a8b0af9d46 RT-21597: 'Move SkinBase into public API': Calling super.dispose(). ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/BehaviorSkinBase.java Changeset: c8452a11548d Author: jgiles Date: 2012-12-04 18:10 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c8452a11548d Updating unit tests related to SkinBase / BehaviorSkinBase + javafx-ui-controls/test/com/sun/javafx/scene/control/skin/BehaviorSkinBaseTest.java ! javafx-ui-controls/test/javafx/scene/control/SkinBaseTest.java Changeset: e17bfdb2019b Author: jgiles Date: 2012-12-04 18:10 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e17bfdb2019b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java Changeset: fefcbba9f15c Author: Paru Somashekar Date: 2012-12-03 21:42 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fefcbba9f15c add AccessibleMenuButton ! javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleButton.java + javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleMenuButton.java Changeset: e76b08812540 Author: leifs Date: 2012-12-05 12:04 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e76b08812540 RT-24930: Add RTL support to ProgressIndicator and ProgressBar ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/javafx/scene/control/ProgressBar.java ! javafx-ui-controls/src/javafx/scene/control/ProgressIndicator.java Changeset: 73632e466060 Author: jgiles Date: 2012-12-06 12:16 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/73632e466060 Removing redundant com.sun.javafx.scene.control.WeakEventHandler, and replacing usages with javafx.event.WeakEventHandler instances. - javafx-ui-controls/src/com/sun/javafx/scene/control/WeakEventHandler.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java Changeset: eefd03e1ae97 Author: jgiles Date: 2012-12-06 12:18 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/eefd03e1ae97 Fixing issue in MultipleSelectionModelBase where a boolean test was being duplicated needlessly. ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java Changeset: 96c299db643a Author: jgiles Date: 2012-12-06 12:20 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/96c299db643a Findbugs: Redundant nullcheck of value known to be non-null in TableView. ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: bdd29e62d47c Author: jgiles Date: 2012-12-06 12:22 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bdd29e62d47c Findbugs: Boxed value is unboxed and then immediately reboxed in CheckBoxTreeItem. ! javafx-ui-controls/src/javafx/scene/control/CheckBoxTreeItem.java Changeset: 3294d1b3ce3d Author: jgiles Date: 2012-12-06 12:32 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3294d1b3ce3d Findbugs: Unwritten field in TextField*Cell classes for textField field. ! javafx-ui-controls/src/javafx/scene/control/cell/CellUtils.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeTableCell.java Changeset: a8a1dfc873f4 Author: jgiles Date: 2012-12-06 12:41 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a8a1dfc873f4 Findbugs: Redundant nullcheck of value known to be non-null in TreeTableView ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java Changeset: 152535ac19aa Author: jgiles Date: 2012-12-06 12:42 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/152535ac19aa Findbugs: Unused fields in TabPane ! javafx-ui-controls/src/javafx/scene/control/TabPane.java Changeset: 078fb6f86f96 Author: jgiles Date: 2012-12-06 12:43 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/078fb6f86f96 Findbugs: Redundant nullcheck of value known to be non-null in TableView ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: 19e297131c24 Author: jgiles Date: 2012-12-06 13:00 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/19e297131c24 Findbugs: Dead store to local variable in ChoiceBoxSelectionModel ! javafx-ui-controls/src/javafx/scene/control/ChoiceBox.java Changeset: 242d2e2f26f6 Author: jgiles Date: 2012-12-06 13:12 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/242d2e2f26f6 Findbugs: Method call passes null for nonnull parameter in ContextMenu ! javafx-ui-controls/src/javafx/scene/control/ContextMenu.java Changeset: 2d9fb12395eb Author: jgiles Date: 2012-12-06 13:14 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2d9fb12395eb Findbugs: Redundant nullcheck of value known to be non-null in TreeTableView ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java Changeset: 5a40381a4c3d Author: jgiles Date: 2012-12-06 13:15 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5a40381a4c3d Findbugs: Dead store to local variable in TextArea ! javafx-ui-controls/src/javafx/scene/control/TextArea.java Changeset: fda395cfc7d6 Author: jgiles Date: 2012-12-06 13:17 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fda395cfc7d6 Findbugs: Dead store to local variable in PopupControl. ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 1a1d89cf5390 Author: jgiles Date: 2012-12-06 13:40 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1a1d89cf5390 Findbugs: Redundant nullcheck of value known to be non-null in TreeCellSkin. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java Changeset: ed94b6913f66 Author: jgiles Date: 2012-12-06 13:51 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ed94b6913f66 Findbugs: Redundant nullcheck of value known to be non-null in VirtualFlow. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 8a90d8a34b74 Author: jgiles Date: 2012-12-06 13:57 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8a90d8a34b74 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt - javafx-ui-controls/src/com/sun/javafx/scene/control/WeakEventHandler.java Changeset: 08a7980d8bc4 Author: leifs Date: 2012-12-06 13:22 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/08a7980d8bc4 RT-24225: Add RTL support to Menu / MenuItem / RadioMenuItem / CheckMenuItem / ContextMenu / MenuBar ! javafx-ui-common/src/com/sun/javafx/Utils.java ! javafx-ui-controls/src/javafx/scene/control/ContextMenu.java Changeset: ee46c5bb984f Author: Paru Somashekar Date: 2012-12-06 15:24 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ee46c5bb984f fix RT-18448 [Slider] label formatter is not applicable + unit test ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SliderSkin.java ! javafx-ui-controls/src/javafx/scene/chart/Axis.java ! javafx-ui-controls/src/javafx/scene/chart/ValueAxis.java ! javafx-ui-controls/test/javafx/scene/control/SliderTest.java Changeset: e8d1d5ae5f78 Author: Paru Somashekar Date: 2012-12-06 15:51 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e8d1d5ae5f78 RT-18448: cleaned up the previous patch. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SliderSkin.java Changeset: bfebbf84081f Author: David Grieve Date: 2012-12-07 14:37 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bfebbf84081f RT-26622: apply linear-gradient patch to highcontrast.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/highcontrast.css Changeset: 4fd3e1bdb19b Author: David Grieve Date: 2012-12-07 14:38 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4fd3e1bdb19b RT-17607: -fx-font-weight: 600 parses as a NUMBER but the css parser expects an IDENT. Fix parser to accept a number. ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java ! javafx-ui-common/test/unit/com/sun/javafx/css/FontWeightTypeTest.java Changeset: bf75ca4caf36 Author: David Grieve Date: 2012-12-07 14:41 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bf75ca4caf36 RT-21709 [partial]: prepare to make CSS Styleable* properites public ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java ! javafx-ui-charts/src/javafx/scene/chart/Chart.java ! javafx-ui-charts/src/javafx/scene/chart/LineChart.java ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java ! javafx-ui-charts/src/javafx/scene/chart/StackedAreaChart.java ! javafx-ui-charts/src/javafx/scene/chart/StackedBarChart.java ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java ! javafx-ui-charts/test/javafx/scene/chart/XYChartTest.java ! javafx-ui-common/src/com/sun/javafx/css/CascadingStyle.java ! javafx-ui-common/src/com/sun/javafx/css/CssError.java ! javafx-ui-common/src/com/sun/javafx/css/Declaration.java + javafx-ui-common/src/com/sun/javafx/css/Origin.java - javafx-ui-common/src/com/sun/javafx/css/Property.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Style.java ! javafx-ui-common/src/com/sun/javafx/css/StyleConverter.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/com/sun/javafx/css/Styleable.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableBooleanProperty.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableDoubleProperty.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableFloatProperty.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableIntegerProperty.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableLongProperty.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableObjectProperty.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableProperty.java + javafx-ui-common/src/com/sun/javafx/css/StyleablePropertyMetaData.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableStringProperty.java ! javafx-ui-common/src/com/sun/javafx/css/Stylesheet.java + javafx-ui-common/src/com/sun/javafx/css/SubCSSProperty.java - javafx-ui-common/src/com/sun/javafx/css/SubStyleableProperty.java ! javafx-ui-common/src/com/sun/javafx/css/converters/FontConverter.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/src/javafx/scene/layout/Background.java ! javafx-ui-common/src/javafx/scene/layout/BackgroundConverter.java ! javafx-ui-common/src/javafx/scene/layout/Border.java ! javafx-ui-common/src/javafx/scene/layout/BorderConverter.java ! javafx-ui-common/src/javafx/scene/layout/FlowPane.java ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/src/javafx/scene/layout/HBox.java ! javafx-ui-common/src/javafx/scene/layout/Region.java ! javafx-ui-common/src/javafx/scene/layout/StackPane.java ! javafx-ui-common/src/javafx/scene/layout/TilePane.java ! javafx-ui-common/src/javafx/scene/layout/VBox.java ! javafx-ui-common/src/javafx/scene/shape/Line.java ! javafx-ui-common/src/javafx/scene/shape/Path.java ! javafx-ui-common/src/javafx/scene/shape/Polyline.java ! javafx-ui-common/src/javafx/scene/shape/Rectangle.java ! javafx-ui-common/src/javafx/scene/shape/Shape.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/src/javafx/scene/text/TextFlow.java ! javafx-ui-common/test/unit/com/sun/javafx/css/DeclarationTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/RuleTest.java + javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyMetaDataTest.java - javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StylesheetTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/TestNode.java ! javafx-ui-common/test/unit/com/sun/javafx/css/TestNodeBase.java ! javafx-ui-common/test/unit/com/sun/javafx/css/TypeTest.java ! javafx-ui-common/test/unit/com/sun/javafx/scene/layout/RegionTest.java ! javafx-ui-common/test/unit/com/sun/javafx/scene/layout/region/BackgroundFillConverterTest.java ! javafx-ui-common/test/unit/com/sun/javafx/test/CssMethodsTestBase.java ! javafx-ui-common/test/unit/com/sun/javafx/test/OnInvalidateMethodsTestBase.java ! javafx-ui-common/test/unit/javafx/scene/CSSNode.java ! javafx-ui-common/test/unit/javafx/scene/Node_onInvalidate_Test.java ! javafx-ui-common/test/unit/javafx/scene/layout/TilePaneTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/ShapeTest.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CellSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVK.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledImpl.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/javafx/scene/chart/Axis.java ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java ! javafx-ui-controls/src/javafx/scene/chart/NumberAxis.java ! javafx-ui-controls/src/javafx/scene/chart/ValueAxis.java ! javafx-ui-controls/src/javafx/scene/control/Accordion.java ! javafx-ui-controls/src/javafx/scene/control/Cell.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/Hyperlink.java ! javafx-ui-controls/src/javafx/scene/control/Label.java ! 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/MenuBar.java ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/ProgressBar.java ! javafx-ui-controls/src/javafx/scene/control/ProgressIndicator.java ! javafx-ui-controls/src/javafx/scene/control/RadioButton.java ! javafx-ui-controls/src/javafx/scene/control/ScrollBar.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java ! javafx-ui-controls/src/javafx/scene/control/Separator.java ! javafx-ui-controls/src/javafx/scene/control/SkinBase.java ! javafx-ui-controls/src/javafx/scene/control/Slider.java ! javafx-ui-controls/src/javafx/scene/control/SplitPane.java ! javafx-ui-controls/src/javafx/scene/control/Tab.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TextField.java ! javafx-ui-controls/src/javafx/scene/control/TitledPane.java ! javafx-ui-controls/src/javafx/scene/control/ToggleButton.java ! javafx-ui-controls/src/javafx/scene/control/ToolBar.java ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTableCell.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabeledImplTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabeledImplTestOther.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabeledTextTest.java ! javafx-ui-controls/test/javafx/scene/chart/AxisTest.java ! javafx-ui-controls/test/javafx/scene/chart/CategoryAxisTest.java ! javafx-ui-controls/test/javafx/scene/chart/NumberAxisTest.java ! javafx-ui-controls/test/javafx/scene/chart/ValueAxisTest.java ! javafx-ui-controls/test/javafx/scene/control/ControlSkinTest.java ! javafx-ui-controls/test/javafx/scene/control/ControlTest.java ! javafx-ui-controls/test/javafx/scene/control/HyperlinkTest.java ! javafx-ui-controls/test/javafx/scene/control/LabelTest.java ! javafx-ui-controls/test/javafx/scene/control/LabeledTest.java ! javafx-ui-controls/test/javafx/scene/control/PaginationTest.java ! javafx-ui-controls/test/javafx/scene/control/ScrollBarTest.java ! javafx-ui-controls/test/javafx/scene/control/ScrollPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/SeparatorTest.java ! javafx-ui-controls/test/javafx/scene/control/SliderTest.java ! javafx-ui-controls/test/javafx/scene/control/SplitPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/TextInputControlTest.java ! javafx-ui-controls/test/javafx/scene/control/TitledPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/ToolbarTest.java ! javafx-ui-controls/test/javafx/scene/control/TooltipTest.java Changeset: 382ea952840d Author: David Grieve Date: 2012-12-07 15:13 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/382ea952840d merge - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableColumn.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableRow.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableView.java - javafx-ui-controls/src/com/sun/javafx/scene/control/WeakEventHandler.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/javafx/scene/chart/Axis.java ! javafx-ui-controls/src/javafx/scene/chart/ValueAxis.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/ProgressBar.java ! javafx-ui-controls/src/javafx/scene/control/ProgressIndicator.java ! javafx-ui-controls/src/javafx/scene/control/SkinBase.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/test/javafx/scene/control/SliderTest.java Changeset: 55b52b24b94d Author: David Grieve Date: 2012-12-10 10:26 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/55b52b24b94d RT-21709 [partial]: fix merge errors after pulling changes onto bf75ca4caf36 ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeTableCell.java Changeset: a867b54962e3 Author: Paru Somashekar Date: 2012-12-10 11:57 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a867b54962e3 fix RT-26820 ChoiceBox with no items throws exception when added to live scene. + unit test. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/test/javafx/scene/control/ChoiceBoxTest.java Changeset: 8dc0b2132350 Author: jgiles Date: 2012-12-07 14:05 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8dc0b2132350 RT-26659: Rename impl_ treeItemCount property in TreeView and TreeTableView (it is now called expandedItemCount and is fully public API). ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! javafx-ui-controls/src/javafx/scene/control/TreeCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeItem.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableRow.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeUtil.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java Changeset: 076a80df7218 Author: jgiles Date: 2012-12-07 17:55 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/076a80df7218 RT-26787: TreeTableView: Key combinations with PgDn and PgUp throw an exception ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java Changeset: 322deaa43d9e Author: jgiles Date: 2012-12-11 09:47 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/322deaa43d9e RT-26656: All functionality that is available on Desktop should also be available on Embedded Touch ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java Changeset: 230b3d48a7a9 Author: jgiles Date: 2012-12-11 10:57 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/230b3d48a7a9 RT-26185: application freeze on focusing combobox (a.k.a RT-26802: Endless loop with multiple focus-traversable ComboBoxes) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 723b6b7fb579 Author: jgiles Date: 2012-12-11 12:06 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/723b6b7fb579 RT-24917: [TreeView] Editing is broken in 8.0 ! javafx-ui-controls/src/javafx/scene/control/ListCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeCell.java Changeset: 28782b36e141 Author: jgiles Date: 2012-12-11 20:52 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/28782b36e141 Fixing unit test to use latest TreeView API. ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: 28aeebda6a0b Author: jgiles Date: 2012-12-11 20:52 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/28aeebda6a0b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java Changeset: 16381e29f371 Author: David Grieve Date: 2012-12-11 11:23 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/16381e29f371 resolve merge conflict - javafx-fxml/test/javafx/fxml/RT_14880.java - javafx-fxml/test/javafx/fxml/RT_15524.java - javafx-fxml/test/javafx/fxml/RT_16722.java - javafx-fxml/test/javafx/fxml/RT_16724.java - javafx-fxml/test/javafx/fxml/RT_16815.java - javafx-fxml/test/javafx/fxml/RT_16977.java - javafx-fxml/test/javafx/fxml/RT_17646.java - javafx-fxml/test/javafx/fxml/RT_17714.java - javafx-fxml/test/javafx/fxml/RT_18046.java - javafx-fxml/test/javafx/fxml/RT_18218.java - javafx-fxml/test/javafx/fxml/RT_18680.java - javafx-fxml/test/javafx/fxml/RT_18933.java - javafx-fxml/test/javafx/fxml/RT_19008.java - javafx-fxml/test/javafx/fxml/RT_19112.java - javafx-fxml/test/javafx/fxml/RT_19139.java - javafx-fxml/test/javafx/fxml/RT_19228.java - javafx-fxml/test/javafx/fxml/RT_19329.java - javafx-fxml/test/javafx/fxml/RT_19870.java - javafx-fxml/test/javafx/fxml/RT_20082.java - javafx-fxml/test/javafx/fxml/RT_20471.java - javafx-fxml/test/javafx/fxml/RT_22971.java - javafx-fxml/test/javafx/fxml/RT_23413.java - javafx-fxml/test/javafx/fxml/RT_24380.java ! javafx-ui-common/src/javafx/scene/layout/BorderConverter.java ! javafx-ui-common/src/javafx/scene/layout/Region.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java Changeset: 8749547f90e5 Author: David Grieve Date: 2012-12-11 11:42 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8749547f90e5 RT-26694: gatherParentStylesheets in StyleManager might return null. ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: 5e68c3c1e45f Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-12-11 10:11 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5e68c3c1e45f Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css From kevin.rushforth at oracle.com Tue Dec 11 10:35:33 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 11 Dec 2012 10:35:33 -0800 Subject: Provide source files of JavaFX for JDK8 preview builds In-Reply-To: References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C76B9A.9000300@jugs.org> Message-ID: <50C77CF5.8050102@oracle.com> http://javafx-jira.kenai.com/browse/RT-21415 Richard Bair wrote: > Kevin, don't we have a JIRA for this? > > Richard > > On Dec 11, 2012, at 9:21 AM, Dr. Michael Paus wrote: > > >> Hi, >> I wonder whether it would be possible to distribute the corresponding JavaFX source >> code as a zip-file together with each new JDK8 preview build in a way similar to the standard >> Java sources or the javadoc files. This would make debugging and error reporting a lot >> easier because you could step right into the code when you encounter a problem. >> LG, Michael >> > > From pedro.duquevieira at gmail.com Tue Dec 11 10:38:31 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 11 Dec 2012 18:38:31 +0000 Subject: Provide source files of JavaFX for JDK8 preview builds Message-ID: Yap, there is a Jira for that. Cheers, -- Pedro Duque Vieira From mp at jugs.org Tue Dec 11 10:42:38 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Tue, 11 Dec 2012 19:42:38 +0100 Subject: Provide source files of JavaFX for JDK8 preview builds In-Reply-To: References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C76B9A.9000300@jugs.org> Message-ID: <50C77E9E.8050503@jugs.org> I just dared to ask because the JIRA is from May and nothing happened since then. If more people would show an interest in that maybe that could raise the priority of it. Am 11.12.2012 19:21, schrieb Richard Bair: > Kevin, don't we have a JIRA for this? > > Richard > > On Dec 11, 2012, at 9:21 AM, Dr. Michael Paus wrote: > >> Hi,t >> I wonder whether it would be possible to distribute the corresponding JavaFX source >> code as a zip-file together with each new JDK8 preview build in a way similar to the standard >> Java sources or the javadoc files. This would make debugging and error reporting a lot >> easier because you could step right into the code when you encounter a problem. >> LG, Michael -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From pedro.duquevieira at gmail.com Tue Dec 11 13:34:22 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 11 Dec 2012 21:34:22 +0000 Subject: Provide source files of JavaFX for JDK8 preview builds Message-ID: Richard has already expressed interest on that, it's just a question of when. cheers, -- Pedro Duque Vieira From Joseph.Andresen at oracle.com Tue Dec 11 14:18:01 2012 From: Joseph.Andresen at oracle.com (Joe Andresen) Date: Tue, 11 Dec 2012 14:18:01 -0800 Subject: ImagePattern, WritableImage, and Shapes Message-ID: <50C7B119.30506@oracle.com> Hey Fellow JFXers! I have been working on an issue recently that has to do with ImagePattern not updating when it's image changes (ie an animated writable image/animated gif). I do not feel great about my current fix because it requrires some public api, which basically copy's how ImageView listens for changes. The shape asks if the Paint can change (paint.canIchange()) and then adding a listener that is forwarded to the imagepattern's image. When fired, the shape marks is fill dirty. Pretty straightforward, but since these are in separate packages, public API is created. Bottom line? Public API just to update an ImagePattern? Seems a bit of overkill. The Fundamental issue here is that in JavaFX, Paints are more or less considered immutable, (the cold hard truth is that sometimes they are not, like in the ImagePattern case), mutable paints have their own set of problems which one could argue is a snowballing scope for this particular issue =(. Because of this, a workaround can be done by the user assuming immutable paints to create a new imagePattern with the newly changed WritableImage, but again this is overkill. It seems to me like it "should just work". So we have 2 options: 1) ImagePattern is fundamentally immutable, and a copy of an image is taken at constructor time and you the user should construct new ImagePattern's if you want it to change. 2) ImagePattern is fundamentally mutable, and can notify its shape of changes, this requires that Paints have the notion of being mutable (color and gradient would return "not Mutable" when asked). Thoughts? -Joe From zonski at gmail.com Tue Dec 11 14:50:47 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Wed, 12 Dec 2012 09:50:47 +1100 Subject: The competition In-Reply-To: References: Message-ID: Short, sharp article that does a good job of expressing the current state of web with regards to "desktop" applications (the link through to the JavaOne talk is also good): http://www.infoq.com/articles/client-server-application-development-with-html5-and-java There is also some very good high-level teasers on things like: - responsive designs (i.e. those that adapt to different screen sizes - possibly relevant to the retina topics recently). - client server design and state management for rich GUI apps (web now needs and is getting a programming model similar to traditional desktop) - tech choice considerations when looking at mobile apps On Tue, Dec 4, 2012 at 7:08 AM, Pedro Duque Vieira < pedro.duquevieira at gmail.com> wrote: > Hi, > > I agree with practically everything Daniel said. > > I've previously stated that deployment is seriously jeopardizing the > adoptance of JavaFX. Let me give 3 use-cases I've experienced in which > JavaFX wasn't a choice because of this: > 1- An hobby project of mine (called Modellus) in which students and > teachers can create simulations of math phenomenon. Animation, charts, > tables, etc can than be used to better illustrate this. I'm still using > JavaFX here but some features will not be possible because of this. > *The problem*: Users want to share their models (Modellus files) on the > internet via a web site with other users. They don't want this to require > other users to download and install Modellus, at least not in a explicit > way > *The possible solution*: If applets were working this could be feasible. > 2- A wallpaper (as in for actual walls) internet shop wants to provide a > service to their customers in which they can create their own custom > wallpapers. For this, customers can upload images and assemble them in the > way they want. > *The problem*: Ideally this should require zero install and zero hassle for > the customers. The zero install part is not possible with javafx. HTML5 > might be the solution however if at all possible one would face serious > technical difficulties. > *The possible solution*: If applets were working this could be feasible. > 3- A Content Management System for mobile phones (initially android and > iphone). Through a site an administrator manages the content that should > appear in a mobile phone app. > *The problem*: JavaFX isn't available for mobile phones. The client has > decided to use phone gap for this, however development with this technology > is sub optimal and performance is also an issue. > *The solution*: Have JavaFX run on mobile phones. > > Thanks for your time, cheers, > > -- > Pedro Duque Vieira > From John_Smith at symantec.com Tue Dec 11 14:53:46 2012 From: John_Smith at symantec.com (John Smith) Date: Tue, 11 Dec 2012 14:53:46 -0800 Subject: Provide source files of JavaFX for JDK8 preview builds In-Reply-To: <50C77E9E.8050503@jugs.org> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C76B9A.9000300@jugs.org> <50C77E9E.8050503@jugs.org> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D22160B262671@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> I find the following useful if I just want to view source when developing using the public APIs as opposed to modifying open-jfx code. Download all of the (public) sources without an hg client from the following link: http://hg.openjdk.java.net/openjfx/8/master/rt/tip.zip Or get the source for a specific tag by going to: http://hg.openjdk.java.net/openjfx/8/master/rt, clicking on the manifest link next to the tag, then clicking on the zip link at the top of the page. The sources aren't under one tree, but are split among the sub-projects, so you need to add the sources for each project to your IDE. For instance for idea you can follow these instructions: http://stackoverflow.com/questions/13407017/javafx-source-code-not-showing-in-intellij-idea After I do that I can debug and step through all of the public source (and yes, it is much easier to develop this way than having no source at all). Of course the above won't be necessary once there is a real zip distribution of the source :-) -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Dr. Michael Paus Sent: Tuesday, December 11, 2012 10:43 AM To: openjfx-dev at openjdk.java.net Subject: Re: Provide source files of JavaFX for JDK8 preview builds I just dared to ask because the JIRA is from May and nothing happened since then. If more people would show an interest in that maybe that could raise the priority of it. Am 11.12.2012 19:21, schrieb Richard Bair: > Kevin, don't we have a JIRA for this? > > Richard > > On Dec 11, 2012, at 9:21 AM, Dr. Michael Paus wrote: > >> Hi,t >> I wonder whether it would be possible to distribute the corresponding >> JavaFX source code as a zip-file together with each new JDK8 preview >> build in a way similar to the standard Java sources or the javadoc >> files. This would make debugging and error reporting a lot easier because you could step right into the code when you encounter a problem. >> LG, Michael -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From pedro.duquevieira at gmail.com Tue Dec 11 14:57:56 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 11 Dec 2012 22:57:56 +0000 Subject: Need help styling context menu Message-ID: Thanks Jerome, that sounds promising! I had your article on my to-read list but didn't have the time to read it yet. Cheers, -- Pedro Duque Vieira From hang.vo at oracle.com Tue Dec 11 15:18:16 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 11 Dec 2012 23:18:16 +0000 Subject: hg: openjfx/2.2.6/graphics/rt: 2 new changesets Message-ID: <20121211231818.A0A6447098@hg.openjdk.java.net> Changeset: ebfca02fc014 Author: hudson Date: 2012-12-05 15:26 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/ebfca02fc014 Added tag 2.2.6-b04 for changeset 3617bc4b5d81 ! .hgtags Changeset: 6feb25f693a2 Author: kcr Date: 2012-12-11 15:03 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/graphics/rt/rev/6feb25f693a2 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.6/MASTER/jfx/rt From pedro.duquevieira at gmail.com Tue Dec 11 15:50:54 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 11 Dec 2012 23:50:54 +0000 Subject: Need way to define width and height in CSS Message-ID: Hi, After some practice writing JavaFX CSS one thing as become clear: a way to clearly define a width and a height is lacking. In standard w3c css you have width and height, on JavaFX CSS you have padding - look at the way the size of the mark on a checkbox is defined in caspian. Padding isn't the nicest way to define this because it is supposed to define the spacing between an element and it's contents. Cheers, -- Pedro Duque Vieira From hang.vo at oracle.com Tue Dec 11 16:04:03 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 12 Dec 2012 00:04:03 +0000 Subject: hg: openjfx/8/controls/rt: 11 new changesets Message-ID: <20121212000418.9EC454709B@hg.openjdk.java.net> Changeset: e941ae1fb3e5 Author: rbair Date: 2012-12-05 10:49 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e941ae1fb3e5 [JavaDoc] Added some missing doc comments on methods in TextInputControl ! javafx-ui-controls/src/javafx/scene/control/TextInputControl.java Changeset: 4daba9576a3b Author: Martin Sladecek Date: 2012-12-06 09:48 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4daba9576a3b RT-26518 Children of Sequential and Parallel Transition should be controlled only through their parent + Sequential Transition test & fixes ! javafx-ui-common/nbproject/project.xml ! javafx-ui-common/src/javafx/animation/ParallelTransition.java ! javafx-ui-common/src/javafx/animation/SequentialTransition.java ! javafx-ui-common/src/javafx/animation/Transition.java + javafx-ui-common/test/unit/javafx/animation/AbstractMasterTimerMock.java + javafx-ui-common/test/unit/javafx/animation/SequentialTransitionPlayTest.java Changeset: 218967f4a7a7 Author: Martin Sladecek Date: 2012-12-06 09:49 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/218967f4a7a7 merge Changeset: ffd89bb359f1 Author: rbair Date: 2012-12-06 16:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ffd89bb359f1 Fix for RT-26100. This change should have no functional impact, but I changed the defaults to match with the multipliers hard-coded into NGRegion. ! javafx-ui-common/src/javafx/scene/layout/BorderStrokeStyle.java Changeset: 34ae31eab256 Author: tb115823 Date: 2012-12-07 12:56 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/34ae31eab256 RT-25494 Cycle detection in fxml includes ! javafx-fxml/src/javafx/fxml/FXMLLoader.java + javafx-fxml/test/javafx/fxml/RT_25494_Cycle_DetectionTest.java + javafx-fxml/test/javafx/fxml/cycle.fxml + javafx-fxml/test/javafx/fxml/dummy-cycle.fxml + javafx-fxml/test/javafx/fxml/leaf1.fxml + javafx-fxml/test/javafx/fxml/leaf2.fxml + javafx-fxml/test/javafx/fxml/leaf3.fxml + javafx-fxml/test/javafx/fxml/leaf4.fxml + javafx-fxml/test/javafx/fxml/one-2-one-cycle.fxml Changeset: 698048c91224 Author: "Jasper Potts" Date: 2012-12-07 15:37 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/698048c91224 Fixed RT-26814: Scrollbar buttons look bad where they meet the track ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: d33ae5444ad0 Author: Martin Sladecek Date: 2012-12-10 13:41 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d33ae5444ad0 More tests & fixes for SequentialTransition. ! javafx-ui-common/src/javafx/animation/SequentialTransition.java ! javafx-ui-common/test/unit/javafx/animation/SequentialTransitionPlayTest.java Changeset: e4f650594652 Author: Martin Sladecek Date: 2012-12-10 13:42 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e4f650594652 merge Changeset: 6ad8578c9044 Author: Milan Kubec Date: 2012-12-11 15:39 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6ad8578c9044 additional asserts; patch applied in behalf of QA ! javafx-fxml/src/javafx/fxml/doc-files/introduction_to_fxml.html Changeset: d42c1ae9369a Author: Milan Kubec Date: 2012-12-11 14:40 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d42c1ae9369a Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx////rt Changeset: 5e68c3c1e45f Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-12-11 10:11 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5e68c3c1e45f Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css From hang.vo at oracle.com Tue Dec 11 16:18:40 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 12 Dec 2012 00:18:40 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20121212001842.EF4714709C@hg.openjdk.java.net> Changeset: 7693bac88ebe Author: David Grieve Date: 2012-12-11 18:57 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7693bac88ebe RT-21709 [partial]: more preparation to make CSS Styleable* properites public ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java ! javafx-ui-charts/src/javafx/scene/chart/Chart.java ! javafx-ui-charts/src/javafx/scene/chart/LineChart.java ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java ! javafx-ui-charts/src/javafx/scene/chart/StackedAreaChart.java ! javafx-ui-charts/src/javafx/scene/chart/StackedBarChart.java ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java ! javafx-ui-charts/test/javafx/scene/chart/XYChartTest.java ! javafx-ui-common/src/com/sun/javafx/css/CssError.java + javafx-ui-common/src/com/sun/javafx/css/CssMetaData.java ! javafx-ui-common/src/com/sun/javafx/css/StyleConverter.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/Styleable.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableProperty.java - javafx-ui-common/src/com/sun/javafx/css/StyleablePropertyMetaData.java ! javafx-ui-common/src/com/sun/javafx/css/SubCSSProperty.java ! javafx-ui-common/src/com/sun/javafx/css/converters/FontConverter.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/src/javafx/scene/layout/Background.java ! javafx-ui-common/src/javafx/scene/layout/BackgroundConverter.java ! javafx-ui-common/src/javafx/scene/layout/Border.java ! javafx-ui-common/src/javafx/scene/layout/BorderConverter.java ! javafx-ui-common/src/javafx/scene/layout/FlowPane.java ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/src/javafx/scene/layout/HBox.java ! javafx-ui-common/src/javafx/scene/layout/Region.java ! javafx-ui-common/src/javafx/scene/layout/StackPane.java ! javafx-ui-common/src/javafx/scene/layout/TilePane.java ! javafx-ui-common/src/javafx/scene/layout/VBox.java ! javafx-ui-common/src/javafx/scene/shape/Line.java ! javafx-ui-common/src/javafx/scene/shape/Path.java ! javafx-ui-common/src/javafx/scene/shape/Polyline.java ! javafx-ui-common/src/javafx/scene/shape/Rectangle.java ! javafx-ui-common/src/javafx/scene/shape/Shape.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/src/javafx/scene/text/TextFlow.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyMetaDataTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/TestNode.java ! javafx-ui-common/test/unit/com/sun/javafx/css/TestNodeBase.java ! javafx-ui-common/test/unit/com/sun/javafx/css/TypeTest.java ! javafx-ui-common/test/unit/com/sun/javafx/scene/layout/RegionTest.java ! javafx-ui-common/test/unit/com/sun/javafx/test/CssMethodsTestBase.java ! javafx-ui-common/test/unit/com/sun/javafx/test/OnInvalidateMethodsTestBase.java ! javafx-ui-common/test/unit/javafx/scene/CSSNode.java ! javafx-ui-common/test/unit/javafx/scene/Node_onInvalidate_Test.java ! javafx-ui-common/test/unit/javafx/scene/layout/TilePaneTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/ShapeTest.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CellSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVK.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledImpl.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/javafx/scene/chart/Axis.java ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java ! javafx-ui-controls/src/javafx/scene/chart/NumberAxis.java ! javafx-ui-controls/src/javafx/scene/chart/ValueAxis.java ! javafx-ui-controls/src/javafx/scene/control/Accordion.java ! javafx-ui-controls/src/javafx/scene/control/Cell.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/Hyperlink.java ! javafx-ui-controls/src/javafx/scene/control/Label.java ! 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/MenuBar.java ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/ProgressBar.java ! javafx-ui-controls/src/javafx/scene/control/ProgressIndicator.java ! javafx-ui-controls/src/javafx/scene/control/RadioButton.java ! javafx-ui-controls/src/javafx/scene/control/ScrollBar.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java ! javafx-ui-controls/src/javafx/scene/control/Separator.java ! javafx-ui-controls/src/javafx/scene/control/SkinBase.java ! javafx-ui-controls/src/javafx/scene/control/Slider.java ! javafx-ui-controls/src/javafx/scene/control/SplitPane.java ! javafx-ui-controls/src/javafx/scene/control/Tab.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TextField.java ! javafx-ui-controls/src/javafx/scene/control/TitledPane.java ! javafx-ui-controls/src/javafx/scene/control/ToggleButton.java ! javafx-ui-controls/src/javafx/scene/control/ToolBar.java ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeTableCell.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabeledImplTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabeledImplTestOther.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabeledTextTest.java ! javafx-ui-controls/test/javafx/scene/chart/AxisTest.java ! javafx-ui-controls/test/javafx/scene/chart/CategoryAxisTest.java ! javafx-ui-controls/test/javafx/scene/chart/NumberAxisTest.java ! javafx-ui-controls/test/javafx/scene/chart/ValueAxisTest.java ! javafx-ui-controls/test/javafx/scene/control/ControlSkinTest.java ! javafx-ui-controls/test/javafx/scene/control/ControlTest.java ! javafx-ui-controls/test/javafx/scene/control/HyperlinkTest.java ! javafx-ui-controls/test/javafx/scene/control/LabelTest.java ! javafx-ui-controls/test/javafx/scene/control/LabeledTest.java ! javafx-ui-controls/test/javafx/scene/control/PaginationTest.java ! javafx-ui-controls/test/javafx/scene/control/ScrollBarTest.java ! javafx-ui-controls/test/javafx/scene/control/ScrollPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/SeparatorTest.java ! javafx-ui-controls/test/javafx/scene/control/SliderTest.java ! javafx-ui-controls/test/javafx/scene/control/SplitPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/TextInputControlTest.java ! javafx-ui-controls/test/javafx/scene/control/TitledPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/ToolbarTest.java ! javafx-ui-controls/test/javafx/scene/control/TooltipTest.java Changeset: d73eadc63171 Author: David Grieve Date: 2012-12-11 19:11 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d73eadc63171 branch merge From pedro.duquevieira at gmail.com Tue Dec 11 16:23:54 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 12 Dec 2012 00:23:54 +0000 Subject: Provide source files of JavaFX for JDK8 preview builds Message-ID: Cool John, thanks for the info. -- Pedro Duque Vieira From richard.bair at oracle.com Tue Dec 11 17:19:15 2012 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 11 Dec 2012 17:19:15 -0800 Subject: ImagePattern, WritableImage, and Shapes In-Reply-To: <50C7B119.30506@oracle.com> References: <50C7B119.30506@oracle.com> Message-ID: It seems to me that we ought to allow the ImagePattern to be a mutable paint. Maybe we don't even need to have an "isMutable" method, but just have the "addPaintChangeListener" method that takes a runnable (or something, maybe an event! Seems heavy) and then just have them be no-ops on the mutable paints and document that they are no-ops because the paints never change, and then have it implemented on the ImagePattern. What do you think? Richard On Dec 11, 2012, at 2:18 PM, Joe Andresen wrote: > Hey Fellow JFXers! > > I have been working on an issue recently that has to do with ImagePattern not updating when it's image changes (ie an animated writable image/animated gif). > > I do not feel great about my current fix because it requrires some public api, which basically copy's how ImageView listens for changes. The shape asks if the Paint can change (paint.canIchange()) and then adding a listener that is forwarded to the imagepattern's image. When fired, the shape marks is fill dirty. Pretty straightforward, but since these are in separate packages, public API is created. > > Bottom line? Public API just to update an ImagePattern? Seems a bit of overkill. > > The Fundamental issue here is that in JavaFX, Paints are more or less considered immutable, (the cold hard truth is that sometimes they are not, like in the ImagePattern case), mutable paints have their own set of problems which one could argue is a snowballing scope for this particular issue =(. > > Because of this, a workaround can be done by the user assuming immutable paints to create a new imagePattern with the newly changed WritableImage, but again this is overkill. It seems to me like it "should just work". > > So we have 2 options: > > 1) ImagePattern is fundamentally immutable, and a copy of an image is taken at constructor time and you the user should construct new ImagePattern's if you want it to change. > > 2) ImagePattern is fundamentally mutable, and can notify its shape of changes, this requires that Paints have the notion of being mutable (color and gradient would return "not Mutable" when asked). > > Thoughts? > -Joe > > > From hang.vo at oracle.com Tue Dec 11 22:18:17 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 12 Dec 2012 06:18:17 +0000 Subject: hg: openjfx/8/controls/rt: fix line endings from DOS to UNIX Message-ID: <20121212061820.96631470B2@hg.openjdk.java.net> Changeset: 967790bfb2ac Author: ptbrunet Date: 2012-12-12 00:10 -0600 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/967790bfb2ac fix line endings from DOS to UNIX ! javafx-ui-common/src/com/sun/javafx/accessible/AccessibleNode.java ! javafx-ui-common/src/com/sun/javafx/accessible/AccessibleStage.java ! javafx-ui-common/src/com/sun/javafx/accessible/AccessibleText.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleButton.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleCheckBox.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleControl.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleRadioButton.java From tobi at ultramixer.com Wed Dec 12 01:38:41 2012 From: tobi at ultramixer.com (Tobias Bley) Date: Wed, 12 Dec 2012 10:38:41 +0100 Subject: How to reach retina support In-Reply-To: <81230380-97BD-4951-9CE2-9E2254103456@oracle.com> References: <411E73D23DEC4C46BA48F2B6D8BF3D22160AD6A2AC@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <81230380-97BD-4951-9CE2-9E2254103456@oracle.com> Message-ID: <34E1CFB8-9E00-4452-88D7-49A9865B5958@ultramixer.com> Is there anything we could do out now with JavaFX 2.2 to reach Retina support? Am 05.12.2012 um 01:00 schrieb Richard Bair : > In fact, we've implemented retina once already for the iOS prototype. I'm hoping adding the support to Mac desktop isn't terribly hard. Good question about level of support though -- so far we have been thinking only of the 2x retina case. One reason for this is that aligning to pixel boundaries for crisp controls etc is a PAIN if we don't simply double, but start doing fractional scaling. You position at 100 thinking it will be crisp but it ends up at some fractional position instead. > > On Dec 4, 2012, at 3:07 PM, John Smith wrote: > >> What is desirable is likely: >> 1. A glass implementation which takes advantages of OS API level optimizations for Retina. >> 2. An ability to support apps spanning retina and non-retina windows. >> 3. Image loaders which are aware of whether to use retina or non-retina images >> 4. Ensuring that retina aware apps work when embedded in Swing and Browsers >> 5. Identifying to the OS that the app is retina aware, so that the OS doesn't try to double up the applications pixels. >> 6. A conditional feature which identifies to the app writer that they are running on a retina so they can take special action if they want to. >> 7. High quality text support in retina mode with correct font sizing. >> 8. The ability, perhaps at a node level, to indicate that a 1x or a 4x backing store should be used. >> 9. The ability to specify co-ordinates in a device resolution independent way (e.g. measurement facilities like font ems and percentage values). >> >> ----------------------------------- >> >> If interested, there is some further background info below: >> >> There are some comments by Mike Swingler on developing Retina support for Swing. They won't all apply to JavaFX, and I don't understand them all either ;-) But they are very interesting to read. See: http://prod.lists.apple.com/archives/java-dev/2012/Oct/msg00144.html >> >> 1. History of retina in Swing. >> >> It seems that Apple got retina support working in Apple JDK6 by hacking the graphics pipeline pretty severely and that that work can't be directly ported to OpenJDK, so getting Retina support for Swing is an open item and I don't know if it is scheduled at any time. If Swing for the JDK7+ does not get Retina support, then the impact that has on embedding JFXPanels in Swing will need to be assessed. >> >> Regarding potential OpenJDK AWT support for Retina, Mike comments: "In order to render at a Retina resolution, the OpenGL pipeline will have to create a 4x sized backing store for the pixels, and apply a 2x affine transform to all graphics operations going from the API layer to the graphics context layer. Just that easy (I am, of course joking, the work is actually very hard and is littered with corner cases)." >> >> Perhaps this is also relevant for supporting Retina in JavaFX. >> >> 2. What to do if your app window spans multiple screens, one Retina and one not. >> >> Mike comments: "handling Retina *well* will also include tearing down and recreating the backing store dynamically as window is dragged across displays of varying resolution, and getting the app to redraw a the right times to make this transition smooth." >> >> 3. Apple's OS allows embedding some retina scaled panels inside some panels which are not retina scaled. There is a very good overview of the user facing issues of software running on Retina here: http://www.anandtech.com/show/6023/the-nextgen-macbook-pro-with-retina-display-review/6. From the linked article about Retina support in Aperture: >> >> "Here Apple is scaling the UI elements like the menus and widgets on the screen (backing scale factor = 2.0), but displaying the open image unscaled (backing scale factor = 1.0). As a result we can fit almost an entire 2880 x 1800 image on the screen without zooming out. Remember the backing scale factor isn't global, individual elements on the screen can be scaled independently depending on their purpose." >> >> 4. There is a whole range of things which apple recommends when developing apps for Retina: https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html#//apple_ref/doc/uid/TP40012302-CH4-SW4 >> Providing @2x graphics in addition to "standard" resolution images and adopting an @2x graphics naming convention. >> Including high resolution icons. >> Packaging your app with meta data which indicates to the OS that it is retina capable. >> Loading images using methods which seamlessly lookup the appropriate retina or non-retina images. >> Use higher point fonts for retina displays. >> Make use of advanced apple APIs for high performance rendering of pixels and queries of pixel data. >> >> Retina support for Apple devices is a probably easier than hi-dpi support in non-apple devices. For instance, Apple really only target a limited set of screen resolutions, whereby retina seems to mean double the "standard" resolution. There are currently a bunch of non-apple devices which have high resolution displays (e.g. 1920x1080 13 inch laptops) that are near retina, but not quite and the pixels on these devices become so small that it is hard to make stuff out and use the devices unless your eyes are really young. What might be optimal for JavaFX is display resolution and zoom level independent support. e.g. image lookup routines which choose from bitmapped graphics at @0.75x @1x @1.5x @2x, rather than just @1x and @2x. Such resolution independent apps is useful for accessibility applications. Perhaps there is a link between the Hi-DPI discussion and support for high quality display of resolution and zoom level independent applications. >> >> Hopefully good support for display resolution and zoom level independent JavaFX will not prove difficult. JavaFX has a thin native porting layer in Glass. Most of the JavaFX system is vector based. JavaFX already includes scaling and zooming primitives and a pipeline which supports these at independent levels for different Scene Graph nodes. JavaFX also already features resizable controls supported by sophisticated layout managers. >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Randahl Fink Isaksen >> Sent: Tuesday, December 04, 2012 1:11 PM >> To: Tobi >> Cc: Mailing List openjfx-dev at openjdk.java.net >> Subject: Re: How to reach retina support >> >> Hi Tobi >> >> I am not sure what you mean by "Scale all javaFX rendering by factor 2.0". Since JavaFX is primarily vector based, I cannot see why you would do that. >> >> As long as JavaFX prevents Mac OS from switching a JavaFX app to the magnifying mode, I can ensure that my app looks great, as long as I bring fine enough images along with it. ImageView is already able to scale my images, so why do you need more than bullet 1? >> >> Randahl >> >> >> >> On Dec 4, 2012, at 21:50 , Tobi wrote: >> >>> Hi, >>> >>> I would like to start the discussion about the technical requirements for retina support in javaFX. Java6 and flash supports already retina Displays (aka HiDPI) >>> >>> There seams to be two Important Points: >>> >>> 1. prevent MacOSX from switching The JavaFX app to the magnifying mode so that not all rendering is scaled by 2.0 >>> >>> 2. Scale all javaFX rendering by factor 2.0 >>> >>> What do we have to do besides these points? >>> >>> Best regard, >>> Tobi >> From giovanni_stiwes at yahoo.com.br Wed Dec 12 02:25:01 2012 From: giovanni_stiwes at yahoo.com.br (Giovanni Stiwes Santos Silva) Date: Wed, 12 Dec 2012 02:25:01 -0800 (PST) Subject: TableView refreshing Message-ID: <1355307901.36186.YahooMailNeo@web112006.mail.gq1.yahoo.com> When editing a record in a table that already has a PK defined, the line does not update. Most systems work with jpa, then I think this bug should be given greater importance. I believe this same problem happens to many people. Look at the issues: http://javafx-jira.kenai.com/browse/RT-22463 http://javafx-jira.kenai.com/browse/RT-21822 From hang.vo at oracle.com Wed Dec 12 06:18:47 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 12 Dec 2012 14:18:47 +0000 Subject: hg: openjfx/8/graphics/rt: 3 new changesets Message-ID: <20121212141853.8E6AD470BF@hg.openjdk.java.net> Changeset: 6f55468ef360 Author: Martin Sladecek Date: 2012-12-12 15:04 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6f55468ef360 More SequentialTransition, ParallelTransition fixes & tests. ! javafx-ui-common/src/javafx/animation/ParallelTransition.java ! javafx-ui-common/src/javafx/animation/SequentialTransition.java + javafx-ui-common/test/unit/javafx/animation/ParallelTransitionPlayTest.java ! javafx-ui-common/test/unit/javafx/animation/SequentialTransitionPlayTest.java Changeset: 0e42aeef9aba Author: Martin Sladecek Date: 2012-12-12 15:04 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0e42aeef9aba merge Changeset: 95e34ce7c7d3 Author: Martin Sladecek Date: 2012-12-12 15:05 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/95e34ce7c7d3 merge From hang.vo at oracle.com Wed Dec 12 07:04:24 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 12 Dec 2012 15:04:24 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20121212150432.D399D470C1@hg.openjdk.java.net> Changeset: a2bfab02a6a7 Author: Martin Sladecek Date: 2012-12-12 15:49 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a2bfab02a6a7 [TEST] more Transition tests ! javafx-ui-common/test/unit/javafx/animation/ParallelTransitionPlayTest.java ! javafx-ui-common/test/unit/javafx/animation/SequentialTransitionPlayTest.java Changeset: 8f2a5ad385b2 Author: Martin Sladecek Date: 2012-12-12 15:49 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8f2a5ad385b2 merge - javafx-ui-common/src/com/sun/javafx/css/Property.java - javafx-ui-common/src/com/sun/javafx/css/SubStyleableProperty.java - javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableColumn.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableRow.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableView.java - javafx-ui-controls/src/com/sun/javafx/scene/control/WeakEventHandler.java - javafx-ui-controls/src/javafx/scene/control/UAStylesheetLoader.java From hang.vo at oracle.com Wed Dec 12 07:04:24 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 12 Dec 2012 15:04:24 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20121212150434.8466A470C2@hg.openjdk.java.net> Changeset: d742879f2ba2 Author: David Grieve Date: 2012-12-12 09:49 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d742879f2ba2 [TEST-ONLY] Rename StyleablePropertyMetaDataTest to CssMetaDataTest to fix compile error + javafx-ui-common/test/unit/com/sun/javafx/css/CssMetaDataTest.java - javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyMetaDataTest.java Changeset: 672e8902b7ae Author: David Grieve Date: 2012-12-12 09:49 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/672e8902b7ae branch merge From hang.vo at oracle.com Wed Dec 12 07:33:26 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 12 Dec 2012 15:33:26 +0000 Subject: hg: openjfx/8/controls/rt: RT-26930: fix syntax error in highcontrast.css Message-ID: <20121212153328.EE798470C4@hg.openjdk.java.net> Changeset: 12e9b63a86c9 Author: David Grieve Date: 2012-12-12 10:26 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/12e9b63a86c9 RT-26930: fix syntax error in highcontrast.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/highcontrast.css From richard.bair at oracle.com Wed Dec 12 08:43:31 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 12 Dec 2012 08:43:31 -0800 Subject: How to reach retina support In-Reply-To: <34E1CFB8-9E00-4452-88D7-49A9865B5958@ultramixer.com> References: <411E73D23DEC4C46BA48F2B6D8BF3D22160AD6A2AC@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> <81230380-97BD-4951-9CE2-9E2254103456@oracle.com> <34E1CFB8-9E00-4452-88D7-49A9865B5958@ultramixer.com> Message-ID: <85E7078E-BD41-4A69-B604-A738A8C66C75@oracle.com> I don't believe so, it requires some coordination in the Glass/Prism layer. Richard On Dec 12, 2012, at 1:38 AM, Tobias Bley wrote: > Is there anything we could do out now with JavaFX 2.2 to reach Retina support? > > > Am 05.12.2012 um 01:00 schrieb Richard Bair : > >> In fact, we've implemented retina once already for the iOS prototype. I'm hoping adding the support to Mac desktop isn't terribly hard. Good question about level of support though -- so far we have been thinking only of the 2x retina case. One reason for this is that aligning to pixel boundaries for crisp controls etc is a PAIN if we don't simply double, but start doing fractional scaling. You position at 100 thinking it will be crisp but it ends up at some fractional position instead. >> >> On Dec 4, 2012, at 3:07 PM, John Smith wrote: >> >>> What is desirable is likely: >>> 1. A glass implementation which takes advantages of OS API level optimizations for Retina. >>> 2. An ability to support apps spanning retina and non-retina windows. >>> 3. Image loaders which are aware of whether to use retina or non-retina images >>> 4. Ensuring that retina aware apps work when embedded in Swing and Browsers >>> 5. Identifying to the OS that the app is retina aware, so that the OS doesn't try to double up the applications pixels. >>> 6. A conditional feature which identifies to the app writer that they are running on a retina so they can take special action if they want to. >>> 7. High quality text support in retina mode with correct font sizing. >>> 8. The ability, perhaps at a node level, to indicate that a 1x or a 4x backing store should be used. >>> 9. The ability to specify co-ordinates in a device resolution independent way (e.g. measurement facilities like font ems and percentage values). >>> >>> ----------------------------------- >>> >>> If interested, there is some further background info below: >>> >>> There are some comments by Mike Swingler on developing Retina support for Swing. They won't all apply to JavaFX, and I don't understand them all either ;-) But they are very interesting to read. See: http://prod.lists.apple.com/archives/java-dev/2012/Oct/msg00144.html >>> >>> 1. History of retina in Swing. >>> >>> It seems that Apple got retina support working in Apple JDK6 by hacking the graphics pipeline pretty severely and that that work can't be directly ported to OpenJDK, so getting Retina support for Swing is an open item and I don't know if it is scheduled at any time. If Swing for the JDK7+ does not get Retina support, then the impact that has on embedding JFXPanels in Swing will need to be assessed. >>> >>> Regarding potential OpenJDK AWT support for Retina, Mike comments: "In order to render at a Retina resolution, the OpenGL pipeline will have to create a 4x sized backing store for the pixels, and apply a 2x affine transform to all graphics operations going from the API layer to the graphics context layer. Just that easy (I am, of course joking, the work is actually very hard and is littered with corner cases)." >>> >>> Perhaps this is also relevant for supporting Retina in JavaFX. >>> >>> 2. What to do if your app window spans multiple screens, one Retina and one not. >>> >>> Mike comments: "handling Retina *well* will also include tearing down and recreating the backing store dynamically as window is dragged across displays of varying resolution, and getting the app to redraw a the right times to make this transition smooth." >>> >>> 3. Apple's OS allows embedding some retina scaled panels inside some panels which are not retina scaled. There is a very good overview of the user facing issues of software running on Retina here: http://www.anandtech.com/show/6023/the-nextgen-macbook-pro-with-retina-display-review/6. From the linked article about Retina support in Aperture: >>> >>> "Here Apple is scaling the UI elements like the menus and widgets on the screen (backing scale factor = 2.0), but displaying the open image unscaled (backing scale factor = 1.0). As a result we can fit almost an entire 2880 x 1800 image on the screen without zooming out. Remember the backing scale factor isn't global, individual elements on the screen can be scaled independently depending on their purpose." >>> >>> 4. There is a whole range of things which apple recommends when developing apps for Retina: https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html#//apple_ref/doc/uid/TP40012302-CH4-SW4 >>> Providing @2x graphics in addition to "standard" resolution images and adopting an @2x graphics naming convention. >>> Including high resolution icons. >>> Packaging your app with meta data which indicates to the OS that it is retina capable. >>> Loading images using methods which seamlessly lookup the appropriate retina or non-retina images. >>> Use higher point fonts for retina displays. >>> Make use of advanced apple APIs for high performance rendering of pixels and queries of pixel data. >>> >>> Retina support for Apple devices is a probably easier than hi-dpi support in non-apple devices. For instance, Apple really only target a limited set of screen resolutions, whereby retina seems to mean double the "standard" resolution. There are currently a bunch of non-apple devices which have high resolution displays (e.g. 1920x1080 13 inch laptops) that are near retina, but not quite and the pixels on these devices become so small that it is hard to make stuff out and use the devices unless your eyes are really young. What might be optimal for JavaFX is display resolution and zoom level independent support. e.g. image lookup routines which choose from bitmapped graphics at @0.75x @1x @1.5x @2x, rather than just @1x and @2x. Such resolution independent apps is useful for accessibility applications. Perhaps there is a link between the Hi-DPI discussion and support for high quality display of resolution and zoom level independent applications. >>> >>> Hopefully good support for display resolution and zoom level independent JavaFX will not prove difficult. JavaFX has a thin native porting layer in Glass. Most of the JavaFX system is vector based. JavaFX already includes scaling and zooming primitives and a pipeline which supports these at independent levels for different Scene Graph nodes. JavaFX also already features resizable controls supported by sophisticated layout managers. >>> >>> -----Original Message----- >>> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Randahl Fink Isaksen >>> Sent: Tuesday, December 04, 2012 1:11 PM >>> To: Tobi >>> Cc: Mailing List openjfx-dev at openjdk.java.net >>> Subject: Re: How to reach retina support >>> >>> Hi Tobi >>> >>> I am not sure what you mean by "Scale all javaFX rendering by factor 2.0". Since JavaFX is primarily vector based, I cannot see why you would do that. >>> >>> As long as JavaFX prevents Mac OS from switching a JavaFX app to the magnifying mode, I can ensure that my app looks great, as long as I bring fine enough images along with it. ImageView is already able to scale my images, so why do you need more than bullet 1? >>> >>> Randahl >>> >>> >>> >>> On Dec 4, 2012, at 21:50 , Tobi wrote: >>> >>>> Hi, >>>> >>>> I would like to start the discussion about the technical requirements for retina support in javaFX. Java6 and flash supports already retina Displays (aka HiDPI) >>>> >>>> There seams to be two Important Points: >>>> >>>> 1. prevent MacOSX from switching The JavaFX app to the magnifying mode so that not all rendering is scaled by 2.0 >>>> >>>> 2. Scale all javaFX rendering by factor 2.0 >>>> >>>> What do we have to do besides these points? >>>> >>>> Best regard, >>>> Tobi >>> > From joseph.andresen at oracle.com Wed Dec 12 10:22:28 2012 From: joseph.andresen at oracle.com (joe andresen) Date: Wed, 12 Dec 2012 10:22:28 -0800 Subject: ImagePattern, WritableImage, and Shapes In-Reply-To: References: <50C7B119.30506@oracle.com> Message-ID: <50C8CB64.6030409@oracle.com> I definitely think ImagePattern is better off being acknowledged as mutable, I'll think about what I can do to my current change in regards to public api. -J On 12/11/2012 5:19 PM, Richard Bair wrote: > It seems to me that we ought to allow the ImagePattern to be a mutable paint. Maybe we don't even need to have an "isMutable" method, but just have the "addPaintChangeListener" method that takes a runnable (or something, maybe an event! Seems heavy) and then just have them be no-ops on the mutable paints and document that they are no-ops because the paints never change, and then have it implemented on the ImagePattern. > > What do you think? > Richard > > On Dec 11, 2012, at 2:18 PM, Joe Andresen wrote: > >> Hey Fellow JFXers! >> >> I have been working on an issue recently that has to do with ImagePattern not updating when it's image changes (ie an animated writable image/animated gif). >> >> I do not feel great about my current fix because it requrires some public api, which basically copy's how ImageView listens for changes. The shape asks if the Paint can change (paint.canIchange()) and then adding a listener that is forwarded to the imagepattern's image. When fired, the shape marks is fill dirty. Pretty straightforward, but since these are in separate packages, public API is created. >> >> Bottom line? Public API just to update an ImagePattern? Seems a bit of overkill. >> >> The Fundamental issue here is that in JavaFX, Paints are more or less considered immutable, (the cold hard truth is that sometimes they are not, like in the ImagePattern case), mutable paints have their own set of problems which one could argue is a snowballing scope for this particular issue =(. >> >> Because of this, a workaround can be done by the user assuming immutable paints to create a new imagePattern with the newly changed WritableImage, but again this is overkill. It seems to me like it "should just work". >> >> So we have 2 options: >> >> 1) ImagePattern is fundamentally immutable, and a copy of an image is taken at constructor time and you the user should construct new ImagePattern's if you want it to change. >> >> 2) ImagePattern is fundamentally mutable, and can notify its shape of changes, this requires that Paints have the notion of being mutable (color and gradient would return "not Mutable" when asked). >> >> Thoughts? >> -Joe >> >> >> From swpalmer at gmail.com Wed Dec 12 11:07:41 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 12 Dec 2012 14:07:41 -0500 Subject: WebStart Install Fail Message-ID: Recall the previous discussions about deployment... I just tried to start the JFXExtras 2 Ensemble application. I clicked the image to run it via web start. It downloaded and I saw a progress bar in a window titled "JavaFX Application Preview" and then the JRE 1.7.0_10 installer failed. "Unable to launch the application." Name: J2RE 1.7.0_10 Installer Publisher: Sun Microsystems, Inc. From: http://javadl.sun.com (Not from Oracle?) Details: java.lang.UnsatisfiedLinkError: C:\Users\scott.palmer\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\ext\E1355338521796\j2re-installer.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary1(Unknown Source) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.load0(Unknown Source) at java.lang.System.load(Unknown Source) at com.sun.webstart.installers.Main.install(Main.java:156) at com.sun.webstart.installers.Main.main(Main.java:554) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.sun.javaws.Launcher.executeApplication(Unknown Source) at com.sun.javaws.Launcher.executeMainClass(Unknown Source) at com.sun.javaws.Launcher.doLaunchApp(Unknown Source) at com.sun.javaws.Launcher.run(Unknown Source) at java.lang.Thread.run(Unknown Source) In other words... a pathetic user experience. I would have thought that the people behind the JFXExtras project are pretty competent developers. If they can't get the JFXExtras project deployment to work... Scott From tbee at tbee.org Wed Dec 12 11:17:54 2012 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 12 Dec 2012 20:17:54 +0100 Subject: WebStart Install Fail In-Reply-To: References: Message-ID: <50C8D862.6090908@tbee.org> And thank you for appreciating the spare time we put into this. You are welcome. Tom On 2012-12-12 20:07, Scott Palmer wrote: > Recall the previous discussions about deployment... > > I just tried to start the JFXExtras 2 Ensemble application. > > I clicked the image to run it via web start. > It downloaded and I saw a progress bar in a window titled "JavaFX > Application Preview" and then the JRE 1.7.0_10 installer failed. > "Unable to launch the application." > Name: J2RE 1.7.0_10 Installer > Publisher: Sun Microsystems, Inc. > From: http://javadl.sun.com > > (Not from Oracle?) > > Details: > java.lang.UnsatisfiedLinkError: > C:\Users\scott.palmer\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\ext\E1355338521796\j2re-installer.dll: > Can't load IA 32-bit .dll on a AMD 64-bit platform > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary1(Unknown Source) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.load0(Unknown Source) > at java.lang.System.load(Unknown Source) > at com.sun.webstart.installers.Main.install(Main.java:156) > at com.sun.webstart.installers.Main.main(Main.java:554) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at com.sun.javaws.Launcher.executeApplication(Unknown Source) > at com.sun.javaws.Launcher.executeMainClass(Unknown Source) > at com.sun.javaws.Launcher.doLaunchApp(Unknown Source) > at com.sun.javaws.Launcher.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) > > In other words... a pathetic user experience. > > I would have thought that the people behind the JFXExtras project are > pretty competent developers. If they can't get the JFXExtras project > deployment to work... > > > Scott From joe.mcglynn at oracle.com Wed Dec 12 11:20:25 2012 From: joe.mcglynn at oracle.com (Joe McGlynn) Date: Wed, 12 Dec 2012 11:20:25 -0800 Subject: WebStart Install Fail In-Reply-To: References: Message-ID: <9512906A-13C1-45F5-B9E6-D6A71A1DC673@oracle.com> Hi Scott, The publisher (signer) was changed to Sun for this release intentionally due to problems in the past with the JRE autoupdate on Win 32, so that's expected. Can you file a bug on this please with the details on your platform (OS, pre-existing JRE, etc?) I just tried this and it works as expected on my system that already has 7u10 installed. On Dec 12, 2012, at 11:07 AM, Scott Palmer wrote: > Recall the previous discussions about deployment... > > I just tried to start the JFXExtras 2 Ensemble application. > > I clicked the image to run it via web start. > It downloaded and I saw a progress bar in a window titled "JavaFX > Application Preview" and then the JRE 1.7.0_10 installer failed. > "Unable to launch the application." > Name: J2RE 1.7.0_10 Installer > Publisher: Sun Microsystems, Inc. > From: http://javadl.sun.com > > (Not from Oracle?) > > Details: > java.lang.UnsatisfiedLinkError: > C:\Users\scott.palmer\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\ext\E1355338521796\j2re-installer.dll: > Can't load IA 32-bit .dll on a AMD 64-bit platform > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary1(Unknown Source) > at java.lang.ClassLoader.loadLibrary0(Unknown Source) > at java.lang.ClassLoader.loadLibrary(Unknown Source) > at java.lang.Runtime.load0(Unknown Source) > at java.lang.System.load(Unknown Source) > at com.sun.webstart.installers.Main.install(Main.java:156) > at com.sun.webstart.installers.Main.main(Main.java:554) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at com.sun.javaws.Launcher.executeApplication(Unknown Source) > at com.sun.javaws.Launcher.executeMainClass(Unknown Source) > at com.sun.javaws.Launcher.doLaunchApp(Unknown Source) > at com.sun.javaws.Launcher.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) > > In other words... a pathetic user experience. > > I would have thought that the people behind the JFXExtras project are > pretty competent developers. If they can't get the JFXExtras project > deployment to work... > > > Scott From swpalmer at gmail.com Wed Dec 12 11:26:51 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 12 Dec 2012 14:26:51 -0500 Subject: WebStart Install Fail In-Reply-To: <9512906A-13C1-45F5-B9E6-D6A71A1DC673@oracle.com> References: <9512906A-13C1-45F5-B9E6-D6A71A1DC673@oracle.com> Message-ID: <0894332B-1521-4C18-BEED-C30C778E4B69@gmail.com> Would you like it filed in the JavaFX Jira or the Java Bug Reporter? I wasn't sure if this was specific to the JavaFX deployment toolchain or not. Scott On 2012-12-12, at 2:20 PM, Joe McGlynn wrote: > Hi Scott, > > The publisher (signer) was changed to Sun for this release intentionally due to problems in the past with the JRE autoupdate on Win 32, so that's expected. > > Can you file a bug on this please with the details on your platform (OS, pre-existing JRE, etc?) > > I just tried this and it works as expected on my system that already has 7u10 installed. > > > > On Dec 12, 2012, at 11:07 AM, Scott Palmer wrote: > >> Recall the previous discussions about deployment... >> >> I just tried to start the JFXExtras 2 Ensemble application. >> >> I clicked the image to run it via web start. >> It downloaded and I saw a progress bar in a window titled "JavaFX >> Application Preview" and then the JRE 1.7.0_10 installer failed. >> "Unable to launch the application." >> Name: J2RE 1.7.0_10 Installer >> Publisher: Sun Microsystems, Inc. >> From: http://javadl.sun.com >> >> (Not from Oracle?) >> >> Details: >> java.lang.UnsatisfiedLinkError: >> C:\Users\scott.palmer\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\ext\E1355338521796\j2re-installer.dll: >> Can't load IA 32-bit .dll on a AMD 64-bit platform >> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >> at java.lang.ClassLoader.loadLibrary1(Unknown Source) >> at java.lang.ClassLoader.loadLibrary0(Unknown Source) >> at java.lang.ClassLoader.loadLibrary(Unknown Source) >> at java.lang.Runtime.load0(Unknown Source) >> at java.lang.System.load(Unknown Source) >> at com.sun.webstart.installers.Main.install(Main.java:156) >> at com.sun.webstart.installers.Main.main(Main.java:554) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) >> at java.lang.reflect.Method.invoke(Unknown Source) >> at com.sun.javaws.Launcher.executeApplication(Unknown Source) >> at com.sun.javaws.Launcher.executeMainClass(Unknown Source) >> at com.sun.javaws.Launcher.doLaunchApp(Unknown Source) >> at com.sun.javaws.Launcher.run(Unknown Source) >> at java.lang.Thread.run(Unknown Source) >> >> In other words... a pathetic user experience. >> >> I would have thought that the people behind the JFXExtras project are >> pretty competent developers. If they can't get the JFXExtras project >> deployment to work... >> >> >> Scott > From joe.mcglynn at oracle.com Wed Dec 12 11:42:23 2012 From: joe.mcglynn at oracle.com (Joe McGlynn) Date: Wed, 12 Dec 2012 11:42:23 -0800 Subject: WebStart Install Fail In-Reply-To: <0894332B-1521-4C18-BEED-C30C778E4B69@gmail.com> References: <9512906A-13C1-45F5-B9E6-D6A71A1DC673@oracle.com> <0894332B-1521-4C18-BEED-C30C778E4B69@gmail.com> Message-ID: FX Jira is fine. Thanks. -- On Dec 12, 2012, at 11:26 AM, Scott Palmer wrote: > Would you like it filed in the JavaFX Jira or the Java Bug Reporter? I wasn't sure if this was specific to the JavaFX deployment toolchain or not. > > Scott > > On 2012-12-12, at 2:20 PM, Joe McGlynn wrote: > >> Hi Scott, >> >> The publisher (signer) was changed to Sun for this release intentionally due to problems in the past with the JRE autoupdate on Win 32, so that's expected. >> >> Can you file a bug on this please with the details on your platform (OS, pre-existing JRE, etc?) >> >> I just tried this and it works as expected on my system that already has 7u10 installed. >> >> >> >> On Dec 12, 2012, at 11:07 AM, Scott Palmer wrote: >> >>> Recall the previous discussions about deployment... >>> >>> I just tried to start the JFXExtras 2 Ensemble application. >>> >>> I clicked the image to run it via web start. >>> It downloaded and I saw a progress bar in a window titled "JavaFX >>> Application Preview" and then the JRE 1.7.0_10 installer failed. >>> "Unable to launch the application." >>> Name: J2RE 1.7.0_10 Installer >>> Publisher: Sun Microsystems, Inc. >>> From: http://javadl.sun.com >>> >>> (Not from Oracle?) >>> >>> Details: >>> java.lang.UnsatisfiedLinkError: >>> C:\Users\scott.palmer\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\ext\E1355338521796\j2re-installer.dll: >>> Can't load IA 32-bit .dll on a AMD 64-bit platform >>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>> at java.lang.ClassLoader.loadLibrary1(Unknown Source) >>> at java.lang.ClassLoader.loadLibrary0(Unknown Source) >>> at java.lang.ClassLoader.loadLibrary(Unknown Source) >>> at java.lang.Runtime.load0(Unknown Source) >>> at java.lang.System.load(Unknown Source) >>> at com.sun.webstart.installers.Main.install(Main.java:156) >>> at com.sun.webstart.installers.Main.main(Main.java:554) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) >>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) >>> at java.lang.reflect.Method.invoke(Unknown Source) >>> at com.sun.javaws.Launcher.executeApplication(Unknown Source) >>> at com.sun.javaws.Launcher.executeMainClass(Unknown Source) >>> at com.sun.javaws.Launcher.doLaunchApp(Unknown Source) >>> at com.sun.javaws.Launcher.run(Unknown Source) >>> at java.lang.Thread.run(Unknown Source) >>> >>> In other words... a pathetic user experience. >>> >>> I would have thought that the people behind the JFXExtras project are >>> pretty competent developers. If they can't get the JFXExtras project >>> deployment to work... >>> >>> >>> Scott >> > From tbee at tbee.org Wed Dec 12 11:51:06 2012 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 12 Dec 2012 20:51:06 +0100 Subject: WebStart Install Fail In-Reply-To: <50C8D862.6090908@tbee.org> References: <50C8D862.6090908@tbee.org> Message-ID: <50C8E02A.4020104@tbee.org> Maybe that was overreacting, but I stumbled over the word "pathetic". On 2012-12-12 20:17, Tom Eugelink wrote: > And thank you for appreciating the spare time we put into this. You are welcome. From richard.bair at oracle.com Wed Dec 12 12:00:41 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 12 Dec 2012 12:00:41 -0800 Subject: WebStart Install Fail In-Reply-To: <50C8E02A.4020104@tbee.org> References: <50C8D862.6090908@tbee.org> <50C8E02A.4020104@tbee.org> Message-ID: <7ABB4CEE-3C25-4852-9CF8-04D085B24B41@oracle.com> Ya, that was aimed at us not you ;-) On Dec 12, 2012, at 11:51 AM, Tom Eugelink wrote: > Maybe that was overreacting, but I stumbled over the word "pathetic". > > On 2012-12-12 20:17, Tom Eugelink wrote: >> And thank you for appreciating the spare time we put into this. You are welcome. > From zonski at gmail.com Wed Dec 12 12:18:38 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Thu, 13 Dec 2012 07:18:38 +1100 Subject: ImagePattern, WritableImage, and Shapes In-Reply-To: <50C8CB64.6030409@oracle.com> References: <50C7B119.30506@oracle.com> <50C8CB64.6030409@oracle.com> Message-ID: <7C5BCEA1-B7FC-4E33-905A-1F592623A2DC@gmail.com> Is there a reason not to do something simple/normal like: interface MutablePaint { void setOnChanged(ActionEvent) // or whatever } Implemented by ImagePattern and not Color and Gradient. I know it's an interface but in this case I don't think the usual backwards compatability problems are overly relevant. It's not really a 'thing', just a marker interface. Having a no-op method is a less honest API to having the method not available at all (adding a Boolean isMutable is only slightly more honest). More just curious than anything. On 13/12/2012, at 5:22 AM, joe andresen wrote: > I definitely think ImagePattern is better off being acknowledged as mutable, I'll think about what I can do to my current change in regards to public api. > > -J > > On 12/11/2012 5:19 PM, Richard Bair wrote: >> It seems to me that we ought to allow the ImagePattern to be a mutable paint. Maybe we don't even need to have an "isMutable" method, but just have the "addPaintChangeListener" method that takes a runnable (or something, maybe an event! Seems heavy) and then just have them be no-ops on the mutable paints and document that they are no-ops because the paints never change, and then have it implemented on the ImagePattern. >> >> What do you think? >> Richard >> >> On Dec 11, 2012, at 2:18 PM, Joe Andresen wrote: >> >>> Hey Fellow JFXers! >>> >>> I have been working on an issue recently that has to do with ImagePattern not updating when it's image changes (ie an animated writable image/animated gif). >>> >>> I do not feel great about my current fix because it requrires some public api, which basically copy's how ImageView listens for changes. The shape asks if the Paint can change (paint.canIchange()) and then adding a listener that is forwarded to the imagepattern's image. When fired, the shape marks is fill dirty. Pretty straightforward, but since these are in separate packages, public API is created. >>> >>> Bottom line? Public API just to update an ImagePattern? Seems a bit of overkill. >>> >>> The Fundamental issue here is that in JavaFX, Paints are more or less considered immutable, (the cold hard truth is that sometimes they are not, like in the ImagePattern case), mutable paints have their own set of problems which one could argue is a snowballing scope for this particular issue =(. >>> >>> Because of this, a workaround can be done by the user assuming immutable paints to create a new imagePattern with the newly changed WritableImage, but again this is overkill. It seems to me like it "should just work". >>> >>> So we have 2 options: >>> >>> 1) ImagePattern is fundamentally immutable, and a copy of an image is taken at constructor time and you the user should construct new ImagePattern's if you want it to change. >>> >>> 2) ImagePattern is fundamentally mutable, and can notify its shape of changes, this requires that Paints have the notion of being mutable (color and gradient would return "not Mutable" when asked). >>> >>> Thoughts? >>> -Joe >>> >>> >>> > From richard.bair at oracle.com Wed Dec 12 12:23:44 2012 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 12 Dec 2012 12:23:44 -0800 Subject: ImagePattern, WritableImage, and Shapes In-Reply-To: <7C5BCEA1-B7FC-4E33-905A-1F592623A2DC@gmail.com> References: <50C7B119.30506@oracle.com> <50C8CB64.6030409@oracle.com> <7C5BCEA1-B7FC-4E33-905A-1F592623A2DC@gmail.com> Message-ID: <57AD9D01-88AF-4AED-8880-D8BD066E0421@oracle.com> In this case, my only reason for not suggesting the interface (which I certainly thought about) was that it was an additional class. Is it really paying its weight? On Dec 12, 2012, at 12:18 PM, Daniel Zwolenski wrote: > Is there a reason not to do something simple/normal like: > > interface MutablePaint { > void setOnChanged(ActionEvent) // or whatever > } > > Implemented by ImagePattern and not Color and Gradient. > > I know it's an interface but in this case I don't think the usual backwards compatability problems are overly relevant. It's not really a 'thing', just a marker interface. > > Having a no-op method is a less honest API to having the method not available at all (adding a Boolean isMutable is only slightly more honest). > > More just curious than anything. > > > > On 13/12/2012, at 5:22 AM, joe andresen wrote: > >> I definitely think ImagePattern is better off being acknowledged as mutable, I'll think about what I can do to my current change in regards to public api. >> >> -J >> >> On 12/11/2012 5:19 PM, Richard Bair wrote: >>> It seems to me that we ought to allow the ImagePattern to be a mutable paint. Maybe we don't even need to have an "isMutable" method, but just have the "addPaintChangeListener" method that takes a runnable (or something, maybe an event! Seems heavy) and then just have them be no-ops on the mutable paints and document that they are no-ops because the paints never change, and then have it implemented on the ImagePattern. >>> >>> What do you think? >>> Richard >>> >>> On Dec 11, 2012, at 2:18 PM, Joe Andresen wrote: >>> >>>> Hey Fellow JFXers! >>>> >>>> I have been working on an issue recently that has to do with ImagePattern not updating when it's image changes (ie an animated writable image/animated gif). >>>> >>>> I do not feel great about my current fix because it requrires some public api, which basically copy's how ImageView listens for changes. The shape asks if the Paint can change (paint.canIchange()) and then adding a listener that is forwarded to the imagepattern's image. When fired, the shape marks is fill dirty. Pretty straightforward, but since these are in separate packages, public API is created. >>>> >>>> Bottom line? Public API just to update an ImagePattern? Seems a bit of overkill. >>>> >>>> The Fundamental issue here is that in JavaFX, Paints are more or less considered immutable, (the cold hard truth is that sometimes they are not, like in the ImagePattern case), mutable paints have their own set of problems which one could argue is a snowballing scope for this particular issue =(. >>>> >>>> Because of this, a workaround can be done by the user assuming immutable paints to create a new imagePattern with the newly changed WritableImage, but again this is overkill. It seems to me like it "should just work". >>>> >>>> So we have 2 options: >>>> >>>> 1) ImagePattern is fundamentally immutable, and a copy of an image is taken at constructor time and you the user should construct new ImagePattern's if you want it to change. >>>> >>>> 2) ImagePattern is fundamentally mutable, and can notify its shape of changes, this requires that Paints have the notion of being mutable (color and gradient would return "not Mutable" when asked). >>>> >>>> Thoughts? >>>> -Joe >>>> >>>> >>>> >> From zonski at gmail.com Wed Dec 12 12:39:41 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Thu, 13 Dec 2012 07:39:41 +1100 Subject: WebStart Install Fail In-Reply-To: <7ABB4CEE-3C25-4852-9CF8-04D085B24B41@oracle.com> References: <50C8D862.6090908@tbee.org> <50C8E02A.4020104@tbee.org> <7ABB4CEE-3C25-4852-9CF8-04D085B24B41@oracle.com> Message-ID: <2F53FA00-C034-4921-9D1F-40F23C4F9C7E@gmail.com> Definitely this is a JFX issue and I don't believe there is anything Xtras could do even if they wanted (apart from write their own webstart browser plugin). I have seen this many times. It is one of 3 reasons why I keep saying jnlp doesn't work (the other being the user-off-putting steps of installing Java even when it works; and the forced jre auto-updating that can break your app at any time after release without the developer changing a thing). Igor was aware of this problem (and I think there should be a jira in there somewhere) but since he's gone the rough gist of what he said was happening is that many browsers are still 32bit even if you are running on a 64bit OS. You end up with the browser somehow getting a mix of 64bit and 32bit JREs installed/JFX's installed. Hence the error (eg running 64bit jfx on a 32bit jre or the inverse). The "fix" generally was "once browsers all go to 64bit it won't be a problem" - I'd be inclined to allow the "pathetic" adjective at this point. As an aside, I did notice recently when hacking at the installer package code that regardless of what OS you are on the jnlp gets a 32bit win fallback URL for jfx. In theory if it finds the jre but not jfx then it is suppose to use this URL. This may or may not be related - I only see the packager code that generates the jnlp not the actual plugin code that acts on it. Have I ever mentioned that deployment in jfx sucks ;) On 13/12/2012, at 7:00 AM, Richard Bair wrote: > Ya, that was aimed at us not you ;-) > > On Dec 12, 2012, at 11:51 AM, Tom Eugelink wrote: > >> Maybe that was overreacting, but I stumbled over the word "pathetic". >> >> On 2012-12-12 20:17, Tom Eugelink wrote: >>> And thank you for appreciating the spare time we put into this. You are welcome. >> > From hang.vo at oracle.com Wed Dec 12 13:18:12 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 12 Dec 2012 21:18:12 +0000 Subject: hg: openjfx/8/graphics/rt: [DOC ONLY] Fix for RT-23885. Message-ID: <20121212211817.285F8470D9@hg.openjdk.java.net> Changeset: 93e290f79d5c Author: rbair Date: 2012-12-12 13:15 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/93e290f79d5c [DOC ONLY] Fix for RT-23885. ! javafx-ui-common/src/javafx/scene/layout/Region.java From zonski at gmail.com Wed Dec 12 13:38:46 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Thu, 13 Dec 2012 08:38:46 +1100 Subject: ImagePattern, WritableImage, and Shapes In-Reply-To: <57AD9D01-88AF-4AED-8880-D8BD066E0421@oracle.com> References: <50C7B119.30506@oracle.com> <50C8CB64.6030409@oracle.com> <7C5BCEA1-B7FC-4E33-905A-1F592623A2DC@gmail.com> <57AD9D01-88AF-4AED-8880-D8BD066E0421@oracle.com> Message-ID: The more type safe / explicit API would justify it for me as developers are stopped from doing something dumb at compile time instead of runtime (same reason I like java and not scripting languages) but then maybe in the context of a core API (as opposed to an app) the drivers are different. Good to know the reasons in any case, cheers. On 13/12/2012, at 7:23 AM, Richard Bair wrote: > In this case, my only reason for not suggesting the interface (which I certainly thought about) was that it was an additional class. Is it really paying its weight? > > On Dec 12, 2012, at 12:18 PM, Daniel Zwolenski wrote: > >> Is there a reason not to do something simple/normal like: >> >> interface MutablePaint { >> void setOnChanged(ActionEvent) // or whatever >> } >> >> Implemented by ImagePattern and not Color and Gradient. >> >> I know it's an interface but in this case I don't think the usual backwards compatability problems are overly relevant. It's not really a 'thing', just a marker interface. >> >> Having a no-op method is a less honest API to having the method not available at all (adding a Boolean isMutable is only slightly more honest). >> >> More just curious than anything. >> >> >> >> On 13/12/2012, at 5:22 AM, joe andresen wrote: >> >>> I definitely think ImagePattern is better off being acknowledged as mutable, I'll think about what I can do to my current change in regards to public api. >>> >>> -J >>> >>> On 12/11/2012 5:19 PM, Richard Bair wrote: >>>> It seems to me that we ought to allow the ImagePattern to be a mutable paint. Maybe we don't even need to have an "isMutable" method, but just have the "addPaintChangeListener" method that takes a runnable (or something, maybe an event! Seems heavy) and then just have them be no-ops on the mutable paints and document that they are no-ops because the paints never change, and then have it implemented on the ImagePattern. >>>> >>>> What do you think? >>>> Richard >>>> >>>> On Dec 11, 2012, at 2:18 PM, Joe Andresen wrote: >>>> >>>>> Hey Fellow JFXers! >>>>> >>>>> I have been working on an issue recently that has to do with ImagePattern not updating when it's image changes (ie an animated writable image/animated gif). >>>>> >>>>> I do not feel great about my current fix because it requrires some public api, which basically copy's how ImageView listens for changes. The shape asks if the Paint can change (paint.canIchange()) and then adding a listener that is forwarded to the imagepattern's image. When fired, the shape marks is fill dirty. Pretty straightforward, but since these are in separate packages, public API is created. >>>>> >>>>> Bottom line? Public API just to update an ImagePattern? Seems a bit of overkill. >>>>> >>>>> The Fundamental issue here is that in JavaFX, Paints are more or less considered immutable, (the cold hard truth is that sometimes they are not, like in the ImagePattern case), mutable paints have their own set of problems which one could argue is a snowballing scope for this particular issue =(. >>>>> >>>>> Because of this, a workaround can be done by the user assuming immutable paints to create a new imagePattern with the newly changed WritableImage, but again this is overkill. It seems to me like it "should just work". >>>>> >>>>> So we have 2 options: >>>>> >>>>> 1) ImagePattern is fundamentally immutable, and a copy of an image is taken at constructor time and you the user should construct new ImagePattern's if you want it to change. >>>>> >>>>> 2) ImagePattern is fundamentally mutable, and can notify its shape of changes, this requires that Paints have the notion of being mutable (color and gradient would return "not Mutable" when asked). >>>>> >>>>> Thoughts? >>>>> -Joe >>>>> >>>>> >>>>> >>> > From John_Smith at symantec.com Wed Dec 12 13:40:57 2012 From: John_Smith at symantec.com (John Smith) Date: Wed, 12 Dec 2012 13:40:57 -0800 Subject: WebStart Install Fail In-Reply-To: <2F53FA00-C034-4921-9D1F-40F23C4F9C7E@gmail.com> References: <50C8D862.6090908@tbee.org> <50C8E02A.4020104@tbee.org> <7ABB4CEE-3C25-4852-9CF8-04D085B24B41@oracle.com> <2F53FA00-C034-4921-9D1F-40F23C4F9C7E@gmail.com> Message-ID: <411E73D23DEC4C46BA48F2B6D8BF3D22160B36CE91@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> I don't think this particular issue had anything to do with the browser being used or a browser plugin. The jfxtras deployment is just an html link to a jnlp file (no use of the deployment toolkit javascript or embedded in the html page which could cause a native browser plugin to be used). Due to windows file associations set from a previous jre install, when the link is clicked, it will run the web start launcher, from thereon it goes awry in Scott's environment. Clicking on the same link works fine for me (Win7+jre7u9) and I can use the excellent jfxtras demo app, but that's not surprising as I have the 32 bit jre installed already. -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel Zwolenski Sent: Wednesday, December 12, 2012 12:40 PM To: Richard Bair Cc: openjfx-dev at openjdk.java.net Subject: Re: WebStart Install Fail Definitely this is a JFX issue and I don't believe there is anything Xtras could do even if they wanted (apart from write their own webstart browser plugin). I have seen this many times. It is one of 3 reasons why I keep saying jnlp doesn't work (the other being the user-off-putting steps of installing Java even when it works; and the forced jre auto-updating that can break your app at any time after release without the developer changing a thing). Igor was aware of this problem (and I think there should be a jira in there somewhere) but since he's gone the rough gist of what he said was happening is that many browsers are still 32bit even if you are running on a 64bit OS. You end up with the browser somehow getting a mix of 64bit and 32bit JREs installed/JFX's installed. Hence the error (eg running 64bit jfx on a 32bit jre or the inverse). The "fix" generally was "once browsers all go to 64bit it won't be a problem" - I'd be inclined to allow the "pathetic" adjective at this point. As an aside, I did notice recently when hacking at the installer package code that regardless of what OS you are on the jnlp gets a 32bit win fallback URL for jfx. In theory if it finds the jre but not jfx then it is suppose to use this URL. This may or may not be related - I only see the packager code that generates the jnlp not the actual plugin code that acts on it. Have I ever mentioned that deployment in jfx sucks ;) From hang.vo at oracle.com Wed Dec 12 14:03:49 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 12 Dec 2012 22:03:49 +0000 Subject: hg: openjfx/8/graphics/rt: [DOC ONLY] Fix for RT-26282. Message-ID: <20121212220350.80758470E2@hg.openjdk.java.net> Changeset: da67687c545b Author: rbair Date: 2012-12-12 13:52 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/da67687c545b [DOC ONLY] Fix for RT-26282. ! javafx-ui-common/src/javafx/scene/layout/BorderImage.java From hang.vo at oracle.com Wed Dec 12 14:48:18 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 12 Dec 2012 22:48:18 +0000 Subject: hg: openjfx/8/controls/rt: fix RT-26845 PieChart.Data's changed name is not reflected in the Legend or PieLabel + unit test. Message-ID: <20121212224820.4844F470EE@hg.openjdk.java.net> Changeset: d20210a6c862 Author: Paru Somashekar Date: 2012-12-12 14:50 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d20210a6c862 fix RT-26845 PieChart.Data's changed name is not reflected in the Legend or PieLabel + unit test. ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java ! javafx-ui-charts/test/javafx/scene/chart/PieChartTest.java From pedro.duquevieira at gmail.com Wed Dec 12 15:11:11 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 12 Dec 2012 23:11:11 +0000 Subject: Need way to define width and height in CSS In-Reply-To: References: Message-ID: Just a reminder on this issue (below)... On Tue, Dec 11, 2012 at 11:50 PM, Pedro Duque Vieira < pedro.duquevieira at gmail.com> wrote: > Hi, > > After some practice writing JavaFX CSS one thing as become clear: a way > to clearly define a width and a height is lacking. > In standard w3c css you have width and height, on JavaFX CSS you have > padding - look at the way the size of the mark on a checkbox is defined in > caspian. Padding isn't the nicest way to define this because it is supposed > to define the spacing between an element and it's contents. > > Cheers, > > -- > Pedro Duque Vieira > -- Pedro Duque Vieira From swpalmer at gmail.com Wed Dec 12 16:13:16 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 12 Dec 2012 19:13:16 -0500 Subject: WebStart Install Fail In-Reply-To: <411E73D23DEC4C46BA48F2B6D8BF3D22160B36CE91@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> References: <50C8D862.6090908@tbee.org> <50C8E02A.4020104@tbee.org> <7ABB4CEE-3C25-4852-9CF8-04D085B24B41@oracle.com> <2F53FA00-C034-4921-9D1F-40F23C4F9C7E@gmail.com> <411E73D23DEC4C46BA48F2B6D8BF3D22160B36CE91@TUS1XCHEVSPIN34.SYMC.SYMANTEC.COM> Message-ID: I had 7u10-b18 32-bit already installed when this failed. The fix was to manually install the 64-bit-bit JRE. Filed RT-26964 without using the word pathetic - that was directed towards the situation not any people, sorry for that. I think we can all agree that it was not a good user experience. I can think of only one "weird" thing about my environment that might have triggered this. I had 32-bit 7u10 installed AND I made sure that the 32-bit java.exe was copied into the Windows System32 directory instead of a 64-bit java.exe. Normally on 64-bit windows the 32-bit java.exe isn't copied there, but the 64-bit version is. As we use a lot of 32-bit JNI DLLs the 64-bit java.exe being on the path ahead o 32-bit java causes all sorts of frustration during development. I'm going to uninstall 64-bit 7u10 now and see if I can reproduce the problem again. It happened consistently before installing the 64-bit JRE. Regards, Scott On Wed, Dec 12, 2012 at 4:40 PM, John Smith wrote: > I don't think this particular issue had anything to do with the browser > being used or a browser plugin. > The jfxtras deployment is just an html link to a jnlp file (no use of the > deployment toolkit javascript or embedded in the html page which could > cause a native browser plugin to be used). > Due to windows file associations set from a previous jre install, when the > link is clicked, it will run the web start launcher, from thereon it goes > awry in Scott's environment. > Clicking on the same link works fine for me (Win7+jre7u9) and I can use > the excellent jfxtras demo app, but that's not surprising as I have the 32 > bit jre installed already. > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net [mailto: > openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel Zwolenski > Sent: Wednesday, December 12, 2012 12:40 PM > To: Richard Bair > Cc: openjfx-dev at openjdk.java.net > Subject: Re: WebStart Install Fail > > Definitely this is a JFX issue and I don't believe there is anything Xtras > could do even if they wanted (apart from write their own webstart browser > plugin). > > I have seen this many times. It is one of 3 reasons why I keep saying jnlp > doesn't work (the other being the user-off-putting steps of installing Java > even when it works; and the forced jre auto-updating that can break your > app at any time after release without the developer changing a thing). > > Igor was aware of this problem (and I think there should be a jira in > there somewhere) but since he's gone the rough gist of what he said was > happening is that many browsers are still 32bit even if you are running on > a 64bit OS. You end up with the browser somehow getting a mix of 64bit and > 32bit JREs installed/JFX's installed. Hence the error (eg running 64bit jfx > on a 32bit jre or the inverse). The "fix" generally was "once browsers all > go to 64bit it won't be a problem" - I'd be inclined to allow the > "pathetic" adjective at this point. > > As an aside, I did notice recently when hacking at the installer package > code that regardless of what OS you are on the jnlp gets a 32bit win > fallback URL for jfx. In theory if it finds the jre but not jfx then it is > suppose to use this URL. This may or may not be related - I only see the > packager code that generates the jnlp not the actual plugin code that acts > on it. > > Have I ever mentioned that deployment in jfx sucks ;) > From hang.vo at oracle.com Wed Dec 12 17:33:53 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 13 Dec 2012 01:33:53 +0000 Subject: hg: openjfx/8/graphics/rt: Fixed RT-26968:TabPane with floating styleclass, content overdraws rounded corners Message-ID: <20121213013356.172EF470F3@hg.openjdk.java.net> Changeset: 7af6bad1fda3 Author: "Jasper Potts" Date: 2012-12-12 17:26 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7af6bad1fda3 Fixed RT-26968:TabPane with floating styleclass, content overdraws rounded corners ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css From hang.vo at oracle.com Wed Dec 12 17:55:47 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 13 Dec 2012 01:55:47 +0000 Subject: hg: openjfx/2.2.6/master/rt: 5 new changesets Message-ID: <20121213015552.DC43F470F4@hg.openjdk.java.net> Changeset: 0f987c50cd0f Author: David Grieve Date: 2012-12-06 13:16 -0500 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/0f987c50cd0f RT-24606: backport fix from 8.0 ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java + javafx-ui-common/test/unit/com/sun/javafx/css/StyleTest.java Changeset: fd9fd56f3be9 Author: David Grieve Date: 2012-12-06 13:34 -0500 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/fd9fd56f3be9 RT-24598: backport patch from 8.0 ! javafx-ui-common/src/com/sun/javafx/css/Declaration.java + javafx-ui-common/test/unit/com/sun/javafx/css/DeclarationTest.java Changeset: d95501d73070 Author: David Grieve Date: 2012-12-06 15:54 -0500 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/d95501d73070 RT-25016: backport from 8.0 ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: 6feb25f693a2 Author: kcr Date: 2012-12-11 15:03 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/6feb25f693a2 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.6/MASTER/jfx/rt Changeset: 096f6f6dcf27 Author: hudson Date: 2012-12-12 15:12 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/096f6f6dcf27 Added tag 2.2.6-b05 for changeset 6feb25f693a2 ! .hgtags From tbee at tbee.org Wed Dec 12 22:17:10 2012 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 13 Dec 2012 07:17:10 +0100 Subject: WebStart Install Fail In-Reply-To: <7ABB4CEE-3C25-4852-9CF8-04D085B24B41@oracle.com> References: <50C8D862.6090908@tbee.org> <50C8E02A.4020104@tbee.org> <7ABB4CEE-3C25-4852-9CF8-04D085B24B41@oracle.com> Message-ID: <50C972E6.4080600@tbee.org> Yeah. But since I'm the one maintaining the JFXtras JNLP file, I felt addresses. Apologies & continue. On 2012-12-12 21:00, Richard Bair wrote: > Ya, that was aimed at us not you ;-) > > On Dec 12, 2012, at 11:51 AM, Tom Eugelink wrote: > >> Maybe that was overreacting, but I stumbled over the word "pathetic". >> >> On 2012-12-12 20:17, Tom Eugelink wrote: >>> And thank you for appreciating the spare time we put into this. You are welcome. From randahl at rockit.dk Wed Dec 12 23:31:14 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Thu, 13 Dec 2012 08:31:14 +0100 Subject: Need way to define width and height in CSS In-Reply-To: References: Message-ID: <2125E356-2496-4475-AE56-09A8DFE07BBC@rockit.dk> Hi Pedro I thought so too at first. But I actually managed to build a whole application without it. But I agree that sometimes this would be useful. I think you should do some Jira searches, because as I recall this has been suggested before, and reading what the response was will probably be helpful and give you an indication on whether to raise the issue again. Randahl On Dec 12, 2012, at 0:50 , Pedro Duque Vieira wrote: > Hi, > > After some practice writing JavaFX CSS one thing as become clear: a way to > clearly define a width and a height is lacking. > In standard w3c css you have width and height, on JavaFX CSS you have > padding - look at the way the size of the mark on a checkbox is defined in > caspian. Padding isn't the nicest way to define this because it is supposed > to define the spacing between an element and it's contents. > > Cheers, > > -- > Pedro Duque Vieira From tom.schindl at bestsolution.at Thu Dec 13 00:23:24 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 13 Dec 2012 09:23:24 +0100 Subject: Need way to define width and height in CSS In-Reply-To: References: Message-ID: <50C9907C.4030709@bestsolution.at> You are talking about prefHeight and preWidth only right, because the real height and width is always overruled by the layout-container, right? Tom Am 13.12.12 00:11, schrieb Pedro Duque Vieira: > Just a reminder on this issue (below)... > > On Tue, Dec 11, 2012 at 11:50 PM, Pedro Duque Vieira < > pedro.duquevieira at gmail.com> wrote: > >> Hi, >> >> After some practice writing JavaFX CSS one thing as become clear: a way >> to clearly define a width and a height is lacking. >> In standard w3c css you have width and height, on JavaFX CSS you have >> padding - look at the way the size of the mark on a checkbox is defined in >> caspian. Padding isn't the nicest way to define this because it is supposed >> to define the spacing between an element and it's contents. >> >> Cheers, >> >> -- >> Pedro Duque Vieira >> > > > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From pedro.duquevieira at gmail.com Thu Dec 13 03:37:49 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Thu, 13 Dec 2012 11:37:49 +0000 Subject: Need way to define width and height in CSS In-Reply-To: <2125E356-2496-4475-AE56-09A8DFE07BBC@rockit.dk> References: <2125E356-2496-4475-AE56-09A8DFE07BBC@rockit.dk> Message-ID: Hi Randahl, :-) I don't mean you can't do things without this. What I meant is that it's not the best way to do it, as well as it is not in accordance with w3c css. And what if you wan't to define a width and a padding? I think I also recall someone: tbee? mention something about defining width through css, but as I remember there was no reaction. Besides creating a new jira issue I would also like to know the reasons behind this and try to alert the javafx community for this. It's not that big a deal, but I think it's still a detail that would deserve some attention. IMHO JavaFX CSS as a bunch of small details like this, that together make up a considerable problem. Thanks, best regards, On Thu, Dec 13, 2012 at 7:31 AM, Randahl Fink Isaksen wrote: > Hi Pedro > > I thought so too at first. But I actually managed to build a whole > application without it. But I agree that sometimes this would be useful. I > think you should do some Jira searches, because as I recall this has been > suggested before, and reading what the response was will probably be > helpful and give you an indication on whether to raise the issue again. > > Randahl > > > On Dec 12, 2012, at 0:50 , Pedro Duque Vieira > wrote: > > > Hi, > > > > After some practice writing JavaFX CSS one thing as become clear: a way > to > > clearly define a width and a height is lacking. > > In standard w3c css you have width and height, on JavaFX CSS you have > > padding - look at the way the size of the mark on a checkbox is defined > in > > caspian. Padding isn't the nicest way to define this because it is > supposed > > to define the spacing between an element and it's contents. > > > > Cheers, > > > > -- > > Pedro Duque Vieira > > -- Pedro Duque Vieira From pedro.duquevieira at gmail.com Thu Dec 13 03:55:30 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Thu, 13 Dec 2012 11:55:30 +0000 Subject: Need way to define width and height in CSS Message-ID: @Tom Schindl Yes. It might also be nice to have a way to define the maxHeight, maxWidth, minWidth, minHeight too. You are talking about prefHeight and preWidth only right, because the > real height and width is always overruled by the layout-container, right? > Tom -- Pedro Duque Vieira From hang.vo at oracle.com Thu Dec 13 07:48:42 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 13 Dec 2012 15:48:42 +0000 Subject: hg: openjfx/8/controls/rt: RT-22980 : Focus Stack for 2D traversal. Message-ID: <20121213154847.D92A34710F@hg.openjdk.java.net> Changeset: 64c4f32231ed Author: mickf Date: 2012-12-13 15:39 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/64c4f32231ed RT-22980 : Focus Stack for 2D traversal. + javafx-ui-common/src/com/sun/javafx/scene/traversal/Hueristic2D.java ! javafx-ui-common/src/com/sun/javafx/scene/traversal/TraversalEngine.java ! javafx-ui-common/src/com/sun/javafx/scene/traversal/WeightedClosestCorner.java From david.grieve at oracle.com Thu Dec 13 08:29:19 2012 From: david.grieve at oracle.com (David Grieve) Date: Thu, 13 Dec 2012 11:29:19 -0500 Subject: [REVIEW-REQUEST] RT-21709 Consider making available the CSS Styleable* classes as public API In-Reply-To: <8927902E-376B-40C1-BC9F-40086D0CFE7A@oracle.com> References: <8927902E-376B-40C1-BC9F-40086D0CFE7A@oracle.com> Message-ID: <174CE932-7F2E-4AB3-AC32-ABAA814F69D2@oracle.com> I've updated the proposal on the wiki, making it a little more complete and hopefully making it easier to digest. Please review! On Dec 6, 2012, at 10:17 AM, David Grieve wrote: > Relative to http://javafx-jira.kenai.com/browse/RT-21709, I have posted a proposed CSS API to support the development of custom UI Controls. The proposal covers the API needed to make a JavaFX property styleable through CSS and the API for creating pseudo-class state. The proposal may be found athttps://wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls. > Please take a moment to review the document and provide feedback. > > Thank you. From omeuefilipe at gmail.com Thu Dec 13 09:00:34 2012 From: omeuefilipe at gmail.com (Filipe Portes) Date: Thu, 13 Dec 2012 15:00:34 -0200 Subject: Drombler FX: building modular JavaFX applications with OSGi and Maven In-Reply-To: <1468973.LLaJQ6I9jc@shire> References: <1468973.LLaJQ6I9jc@shire> Message-ID: Hi everyone, I create a simple project called ModuleFX that also make you capable of run JavaFX application over OSGI, It's still very simple, but if anyone get intersted here's the link: https://github.com/filipeportes/ModuleFX On Sun, Dec 9, 2012 at 11:09 AM, Florian Brunner wrote: > Hi everybody, > > I'm happy to announce the availabilty of a first Early Access version of > Drombler FX. Drombler FX is a modular Rich Client Platform for JavaFX. > > You can read more about it here: http://puces- > blog.blogspot.ch/2012/12/drombler-fx-building-modular-javafx.html > > There's a Getting Started page which explains how to create, build and run > a > Drombler FX sample application with a few simple steps: > > http://wiki.drombler.org/GettingStarted > > - Florian > -- Filipe Portes - @filipeportes Java Architect - Senior Java EE/Web JUGLeader Gojava - @gojava From tom.schindl at bestsolution.at Thu Dec 13 13:24:30 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 13 Dec 2012 22:24:30 +0100 Subject: Drombler FX: building modular JavaFX applications with OSGi and Maven In-Reply-To: References: <1468973.LLaJQ6I9jc@shire> Message-ID: <50CA478E.1040103@bestsolution.at> Hi Filipe, >From code inspection I think Florians solution is the way to get JavaFX running in Felix because he's modifying "org.osgi.framework.system.packages.extra". If I'm not 100% mistaken your solution will hit what I describe at http://tomsondev.bestsolution.at/2012/08/01/javafx-2-2-and-osgi/ in the "Straight Repackageing" section. In short: If a user runs with your solution on a JDK which has JavaFX preinstalled the native code from the JDK will be picked up and the Java-Code from your module-fx and there are good chances that they don't match! If I got the solution from Florian right he's using org.osgi.framework.system.packages.extra to teach OSGi the new packages and somehow modifies the application classpath, or something similar. My Equinox solution on the other hand has the advantage that you don't have to control the bootstraping which is e.g. the case when you want to use JavaFX inside an Eclipse Plugin. Tom Am 13.12.12 18:00, schrieb Filipe Portes: > Hi everyone, > > I create a simple project called ModuleFX that also make you capable of run > JavaFX application over OSGI, It's still very simple, but if anyone get > intersted here's the link: > https://github.com/filipeportes/ModuleFX > > > On Sun, Dec 9, 2012 at 11:09 AM, Florian Brunner wrote: > >> Hi everybody, >> >> I'm happy to announce the availabilty of a first Early Access version of >> Drombler FX. Drombler FX is a modular Rich Client Platform for JavaFX. >> >> You can read more about it here: http://puces- >> blog.blogspot.ch/2012/12/drombler-fx-building-modular-javafx.html >> >> There's a Getting Started page which explains how to create, build and run >> a >> Drombler FX sample application with a few simple steps: >> >> http://wiki.drombler.org/GettingStarted >> >> - Florian >> > > > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From zonski at gmail.com Thu Dec 13 14:02:00 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 14 Dec 2012 09:02:00 +1100 Subject: JavaFX performance for complex visualisations In-Reply-To: <9EF244F8-AB86-4234-B2A7-6D672A601788@gmail.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C2FC51.80208@jugs.org> <6B515693-B119-4853-BD71-C9F78917F93B@oracle.com> <01a801cdd5ce$58e1e170$0aa5a450$@com.au> <9EF244F8-AB86-4234-B2A7-6D672A601788@gmail.com> Message-ID: Somewhat related to this thread, I'd be interest in people's responses to this forum post: https://forums.oracle.com/forums/thread.jspa?threadID=2476169&tstart=0 Basically looking for some good design patterns on building these sorts of diagrammatic applications. This will then feed back into Richard's game project with the ultimate goal of testing performance and either showing just what can be done with jfx or just as importantly highlighting to Richard and crew where the problems are. On that same note, there was a lot of enthusiastic comments about people interested in contributing to this project but so far its been pretty light on with only Jose and myself making any serious contributions. It would be good to have more input, users and actual coders. We are getting close to the stage where we need some more complex sprites (mine are currently blue circles), either vector and flip-image style (we'd like to have both in there), and I know quite a few of you wanted to test some specific things in this area. If you're interested in getting involved but don't know how, the two best things to do would be to read through the issues list on the project (we are kind of using this as a forum) or send me an email direct and I'll kick you off - we can look at building up a bit of a JFX games mailing list too so as not to spam this forum too much. Cheers, Dan On Mon, Dec 10, 2012 at 2:31 AM, Scott Palmer wrote: > To be honest, I don't know if the presentation was done in Flash. The end > result is MPEG4 video, not a Flash animation. I would be happy if the > *tools* used to create the presentation could easily be made using JavaFX. > I think JavaFX could do the visualization with a small framework written in > JavaFX. > > Scott > > On 2012-12-09, at 12:30 AM, "John C. Turnbull" > wrote: > > > That looks very good Scott. > > > > But just to put it out there, what *I'd* like to see is that the > presentation at that link be developed in JavaFX instead of Flash as it is > currently (not just the product it describes). Why can't we do that? > Well, the first question is whether JavaFX is capable of supporting such a > visualisation. The second question is even if it was possible, how would > it be developed without similar tools offered by Adobe Creative Suite? We > basically have Scene Builder at the moment which clearly isn't going to cut > it. > > > > -----Original Message----- > > From: openjfx-dev-bounces at openjdk.java.net [mailto: > openjfx-dev-bounces at openjdk.java.net] On Behalf Of Scott Palmer > > Sent: Sunday, 9 December 2012 04:43 > > To: Richard Bair > > Cc: openjfx-dev at openjdk.java.net > > Subject: Re: JavaFX performance for complex visualisations > > > > That first link is very close to what I am doing now with JavaFX... and > yes, the performance is below what I was hoping. When there are many Paths > performance drops substantially. > > Here's a link to info about our product: > > http://www.digitalrapids.com/en/Products/Kayak.aspx > > See Kayak Workflow Designer at 1:50 into the video. > > > > Scott > > > > > > On Sat, Dec 8, 2012 at 11:55 AM, Richard Bair >wrote: > > > >> I think the first link is a great example of something we should be > >> able to do, and the kind of thing that I think you and Michael are > >> saying doesn't work well right now. The second one actually is > >> probably a lot easier now, because of Canvas. Basically, all the > >> typographic background information isn't interactive, so you can > >> render it once and use it as an image thereafter (with Canvas), > >> whereas the first example has what I would guess would be a lot of > interactive content. > >> > >> Richard > >> > >> On Dec 8, 2012, at 1:01 AM, Daniel Zwolenski wrote: > >> > >>> And just for reference, I had business cases to show: > >>> * P&IDs like these > >> http://www.creativeengineers.com/process-engineering/diagrams/pid.html > >>> * Site maps similar to this sort of thing: > >> http://www.cegenvironmental.com/Services/Phase_II_ESA/Blueberry_Proces > >> sing_Plant/topoDKWfsmall.gif > >>> > >>> And to include zooming with LOD (i.e. more detail zoomed in, less > >>> detail > >> at birds eye view), selective layering/highlighting (i.e. turn on/off > >> different pipes or sections), hyperlinking and mouse overs, and > >> markers/annotations (i.e. put a flag on the map, or a semi-transparent > >> overlay over a "hot" section). No animations at least. > >>> > >>> JFX wasn't up to the task performance wise as far as I could tell in > >> 2.0. We scaled back to just showing blurry images and putting a few > >> markers (e.g. triangles/arrows/dots) on them but this was still quite > >> slow but that could well have been the logic behind it (things got > ugly). > >>> > >>> This was for mining, chemical, manufacturing and general heavy > >> industries (not unlike the cargo unloading thing from JavaOne). > >>> > >>> > >>> > >>> > >>> On Sat, Dec 8, 2012 at 7:37 PM, Dr. Michael Paus wrote: > >>> Am 07.12.2012 21:20, schrieb Richard Bair: > >>> > >>> Hi Michael, > >>> > >>> According to my experience JavaFX is currently not able to handle > >> graphically intensive > >>> applications. > >>> Depends on what you are doing that is "graphically intense" -- if it > >>> is > >> a lot of paths (thousands) then yes, this is slow. If it is a lot of > >> images and lines and effects and such, then actually you can do a heck > >> of a lot with FX (which is graphically intense!) > >>> This is of course true but tell me how far do you really get if you > >>> only > >> have these elements available? > >>> You cannot even draw a simple filled triangle without creating a > >>> path > >> and thus slowing down your application. > >>> A graphically intensive business application without paths seems to > >>> be a > >> very specific corner case to me but > >>> maybe it is just me who feels so. What I have in mind when I talk > >>> about > >> such applications are large diagrams, > >>> floor plans, vector maps with a lot of symbols on them and so on. > >>> If you're needing triangles, then you're in another class of > >>> application > >> than the kind we've so far properly supported. Hopefully the 3D stuff > >> will help bridge the gap. > >>> > >>> (I've not seen triangles in use except in 3D programming which may > >> explain why I haven't considered that particular use case critical for > >> our earlier releases, but hopefully we'll be able to handle your case > >> properly now). > >>> Just to avoid some misunderstanding. I mentioned triangles only as > >>> an > >> example for the most trivial geometry which cannot be > >>> created without using paths right now. In practice I have to create > >>> more > >> complicated geometries of course. > >>> > >>> > >>> -- > >>> > >> ---------------------------------------------------------------------- > >> ---------------- > >>> Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. > (JUGS). > >>> For more information visit www.jugs.de. > >>> > >>> > >> > >> > > > From zonski at gmail.com Thu Dec 13 15:08:42 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 14 Dec 2012 10:08:42 +1100 Subject: [REVIEW-REQUEST] RT-21709 Consider making available the CSS Styleable* classes as public API In-Reply-To: <174CE932-7F2E-4AB3-AC32-ABAA814F69D2@oracle.com> References: <8927902E-376B-40C1-BC9F-40086D0CFE7A@oracle.com> <174CE932-7F2E-4AB3-AC32-ABAA814F69D2@oracle.com> Message-ID: Just a side thing to consider in this context (and in FX CSS in general), the following web trends are growing making CSS more programmer-friendly: http://ruby.bvision.com/blog/please-stop-embedding-bootstrap-classes-in-your-html This is more a general high-level comment but I think some of it overlaps with what you are looking at now. For me, it makes sense to keep up with web-CSS trends in order to have appeal to designers from web-land, which as I understand it was the main motivation for using CSS as the styling language in FX. On Fri, Dec 14, 2012 at 3:29 AM, David Grieve wrote: > I've updated the proposal on the wiki, making it a little more complete > and hopefully making it easier to digest. Please review! > > On Dec 6, 2012, at 10:17 AM, David Grieve wrote: > > > Relative to http://javafx-jira.kenai.com/browse/RT-21709, I have posted > a proposed CSS API to support the development of custom UI Controls. The > proposal covers the API needed to make a JavaFX property styleable through > CSS and the API for creating pseudo-class state. The proposal may be found > athttps:// > wikis.oracle.com/display/OpenJDK/CSS+API+to+support+custom+UI+Controls. > > Please take a moment to review the document and provide feedback. > > > > Thank you. > > From jeff at reportmill.com Thu Dec 13 15:36:32 2012 From: jeff at reportmill.com (Jeff Martin) Date: Thu, 13 Dec 2012 17:36:32 -0600 Subject: Reliable deployment idea: JNLP Launcher exe/dmg In-Reply-To: References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C2FC51.80208@jugs.org> <6B515693-B119-4853-BD71-C9F78917F93B@oracle.com> <01a801cdd5ce$58e1e170$0aa5a450$@com.au> <9EF244F8-AB86-4234-B2A7-6D672A601788@gmail.com> Message-ID: <7915E1FB-F436-4260-8F2E-FF9CDCC1450A@reportmill.com> So here's an idea for reliable deployment. What if we build a Netbeans JNLP launcher project that you customize with just a link to a JNLP and a splash image, and it builds your GreatApp.exe and GreatApp.dmg. The launcher app would simply fetch the JNLP, download the jars (if newer than cache), load them, and invoke MainClass.main(). Then on your website you can say, If you have Java, try the Web Start link [ here ] or Download [ GreatApp.exe ] or [ GreatApp.dmg ] So the benefit over plain web start is that your GreatApp would have a consistent, self-contained execution environment, in the event that the target system doesn't have an installed JRE that is the right version or uncorrupted. You also don't get scary warning panels or signing issues. And you wouldn't be susceptible to surprise JRE update problems. But you would still get the benefit of simple upgrades that WebStart gives you. And you wouldn't have to constantly generate a new .exe/.dmg (maybe once or twice a year if you decide a new JRE update would benefit your app). Such a Netbeans project would probably only be a dozen pages of code. Here's an even better idea - Oracle sets up a server that will take any JNLP link and dynamically generates a .exe/.dmg for us. :-) jeff From phidias51 at gmail.com Thu Dec 13 16:23:13 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Thu, 13 Dec 2012 16:23:13 -0800 Subject: Reliable deployment idea: JNLP Launcher exe/dmg In-Reply-To: <7915E1FB-F436-4260-8F2E-FF9CDCC1450A@reportmill.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C2FC51.80208@jugs.org> <6B515693-B119-4853-BD71-C9F78917F93B@oracle.com> <01a801cdd5ce$58e1e170$0aa5a450$@com.au> <9EF244F8-AB86-4234-B2A7-6D672A601788@gmail.com> <7915E1FB-F436-4260-8F2E-FF9CDCC1450A@reportmill.com> Message-ID: Jeff, Unfortunately, Oracle is moving away from having it's own appstore (sort of one step short of what you're asking for) and looking to rely on the OS vendors app stores. It would be nice if when you installed Java you got a Java app store app in your dock. You could then easily find the apps you wanted and wouldn't have to mess with having to repackage things for different platforms. Cheers, Mark On Thu, Dec 13, 2012 at 3:36 PM, Jeff Martin wrote: > So here's an idea for reliable deployment. What if we build a Netbeans > JNLP launcher project that you customize with just a link to a JNLP and a > splash image, and it builds your GreatApp.exe and GreatApp.dmg. The > launcher app would simply fetch the JNLP, download the jars (if newer than > cache), load them, and invoke MainClass.main(). > > Then on your website you can say, > > If you have Java, try the Web Start link [ here ] or > Download [ GreatApp.exe ] or [ GreatApp.dmg ] > > So the benefit over plain web start is that your GreatApp would have a > consistent, self-contained execution environment, in the event that the > target system doesn't have an installed JRE that is the right version or > uncorrupted. You also don't get scary warning panels or signing issues. And > you wouldn't be susceptible to surprise JRE update problems. But you would > still get the benefit of simple upgrades that WebStart gives you. And you > wouldn't have to constantly generate a new .exe/.dmg (maybe once or twice a > year if you decide a new JRE update would benefit your app). > > Such a Netbeans project would probably only be a dozen pages of code. > Here's an even better idea - Oracle sets up a server that will take any > JNLP link and dynamically generates a .exe/.dmg for us. :-) > > jeff From zonski at gmail.com Thu Dec 13 16:32:04 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 14 Dec 2012 11:32:04 +1100 Subject: Reliable deployment idea: JNLP Launcher exe/dmg In-Reply-To: <7915E1FB-F436-4260-8F2E-FF9CDCC1450A@reportmill.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C2FC51.80208@jugs.org> <6B515693-B119-4853-BD71-C9F78917F93B@oracle.com> <01a801cdd5ce$58e1e170$0aa5a450$@com.au> <9EF244F8-AB86-4234-B2A7-6D672A601788@gmail.com> <7915E1FB-F436-4260-8F2E-FF9CDCC1450A@reportmill.com> Message-ID: Hey Jeff, I don't fully follow your suggestion (i.e. which bits are native, which bits are Java and which bits are downloaded when) but I don't think it will be quite as simple as this unfortunately (I've spent many a night laying awake, staring at the ceiling trying to work out a clean way to do deployment). Maybe you could clarify some aspects of your suggestion though: > What if we build a Netbeans JNLP launcher project Do you mean a new open source Java project here that provides extra deployment functionality that others can leverage? Or are you giving an example of a user creating a new "GreatApp" project that they want to launch? Is your launcher project native code or Java code and what role does Netbeans have in this (I wouldn't do anything IDE specific and passionately disagree with the Netbeans bias of JFX - everything should be IDE agnostic). How does the Launcher work and what does it do? that you customize with just a link to a JNLP and a splash image, Where does the JNLP come from, what is building it - are we just building a normal JFX webstart bundle here or is this a special JNLP file? and it builds your GreatApp.exe and GreatApp.dmg. What builds this? To create an 'exe' you have to build on Windows (plus 32 bit on 32 bit, and 64bit on 64 bit), whereas to build a DMG you currently have to be on Mac. There's no nice utility where you just go build-me-all-my-installers-for-all-platforms. Partly this is due to technology issues with each OS (e.g. MSI's can only be built on Windows) and partly it is due to the JRE not being available for co-bundling anywhere (the only one you have is the one installed on your machine), see http://javafx-jira.kenai.com/browse/RT-22964 If this step was small and simple, the rest of it would be easy and we wouldn't really need JNLP, webstart, etc. The launcher app would simply fetch the JNLP, download the jars (if newer > than cache), load them, and invoke MainClass.main(). > This is what JNLP does at the moment. I assume you mean it add some value somewhere but I'm missing what exactly that is? Note there is even a pre-launcher MainClass in the JFX packaging tools that does some JFX checks and updating stuff (it's weird and messy). Then on your website you can say, > > If you have Java, try the Web Start link [ here ] or > Download [ GreatApp.exe ] or [ GreatApp.dmg ] > In this case the JNLP file is a traditional one or something new and special? If it is a traditional one then you cannot pin it to a JRE and have all the problems we know about. If it is something special, I'm not sure what that special is or how the specialness gets hooked into the start-up process (since if you install Java the JNLP will be opened with Java). In this case do GreatApp.exe and GreatApp.dmg have the JRE co-bundled into them - i.e. they are just like the installers we can build now? If the JNLP is not special and the native installers are the same as now then I'm missing what you're adding to what we have now (i.e. you can produce the above website right now)? The only thing I think you might be suggesting is auto-updating of the exe/dmg based apps, which is not currently supported but planned by Oracle (unknown timeframe). Additionally there were a lot of discussions around adding AU and I have put up prototype code for this that can be used to do this (but it is raw and cludgy). See this discussion: http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-June/002433.html > > So the benefit over plain web start is that your GreatApp would have a > consistent, self-contained execution environment, in the event that the > target system doesn't have an installed JRE that is the right version or > uncorrupted. I'm missing how this happens? Can you clarify. > You also don't get scary warning panels or signing issues. Currently you don't have any of this with the native installers. The JRE is co-bundled and never installed so you side-step the JRE installation horrors. The problems with native installers that need to be addressed are: - Auto updating - Reduce the JRE size to make smaller downloads - Being able to build native releases on multiple platforms > > But you would still get the benefit of simple upgrades that WebStart gives > you. And you wouldn't have to constantly generate a new .exe/.dmg (maybe > once or twice a year if you decide a new JRE update would benefit your app). > This is basically just adding Auto Updating (AU) support to native installers. If your open source project is to add this then I'm in for that. I've already done a POC: http://code.google.com/p/zen-update/source/browse/trunk/ I ported JFX Ensemble to include auto updating support: http://zenjava.com/demo/update/ensemble/EnsembleWithZenUpdate-1.0.exe Work on this stalled because the JFX deployment team were unable/uninterested in implementing the changes needed to support this work. Once the packaging tools get open sourced (which is overdue) then the community can take over this work (and it is on my todo list). So long as the code remains behind the Oracle iron curtain however, we are hamstrung unless we want to re-implement most of what they have done from the ground up. This is an option but seems wasteful when the OS of the packaging code is suppose to be soon (but "soon" seems to be a very loose term). > > Such a Netbeans project would probably only be a dozen pages of code. Sounds ambitious :) > Here's an even better idea - Oracle sets up a server that will take any > JNLP link and dynamically generates a .exe/.dmg for us. :-) > > You may be interested in this JIRA for this: http://javafx-jira.kenai.com/browse/RT-22994 http://javafx-jira.kenai.com/browse/RT-22995 I'm keen to explore this topic with anyone and everyone wanting to do so. I like that you are looking at it but I'm either missing something about your suggestion or it's a bit too simple in it's approach to provide a solution. If I'm missing something then I really want to know what! If I'm not then I'm happy to help expose all the nasty complexities around this area if you want. Cheers, Dan From jeff at reportmill.com Thu Dec 13 17:17:07 2012 From: jeff at reportmill.com (Jeff Martin) Date: Thu, 13 Dec 2012 19:17:07 -0600 Subject: Reliable deployment idea: JNLP Launcher exe/dmg In-Reply-To: References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C2FC51.80208@jugs.org> <6B515693-B119-4853-BD71-C9F78917F93B@oracle.com> <01a801cdd5ce$58e1e170$0aa5a450$@com.au> <9EF244F8-AB86-4234-B2A7-6D672A601788@gmail.com> <7915E1FB-F436-4260-8F2E-FF9CDCC1450A@reportmill.com> Message-ID: <4F41ABC9-EDA1-451D-8345-C9826683406B@reportmill.com> Mark, I definitely don't want Oracle to have an app store. App stores are very evil, if done right. :-) Dan, I guess I'm mostly thinking of my deployment scenario with ReportMill (and Java Inventor). I have had good luck with our ReportMill.jnlp Web Start link because our customers are developers who generally have a working, up to date JRE. I update my ReportMill.jar about once a month and my customers get the update automatically. When things don't work, I think it's because the browser didn't handle the JNLP-link/WebStart launch correctly, or they don't have the correct version of Java, and/or the JRE update mechanism doesn't work, or the installed JRE installation is corrupted somehow, or the cache is confused. There may also be security and/or permissions problems with a general JRE installation. Probably the best way to clear this up is to have them uninstall Java and re-install the latest version. But I can't realistically guarantee that my latest version works with all the last 10 updates or the next 100 updates of the JRE. So having the GreatApp.exe and GreatApp.dmg options available, to me, simplifies the step of making sure that the JRE is a clean, uncompromised, compliant (for my app) installation. But I don't want a static version of my app and I don't want to have to rebuild the .exe/.dmg every time I have an update (nor could I expect my customers to regularly re-install my app). So maybe my scenario isn't common for everyone. But I think this is a reasonably trouble free way of deploying an auto-updating app without having to send users to a generic JRE install (and then help some of them troubleshoot it). I only suggest NetBeans because building the .exe/.dmg would be a rare occurrence. I have built a launcher like this before (Sun paid us to do one for a version of JFXBuilder years ago), so I already have some utility methods for checking for a new GreatApp.jar.pack.gz, downloading it, unpacking it and class loading it. I think it was only a few pages of code. :-) jeff On Dec 13, 2012, at 6:32 PM, Daniel Zwolenski wrote: > Hey Jeff, > > I don't fully follow your suggestion (i.e. which bits are native, which bits are Java and which bits are downloaded when) but I don't think it will be quite as simple as this unfortunately (I've spent many a night laying awake, staring at the ceiling trying to work out a clean way to do deployment). > > Maybe you could clarify some aspects of your suggestion though: > > > What if we build a Netbeans JNLP launcher project > > Do you mean a new open source Java project here that provides extra deployment functionality that others can leverage? Or are you giving an example of a user creating a new "GreatApp" project that they want to launch? > > Is your launcher project native code or Java code and what role does Netbeans have in this (I wouldn't do anything IDE specific and passionately disagree with the Netbeans bias of JFX - everything should be IDE agnostic). How does the Launcher work and what does it do? > > > that you customize with just a link to a JNLP and a splash image, > > Where does the JNLP come from, what is building it - are we just building a normal JFX webstart bundle here or is this a special JNLP file? > > > and it builds your GreatApp.exe and GreatApp.dmg. > > What builds this? To create an 'exe' you have to build on Windows (plus 32 bit on 32 bit, and 64bit on 64 bit), whereas to build a DMG you currently have to be on Mac. There's no nice utility where you just go build-me-all-my-installers-for-all-platforms. Partly this is due to technology issues with each OS (e.g. MSI's can only be built on Windows) and partly it is due to the JRE not being available for co-bundling anywhere (the only one you have is the one installed on your machine), see http://javafx-jira.kenai.com/browse/RT-22964 > > If this step was small and simple, the rest of it would be easy and we wouldn't really need JNLP, webstart, etc. > > > The launcher app would simply fetch the JNLP, download the jars (if newer than cache), load them, and invoke MainClass.main(). > > This is what JNLP does at the moment. I assume you mean it add some value somewhere but I'm missing what exactly that is? Note there is even a pre-launcher MainClass in the JFX packaging tools that does some JFX checks and updating stuff (it's weird and messy). > > > Then on your website you can say, > > If you have Java, try the Web Start link [ here ] or > Download [ GreatApp.exe ] or [ GreatApp.dmg ] > > In this case the JNLP file is a traditional one or something new and special? If it is a traditional one then you cannot pin it to a JRE and have all the problems we know about. If it is something special, I'm not sure what that special is or how the specialness gets hooked into the start-up process (since if you install Java the JNLP will be opened with Java). > > In this case do GreatApp.exe and GreatApp.dmg have the JRE co-bundled into them - i.e. they are just like the installers we can build now? > > If the JNLP is not special and the native installers are the same as now then I'm missing what you're adding to what we have now (i.e. you can produce the above website right now)? > > The only thing I think you might be suggesting is auto-updating of the exe/dmg based apps, which is not currently supported but planned by Oracle (unknown timeframe). Additionally there were a lot of discussions around adding AU and I have put up prototype code for this that can be used to do this (but it is raw and cludgy). > > See this discussion: http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-June/002433.html > > > > So the benefit over plain web start is that your GreatApp would have a consistent, self-contained execution environment, in the event that the target system doesn't have an installed JRE that is the right version or uncorrupted. > > I'm missing how this happens? Can you clarify. > > You also don't get scary warning panels or signing issues. > > Currently you don't have any of this with the native installers. The JRE is co-bundled and never installed so you side-step the JRE installation horrors. > > The problems with native installers that need to be addressed are: > - Auto updating > - Reduce the JRE size to make smaller downloads > - Being able to build native releases on multiple platforms > > > > But you would still get the benefit of simple upgrades that WebStart gives you. And you wouldn't have to constantly generate a new .exe/.dmg (maybe once or twice a year if you decide a new JRE update would benefit your app). > > This is basically just adding Auto Updating (AU) support to native installers. > > If your open source project is to add this then I'm in for that. I've already done a POC: http://code.google.com/p/zen-update/source/browse/trunk/ > > I ported JFX Ensemble to include auto updating support: http://zenjava.com/demo/update/ensemble/EnsembleWithZenUpdate-1.0.exe > > Work on this stalled because the JFX deployment team were unable/uninterested in implementing the changes needed to support this work. > > Once the packaging tools get open sourced (which is overdue) then the community can take over this work (and it is on my todo list). So long as the code remains behind the Oracle iron curtain however, we are hamstrung unless we want to re-implement most of what they have done from the ground up. This is an option but seems wasteful when the OS of the packaging code is suppose to be soon (but "soon" seems to be a very loose term). > > > Such a Netbeans project would probably only be a dozen pages of code. > > Sounds ambitious :) > > Here's an even better idea - Oracle sets up a server that will take any JNLP link and dynamically generates a .exe/.dmg for us. :-) > > > You may be interested in this JIRA for this: > http://javafx-jira.kenai.com/browse/RT-22994 > http://javafx-jira.kenai.com/browse/RT-22995 > > I'm keen to explore this topic with anyone and everyone wanting to do so. I like that you are looking at it but I'm either missing something about your suggestion or it's a bit too simple in it's approach to provide a solution. If I'm missing something then I really want to know what! If I'm not then I'm happy to help expose all the nasty complexities around this area if you want. > > Cheers, > Dan > > > > > From hang.vo at oracle.com Thu Dec 13 17:20:12 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 14 Dec 2012 01:20:12 +0000 Subject: hg: openjfx/8/master/rt: 71 new changesets Message-ID: <20121214012204.4A2A247134@hg.openjdk.java.net> Changeset: dd45fc2ac4ba Author: "Jasper Potts" Date: 2012-11-27 16:09 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/dd45fc2ac4ba Fixed RT-19713 & RT-26435 Add API to JavaFX to allow for setting preferred user agent stylesheet. Also add system property for setting the user agent styles. ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/javafx/application/Application.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java - javafx-ui-controls/src/javafx/scene/control/UAStylesheetLoader.java Changeset: 5d5dddfa1a60 Author: "Jasper Potts" Date: 2012-11-27 16:11 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5d5dddfa1a60 Added new experimental application as a playground for prototyping a new look and feel for JavaFX + apps/experiments/Modena/build.xml + apps/experiments/Modena/manifest.mf + apps/experiments/Modena/nbproject/build-impl.xml + apps/experiments/Modena/nbproject/configs/Run_as_WebStart.properties + apps/experiments/Modena/nbproject/configs/Run_in_Browser.properties + apps/experiments/Modena/nbproject/genfiles.properties + apps/experiments/Modena/nbproject/jfx-impl.xml + apps/experiments/Modena/nbproject/jfx-impl_backup.xml + apps/experiments/Modena/nbproject/project.properties + apps/experiments/Modena/nbproject/project.xml + apps/experiments/Modena/src/modena/Modena.css + apps/experiments/Modena/src/modena/Modena.java + apps/experiments/Modena/src/modena/SamplePage.java + apps/experiments/Modena/src/modena/TestApp.css Changeset: b4fe87e55747 Author: David Grieve Date: 2012-11-28 09:14 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b4fe87e55747 branch merge Changeset: c578bb6b90f4 Author: leifs Date: 2012-11-28 07:48 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c578bb6b90f4 Fixed RT-23878: -fx-ellipsis-string doesn't apply after setStyle ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java Changeset: 1ea2d63fa876 Author: David Grieve Date: 2012-11-28 11:19 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1ea2d63fa876 RT-26554: if an inline style changes, clear the style cache so new styles will be recalculated. ! apps/experiments/Modena/src/modena/Modena.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/com/sun/javafx/scene/CSSFlags.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/test/unit/javafx/scene/CSSNode.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: b1f6d7efb9f2 Author: David Grieve Date: 2012-11-28 11:20 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b1f6d7efb9f2 branch merge Changeset: b354819486c6 Author: leifs Date: 2012-11-28 10:06 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b354819486c6 RT-26245: FXML-LoginDemo text field doesn't show characters ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java Changeset: 0ce17489970d Author: David Grieve Date: 2012-11-28 14:11 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0ce17489970d RT-26484: looping on invalidated method of fontProperty in Labeled caused indirectly by ObjectProperty having no check for equals. Override set method to check equals. ! javafx-ui-controls/src/javafx/scene/control/Labeled.java Changeset: f9919f8e02d7 Author: jgiles Date: 2012-09-17 13:22 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f9919f8e02d7 Small improvements to TreeTableView implementation. ! javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableRow.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java Changeset: 7e64b82fa22c Author: jgiles Date: 2012-09-17 15:21 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7e64b82fa22c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: a0feb76fb5a1 Author: jgiles Date: 2012-09-20 08:29 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a0feb76fb5a1 Small TreeTableRow cleanup. ! javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableRow.java Changeset: 686deb763e24 Author: jgiles Date: 2012-09-20 08:39 +1200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/686deb763e24 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 969bc24c7dc8 Author: jgiles Date: 2012-10-08 08:13 -0700 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/969bc24c7dc8 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: ec59f4a357e3 Author: jgiles Date: 2012-11-10 12:07 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ec59f4a357e3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: a819d671e276 Author: jgiles Date: 2012-11-19 10:13 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a819d671e276 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 56426964368a Author: jgiles Date: 2012-12-03 14:18 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/56426964368a RT-17288: Initial import of a completely new TreeTableView implementation (and removal of the old one). - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableColumn.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableRow.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/TableColumnComparator.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java + javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableCellSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableCellSkinBase.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/TableRowSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css + javafx-ui-controls/src/javafx/scene/control/CellSpan.java ! javafx-ui-controls/src/javafx/scene/control/FocusModel.java ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java + javafx-ui-controls/src/javafx/scene/control/ResizeFeaturesBase.java + javafx-ui-controls/src/javafx/scene/control/SpanModel.java ! javafx-ui-controls/src/javafx/scene/control/TableCell.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java + javafx-ui-controls/src/javafx/scene/control/TableColumnBase.java + javafx-ui-controls/src/javafx/scene/control/TableFocusModel.java ! javafx-ui-controls/src/javafx/scene/control/TablePosition.java + javafx-ui-controls/src/javafx/scene/control/TablePositionBase.java + javafx-ui-controls/src/javafx/scene/control/TableSelectionModel.java + javafx-ui-controls/src/javafx/scene/control/TableUtil.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeItem.java + javafx-ui-controls/src/javafx/scene/control/TreeSortMode.java + javafx-ui-controls/src/javafx/scene/control/TreeTableCell.java + javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java + javafx-ui-controls/src/javafx/scene/control/TreeTablePosition.java + javafx-ui-controls/src/javafx/scene/control/TreeTableRow.java + javafx-ui-controls/src/javafx/scene/control/TreeTableView.java + javafx-ui-controls/src/javafx/scene/control/TreeUtil.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java + javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeTableCell.java + javafx-ui-controls/src/javafx/scene/control/cell/ChoiceBoxTreeTableCell.java + javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxTreeTableCell.java + javafx-ui-controls/src/javafx/scene/control/cell/ProgressBarTreeTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/PropertyValueFactory.java + javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeTableCell.java + javafx-ui-controls/src/javafx/scene/control/cell/TreeItemPropertyValueFactory.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/behavior/TableViewAnchorRetriever.java ! javafx-ui-controls/test/javafx/scene/control/MultipleSelectionModelImplTest.java ! javafx-ui-controls/test/javafx/scene/control/TableColumnTest.java + javafx-ui-controls/test/javafx/scene/control/TreeTableColumnTest.java Changeset: 20667075f80a Author: jgiles Date: 2012-12-03 14:22 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/20667075f80a Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableColumn.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableRow.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableView.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 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/javafx/scene/control/TableCell.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java Changeset: 5b9d072ea84c Author: jgiles Date: 2012-12-03 15:06 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5b9d072ea84c Fixing TreeTableView merge errors due to being out in a sandbox for so long. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/javafx/scene/control/TreeTableCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableRow.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/behavior/TableViewAnchorRetriever.java Changeset: 1ae5f7425065 Author: Paru Somashekar Date: 2012-12-03 13:31 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1ae5f7425065 fix RT-26413 Menu blinks when cursor is moved from menu to menuBar. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java Changeset: 3e8a2f562097 Author: jgiles Date: 2012-12-04 12:05 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3e8a2f562097 Partial implementation of RT-21597: 'Move SkinBase into public API'. Namely, removing all references of BehaviorBase from SkinBase, as SkinBase will be public API in 8.0, but BehaviorBase will remain private API for now. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/AccordionSkin.java + javafx-ui-controls/src/com/sun/javafx/scene/control/skin/BehaviorSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ChoiceBoxSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxBaseSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuButtonSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SeparatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SliderSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SplitPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualContainerBase.java ! javafx-ui-controls/src/javafx/scene/control/SkinBase.java Changeset: 06a8b0af9d46 Author: jgiles Date: 2012-12-04 12:19 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/06a8b0af9d46 RT-21597: 'Move SkinBase into public API': Calling super.dispose(). ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/BehaviorSkinBase.java Changeset: c8452a11548d Author: jgiles Date: 2012-12-04 18:10 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c8452a11548d Updating unit tests related to SkinBase / BehaviorSkinBase + javafx-ui-controls/test/com/sun/javafx/scene/control/skin/BehaviorSkinBaseTest.java ! javafx-ui-controls/test/javafx/scene/control/SkinBaseTest.java Changeset: e17bfdb2019b Author: jgiles Date: 2012-12-04 18:10 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e17bfdb2019b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java Changeset: fefcbba9f15c Author: Paru Somashekar Date: 2012-12-03 21:42 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fefcbba9f15c add AccessibleMenuButton ! javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleButton.java + javafx-ui-controls/src/com/sun/javafx/scene/control/accessible/AccessibleMenuButton.java Changeset: e76b08812540 Author: leifs Date: 2012-12-05 12:04 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e76b08812540 RT-24930: Add RTL support to ProgressIndicator and ProgressBar ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/javafx/scene/control/ProgressBar.java ! javafx-ui-controls/src/javafx/scene/control/ProgressIndicator.java Changeset: 73632e466060 Author: jgiles Date: 2012-12-06 12:16 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/73632e466060 Removing redundant com.sun.javafx.scene.control.WeakEventHandler, and replacing usages with javafx.event.WeakEventHandler instances. - javafx-ui-controls/src/com/sun/javafx/scene/control/WeakEventHandler.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java Changeset: eefd03e1ae97 Author: jgiles Date: 2012-12-06 12:18 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/eefd03e1ae97 Fixing issue in MultipleSelectionModelBase where a boolean test was being duplicated needlessly. ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java Changeset: 96c299db643a Author: jgiles Date: 2012-12-06 12:20 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/96c299db643a Findbugs: Redundant nullcheck of value known to be non-null in TableView. ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: bdd29e62d47c Author: jgiles Date: 2012-12-06 12:22 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bdd29e62d47c Findbugs: Boxed value is unboxed and then immediately reboxed in CheckBoxTreeItem. ! javafx-ui-controls/src/javafx/scene/control/CheckBoxTreeItem.java Changeset: 3294d1b3ce3d Author: jgiles Date: 2012-12-06 12:32 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3294d1b3ce3d Findbugs: Unwritten field in TextField*Cell classes for textField field. ! javafx-ui-controls/src/javafx/scene/control/cell/CellUtils.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeTableCell.java Changeset: a8a1dfc873f4 Author: jgiles Date: 2012-12-06 12:41 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a8a1dfc873f4 Findbugs: Redundant nullcheck of value known to be non-null in TreeTableView ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java Changeset: 152535ac19aa Author: jgiles Date: 2012-12-06 12:42 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/152535ac19aa Findbugs: Unused fields in TabPane ! javafx-ui-controls/src/javafx/scene/control/TabPane.java Changeset: 078fb6f86f96 Author: jgiles Date: 2012-12-06 12:43 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/078fb6f86f96 Findbugs: Redundant nullcheck of value known to be non-null in TableView ! javafx-ui-controls/src/javafx/scene/control/TableView.java Changeset: 19e297131c24 Author: jgiles Date: 2012-12-06 13:00 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/19e297131c24 Findbugs: Dead store to local variable in ChoiceBoxSelectionModel ! javafx-ui-controls/src/javafx/scene/control/ChoiceBox.java Changeset: 242d2e2f26f6 Author: jgiles Date: 2012-12-06 13:12 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/242d2e2f26f6 Findbugs: Method call passes null for nonnull parameter in ContextMenu ! javafx-ui-controls/src/javafx/scene/control/ContextMenu.java Changeset: 2d9fb12395eb Author: jgiles Date: 2012-12-06 13:14 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2d9fb12395eb Findbugs: Redundant nullcheck of value known to be non-null in TreeTableView ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java Changeset: 5a40381a4c3d Author: jgiles Date: 2012-12-06 13:15 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5a40381a4c3d Findbugs: Dead store to local variable in TextArea ! javafx-ui-controls/src/javafx/scene/control/TextArea.java Changeset: fda395cfc7d6 Author: jgiles Date: 2012-12-06 13:17 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fda395cfc7d6 Findbugs: Dead store to local variable in PopupControl. ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 1a1d89cf5390 Author: jgiles Date: 2012-12-06 13:40 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1a1d89cf5390 Findbugs: Redundant nullcheck of value known to be non-null in TreeCellSkin. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java Changeset: ed94b6913f66 Author: jgiles Date: 2012-12-06 13:51 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ed94b6913f66 Findbugs: Redundant nullcheck of value known to be non-null in VirtualFlow. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: 8a90d8a34b74 Author: jgiles Date: 2012-12-06 13:57 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8a90d8a34b74 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt - javafx-ui-controls/src/com/sun/javafx/scene/control/WeakEventHandler.java Changeset: 08a7980d8bc4 Author: leifs Date: 2012-12-06 13:22 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/08a7980d8bc4 RT-24225: Add RTL support to Menu / MenuItem / RadioMenuItem / CheckMenuItem / ContextMenu / MenuBar ! javafx-ui-common/src/com/sun/javafx/Utils.java ! javafx-ui-controls/src/javafx/scene/control/ContextMenu.java Changeset: ee46c5bb984f Author: Paru Somashekar Date: 2012-12-06 15:24 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ee46c5bb984f fix RT-18448 [Slider] label formatter is not applicable + unit test ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SliderSkin.java ! javafx-ui-controls/src/javafx/scene/chart/Axis.java ! javafx-ui-controls/src/javafx/scene/chart/ValueAxis.java ! javafx-ui-controls/test/javafx/scene/control/SliderTest.java Changeset: e8d1d5ae5f78 Author: Paru Somashekar Date: 2012-12-06 15:51 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e8d1d5ae5f78 RT-18448: cleaned up the previous patch. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SliderSkin.java Changeset: bfebbf84081f Author: David Grieve Date: 2012-12-07 14:37 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bfebbf84081f RT-26622: apply linear-gradient patch to highcontrast.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/highcontrast.css Changeset: 4fd3e1bdb19b Author: David Grieve Date: 2012-12-07 14:38 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4fd3e1bdb19b RT-17607: -fx-font-weight: 600 parses as a NUMBER but the css parser expects an IDENT. Fix parser to accept a number. ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java ! javafx-ui-common/test/unit/com/sun/javafx/css/FontWeightTypeTest.java Changeset: bf75ca4caf36 Author: David Grieve Date: 2012-12-07 14:41 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bf75ca4caf36 RT-21709 [partial]: prepare to make CSS Styleable* properites public ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java ! javafx-ui-charts/src/javafx/scene/chart/Chart.java ! javafx-ui-charts/src/javafx/scene/chart/LineChart.java ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java ! javafx-ui-charts/src/javafx/scene/chart/StackedAreaChart.java ! javafx-ui-charts/src/javafx/scene/chart/StackedBarChart.java ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java ! javafx-ui-charts/test/javafx/scene/chart/XYChartTest.java ! javafx-ui-common/src/com/sun/javafx/css/CascadingStyle.java ! javafx-ui-common/src/com/sun/javafx/css/CssError.java ! javafx-ui-common/src/com/sun/javafx/css/Declaration.java + javafx-ui-common/src/com/sun/javafx/css/Origin.java - javafx-ui-common/src/com/sun/javafx/css/Property.java ! javafx-ui-common/src/com/sun/javafx/css/Rule.java ! javafx-ui-common/src/com/sun/javafx/css/Style.java ! javafx-ui-common/src/com/sun/javafx/css/StyleConverter.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/com/sun/javafx/css/Styleable.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableBooleanProperty.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableDoubleProperty.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableFloatProperty.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableIntegerProperty.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableLongProperty.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableObjectProperty.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableProperty.java + javafx-ui-common/src/com/sun/javafx/css/StyleablePropertyMetaData.java ! javafx-ui-common/src/com/sun/javafx/css/StyleableStringProperty.java ! javafx-ui-common/src/com/sun/javafx/css/Stylesheet.java + javafx-ui-common/src/com/sun/javafx/css/SubCSSProperty.java - javafx-ui-common/src/com/sun/javafx/css/SubStyleableProperty.java ! javafx-ui-common/src/com/sun/javafx/css/converters/FontConverter.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/src/javafx/scene/layout/Background.java ! javafx-ui-common/src/javafx/scene/layout/BackgroundConverter.java ! javafx-ui-common/src/javafx/scene/layout/Border.java ! javafx-ui-common/src/javafx/scene/layout/BorderConverter.java ! javafx-ui-common/src/javafx/scene/layout/FlowPane.java ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/src/javafx/scene/layout/HBox.java ! javafx-ui-common/src/javafx/scene/layout/Region.java ! javafx-ui-common/src/javafx/scene/layout/StackPane.java ! javafx-ui-common/src/javafx/scene/layout/TilePane.java ! javafx-ui-common/src/javafx/scene/layout/VBox.java ! javafx-ui-common/src/javafx/scene/shape/Line.java ! javafx-ui-common/src/javafx/scene/shape/Path.java ! javafx-ui-common/src/javafx/scene/shape/Polyline.java ! javafx-ui-common/src/javafx/scene/shape/Rectangle.java ! javafx-ui-common/src/javafx/scene/shape/Shape.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/src/javafx/scene/text/TextFlow.java ! javafx-ui-common/test/unit/com/sun/javafx/css/DeclarationTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/RuleTest.java + javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyMetaDataTest.java - javafx-ui-common/test/unit/com/sun/javafx/css/StyleablePropertyTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StylesheetTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/TestNode.java ! javafx-ui-common/test/unit/com/sun/javafx/css/TestNodeBase.java ! javafx-ui-common/test/unit/com/sun/javafx/css/TypeTest.java ! javafx-ui-common/test/unit/com/sun/javafx/scene/layout/RegionTest.java ! javafx-ui-common/test/unit/com/sun/javafx/scene/layout/region/BackgroundFillConverterTest.java ! javafx-ui-common/test/unit/com/sun/javafx/test/CssMethodsTestBase.java ! javafx-ui-common/test/unit/com/sun/javafx/test/OnInvalidateMethodsTestBase.java ! javafx-ui-common/test/unit/javafx/scene/CSSNode.java ! javafx-ui-common/test/unit/javafx/scene/Node_onInvalidate_Test.java ! javafx-ui-common/test/unit/javafx/scene/layout/TilePaneTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/ShapeTest.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CellSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVK.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledImpl.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/javafx/scene/chart/Axis.java ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java ! javafx-ui-controls/src/javafx/scene/chart/NumberAxis.java ! javafx-ui-controls/src/javafx/scene/chart/ValueAxis.java ! javafx-ui-controls/src/javafx/scene/control/Accordion.java ! javafx-ui-controls/src/javafx/scene/control/Cell.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/Hyperlink.java ! javafx-ui-controls/src/javafx/scene/control/Label.java ! 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/MenuBar.java ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/ProgressBar.java ! javafx-ui-controls/src/javafx/scene/control/ProgressIndicator.java ! javafx-ui-controls/src/javafx/scene/control/RadioButton.java ! javafx-ui-controls/src/javafx/scene/control/ScrollBar.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java ! javafx-ui-controls/src/javafx/scene/control/Separator.java ! javafx-ui-controls/src/javafx/scene/control/SkinBase.java ! javafx-ui-controls/src/javafx/scene/control/Slider.java ! javafx-ui-controls/src/javafx/scene/control/SplitPane.java ! javafx-ui-controls/src/javafx/scene/control/Tab.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TextField.java ! javafx-ui-controls/src/javafx/scene/control/TitledPane.java ! javafx-ui-controls/src/javafx/scene/control/ToggleButton.java ! javafx-ui-controls/src/javafx/scene/control/ToolBar.java ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTableCell.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabeledImplTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabeledImplTestOther.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabeledTextTest.java ! javafx-ui-controls/test/javafx/scene/chart/AxisTest.java ! javafx-ui-controls/test/javafx/scene/chart/CategoryAxisTest.java ! javafx-ui-controls/test/javafx/scene/chart/NumberAxisTest.java ! javafx-ui-controls/test/javafx/scene/chart/ValueAxisTest.java ! javafx-ui-controls/test/javafx/scene/control/ControlSkinTest.java ! javafx-ui-controls/test/javafx/scene/control/ControlTest.java ! javafx-ui-controls/test/javafx/scene/control/HyperlinkTest.java ! javafx-ui-controls/test/javafx/scene/control/LabelTest.java ! javafx-ui-controls/test/javafx/scene/control/LabeledTest.java ! javafx-ui-controls/test/javafx/scene/control/PaginationTest.java ! javafx-ui-controls/test/javafx/scene/control/ScrollBarTest.java ! javafx-ui-controls/test/javafx/scene/control/ScrollPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/SeparatorTest.java ! javafx-ui-controls/test/javafx/scene/control/SliderTest.java ! javafx-ui-controls/test/javafx/scene/control/SplitPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/TabPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/TextInputControlTest.java ! javafx-ui-controls/test/javafx/scene/control/TitledPaneTest.java ! javafx-ui-controls/test/javafx/scene/control/ToolbarTest.java ! javafx-ui-controls/test/javafx/scene/control/TooltipTest.java Changeset: 382ea952840d Author: David Grieve Date: 2012-12-07 15:13 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/382ea952840d merge - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableColumn.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableRow.java - javafx-ui-controls/src/com/preview/javafx/scene/control/TreeTableView.java - javafx-ui-controls/src/com/sun/javafx/scene/control/WeakEventHandler.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/javafx/scene/chart/Axis.java ! javafx-ui-controls/src/javafx/scene/chart/ValueAxis.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/ProgressBar.java ! javafx-ui-controls/src/javafx/scene/control/ProgressIndicator.java ! javafx-ui-controls/src/javafx/scene/control/SkinBase.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/test/javafx/scene/control/SliderTest.java Changeset: 55b52b24b94d Author: David Grieve Date: 2012-12-10 10:26 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/55b52b24b94d RT-21709 [partial]: fix merge errors after pulling changes onto bf75ca4caf36 ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeTableCell.java Changeset: a867b54962e3 Author: Paru Somashekar Date: 2012-12-10 11:57 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a867b54962e3 fix RT-26820 ChoiceBox with no items throws exception when added to live scene. + unit test. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/test/javafx/scene/control/ChoiceBoxTest.java Changeset: 8dc0b2132350 Author: jgiles Date: 2012-12-07 14:05 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8dc0b2132350 RT-26659: Rename impl_ treeItemCount property in TreeView and TreeTableView (it is now called expandedItemCount and is fully public API). ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! javafx-ui-controls/src/javafx/scene/control/TreeCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeItem.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableRow.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeUtil.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java Changeset: 076a80df7218 Author: jgiles Date: 2012-12-07 17:55 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/076a80df7218 RT-26787: TreeTableView: Key combinations with PgDn and PgUp throw an exception ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java Changeset: 322deaa43d9e Author: jgiles Date: 2012-12-11 09:47 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/322deaa43d9e RT-26656: All functionality that is available on Desktop should also be available on Embedded Touch ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java Changeset: 230b3d48a7a9 Author: jgiles Date: 2012-12-11 10:57 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/230b3d48a7a9 RT-26185: application freeze on focusing combobox (a.k.a RT-26802: Endless loop with multiple focus-traversable ComboBoxes) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 723b6b7fb579 Author: jgiles Date: 2012-12-11 12:06 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/723b6b7fb579 RT-24917: [TreeView] Editing is broken in 8.0 ! javafx-ui-controls/src/javafx/scene/control/ListCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeCell.java Changeset: 28782b36e141 Author: jgiles Date: 2012-12-11 20:52 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/28782b36e141 Fixing unit test to use latest TreeView API. ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: 28aeebda6a0b Author: jgiles Date: 2012-12-11 20:52 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/28aeebda6a0b Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java Changeset: 16381e29f371 Author: David Grieve Date: 2012-12-11 11:23 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/16381e29f371 resolve merge conflict - javafx-fxml/test/javafx/fxml/RT_14880.java - javafx-fxml/test/javafx/fxml/RT_15524.java - javafx-fxml/test/javafx/fxml/RT_16722.java - javafx-fxml/test/javafx/fxml/RT_16724.java - javafx-fxml/test/javafx/fxml/RT_16815.java - javafx-fxml/test/javafx/fxml/RT_16977.java - javafx-fxml/test/javafx/fxml/RT_17646.java - javafx-fxml/test/javafx/fxml/RT_17714.java - javafx-fxml/test/javafx/fxml/RT_18046.java - javafx-fxml/test/javafx/fxml/RT_18218.java - javafx-fxml/test/javafx/fxml/RT_18680.java - javafx-fxml/test/javafx/fxml/RT_18933.java - javafx-fxml/test/javafx/fxml/RT_19008.java - javafx-fxml/test/javafx/fxml/RT_19112.java - javafx-fxml/test/javafx/fxml/RT_19139.java - javafx-fxml/test/javafx/fxml/RT_19228.java - javafx-fxml/test/javafx/fxml/RT_19329.java - javafx-fxml/test/javafx/fxml/RT_19870.java - javafx-fxml/test/javafx/fxml/RT_20082.java - javafx-fxml/test/javafx/fxml/RT_20471.java - javafx-fxml/test/javafx/fxml/RT_22971.java - javafx-fxml/test/javafx/fxml/RT_23413.java - javafx-fxml/test/javafx/fxml/RT_24380.java ! javafx-ui-common/src/javafx/scene/layout/BorderConverter.java ! javafx-ui-common/src/javafx/scene/layout/Region.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/FXVKSkin.java Changeset: 8749547f90e5 Author: David Grieve Date: 2012-12-11 11:42 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8749547f90e5 RT-26694: gatherParentStylesheets in StyleManager might return null. ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java Changeset: e941ae1fb3e5 Author: rbair Date: 2012-12-05 10:49 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e941ae1fb3e5 [JavaDoc] Added some missing doc comments on methods in TextInputControl ! javafx-ui-controls/src/javafx/scene/control/TextInputControl.java Changeset: 4daba9576a3b Author: Martin Sladecek Date: 2012-12-06 09:48 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4daba9576a3b RT-26518 Children of Sequential and Parallel Transition should be controlled only through their parent + Sequential Transition test & fixes ! javafx-ui-common/nbproject/project.xml ! javafx-ui-common/src/javafx/animation/ParallelTransition.java ! javafx-ui-common/src/javafx/animation/SequentialTransition.java ! javafx-ui-common/src/javafx/animation/Transition.java + javafx-ui-common/test/unit/javafx/animation/AbstractMasterTimerMock.java + javafx-ui-common/test/unit/javafx/animation/SequentialTransitionPlayTest.java Changeset: 218967f4a7a7 Author: Martin Sladecek Date: 2012-12-06 09:49 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/218967f4a7a7 merge Changeset: ffd89bb359f1 Author: rbair Date: 2012-12-06 16:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ffd89bb359f1 Fix for RT-26100. This change should have no functional impact, but I changed the defaults to match with the multipliers hard-coded into NGRegion. ! javafx-ui-common/src/javafx/scene/layout/BorderStrokeStyle.java Changeset: 34ae31eab256 Author: tb115823 Date: 2012-12-07 12:56 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/34ae31eab256 RT-25494 Cycle detection in fxml includes ! javafx-fxml/src/javafx/fxml/FXMLLoader.java + javafx-fxml/test/javafx/fxml/RT_25494_Cycle_DetectionTest.java + javafx-fxml/test/javafx/fxml/cycle.fxml + javafx-fxml/test/javafx/fxml/dummy-cycle.fxml + javafx-fxml/test/javafx/fxml/leaf1.fxml + javafx-fxml/test/javafx/fxml/leaf2.fxml + javafx-fxml/test/javafx/fxml/leaf3.fxml + javafx-fxml/test/javafx/fxml/leaf4.fxml + javafx-fxml/test/javafx/fxml/one-2-one-cycle.fxml Changeset: 698048c91224 Author: "Jasper Potts" Date: 2012-12-07 15:37 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/698048c91224 Fixed RT-26814: Scrollbar buttons look bad where they meet the track ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: d33ae5444ad0 Author: Martin Sladecek Date: 2012-12-10 13:41 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d33ae5444ad0 More tests & fixes for SequentialTransition. ! javafx-ui-common/src/javafx/animation/SequentialTransition.java ! javafx-ui-common/test/unit/javafx/animation/SequentialTransitionPlayTest.java Changeset: e4f650594652 Author: Martin Sladecek Date: 2012-12-10 13:42 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e4f650594652 merge Changeset: 6ad8578c9044 Author: Milan Kubec Date: 2012-12-11 15:39 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6ad8578c9044 additional asserts; patch applied in behalf of QA ! javafx-fxml/src/javafx/fxml/doc-files/introduction_to_fxml.html Changeset: d42c1ae9369a Author: Milan Kubec Date: 2012-12-11 14:40 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d42c1ae9369a Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfx////rt Changeset: 5e68c3c1e45f Author: jpgodine at JPGODINE-LAP.st-users.us.oracle.com Date: 2012-12-11 10:11 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5e68c3c1e45f Automated merge with ssh://jpgodine at jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: fa103e8c9776 Author: hudson Date: 2012-12-13 16:55 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fa103e8c9776 Added tag 8.0-b68 for changeset 5e68c3c1e45f ! .hgtags From zonski at gmail.com Thu Dec 13 17:43:08 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 14 Dec 2012 12:43:08 +1100 Subject: Reliable deployment idea: JNLP Launcher exe/dmg In-Reply-To: <4F41ABC9-EDA1-451D-8345-C9826683406B@reportmill.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C2FC51.80208@jugs.org> <6B515693-B119-4853-BD71-C9F78917F93B@oracle.com> <01a801cdd5ce$58e1e170$0aa5a450$@com.au> <9EF244F8-AB86-4234-B2A7-6D672A601788@gmail.com> <7915E1FB-F436-4260-8F2E-FF9CDCC1450A@reportmill.com> <4F41ABC9-EDA1-451D-8345-C9826683406B@reportmill.com> Message-ID: In your exe and dmg do you want the JRE co-bundled into each? It does sound like you basically want the existing native packaging tools but with AU support? As a general aside/heads-up, I think you will likely find more problems with JNLP than in the past, the 64bit-32bit cross-over has known bugs, and the forced auto-updating (i.e. you can't actually pin your app to a Java version in the JNLP going forward) causes new problems. Add to that the risk of CSS changes being uncontainable (a change could affect anything anywhere), and the fact that Swing was more or less stable for 10 years whereas FX is rapidly growing and not looking to stabalize any time soon (I hope!), and you have some pretty rocky ground to stand on. I'd be cautious about treating JNLP with the same confidence you might have had with it in the past. I took that approach on my project and had some frustrated users (stuff wouldn't launch because of the 64bit issue, lots of uninstalling/re-installing) and narrowly avoided a system death when 2.2 was released. FXML changed, breaking my code and a ComboBox class was added which clashed with my own - since I couldn't pin my app to a version, had I not caught this ahead of time, my live app would have stopped working the instant users were forced to upgrade their JRE. And that's with Richard being super defensive about backwards compatibility to the point of not allowing interfaces in the code! On Fri, Dec 14, 2012 at 12:17 PM, Jeff Martin wrote: > Mark, I definitely don't want Oracle to have an app store. App stores are > very evil, if done right. :-) > > Dan, I guess I'm mostly thinking of my deployment scenario with ReportMill > (and Java Inventor). I have had good luck with our ReportMill.jnlp Web > Start link because our customers are developers who generally have a > working, up to date JRE. I update my ReportMill.jar about once a month and > my customers get the update automatically. > > When things don't work, I think it's because the browser didn't handle the > JNLP-link/WebStart launch correctly, or they don't have the correct version > of Java, and/or the JRE update mechanism doesn't work, or the installed JRE > installation is corrupted somehow, or the cache is confused. There may also > be security and/or permissions problems with a general JRE installation. > Probably the best way to clear this up is to have them uninstall Java and > re-install the latest version. But I can't realistically guarantee that my > latest version works with all the last 10 updates or the next 100 updates > of the JRE. > > So having the GreatApp.exe and GreatApp.dmg options available, to me, > simplifies the step of making sure that the JRE is a clean, uncompromised, > compliant (for my app) installation. But I don't want a static version of > my app and I don't want to have to rebuild the .exe/.dmg every time I have > an update (nor could I expect my customers to regularly re-install my app). > > So maybe my scenario isn't common for everyone. But I think this is a > reasonably trouble free way of deploying an auto-updating app without > having to send users to a generic JRE install (and then help some of them > troubleshoot it). I only suggest NetBeans because building the .exe/.dmg > would be a rare occurrence. > > I have built a launcher like this before (Sun paid us to do one for a > version of JFXBuilder years ago), so I already have some utility methods > for checking for a new GreatApp.jar.pack.gz, downloading it, unpacking it > and class loading it. I think it was only a few pages of code. :-) > > jeff > > On Dec 13, 2012, at 6:32 PM, Daniel Zwolenski wrote: > > > Hey Jeff, > > > > I don't fully follow your suggestion (i.e. which bits are native, which > bits are Java and which bits are downloaded when) but I don't think it will > be quite as simple as this unfortunately (I've spent many a night laying > awake, staring at the ceiling trying to work out a clean way to do > deployment). > > > > Maybe you could clarify some aspects of your suggestion though: > > > > > > What if we build a Netbeans JNLP launcher project > > > > Do you mean a new open source Java project here that provides extra > deployment functionality that others can leverage? Or are you giving an > example of a user creating a new "GreatApp" project that they want to > launch? > > > > Is your launcher project native code or Java code and what role does > Netbeans have in this (I wouldn't do anything IDE specific and passionately > disagree with the Netbeans bias of JFX - everything should be IDE > agnostic). How does the Launcher work and what does it do? > > > > > > that you customize with just a link to a JNLP and a splash image, > > > > Where does the JNLP come from, what is building it - are we just > building a normal JFX webstart bundle here or is this a special JNLP file? > > > > > > and it builds your GreatApp.exe and GreatApp.dmg. > > > > What builds this? To create an 'exe' you have to build on Windows (plus > 32 bit on 32 bit, and 64bit on 64 bit), whereas to build a DMG you > currently have to be on Mac. There's no nice utility where you just go > build-me-all-my-installers-for-all-platforms. Partly this is due to > technology issues with each OS (e.g. MSI's can only be built on Windows) > and partly it is due to the JRE not being available for co-bundling > anywhere (the only one you have is the one installed on your machine), see > http://javafx-jira.kenai.com/browse/RT-22964 > > > > If this step was small and simple, the rest of it would be easy and we > wouldn't really need JNLP, webstart, etc. > > > > > > The launcher app would simply fetch the JNLP, download the jars (if > newer than cache), load them, and invoke MainClass.main(). > > > > This is what JNLP does at the moment. I assume you mean it add some > value somewhere but I'm missing what exactly that is? Note there is even a > pre-launcher MainClass in the JFX packaging tools that does some JFX checks > and updating stuff (it's weird and messy). > > > > > > Then on your website you can say, > > > > If you have Java, try the Web Start link [ here ] or > > Download [ GreatApp.exe ] or [ GreatApp.dmg ] > > > > In this case the JNLP file is a traditional one or something new and > special? If it is a traditional one then you cannot pin it to a JRE and > have all the problems we know about. If it is something special, I'm not > sure what that special is or how the specialness gets hooked into the > start-up process (since if you install Java the JNLP will be opened with > Java). > > > > In this case do GreatApp.exe and GreatApp.dmg have the JRE co-bundled > into them - i.e. they are just like the installers we can build now? > > > > If the JNLP is not special and the native installers are the same as now > then I'm missing what you're adding to what we have now (i.e. you can > produce the above website right now)? > > > > The only thing I think you might be suggesting is auto-updating of the > exe/dmg based apps, which is not currently supported but planned by Oracle > (unknown timeframe). Additionally there were a lot of discussions around > adding AU and I have put up prototype code for this that can be used to do > this (but it is raw and cludgy). > > > > See this discussion: > http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-June/002433.html > > > > > > > > So the benefit over plain web start is that your GreatApp would have a > consistent, self-contained execution environment, in the event that the > target system doesn't have an installed JRE that is the right version or > uncorrupted. > > > > I'm missing how this happens? Can you clarify. > > > > You also don't get scary warning panels or signing issues. > > > > Currently you don't have any of this with the native installers. The JRE > is co-bundled and never installed so you side-step the JRE installation > horrors. > > > > The problems with native installers that need to be addressed are: > > - Auto updating > > - Reduce the JRE size to make smaller downloads > > - Being able to build native releases on multiple platforms > > > > > > > > But you would still get the benefit of simple upgrades that WebStart > gives you. And you wouldn't have to constantly generate a new .exe/.dmg > (maybe once or twice a year if you decide a new JRE update would benefit > your app). > > > > This is basically just adding Auto Updating (AU) support to native > installers. > > > > If your open source project is to add this then I'm in for that. I've > already done a POC: > http://code.google.com/p/zen-update/source/browse/trunk/ > > > > I ported JFX Ensemble to include auto updating support: > http://zenjava.com/demo/update/ensemble/EnsembleWithZenUpdate-1.0.exe > > > > Work on this stalled because the JFX deployment team were > unable/uninterested in implementing the changes needed to support this work. > > > > Once the packaging tools get open sourced (which is overdue) then the > community can take over this work (and it is on my todo list). So long as > the code remains behind the Oracle iron curtain however, we are hamstrung > unless we want to re-implement most of what they have done from the ground > up. This is an option but seems wasteful when the OS of the packaging code > is suppose to be soon (but "soon" seems to be a very loose term). > > > > > > Such a Netbeans project would probably only be a dozen pages of code. > > > > Sounds ambitious :) > > > > Here's an even better idea - Oracle sets up a server that will take any > JNLP link and dynamically generates a .exe/.dmg for us. :-) > > > > > > You may be interested in this JIRA for this: > > http://javafx-jira.kenai.com/browse/RT-22994 > > http://javafx-jira.kenai.com/browse/RT-22995 > > > > I'm keen to explore this topic with anyone and everyone wanting to do > so. I like that you are looking at it but I'm either missing something > about your suggestion or it's a bit too simple in it's approach to provide > a solution. If I'm missing something then I really want to know what! If > I'm not then I'm happy to help expose all the nasty complexities around > this area if you want. > > > > Cheers, > > Dan > > > > > > > > > > > > From zonski at gmail.com Thu Dec 13 20:35:49 2012 From: zonski at gmail.com (Daniel Zwolenski) Date: Fri, 14 Dec 2012 15:35:49 +1100 Subject: Reliable deployment idea: JNLP Launcher exe/dmg In-Reply-To: References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C2FC51.80208@jugs.org> <6B515693-B119-4853-BD71-C9F78917F93B@oracle.com> <01a801cdd5ce$58e1e170$0aa5a450$@com.au> <9EF244F8-AB86-4234-B2A7-6D672A601788@gmail.com> <7915E1FB-F436-4260-8F2E-FF9CDCC1450A@reportmill.com> <4F41ABC9-EDA1-451D-8345-C9826683406B@reportmill.com> Message-ID: As an aside, I agree that Oracle shouldn't try to do it's own App store - Oracle is not consumer focused enough (and not a consumer brand name) to compete with the other big vendors in the space. Far better to collaborate and team up with other vendors like MS, Google, etc, to ensure smooth Java support. In my opinion though AppStores are the unexpected light in the dark for JFX deployment. All of our web-based installer methods in Java are dead or dying (webstart, applet). Native installers are our last option and are ok, but they have a lot of issues some of which may well be unsolvable (e.g. building installers for each platform). Meanwhile some platforms (e.g. Mac) may well be AppStore only before long, blocking the native installer option for us. Ironically, we are seeing a small resurgence of interest in "desktop apps" thanks to the mobile/smart device revolution. On mobile, "apps" and "app stores" are seen as richer/faster/more-appealing than "web apps". On a technical level the gap between "desktop apps" and "webapps" has been steadily closing but "desktop apps" are getting a PR boost just by association with the "app" concept. Meanwhile the hugely successful commercial strategy of the iOS app store has caught the interest of the money guys, and they are trying to work out how to replicate this on the desktop side of things. As a result, the big players and OS vendors are actually competing with each other to provide us with a clean, easy way to get desktop apps onto their platforms. Of course the trade off is we have to get our apps reviewed and go through red-tape but as we've seen with the iOS app store, this is not an overall barrier to development and getting apps out there. In fact the ease of installation and the added trust users have in terms of payments, viruses and spamware aid distribution and make the cost of dealing with the red-tape insignificant by comparison. The biggest risk to us within the AppStore era in the JFX/Java space is getting locked out by the vendors. Not sure how we mitigate this risk (maybe Ellison, Ballmer and Page could group hug?), but keeping an eye on, and adjusting to, the licencing issues around AppStores is a good start, e.g. we can't deploy GPL projects (such as OpenJDK based ones) into the Apple app store (mobile or desktop) so we need to bias towards solutions that aren't limited by this. I never thought I'd say it, but bring on the AppStore era. On Fri, Dec 14, 2012 at 12:43 PM, Daniel Zwolenski wrote: > > In your exe and dmg do you want the JRE co-bundled into each? It does > sound like you basically want the existing native packaging tools but with > AU support? > > As a general aside/heads-up, I think you will likely find more problems > with JNLP than in the past, the 64bit-32bit cross-over has known bugs, and > the forced auto-updating (i.e. you can't actually pin your app to a Java > version in the JNLP going forward) causes new problems. Add to that the > risk of CSS changes being uncontainable (a change could affect anything > anywhere), and the fact that Swing was more or less stable for 10 years > whereas FX is rapidly growing and not looking to stabalize any time soon (I > hope!), and you have some pretty rocky ground to stand on. > > I'd be cautious about treating JNLP with the same confidence you might > have had with it in the past. I took that approach on my project and had > some frustrated users (stuff wouldn't launch because of the 64bit issue, > lots of uninstalling/re-installing) and narrowly avoided a system death > when 2.2 was released. FXML changed, breaking my code and a ComboBox class > was added which clashed with my own - since I couldn't pin my app to a > version, had I not caught this ahead of time, my live app would have > stopped working the instant users were forced to upgrade their JRE. And > that's with Richard being super defensive about backwards compatibility to > the point of not allowing interfaces in the code! > > > On Fri, Dec 14, 2012 at 12:17 PM, Jeff Martin wrote: > >> Mark, I definitely don't want Oracle to have an app store. App stores are >> very evil, if done right. :-) >> >> Dan, I guess I'm mostly thinking of my deployment scenario with >> ReportMill (and Java Inventor). I have had good luck with our >> ReportMill.jnlp Web Start link because our customers are developers who >> generally have a working, up to date JRE. I update my ReportMill.jar about >> once a month and my customers get the update automatically. >> >> When things don't work, I think it's because the browser didn't handle >> the JNLP-link/WebStart launch correctly, or they don't have the correct >> version of Java, and/or the JRE update mechanism doesn't work, or the >> installed JRE installation is corrupted somehow, or the cache is confused. >> There may also be security and/or permissions problems with a general JRE >> installation. Probably the best way to clear this up is to have them >> uninstall Java and re-install the latest version. But I can't realistically >> guarantee that my latest version works with all the last 10 updates or the >> next 100 updates of the JRE. >> >> So having the GreatApp.exe and GreatApp.dmg options available, to me, >> simplifies the step of making sure that the JRE is a clean, uncompromised, >> compliant (for my app) installation. But I don't want a static version of >> my app and I don't want to have to rebuild the .exe/.dmg every time I have >> an update (nor could I expect my customers to regularly re-install my app). >> >> So maybe my scenario isn't common for everyone. But I think this is a >> reasonably trouble free way of deploying an auto-updating app without >> having to send users to a generic JRE install (and then help some of them >> troubleshoot it). I only suggest NetBeans because building the .exe/.dmg >> would be a rare occurrence. >> >> I have built a launcher like this before (Sun paid us to do one for a >> version of JFXBuilder years ago), so I already have some utility methods >> for checking for a new GreatApp.jar.pack.gz, downloading it, unpacking it >> and class loading it. I think it was only a few pages of code. :-) >> >> jeff >> >> On Dec 13, 2012, at 6:32 PM, Daniel Zwolenski wrote: >> >> > Hey Jeff, >> > >> > I don't fully follow your suggestion (i.e. which bits are native, which >> bits are Java and which bits are downloaded when) but I don't think it will >> be quite as simple as this unfortunately (I've spent many a night laying >> awake, staring at the ceiling trying to work out a clean way to do >> deployment). >> > >> > Maybe you could clarify some aspects of your suggestion though: >> > >> > >> > What if we build a Netbeans JNLP launcher project >> > >> > Do you mean a new open source Java project here that provides extra >> deployment functionality that others can leverage? Or are you giving an >> example of a user creating a new "GreatApp" project that they want to >> launch? >> > >> > Is your launcher project native code or Java code and what role does >> Netbeans have in this (I wouldn't do anything IDE specific and passionately >> disagree with the Netbeans bias of JFX - everything should be IDE >> agnostic). How does the Launcher work and what does it do? >> > >> > >> > that you customize with just a link to a JNLP and a splash image, >> > >> > Where does the JNLP come from, what is building it - are we just >> building a normal JFX webstart bundle here or is this a special JNLP file? >> > >> > >> > and it builds your GreatApp.exe and GreatApp.dmg. >> > >> > What builds this? To create an 'exe' you have to build on Windows (plus >> 32 bit on 32 bit, and 64bit on 64 bit), whereas to build a DMG you >> currently have to be on Mac. There's no nice utility where you just go >> build-me-all-my-installers-for-all-platforms. Partly this is due to >> technology issues with each OS (e.g. MSI's can only be built on Windows) >> and partly it is due to the JRE not being available for co-bundling >> anywhere (the only one you have is the one installed on your machine), see >> http://javafx-jira.kenai.com/browse/RT-22964 >> > >> > If this step was small and simple, the rest of it would be easy and we >> wouldn't really need JNLP, webstart, etc. >> > >> > >> > The launcher app would simply fetch the JNLP, download the jars (if >> newer than cache), load them, and invoke MainClass.main(). >> > >> > This is what JNLP does at the moment. I assume you mean it add some >> value somewhere but I'm missing what exactly that is? Note there is even a >> pre-launcher MainClass in the JFX packaging tools that does some JFX checks >> and updating stuff (it's weird and messy). >> > >> > >> > Then on your website you can say, >> > >> > If you have Java, try the Web Start link [ here ] or >> > Download [ GreatApp.exe ] or [ GreatApp.dmg ] >> > >> > In this case the JNLP file is a traditional one or something new and >> special? If it is a traditional one then you cannot pin it to a JRE and >> have all the problems we know about. If it is something special, I'm not >> sure what that special is or how the specialness gets hooked into the >> start-up process (since if you install Java the JNLP will be opened with >> Java). >> > >> > In this case do GreatApp.exe and GreatApp.dmg have the JRE co-bundled >> into them - i.e. they are just like the installers we can build now? >> > >> > If the JNLP is not special and the native installers are the same as >> now then I'm missing what you're adding to what we have now (i.e. you can >> produce the above website right now)? >> > >> > The only thing I think you might be suggesting is auto-updating of the >> exe/dmg based apps, which is not currently supported but planned by Oracle >> (unknown timeframe). Additionally there were a lot of discussions around >> adding AU and I have put up prototype code for this that can be used to do >> this (but it is raw and cludgy). >> > >> > See this discussion: >> http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-June/002433.html >> > >> > >> > >> > So the benefit over plain web start is that your GreatApp would have a >> consistent, self-contained execution environment, in the event that the >> target system doesn't have an installed JRE that is the right version or >> uncorrupted. >> > >> > I'm missing how this happens? Can you clarify. >> > >> > You also don't get scary warning panels or signing issues. >> > >> > Currently you don't have any of this with the native installers. The >> JRE is co-bundled and never installed so you side-step the JRE installation >> horrors. >> > >> > The problems with native installers that need to be addressed are: >> > - Auto updating >> > - Reduce the JRE size to make smaller downloads >> > - Being able to build native releases on multiple platforms >> > >> > >> > >> > But you would still get the benefit of simple upgrades that WebStart >> gives you. And you wouldn't have to constantly generate a new .exe/.dmg >> (maybe once or twice a year if you decide a new JRE update would benefit >> your app). >> > >> > This is basically just adding Auto Updating (AU) support to native >> installers. >> > >> > If your open source project is to add this then I'm in for that. I've >> already done a POC: >> http://code.google.com/p/zen-update/source/browse/trunk/ >> > >> > I ported JFX Ensemble to include auto updating support: >> http://zenjava.com/demo/update/ensemble/EnsembleWithZenUpdate-1.0.exe >> > >> > Work on this stalled because the JFX deployment team were >> unable/uninterested in implementing the changes needed to support this work. >> > >> > Once the packaging tools get open sourced (which is overdue) then the >> community can take over this work (and it is on my todo list). So long as >> the code remains behind the Oracle iron curtain however, we are hamstrung >> unless we want to re-implement most of what they have done from the ground >> up. This is an option but seems wasteful when the OS of the packaging code >> is suppose to be soon (but "soon" seems to be a very loose term). >> > >> > >> > Such a Netbeans project would probably only be a dozen pages of code. >> > >> > Sounds ambitious :) >> > >> > Here's an even better idea - Oracle sets up a server that will take any >> JNLP link and dynamically generates a .exe/.dmg for us. :-) >> > >> > >> > You may be interested in this JIRA for this: >> > http://javafx-jira.kenai.com/browse/RT-22994 >> > http://javafx-jira.kenai.com/browse/RT-22995 >> > >> > I'm keen to explore this topic with anyone and everyone wanting to do >> so. I like that you are looking at it but I'm either missing something >> about your suggestion or it's a bit too simple in it's approach to provide >> a solution. If I'm missing something then I really want to know what! If >> I'm not then I'm happy to help expose all the nasty complexities around >> this area if you want. >> > >> > Cheers, >> > Dan >> > >> > >> > >> > >> > >> >> > From lubomir.nerad at oracle.com Fri Dec 14 02:51:51 2012 From: lubomir.nerad at oracle.com (Lubomir Nerad) Date: Fri, 14 Dec 2012 11:51:51 +0100 Subject: [REVIEW REQUEST] RT-24088 Add API to JavaFX to allow vetoing the closing of a Tab in a TabPane In-Reply-To: <50C11782.7090407@oracle.com> References: <50BFED62.1070804@bestsolution.at> <50C03656.6020903@tbee.org> <50C08247.2060600@media-interactive.de> <50C09E8E.1090909@bestsolution.at> <50C0BFAE.8000808@oracle.com> <50C11358.8030700@bestsolution.at> <50C11782.7090407@oracle.com> Message-ID: <50CB04C7.7070001@oracle.com> On 6.12.2012 23:09, Jonathan Giles wrote: > Richard and I were just chatting about this patch, and the general > feeling is that it feels weird to consume an event and make that > indicate the event has been vetoed (despite that being how it is > already done in the Window case). In the case of Window the WINDOW_CLOSE_REQUEST indicates that user wants to close the corresponding Window. As with any other event, the application can install its own handler to this event and respond to this request in its own way. If it does so, it should indicate that the event has been handled by "consuming" the corresponding event (as should be done with any other user handled event). If the event is not handled by the application code, the default handler simply closes the corresponding window. This API was approved by Richard and I am surprised he finds it weird now. Lubo > It just feels like a bit of a side effect, rather than the actual > intent of consume() (which is to prevent event propagation, not to > pass on additional information such as the state of a veto command). > > An option is to add a new property to TabEvent that makes it clearer > to developers that they are telling the tab not to be closed. Richard > suggested having a 'vetoOnClose' property on TabEvent, and to use this > rather than consume. > > Regarding the location from where the event is fired, the primary > requirement is to ensure that this event is fired in all cases when a > Tab is closed. If that requirement is met I don't think there is a > massive concern about where the event itself fires from. > > Other than that the patch looks fine. > > -- Jonathan > > On 7/12/2012 10:51 a.m., Tom Schindl wrote: >> Hi, >> >> I've uploaded a revised patch which now works using the event system >> sending out an TabEvent of type "TAB_CLOSE_REQUEST". >> >> So the revised API on Tab would now be: >> + ObjectProperty> onCloseRequestProperty() >> + EventHandler getOnCloseRequest() >> + setOnCloseRequests(EventHandler value) >> >> and vetoing a close would look like this: >> >> Tab tab1 = new Tab("Hello"); >> tab1.setOnCloseRequests(new EventHandler() { >> >> @Override >> public void handle(TabEvent event) { >> event.consume(); >> } >> }); >> >> Thanks for the input Werner, Steven and Richard. >> >> One thing I was not sure is who is supposed to deliver an event. I used >> the TabPaneBehavior maybe the Tab itself should send out this event? >> >> Tom >> >> Am 06.12.12 17:04, schrieb Richard Bair: >>> Indeed, this sounds like the same idea Werner had. Good find. >>> >>> On Dec 6, 2012, at 7:54 AM, steve.x.northover at oracle.com wrote: >>> >>>> Stage has the onCloseRequest property. Might make sense to have a >>>> similar API in Tab. >>>> >>>> Steve >>>> >>>> On 06/12/2012 8:33 AM, Tom Schindl wrote: >>>>> Hi, >>>>> >>>>> This is an interesting idea. I'm not that deep in the FX-API to >>>>> understand if this the advised way in other areas so. I let >>>>> Richard and >>>>> Jonathan comment on it. >>>>> >>>>> Tom >>>>> >>>>> Am 06.12.12 12:32, schrieb Werner Lehmann: >>>>>> Would it also be possible to have a simple onClosing event and >>>>>> require a >>>>>> handler to Event.consume() it? Maybe slightly less obvious than an >>>>>> explicit "*veto*" but more flexible/resuable, too (as a general >>>>>> pattern >>>>>> in similar situations). >>>>>> >>>>>> Werner >>>>>> >>>>>> On 06.12.2012 07:08, Tom Eugelink wrote: >>>>>>> Just a remark to see if we can make this more reusable; would it be >>>>>>> an idea to actually veto the close action? Like veto the removal >>>>>>> of a >>>>>>> tab from a list? In that way veto-ing would be available to other >>>>>>> usages of such lists as well, a uniform API. >>>>>>> >>>>>>> Tom >> > From swpalmer at gmail.com Fri Dec 14 04:38:02 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 14 Dec 2012 07:38:02 -0500 Subject: [REVIEW REQUEST] RT-24088 Add API to JavaFX to allow vetoing the closing of a Tab in a TabPane In-Reply-To: <50CB04C7.7070001@oracle.com> References: <50BFED62.1070804@bestsolution.at> <50C03656.6020903@tbee.org> <50C08247.2060600@media-interactive.de> <50C09E8E.1090909@bestsolution.at> <50C0BFAE.8000808@oracle.com> <50C11358.8030700@bestsolution.at> <50C11782.7090407@oracle.com> <50CB04C7.7070001@oracle.com> Message-ID: <746C6CA0-6464-459D-9477-6AAF776E5E1D@gmail.com> On 2012-12-14, at 5:51 AM, Lubomir Nerad wrote: > On 6.12.2012 23:09, Jonathan Giles wrote: >> Richard and I were just chatting about this patch, and the general feeling is that it feels weird to consume an event and make that indicate the event has been vetoed (despite that being how it is already done in the Window case). > > In the case of Window the WINDOW_CLOSE_REQUEST indicates that user wants to close the corresponding Window. As with any other event, the application can install its own handler to this event and respond to this request in its own way. If it does so, it should indicate that the event has been handled by "consuming" the corresponding event (as should be done with any other user handled event). If the event is not handled by the application code, the default handler simply closes the corresponding window. This API was approved by Richard and I am surprised he finds it weird now. > > Lubo >> It just feels like a bit of a side effect, rather than the actual intent of consume() (which is to prevent event propagation, not to pass on additional information such as the state of a veto command). >> I think consuming the event is the most natural way to do this. Preventing event propagation to the code that would otherwise act on it is exactly what we want. There is no need to introduce a new concept here. Scott From omeuefilipe at gmail.com Fri Dec 14 05:01:12 2012 From: omeuefilipe at gmail.com (Filipe Portes) Date: Fri, 14 Dec 2012 11:01:12 -0200 Subject: Drombler FX: building modular JavaFX applications with OSGi and Maven In-Reply-To: <50CA478E.1040103@bestsolution.at> References: <1468973.LLaJQ6I9jc@shire> <50CA478E.1040103@bestsolution.at> Message-ID: Hi tom, I follow your projects for long time, really like... i'm such a fan!! I created the moduleFX for the 2.1 JavaFX, and JDK version without preinstalled JavaFX, never tested for the newer versions... for sure I'll look at florian domblerFX to learn how to manage this problem!! Thanks for the tips!! On Thu, Dec 13, 2012 at 7:24 PM, Tom Schindl wrote: > Hi Filipe, > > From code inspection I think Florians solution is the way to get JavaFX > running in Felix because he's modifying > "org.osgi.framework.system.packages.extra". If I'm not 100% mistaken > your solution will hit what I describe at > http://tomsondev.bestsolution.at/2012/08/01/javafx-2-2-and-osgi/ in the > "Straight Repackageing" section. > > In short: If a user runs with your solution on a JDK which has JavaFX > preinstalled the native code from the JDK will be picked up and the > Java-Code from your module-fx and there are good chances that they don't > match! > > If I got the solution from Florian right he's using > org.osgi.framework.system.packages.extra to teach OSGi the new packages > and somehow modifies the application classpath, or something similar. > > My Equinox solution on the other hand has the advantage that you don't > have to control the bootstraping which is e.g. the case when you want to > use JavaFX inside an Eclipse Plugin. > > Tom > > Am 13.12.12 18:00, schrieb Filipe Portes: > > Hi everyone, > > > > I create a simple project called ModuleFX that also make you capable of > run > > JavaFX application over OSGI, It's still very simple, but if anyone get > > intersted here's the link: > > https://github.com/filipeportes/ModuleFX > > > > > > On Sun, Dec 9, 2012 at 11:09 AM, Florian Brunner >wrote: > > > >> Hi everybody, > >> > >> I'm happy to announce the availabilty of a first Early Access version of > >> Drombler FX. Drombler FX is a modular Rich Client Platform for JavaFX. > >> > >> You can read more about it here: http://puces- > >> blog.blogspot.ch/2012/12/drombler-fx-building-modular-javafx.html > >> > >> There's a Getting Started page which explains how to create, build and > run > >> a > >> Drombler FX sample application with a few simple steps: > >> > >> http://wiki.drombler.org/GettingStarted > >> > >> - Florian > >> > > > > > > > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 > -- Filipe Portes - @filipeportes Java Architect - Senior Java EE/Web JUGLeader Gojava - @gojava From jeff at reportmill.com Fri Dec 14 05:23:05 2012 From: jeff at reportmill.com (Jeff Martin) Date: Fri, 14 Dec 2012 07:23:05 -0600 Subject: Reliable deployment idea: JNLP Launcher exe/dmg In-Reply-To: References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C2FC51.80208@jugs.org> <6B515693-B119-4853-BD71-C9F78917F93B@oracle.com> <01a801cdd5ce$58e1e170$0aa5a450$@com.au> <9EF244F8-AB86-4234-B2A7-6D672A601788@gmail.com> <7915E1FB-F436-4260-8F2E-FF9CDCC1450A@reportmill.com> <4F41ABC9-EDA1-451D-8345-C9826683406B@reportmill.com> Message-ID: <38520EC1-578D-4011-A537-1DFF6F296562@reportmill.com> I can't disagree with most of that - but I also can't help but feel Apple set up a big toll booth for app developers (complete with bureaucracy and censorship). I don't want to have to go hat-in-hand to anyone for approval to release my app, and I don't want to part with 30% of the proceeds unless they are contributing serious sales and marketing effort. Not to cry a river for Oracle, but it seems a shame that my app(s) rely so heavily on Java and JavaFX, yet Apple walks away with 30% and Oracle 0%. Yet if Oracle were to charge 30% for their significant contribution, app developers might as well give up. I'm a former Apple employee and a stock holder - but their precedent scares me. And I was a Steve Jobs hero worshipper, but I always said if Apple was as big as Microsoft, they'd probably be at least as evil. :-) jeff On Dec 13, 2012, at 10:35 PM, Daniel Zwolenski wrote: > As an aside, I agree that Oracle shouldn't try to do it's own App store - Oracle is not consumer focused enough (and not a consumer brand name) to compete with the other big vendors in the space. Far better to collaborate and team up with other vendors like MS, Google, etc, to ensure smooth Java support. > > In my opinion though AppStores are the unexpected light in the dark for JFX deployment. All of our web-based installer methods in Java are dead or dying (webstart, applet). Native installers are our last option and are ok, but they have a lot of issues some of which may well be unsolvable (e.g. building installers for each platform). Meanwhile some platforms (e.g. Mac) may well be AppStore only before long, blocking the native installer option for us. > > Ironically, we are seeing a small resurgence of interest in "desktop apps" thanks to the mobile/smart device revolution. On mobile, "apps" and "app stores" are seen as richer/faster/more-appealing than "web apps". On a technical level the gap between "desktop apps" and "webapps" has been steadily closing but "desktop apps" are getting a PR boost just by association with the "app" concept. Meanwhile the hugely successful commercial strategy of the iOS app store has caught the interest of the money guys, and they are trying to work out how to replicate this on the desktop side of things. As a result, the big players and OS vendors are actually competing with each other to provide us with a clean, easy way to get desktop apps onto their platforms. > > Of course the trade off is we have to get our apps reviewed and go through red-tape but as we've seen with the iOS app store, this is not an overall barrier to development and getting apps out there. In fact the ease of installation and the added trust users have in terms of payments, viruses and spamware aid distribution and make the cost of dealing with the red-tape insignificant by comparison. > > The biggest risk to us within the AppStore era in the JFX/Java space is getting locked out by the vendors. Not sure how we mitigate this risk (maybe Ellison, Ballmer and Page could group hug?), but keeping an eye on, and adjusting to, the licencing issues around AppStores is a good start, e.g. we can't deploy GPL projects (such as OpenJDK based ones) into the Apple app store (mobile or desktop) so we need to bias towards solutions that aren't limited by this. > > I never thought I'd say it, but bring on the AppStore era. > > > > > On Fri, Dec 14, 2012 at 12:43 PM, Daniel Zwolenski wrote: > > In your exe and dmg do you want the JRE co-bundled into each? It does sound like you basically want the existing native packaging tools but with AU support? > > As a general aside/heads-up, I think you will likely find more problems with JNLP than in the past, the 64bit-32bit cross-over has known bugs, and the forced auto-updating (i.e. you can't actually pin your app to a Java version in the JNLP going forward) causes new problems. Add to that the risk of CSS changes being uncontainable (a change could affect anything anywhere), and the fact that Swing was more or less stable for 10 years whereas FX is rapidly growing and not looking to stabalize any time soon (I hope!), and you have some pretty rocky ground to stand on. > > I'd be cautious about treating JNLP with the same confidence you might have had with it in the past. I took that approach on my project and had some frustrated users (stuff wouldn't launch because of the 64bit issue, lots of uninstalling/re-installing) and narrowly avoided a system death when 2.2 was released. FXML changed, breaking my code and a ComboBox class was added which clashed with my own - since I couldn't pin my app to a version, had I not caught this ahead of time, my live app would have stopped working the instant users were forced to upgrade their JRE. And that's with Richard being super defensive about backwards compatibility to the point of not allowing interfaces in the code! > > > On Fri, Dec 14, 2012 at 12:17 PM, Jeff Martin wrote: > Mark, I definitely don't want Oracle to have an app store. App stores are very evil, if done right. :-) > > Dan, I guess I'm mostly thinking of my deployment scenario with ReportMill (and Java Inventor). I have had good luck with our ReportMill.jnlp Web Start link because our customers are developers who generally have a working, up to date JRE. I update my ReportMill.jar about once a month and my customers get the update automatically. > > When things don't work, I think it's because the browser didn't handle the JNLP-link/WebStart launch correctly, or they don't have the correct version of Java, and/or the JRE update mechanism doesn't work, or the installed JRE installation is corrupted somehow, or the cache is confused. There may also be security and/or permissions problems with a general JRE installation. Probably the best way to clear this up is to have them uninstall Java and re-install the latest version. But I can't realistically guarantee that my latest version works with all the last 10 updates or the next 100 updates of the JRE. > > So having the GreatApp.exe and GreatApp.dmg options available, to me, simplifies the step of making sure that the JRE is a clean, uncompromised, compliant (for my app) installation. But I don't want a static version of my app and I don't want to have to rebuild the .exe/.dmg every time I have an update (nor could I expect my customers to regularly re-install my app). > > So maybe my scenario isn't common for everyone. But I think this is a reasonably trouble free way of deploying an auto-updating app without having to send users to a generic JRE install (and then help some of them troubleshoot it). I only suggest NetBeans because building the .exe/.dmg would be a rare occurrence. > > I have built a launcher like this before (Sun paid us to do one for a version of JFXBuilder years ago), so I already have some utility methods for checking for a new GreatApp.jar.pack.gz, downloading it, unpacking it and class loading it. I think it was only a few pages of code. :-) > > jeff > > On Dec 13, 2012, at 6:32 PM, Daniel Zwolenski wrote: > > > Hey Jeff, > > > > I don't fully follow your suggestion (i.e. which bits are native, which bits are Java and which bits are downloaded when) but I don't think it will be quite as simple as this unfortunately (I've spent many a night laying awake, staring at the ceiling trying to work out a clean way to do deployment). > > > > Maybe you could clarify some aspects of your suggestion though: > > > > > > What if we build a Netbeans JNLP launcher project > > > > Do you mean a new open source Java project here that provides extra deployment functionality that others can leverage? Or are you giving an example of a user creating a new "GreatApp" project that they want to launch? > > > > Is your launcher project native code or Java code and what role does Netbeans have in this (I wouldn't do anything IDE specific and passionately disagree with the Netbeans bias of JFX - everything should be IDE agnostic). How does the Launcher work and what does it do? > > > > > > that you customize with just a link to a JNLP and a splash image, > > > > Where does the JNLP come from, what is building it - are we just building a normal JFX webstart bundle here or is this a special JNLP file? > > > > > > and it builds your GreatApp.exe and GreatApp.dmg. > > > > What builds this? To create an 'exe' you have to build on Windows (plus 32 bit on 32 bit, and 64bit on 64 bit), whereas to build a DMG you currently have to be on Mac. There's no nice utility where you just go build-me-all-my-installers-for-all-platforms. Partly this is due to technology issues with each OS (e.g. MSI's can only be built on Windows) and partly it is due to the JRE not being available for co-bundling anywhere (the only one you have is the one installed on your machine), see http://javafx-jira.kenai.com/browse/RT-22964 > > > > If this step was small and simple, the rest of it would be easy and we wouldn't really need JNLP, webstart, etc. > > > > > > The launcher app would simply fetch the JNLP, download the jars (if newer than cache), load them, and invoke MainClass.main(). > > > > This is what JNLP does at the moment. I assume you mean it add some value somewhere but I'm missing what exactly that is? Note there is even a pre-launcher MainClass in the JFX packaging tools that does some JFX checks and updating stuff (it's weird and messy). > > > > > > Then on your website you can say, > > > > If you have Java, try the Web Start link [ here ] or > > Download [ GreatApp.exe ] or [ GreatApp.dmg ] > > > > In this case the JNLP file is a traditional one or something new and special? If it is a traditional one then you cannot pin it to a JRE and have all the problems we know about. If it is something special, I'm not sure what that special is or how the specialness gets hooked into the start-up process (since if you install Java the JNLP will be opened with Java). > > > > In this case do GreatApp.exe and GreatApp.dmg have the JRE co-bundled into them - i.e. they are just like the installers we can build now? > > > > If the JNLP is not special and the native installers are the same as now then I'm missing what you're adding to what we have now (i.e. you can produce the above website right now)? > > > > The only thing I think you might be suggesting is auto-updating of the exe/dmg based apps, which is not currently supported but planned by Oracle (unknown timeframe). Additionally there were a lot of discussions around adding AU and I have put up prototype code for this that can be used to do this (but it is raw and cludgy). > > > > See this discussion: http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-June/002433.html > > > > > > > > So the benefit over plain web start is that your GreatApp would have a consistent, self-contained execution environment, in the event that the target system doesn't have an installed JRE that is the right version or uncorrupted. > > > > I'm missing how this happens? Can you clarify. > > > > You also don't get scary warning panels or signing issues. > > > > Currently you don't have any of this with the native installers. The JRE is co-bundled and never installed so you side-step the JRE installation horrors. > > > > The problems with native installers that need to be addressed are: > > - Auto updating > > - Reduce the JRE size to make smaller downloads > > - Being able to build native releases on multiple platforms > > > > > > > > But you would still get the benefit of simple upgrades that WebStart gives you. And you wouldn't have to constantly generate a new .exe/.dmg (maybe once or twice a year if you decide a new JRE update would benefit your app). > > > > This is basically just adding Auto Updating (AU) support to native installers. > > > > If your open source project is to add this then I'm in for that. I've already done a POC: http://code.google.com/p/zen-update/source/browse/trunk/ > > > > I ported JFX Ensemble to include auto updating support: http://zenjava.com/demo/update/ensemble/EnsembleWithZenUpdate-1.0.exe > > > > Work on this stalled because the JFX deployment team were unable/uninterested in implementing the changes needed to support this work. > > > > Once the packaging tools get open sourced (which is overdue) then the community can take over this work (and it is on my todo list). So long as the code remains behind the Oracle iron curtain however, we are hamstrung unless we want to re-implement most of what they have done from the ground up. This is an option but seems wasteful when the OS of the packaging code is suppose to be soon (but "soon" seems to be a very loose term). > > > > > > Such a Netbeans project would probably only be a dozen pages of code. > > > > Sounds ambitious :) > > > > Here's an even better idea - Oracle sets up a server that will take any JNLP link and dynamically generates a .exe/.dmg for us. :-) > > > > > > You may be interested in this JIRA for this: > > http://javafx-jira.kenai.com/browse/RT-22994 > > http://javafx-jira.kenai.com/browse/RT-22995 > > > > I'm keen to explore this topic with anyone and everyone wanting to do so. I like that you are looking at it but I'm either missing something about your suggestion or it's a bit too simple in it's approach to provide a solution. If I'm missing something then I really want to know what! If I'm not then I'm happy to help expose all the nasty complexities around this area if you want. > > > > Cheers, > > Dan > > > > > > > > > > > > > From swpalmer at gmail.com Fri Dec 14 07:39:48 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 14 Dec 2012 10:39:48 -0500 Subject: JFXPanel Message-ID: I'm trying to migrate more of my app from Swing to JavaFX piece-wise via JFXPanels. It's not fun as there are many rough edges. In order to work around some of them I am wondering if it is possible to get a reference to the JFXPanel if all I have is a Node? I can get the Scene's Window, an "Embedded" Window that seems to be the root of a lot of problems with popups and dialogs. That seems to be enough to determine that the Node is hosted by a JFXPanel, but can I actually get the JFXPanel instance? If there is a way via public APIs that don't rely on me peaking at implementation details like com.sun.javafx.stage.EmbeddedWindow? Along this line? why is it that things like the FileChooser and other JavaFX dialogs don't respect the window ordering when used from a JFXPanel? They easily flip behind the parent JFrame. I would have thought that the correct Window hierarchy in native land could still include the native window of the JFrame and that should prevent such things. Scott From richard.bair at oracle.com Fri Dec 14 08:08:49 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 14 Dec 2012 08:08:49 -0800 Subject: [REVIEW REQUEST] RT-24088 Add API to JavaFX to allow vetoing the closing of a Tab in a TabPane In-Reply-To: <50CB04C7.7070001@oracle.com> References: <50BFED62.1070804@bestsolution.at> <50C03656.6020903@tbee.org> <50C08247.2060600@media-interactive.de> <50C09E8E.1090909@bestsolution.at> <50C0BFAE.8000808@oracle.com> <50C11358.8030700@bestsolution.at> <50C11782.7090407@oracle.com> <50CB04C7.7070001@oracle.com> Message-ID: <5517EDFC-0F68-4CFF-8328-A2B3D1CC15A6@oracle.com> >> Richard and I were just chatting about this patch, and the general feeling is that it feels weird to consume an event and make that indicate the event has been vetoed (despite that being how it is already done in the Window case). > > In the case of Window the WINDOW_CLOSE_REQUEST indicates that user wants to close the corresponding Window. As with any other event, the application can install its own handler to this event and respond to this request in its own way. If it does so, it should indicate that the event has been handled by "consuming" the corresponding event (as should be done with any other user handled event). If the event is not handled by the application code, the default handler simply closes the corresponding window. This API was approved by Richard and I am surprised he finds it weird now. Ya, people are always pointing me at change sets I did that I don't remember making. Old age is setting in I'm afraid (and at such a young age too, I'm hosed) :-) From richard.bair at oracle.com Fri Dec 14 08:10:12 2012 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 14 Dec 2012 08:10:12 -0800 Subject: [REVIEW REQUEST] RT-24088 Add API to JavaFX to allow vetoing the closing of a Tab in a TabPane In-Reply-To: <746C6CA0-6464-459D-9477-6AAF776E5E1D@gmail.com> References: <50BFED62.1070804@bestsolution.at> <50C03656.6020903@tbee.org> <50C08247.2060600@media-interactive.de> <50C09E8E.1090909@bestsolution.at> <50C0BFAE.8000808@oracle.com> <50C11358.8030700@bestsolution.at> <50C11782.7090407@oracle.com> <50CB04C7.7070001@oracle.com> <746C6CA0-6464-459D-9477-6AAF776E5E1D@gmail.com> Message-ID: <4F7E1A2F-81EF-4FE7-999C-01AAD128B8A4@oracle.com> >> On 6.12.2012 23:09, Jonathan Giles wrote: >>> Richard and I were just chatting about this patch, and the general feeling is that it feels weird to consume an event and make that indicate the event has been vetoed (despite that being how it is already done in the Window case). >> >> In the case of Window the WINDOW_CLOSE_REQUEST indicates that user wants to close the corresponding Window. As with any other event, the application can install its own handler to this event and respond to this request in its own way. If it does so, it should indicate that the event has been handled by "consuming" the corresponding event (as should be done with any other user handled event). If the event is not handled by the application code, the default handler simply closes the corresponding window. This API was approved by Richard and I am surprised he finds it weird now. >> >> Lubo >>> It just feels like a bit of a side effect, rather than the actual intent of consume() (which is to prevent event propagation, not to pass on additional information such as the state of a veto command). >>> > > I think consuming the event is the most natural way to do this. Preventing event propagation to the code that would otherwise act on it is exactly what we want. There is no need to introduce a new concept here. That make sense. I think I remember the argument now, which was basically the question of what do we do when something needs to be consumed -- do we continue propagating and have a flag and ask each listener to check the flag, or do we just stop propagation. If we wanted an API that said "cancelClose", then it could call consume() behind the scenes, but just provide a somewhat more obvious API that you are to invoke. From lehmann at media-interactive.de Fri Dec 14 08:19:43 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Fri, 14 Dec 2012 17:19:43 +0100 Subject: JFXPanel In-Reply-To: References: Message-ID: <50CB519F.9090302@media-interactive.de> Scott, JFXPanel has quite a few issues (look for JFXPanel or Swing in Jira). Among those is the filechooser problem. It is probably just one instance of the problem that a JavaFX stage cannot be modal or on top of Swing windows. To work around this we have to put JFXPanels in JDialogs. Not really sexy: apart from the overhead in code we know today that we have to touch this again one day to convert the JDialog to a stage. Regarding your problem of how to get from a node to the JFXPanel: no idea why you would want to do this. I have a dozen jfxpanels but never needed such a thing. I guess you could extend JFXPanel and add a reference to the fxpanel to some userdata on a node, or something like that. Rgds Werner On 14.12.2012 16:39, Scott Palmer wrote: > I'm trying to migrate more of my app from Swing to JavaFX piece-wise > via JFXPanels. It's not fun as there are many rough edges. In order > to work around some of them I am wondering if it is possible to get a > reference to the JFXPanel if all I have is a Node? I can get the > Scene's Window, an "Embedded" Window that seems to be the root of a > lot of problems with popups and dialogs. That seems to be enough to > determine that the Node is hosted by a JFXPanel, but can I actually > get the JFXPanel instance? > > If there is a way via public APIs that don't rely on me peaking at > implementation details like com.sun.javafx.stage.EmbeddedWindow? > > Along this line? why is it that things like the FileChooser and other > JavaFX dialogs don't respect the window ordering when used from a > JFXPanel? They easily flip behind the parent JFrame. I would have > thought that the correct Window hierarchy in native land could still > include the native window of the JFrame and that should prevent such > things. > > Scott From chris.bensen at oracle.com Fri Dec 14 08:49:57 2012 From: chris.bensen at oracle.com (Chris Bensen) Date: Fri, 14 Dec 2012 08:49:57 -0800 Subject: Reliable deployment idea: JNLP Launcher exe/dmg In-Reply-To: <38520EC1-578D-4011-A537-1DFF6F296562@reportmill.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C2FC51.80208@jugs.org> <6B515693-B119-4853-BD71-C9F78917F93B@oracle.com> <01a801cdd5ce$58e1e170$0aa5a450$@com.au> <9EF244F8-AB86-4234-B2A7-6D672A601788@gmail.com> <7915E1FB-F436-4260-8F2E-FF9CDCC1450A@reportmill.com> <4F41ABC9-EDA1-451D-8345-C9826683406B@reportmill.com> <38520EC1-578D-4011-A537-1DFF6F296562@reportmill.com> Message-ID: Going forward I'm going to be one of the engineers working on the bundling feature. Currently we are collecting requirements so any input is more than welcome. Hopefully I have enough time to read all of your input :-) Chris On Dec 14, 2012, at 5:23 AM, Jeff Martin wrote: > I can't disagree with most of that - but I also can't help but feel Apple set up a big toll booth for app developers (complete with bureaucracy and censorship). I don't want to have to go hat-in-hand to anyone for approval to release my app, and I don't want to part with 30% of the proceeds unless they are contributing serious sales and marketing effort. > > Not to cry a river for Oracle, but it seems a shame that my app(s) rely so heavily on Java and JavaFX, yet Apple walks away with 30% and Oracle 0%. Yet if Oracle were to charge 30% for their significant contribution, app developers might as well give up. > > I'm a former Apple employee and a stock holder - but their precedent scares me. And I was a Steve Jobs hero worshipper, but I always said if Apple was as big as Microsoft, they'd probably be at least as evil. :-) > > jeff > > On Dec 13, 2012, at 10:35 PM, Daniel Zwolenski wrote: > >> As an aside, I agree that Oracle shouldn't try to do it's own App store - Oracle is not consumer focused enough (and not a consumer brand name) to compete with the other big vendors in the space. Far better to collaborate and team up with other vendors like MS, Google, etc, to ensure smooth Java support. >> >> In my opinion though AppStores are the unexpected light in the dark for JFX deployment. All of our web-based installer methods in Java are dead or dying (webstart, applet). Native installers are our last option and are ok, but they have a lot of issues some of which may well be unsolvable (e.g. building installers for each platform). Meanwhile some platforms (e.g. Mac) may well be AppStore only before long, blocking the native installer option for us. >> >> Ironically, we are seeing a small resurgence of interest in "desktop apps" thanks to the mobile/smart device revolution. On mobile, "apps" and "app stores" are seen as richer/faster/more-appealing than "web apps". On a technical level the gap between "desktop apps" and "webapps" has been steadily closing but "desktop apps" are getting a PR boost just by association with the "app" concept. Meanwhile the hugely successful commercial strategy of the iOS app store has caught the interest of the money guys, and they are trying to work out how to replicate this on the desktop side of things. As a result, the big players and OS vendors are actually competing with each other to provide us with a clean, easy way to get desktop apps onto their platforms. >> >> Of course the trade off is we have to get our apps reviewed and go through red-tape but as we've seen with the iOS app store, this is not an overall barrier to development and getting apps out there. In fact the ease of installation and the added trust users have in terms of payments, viruses and spamware aid distribution and make the cost of dealing with the red-tape insignificant by comparison. >> >> The biggest risk to us within the AppStore era in the JFX/Java space is getting locked out by the vendors. Not sure how we mitigate this risk (maybe Ellison, Ballmer and Page could group hug?), but keeping an eye on, and adjusting to, the licencing issues around AppStores is a good start, e.g. we can't deploy GPL projects (such as OpenJDK based ones) into the Apple app store (mobile or desktop) so we need to bias towards solutions that aren't limited by this. >> >> I never thought I'd say it, but bring on the AppStore era. >> >> >> >> >> On Fri, Dec 14, 2012 at 12:43 PM, Daniel Zwolenski wrote: >> >> In your exe and dmg do you want the JRE co-bundled into each? It does sound like you basically want the existing native packaging tools but with AU support? >> >> As a general aside/heads-up, I think you will likely find more problems with JNLP than in the past, the 64bit-32bit cross-over has known bugs, and the forced auto-updating (i.e. you can't actually pin your app to a Java version in the JNLP going forward) causes new problems. Add to that the risk of CSS changes being uncontainable (a change could affect anything anywhere), and the fact that Swing was more or less stable for 10 years whereas FX is rapidly growing and not looking to stabalize any time soon (I hope!), and you have some pretty rocky ground to stand on. >> >> I'd be cautious about treating JNLP with the same confidence you might have had with it in the past. I took that approach on my project and had some frustrated users (stuff wouldn't launch because of the 64bit issue, lots of uninstalling/re-installing) and narrowly avoided a system death when 2.2 was released. FXML changed, breaking my code and a ComboBox class was added which clashed with my own - since I couldn't pin my app to a version, had I not caught this ahead of time, my live app would have stopped working the instant users were forced to upgrade their JRE. And that's with Richard being super defensive about backwards compatibility to the point of not allowing interfaces in the code! >> >> >> On Fri, Dec 14, 2012 at 12:17 PM, Jeff Martin wrote: >> Mark, I definitely don't want Oracle to have an app store. App stores are very evil, if done right. :-) >> >> Dan, I guess I'm mostly thinking of my deployment scenario with ReportMill (and Java Inventor). I have had good luck with our ReportMill.jnlp Web Start link because our customers are developers who generally have a working, up to date JRE. I update my ReportMill.jar about once a month and my customers get the update automatically. >> >> When things don't work, I think it's because the browser didn't handle the JNLP-link/WebStart launch correctly, or they don't have the correct version of Java, and/or the JRE update mechanism doesn't work, or the installed JRE installation is corrupted somehow, or the cache is confused. There may also be security and/or permissions problems with a general JRE installation. Probably the best way to clear this up is to have them uninstall Java and re-install the latest version. But I can't realistically guarantee that my latest version works with all the last 10 updates or the next 100 updates of the JRE. >> >> So having the GreatApp.exe and GreatApp.dmg options available, to me, simplifies the step of making sure that the JRE is a clean, uncompromised, compliant (for my app) installation. But I don't want a static version of my app and I don't want to have to rebuild the .exe/.dmg every time I have an update (nor could I expect my customers to regularly re-install my app). >> >> So maybe my scenario isn't common for everyone. But I think this is a reasonably trouble free way of deploying an auto-updating app without having to send users to a generic JRE install (and then help some of them troubleshoot it). I only suggest NetBeans because building the .exe/.dmg would be a rare occurrence. >> >> I have built a launcher like this before (Sun paid us to do one for a version of JFXBuilder years ago), so I already have some utility methods for checking for a new GreatApp.jar.pack.gz, downloading it, unpacking it and class loading it. I think it was only a few pages of code. :-) >> >> jeff >> >> On Dec 13, 2012, at 6:32 PM, Daniel Zwolenski wrote: >> >>> Hey Jeff, >>> >>> I don't fully follow your suggestion (i.e. which bits are native, which bits are Java and which bits are downloaded when) but I don't think it will be quite as simple as this unfortunately (I've spent many a night laying awake, staring at the ceiling trying to work out a clean way to do deployment). >>> >>> Maybe you could clarify some aspects of your suggestion though: >>> >>> >>> What if we build a Netbeans JNLP launcher project >>> >>> Do you mean a new open source Java project here that provides extra deployment functionality that others can leverage? Or are you giving an example of a user creating a new "GreatApp" project that they want to launch? >>> >>> Is your launcher project native code or Java code and what role does Netbeans have in this (I wouldn't do anything IDE specific and passionately disagree with the Netbeans bias of JFX - everything should be IDE agnostic). How does the Launcher work and what does it do? >>> >>> >>> that you customize with just a link to a JNLP and a splash image, >>> >>> Where does the JNLP come from, what is building it - are we just building a normal JFX webstart bundle here or is this a special JNLP file? >>> >>> >>> and it builds your GreatApp.exe and GreatApp.dmg. >>> >>> What builds this? To create an 'exe' you have to build on Windows (plus 32 bit on 32 bit, and 64bit on 64 bit), whereas to build a DMG you currently have to be on Mac. There's no nice utility where you just go build-me-all-my-installers-for-all-platforms. Partly this is due to technology issues with each OS (e.g. MSI's can only be built on Windows) and partly it is due to the JRE not being available for co-bundling anywhere (the only one you have is the one installed on your machine), see http://javafx-jira.kenai.com/browse/RT-22964 >>> >>> If this step was small and simple, the rest of it would be easy and we wouldn't really need JNLP, webstart, etc. >>> >>> >>> The launcher app would simply fetch the JNLP, download the jars (if newer than cache), load them, and invoke MainClass.main(). >>> >>> This is what JNLP does at the moment. I assume you mean it add some value somewhere but I'm missing what exactly that is? Note there is even a pre-launcher MainClass in the JFX packaging tools that does some JFX checks and updating stuff (it's weird and messy). >>> >>> >>> Then on your website you can say, >>> >>> If you have Java, try the Web Start link [ here ] or >>> Download [ GreatApp.exe ] or [ GreatApp.dmg ] >>> >>> In this case the JNLP file is a traditional one or something new and special? If it is a traditional one then you cannot pin it to a JRE and have all the problems we know about. If it is something special, I'm not sure what that special is or how the specialness gets hooked into the start-up process (since if you install Java the JNLP will be opened with Java). >>> >>> In this case do GreatApp.exe and GreatApp.dmg have the JRE co-bundled into them - i.e. they are just like the installers we can build now? >>> >>> If the JNLP is not special and the native installers are the same as now then I'm missing what you're adding to what we have now (i.e. you can produce the above website right now)? >>> >>> The only thing I think you might be suggesting is auto-updating of the exe/dmg based apps, which is not currently supported but planned by Oracle (unknown timeframe). Additionally there were a lot of discussions around adding AU and I have put up prototype code for this that can be used to do this (but it is raw and cludgy). >>> >>> See this discussion: http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-June/002433.html >>> >>> >>> >>> So the benefit over plain web start is that your GreatApp would have a consistent, self-contained execution environment, in the event that the target system doesn't have an installed JRE that is the right version or uncorrupted. >>> >>> I'm missing how this happens? Can you clarify. >>> >>> You also don't get scary warning panels or signing issues. >>> >>> Currently you don't have any of this with the native installers. The JRE is co-bundled and never installed so you side-step the JRE installation horrors. >>> >>> The problems with native installers that need to be addressed are: >>> - Auto updating >>> - Reduce the JRE size to make smaller downloads >>> - Being able to build native releases on multiple platforms >>> >>> >>> >>> But you would still get the benefit of simple upgrades that WebStart gives you. And you wouldn't have to constantly generate a new .exe/.dmg (maybe once or twice a year if you decide a new JRE update would benefit your app). >>> >>> This is basically just adding Auto Updating (AU) support to native installers. >>> >>> If your open source project is to add this then I'm in for that. I've already done a POC: http://code.google.com/p/zen-update/source/browse/trunk/ >>> >>> I ported JFX Ensemble to include auto updating support: http://zenjava.com/demo/update/ensemble/EnsembleWithZenUpdate-1.0.exe >>> >>> Work on this stalled because the JFX deployment team were unable/uninterested in implementing the changes needed to support this work. >>> >>> Once the packaging tools get open sourced (which is overdue) then the community can take over this work (and it is on my todo list). So long as the code remains behind the Oracle iron curtain however, we are hamstrung unless we want to re-implement most of what they have done from the ground up. This is an option but seems wasteful when the OS of the packaging code is suppose to be soon (but "soon" seems to be a very loose term). >>> >>> >>> Such a Netbeans project would probably only be a dozen pages of code. >>> >>> Sounds ambitious :) >>> >>> Here's an even better idea - Oracle sets up a server that will take any JNLP link and dynamically generates a .exe/.dmg for us. :-) >>> >>> >>> You may be interested in this JIRA for this: >>> http://javafx-jira.kenai.com/browse/RT-22994 >>> http://javafx-jira.kenai.com/browse/RT-22995 >>> >>> I'm keen to explore this topic with anyone and everyone wanting to do so. I like that you are looking at it but I'm either missing something about your suggestion or it's a bit too simple in it's approach to provide a solution. If I'm missing something then I really want to know what! If I'm not then I'm happy to help expose all the nasty complexities around this area if you want. >>> >>> Cheers, >>> Dan >>> >>> >>> >>> >>> >> >> >> > From joshua at marinacci.org Fri Dec 14 08:57:56 2012 From: joshua at marinacci.org (Josh Marinacci) Date: Fri, 14 Dec 2012 08:57:56 -0800 Subject: Reliable deployment idea: JNLP Launcher exe/dmg In-Reply-To: <38520EC1-578D-4011-A537-1DFF6F296562@reportmill.com> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C2FC51.80208@jugs.org> <6B515693-B119-4853-BD71-C9F78917F93B@oracle.com> <01a801cdd5ce$58e1e170$0aa5a450$@com.au> <9EF244F8-AB86-4234-B2A7-6D672A601788@gmail.com> <7915E1FB-F436-4260-8F2E-FF9CDCC1450A@reportmill.com> <4F41ABC9-EDA1-451D-8345-C9826683406B@reportmill.com> <38520EC1-578D-4011-A537-1DFF6F296562@reportmill.com> Message-ID: <817F0DD358904942831282A982C0CC2C@marinacci.org> Sun/Oracle did build a Java app store, remember? I built the GUI :) The reality is that desktop OSes are moving towards an app store model. Java has to adapt to this new reality. -- Josh Marinacci joshondesign.com On Friday, December 14, 2012 at 5:23 AM, Jeff Martin wrote: > I can't disagree with most of that - but I also can't help but feel Apple set up a big toll booth for app developers (complete with bureaucracy and censorship). I don't want to have to go hat-in-hand to anyone for approval to release my app, and I don't want to part with 30% of the proceeds unless they are contributing serious sales and marketing effort. > > Not to cry a river for Oracle, but it seems a shame that my app(s) rely so heavily on Java and JavaFX, yet Apple walks away with 30% and Oracle 0%. Yet if Oracle were to charge 30% for their significant contribution, app developers might as well give up. > > I'm a former Apple employee and a stock holder - but their precedent scares me. And I was a Steve Jobs hero worshipper, but I always said if Apple was as big as Microsoft, they'd probably be at least as evil. :-) > > jeff > > On Dec 13, 2012, at 10:35 PM, Daniel Zwolenski wrote: > > > As an aside, I agree that Oracle shouldn't try to do it's own App store - Oracle is not consumer focused enough (and not a consumer brand name) to compete with the other big vendors in the space. Far better to collaborate and team up with other vendors like MS, Google, etc, to ensure smooth Java support. > > > > In my opinion though AppStores are the unexpected light in the dark for JFX deployment. All of our web-based installer methods in Java are dead or dying (webstart, applet). Native installers are our last option and are ok, but they have a lot of issues some of which may well be unsolvable (e.g. building installers for each platform). Meanwhile some platforms (e.g. Mac) may well be AppStore only before long, blocking the native installer option for us. > > > > Ironically, we are seeing a small resurgence of interest in "desktop apps" thanks to the mobile/smart device revolution. On mobile, "apps" and "app stores" are seen as richer/faster/more-appealing than "web apps". On a technical level the gap between "desktop apps" and "webapps" has been steadily closing but "desktop apps" are getting a PR boost just by association with the "app" concept. Meanwhile the hugely successful commercial strategy of the iOS app store has caught the interest of the money guys, and they are trying to work out how to replicate this on the desktop side of things. As a result, the big players and OS vendors are actually competing with each other to provide us with a clean, easy way to get desktop apps onto their platforms. > > > > Of course the trade off is we have to get our apps reviewed and go through red-tape but as we've seen with the iOS app store, this is not an overall barrier to development and getting apps out there. In fact the ease of installation and the added trust users have in terms of payments, viruses and spamware aid distribution and make the cost of dealing with the red-tape insignificant by comparison. > > > > The biggest risk to us within the AppStore era in the JFX/Java space is getting locked out by the vendors. Not sure how we mitigate this risk (maybe Ellison, Ballmer and Page could group hug?), but keeping an eye on, and adjusting to, the licencing issues around AppStores is a good start, e.g. we can't deploy GPL projects (such as OpenJDK based ones) into the Apple app store (mobile or desktop) so we need to bias towards solutions that aren't limited by this. > > > > I never thought I'd say it, but bring on the AppStore era. > > > > > > > > > > On Fri, Dec 14, 2012 at 12:43 PM, Daniel Zwolenski wrote: > > > > In your exe and dmg do you want the JRE co-bundled into each? It does sound like you basically want the existing native packaging tools but with AU support? > > > > As a general aside/heads-up, I think you will likely find more problems with JNLP than in the past, the 64bit-32bit cross-over has known bugs, and the forced auto-updating (i.e. you can't actually pin your app to a Java version in the JNLP going forward) causes new problems. Add to that the risk of CSS changes being uncontainable (a change could affect anything anywhere), and the fact that Swing was more or less stable for 10 years whereas FX is rapidly growing and not looking to stabalize any time soon (I hope!), and you have some pretty rocky ground to stand on. > > > > I'd be cautious about treating JNLP with the same confidence you might have had with it in the past. I took that approach on my project and had some frustrated users (stuff wouldn't launch because of the 64bit issue, lots of uninstalling/re-installing) and narrowly avoided a system death when 2.2 was released. FXML changed, breaking my code and a ComboBox class was added which clashed with my own - since I couldn't pin my app to a version, had I not caught this ahead of time, my live app would have stopped working the instant users were forced to upgrade their JRE. And that's with Richard being super defensive about backwards compatibility to the point of not allowing interfaces in the code! > > > > > > On Fri, Dec 14, 2012 at 12:17 PM, Jeff Martin wrote: > > Mark, I definitely don't want Oracle to have an app store. App stores are very evil, if done right. :-) > > > > Dan, I guess I'm mostly thinking of my deployment scenario with ReportMill (and Java Inventor). I have had good luck with our ReportMill.jnlp Web Start link because our customers are developers who generally have a working, up to date JRE. I update my ReportMill.jar about once a month and my customers get the update automatically. > > > > When things don't work, I think it's because the browser didn't handle the JNLP-link/WebStart launch correctly, or they don't have the correct version of Java, and/or the JRE update mechanism doesn't work, or the installed JRE installation is corrupted somehow, or the cache is confused. There may also be security and/or permissions problems with a general JRE installation. Probably the best way to clear this up is to have them uninstall Java and re-install the latest version. But I can't realistically guarantee that my latest version works with all the last 10 updates or the next 100 updates of the JRE. > > > > So having the GreatApp.exe and GreatApp.dmg options available, to me, simplifies the step of making sure that the JRE is a clean, uncompromised, compliant (for my app) installation. But I don't want a static version of my app and I don't want to have to rebuild the .exe/.dmg every time I have an update (nor could I expect my customers to regularly re-install my app). > > > > So maybe my scenario isn't common for everyone. But I think this is a reasonably trouble free way of deploying an auto-updating app without having to send users to a generic JRE install (and then help some of them troubleshoot it). I only suggest NetBeans because building the .exe/.dmg would be a rare occurrence. > > > > I have built a launcher like this before (Sun paid us to do one for a version of JFXBuilder years ago), so I already have some utility methods for checking for a new GreatApp.jar.pack.gz, downloading it, unpacking it and class loading it. I think it was only a few pages of code. :-) > > > > jeff > > > > On Dec 13, 2012, at 6:32 PM, Daniel Zwolenski wrote: > > > > > Hey Jeff, > > > > > > I don't fully follow your suggestion (i.e. which bits are native, which bits are Java and which bits are downloaded when) but I don't think it will be quite as simple as this unfortunately (I've spent many a night laying awake, staring at the ceiling trying to work out a clean way to do deployment). > > > > > > Maybe you could clarify some aspects of your suggestion though: > > > > > > > > > What if we build a Netbeans JNLP launcher project > > > > > > Do you mean a new open source Java project here that provides extra deployment functionality that others can leverage? Or are you giving an example of a user creating a new "GreatApp" project that they want to launch? > > > > > > Is your launcher project native code or Java code and what role does Netbeans have in this (I wouldn't do anything IDE specific and passionately disagree with the Netbeans bias of JFX - everything should be IDE agnostic). How does the Launcher work and what does it do? > > > > > > > > > that you customize with just a link to a JNLP and a splash image, > > > > > > Where does the JNLP come from, what is building it - are we just building a normal JFX webstart bundle here or is this a special JNLP file? > > > > > > > > > and it builds your GreatApp.exe and GreatApp.dmg. > > > > > > What builds this? To create an 'exe' you have to build on Windows (plus 32 bit on 32 bit, and 64bit on 64 bit), whereas to build a DMG you currently have to be on Mac. There's no nice utility where you just go build-me-all-my-installers-for-all-platforms. Partly this is due to technology issues with each OS (e.g. MSI's can only be built on Windows) and partly it is due to the JRE not being available for co-bundling anywhere (the only one you have is the one installed on your machine), see http://javafx-jira.kenai.com/browse/RT-22964 > > > > > > If this step was small and simple, the rest of it would be easy and we wouldn't really need JNLP, webstart, etc. > > > > > > > > > The launcher app would simply fetch the JNLP, download the jars (if newer than cache), load them, and invoke MainClass.main(). > > > > > > This is what JNLP does at the moment. I assume you mean it add some value somewhere but I'm missing what exactly that is? Note there is even a pre-launcher MainClass in the JFX packaging tools that does some JFX checks and updating stuff (it's weird and messy). > > > > > > > > > Then on your website you can say, > > > > > > If you have Java, try the Web Start link [ here ] or > > > Download [ GreatApp.exe ] or [ GreatApp.dmg ] > > > > > > In this case the JNLP file is a traditional one or something new and special? If it is a traditional one then you cannot pin it to a JRE and have all the problems we know about. If it is something special, I'm not sure what that special is or how the specialness gets hooked into the start-up process (since if you install Java the JNLP will be opened with Java). > > > > > > In this case do GreatApp.exe and GreatApp.dmg have the JRE co-bundled into them - i.e. they are just like the installers we can build now? > > > > > > If the JNLP is not special and the native installers are the same as now then I'm missing what you're adding to what we have now (i.e. you can produce the above website right now)? > > > > > > The only thing I think you might be suggesting is auto-updating of the exe/dmg based apps, which is not currently supported but planned by Oracle (unknown timeframe). Additionally there were a lot of discussions around adding AU and I have put up prototype code for this that can be used to do this (but it is raw and cludgy). > > > > > > See this discussion: http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-June/002433.html > > > > > > > > > > > > So the benefit over plain web start is that your GreatApp would have a consistent, self-contained execution environment, in the event that the target system doesn't have an installed JRE that is the right version or uncorrupted. > > > > > > I'm missing how this happens? Can you clarify. > > > > > > You also don't get scary warning panels or signing issues. > > > > > > Currently you don't have any of this with the native installers. The JRE is co-bundled and never installed so you side-step the JRE installation horrors. > > > > > > The problems with native installers that need to be addressed are: > > > - Auto updating > > > - Reduce the JRE size to make smaller downloads > > > - Being able to build native releases on multiple platforms > > > > > > > > > > > > But you would still get the benefit of simple upgrades that WebStart gives you. And you wouldn't have to constantly generate a new .exe/.dmg (maybe once or twice a year if you decide a new JRE update would benefit your app). > > > > > > This is basically just adding Auto Updating (AU) support to native installers. > > > > > > If your open source project is to add this then I'm in for that. I've already done a POC: http://code.google.com/p/zen-update/source/browse/trunk/ > > > > > > I ported JFX Ensemble to include auto updating support: http://zenjava.com/demo/update/ensemble/EnsembleWithZenUpdate-1.0.exe > > > > > > Work on this stalled because the JFX deployment team were unable/uninterested in implementing the changes needed to support this work. > > > > > > Once the packaging tools get open sourced (which is overdue) then the community can take over this work (and it is on my todo list). So long as the code remains behind the Oracle iron curtain however, we are hamstrung unless we want to re-implement most of what they have done from the ground up. This is an option but seems wasteful when the OS of the packaging code is suppose to be soon (but "soon" seems to be a very loose term). > > > > > > > > > Such a Netbeans project would probably only be a dozen pages of code. > > > > > > Sounds ambitious :) > > > > > > Here's an even better idea - Oracle sets up a server that will take any JNLP link and dynamically generates a .exe/.dmg for us. :-) > > > > > > > > > You may be interested in this JIRA for this: > > > http://javafx-jira.kenai.com/browse/RT-22994 > > > http://javafx-jira.kenai.com/browse/RT-22995 > > > > > > I'm keen to explore this topic with anyone and everyone wanting to do so. I like that you are looking at it but I'm either missing something about your suggestion or it's a bit too simple in it's approach to provide a solution. If I'm missing something then I really want to know what! If I'm not then I'm happy to help expose all the nasty complexities around this area if you want. > > > > > > Cheers, > > > Dan > > > > > > > > > > From pedro.duquevieira at gmail.com Fri Dec 14 09:12:13 2012 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Fri, 14 Dec 2012 17:12:13 +0000 Subject: Reliable deployment idea: JNLP Launcher exe/dmg (Chris Bensen) Message-ID: Hi Chris :) Could you clarify a little bit better? Do you want requirements for only the creation of app installers and self contained executables (with the jre inside)? Cheers, -- Pedro Duque Vieira From phidias51 at gmail.com Fri Dec 14 09:24:19 2012 From: phidias51 at gmail.com (Mark Fortner) Date: Fri, 14 Dec 2012 09:24:19 -0800 Subject: Reliable deployment idea: JNLP Launcher exe/dmg In-Reply-To: <817F0DD358904942831282A982C0CC2C@marinacci.org> References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C2FC51.80208@jugs.org> <6B515693-B119-4853-BD71-C9F78917F93B@oracle.com> <01a801cdd5ce$58e1e170$0aa5a450$@com.au> <9EF244F8-AB86-4234-B2A7-6D672A601788@gmail.com> <7915E1FB-F436-4260-8F2E-FF9CDCC1450A@reportmill.com> <4F41ABC9-EDA1-451D-8345-C9826683406B@reportmill.com> <38520EC1-578D-4011-A537-1DFF6F296562@reportmill.com> <817F0DD358904942831282A982C0CC2C@marinacci.org> Message-ID: Here's what's on my app store wish list: Short-term wishes - A simple app store that lets me upload a JNLP and a JAR. The app store would then: - Fetch all dependencies listed in the JNLP from the Maven Repo - Create all platform dependent artifacts (i.e. RPMs, DEBs, DMGs, EXEs) - Handle signing - Set the price & handle licensing - A simple app store client that sits in the dock and lets me find, download and update apps, and notifies me when updates are available, and lets me file bug reports for those apps. Longer-term wishes - An open source, enterprise version of the app store that lets businesses distribute their own apps internally, and could optionally allow them to search the external app store to find apps that I want to make part of a "standard" desktop. If you buy apps through the enterprise store, then licensing is handled at the enterprise store level, not at the individual desktop level. - The ability to republish apps from the app store to platform dependent app stores, thus making it easier for users to get my app. - A Git-hub like experience, where I can publish the source code to the enterprise app store, and the app store will build my app and the appropriate artifacts. Business justification - Since JavaFX is clearly aimed at the desktop (for the time being) it's critical to create positive awareness of Java on the desktop. - The app store creates an opportunity for Oracle to incentivize developers who might otherwise not look at desktop development as a viable business opportunity. - The enterprise app store creates another revenue stream for Oracle. Cheers, Mark On Fri, Dec 14, 2012 at 8:57 AM, Josh Marinacci wrote: > Sun/Oracle did build a Java app store, remember? I built the GUI :) > > The reality is that desktop OSes are moving towards an app store model. > Java has to adapt to this new reality. > > > -- > Josh Marinacci > joshondesign.com > > > On Friday, December 14, 2012 at 5:23 AM, Jeff Martin wrote: > > > I can't disagree with most of that - but I also can't help but feel > Apple set up a big toll booth for app developers (complete with bureaucracy > and censorship). I don't want to have to go hat-in-hand to anyone for > approval to release my app, and I don't want to part with 30% of the > proceeds unless they are contributing serious sales and marketing effort. > > > > Not to cry a river for Oracle, but it seems a shame that my app(s) rely > so heavily on Java and JavaFX, yet Apple walks away with 30% and Oracle 0%. > Yet if Oracle were to charge 30% for their significant contribution, app > developers might as well give up. > > > > I'm a former Apple employee and a stock holder - but their precedent > scares me. And I was a Steve Jobs hero worshipper, but I always said if > Apple was as big as Microsoft, they'd probably be at least as evil. :-) > > > > jeff > > > > On Dec 13, 2012, at 10:35 PM, Daniel Zwolenski zonski at gmail.com)> wrote: > > > > > As an aside, I agree that Oracle shouldn't try to do it's own App > store - Oracle is not consumer focused enough (and not a consumer brand > name) to compete with the other big vendors in the space. Far better to > collaborate and team up with other vendors like MS, Google, etc, to ensure > smooth Java support. > > > > > > In my opinion though AppStores are the unexpected light in the dark > for JFX deployment. All of our web-based installer methods in Java are dead > or dying (webstart, applet). Native installers are our last option and are > ok, but they have a lot of issues some of which may well be unsolvable > (e.g. building installers for each platform). Meanwhile some platforms > (e.g. Mac) may well be AppStore only before long, blocking the native > installer option for us. > > > > > > Ironically, we are seeing a small resurgence of interest in "desktop > apps" thanks to the mobile/smart device revolution. On mobile, "apps" and > "app stores" are seen as richer/faster/more-appealing than "web apps". On a > technical level the gap between "desktop apps" and "webapps" has been > steadily closing but "desktop apps" are getting a PR boost just by > association with the "app" concept. Meanwhile the hugely successful > commercial strategy of the iOS app store has caught the interest of the > money guys, and they are trying to work out how to replicate this on the > desktop side of things. As a result, the big players and OS vendors are > actually competing with each other to provide us with a clean, easy way to > get desktop apps onto their platforms. > > > > > > Of course the trade off is we have to get our apps reviewed and go > through red-tape but as we've seen with the iOS app store, this is not an > overall barrier to development and getting apps out there. In fact the ease > of installation and the added trust users have in terms of payments, > viruses and spamware aid distribution and make the cost of dealing with the > red-tape insignificant by comparison. > > > > > > The biggest risk to us within the AppStore era in the JFX/Java space > is getting locked out by the vendors. Not sure how we mitigate this risk > (maybe Ellison, Ballmer and Page could group hug?), but keeping an eye on, > and adjusting to, the licencing issues around AppStores is a good start, > e.g. we can't deploy GPL projects (such as OpenJDK based ones) into the > Apple app store (mobile or desktop) so we need to bias towards solutions > that aren't limited by this. > > > > > > I never thought I'd say it, but bring on the AppStore era. > > > > > > > > > > > > > > > On Fri, Dec 14, 2012 at 12:43 PM, Daniel Zwolenski zonski at gmail.com)> wrote: > > > > > > In your exe and dmg do you want the JRE co-bundled into each? It does > sound like you basically want the existing native packaging tools but with > AU support? > > > > > > As a general aside/heads-up, I think you will likely find more > problems with JNLP than in the past, the 64bit-32bit cross-over has known > bugs, and the forced auto-updating (i.e. you can't actually pin your app to > a Java version in the JNLP going forward) causes new problems. Add to that > the risk of CSS changes being uncontainable (a change could affect anything > anywhere), and the fact that Swing was more or less stable for 10 years > whereas FX is rapidly growing and not looking to stabalize any time soon (I > hope!), and you have some pretty rocky ground to stand on. > > > > > > I'd be cautious about treating JNLP with the same confidence you might > have had with it in the past. I took that approach on my project and had > some frustrated users (stuff wouldn't launch because of the 64bit issue, > lots of uninstalling/re-installing) and narrowly avoided a system death > when 2.2 was released. FXML changed, breaking my code and a ComboBox class > was added which clashed with my own - since I couldn't pin my app to a > version, had I not caught this ahead of time, my live app would have > stopped working the instant users were forced to upgrade their JRE. And > that's with Richard being super defensive about backwards compatibility to > the point of not allowing interfaces in the code! > > > > > > > > > On Fri, Dec 14, 2012 at 12:17 PM, Jeff Martin jeff at reportmill.com)> wrote: > > > Mark, I definitely don't want Oracle to have an app store. App stores > are very evil, if done right. :-) > > > > > > Dan, I guess I'm mostly thinking of my deployment scenario with > ReportMill (and Java Inventor). I have had good luck with our > ReportMill.jnlp Web Start link because our customers are developers who > generally have a working, up to date JRE. I update my ReportMill.jar about > once a month and my customers get the update automatically. > > > > > > When things don't work, I think it's because the browser didn't handle > the JNLP-link/WebStart launch correctly, or they don't have the correct > version of Java, and/or the JRE update mechanism doesn't work, or the > installed JRE installation is corrupted somehow, or the cache is confused. > There may also be security and/or permissions problems with a general JRE > installation. Probably the best way to clear this up is to have them > uninstall Java and re-install the latest version. But I can't realistically > guarantee that my latest version works with all the last 10 updates or the > next 100 updates of the JRE. > > > > > > So having the GreatApp.exe and GreatApp.dmg options available, to me, > simplifies the step of making sure that the JRE is a clean, uncompromised, > compliant (for my app) installation. But I don't want a static version of > my app and I don't want to have to rebuild the .exe/.dmg every time I have > an update (nor could I expect my customers to regularly re-install my app). > > > > > > So maybe my scenario isn't common for everyone. But I think this is a > reasonably trouble free way of deploying an auto-updating app without > having to send users to a generic JRE install (and then help some of them > troubleshoot it). I only suggest NetBeans because building the .exe/.dmg > would be a rare occurrence. > > > > > > I have built a launcher like this before (Sun paid us to do one for a > version of JFXBuilder years ago), so I already have some utility methods > for checking for a new GreatApp.jar.pack.gz, downloading it, unpacking it > and class loading it. I think it was only a few pages of code. :-) > > > > > > jeff > > > > > > On Dec 13, 2012, at 6:32 PM, Daniel Zwolenski zonski at gmail.com)> wrote: > > > > > > > Hey Jeff, > > > > > > > > I don't fully follow your suggestion (i.e. which bits are native, > which bits are Java and which bits are downloaded when) but I don't think > it will be quite as simple as this unfortunately (I've spent many a night > laying awake, staring at the ceiling trying to work out a clean way to do > deployment). > > > > > > > > Maybe you could clarify some aspects of your suggestion though: > > > > > > > > > > > > What if we build a Netbeans JNLP launcher project > > > > > > > > Do you mean a new open source Java project here that provides extra > deployment functionality that others can leverage? Or are you giving an > example of a user creating a new "GreatApp" project that they want to > launch? > > > > > > > > Is your launcher project native code or Java code and what role does > Netbeans have in this (I wouldn't do anything IDE specific and passionately > disagree with the Netbeans bias of JFX - everything should be IDE > agnostic). How does the Launcher work and what does it do? > > > > > > > > > > > > that you customize with just a link to a JNLP and a splash image, > > > > > > > > Where does the JNLP come from, what is building it - are we just > building a normal JFX webstart bundle here or is this a special JNLP file? > > > > > > > > > > > > and it builds your GreatApp.exe and GreatApp.dmg. > > > > > > > > What builds this? To create an 'exe' you have to build on Windows > (plus 32 bit on 32 bit, and 64bit on 64 bit), whereas to build a DMG you > currently have to be on Mac. There's no nice utility where you just go > build-me-all-my-installers-for-all-platforms. Partly this is due to > technology issues with each OS (e.g. MSI's can only be built on Windows) > and partly it is due to the JRE not being available for co-bundling > anywhere (the only one you have is the one installed on your machine), see > http://javafx-jira.kenai.com/browse/RT-22964 > > > > > > > > If this step was small and simple, the rest of it would be easy and > we wouldn't really need JNLP, webstart, etc. > > > > > > > > > > > > The launcher app would simply fetch the JNLP, download the jars (if > newer than cache), load them, and invoke MainClass.main(). > > > > > > > > This is what JNLP does at the moment. I assume you mean it add some > value somewhere but I'm missing what exactly that is? Note there is even a > pre-launcher MainClass in the JFX packaging tools that does some JFX checks > and updating stuff (it's weird and messy). > > > > > > > > > > > > Then on your website you can say, > > > > > > > > If you have Java, try the Web Start link [ here ] or > > > > Download [ GreatApp.exe ] or [ GreatApp.dmg ] > > > > > > > > In this case the JNLP file is a traditional one or something new and > special? If it is a traditional one then you cannot pin it to a JRE and > have all the problems we know about. If it is something special, I'm not > sure what that special is or how the specialness gets hooked into the > start-up process (since if you install Java the JNLP will be opened with > Java). > > > > > > > > In this case do GreatApp.exe and GreatApp.dmg have the JRE > co-bundled into them - i.e. they are just like the installers we can build > now? > > > > > > > > If the JNLP is not special and the native installers are the same as > now then I'm missing what you're adding to what we have now (i.e. you can > produce the above website right now)? > > > > > > > > The only thing I think you might be suggesting is auto-updating of > the exe/dmg based apps, which is not currently supported but planned by > Oracle (unknown timeframe). Additionally there were a lot of discussions > around adding AU and I have put up prototype code for this that can be used > to do this (but it is raw and cludgy). > > > > > > > > See this discussion: > http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-June/002433.html > > > > > > > > > > > > > > > > So the benefit over plain web start is that your GreatApp would have > a consistent, self-contained execution environment, in the event that the > target system doesn't have an installed JRE that is the right version or > uncorrupted. > > > > > > > > I'm missing how this happens? Can you clarify. > > > > > > > > You also don't get scary warning panels or signing issues. > > > > > > > > Currently you don't have any of this with the native installers. The > JRE is co-bundled and never installed so you side-step the JRE installation > horrors. > > > > > > > > The problems with native installers that need to be addressed are: > > > > - Auto updating > > > > - Reduce the JRE size to make smaller downloads > > > > - Being able to build native releases on multiple platforms > > > > > > > > > > > > > > > > But you would still get the benefit of simple upgrades that WebStart > gives you. And you wouldn't have to constantly generate a new .exe/.dmg > (maybe once or twice a year if you decide a new JRE update would benefit > your app). > > > > > > > > This is basically just adding Auto Updating (AU) support to native > installers. > > > > > > > > If your open source project is to add this then I'm in for that. > I've already done a POC: > http://code.google.com/p/zen-update/source/browse/trunk/ > > > > > > > > I ported JFX Ensemble to include auto updating support: > http://zenjava.com/demo/update/ensemble/EnsembleWithZenUpdate-1.0.exe > > > > > > > > Work on this stalled because the JFX deployment team were > unable/uninterested in implementing the changes needed to support this work. > > > > > > > > Once the packaging tools get open sourced (which is overdue) then > the community can take over this work (and it is on my todo list). So long > as the code remains behind the Oracle iron curtain however, we are > hamstrung unless we want to re-implement most of what they have done from > the ground up. This is an option but seems wasteful when the OS of the > packaging code is suppose to be soon (but "soon" seems to be a very loose > term). > > > > > > > > > > > > Such a Netbeans project would probably only be a dozen pages of code. > > > > > > > > Sounds ambitious :) > > > > > > > > Here's an even better idea - Oracle sets up a server that will take > any JNLP link and dynamically generates a .exe/.dmg for us. :-) > > > > > > > > > > > > You may be interested in this JIRA for this: > > > > http://javafx-jira.kenai.com/browse/RT-22994 > > > > http://javafx-jira.kenai.com/browse/RT-22995 > > > > > > > > I'm keen to explore this topic with anyone and everyone wanting to > do so. I like that you are looking at it but I'm either missing something > about your suggestion or it's a bit too simple in it's approach to provide > a solution. If I'm missing something then I really want to know what! If > I'm not then I'm happy to help expose all the nasty complexities around > this area if you want. > > > > > > > > Cheers, > > > > Dan > > > > > > > > > > > > > > > > > > > From hang.vo at oracle.com Fri Dec 14 10:33:13 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 14 Dec 2012 18:33:13 +0000 Subject: hg: openjfx/8/graphics/rt: Fix up default dist and ant targets for openjfx build (they were switched) Message-ID: <20121214183315.A21F247176@hg.openjdk.java.net> Changeset: ad0025b5ba3e Author: kcr Date: 2012-12-14 10:07 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ad0025b5ba3e Fix up default dist and ant targets for openjfx build (they were switched) ! build.xml From lehmann at media-interactive.de Fri Dec 14 10:52:56 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Fri, 14 Dec 2012 19:52:56 +0100 Subject: JFXPanel ignores size change of root node Message-ID: <50CB7588.9060607@media-interactive.de> Hi, as far as I know JFXPanel is supposed to be sized according to its content (also stated in RT-13758). This does not seem to work when the content's size changes later: the jfxpanel is not resized along. Hopefully I am missing something. The test code below creates a Swing flowlayout with a button, a jfxpanel, and a label: http://s16.postimage.org/6nfil2myt/jfxpanel_width_160px.png When clicking the button, the rectangle inside the fxpanel is resized from 160px to 120px width. The jfxpanel itself does not seem to be resized: http://s16.postimage.org/p1q1p1z9h/jfxpanel_width_120px.png It also does not work to increase the rectangle width - the jfxpanel width does not change. In my non-test application I have tried to remove and add the jfxpanel but that only works sometimes and is not exactly elegant. Any ideas? Rgds Werner > public class JFXPanelResizeTest > { > public static void main(String[] args) > { > SwingUtilities.invokeLater(new Runnable() { > @Override public void run() { initAndShowGUI(); } > }); > } > > private static void initAndShowGUI() > { > final JFrame f = new JFrame("Test JFXPanel resize"); > f.setSize(600, 200); > f.setLocationRelativeTo(null); > f.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE); > f.setLayout(new FlowLayout()); > final MyJFXPanel fxPanel = new MyJFXPanel(); > JButton button = new JButton("Toggle Rectangel Width"); > button.addActionListener(new ActionListener() { > @Override public void actionPerformed(ActionEvent paramActionEvent) { fxPanel.toggle(); } > }); > f.add(button); > f.add(fxPanel); > f.add(new JLabel("Label1")); > f.setVisible(true); > } > > private static class MyJFXPanel extends JFXPanel > { > private final Rectangle r = new Rectangle(160, 120); > > public MyJFXPanel() > { > Platform.runLater(new Runnable() { > @Override public void run() { setScene(new Scene(new Group(r))); } > }); > } > > // Toggle rectangle width 120px / 160px. > public void toggle() > { > Platform.runLater(new Runnable() { > @Override public void run() { r.setWidth(r.getWidth() == 160 ? 120 : 160); } > }); > } > } > } From java.whoover at gmail.com Fri Dec 14 12:09:25 2012 From: java.whoover at gmail.com (Will Hoover) Date: Fri, 14 Dec 2012 15:09:25 -0500 Subject: JavaFX performance for complex visualisations In-Reply-To: References: <004f01cdc3da$c8fd1b10$5af75130$@com.au> <50A62AE4.7030309@jugs.org> <5702E74D-9D64-43BC-B993-3401BEF681EA@oracle.com> <50C24014.5000003@jugs.org> <5CCC55BD-C6F0-46A0-A638-C72F1947FFCE@oracle.com> <50C2FC51.80208@jugs.org> <6B515693-B119-4853-BD71-C9F78917F93B@oracle.com> <01a801cdd5ce$58e1e170$0aa5a450$@com.au> <9EF244F8-AB86-4234-B2A7-6D672A601788@gmail.com> Message-ID: <50cb8776.e684ec0a.4e83.ffffdde8@mx.google.com> Not sure if it's relevant or not, but I've experimented with generating some gauge graphics without using any external images (i.e. paths and the alike are used). I knew going into it that this is not the optimal method for doing this, but I wanted to see how well JavaFX performed under such stresses. Again, I'm not sure if it's relevant to your gaming project, but it may be of some use for testing the limits of drawing in JavaFX. Here is some screenshots of the gauges (gauges under "Alarm Settings" and knobs under "Positioning" are what I'm referring to): http://www.ugate.org/screenshots.php -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel Zwolenski Sent: Thursday, December 13, 2012 5:02 PM To: Scott Palmer Cc: Subject: Re: JavaFX performance for complex visualisations Somewhat related to this thread, I'd be interest in people's responses to this forum post: https://forums.oracle.com/forums/thread.jspa?threadID=2476169&tstart=0 Basically looking for some good design patterns on building these sorts of diagrammatic applications. This will then feed back into Richard's game project with the ultimate goal of testing performance and either showing just what can be done with jfx or just as importantly highlighting to Richard and crew where the problems are. On that same note, there was a lot of enthusiastic comments about people interested in contributing to this project but so far its been pretty light on with only Jose and myself making any serious contributions. It would be good to have more input, users and actual coders. We are getting close to the stage where we need some more complex sprites (mine are currently blue circles), either vector and flip-image style (we'd like to have both in there), and I know quite a few of you wanted to test some specific things in this area. If you're interested in getting involved but don't know how, the two best things to do would be to read through the issues list on the project (we are kind of using this as a forum) or send me an email direct and I'll kick you off - we can look at building up a bit of a JFX games mailing list too so as not to spam this forum too much. Cheers, Dan On Mon, Dec 10, 2012 at 2:31 AM, Scott Palmer wrote: > To be honest, I don't know if the presentation was done in Flash. The > end result is MPEG4 video, not a Flash animation. I would be happy if > the > *tools* used to create the presentation could easily be made using JavaFX. > I think JavaFX could do the visualization with a small framework > written in JavaFX. > > Scott > > On 2012-12-09, at 12:30 AM, "John C. Turnbull" > > wrote: > > > That looks very good Scott. > > > > But just to put it out there, what *I'd* like to see is that the > presentation at that link be developed in JavaFX instead of Flash as > it is currently (not just the product it describes). Why can't we do that? > Well, the first question is whether JavaFX is capable of supporting > such a visualisation. The second question is even if it was possible, > how would it be developed without similar tools offered by Adobe > Creative Suite? We basically have Scene Builder at the moment which > clearly isn't going to cut it. > > > > -----Original Message----- > > From: openjfx-dev-bounces at openjdk.java.net [mailto: > openjfx-dev-bounces at openjdk.java.net] On Behalf Of Scott Palmer > > Sent: Sunday, 9 December 2012 04:43 > > To: Richard Bair > > Cc: openjfx-dev at openjdk.java.net > > Subject: Re: JavaFX performance for complex visualisations > > > > That first link is very close to what I am doing now with JavaFX... > > and > yes, the performance is below what I was hoping. When there are many > Paths performance drops substantially. > > Here's a link to info about our product: > > http://www.digitalrapids.com/en/Products/Kayak.aspx > > See Kayak Workflow Designer at 1:50 into the video. > > > > Scott > > > > > > On Sat, Dec 8, 2012 at 11:55 AM, Richard Bair > > >wrote: > > > >> I think the first link is a great example of something we should be > >> able to do, and the kind of thing that I think you and Michael are > >> saying doesn't work well right now. The second one actually is > >> probably a lot easier now, because of Canvas. Basically, all the > >> typographic background information isn't interactive, so you can > >> render it once and use it as an image thereafter (with Canvas), > >> whereas the first example has what I would guess would be a lot of > interactive content. > >> > >> Richard > >> > >> On Dec 8, 2012, at 1:01 AM, Daniel Zwolenski wrote: > >> > >>> And just for reference, I had business cases to show: > >>> * P&IDs like these > >> http://www.creativeengineers.com/process-engineering/diagrams/pid.h > >> tml > >>> * Site maps similar to this sort of thing: > >> http://www.cegenvironmental.com/Services/Phase_II_ESA/Blueberry_Pro > >> ces > >> sing_Plant/topoDKWfsmall.gif > >>> > >>> And to include zooming with LOD (i.e. more detail zoomed in, less > >>> detail > >> at birds eye view), selective layering/highlighting (i.e. turn > >> on/off different pipes or sections), hyperlinking and mouse overs, > >> and markers/annotations (i.e. put a flag on the map, or a > >> semi-transparent overlay over a "hot" section). No animations at least. > >>> > >>> JFX wasn't up to the task performance wise as far as I could tell > >>> in > >> 2.0. We scaled back to just showing blurry images and putting a few > >> markers (e.g. triangles/arrows/dots) on them but this was still > >> quite slow but that could well have been the logic behind it > >> (things got > ugly). > >>> > >>> This was for mining, chemical, manufacturing and general heavy > >> industries (not unlike the cargo unloading thing from JavaOne). > >>> > >>> > >>> > >>> > >>> On Sat, Dec 8, 2012 at 7:37 PM, Dr. Michael Paus wrote: > >>> Am 07.12.2012 21:20, schrieb Richard Bair: > >>> > >>> Hi Michael, > >>> > >>> According to my experience JavaFX is currently not able to handle > >> graphically intensive > >>> applications. > >>> Depends on what you are doing that is "graphically intense" -- if > >>> it is > >> a lot of paths (thousands) then yes, this is slow. If it is a lot > >> of images and lines and effects and such, then actually you can do > >> a heck of a lot with FX (which is graphically intense!) > >>> This is of course true but tell me how far do you really get if > >>> you only > >> have these elements available? > >>> You cannot even draw a simple filled triangle without creating a > >>> path > >> and thus slowing down your application. > >>> A graphically intensive business application without paths seems > >>> to be a > >> very specific corner case to me but > >>> maybe it is just me who feels so. What I have in mind when I talk > >>> about > >> such applications are large diagrams, > >>> floor plans, vector maps with a lot of symbols on them and so on. > >>> If you're needing triangles, then you're in another class of > >>> application > >> than the kind we've so far properly supported. Hopefully the 3D > >> stuff will help bridge the gap. > >>> > >>> (I've not seen triangles in use except in 3D programming which may > >> explain why I haven't considered that particular use case critical > >> for our earlier releases, but hopefully we'll be able to handle > >> your case properly now). > >>> Just to avoid some misunderstanding. I mentioned triangles only as > >>> an > >> example for the most trivial geometry which cannot be > >>> created without using paths right now. In practice I have to > >>> create more > >> complicated geometries of course. > >>> > >>> > >>> -- > >>> > >> ------------------------------------------------------------------- > >> --- > >> ---------------- > >>> Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. > (JUGS). > >>> For more information visit www.jugs.de. > >>> > >>> > >> > >> > > > From swpalmer at gmail.com Fri Dec 14 12:15:03 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 14 Dec 2012 15:15:03 -0500 Subject: JFXPanel In-Reply-To: <50CB519F.9090302@media-interactive.de> References: <50CB519F.9090302@media-interactive.de> Message-ID: I need to present a dialog when interacting with some of the JavaFX controls. Since a JavaFX Dialog doesn't work properly without a JavaFX Window, I need to continue to use a JOptionPane or JDialog. The current Swing code doesn't have a reference to the parent JFrame. It just uses the control that is associated with the action that triggered the need for a dialog/JOptionPane as the parent. E.g. I press a JButton and a JOptionPane appears. The JOptionPane knows about the button and can use that as the parent component. Now I have a JavaFX Button? but no path to a reasonable parent for the JOptionPane. Scott On 2012-12-14, at 11:19 AM, Werner Lehmann wrote: > Scott, > > JFXPanel has quite a few issues (look for JFXPanel or Swing in Jira). Among those is the filechooser problem. It is probably just one instance of the problem that a JavaFX stage cannot be modal or on top of Swing windows. > > To work around this we have to put JFXPanels in JDialogs. Not really sexy: apart from the overhead in code we know today that we have to touch this again one day to convert the JDialog to a stage. > > Regarding your problem of how to get from a node to the JFXPanel: no idea why you would want to do this. I have a dozen jfxpanels but never needed such a thing. I guess you could extend JFXPanel and add a reference to the fxpanel to some userdata on a node, or something like that. > > Rgds > Werner > > On 14.12.2012 16:39, Scott Palmer wrote: >> I'm trying to migrate more of my app from Swing to JavaFX piece-wise >> via JFXPanels. It's not fun as there are many rough edges. In order >> to work around some of them I am wondering if it is possible to get a >> reference to the JFXPanel if all I have is a Node? I can get the >> Scene's Window, an "Embedded" Window that seems to be the root of a >> lot of problems with popups and dialogs. That seems to be enough to >> determine that the Node is hosted by a JFXPanel, but can I actually >> get the JFXPanel instance? >> >> If there is a way via public APIs that don't rely on me peaking at >> implementation details like com.sun.javafx.stage.EmbeddedWindow? >> >> Along this line? why is it that things like the FileChooser and other >> JavaFX dialogs don't respect the window ordering when used from a >> JFXPanel? They easily flip behind the parent JFrame. I would have >> thought that the correct Window hierarchy in native land could still >> include the native window of the JFrame and that should prevent such >> things. >> >> Scott > From hang.vo at oracle.com Fri Dec 14 15:17:59 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 14 Dec 2012 23:17:59 +0000 Subject: hg: openjfx/8/controls/rt: fix RT-25187 charts - duplicate children added when sorting the chart data. Message-ID: <20121214231805.01D1B47181@hg.openjdk.java.net> Changeset: e67a5c63ca31 Author: Paru Somashekar Date: 2012-12-14 15:08 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e67a5c63ca31 fix RT-25187 charts - duplicate children added when sorting the chart data. + unit test. ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java ! javafx-ui-charts/test/javafx/scene/chart/XYChartDataTest.java From ozemale at ozemail.com.au Sun Dec 16 01:33:44 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Sun, 16 Dec 2012 20:33:44 +1100 Subject: LCD text in Canvas Message-ID: <007e01cddb70$718034a0$54809de0$@com.au> When will JavaFX Canvas support LCD text? Thanks, -jct From tbee at tbee.org Sun Dec 16 02:49:04 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 16 Dec 2012 11:49:04 +0100 Subject: LCD text in Canvas In-Reply-To: <007e01cddb70$718034a0$54809de0$@com.au> References: <007e01cddb70$718034a0$54809de0$@com.au> Message-ID: <50CDA720.30402@tbee.org> I think Canvas will never support that, just like a real world painting canvas will never support a Rembrand. You'll have to create LCD yourself. But Gerrit has created a few LCD gauges in the JFXtras project, maybe those will help. On 2012-12-16 10:33, John C. Turnbull wrote: > When will JavaFX Canvas support LCD text? > > > > Thanks, > > > > -jct > From tom.schindl at bestsolution.at Sun Dec 16 03:34:11 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sun, 16 Dec 2012 12:34:11 +0100 Subject: LCD text in Canvas In-Reply-To: <50CDA720.30402@tbee.org> References: <007e01cddb70$718034a0$54809de0$@com.au> <50CDA720.30402@tbee.org> Message-ID: <50CDB1B3.2040004@bestsolution.at> Isn't he talking about the font-rendering? Tom Am 16.12.12 11:49, schrieb Tom Eugelink: > I think Canvas will never support that, just like a real world painting > canvas will never support a Rembrand. You'll have to create LCD > yourself. But Gerrit has created a few LCD gauges in the JFXtras > project, maybe those will help. > > > > On 2012-12-16 10:33, John C. Turnbull wrote: >> When will JavaFX Canvas support LCD text? >> >> >> Thanks, >> >> >> -jct >> > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From tbee at tbee.org Sun Dec 16 04:02:59 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 16 Dec 2012 13:02:59 +0100 Subject: LCD text in Canvas In-Reply-To: <50CDB1B3.2040004@bestsolution.at> References: <007e01cddb70$718034a0$54809de0$@com.au> <50CDA720.30402@tbee.org> <50CDB1B3.2040004@bestsolution.at> Message-ID: <50CDB873.8070808@tbee.org> Could be. But phrased like that, I read it as something bigger, more an LCD control. LCD fonts are readily available on the internet and have not much to do with canvas specifically. Tom On 2012-12-16 12:34, Tom Schindl wrote: > Isn't he talking about the font-rendering? > > Tom > > Am 16.12.12 11:49, schrieb Tom Eugelink: >> I think Canvas will never support that, just like a real world painting >> canvas will never support a Rembrand. You'll have to create LCD >> yourself. But Gerrit has created a few LCD gauges in the JFXtras >> project, maybe those will help. >> >> >> >> On 2012-12-16 10:33, John C. Turnbull wrote: >>> When will JavaFX Canvas support LCD text? >>> >>> >>> Thanks, >>> >>> >>> -jct >>> > From james.weaver at oracle.com Sun Dec 16 04:50:22 2012 From: james.weaver at oracle.com (Jim Weaver) Date: Sun, 16 Dec 2012 07:50:22 -0500 Subject: LCD text in Canvas In-Reply-To: <50CDB873.8070808@tbee.org> References: <007e01cddb70$718034a0$54809de0$@com.au> <50CDA720.30402@tbee.org> <50CDB1B3.2040004@bestsolution.at> <50CDB873.8070808@tbee.org> Message-ID: <50CDC38E.8000506@oracle.com> I'm sure that Gerrit appreciated the association with Rembrandt though :-) Regards, Jim Weaver On 12/16/12 7:02 AM, Tom Eugelink wrote: > Could be. But phrased like that, I read it as something bigger, more > an LCD control. LCD fonts are readily available on the internet and > have not much to do with canvas specifically. > > Tom > > > > On 2012-12-16 12:34, Tom Schindl wrote: >> Isn't he talking about the font-rendering? >> >> Tom >> >> Am 16.12.12 11:49, schrieb Tom Eugelink: >>> I think Canvas will never support that, just like a real world painting >>> canvas will never support a Rembrand. You'll have to create LCD >>> yourself. But Gerrit has created a few LCD gauges in the JFXtras >>> project, maybe those will help. >>> >>> >>> >>> On 2012-12-16 10:33, John C. Turnbull wrote: >>>> When will JavaFX Canvas support LCD text? >>>> >>>> Thanks, >>>> >>>> -jct >>>> >> > -- Regards, Jim Weaver Java Technology Ambassador Oracle Corporation james.weaver at oracle.com From mp at jugs.org Sun Dec 16 05:35:42 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Sun, 16 Dec 2012 14:35:42 +0100 Subject: LCD text in Canvas In-Reply-To: <50CDA720.30402@tbee.org> References: <007e01cddb70$718034a0$54809de0$@com.au> <50CDA720.30402@tbee.org> Message-ID: <50CDCE2E.8000002@jugs.org> I am quite sure the OP is referring to this: https://blogs.oracle.com/javafx/entry/lcd_text_support_in_javafx Whether that is or will be supported for Cancas - I don't know. Michael Am 16.12.2012 11:49, schrieb Tom Eugelink: > I think Canvas will never support that, just like a real world > painting canvas will never support a Rembrand. You'll have to create > LCD yourself. But Gerrit has created a few LCD gauges in the JFXtras > project, maybe those will help. > > > > On 2012-12-16 10:33, John C. Turnbull wrote: >> When will JavaFX Canvas support LCD text? >> >> >> Thanks, >> >> >> -jct >> > -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From tbee at tbee.org Sun Dec 16 07:14:29 2012 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 16 Dec 2012 16:14:29 +0100 Subject: LCD text in Canvas In-Reply-To: <50CDCE2E.8000002@jugs.org> References: <007e01cddb70$718034a0$54809de0$@com.au> <50CDA720.30402@tbee.org> <50CDCE2E.8000002@jugs.org> Message-ID: <50CDE555.9050307@tbee.org> Ah, yes, that is another take on the matter (what a simple question can do). But LCD text on a canvas will turn into vectors or bits I guess, so LCD text won't help much I figure. Tom On 2012-12-16 14:35, Dr. Michael Paus wrote: > I am quite sure the OP is referring to this: > https://blogs.oracle.com/javafx/entry/lcd_text_support_in_javafx > Whether that is or will be supported for Cancas - I don't know. > Michael > > Am 16.12.2012 11:49, schrieb Tom Eugelink: >> I think Canvas will never support that, just like a real world >> painting canvas will never support a Rembrand. You'll have to create >> LCD yourself. But Gerrit has created a few LCD gauges in the JFXtras >> project, maybe those will help. >> >> >> >> On 2012-12-16 10:33, John C. Turnbull wrote: >>> When will JavaFX Canvas support LCD text? >>> >>> >>> Thanks, >>> >>> >>> -jct >>> >> > > From ozemale at ozemail.com.au Sun Dec 16 07:16:53 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Mon, 17 Dec 2012 02:16:53 +1100 Subject: LCD text in Canvas In-Reply-To: <50CDCE2E.8000002@jugs.org> References: <007e01cddb70$718034a0$54809de0$@com.au> <50CDA720.30402@tbee.org> <50CDCE2E.8000002@jugs.org> Message-ID: <009301cddba0$6150ada0$23f208e0$@com.au> Yes sorry, I was referring to LCD font rendering (or sub-pixel antialiasing). It seems JavaFX text controls support this but text rendered in Canvas is always using gray-scale antialiasing and looks blurry in comparison as a result. -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Dr. Michael Paus Sent: Monday, 17 December 2012 00:36 To: openjfx-dev at openjdk.java.net Subject: Re: LCD text in Canvas I am quite sure the OP is referring to this: https://blogs.oracle.com/javafx/entry/lcd_text_support_in_javafx Whether that is or will be supported for Cancas - I don't know. Michael Am 16.12.2012 11:49, schrieb Tom Eugelink: > I think Canvas will never support that, just like a real world > painting canvas will never support a Rembrand. You'll have to create > LCD yourself. But Gerrit has created a few LCD gauges in the JFXtras > project, maybe those will help. > > > > On 2012-12-16 10:33, John C. Turnbull wrote: >> When will JavaFX Canvas support LCD text? >> >> >> Thanks, >> >> >> -jct >> > -- ---------------------------------------------------------------------------- ---------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From philip.race at oracle.com Sun Dec 16 14:25:17 2012 From: philip.race at oracle.com (Phil Race) Date: Sun, 16 Dec 2012 14:25:17 -0800 Subject: LCD text in Canvas In-Reply-To: <009301cddba0$6150ada0$23f208e0$@com.au> References: <007e01cddb70$718034a0$54809de0$@com.au> <50CDA720.30402@tbee.org> <50CDCE2E.8000002@jugs.org> <009301cddba0$6150ada0$23f208e0$@com.au> Message-ID: <50CE4A4D.4090702@oracle.com> We could easily add API to support LCD text on Canvas although we wanted to minimise the amount of Text related API there until we have more experience with how people use it and how it should be developed in general. The blurriness is down to the grayscale text being unhinted so it behaves predictably under transformations as supposed to be the most typical canvas uses case. This is also why its the default on a Text node. -phil. On 12/16/12 7:16 AM, John C. Turnbull wrote: > Yes sorry, I was referring to LCD font rendering (or sub-pixel > antialiasing). It seems JavaFX text controls support this but text rendered > in Canvas is always using gray-scale antialiasing and looks blurry in > comparison as a result. > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net > [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Dr. Michael Paus > Sent: Monday, 17 December 2012 00:36 > To: openjfx-dev at openjdk.java.net > Subject: Re: LCD text in Canvas > > I am quite sure the OP is referring to this: > https://blogs.oracle.com/javafx/entry/lcd_text_support_in_javafx > Whether that is or will be supported for Cancas - I don't know. > Michael > > Am 16.12.2012 11:49, schrieb Tom Eugelink: >> I think Canvas will never support that, just like a real world >> painting canvas will never support a Rembrand. You'll have to create >> LCD yourself. But Gerrit has created a few LCD gauges in the JFXtras >> project, maybe those will help. >> >> >> >> On 2012-12-16 10:33, John C. Turnbull wrote: >>> When will JavaFX Canvas support LCD text? >>> >>> >>> Thanks, >>> >>> >>> -jct >>> > > -- > ---------------------------------------------------------------------------- > ---------- > Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). > For more information visit www.jugs.de. > From ozemale at ozemail.com.au Sun Dec 16 15:14:11 2012 From: ozemale at ozemail.com.au (ozemale at ozemail.com.au) Date: Mon, 17 Dec 2012 07:14:11 +0800 Subject: LCD text in Canvas In-Reply-To: <50CE4A4D.4090702@oracle.com> Message-ID: <77f28445b915ed74024b08d3925fb7906158672c@webmail.iinet.net.au> I think for the vast majority of use cases we would want LCD text in Canvas.? The current grayscale antialiasing is just too blurry and is very noticeably different in rendering quality to the text used in controls. I am thinking that adding a single method to set the smoothing type for text would not cause too much bloat in the API.? I am officially requesting it! Thanks, -jct ----- Original Message ----- From: "Phil Race" To:"John C. Turnbull" Cc:"Dr. Michael Paus" , Sent:Sun, 16 Dec 2012 14:25:17 -0800 Subject:Re: LCD text in Canvas We could easily add API to support LCD text on Canvas although we wanted to minimise the amount of Text related API there until we have more experience with how people use it and how it should be developed in general. The blurriness is down to the grayscale text being unhinted so it behaves predictably under transformations as supposed to be the most typical canvas uses case. This is also why its the default on a Text node. -phil. On 12/16/12 7:16 AM, John C. Turnbull wrote: > Yes sorry, I was referring to LCD font rendering (or sub-pixel > antialiasing). It seems JavaFX text controls support this but text rendered > in Canvas is always using gray-scale antialiasing and looks blurry in > comparison as a result. > > -----Original Message----- > From: openjfx-dev-bounces at openjdk.java.net > [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Dr. Michael Paus > Sent: Monday, 17 December 2012 00:36 > To: openjfx-dev at openjdk.java.net > Subject: Re: LCD text in Canvas > > I am quite sure the OP is referring to this: > https://blogs.oracle.com/javafx/entry/lcd_text_support_in_javafx > Whether that is or will be supported for Cancas - I don't know. > Michael > > Am 16.12.2012 11:49, schrieb Tom Eugelink: >> I think Canvas will never support that, just like a real world >> painting canvas will never support a Rembrand. You'll have to create >> LCD yourself But Gerrit has created a few LCD gauges in the JFXtras >> project, maybe those will help. >> >> >> >> On 2012-12-16 10:33, John C. Turnbull wrote: >>> When will JavaFX Canvas support LCD text? >>> >>> >>> Thanks, >>> >>> >>> -jct >>> > > -- > ---------------------------------------------------------------------------- > ---------- > Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). > For more information visit www.jugs.de. > From joseph.andresen at oracle.com Sun Dec 16 21:13:40 2012 From: joseph.andresen at oracle.com (Joseph Andresen) Date: Sun, 16 Dec 2012 21:13:40 -0800 Subject: LCD text in Canvas In-Reply-To: <77f28445b915ed74024b08d3925fb7906158672c@webmail.iinet.net.au> References: <77f28445b915ed74024b08d3925fb7906158672c@webmail.iinet.net.au> Message-ID: <1F367C06-A7FB-4870-9D92-252DED2CAA9E@oracle.com> It would really help if you could explain your use cases. Canvas is meant for very dynamic rendering, and I don't really want to say LCD text isn't, but it certainly is not meant to be animated. Hmm... -J On Dec 16, 2012, at 3:14 PM, ozemale at ozemail.com.au wrote: > I think for the vast majority of use cases we would want LCD text in > Canvas. The current grayscale antialiasing is just too blurry and is > very noticeably different in rendering quality to the text used in > controls. > > I am thinking that adding a single method to set the smoothing type > for text would not cause too much bloat in the API. I am officially > requesting it! > > Thanks, > > -jct > > ----- Original Message ----- > From: "Phil Race" > To:"John C. Turnbull" > Cc:"Dr. Michael Paus" , > Sent:Sun, 16 Dec 2012 14:25:17 -0800 > Subject:Re: LCD text in Canvas > > We could easily add API to support LCD text on Canvas although > we wanted to minimise the amount of Text related API there until > we have more experience with how people use it and how it should > be developed in general. > The blurriness is down to the grayscale text being unhinted so it > behaves predictably under transformations as supposed to be the most > typical canvas uses case. This is also why its the default on a Text > node. > > -phil. > > On 12/16/12 7:16 AM, John C. Turnbull wrote: >> Yes sorry, I was referring to LCD font rendering (or sub-pixel >> antialiasing). It seems JavaFX text controls support this but text > rendered >> in Canvas is always using gray-scale antialiasing and looks blurry > in >> comparison as a result. >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net >> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Dr. > Michael Paus >> Sent: Monday, 17 December 2012 00:36 >> To: openjfx-dev at openjdk.java.net >> Subject: Re: LCD text in Canvas >> >> I am quite sure the OP is referring to this: >> https://blogs.oracle.com/javafx/entry/lcd_text_support_in_javafx >> Whether that is or will be supported for Cancas - I don't know. >> Michael >> >> Am 16.12.2012 11:49, schrieb Tom Eugelink: >>> I think Canvas will never support that, just like a real world >>> painting canvas will never support a Rembrand. You'll have to > create >>> LCD yourself But Gerrit has created a few LCD gauges in the > JFXtras >>> project, maybe those will help. >>> >>> >>> >>> On 2012-12-16 10:33, John C. Turnbull wrote: >>>> When will JavaFX Canvas support LCD text? >>>> >>>> >>>> Thanks, >>>> >>>> >>>> -jct >> >> -- > ---------------------------------------------------------------------------- >> ---------- >> Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. > (JUGS). >> For more information visit www.jugs.de. > > From hang.vo at oracle.com Sun Dec 16 22:18:22 2012 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 17 Dec 2012 06:18:22 +0000 Subject: hg: openjfx/8/controls/rt: 7 new changesets Message-ID: <20121217061836.2B69A471B8@hg.openjdk.java.net> Changeset: a563c56b55be Author: jgiles Date: 2012-12-14 10:16 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a563c56b55be RT-26988: [TreeTableView] Exception is thrown column is resized ! javafx-ui-controls/src/javafx/scene/control/TableUtil.java Changeset: 0c9f73153402 Author: jgiles Date: 2012-12-14 10:41 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0c9f73153402 RT-26986: [TreeTableView] When all columns are removed, they will still be rendered (also happens in TableView) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/NestedTableColumnHeader.java Changeset: 66aa13deb8e7 Author: jgiles Date: 2012-12-14 10:50 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/66aa13deb8e7 RT-26989: [TreeTableView] Sort node is not applied immediately when it is set ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java Changeset: 1eedf8a7ec44 Author: jgiles Date: 2012-12-14 10:54 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1eedf8a7ec44 RT-26945: generics-related compilation failure in TreeUtil.java using jdk 8 ! javafx-ui-controls/src/javafx/scene/control/TreeUtil.java Changeset: e0f30632c828 Author: jgiles Date: 2012-12-14 11:32 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e0f30632c828 RT-26914: [TreeTableView] Tree item is not expanded by single mouse click. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java Changeset: 240670cfcc48 Author: jgiles Date: 2012-12-17 18:59 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/240670cfcc48 RT-25684: GridPane.layoutChildren() hangs when wrapText is true ! javafx-ui-common/src/javafx/scene/layout/GridPane.java Changeset: f66c819f406c Author: jgiles Date: 2012-12-17 18:59 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f66c819f406c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java From ozemale at ozemail.com.au Mon Dec 17 00:23:17 2012 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Mon, 17 Dec 2012 19:23:17 +1100 Subject: LCD text in Canvas In-Reply-To: <1F367C06-A7FB-4870-9D92-252DED2CAA9E@oracle.com> References: <77f28445b915ed74024b08d3925fb7906158672c@webmail.iinet.net.au> <1F367C06-A7FB-4870-9D92-252DED2CAA9E@oracle.com> Message-ID: <006701cddc2f$c4462f40$4cd28dc0$@com.au> The way I see it, Canvas is certainly for dynamic rendering but that's not to say that LCD text would need to be animated (although it would be absolutely wonderful if it could be). I am thinking of developing some sophisticated controls which have a very dynamic nature and, as I said, I want the text in those controls to be as crisp and clear as the other more "standard/static" controls. For the uninitiated, what exactly is the problem with animating LCD text anyway? It seems to be possible in Flash, Silverlight and even in HTML 5 so why should it not be possible in JavaFX? Thanks, -jct -----Original Message----- From: Joseph Andresen [mailto:joseph.andresen at oracle.com] Sent: Monday, 17 December 2012 16:14 To: ozemale at ozemail.com.au Cc: Phil Race; John C. Turnbull; openjfx-dev at openjdk.java.net Subject: Re: LCD text in Canvas It would really help if you could explain your use cases. Canvas is meant for very dynamic rendering, and I don't really want to say LCD text isn't, but it certainly is not meant to be animated. Hmm... -J On Dec 16, 2012, at 3:14 PM, ozemale at ozemail.com.au wrote: > I think for the vast majority of use cases we would want LCD text in > Canvas. The current grayscale antialiasing is just too blurry and is > very noticeably different in rendering quality to the text used in > controls. > > I am thinking that adding a single method to set the smoothing type > for text would not cause too much bloat in the API. I am officially > requesting it! > > Thanks, > > -jct > > ----- Original Message ----- > From: "Phil Race" > To:"John C. Turnbull" > Cc:"Dr. Michael Paus" , > Sent:Sun, 16 Dec 2012 14:25:17 -0800 > Subject:Re: LCD text in Canvas > > We could easily add API to support LCD text on Canvas although we > wanted to minimise the amount of Text related API there until we have > more experience with how people use it and how it should be developed > in general. > The blurriness is down to the grayscale text being unhinted so it > behaves predictably under transformations as supposed to be the most > typical canvas uses case. This is also why its the default on a Text > node. > > -phil. > > On 12/16/12 7:16 AM, John C. Turnbull wrote: >> Yes sorry, I was referring to LCD font rendering (or sub-pixel >> antialiasing). It seems JavaFX text controls support this but text > rendered >> in Canvas is always using gray-scale antialiasing and looks blurry > in >> comparison as a result. >> >> -----Original Message----- >> From: openjfx-dev-bounces at openjdk.java.net >> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Dr. > Michael Paus >> Sent: Monday, 17 December 2012 00:36 >> To: openjfx-dev at openjdk.java.net >> Subject: Re: LCD text in Canvas >> >> I am quite sure the OP is referring to this: >> https://blogs.oracle.com/javafx/entry/lcd_text_support_in_javafx >> Whether that is or will be supported for Cancas - I don't know. >> Michael >> >> Am 16.12.2012 11:49, schrieb Tom Eugelink: >>> I think Canvas will never support that, just like a real world >>> painting canvas will never support a Rembrand. You'll have to > create >>> LCD yourself But Gerrit has created a few LCD gauges in the > JFXtras >>> project, maybe those will help. >>> >>> >>> >>> On 2012-12-16 10:33, John C. Turnbull wrote: >>>> When will JavaFX Canvas support LCD text? >>>> >>>> >>>> Thanks, >>>> >>>> >>>> -jct >> >> -- > ---------------------------------------------------------------------- > ------ >> ---------- >> Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. > (JUGS). >> For more information visit www.jugs.de. > > From bruno.borges at oracle.com Mon Dec 17 00:45:44 2012 From: bruno.borges at oracle.com (Bruno Borges) Date: Mon, 17 Dec 2012 06:45:44 -0200 Subject: WebFX - Running FXML JavaFX as web pages Message-ID: <50CEDBB8.6000208@oracle.com> Hi everyone, This weekend I wanted to learn some JavaFX, and decided to code an idea I had years ago when I first saw JavaFX Script. The project, WebFX, has a prototype on GitHub and I uploaded a video on YouTube showing what's it all about. Any comments are welcome. https://www.youtube.com/watch?v=5yatMypNrTA https://github.com/brunoborges/webfx Thanks -- Bruno Borges Principal Product Manager | JavaEE WebLogic GlassFish Oracle LAD PM Team | Cloud Application Foundation +55 11 5187 6514 (Work) | +55 11 99564 9058 (Mobi) From artem.ananiev at oracle.com Mon Dec 17 02:55:03 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 17 Dec 2012 14:55:03 +0400 Subject: JFXPanel In-Reply-To: <50CB519F.9090302@media-interactive.de> References: <50CB519F.9090302@media-interactive.de> Message-ID: <50CEFA07.2090104@oracle.com> On 12/14/2012 8:19 PM, Werner Lehmann wrote: > Scott, > > JFXPanel has quite a few issues (look for JFXPanel or Swing in Jira). > Among those is the filechooser problem. It is probably just one instance > of the problem that a JavaFX stage cannot be modal or on top of Swing > windows. Yes, z-order and modality problems with Swing and FX top-level windows is a known issue. Unfortunately, I don't know a good way to fix it: AWT/Swing doesn't expose enough information to use its windows as owner windows for other UI toolkits. Thanks, Artem > To work around this we have to put JFXPanels in JDialogs. Not really > sexy: apart from the overhead in code we know today that we have to > touch this again one day to convert the JDialog to a stage. > > Regarding your problem of how to get from a node to the JFXPanel: no > idea why you would want to do this. I have a dozen jfxpanels but never > needed such a thing. I guess you could extend JFXPanel and add a > reference to the fxpanel to some userdata on a node, or something like > that. > > Rgds > Werner > > On 14.12.2012 16:39, Scott Palmer wrote: >> I'm trying to migrate more of my app from Swing to JavaFX piece-wise >> via JFXPanels. It's not fun as there are many rough edges. In order >> to work around some of them I am wondering if it is possible to get a >> reference to the JFXPanel if all I have is a Node? I can get the >> Scene's Window, an "Embedded" Window that seems to be the root of a >> lot of problems with popups and dialogs. That seems to be enough to >> determine that the Node is hosted by a JFXPanel, but can I actually >> get the JFXPanel instance? >> >> If there is a way via public APIs that don't rely on me peaking at >> implementation details like com.sun.javafx.stage.EmbeddedWindow? >> >> Along this line? why is it that things like the FileChooser and other >> JavaFX dialogs don't respect the window ordering when used from a >> JFXPanel? They easily flip behind the parent JFrame. I would have >> thought that the correct Window hierarchy in native land could still >> include the native window of the JFrame and that should prevent such >> things. >> >> Scott > From artem.ananiev at oracle.com Mon Dec 17 03:09:57 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 17 Dec 2012 15:09:57 +0400 Subject: JFXPanel ignores size change of root node In-Reply-To: <50CB7588.9060607@media-interactive.de> References: <50CB7588.9060607@media-interactive.de> Message-ID: <50CEFD85.4000802@oracle.com> Hi, Werner, On 12/14/2012 10:52 PM, Werner Lehmann wrote: > Hi, > > as far as I know JFXPanel is supposed to be sized according to its > content (also stated in RT-13758). This does not seem to work when the this is true... to some extent. JFXPanel's preferred size is set only once, when a scene is attached to it. If you change scene content after that, scene/stage size is not suppose to change. Just imagine the following scenario. Create a regular FX Stage and put a 120x120 button inside. Then show the stage. Then set an action listener to the button, so it changes the button size to 160x120. Will the stage size change, when the button is clicked? > content's size changes later: the jfxpanel is not resized along. > > Hopefully I am missing something. The test code below creates a Swing > flowlayout with a button, a jfxpanel, and a label: > http://s16.postimage.org/6nfil2myt/jfxpanel_width_160px.png > > When clicking the button, the rectangle inside the fxpanel is resized > from 160px to 120px width. The jfxpanel itself does not seem to be resized: > http://s16.postimage.org/p1q1p1z9h/jfxpanel_width_120px.png > > It also does not work to increase the rectangle width - the jfxpanel > width does not change. In my non-test application I have tried to remove > and add the jfxpanel but that only works sometimes and is not exactly > elegant. Any ideas? Could you try to leave JFXPanel as is, but set its scene to null and back to your scene, please? I don't say it's the way it's supposed to work, just an idea for workaround. In general, updating JFXPanel's preferred size upon FX scene size/content changes looks like a valid request. It's not a pure JFXPanel feature, though: we need to have a notification from Scene to know that the window size should be updated. Thanks, Artem > Rgds > Werner > >> public class JFXPanelResizeTest >> { >> public static void main(String[] args) >> { >> SwingUtilities.invokeLater(new Runnable() { >> @Override public void run() { initAndShowGUI(); } >> }); >> } >> >> private static void initAndShowGUI() >> { >> final JFrame f = new JFrame("Test JFXPanel resize"); >> f.setSize(600, 200); >> f.setLocationRelativeTo(null); >> f.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE); >> f.setLayout(new FlowLayout()); >> final MyJFXPanel fxPanel = new MyJFXPanel(); >> JButton button = new JButton("Toggle Rectangel Width"); >> button.addActionListener(new ActionListener() { >> @Override public void actionPerformed(ActionEvent >> paramActionEvent) { fxPanel.toggle(); } >> }); >> f.add(button); >> f.add(fxPanel); >> f.add(new JLabel("Label1")); >> f.setVisible(true); >> } >> >> private static class MyJFXPanel extends JFXPanel >> { >> private final Rectangle r = new Rectangle(160, 120); >> >> public MyJFXPanel() >> { >> Platform.runLater(new Runnable() { >> @Override public void run() { setScene(new Scene(new >> Group(r))); } >> }); >> } >> >> // Toggle rectangle width 120px / 160px. >> public void toggle() >> { >> Platform.runLater(new Runnable() { >> @Override public void run() { r.setWidth(r.getWidth() == 160 ? >> 120 : 160); } >> }); >> } >> } >> } > > From lehmann at media-interactive.de Mon Dec 17 03:59:29 2012 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 17 Dec 2012 12:59:29 +0100 Subject: JFXPanel ignores size change of root node In-Reply-To: <50CEFD85.4000802@oracle.com> References: <50CB7588.9060607@media-interactive.de> <50CEFD85.4000802@oracle.com> Message-ID: <50CF0921.4040502@media-interactive.de> Hi Artem, On 17.12.2012 12:09, Artem Ananiev wrote: > Just imagine the following scenario. Create a regular FX Stage and put a > 120x120 button inside. Then show the stage. Then set an action listener > to the button, so it changes the button size to 160x120. Will the stage > size change, when the button is clicked? coincidentally I tried that while you were typing up that email. The stage does not resize. Inspection in a breakpoint shows that also the scene.width does not change. So how would the stage know about it anyway... > Could you try to leave JFXPanel as is, but set its scene to null and > back to your scene, please? I don't say it's the way it's supposed to > work, just an idea for workaround. This works - sometimes. If I keep clicking that button I get about 70% correct results and occasionally the JFXPanel did not resize as desired. Here's the kicker: sleeping for 10ms after setting the scene works reliably (on my machine and for this simple scene). 9ms is not enough: r.setWidth(r.getWidth() == 160 ? 120 : 160); Scene scene = getScene(); setScene(null); setScene(scene); sleep(10); Not exactly reassuring but better than before. Alternatively, the sleep can be moved to the EDT which also works: r.setWidth(r.getWidth() == 160 ? 120 : 160); Scene scene = getScene(); setScene(null); setScene(scene); SwingUtilities.invokeLater(new Runnable() { @Override public void run() { sleep(10); invalidate(); } }); Some kind of strange race condition? Obviously I'd like to avoid any hardcoded sleeps... Also: am I supposed to invalidate on EDT, or not? Seems to work without. > In general, updating JFXPanel's preferred size upon FX scene > size/content changes looks like a valid request. It's not a pure > JFXPanel feature, though: we need to have a notification from Scene to > know that the window size should be updated. Scene has observable width/height properties. Not sure if those change but at least Scene.root.*anyboundsproperty* should do. Rgds Werner From swpalmer at gmail.com Mon Dec 17 04:49:55 2012 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 17 Dec 2012 07:49:55 -0500 Subject: JFXPanel In-Reply-To: <50CEFA07.2090104@oracle.com> References: <50CB519F.9090302@media-interactive.de> <50CEFA07.2090104@oracle.com> Message-ID: <9C870ECA-7C84-4041-9F7C-5880C0E47905@gmail.com> On 2012-12-17, at 5:55 AM, Artem Ananiev wrote: > > On 12/14/2012 8:19 PM, Werner Lehmann wrote: >> Scott, >> >> JFXPanel has quite a few issues (look for JFXPanel or Swing in Jira). >> Among those is the filechooser problem. It is probably just one instance >> of the problem that a JavaFX stage cannot be modal or on top of Swing >> windows. > > Yes, z-order and modality problems with Swing and FX top-level windows is a known issue. Unfortunately, I don't know a good way to fix it: AWT/Swing doesn't expose enough information to use its windows as owner windows for other UI toolkits. Not on the Java side, but it does if you use JNI... jawt.h has enough information to get the native window handle. In fact I wanted the equivalent of jawt.h for JavaFX windows as without it we lose the ability to render directly into windows of the java app. I need to effectively do a video overlay. Scott > > Thanks, > > Artem > >> To work around this we have to put JFXPanels in JDialogs. Not really >> sexy: apart from the overhead in code we know today that we have to >> touch this again one day to convert the JDialog to a stage. >> >> Regarding your problem of how to get from a node to the JFXPanel: no >> idea why you would want to do this. I have a dozen jfxpanels but never >> needed such a thing. I guess you could extend JFXPanel and add a >> reference to the fxpanel to some userdata on a node, or something like >> that. >> >> Rgds >> Werner >> >> On 14.12.2012 16:39, Scott Palmer wrote: >>> I'm trying to migrate more of my app from Swing to JavaFX piece-wise >>> via JFXPanels. It's not fun as there are many rough edges. In order >>> to work around some of them I am wondering if it is possible to get a >>> reference to the JFXPanel if all I have is a Node? I can get the >>> Scene's Window, an "Embedded" Window that seems to be the root of a >>> lot of problems with popups and dialogs. That seems to be enough to >>> determine that the Node is hosted by a JFXPanel, but can I actually >>> get the JFXPanel instance? >>> >>> If there is a way via public APIs that don't rely on me peaking at >>> implementation details like com.sun.javafx.stage.EmbeddedWindow? >>> >>> Along this line? why is it that things like the FileChooser and other >>> JavaFX dialogs don't respect the window ordering when used from a >>> JFXPanel? They easily flip behind the parent JFrame. I would have >>> thought that the correct Window hierarchy in native land could still >>> include the native window of the JFrame and that should prevent such >>> things. >>> >>> Scott >> From artem.ananiev at oracle.com Mon Dec 17 04:49:45 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 17 Dec 2012 16:49:45 +0400 Subject: JFXPanel ignores size change of root node In-Reply-To: <50CF0921.4040502@media-interactive.de> References: <50CB7588.9060607@media-interactive.de> <50CEFD85.4000802@oracle.com> <50CF0921.4040502@media-interactive.de> Message-ID: <50CF14E9.7080607@oracle.com> On 12/17/2012 3:59 PM, Werner Lehmann wrote: > Hi Artem, > > On 17.12.2012 12:09, Artem Ananiev wrote: >> Just imagine the following scenario. Create a regular FX Stage and put a >> 120x120 button inside. Then show the stage. Then set an action listener >> to the button, so it changes the button size to 160x120. Will the stage >> size change, when the button is clicked? > > coincidentally I tried that while you were typing up that email. The > stage does not resize. Inspection in a breakpoint shows that also the > scene.width does not change. So how would the stage know about it anyway... Thanks for trying this. My assumption about JFXPanel behaving exactly like regular FX Stage was correct. If we want to "fix" it, the fix will be common for embedded and standalone windows. At the API level we have code that calculates Scene's preferred size and resize Stage so it perfectly matches this Scene. It's only done a) when the window is being shown b) if the window size was not set explicitly. This code can be extracted into a public method to be called by application at arbitrary moment, close to AWT's Frame.pack(). Jasper, Richard, what do you think about this idea? >> Could you try to leave JFXPanel as is, but set its scene to null and >> back to your scene, please? I don't say it's the way it's supposed to >> work, just an idea for workaround. > > This works - sometimes. If I keep clicking that button I get about 70% > correct results and occasionally the JFXPanel did not resize as desired. > Here's the kicker: sleeping for 10ms after setting the scene works > reliably (on my machine and for this simple scene). 9ms is not enough: > > r.setWidth(r.getWidth() == 160 ? 120 : 160); > Scene scene = getScene(); > setScene(null); > setScene(scene); > sleep(10); > > Not exactly reassuring but better than before. Alternatively, the sleep > can be moved to the EDT which also works: > > r.setWidth(r.getWidth() == 160 ? 120 : 160); > Scene scene = getScene(); > setScene(null); > setScene(scene); > SwingUtilities.invokeLater(new Runnable() { > @Override > public void run() > { > sleep(10); > invalidate(); > } > }); > > Some kind of strange race condition? Obviously I'd like to avoid any > hardcoded sleeps... Also: am I supposed to invalidate on EDT, or not? > Seems to work without. invalidate(), as well as JComponent.revalidate(), is thread safe. In general, it looks like a bug, we shouldn't depend on the timings. Please, file a new bug to JavaFX JIRA, but I can't guarantee it will be fixed in a few hours :) Thanks, Artem >> In general, updating JFXPanel's preferred size upon FX scene >> size/content changes looks like a valid request. It's not a pure >> JFXPanel feature, though: we need to have a notification from Scene to >> know that the window size should be updated. > > Scene has observable width/height properties. Not sure if those change > but at least Scene.root.*anyboundsproperty* should do. > > Rgds > Werner From mark.bulthuis at nedap.com Mon Dec 17 05:42:45 2012 From: mark.bulthuis at nedap.com (Mark Bulthuis) Date: Mon, 17 Dec 2012 14:42:45 +0100 Subject: How to set grid line color in CSS? Message-ID: <03230006CA5E1B4D89CCC1DC0BF2209C047254469A@NVS0192.nedap.local> Hi, It seems simple. Create a GridPane and add css property to define the color of the lines, but...no. If you take a look at the source of GridPane, method createGidline, a constant GRID_LINE_COLOR is used: private static final Color GRID_LINE_COLOR = Color.rgb(30, 30, 30); All these methods are private. Can someone tell me what to do? Greetz, Mark From randahl at rockit.dk Mon Dec 17 05:46:49 2012 From: randahl at rockit.dk (Randahl Fink Isaksen) Date: Mon, 17 Dec 2012 14:46:49 +0100 Subject: How to set grid line color in CSS? In-Reply-To: <03230006CA5E1B4D89CCC1DC0BF2209C047254469A@NVS0192.nedap.local> References: <03230006CA5E1B4D89CCC1DC0BF2209C047254469A@NVS0192.nedap.local> Message-ID: From the docs of GridPane: gridLinesVisible For debug purposes only: controls whether lines are displayed to show the gridpane's rows and columns. ? if you want to create something like a table with lines between borders, use a HBox to contain the columns and a VBox for each column, and style the columns using -fx-background-insets and -fx-background-color. Randahl On Dec 17, 2012, at 14:42 , Mark Bulthuis wrote: > Hi, > > It seems simple. Create a GridPane and add css property to define the color of the lines, but...no. > > If you take a look at the source of GridPane, method createGidline, a constant GRID_LINE_COLOR is used: > private static final Color GRID_LINE_COLOR = Color.rgb(30, 30, 30); > > All these methods are private. > > Can someone tell me what to do? > > Greetz, > Mark From tbee at tbee.org Mon Dec 17 06:10:40 2012 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 17 Dec 2012 15:10:40 +0100 Subject: How to set grid line color in CSS? In-Reply-To: References: <03230006CA5E1B4D89CCC1DC0BF2209C047254469A@NVS0192.nedap.local> Message-ID: <50CF27E0.7090805@tbee.org> Ok. But OTOH how hard can it be to assign a CSS class to those lines? I'd go for a Jira issue. Tom On 2012-12-17 14:46, Randahl Fink Isaksen wrote: > From the docs of GridPane: > > gridLinesVisible > For debug purposes only: controls whether lines are displayed to show the gridpane's rows and columns. > > ? if you want to create something like a table with lines between borders, use a HBox to contain the columns and a VBox for each column, and style the columns using -fx-background-insets and -fx-background-color. > > Randahl > > > > On Dec 17, 2012, at 14:42 , Mark Bulthuis wrote: > >> Hi, >> >> It seems simple. Create a GridPane and add css property to define the color of the lines, but...no. >> >> If you take a look at the source of GridPane, method createGidline, a constant GRID_LINE_COLOR is used: >> private static final Color GRID_LINE_COLOR = Color.rgb(30, 30, 30); >> >> All these methods are private. >> >> Can someone tell me what to do? >> >> Greetz, >> Mark From yennick.trevels at gmail.com Mon Dec 17 06:40:43 2012 From: yennick.trevels at gmail.com (Yennick Trevels) Date: Mon, 17 Dec 2012 15:40:43 +0100 Subject: Proposal: Avoiding nested views with a merge tag Message-ID: One of the most common performance problems in RIA frameworks is having a deeply nested component tree. One of the reasons is the use of xml for declaring the layout (fxml in case of JavaFx). The problem with xml is that when you want to group multiple components in a separate fxml for reuse purposes, you have to define a root tag, which in most frameworks will create an extra (potentially unnecessary) node in the displaylist. The way Android has solved this is by using a tag, which doesn't create an extra node in the displayList. A good overview of this tag can be found here: http://android-developers.blogspot.com/2009/03/android-layout-tricks-3-optimize-by.html Imo such a tag is something which can also be very useful for JavaFx since it's also node-based, certainly since performance is key in RIA applications. Is something like this already in development and if not, what are your thoughts about this? Greetz, Yennick From tom.schindl at bestsolution.at Mon Dec 17 06:45:43 2012 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 17 Dec 2012 15:45:43 +0100 Subject: Proposal: Avoiding nested views with a merge tag In-Reply-To: References: Message-ID: <50CF3017.80807@bestsolution.at> Isn't that what is good for? Tom Am 17.12.12 15:40, schrieb Yennick Trevels: > One of the most common performance problems in RIA frameworks is having a > deeply nested component tree. One of the reasons is the use of xml for > declaring the layout (fxml in case of JavaFx). The problem with xml is that > when you want to group multiple components in a separate fxml for reuse > purposes, you have to define a root tag, which in most frameworks will > create an extra (potentially unnecessary) node in the displaylist. > > The way Android has solved this is by using a tag, which doesn't > create an extra node in the displayList. A good overview of this tag can be > found here: > http://android-developers.blogspot.com/2009/03/android-layout-tricks-3-optimize-by.html > > Imo such a tag is something which can also be very useful for JavaFx since > it's also node-based, certainly since performance is key in RIA > applications. > > Is something like this already in development and if not, what are your > thoughts about this? > > > Greetz, > Yennick > -- 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 yennick.trevels at gmail.com Mon Dec 17 07:03:01 2012 From: yennick.trevels at gmail.com (Yennick Trevels) Date: Mon, 17 Dec 2012 16:03:01 +0100 Subject: Proposal: Avoiding nested views with a merge tag In-Reply-To: <50CF3017.80807@bestsolution.at> References: <50CF3017.80807@bestsolution.at> Message-ID: But if I understand this tag correctly it will still create an instance of HBox? So this root tag will still create a container (which will be added as a Node to the displaylist), which may be unnecessary. Is it possible with this tag to not create a node in the displaylist, so that elements defined under the root tag are added to the container in which the fxml view is being used? On Mon, Dec 17, 2012 at 3:45 PM, Tom Schindl wrote: > Isn't that what > > > > > is good for? > > Tom > > Am 17.12.12 15:40, schrieb Yennick Trevels: > > One of the most common performance problems in RIA frameworks is having a > > deeply nested component tree. One of the reasons is the use of xml for > > declaring the layout (fxml in case of JavaFx). The problem with xml is > that > > when you want to group multiple components in a separate fxml for reuse > > purposes, you have to define a root tag, which in most frameworks will > > create an extra (potentially unnecessary) node in the displaylist. > > > > The way Android has solved this is by using a tag, which doesn't > > create an extra node in the displayList. A good overview of this tag can > be > > found here: > > > http://android-developers.blogspot.com/2009/03/android-layout-tricks-3-optimize-by.html > > > > Imo such a tag is something which can also be very useful for JavaFx > since > > it's also node-based, certainly since performance is key in RIA > > applications. > > > > Is something like this already in development and if not, what are your > > thoughts about this? > > > > > > Greetz, > > Yennick > > > > > -- > 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 mark.bulthuis at nedap.com Mon Dec 17 07:23:18 2012 From: mark.bulthuis at nedap.com (Mark Bulthuis) Date: Mon, 17 Dec 2012 16:23:18 +0100 Subject: How to set grid line color in CSS? In-Reply-To: <50CF27E0.7090805@tbee.org> References: <03230006CA5E1B4D89CCC1DC0BF2209C047254469A@NVS0192.nedap.local> <50CF27E0.7090805@tbee.org> Message-ID: <03230006CA5E1B4D89CCC1DC0BF2209C04727641CC@NVS0192.nedap.local> Thanx for the feedback! Ok, it is for debug purpose only. I will find another way to do this. But it would be a nice feature, created an issue for this: http://javafx-jira.kenai.com/browse/RT-27047 please vote ;) Mark -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Tom Eugelink Sent: maandag 17 december 2012 15:11 To: openjfx-dev at openjdk.java.net Subject: Re: How to set grid line color in CSS? Ok. But OTOH how hard can it be to assign a CSS class to those lines? I'd go for a Jira issue. Tom On 2012-12-17 14:46, Randahl Fink Isaksen wrote: > From the docs of GridPane: > > gridLinesVisible > For debug purposes only: controls whether lines are displayed to show the gridpane's rows and columns. > > - if you want to create something like a table with lines between borders, use a HBox to contain the columns and a VBox for each column, and style the columns using -fx-background-insets and -fx-background-color. > > Randahl > > > > On Dec 17, 2012, at 14:42 , Mark Bulthuis wrote: > >> Hi, >> >> It seems simple. Create a GridPane and add css property to define the color of the lines, but...no. >> >> If you take a look at the source of GridPane, method createGidline, a constant GRID_LINE_COLOR is used: >> private static final Color GRID_LINE_COLOR = Color.rgb(30, 30, 30); >> >> All these methods are private. >> >> Can someone tell me what to do? >> >> Greetz, >> Mark From richard.bair at oracle.com Mon Dec 17 07:43:59 2012 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 17 Dec 2012 07:43:59 -0800 Subject: Proposal: Avoiding nested views with a merge tag In-Reply-To: References: <50CF3017.80807@bestsolution.at> Message-ID: In fx there is not a display list, and nodes cannot be repeated in the scene graph, so you have to have the duplicate hbox. ListView is a powerful tool for doing virtualized views, maybe that is what you need? What is the use case? On Dec 17, 2012, at 7:03 AM, Yennick Trevels wrote: > But if I understand this tag correctly it will still create an instance of > HBox? So this root tag will still create a container (which will be added > as a Node to the displaylist), which may be unnecessary. > Is it possible with this tag to not create a node in the displaylist, so > that elements defined under the root tag are added to the container in > which the fxml view is being used? > > > On Mon, Dec 17, 2012 at 3:45 PM, Tom Schindl wrote: > >> Isn't that what >> >> >> >> >> is good for? >> >> Tom >> >> Am 17.12.12 15:40, schrieb Yennick Trevels: >>> One of the most common performance problems in RIA frameworks is having a >>> deeply nested component tree. One of the reasons is the use of xml for >>> declaring the layout (fxml in case of JavaFx). The problem with xml is >> that >>> when you want to group multiple components in a separate fxml for reuse >>> purposes, you have to define a root tag, which in most frameworks will >>> create an extra (potentially unnecessary) node in the displaylist. >>> >>> The way Android has solved this is by using a tag, which doesn't >>> create an extra node in the displayList. A good overview of this tag can >> be >>> found here: >> http://android-developers.blogspot.com/2009/03/android-layout-tricks-3-optimize-by.html >>> >>> Imo such a tag is something which can also be very useful for JavaFx >> since >>> it's also node-based, certainly since performance is key in RIA >>> applications. >>> >>> Is something like this already in development and if not, what are your >>> thoughts about this? >>> >>> >>> Greetz, >>> Yennick >> >> >> -- >> 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 yennick.trevels at gmail.com Mon Dec 17 08:28:39 2012 From: yennick.trevels at gmail.com (Yennick Trevels) Date: Mon, 17 Dec 2012 17:28:39 +0100 Subject: Proposal: Avoiding nested views with a merge tag In-Reply-To: References: <50CF3017.80807@bestsolution.at> Message-ID: ListView isn't what I'm looking for. It's more about a general way to reduce the number of levels in the scene graph (which I called display list). The blog post I mentioned describes quite clearly what I'm aiming it. For example when you have the following: *MyComponent.fxml:*