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 On Dec 9, 2013 4:14 PM, "Felix Bembrick" <felix.bembr...@gmail.com> wrote: > 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 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 >> >> >> >> >> >> >> >> >
