To Be Or Not To Be (Native), was:Look and feel mechanism?
Anthony Petrov
anthony.petrov at oracle.com
Wed Dec 11 04:49:02 PST 2013
As I mentioned earlier in this thread: "the limitations come from native
system capabilities that can't be worked around easily."
If you know how to overcome the difficulties at the native level, let's
discuss this.
--
best regards,
Anthony
On 12/11/2013 12:14 AM, Felix Bembrick wrote:
> Right, I guess what I was really asking was is there any way to craft a
> LW/HW integration solution that *doesn't* have nasty limitations?
>
>
> On 11 December 2013 07:11, Stephen F Northover
> <steve.x.northover at oracle.com <mailto: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
>>> 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