To Be Or Not To Be (Native), was:Look and feel mechanism?

[Felix Bembrick]

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 actually achievable because the same control on one OS can look
and feel/behave quite differently on another OS which leads to very poor
levels of reuse.

It is not actually achievable because many controls simply *can't be
emulated in using Java/JavaFX *most likely because they have exclusive
access to native system or OS calls that are not accessible to Java or
because the expected levels of performance or "snappiness" cannot be
achieved using Java by any means.  Even with JNA or JNI you would be left
scratching your head in many cases.

And, it is not actually achievable because it's *simply too much work* to
get anywhere near to perfection!  We are talking *massive* amounts of
effort and very few people have either the talent, the eye, the attention
to detail or the patience to see such a project right through to the end
where *all* controls are covered.  The rock stars I mentioned earlier are
the exceptions of course.  There's clearly zero point in emulating *some*
of the controls only; you need the *full set* or it's just not viable.

Finally, and to look at it another way, what do we get even if some
super-human delivers us a native Look and Feel for every possible platform?
 Well, a massive maintenance nightmare for a start!  This super-human would
basically be spending all their super time and using up all their super
powers just keeping such libraries current.

So, if you are still with me, *why bother*?  Just consider if all those
rock stars (and super heroes) concentrated all their super efforts into
either improving the features, stability, performance or appearance of
JavaFX itself?  Just think what we could achieve!

And on the *why bother* theme, why bother to devote all that time and
effort, spend all those millions, tear out all that hair and hit all those
roadblocks when the *very thing we are trying to achieve is already
available*?

Yes, that's right, if you really, really, really want to build a native app
then why don't you just build a native app?  There are numerous tools,
languages, IDEs, toolchains and libraries that enable you to build awesome
*true* native apps!  I just don't think JavaFX is one of them :-)

And it doesn't have to be one of those toolkits because JavaFX can be used
to build an entirely different class of application and I now strongly
believe that this is the kind of app we should be concentrating on.  That
class (or classes) of app is one that is not so heavily dependent on the
native Look and Feel and doesn't need to be.  There are probably hundreds
of thousands of apps that are like this.  They are everywhere and JavaFX is
*perfect* for them!

Scott Palmer has argued that this approach is not valid (and sorry Scott if
am inaccurately paraphrasing you).  He cites examples such as Chrome,
Firefox and even MS Office as proof that this approach does not work.
 However, my response to that would be to say that just because these are
examples of where the developers got it seriously wrong, they do not prove
that this approach can't work and isn't working all over the marketplace.

There is no need to develop crappy, mistake ridden software by using a
toolkit such as JavaFX in a way that does not attempt to emulate the native
Look and Feel and the fact that even big companies like Google *still*
clearly get it horribly wrong doesn't imply that we *all* have to be so
ineffective.

Part of my newly-found aversion to emulated native Look and Feel comes from
my many years of both developing and using Swing applications.  Sure, I
know there are *some* (handful?) successful Swing apps, most notably those
developed with the NetBeans RCP, but in general Swing has failed to have
any penetration into serious commercial software.  Why?  Well, there are
several reasons (and a lot are due to Java itself) but, for me, I was never
satisfied with the so-called native Look and Feel options that come with
Swing.  I have been (and still am) very critical of the Windows Look and
Feel in Swing in particular because, even today, there is a vast gulf
between an actual native Windows application and a Swing application with
this Look and Feel.  So much so that I still want to almost knock my
monitor off the desk when I am using an application developed in this way.
 For me, this is not acceptable and such an application could never be
released as a *serious commercial product*.

And that's pretty much what this all boils down to: developing *serious
commercial software*.

If you are interested in developing something else then these lengthy
comments (am I *still* going?) probably do not apply to you :-)

So to summarise, I argue that it is not possible to develop serious
commercial software using emulated Look and Feel in JavaFX or in *any*
UItoolkit.  I *strongly* recommend that we all work together to make
JavaFX as good as it can be (which is absolutely awesome) by focusing on
the core product, the API, the performance, the feature set, the stability
*and* the supported platforms rather than throw good money after bad on a
*wonderful* goal that ultimately can never be reached...

Just my 2 bits,

Felix

P.S. I surely hope I have not offended any/all those who either disagree
with the main points or who still believe that native Look and Feel is
viable.  I remind you all that I am on my knees bowing with respect to the
rock stars I referred to and anyone else working on similar projects.
 Absolutely no offence is intended, I am merely expressing my (passionate)
feelings on this subject.


On 9 December 2013 19:10, Felix Bembrick <felix.bembrick at gmail.com> wrote:

>
>
>
> On 9 December 2013 16:10, Scott Palmer <swpalmer at gmail.com> wrote:
>
>>
>>
>> > On Dec 8, 2013, at 9:18 PM, Felix Bembrick <felix.bembrick at 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.duquevieira at gmail.com>wrote:
>> >
>> >> 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 <steve at 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.potts at 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.giles at 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
>> >>
>>
>
>