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

[Felix Bembrick]

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
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>
>>>
>>>
>