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
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.duquevie...@gmail.com
<mailto:pedro.duquevie...@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
<st...@winnall.ch
<mailto:st...@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.po...@oracle.com
<mailto:jasper.po...@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.gi...@oracle.com
<mailto:jonathan.gi...@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
