That's correct Hendrik and this only adds weight to my argument. Clearly the mobile platforms (Android and especially iOS) are even harder-to-hit targets than desktop platforms.
And if you are not able to develop a viable native Look and Feel for every platform then the paradigm of deploying your app using a native Look and Feel to *every* device breaks down... On 9 December 2013 20:57, Hendrik Ebbers <hendrik.ebb...@me.com> wrote: > Hi, > when talking about mobile L&Fs like iOS and Android a lot more stuff need > to be done. All the mobile UIs have different layout contains and a lot of > default animations. When creating a Look and Feel for mobile systems a set > of additinal panes / layout containers need to be created. > > Hendrik > > > Am 09.12.2013 um 10:36 schrieb Felix Bembrick <felix.bembr...@gmail.com > >: > > > > BTW, I was wanting to refer to a comment on this topic made my Pedro DV > on > > Twitter today. Pedro has been doing stunningly good work on a Metro Look > > and Feel for JavaFX and, when questioned by me, stated that while he may > > attempt such a Look and Feel for Android, he wouldn't try to do one for > iOS > > for reasons which he did not completely explain. > > > > Pedro, do you mind expanding on those thoughts here? When you referred > to > > the numerous issue with iOS were you referring to iOS itself or to trying > > to emulate iOS with JavaFX? > > > > Thanks, > > > > Felix > > > > > > > >> On 9 December 2013 20:24, 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 > codebaseacross 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 > JavaFXis *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* > UItoolkit. 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 > >>>>>> > >>>> > >>> > >>> > >> >
