Stephen, why do you refer to this discussion as "academic"? Felix
On 11 December 2013 05:20, Stephen F Northover <steve.x.northo...@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.northo...@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.northo...@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.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 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.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 >>>>>>>>>>>>> >>>>>>>>>>>> >>>>> >>> >>> >
