Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

2013-12-11 Thread Robert Krüger
Amen and +1.

On Tue, Dec 10, 2013 at 9:11 PM, Stephen F Northover
steve.x.northo...@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.northo...@oracle.com mailto:steve.x.northo...@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.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 

Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

2013-12-11 Thread Jasper Potts
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 krue...@lesspain.de wrote:
 
 Amen and +1.
 
 On Tue, Dec 10, 2013 at 9:11 PM, Stephen F Northover
 steve.x.northo...@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.northo...@oracle.com mailto:steve.x.northo...@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.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, 

Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

2013-12-11 Thread Scott Palmer
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.po...@oracle.comwrote:

 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 krue...@lesspain.de wrote:
 
  Amen and +1.
 
  On Tue, Dec 10, 2013 at 9:11 PM, Stephen F Northover
  steve.x.northo...@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.northo...@oracle.com mailto:steve.x.northo...@oracle.com
 wrote:
 
 I was very interesting in heavyweight integration a while back but
 could not get anyone 

Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

2013-12-10 Thread Anthony Petrov
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 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 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 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 

Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

2013-12-10 Thread Stephen F Northover
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 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 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 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 

Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

2013-12-10 Thread Felix Bembrick
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
 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 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 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 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 

Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

2013-12-10 Thread Stephen F Northover
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.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 

Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

2013-12-10 Thread Felix Bembrick
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.northo...@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.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 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 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 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 

Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

2013-12-10 Thread Felix Bembrick
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.northo...@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.northo...@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.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 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 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 

Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

2013-12-09 Thread Felix Bembrick
BTW, I was wanting to refer to a comment on this topic made my Pedro DV on
Twitter today.  Pedro has been doing stunningly good work on a Metro Look
and Feel for JavaFX and, when questioned by me, stated that while he may
attempt such a Look and Feel for Android, he wouldn't try to do one for iOS
for reasons which he did not completely explain.

Pedro, do you mind expanding on those thoughts here?  When you referred to
the numerous issue with iOS were you referring to iOS itself or to trying
to emulate iOS with JavaFX?

Thanks,

Felix



On 9 December 2013 20:24, Felix Bembrick 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 codebaseacross 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* 

Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

2013-12-09 Thread Hendrik Ebbers
Hi,
when talking about mobile LFs like iOS and Android a lot more stuff need to be 
done. All the mobile UIs have different layout contains and a lot of default 
animations. When creating a Look and Feel for mobile systems a set of additinal 
panes / layout containers need to be created.

Hendrik

 Am 09.12.2013 um 10:36 schrieb Felix Bembrick felix.bembr...@gmail.com:
 
 BTW, I was wanting to refer to a comment on this topic made my Pedro DV on
 Twitter today.  Pedro has been doing stunningly good work on a Metro Look
 and Feel for JavaFX and, when questioned by me, stated that while he may
 attempt such a Look and Feel for Android, he wouldn't try to do one for iOS
 for reasons which he did not completely explain.
 
 Pedro, do you mind expanding on those thoughts here?  When you referred to
 the numerous issue with iOS were you referring to iOS itself or to trying
 to emulate iOS with JavaFX?
 
 Thanks,
 
 Felix
 
 
 
 On 9 December 2013 20:24, Felix Bembrick 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 codebaseacross 
 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 

Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

2013-12-09 Thread Felix Bembrick
That's correct Hendrik and this only adds weight to my argument.  Clearly
the mobile platforms (Android and especially iOS) are even harder-to-hit
targets than desktop platforms.

And if you are not able to develop a viable native Look and Feel for every
platform then the paradigm of deploying your app using a native Look and
Feel to *every* device breaks down...


On 9 December 2013 20:57, Hendrik Ebbers hendrik.ebb...@me.com wrote:

 Hi,
 when talking about mobile LFs like iOS and Android a lot more stuff need
 to be done. All the mobile UIs have different layout contains and a lot of
 default animations. When creating a Look and Feel for mobile systems a set
 of additinal panes / layout containers need to be created.

 Hendrik

  Am 09.12.2013 um 10:36 schrieb Felix Bembrick felix.bembr...@gmail.com
 :
 
  BTW, I was wanting to refer to a comment on this topic made my Pedro DV
 on
  Twitter today.  Pedro has been doing stunningly good work on a Metro Look
  and Feel for JavaFX and, when questioned by me, stated that while he may
  attempt such a Look and Feel for Android, he wouldn't try to do one for
 iOS
  for reasons which he did not completely explain.
 
  Pedro, do you mind expanding on those thoughts here?  When you referred
 to
  the numerous issue with iOS were you referring to iOS itself or to trying
  to emulate iOS with JavaFX?
 
  Thanks,
 
  Felix
 
 
 
  On 9 December 2013 20:24, Felix Bembrick 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
 codebaseacross 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 

Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

2013-12-09 Thread Scott Palmer
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 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 

Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

2013-12-09 Thread Stephen F Northover
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 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 

Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

2013-12-09 Thread Felix Bembrick
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 
 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 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, 

Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

2013-12-09 Thread Rick Walker
There are a few critical elements that must conform to
platform-specific look and feel:

- app installer
- management of app icons
- system dialogs: file open, save and save, print
- os x system menu bar

Apart from these elements, native look and feel should be optional.

On Mon, Dec 9, 2013 at 12:31 PM, Felix Bembrick
felix.bembr...@gmail.com 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 
 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 
 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 

Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

2013-12-09 Thread Felix Bembrick
I would go further by saying that those things you have mentioned should be 
truly native, not just native look and feel. Consider the Swing file chooser 
using Windows look and feel for example. That just never worked or looked right.

 On 10 Dec 2013, at 4:47, Rick Walker thoughtslin...@gmail.com wrote:
 
 There are a few critical elements that must conform to
 platform-specific look and feel:
 
 - app installer
 - management of app icons
 - system dialogs: file open, save and save, print
 - os x system menu bar
 
 Apart from these elements, native look and feel should be optional.
 
 On Mon, Dec 9, 2013 at 12:31 PM, Felix Bembrick
 felix.bembr...@gmail.com 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 
 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 
 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 

Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

2013-12-09 Thread Stephen F Northover
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 
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 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 

Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

2013-12-09 Thread Felix Bembrick
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 
 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 
 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 
 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 

Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

2013-12-09 Thread Scott Palmer
Doesn’t this also imply that you are using AWT/Swing?  JavaFX has no way to be 
hosted in anything other than a JFXPanel or a JavaFX Stage.  Only the JFXPanel 
can be hosted in a windows that allows heavy weight (native) controls, or even 
allows JNI code to get the window handle so you can integrate your JavaFX with 
other native bits.


Scott

On Dec 9, 2013, at 12:55 PM, Stephen F Northover 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 
 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