To Be Or Not To Be (Native), was:Look and feel mechanism?
Robert Krüger
krueger at lesspain.de
Wed Dec 11 06:23:38 PST 2013
Amen and +1.
On Tue, Dec 10, 2013 at 9:11 PM, Stephen F Northover
<steve.x.northover at 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.northover at oracle.com <mailto:steve.x.northover at 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.northover at oracle.com
>>> <mailto:steve.x.northover at 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.northover at oracle.com
>>> <mailto:steve.x.northover at 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.northover at oracle.com
>>> <mailto:steve.x.northover at 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.bembrick at gmail.com
>>>
>>> <mailto:felix.bembrick at 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.bembrick at gmail.com
>>>
>>> <mailto:felix.bembrick at gmail.com>>
>>> wrote:
>>>
>>>
>>>
>>> On 9 December 2013
>>> 16:10, Scott Palmer
>>> <swpalmer at gmail.com
>>>
>>> <mailto:swpalmer at gmail.com>>
>>> wrote:
>>>
>>>
>>> On Dec 8, 2013,
>>> at 9:18 PM, Felix
>>> Bembrick
>>>
>>> <felix.bembrick at gmail.com
>>>
>>> <mailto:felix.bembrick at 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
More information about the openjfx-dev
mailing list