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