To Be Or Not To Be (Native), was:Look and feel mechanism?
Stephen F Northover
steve.x.northover at oracle.com
Tue Dec 10 11:57:49 PST 2013
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
> 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.duquevieira at gmail.com
> <mailto:pedro.duquevieira at 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
> <steve at winnall.ch
> <mailto:steve at 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.potts at oracle.com
> <mailto:jasper.potts at 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.giles at oracle.com
> <mailto:jonathan.giles at 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
>
>
>
>
>
>
More information about the openjfx-dev
mailing list