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.bembr...@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.bembr...@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.bembr...@gmail.com> wrote:
>>> 
>>> 
>>> 
>>> 
>>>> On 9 December 2013 16:10, Scott Palmer <swpal...@gmail.com> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Dec 8, 2013, at 9:18 PM, Felix Bembrick <felix.bembr...@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.duquevie...@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 <st...@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.po...@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.gi...@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
>>>>>> 
>>>> 
>>> 
>>> 
>> 

Reply via email to