Look and feel mechanism?

[Felix Bembrick]

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 <swpalmer at 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.bembrick at 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 <steve at 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.bembrick at 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 <steve at winnall.ch> wrote:
> >>
> >> On 9 Dec 2013, at 03:18, Felix Bembrick <felix.bembrick at 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
> >>
> >>
> >>
>
>