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