Yes, I think that's the best approach. I am working on some aspects of this internally and hopefully next year I can contribute some parts of that :-)
Felix On 10 December 2013 10:49, Scott Palmer <swpal...@gmail.com> 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 > 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 >>> >> >>> >> >>> >> >>> >>> >>
