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

[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 wrote:

> I feel it's possible to emulate native well enough that vast majority of
> users would not notice. But I don't think it's commercially viable as the
> cost to create and maintain is just too high. I worked for years with apps
> using Swing native LAF and later on worked on Swing team on LAFs including
> creating the complete new Nimbus LAF. So I have felt the effort involved in
> full LAFs. When I started the direction for JavaFX skins and looks we made
> a very conscious decision to not do native looks. What we decided is to
> separate the look from the feel. There were already a good proportion of
> windows apps including Microsofts own Office that did not use the native
> look. Though they all tried to feel native, bar some new concepts each
> added like a ribbon control. So with FX we decided to go for single modern
> look with a native like feel. We went to a lot of effort to do a look that
> would not looks out of place on current platforms. Also in other areas we
> have put huge efforts in to be native like font rendering and file dialogs
> as they just have to be native. We never ruled out native look and feel in
> FX and I think technically its possible but decided we would not provide
> one as our resources were better focused in other areas.
>
> I also have amazing respect for Claudine Zillmann, Hendrik Ebbers etc. As
> they have done amazing job with Aqua look and I hope the community keeps
> working on cool projects like theirs.
>
> I dissagree that there are cases that can't be handled with Skin and CSS
> because all our controls implementation is in the skin so replacing that
> gives you 100% control. It was designed to leave the option open to have a
> set of skins that use the native heavy weight controls if we wanted that
> option. We already do that on platforms like iOS where there is just no way
> to emulate a text field for example with all the complex touch editing.
>
> Jasper
>
> > On Dec 11, 2013, at 6:23 AM, Robert Krüger  wrote:
> >
> > Amen and +1.
> >
> > On Tue, Dec 10, 2013 at 9:11 PM, Stephen F Northover
> >  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
> >>> mailto:steve.x.northo...@oracle.com>>
> wrote:
> >>>
> >>>I was very interesting in heavyweight integratio

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

[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  wrote:
> 
> Amen and +1.
> 
> On Tue, Dec 10, 2013 at 9:11 PM, Stephen F Northover
>  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
>>> 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
>>>> 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 b

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

[Robert Krüger]

Amen and +1.

On Tue, Dec 10, 2013 at 9:11 PM, Stephen F Northover
 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
>> 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
>>> >> > 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
>>> >> > 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
>>>

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

[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  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
>>>  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
>  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 th

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

[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  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
>>  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
  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 

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

[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 
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
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
mailto:steve.x.northo...@oracle.com>> wrote:

Here are my thoughts on the matter.  Give
people the choice of
whether to use native or non-native
components.  In some
applications, everything will be
non-native.  In others, only the
main content area will be non-native and
the rest will be native.
In some mobile applications, perhaps the
preference pages will be
native and other parts will not.

JavaFX is the best choice for non-native
widgets and we are
committed to making it the best toolkit
all around.

Steve

On 2013-12-09 9:49 AM, Scott Palmer wrote:
I agree that perfect sync with native
look and feels is not what
is required and not worth the effort.
 I do think though that
major concepts in the platform's look
and feel should (must!) be
followed or the user experience is ruined.

The example of the order of the ok and
cancel buttons has been
brought up alre

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

[Felix Bembrick]

Stephen, why do you refer to this discussion as "academic"?

Felix



On 11 December 2013 05:20, Stephen F Northover  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
>  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
>>>  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
>  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 

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

[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
 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
 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
 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 

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

[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
 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
 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
 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?)
amo

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

[Stephen F Northover]

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  
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  
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  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

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

[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  
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  
>>> 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

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

[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  
> 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  
>>> 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  
> 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 i

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

[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  
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  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

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

[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  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
>  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  
>>> 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  
> 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

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

[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
 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  
>> 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  
 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 

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

[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  
> 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  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 expl

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

[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  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 

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

[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  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 
> harsh

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

[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  wrote:

> Hi,
> when talking about mobile L&Fs 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  >:
> >
> > 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 
> 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, 

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

[Hendrik Ebbers]

Hi,
when talking about mobile L&Fs 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 :
> 
> 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  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 

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

[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  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
> a

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

[Felix Bembrick]

Spoiler: This is something I have become intensely passionate about so this
is likely to be a long post...

OK, so this (hijacked) thread started out as a discussion of options in
JavaFX for implementing "Look and Feel".  I think everyone agrees that even
with CSS and skins, JavaFX lacks the built-in ability to define a true Look
*and* Feel.  Further to this, there has been discussion on Twitter and
elsewhere regarding *native* Look and Feel and the merits of attempting
such an animal with JavaFX.

It is on this topic that I would like to add my 2 bits (as I am known to
do)!  I was going to use my blog http://justmy2bits.com but decided I would
be much more likely to be able to engage fellow JavaFX developers in a
positive, polite and respectful conversation here.

First, anyone who may follow me on Twitter, in this forum or when I post in
other forums (anyone?) will probably be a little bit confused as to where I
actually stand on this issue.  Well, this stems from the fact that I have
been giving confusing (if not conflicting) input into various threads on
this topic for quite a while.

Why?

Well, because until very recently, I myself was completely torn on the
subject of native Look and Feel.  In fact, I seemed to oscillate on an
almost daily basis from thinking it's a great, achievable idea to
dismissing such an idea on various grounds.  I am swaying so much because I
have so much riding on successful ports of JavaFX to iOS and Android and
because those ports depend heavily on resolving this issue once and for all.

Now I have had something of an epiphany and reached a conclusion.  I now do
not believe that pouring large (massive?) amounts of resources into the
painstaking task of building a fully compliant, fully performant native
Look and Feel is justifiable or worth the effort.  And let's be clear about
this: it is a *lot* of effort!

But before I proceed I just want to say categorically how much I admire the
thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann,
Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and
Feel to various OS/platforms with JavaFX.  I cannot put in words how much I
am in awe of the commitment, the attention to detail, the technical
prowess, the artistry and the drive of these fantastic people.  Their work
will undoubtedly be extremely useful to many developers worldwide.

I want to make all that *perfectly clear* because now I am going to explain
why I (probably) will not be one of those people and (hopefully) do it with
the utmost respect for the aforementioned rock stars :-)

Right, so back to the issue of whether to or not to implement or use a
native Look and Feel.  Some of the following comments have already been
made by me on other networks and in other forums so apologies if it seems a
bit repetitive to some.

At first glance, the idea of a native Look and Feel seems almost like the
proverbial Holy Grail.  I mean, if such a thing were truly possible and
viable, who wouldn't want one?  You still have your single codebase across
all platforms and you just just plug-in the particular native Look and Feel
for your target platform and voila!  World domination will surely soon
follow!

Well, not quite.  It's a great idea but I am going out on a limb to claim
that it has *never* worked.  Ever!  And by "work" I mean so that your
"not-so-native" app looks and feels (which includes all aspects of
behaviour, not just appearance) *exactly* like a true native app and *no
one* could tell you that it *wasn't* a native app.

Yes, I know there are masses now screaming at their monitors who will
undoubtedly cite the numerous success stories of Swing apps or maybe even
Qt or some other cross-platform UI toolkit and maybe my standards/criteria
are harsher than others but I stand by my claim that this has *never ever*
really, really, really worked.

OK, so why not?

Here's my first point: I postulate that such a noble goal is *not actually
achievable*.  It is not actually achievable for a number of reasons.

It is not actually achievable because, in most cases, we do not have access
to the code that implements the native controls on each OS so, at best, we
are "guessing" when we try to emulate all aspects of their appearance and
behaviour.  Try as we may, we will never get *every* control exactly right
and I firmly believe that anything that purports to be something else needs
to be *identical*.

It is not actually achievable because just as you feel you have reached an
acceptable level of "compliance" (which I again wager is never 100%), the
goal posts will move.  That is, the OS vendor will release an update and
even the minor ones can change either the appearance or behaviour of
controls, sometimes in subtle ways, sometimes in not so subtle ways.
 Either way, there is then going to be a period of time where you are
playing a futile game of catch-up and during that time your "native"
controls will be surely exposed for the impostors they are.