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

[Felix Bembrick]

Do you think it's either feasible or viable to the extent that a successful
implementation would not have the limitations such as lack of transparency
or be limited by the inability to apply Node transforms and functionality
to native controls?  I mean, such a large undertaking would only made sense
if the end result gave us something we don't have now and that it worked
well.

Felix



On 11 December 2013 06:57, Stephen F Northover <steve.x.northover at oracle.com
> wrote:

>  I was very interesting in heavyweight integration a while back but could
> not get anyone very enthusiastic about it.
>
> Steve
>
>
> On 2013-12-10 1:35 PM, Felix Bembrick wrote:
>
>  Stephen, why do you refer to this discussion as "academic"?
>
>  Felix
>
>
>
> On 11 December 2013 05:20, Stephen F Northover <
> steve.x.northover at oracle.com> wrote:
>
>> 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.
>>
>> Steve
>>
>>
>> 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]
>>> http://www.oracle.com/technetwork/articles/java/mixing-components-433992.html
>>>
>>> --
>>> 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 oracle.com> 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 oracle.com> 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 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 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 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>
>>>>
>>>>
>>
>
>