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.northo...@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.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 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> >>>> >>>> >> > >
