To Be Or Not To Be (Native), was:Look and feel mechanism?
Scott Palmer
swpalmer at gmail.com
Wed Dec 11 09:14:11 PST 2013
This isn't directly related to native Look and Feel, but it is related to
the ability to embed native controls in specific cases where they are
needed...
I want to be able to get some way to render in native code onto my JavaFX
app. One option that was discussed was to have some sort of native surface
that could be placed into the scene that we could render to with native
code (e.g. a Direct3D or OpenGL surface). Even something as simple as
getting access to the window handle of a Stage from native code much like
what was done with JAWT would help. At least then we could manage our own
native surface that was in a proper child of the main app window.
Are Skins properly documented and supported in JavaFX 8? I know that
Behaviours are not yet in that state. When Jasper wrote about "..option
open to have a set of skins that use the native heavy weight controls if we
wanted that option. We already do that on platforms like iOS where there is
just no way to emulate a text field for example with all the complex touch
editing." I wondered if it would be possible to get a native rendering
surface into a desktop app just by making a custom skin? Could we make
something as simple as a HeavyweightPanel and populate it with whatever
native widgets we want via JNI? In my opinion restricting the use of true
native controls to JNI access only isn't entirely unreasonable, but I don't
know how it can be done with a JavaFX app currently as we just don't have
the access to the native window. Having only JNI access forces one to deal
with the platform specifics that Anthony Petrov has mentioned ("the
limitations come from native system capabilities that can't be worked
around easily.") up front - that may be a good thing.
Scott
On Wed, Dec 11, 2013 at 11:52 AM, Jasper Potts <jasper.potts at oracle.com>wrote:
> I feel it's possible to emulate native well enough that vast majority of
> users would not notice. But I don't think it's commercially viable as the
> cost to create and maintain is just too high. I worked for years with apps
> using Swing native LAF and later on worked on Swing team on LAFs including
> creating the complete new Nimbus LAF. So I have felt the effort involved in
> full LAFs. When I started the direction for JavaFX skins and looks we made
> a very conscious decision to not do native looks. What we decided is to
> separate the look from the feel. There were already a good proportion of
> windows apps including Microsofts own Office that did not use the native
> look. Though they all tried to feel native, bar some new concepts each
> added like a ribbon control. So with FX we decided to go for single modern
> look with a native like feel. We went to a lot of effort to do a look that
> would not looks out of place on current platforms. Also in other areas we
> have put huge efforts in to be native like font rendering and file dialogs
> as they just have to be native. We never ruled out native look and feel in
> FX and I think technically its possible but decided we would not provide
> one as our resources were better focused in other areas.
>
> I also have amazing respect for Claudine Zillmann, Hendrik Ebbers etc. As
> they have done amazing job with Aqua look and I hope the community keeps
> working on cool projects like theirs.
>
> I dissagree that there are cases that can't be handled with Skin and CSS
> because all our controls implementation is in the skin so replacing that
> gives you 100% control. It was designed to leave the option open to have a
> set of skins that use the native heavy weight controls if we wanted that
> option. We already do that on platforms like iOS where there is just no way
> to emulate a text field for example with all the complex touch editing.
>
> Jasper
>
> > On Dec 11, 2013, at 6:23 AM, Robert Krüger <krueger at lesspain.de> wrote:
> >
> > 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