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 > >> > >> > >> > >
