Amen and +1.
On Tue, Dec 10, 2013 at 9:11 PM, 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 <mailto: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 >>> <mailto: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 >>> <mailto: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 >>> <mailto: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 >>> >>> <mailto: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 >>> >>> <mailto:felix.bembr...@gmail.com>> >>> wrote: >>> >>> >>> >>> On 9 December 2013 >>> 16:10, Scott Palmer >>> <swpal...@gmail.com >>> >>> <mailto:swpal...@gmail.com>> >>> wrote: >>> >>> >>> On Dec 8, 2013, >>> at 9:18 PM, Felix >>> Bembrick >>> >>> <felix.bembr...@gmail.com >>> >>> <mailto: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
