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

Stephen F Northover steve.x.northover at
Tue Dec 10 10:20:06 PST 2013

Yes, if it helps an application ship using the components and technology 
they need to make their product successful.  In any case, this 
discussion is academic.


On 2013-12-10 12:25 PM, Anthony Petrov wrote:
> We have implemented HW/LW components mixing for AWT/Swing in the past 
> [1]. However, the feature is very limited (no transparency support, 
> etc.), and the limitations come from native system capabilities that 
> can't be worked around easily.
> Do we really want something limited like this in FX?
> [1] 
> -- 
> best regards,
> Anthony
> On 12/10/2013 06:14 AM, Stephen F Northover wrote:
>> At one point,  I was very interested in seeing this happen but there
>> wasn't the band width and resources.
>> Steve
>> On 2013-12-09 1:00 PM, Felix Bembrick wrote:
>>> What can we expect from the JavaFX team in this regard in the future?
>>> I know we have talked about mixing lightweight and heavyweight
>>> controls in the same context but is it going to happen? Is this
>>> planned for JFX9 perhaps? Is it *really* even feasible?
>>>> On 10 Dec 2013, at 4:55, Stephen F Northover
>>>> <steve.x.northover at> wrote:
>>>> Today, you can only exercise the choice by writing native code and
>>>> you face heavyweight / lightweight issues depending on the platform
>>>> and API.
>>>> Steve
>>>>> 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 performance?
>>>>> Could JavaFX ever be such a toolkit?
>>>>>> On 10 Dec 2013, at 2:24, Stephen F Northover
>>>>>> <steve.x.northover at> wrote:
>>>>>> 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.
>>>>>> Steve
>>>>>>> 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 ruined.
>>>>>>> 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.
>>>>>>> Scott
>>>>>>>> On Dec 9, 2013, at 4:24 AM, Felix Bembrick
>>>>>>>> <felix.bembrick at> 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.
>>>>>>>> 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* 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,
>>>>>>>> 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> wrote:
>>>>>>>>>> On 9 December 2013 16:10, Scott Palmer <swpalmer at> 
>>>>>>>>>> wrote:
>>>>>>>>>>> On Dec 8, 2013, at 9:18 PM, Felix Bembrick
>>>>>>>>>>> <felix.bembrick at> 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>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> 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> 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
>>>>>>>>>>>>> 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

More information about the openjfx-dev mailing list