Re: Look and feel mechanism?
On 9 December 2013 16:10, Scott Palmer swpal...@gmail.com wrote: On Dec 8, 2013, at 9:18 PM, Felix Bembrick felix.bembr...@gmail.com wrote: snip Firstly, it will *never* be possible to completely emulate the native look and feel. Sure it is. Though it may never be practical, for many of the reasons you have given. My reasoning is: why bother? Because it matters. As computer literate developers, we often don't realize what trips other people up. I get so frustrated with apps these days because they have become hard to use simply because the developers tried to define their own look and feel. For example, Chrome and Firefox... Or Microsoft Office... Where did the title bar go in chrome? Where have all the menus gone in Chrome, Firefox andOffice? I can find them, but when I have to play tech support over the phone to my parents these changes are massive problems. I ask my dad to move he window by dragging the title bar (please don't ask why he doesn't know to do this himself after decades of computer use) and he says there is no title bar... I the remember that yes, chrome did that... They got rid of a standard concept in the OS' windowing system and screed the end users. These apps became harder to use because of this innovation in the UI. Contrast this with applications on OS X where getting the UI right has always been an important priority for developers. Because adhering to the system look and feel has always been strongly encouraged the system is much easier to use. These days, many apps do not look 100% native and may have their own controls or look and feel in general. Yes, but to what end? They are now more difficult to use. Why not channel all that massive effort in constructing an emulated native look and feel into simply making JavaFX better overall? But I agree here. The general look isn't the main issue.. E.g. little variations in color and minor tweaks to a few pixels here and there don't really matter. What does matter is when you change the order of buttons, like Okay Cancel which have standard places that are different between Mac and Windows, or you move the About menu item from the Application menu on an OS X app to the help menu! because that is where you find it on Windows. Those things matter. Scott Felix On 9 December 2013 12:35, Pedro Duque Vieira pedro.duquevie...@gmail.comwrote: Thanks! @Jasper: Yes, that's very interesting! Forgot that was possible to do in CSS. On Mon, Dec 9, 2013 at 12:15 AM, Stephen Winnall st...@winnall.ch wrote: It may be possible to change the LOOK with CSS, but not the FEEL, which is where Java apps have traditionally failed big time. Some things that I don’t think can be changed with CSS: 1) texts 2) order of buttons 3) escape characters for shortcuts 4) menus 5) system-level stuff (double-clicking on files, dropping files on applications, …) 6) filesystem conventions 7) ... I think FXML can fix some of these, but not all. So it seems to me that a LaF in JFX will consist of at least: - one or more CSS files - one or more FXML files - some plumbing at the system level It would be nice to have a set of proper LaFs for each major platform with an appropriate common API. Steve On 9 Dec 2013, at 00:20, Jasper Potts jasper.po...@oracle.com wrote: You can set skin classes from CSS so should be able to do everything you could with Swing and more. With just a CSS file and skins as and when needed. Jasper On Dec 8, 2013, at 3:00 PM, Jonathan Giles jonathan.gi...@oracle.com wrote: At present there are no plans to introduce any further API or functionality in this area, but if there is something you are wanting then you should file feature requests in Jira. -- Jonathan On 9/12/2013 11:54 a.m., Pedro Duque Vieira wrote: Hi, Is there any Look and Feel mechanism in place, like the one in Swing? That doesn't appear to exist.. Are there any plans to add one? You can only do so much with CSS... Thanks in advance, best regards, -- Pedro Duque Vieira
To Be Or Not To Be (Native), was:Look and feel mechanism?
Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry and the drive of these fantastic people. Their work will undoubtedly be extremely useful to many developers worldwide. I want to make all that *perfectly clear* because now I am going to explain why I (probably) will not be one of those people and (hopefully) do it with the utmost respect for the aforementioned rock stars :-) Right, so back to the issue of whether to or not to implement or use a native Look and Feel. Some of the following comments have already been made by me on other networks and in other forums so apologies if it seems a bit repetitive to some. At first glance, the idea of a native Look and Feel seems almost like the proverbial Holy Grail. I mean, if such a thing were truly possible and viable, who wouldn't want one? You still have your single codebase across all platforms and you just just plug-in the particular native Look and Feel for your target platform and voila! World domination will surely soon follow! Well, not quite. It's a great idea but I am going out on a limb to claim that it has *never* worked. Ever! And by work I mean so that your not-so-native app looks and feels (which includes all aspects of behaviour, not just appearance) *exactly* like a true native app and *no one* could tell you that it *wasn't* a native app. Yes, I know there are masses now screaming at their monitors who will undoubtedly cite the numerous success stories of Swing apps or maybe even Qt or some other cross-platform UI toolkit and maybe my standards/criteria are harsher than others but I stand by my claim that this has *never ever* really, really, really worked. OK, so why not? Here's my first point: I postulate that such a noble goal is *not actually achievable*. It is not actually achievable for a number of reasons. It is not actually achievable because, in most cases, we do not have access to the code that implements the native controls on each OS so, at best, we are guessing when we try to emulate all aspects of their appearance and behaviour. Try as we may, we will never get *every* control exactly right and I firmly believe that anything that purports to be something else needs to be *identical*. It is not actually achievable because just as you feel you have reached an acceptable level of compliance (which I again wager is never 100%), the goal posts will move. That is, the OS vendor will release an update and even the minor ones can change either the appearance or behaviour of controls, sometimes in subtle ways, sometimes in not so subtle ways. Either way, there is then going to be a period of time where you are playing a futile game of catch-up and during that time your native controls will be surely exposed for the impostors they are. It is not
hg: openjfx/8/graphics/rt: Ensemble8: Fix for RT-34712 Ensemble8: Bouncing Balls View source link doesn't work
Changeset: d0bca0f6ab5a Author:Alexander Kouznetsov Date: 2013-12-09 01:29 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d0bca0f6ab5a Ensemble8: Fix for RT-34712 Ensemble8: Bouncing Balls View source link doesn't work ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/SamplePageContent.java
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
BTW, I was wanting to refer to a comment on this topic made my Pedro DV on Twitter today. Pedro has been doing stunningly good work on a Metro Look and Feel for JavaFX and, when questioned by me, stated that while he may attempt such a Look and Feel for Android, he wouldn't try to do one for iOS for reasons which he did not completely explain. Pedro, do you mind expanding on those thoughts here? When you referred to the numerous issue with iOS were you referring to iOS itself or to trying to emulate iOS with JavaFX? Thanks, Felix On 9 December 2013 20:24, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry and the drive of these fantastic people. Their work will undoubtedly be extremely useful to many developers worldwide. I want to make all that *perfectly clear* because now I am going to explain why I (probably) will not be one of those people and (hopefully) do it with the utmost respect for the aforementioned rock stars :-) Right, so back to the issue of whether to or not to implement or use a native Look and Feel. Some of the following comments have already been made by me on other networks and in other forums so apologies if it seems a bit repetitive to some. At first glance, the idea of a native Look and Feel seems almost like the proverbial Holy Grail. I mean, if such a thing were truly possible and viable, who wouldn't want one? You still have your single codebaseacross all platforms and you just just plug-in the particular native Look and Feel for your target platform and voila! World domination will surely soon follow! Well, not quite. It's a great idea but I am going out on a limb to claim that it has *never* worked. Ever! And by work I mean so that your not-so-native app looks and feels (which includes all aspects of behaviour, not just appearance) *exactly* like a true native app and *no one* could tell you that it *wasn't* a native app. Yes, I know there are masses now screaming at their monitors who will undoubtedly cite the numerous success stories of Swing apps or maybe even Qt or some other cross-platform UI toolkit and maybe my standards/criteria are harsher than others but I stand by my claim that this has *never ever* really, really, really worked. OK, so why not? Here's my first point: I postulate that such a noble goal is *not actually achievable*. It is not actually achievable for a number of reasons. It is not actually achievable because, in most cases, we do not have access to the code that implements the native controls on each OS so, at best, we are guessing when we try to emulate all aspects of their appearance and behaviour. Try as we may, we will never get *every*
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Hi, when talking about mobile LFs like iOS and Android a lot more stuff need to be done. All the mobile UIs have different layout contains and a lot of default animations. When creating a Look and Feel for mobile systems a set of additinal panes / layout containers need to be created. Hendrik Am 09.12.2013 um 10:36 schrieb Felix Bembrick felix.bembr...@gmail.com: BTW, I was wanting to refer to a comment on this topic made my Pedro DV on Twitter today. Pedro has been doing stunningly good work on a Metro Look and Feel for JavaFX and, when questioned by me, stated that while he may attempt such a Look and Feel for Android, he wouldn't try to do one for iOS for reasons which he did not completely explain. Pedro, do you mind expanding on those thoughts here? When you referred to the numerous issue with iOS were you referring to iOS itself or to trying to emulate iOS with JavaFX? Thanks, Felix On 9 December 2013 20:24, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry and the drive of these fantastic people. Their work will undoubtedly be extremely useful to many developers worldwide. I want to make all that *perfectly clear* because now I am going to explain why I (probably) will not be one of those people and (hopefully) do it with the utmost respect for the aforementioned rock stars :-) Right, so back to the issue of whether to or not to implement or use a native Look and Feel. Some of the following comments have already been made by me on other networks and in other forums so apologies if it seems a bit repetitive to some. At first glance, the idea of a native Look and Feel seems almost like the proverbial Holy Grail. I mean, if such a thing were truly possible and viable, who wouldn't want one? You still have your single codebaseacross all platforms and you just just plug-in the particular native Look and Feel for your target platform and voila! World domination will surely soon follow! Well, not quite. It's a great idea but I am going out on a limb to claim that it has *never* worked. Ever! And by work I mean so that your not-so-native app looks and feels (which includes all aspects of behaviour, not just appearance) *exactly* like a true native app and *no one* could tell you that it *wasn't* a native app. Yes, I know there are masses now screaming at their monitors who will undoubtedly cite the numerous success stories of Swing apps or maybe even Qt or some other cross-platform UI toolkit and maybe my standards/criteria are harsher than others but I stand by my claim that this has *never ever* really, really, really worked. OK, so why not? Here's my first
Re: Look and feel mechanism?
By the way, platform order of dialog buttons is implemented by the ButtonBar control in ControlsFX. It is of course Java8 only but can easily be brought back to FX2. Werner On 09.12.2013 10:45, Hendrik Ebbers wrote: Next to the skinning of controls additional features are needed. One example that was already mentioned is the order of cancel and ok buttons. Actually there is no support in JavaFX. If basic dialogs would support this features a definition of the order etc. is needed. This can be done by using a plugin for the LF API, too.
Re: Look and feel mechanism?
All I know, as a 3rd party control developer, is that I want to be able to setup the CSS of my controls in such a way that as much of a new skin is automatically adopted; borders, colors, focus rendering, etc. Tom
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
That's correct Hendrik and this only adds weight to my argument. Clearly the mobile platforms (Android and especially iOS) are even harder-to-hit targets than desktop platforms. And if you are not able to develop a viable native Look and Feel for every platform then the paradigm of deploying your app using a native Look and Feel to *every* device breaks down... On 9 December 2013 20:57, Hendrik Ebbers hendrik.ebb...@me.com wrote: Hi, when talking about mobile LFs like iOS and Android a lot more stuff need to be done. All the mobile UIs have different layout contains and a lot of default animations. When creating a Look and Feel for mobile systems a set of additinal panes / layout containers need to be created. Hendrik Am 09.12.2013 um 10:36 schrieb Felix Bembrick felix.bembr...@gmail.com : BTW, I was wanting to refer to a comment on this topic made my Pedro DV on Twitter today. Pedro has been doing stunningly good work on a Metro Look and Feel for JavaFX and, when questioned by me, stated that while he may attempt such a Look and Feel for Android, he wouldn't try to do one for iOS for reasons which he did not completely explain. Pedro, do you mind expanding on those thoughts here? When you referred to the numerous issue with iOS were you referring to iOS itself or to trying to emulate iOS with JavaFX? Thanks, Felix On 9 December 2013 20:24, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry and the drive of these fantastic people. Their work will undoubtedly be extremely useful to many developers worldwide. I want to make all that *perfectly clear* because now I am going to explain why I (probably) will not be one of those people and (hopefully) do it with the utmost respect for the aforementioned rock stars :-) Right, so back to the issue of whether to or not to implement or use a native Look and Feel. Some of the following comments have already been made by me on other networks and in other forums so apologies if it seems a bit repetitive to some. At first glance, the idea of a native Look and Feel seems almost like the proverbial Holy Grail. I mean, if such a thing were truly possible and viable, who wouldn't want one? You still have your single codebaseacross all platforms and you just just plug-in the particular native Look and Feel for your target platform and voila! World domination will surely soon follow! Well, not quite. It's a great idea but I am going out on a limb to claim that it has *never* worked. Ever! And by work I mean so that your not-so-native app looks and feels (which
Re: Look and feel mechanism?
On 9 Dec 2013, at 03:18, Felix Bembrick felix.bembr...@gmail.com wrote: @Stephen, you are absolutely right about this. But such an approach (and pretty much *any* approach) to emulated native look and feels is fraught with difficulties and complexities. Firstly, it will *never* be possible to completely emulate the native look and feel. And, even if the differences are subtle, there is the very real risk that the end user will have a very uneasy feeling using such a look and feel. At times it will even seem like an imposter. Agreed, though Quaqua did quite a good (and unobtrusive) job for the look on Swing on Mac OS X. Secondly, you will be forever playing catchup as each new major release (and also even each minor update) changes one or more of the behaviours that you have so carefully emulated. The result is that for a while at least, your emulated look and feel is an even more obvious imposter with an even more uneasy experience for the user. Indeed. I’m not really a fan of reimplementing something that’s already there anyway. It should be possible to use the native facilities via appropriate APIs. Thirdly, building such emulated look and feels is a *lot* of work (much more than you would think). Tell me about it :-) I spent a long time trying to create a Platform abstraction for Swing which would allow applications to be moved from platform to platform and adopt the native look and feel. The along came JavaFX. But we missed out on the chance of developing a platform abstraction there too. My reasoning is: why bother? Why not build a JavaFX look and feel (akin to something like Nimubs in Swing) that simply doesn't even try to look native? Then you know for sure your app looks and behaves identically on all devices and there is no hint of imposter-ness”. The answer to this question is relatively simple: Metal. Metal, you will recall, was the one-size-fits-all look for Swing. And it was expletive deleted and was a major reason for the failure of Swing (and thus Java) on the desktop. Ultimately, all cross-platform looks suffer from the same problem: they don’t look right on any platform and often terrible on others. And ignoring the feel of the target platform is the ultimate sin: users don’t understand what the app is doing or why but often cannot articulate their feelings because there’s no *observable* problem, only a “feelable one. And so another Java desktop app dies the death... These days, many apps do not look 100% native and may have their own controls or look and feel in general. Why not channel all that massive effort in constructing an emulated native look and feel into simply making JavaFX better overall? Agreed. Let’s define a platform abstraction… Steve
Review Request: RT-34770 [TextArea MacOS] selected text is removed on focus leaving then returning
Hello, OpenJFX. Please review the fix for the issue: https://javafx-jira.kenai.com/browse/RT-34770 The details are in the bug comments. With best regards. Petr.
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry and the drive of these fantastic people. Their work will undoubtedly be extremely useful to many developers worldwide. I want to make all that *perfectly clear* because now I am going to explain why I (probably) will not be one of those people and (hopefully) do it with the utmost respect for the aforementioned rock stars :-) Right, so back to the issue of whether to or not to implement or use a native Look and Feel. Some of the following comments have already been made by me on other networks and in other forums so apologies if it seems a bit repetitive to some. At first glance, the idea of a native Look and Feel seems almost like the proverbial Holy Grail. I mean, if such a thing were truly possible and viable, who wouldn't want one? You still have your single codebase across all platforms and you just just plug-in the particular native Look and Feel for your target platform and voila! World domination will surely soon follow! Well, not quite. It's a great idea but I am going out on a limb to claim that it has *never* worked. Ever! And by work I mean so that your not-so-native app looks and feels (which includes all aspects of behaviour, not just appearance) *exactly* like a true native app and *no one* could tell you that it *wasn't* a native app. Yes, I know there are masses now screaming at their monitors who will undoubtedly cite the numerous success stories of Swing apps or maybe even Qt or some other cross-platform UI toolkit and maybe my standards/criteria are harsher than others but I stand by my claim that this has
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry and the drive of these fantastic people. Their work will undoubtedly be extremely useful to many developers worldwide. I want to make all that *perfectly clear* because now I am going to explain why I (probably) will not be one of those people and (hopefully) do it with the utmost respect for the aforementioned rock stars :-) Right, so back to the issue of whether to or not to implement or use a native Look and Feel. Some of the following comments have already been made by me on other networks and in other forums so apologies if it seems a bit repetitive to some. At first glance, the idea of a native Look and Feel seems almost like the proverbial Holy Grail. I mean, if such a thing were truly possible and viable, who wouldn't want one? You still have your single codebase across all platforms and you just just plug-in the particular native Look and Feel for your target platform and voila! World domination will surely soon follow! Well, not quite. It's a great idea but I am going out on a limb to claim that it has *never* worked. Ever! And by work I mean so that your not-so-native app looks
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry and the drive of these fantastic people. Their work will undoubtedly be extremely useful to many developers worldwide. I want to make all that *perfectly clear* because now I am going to explain why I (probably) will not be one of those people and (hopefully) do it with the utmost respect for the aforementioned rock stars :-) Right,
Re: Look and feel mechanism?
Agreed that Quaqua did a great job and lets not lose sight of the fact that I am totally praising the efforts of everyone who has worked in this frustrating and tedious area of UI development/support. I just think the obvious talents of those people could be utilised for a purpose less likely to drive them crazy! Yes, Metal was an unabridged disaster but did you ever see Substance? I thought that looked great on all platforms. And today there is also Cezanne which isn't too shabby. What's really needed is, as you say, some kind of platform abstraction that handles all the OS specific details and then you code to use it. Ideally this abstraction would result in the use of actual native widgets but how you would apply all the features that come with Node to those widgets I have no idea... On 9 Dec 2013, at 22:49, Stephen Winnall st...@winnall.ch wrote: On 9 Dec 2013, at 03:18, Felix Bembrick felix.bembr...@gmail.com wrote: @Stephen, you are absolutely right about this. But such an approach (and pretty much *any* approach) to emulated native look and feels is fraught with difficulties and complexities. Firstly, it will *never* be possible to completely emulate the native look and feel. And, even if the differences are subtle, there is the very real risk that the end user will have a very uneasy feeling using such a look and feel. At times it will even seem like an imposter. Agreed, though Quaqua did quite a good (and unobtrusive) job for the look on Swing on Mac OS X. Secondly, you will be forever playing catchup as each new major release (and also even each minor update) changes one or more of the behaviours that you have so carefully emulated. The result is that for a while at least, your emulated look and feel is an even more obvious imposter with an even more uneasy experience for the user. Indeed. I’m not really a fan of reimplementing something that’s already there anyway. It should be possible to use the native facilities via appropriate APIs. Thirdly, building such emulated look and feels is a *lot* of work (much more than you would think). Tell me about it :-) I spent a long time trying to create a Platform abstraction for Swing which would allow applications to be moved from platform to platform and adopt the native look and feel. The along came JavaFX. But we missed out on the chance of developing a platform abstraction there too. My reasoning is: why bother? Why not build a JavaFX look and feel (akin to something like Nimubs in Swing) that simply doesn't even try to look native? Then you know for sure your app looks and behaves identically on all devices and there is no hint of imposter-ness”. The answer to this question is relatively simple: Metal. Metal, you will recall, was the one-size-fits-all look for Swing. And it was expletive deleted and was a major reason for the failure of Swing (and thus Java) on the desktop. Ultimately, all cross-platform looks suffer from the same problem: they don’t look right on any platform and often terrible on others. And ignoring the feel of the target platform is the ultimate sin: users don’t understand what the app is doing or why but often cannot articulate their feelings because there’s no *observable* problem, only a “feelable one. And so another Java desktop app dies the death... These days, many apps do not look 100% native and may have their own controls or look and feel in general. Why not channel all that massive effort in constructing an emulated native look and feel into simply making JavaFX better overall? Agreed. Let’s define a platform abstraction… Steve
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
There are a few critical elements that must conform to platform-specific look and feel: - app installer - management of app icons - system dialogs: file open, save and save, print - os x system menu bar Apart from these elements, native look and feel should be optional. On Mon, Dec 9, 2013 at 12:31 PM, Felix Bembrick felix.bembr...@gmail.com wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
I would go further by saying that those things you have mentioned should be truly native, not just native look and feel. Consider the Swing file chooser using Windows look and feel for example. That just never worked or looked right. On 10 Dec 2013, at 4:47, Rick Walker thoughtslin...@gmail.com wrote: There are a few critical elements that must conform to platform-specific look and feel: - app installer - management of app icons - system dialogs: file open, save and save, print - os x system menu bar Apart from these elements, native look and feel should be optional. On Mon, Dec 9, 2013 at 12:31 PM, Felix Bembrick felix.bembr...@gmail.com wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry and the drive of these fantastic people. Their work will undoubtedly be extremely useful to many developers worldwide. I want to make all that *perfectly clear* because now I am going to explain why I (probably) will not be
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
What can we expect from the JavaFX team in this regard in the future? I know we have talked about mixing lightweight and heavyweight controls in the same context but is it going to happen? Is this planned for JFX9 perhaps? Is it *really* even feasible? On 10 Dec 2013, at 4:55, Stephen F Northover steve.x.northo...@oracle.com wrote: Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Doesn’t this also imply that you are using AWT/Swing? JavaFX has no way to be hosted in anything other than a JFXPanel or a JavaFX Stage. Only the JFXPanel can be hosted in a windows that allows heavy weight (native) controls, or even allows JNI code to get the window handle so you can integrate your JavaFX with other native bits. Scott On Dec 9, 2013, at 12:55 PM, Stephen F Northover steve.x.northo...@oracle.com wrote: Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve
Re: Look and feel mechanism?
Just to take a completely different tack: I have a sneaking suspicion that the whole approach to UI design is wrong. Aside from the platform abstraction thing, I wonder whether we shouldn’t be approaching UIs from a design pattern perspective. The application programmer is the wrong person to decide whether to implement a pop-up menu, a combobox or a selection list: all the programmer needs to specify is “get me one or more elements from this list”, and someone who loves the target platform (even Windows ;-) ) should instantiate the appropriate widget for that platform. JavaFX gives us the capability to do this. I think we tend to think of ourselves as clones of Leonardo da Vinci, capable of programming and design, when the truth is somewhat different, the more so when we’re implementing stuff for platforms we secretly despise… But now I’m ranting, sorry. To get back to cross-platform looks. People are used to them because of WWW and browser interfaces. But the desktop has no competitive advantage over the browser idiom if it doesn’t do the user experience better. It’s a question of quality as opposed to 80:20 in my view. It’s look AND feel. Steve On 9 Dec 2013, at 18:42, Felix Bembrick felix.bembr...@gmail.com wrote: Agreed that Quaqua did a great job and lets not lose sight of the fact that I am totally praising the efforts of everyone who has worked in this frustrating and tedious area of UI development/support. I just think the obvious talents of those people could be utilised for a purpose less likely to drive them crazy! Yes, Metal was an unabridged disaster but did you ever see Substance? I thought that looked great on all platforms. And today there is also Cezanne which isn't too shabby. What's really needed is, as you say, some kind of platform abstraction that handles all the OS specific details and then you code to use it. Ideally this abstraction would result in the use of actual native widgets but how you would apply all the features that come with Node to those widgets I have no idea... On 9 Dec 2013, at 22:49, Stephen Winnall st...@winnall.ch wrote: On 9 Dec 2013, at 03:18, Felix Bembrick felix.bembr...@gmail.com wrote: @Stephen, you are absolutely right about this. But such an approach (and pretty much *any* approach) to emulated native look and feels is fraught with difficulties and complexities. Firstly, it will *never* be possible to completely emulate the native look and feel. And, even if the differences are subtle, there is the very real risk that the end user will have a very uneasy feeling using such a look and feel. At times it will even seem like an imposter. Agreed, though Quaqua did quite a good (and unobtrusive) job for the look on Swing on Mac OS X. Secondly, you will be forever playing catchup as each new major release (and also even each minor update) changes one or more of the behaviours that you have so carefully emulated. The result is that for a while at least, your emulated look and feel is an even more obvious imposter with an even more uneasy experience for the user. Indeed. I’m not really a fan of reimplementing something that’s already there anyway. It should be possible to use the native facilities via appropriate APIs. Thirdly, building such emulated look and feels is a *lot* of work (much more than you would think). Tell me about it :-) I spent a long time trying to create a Platform abstraction for Swing which would allow applications to be moved from platform to platform and adopt the native look and feel. The along came JavaFX. But we missed out on the chance of developing a platform abstraction there too. My reasoning is: why bother? Why not build a JavaFX look and feel (akin to something like Nimubs in Swing) that simply doesn't even try to look native? Then you know for sure your app looks and behaves identically on all devices and there is no hint of imposter-ness”. The answer to this question is relatively simple: Metal. Metal, you will recall, was the one-size-fits-all look for Swing. And it was expletive deleted and was a major reason for the failure of Swing (and thus Java) on the desktop. Ultimately, all cross-platform looks suffer from the same problem: they don’t look right on any platform and often terrible on others. And ignoring the feel of the target platform is the ultimate sin: users don’t understand what the app is doing or why but often cannot articulate their feelings because there’s no *observable* problem, only a “feelable one. And so another Java desktop app dies the death... These days, many apps do not look 100% native and may have their own controls or look and feel in general. Why not channel all that massive effort in constructing an emulated native look and feel into simply making JavaFX better overall? Agreed. Let’s define a platform abstraction… Steve
hg: openjfx/8/graphics/rt: Ensemble8: Fix for RT-34710 Ensemble8: Gesture Events sample name and description is confusing
Changeset: d337fbc19887 Author:Alexander Kouznetsov Date: 2013-12-09 12:37 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d337fbc19887 Ensemble8: Fix for RT-34710 Ensemble8: Gesture Events sample name and description is confusing ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/scenegraph/events/gestureevent/GestureEventApp.java
Re: Look and feel mechanism?
I see the point of he higher-level abstraction, but I think we need more control over the user experience than that for most cases. If not simply for aesthetics, there are times when I know I want a combobox vs. a spinner vs. a list with a single selection model. What we need are more of what we already have with things like: MenuBar.useSystemMenuBarProperty() or in Swing, MouseEvent.isPopupTrigger() Consider for example the standard shortcut for Undo. CTRL-Z on Windows, Command-Z o Mac. That’s easy, Mac uses Command where Windows uses CTRL. But what about Redo? CTRL-Y on Windows, Command-Shift-Z on Mac. Developers have to know these things and code for them explicitly. Where is the abstraction in the Java APIs? Scott On Dec 9, 2013, at 3:03 PM, Felix Bembrick felix.bembr...@gmail.com wrote: I am with you on the design pattern approach you refer to which is basically a higher level of abstraction than say one which actually specifies which widget types to use. But who is this someone who loves the target platform and how and when do they get to hook-in the actual widgets? While I agree JavaFX certainly has the ability to implement the high-level abstraction layer (as does pretty much any programming language, how (physically speaking) is someone going to link this with an actual selection of widgets on each OS? Isn't *that* the whole problem here? Felix On 10 December 2013 06:50, Stephen Winnall st...@winnall.ch wrote: Just to take a completely different tack: I have a sneaking suspicion that the whole approach to UI design is wrong. Aside from the platform abstraction thing, I wonder whether we shouldn’t be approaching UIs from a design pattern perspective. The application programmer is the wrong person to decide whether to implement a pop-up menu, a combobox or a selection list: all the programmer needs to specify is “get me one or more elements from this list”, and someone who loves the target platform (even Windows ;-) ) should instantiate the appropriate widget for that platform. JavaFX gives us the capability to do this. I think we tend to think of ourselves as clones of Leonardo da Vinci, capable of programming and design, when the truth is somewhat different, the more so when we’re implementing stuff for platforms we secretly despise… But now I’m ranting, sorry. To get back to cross-platform looks. People are used to them because of WWW and browser interfaces. But the desktop has no competitive advantage over the browser idiom if it doesn’t do the user experience better. It’s a question of quality as opposed to 80:20 in my view. It’s look AND feel. Steve On 9 Dec 2013, at 18:42, Felix Bembrick felix.bembr...@gmail.com wrote: Agreed that Quaqua did a great job and lets not lose sight of the fact that I am totally praising the efforts of everyone who has worked in this frustrating and tedious area of UI development/support. I just think the obvious talents of those people could be utilised for a purpose less likely to drive them crazy! Yes, Metal was an unabridged disaster but did you ever see Substance? I thought that looked great on all platforms. And today there is also Cezanne which isn't too shabby. What's really needed is, as you say, some kind of platform abstraction that handles all the OS specific details and then you code to use it. Ideally this abstraction would result in the use of actual native widgets but how you would apply all the features that come with Node to those widgets I have no idea... On 9 Dec 2013, at 22:49, Stephen Winnall st...@winnall.ch wrote: On 9 Dec 2013, at 03:18, Felix Bembrick felix.bembr...@gmail.com wrote: @Stephen, you are absolutely right about this. But such an approach (and pretty much *any* approach) to emulated native look and feels is fraught with difficulties and complexities. Firstly, it will *never* be possible to completely emulate the native look and feel. And, even if the differences are subtle, there is the very real risk that the end user will have a very uneasy feeling using such a look and feel. At times it will even seem like an imposter. Agreed, though Quaqua did quite a good (and unobtrusive) job for the look on Swing on Mac OS X. Secondly, you will be forever playing catchup as each new major release (and also even each minor update) changes one or more of the behaviours that you have so carefully emulated. The result is that for a while at least, your emulated look and feel is an even more obvious imposter with an even more uneasy experience for the user. Indeed. I’m not really a fan of reimplementing something that’s already there anyway. It should be possible to use the native facilities via appropriate APIs. Thirdly, building such emulated look and feels is a *lot* of work (much more than you would think). Tell me about it :-) I spent a long time trying to create a Platform abstraction for
Re: Look and feel mechanism?
I am with you on the design pattern approach you refer to which is basically a higher level of abstraction than say one which actually specifies which widget types to use. But who is this someone who loves the target platform and how and when do they get to hook-in the actual widgets? While I agree JavaFX certainly has the ability to implement the high-level abstraction layer (as does pretty much any programming language, how (physically speaking) is someone going to link this with an actual selection of widgets on each OS? Isn't *that* the whole problem here? That’s JavaFX, CSS and FXML, with the native platform shining though thanks to the platform API. Steve
hg: openjfx/8/graphics/rt: Ensemble8: Fix for RT-34713 Ensemble8: TreeTableView sample is bad in editing: edited values disappear
Changeset: 3bdcd01853bf Author:Alexander Kouznetsov Date: 2013-12-09 12:52 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3bdcd01853bf Ensemble8: Fix for RT-34713 Ensemble8: TreeTableView sample is bad in editing: edited values disappear + apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/treetableview/Data.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/treetableview/Inventory.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/treetableview/Part.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/treetableview/TreeTableViewApp.java
Re: Look and feel mechanism?
@Felix: Thank you for the kind words (although I don't consider myself a rock star :-) ). As you mentioned I said I didn't want to make a iOS 7 native look and feel, I said it because I consider it broken as well as many other influential designers do. Broken in the sense that it has various wrong design decisions. As for the discussion of native look and feels, I think a cross platform look and feel that goes for the least common denominator and doesn't violate any of the platforms look and feel guidelines is the best way to go. As was already said having a native look and feel for each platform is a ton of work, even if the framework does provide one (as Felix said, most often is not even 80% identical) you still have to adapt the application for each platform if you go this way. The real problem is the feel part, each platform has a different standard set of controls, consider for example windows 8 which for desktop app almost always substitutes menus for a ribbon. If you go this way you better, as was already said, go with the platforms set of tools to create apps, instead of using java/javafx. Modena is an excellent cross platform look and feel that looks great, something we never had in swing, at least not out of the box in the framework. And I think this is the best way to go. As for mobile, I think the same should be done: create a cross platform look and feel. When developers choose java for this it often is because they lake the necessary resources to build a native app for each system. A good cross platform look and feel will speed up development and time of delivery. I don't think you have to go native to have a great designed app, there are various examples on mobile of great apps that don't use the standard looking platform controls. There are even apps that go as far as use almost only gestures with almost no controls. Checkout Clear, a critically acclaimed app for its design, that almost doesn't use controls: http://realmacsoftware.com/clear/ or Paper also an app that is recognized by many as having an excellent design that also doesn't use standard native controls: http://www.fiftythree.com/ On Mon, Dec 9, 2013 at 8:03 PM, Felix Bembrick felix.bembr...@gmail.comwrote: I am with you on the design pattern approach you refer to which is basically a higher level of abstraction than say one which actually specifies which widget types to use. But who is this someone who loves the target platform and how and when do they get to hook-in the actual widgets? While I agree JavaFX certainly has the ability to implement the high-level abstraction layer (as does pretty much any programming language, how (physically speaking) is someone going to link this with an actual selection of widgets on each OS? Isn't *that* the whole problem here? Felix On 10 December 2013 06:50, Stephen Winnall st...@winnall.ch wrote: Just to take a completely different tack: I have a sneaking suspicion that the whole approach to UI design is wrong. Aside from the platform abstraction thing, I wonder whether we shouldn’t be approaching UIs from a design pattern perspective. The application programmer is the wrong person to decide whether to implement a pop-up menu, a combobox or a selection list: all the programmer needs to specify is “get me one or more elements from this list”, and someone who loves the target platform (even Windows ;-) ) should instantiate the appropriate widget for that platform. JavaFX gives us the capability to do this. I think we tend to think of ourselves as clones of Leonardo da Vinci, capable of programming and design, when the truth is somewhat different, the more so when we’re implementing stuff for platforms we secretly despise… But now I’m ranting, sorry. To get back to cross-platform looks. People are used to them because of WWW and browser interfaces. But the desktop has no competitive advantage over the browser idiom if it doesn’t do the user experience better. It’s a question of quality as opposed to 80:20 in my view. It’s look AND feel. Steve On 9 Dec 2013, at 18:42, Felix Bembrick felix.bembr...@gmail.com wrote: Agreed that Quaqua did a great job and lets not lose sight of the fact that I am totally praising the efforts of everyone who has worked in this frustrating and tedious area of UI development/support. I just think the obvious talents of those people could be utilised for a purpose less likely to drive them crazy! Yes, Metal was an unabridged disaster but did you ever see Substance? I thought that looked great on all platforms. And today there is also Cezanne which isn't too shabby. What's really needed is, as you say, some kind of platform abstraction that handles all the OS specific details and then you code to use it. Ideally this abstraction would result in the use of actual native widgets but how you would apply all the features that come with Node to those widgets I have no idea... On 9 Dec 2013, at 22:49,
Re: Look and feel mechanism?
Scott, I think the take-away here is that there simply aren't the features out of the box in JavaFX/Java (even with CSS, skins, FXML) to implement the best platform/UI abstraction and, given the various and vastly differing opinions of how this layer should work or look, I doubt that any official solution will ever be provided by Oracle. I guess that we all need to do what works for ourselves in this area which is admittedly unfortunate and undesirable... On 10 December 2013 07:49, Scott Palmer swpal...@gmail.com wrote: I see the point of he higher-level abstraction, but I think we need more control over the user experience than that for most cases. If not simply for aesthetics, there are times when I know I want a combobox vs. a spinner vs. a list with a single selection model. What we need are more of what we already have with things like: MenuBar.useSystemMenuBarProperty() or in Swing, MouseEvent.isPopupTrigger() Consider for example the standard shortcut for Undo. CTRL-Z on Windows, Command-Z o Mac. That’s easy, Mac uses Command where Windows uses CTRL. But what about Redo? CTRL-Y on Windows, Command-Shift-Z on Mac. Developers have to know these things and code for them explicitly. Where is the abstraction in the Java APIs? Scott On Dec 9, 2013, at 3:03 PM, Felix Bembrick felix.bembr...@gmail.com wrote: I am with you on the design pattern approach you refer to which is basically a higher level of abstraction than say one which actually specifies which widget types to use. But who is this someone who loves the target platform and how and when do they get to hook-in the actual widgets? While I agree JavaFX certainly has the ability to implement the high-level abstraction layer (as does pretty much any programming language, how (physically speaking) is someone going to link this with an actual selection of widgets on each OS? Isn't *that* the whole problem here? Felix On 10 December 2013 06:50, Stephen Winnall st...@winnall.ch wrote: Just to take a completely different tack: I have a sneaking suspicion that the whole approach to UI design is wrong. Aside from the platform abstraction thing, I wonder whether we shouldn’t be approaching UIs from a design pattern perspective. The application programmer is the wrong person to decide whether to implement a pop-up menu, a combobox or a selection list: all the programmer needs to specify is “get me one or more elements from this list”, and someone who loves the target platform (even Windows ;-) ) should instantiate the appropriate widget for that platform. JavaFX gives us the capability to do this. I think we tend to think of ourselves as clones of Leonardo da Vinci, capable of programming and design, when the truth is somewhat different, the more so when we’re implementing stuff for platforms we secretly despise… But now I’m ranting, sorry. To get back to cross-platform looks. People are used to them because of WWW and browser interfaces. But the desktop has no competitive advantage over the browser idiom if it doesn’t do the user experience better. It’s a question of quality as opposed to 80:20 in my view. It’s look AND feel. Steve On 9 Dec 2013, at 18:42, Felix Bembrick felix.bembr...@gmail.com wrote: Agreed that Quaqua did a great job and lets not lose sight of the fact that I am totally praising the efforts of everyone who has worked in this frustrating and tedious area of UI development/support. I just think the obvious talents of those people could be utilised for a purpose less likely to drive them crazy! Yes, Metal was an unabridged disaster but did you ever see Substance? I thought that looked great on all platforms. And today there is also Cezanne which isn't too shabby. What's really needed is, as you say, some kind of platform abstraction that handles all the OS specific details and then you code to use it. Ideally this abstraction would result in the use of actual native widgets but how you would apply all the features that come with Node to those widgets I have no idea... On 9 Dec 2013, at 22:49, Stephen Winnall st...@winnall.ch wrote: On 9 Dec 2013, at 03:18, Felix Bembrick felix.bembr...@gmail.com wrote: @Stephen, you are absolutely right about this. But such an approach (and pretty much *any* approach) to emulated native look and feels is fraught with difficulties and complexities. Firstly, it will *never* be possible to completely emulate the native look and feel. And, even if the differences are subtle, there is the very real risk that the end user will have a very uneasy feeling using such a look and feel. At times it will even seem like an imposter. Agreed, though Quaqua did quite a good (and unobtrusive) job for the look on Swing on Mac OS X. Secondly, you will be forever playing catchup as each new major release (and also even
hg: openjfx/8/graphics/rt: Ensemble8: Fix for RT-34769 Ensemble8: TableCellFactoryApp sample needs cleanup
Changeset: a5d957304de7 Author:Alexander Kouznetsov Date: 2013-12-09 13:18 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a5d957304de7 Ensemble8: Fix for RT-34769 Ensemble8: TableCellFactoryApp sample needs cleanup ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/Person.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/table/tablecellfactory/TableCellFactoryApp.java
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: 2883ec7be017 Author:Alexander Kouznetsov Date: 2013-12-09 13:36 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2883ec7be017 Ensemble8: Fix for RT-34448 HTML Editor in Ensemble8 is not completely visible ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/web/htmleditor/HTMLEditorApp.java Changeset: 98ffb00297f5 Author:Alexander Kouznetsov Date: 2013-12-09 13:45 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/98ffb00297f5 Ensemble8: Fix for RT-30482 Ensemble8: no format checking for X and Y values in charts ! apps/samples/Ensemble8/src/app/java/ensemble/samplepage/XYDataVisualizer.java
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: 53cb68c02d07 Author:John Yoon john.y...@oracle.com Date: 2013-12-09 12:38 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/53cb68c02d07 [Samples Only][RT-33754] Ensemble Icons ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/animation/timeline/timeline/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/animation/timeline/timeline/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/animation/timeline/timelineevents/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/animation/timeline/timelineevents/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/animation/transitions/pathtransition/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/animation/transitions/pathtransition/prev...@2x.png Changeset: a7f21c31ef3e Author:Alexander Kouznetsov Date: 2013-12-09 13:16 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a7f21c31ef3e Ensemble8: Fix for RT-34785 Ensemble8: Multi-touch sample is not found using Search ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/scenegraph/events/multitouch/MultiTouchApp.java
hg: openjfx/8/graphics/rt: [Samples Only][RT-33754] Ensemble Icons
Changeset: bee5e52e68ae Author:John Yoon john.y...@oracle.com Date: 2013-12-09 14:28 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bee5e52e68ae [Samples Only][RT-33754] Ensemble Icons ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/canvas/fireworks/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/canvas/fireworks/prev...@2x.png
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: 57153bcef81f Author:kcr Date: 2013-12-09 15:15 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/57153bcef81f RT-34389: [doc] cssref.html copyright is incorrect Contributed-by: Tom Schindl ! apps/samples/Ensemble8/build.xml ! apps/samples/Ensemble8/nbproject/project.properties Changeset: c7d6f188d1d3 Author:kcr Date: 2013-12-09 15:17 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c7d6f188d1d3 RT-19968: Document that Platform.runLater must not be called before FX is initialized ! modules/graphics/src/main/java/javafx/application/Platform.java
8 post-commit review request: RT-19968: Document that Platform.runLater must not be called before FX is initialized
Please review the following javadoc change (post-commit). https://javafx-jira.kenai.com/browse/RT-19968 -- Kevin
Re: Look and feel mechanism?
This is my preferred approach. There is no need for the vast bulk of the work to be initiated within OpenJFX, and a third party project for touch / mobile devices, much like there are for JavaFX on the desktop, is the natural starting place to explore ideas. If I had unlimited time and resources, I would start up a ControlsFX project for Android / iOS, but I just don't think I have the bandwidth to do that along with everything else. Maybe that might change in the future, but I encourage those with more time to consider a project (or projects) of this nature. -- Jonathan On 10/12/2013 12:49 p.m., Scott Palmer wrote: Well there is the option of doing some sort of application support library in an external project first. Much like the ControlsFX stuff. If it works out, some aspects can be pulled into the JavaFX runtime at a later date. Scott
RE: 8 post-commit review request: RT-19968: Document that Platform.runLater must not be called before FX is initialized
The comments around application runtime initialization seem like they belong
more properly in the application lifecycle javadoc for the Application class
rather than on the Platform.runLater method specifically, though I do see how
the runtime initialization cuts across multiple classes
(Application/JFXPanel/FXCanvas, etc), so perhaps it is OK having the
description where it is (lacking some better place to put it). Useful
information though, thanks for including it.
+ *For standard JavaFX applications that extend
+ * {@see Application}, and use either the Java launcher or one of the
+ * launch methods in the Application class to launch the application,
+ * the FX runtime is initialized by the launcher before the Application
+ * class is loaded.
+ * For Swing applications that use JFXPanel to display FX content, the FX
+ * runtime is initialized when the first JFXPanel instance is constructed.
+ * For SWT application that use FXCanvas to display FX content, the FX
+ * runtime is initialized when the first FXCanvas instance is constructed.
-Original Message-
From: openjfx-dev-boun...@openjdk.java.net
[mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Kevin Rushforth
Sent: Monday, December 09, 2013 3:43 PM
To: Anthony Petrov
Cc: openjfx-dev@openjdk.java.net
Subject: 8 post-commit review request: RT-19968: Document that
Platform.runLater must not be called before FX is initialized
Please review the following javadoc change (post-commit).
https://javafx-jira.kenai.com/browse/RT-19968
-- Kevin
Re: 8 post-commit review request: RT-19968: Document that Platform.runLater must not be called before FX is initialized
(note that review comments should go into the JIRA)
Hi John,
You raise a good point about possibly moving the runtime initialization
section. Perhaps it's worth a follow-up JIRA for FX 8u20 or 9 to address
this. One possibility is to have most of the documentation in the
Application class, and then refer to it from Platform, JFXPanel, and
FXCanvas.
-- Kevin
John Smith wrote:
The comments around application runtime initialization seem like they belong
more properly in the application lifecycle javadoc for the Application class
rather than on the Platform.runLater method specifically, though I do see how
the runtime initialization cuts across multiple classes
(Application/JFXPanel/FXCanvas, etc), so perhaps it is OK having the
description where it is (lacking some better place to put it). Useful
information though, thanks for including it.
+ *For standard JavaFX applications that extend
+ * {@see Application}, and use either the Java launcher or one of the
+ * launch methods in the Application class to launch the application,
+ * the FX runtime is initialized by the launcher before the Application
+ * class is loaded.
+ * For Swing applications that use JFXPanel to display FX content, the FX
+ * runtime is initialized when the first JFXPanel instance is constructed.
+ * For SWT application that use FXCanvas to display FX content, the FX
+ * runtime is initialized when the first FXCanvas instance is constructed.
-Original Message-
From: openjfx-dev-boun...@openjdk.java.net
[mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Kevin Rushforth
Sent: Monday, December 09, 2013 3:43 PM
To: Anthony Petrov
Cc: openjfx-dev@openjdk.java.net
Subject: 8 post-commit review request: RT-19968: Document that
Platform.runLater must not be called before FX is initialized
Please review the following javadoc change (post-commit).
https://javafx-jira.kenai.com/browse/RT-19968
-- Kevin
8 review request: RT-32512: Fix URL for JavaFX API docs license terms link
Mong, Please review the following (in the JIRA). https://javafx-jira.kenai.com/browse/RT-32512 Thanks. -- Kevin
Re: 8 review request: RT-32512: Fix URL for JavaFX API docs license terms link
Kevin, Looks great. Approved. Thanks, Mong On 12/9/2013 5:58 PM, Kevin Rushforth wrote: Mong, Please review the following (in the JIRA). https://javafx-jira.kenai.com/browse/RT-32512 Thanks. -- Kevin
hg: openjfx/8/graphics/rt: RT-32512: Fix URL for JavaFX API docs license terms link
Changeset: c818e4054cc7 Author:kcr Date: 2013-12-09 18:29 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c818e4054cc7 RT-32512: Fix URL for JavaFX API docs license terms link Reviewed-by: mtvo ! apps/samples/Ensemble8/build.xml ! build.properties ! modules/fxml/src/main/docs/javafx/fxml/doc-files/introduction_to_fxml.html ! modules/graphics/src/main/docs/javafx/scene/doc-files/cssref.html
8 review request: RT-21569: Document that applications should avoid flooding FX with Platform.runLater calls
Please review the following: https://javafx-jira.kenai.com/browse/RT-21569 -- Kevin
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: a09aab639ad0 Author:kcr Date: 2013-12-09 18:52 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a09aab639ad0 RT-34522: Update javafxpackager man pages for JDK/FX 8 Contributed-by: Nancy Hildebrandt - modules/fxpackager/src/main/man/html/javafxpackager.1.html ! modules/fxpackager/src/main/man/man1/javafxpackager.1 Changeset: f1d3a11f6cc4 Author:John Yoon john.y...@oracle.com Date: 2013-12-09 19:00 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f1d3a11f6cc4 [Samples Only][RT-33754] Ensemble Icons ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/concurrency/service/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/concurrency/service/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/concurrency/task/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/concurrency/task/prev...@2x.png
hg: openjfx/8/graphics/rt: [Samples Only][RT-33754] Ensemble Icons
Changeset: 58f12825ecac Author:John Yoon john.y...@oracle.com Date: 2013-12-09 19:57 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/58f12825ecac [Samples Only][RT-33754] Ensemble Icons ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/accordion/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/accordion/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/button/colorbutton/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/button/colorbutton/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/button/graphicbutton/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/button/graphicbutton/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/button/pillbutton/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/button/pillbutton/prev...@2x.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/checkbox/preview.png ! apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/checkbox/prev...@2x.png
hg: openjfx/8/graphics/rt: Ensemble8: Fix for RT-34006 Simplify Ensemble8 categories
Changeset: 8f0a6f77ec8f Author:Alexander Kouznetsov Date: 2013-12-09 20:19 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8f0a6f77ec8f Ensemble8: Fix for RT-34006 Simplify Ensemble8 categories ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java + apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.fdt + apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.fdx + apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.fnm + apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.frq + apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.nrm + apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.prx + apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.tii + apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.tis - apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_2.fdt - apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_2.fdx - apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_2.fnm - apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_2.frq - apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_2.nrm - apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_2.prx - apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_2.tii - apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_2.tis ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/listAll.txt ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/segments.gen + apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/segments_1 - apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/segments_3 + apps/samples/Ensemble8/src/samples/java/ensemble/samples/animation/timeline/TimelineApp.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/animation/timeline/timeline/TimelineApp.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/animation/timeline/timelineevents/TimelineEventsApp.java + apps/samples/Ensemble8/src/samples/java/ensemble/samples/animation/timelineevents/TimelineEventsApp.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/canvas/fireworks/FireworksApp.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/canvas/fireworks/Particle.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/canvas/fireworks/SanFranciscoFireworks.java + apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/bubble/BubbleChartApp.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/bubble/chart/BubbleChartApp.java + apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/candlestick/Candle.java + apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/candlestick/CandleStickChart.java + apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/candlestick/CandleStickChartApp.java + apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/candlestick/CandleStickExtraValues.java + apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/candlestick/TooltipContent.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/custom/candlestick/Candle.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/custom/candlestick/CandleStickChart.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/custom/candlestick/CandleStickChartApp.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/custom/candlestick/CandleStickExtraValues.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/custom/candlestick/TooltipContent.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/concurrency/service/DailySales.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/concurrency/service/GetDailySalesService.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/concurrency/service/GetDailySalesTask.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/concurrency/service/ServiceApp.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/concurrency/task/DailySales.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/concurrency/task/GetDailySalesTask.java - apps/samples/Ensemble8/src/samples/java/ensemble/samples/concurrency/task/TaskApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/accordion/AccordionApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/checkbox/CheckBoxApp.java + apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/htmleditor/HTMLEditorApp.java + apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/splitpane/HiddenSplitPaneApp.java -
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: 0d24fac99293 Author:Alexander Kouznetsov Date: 2013-12-09 20:36 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0d24fac99293 Ensemble8: Part #2 of fix for RT-34006 Simplify Ensemble8 categories ! apps/samples/Ensemble8/src/app/java/ensemble/SamplePopoverTreeList.java Changeset: 674968d9c3b6 Author:Alexander Kouznetsov Date: 2013-12-09 20:44 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/674968d9c3b6 Ensemble8: Fix for RT-34716 Ensemble8: xAxis label playground warning ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/area/curvefitted/CurveFittedAreaChartApp.java
hg: openjfx/8/graphics/rt: Ensemble8: Fix for RT-33532 Ensemble8: alternative column and row fill visible options doesn't work
Changeset: 9bbe05e11f94 Author:Alexander Kouznetsov Date: 2013-12-09 21:17 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9bbe05e11f94 Ensemble8: Fix for RT-33532 Ensemble8: alternative column and row fill visible options doesn't work ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/area/chart/AreaChartApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/area/curvefitted/CurveFittedAreaChartApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/area/stacked/StackedAreaChartApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/bar/chart/BarChartApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/bar/horizontal/HorizontalBarChartApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/bar/image/ImageBarChartApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/bar/stacked/StackedBarChartApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/bubble/BubbleChartApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/candlestick/CandleStickChartApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/line/category/CategoryLineChartApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/line/chart/LineChartApp.java ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/charts/scatter/chart/ScatterChartApp.java
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: 5fc3e61b4f21 Author:Alexander Kouznetsov Date: 2013-12-09 21:04 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5fc3e61b4f21 Ensemble8: Fix for RT-34714 Ensemble8: WebView sample limits its size ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/webview/WebViewApp.java Changeset: 50ed24bf65b7 Author:Alexander Kouznetsov Date: 2013-12-09 21:13 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/50ed24bf65b7 Ensemble8: Fix for RT-34786 Ensemble8: Multi-touch sample has bad size ! apps/samples/Ensemble8/src/samples/java/ensemble/samples/scenegraph/events/multitouch/MultiTouchApp.java
hg: openjfx/8/graphics/rt: Sync up SceneBuilder changes
Changeset: 6dfa55f03e62 Author:Yves Joan yves.j...@oracle.com Date: 2013-12-10 08:36 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6dfa55f03e62 Sync up SceneBuilder changes + apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/CssPanelDelegate.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/DocumentWindowController.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/SceneBuilderApp.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/SceneBuilderTest.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/about/AboutWindowController.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/i18n/SceneBuilderApp.properties + apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/info/InfoPanel.css ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/info/InfoPanel.fxml ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/info/InfoPanelController.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/menubar/MenuBar.fxml ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/menubar/MenuBarController.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/message/MessageBarController.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/message/MessagePanelController.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/preferences/Preferences.fxml + apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/preferences/PreferencesController.java + apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/preferences/PreferencesRecordDocument.java + apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/preferences/PreferencesRecordGlobal.java + apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/preferences/PreferencesWindowController.java + apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/preview/BackgroundColor.fxml + apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/preview/BackgroundColorDialogController.java ! apps/scenebuilder/SceneBuilderApp/src/com/oracle/javafx/scenebuilder/app/selectionbar/SelectionBarController.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/EditorController.css ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/EditorController.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/EditorPlatform.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/drag/DragController.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/drag/source/AbstractDragSource.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/drag/source/DocumentDragSource.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/drag/source/ExternalDragSource.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/drag/source/LibraryDragSource.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/drag/target/ContainerXYDropTarget.java + apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/drag/target/GridPaneDropTarget.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/i18n/SceneBuilderKit.properties ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/job/DeleteObjectSelectionJob.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/job/DuplicateSelectionJob.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/job/PasteJob.java + apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/job/gridpane/v2/GridSnapshot.java + apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/job/gridpane/v2/GridSnapshotItem.java + apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/job/gridpane/v2/InsertColumnConstraintsJob.java + apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/job/gridpane/v2/InsertColumnJob.java + apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/job/gridpane/v2/MoveCellContentJob.java + apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/job/gridpane/v2/MoveColumnContentJob.java ! apps/scenebuilder/SceneBuilderKit/src/com/oracle/javafx/scenebuilder/kit/editor/job/v2/CompositeJob.java !
