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

Felix Bembrick felix.bembrick at
Tue Dec 10 12:14:55 PST 2013

Right, I guess what I was really asking was is there any way to craft a
LW/HW integration solution that *doesn't* have nasty limitations?

On 11 December 2013 07:11, Stephen F Northover <steve.x.northover at
> wrote:

>  As I said before, it would be up to the application.  If it was critical
> that your application do something like embed Excel, then it could live
> with the limitations.  Perhaps you work in a company where you have a
> custom native control that you are already embedding in Swing and you want
> to migrate to FX.  These sorts of applications could live with the
> limitations.
> Steve
> On 2013-12-10 3:03 PM, Felix Bembrick wrote:
>  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> 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> 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]
>>>> --
>>>> 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