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

[Felix Bembrick]

That's correct Hendrik and this only adds weight to my argument.  Clearly
the mobile platforms (Android and especially iOS) are even harder-to-hit
targets than desktop platforms.

And if you are not able to develop a viable native Look and Feel for every
platform then the paradigm of deploying your app using a native Look and
Feel to *every* device breaks down...


On 9 December 2013 20:57, Hendrik Ebbers <hendrik.ebbers at me.com> wrote:

> Hi,
> when talking about mobile L&Fs like iOS and Android a lot more stuff need
> to be done. All the mobile UIs have different layout contains and a lot of
> default animations. When creating a Look and Feel for mobile systems a set
> of additinal panes / layout containers need to be created.
>
> Hendrik
>
> > Am 09.12.2013 um 10:36 schrieb Felix Bembrick <felix.bembrick at gmail.com
> >:
> >
> > BTW, I was wanting to refer to a comment on this topic made my Pedro DV
> on
> > Twitter today.  Pedro has been doing stunningly good work on a Metro Look
> > and Feel for JavaFX and, when questioned by me, stated that while he may
> > attempt such a Look and Feel for Android, he wouldn't try to do one for
> iOS
> > for reasons which he did not completely explain.
> >
> > Pedro, do you mind expanding on those thoughts here?  When you referred
> to
> > the numerous issue with iOS were you referring to iOS itself or to trying
> > to emulate iOS with JavaFX?
> >
> > Thanks,
> >
> > Felix
> >
> >
> >
> >> On 9 December 2013 20:24, Felix Bembrick <felix.bembrick at gmail.com>
> 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 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
> codebaseacross 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
> JavaFXis *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
> >>>>>>
> >>>>
> >>>
> >>>
> >>
>