Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API.


On 2013-12-09 12:31 PM, Felix Bembrick wrote:
Stephen, I thoroughly agree that JavaFX is by far the best choice for 
non-native apps/widgets which is precisely my point. They are the kind of apps 
perfect for using JavaFX.

But you refer to giving people the choice to go native where appropriate. How 
can I exercise that choice? Where is the support for native widgets in JavaFX?

And isn't the real Holy Grail being able to mix native and non-native widgets 
in the same app with all features of Node being available to every widget, with 
all the effects and transforms, all the CSS/styling and with all the 

Could JavaFX ever be such a toolkit?

On 10 Dec 2013, at 2:24, Stephen F Northover <> 

Here are my thoughts on the matter.  Give people the choice of whether to use 
native or non-native components.  In some applications, everything will be 
non-native.  In others, only the main content area will be non-native and the 
rest will be native. In some mobile applications, perhaps the preference pages 
will be native and other parts will not.

JavaFX is the best choice for non-native widgets and we are committed to making 
it the best toolkit all around.


On 2013-12-09 9:49 AM, Scott Palmer wrote:
I agree that perfect sync with native look and feels is not what is required 
and not worth the effort.  I do think though that major concepts in the 
platform's look and feel should (must!) be followed or the user experience is 

The example of the order of the ok and cancel buttons has been brought up 
already.  But that isn't even the most important one.

Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. 
 Standard menu layouts, right-click behaviour and standard context menus.  They 
just have to be in the right place.  That they look different doesn't matter as 
much. And this doesn't mean that you can't try new ideas for UI.  But basic 
things that users expect to work should still work. E.g. Command-Q on OS X 
better quit the app :-)

As noted already with my reference to Office and browsers.. Fully native apps 
can be non-compliant with the platforms look and feel.  So this isn't really a 
Java-specific issue.


On Dec 9, 2013, at 4:24 AM, Felix Bembrick <> wrote:

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


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 

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 

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* UI toolkit.  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,


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

On 9 December 2013 16:10, Scott Palmer <> wrote:

On Dec 8, 2013, at 9:18 PM, Felix Bembrick <> wrote:
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 

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



On 9 December 2013 12:35, Pedro Duque Vieira <>wrote:


@Jasper: Yes, that's very interesting! Forgot that was possible to do in

On Mon, Dec 9, 2013 at 12:15 AM, Stephen Winnall <> wrote:

It may be possible to change the LOOK with CSS, but not the FEEL, which
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
an appropriate common API.


On 9 Dec 2013, at 00:20, Jasper Potts <> wrote:

You can set skin classes from CSS so should be able to do everything
could with Swing and more. With just a CSS file and skins as and when

On Dec 8, 2013, at 3:00 PM, Jonathan Giles <
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:

Is there any Look and Feel mechanism in place, like the one in Swing?
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

Reply via email to