Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Amen and +1. On Tue, Dec 10, 2013 at 9:11 PM, Stephen F Northover steve.x.northo...@oracle.com wrote: As I said before, it would be up to the application. If it was critical that your application do something like embed Excel, then it could live with the limitations. Perhaps you work in a company where you have a custom native control that you are already embedding in Swing and you want to migrate to FX. These sorts of applications could live with the limitations. Steve On 2013-12-10 3:03 PM, Felix Bembrick wrote: Do you think it's either feasible or viable to the extent that a successful implementation would not have the limitations such as lack of transparency or be limited by the inability to apply Node transforms and functionality to native controls? I mean, such a large undertaking would only made sense if the end result gave us something we don't have now and that it worked well. Felix On 11 December 2013 06:57, Stephen F Northover steve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com wrote: I was very interesting in heavyweight integration a while back but could not get anyone very enthusiastic about it. Steve On 2013-12-10 1:35 PM, Felix Bembrick wrote: Stephen, why do you refer to this discussion as academic? Felix On 11 December 2013 05:20, Stephen F Northover steve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com wrote: Yes, if it helps an application ship using the components and technology they need to make their product successful. In any case, this discussion is academic. Steve On 2013-12-10 12:25 PM, Anthony Petrov wrote: We have implemented HW/LW components mixing for AWT/Swing in the past [1]. However, the feature is very limited (no transparency support, etc.), and the limitations come from native system capabilities that can't be worked around easily. Do we really want something limited like this in FX? [1] http://www.oracle.com/technetwork/articles/java/mixing-components-433992.html -- best regards, Anthony On 12/10/2013 06:14 AM, Stephen F Northover wrote: At one point, I was very interested in seeing this happen but there wasn't the band width and resources. Steve On 2013-12-09 1:00 PM, Felix Bembrick wrote: What can we expect from the JavaFX team in this regard in the future? I know we have talked about mixing lightweight and heavyweight controls in the same context but is it going to happen? Is this planned for JFX9 perhaps? Is it *really* even feasible? On 10 Dec 2013, at 4:55, Stephen F Northover steve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com wrote: Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com wrote: Here are my thoughts on
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
I feel it's possible to emulate native well enough that vast majority of users would not notice. But I don't think it's commercially viable as the cost to create and maintain is just too high. I worked for years with apps using Swing native LAF and later on worked on Swing team on LAFs including creating the complete new Nimbus LAF. So I have felt the effort involved in full LAFs. When I started the direction for JavaFX skins and looks we made a very conscious decision to not do native looks. What we decided is to separate the look from the feel. There were already a good proportion of windows apps including Microsofts own Office that did not use the native look. Though they all tried to feel native, bar some new concepts each added like a ribbon control. So with FX we decided to go for single modern look with a native like feel. We went to a lot of effort to do a look that would not looks out of place on current platforms. Also in other areas we have put huge efforts in to be native like font rendering and file dialogs as they just have to be native. We never ruled out native look and feel in FX and I think technically its possible but decided we would not provide one as our resources were better focused in other areas. I also have amazing respect for Claudine Zillmann, Hendrik Ebbers etc. As they have done amazing job with Aqua look and I hope the community keeps working on cool projects like theirs. I dissagree that there are cases that can't be handled with Skin and CSS because all our controls implementation is in the skin so replacing that gives you 100% control. It was designed to leave the option open to have a set of skins that use the native heavy weight controls if we wanted that option. We already do that on platforms like iOS where there is just no way to emulate a text field for example with all the complex touch editing. Jasper On Dec 11, 2013, at 6:23 AM, Robert Krüger krue...@lesspain.de wrote: Amen and +1. On Tue, Dec 10, 2013 at 9:11 PM, Stephen F Northover steve.x.northo...@oracle.com wrote: As I said before, it would be up to the application. If it was critical that your application do something like embed Excel, then it could live with the limitations. Perhaps you work in a company where you have a custom native control that you are already embedding in Swing and you want to migrate to FX. These sorts of applications could live with the limitations. Steve On 2013-12-10 3:03 PM, Felix Bembrick wrote: Do you think it's either feasible or viable to the extent that a successful implementation would not have the limitations such as lack of transparency or be limited by the inability to apply Node transforms and functionality to native controls? I mean, such a large undertaking would only made sense if the end result gave us something we don't have now and that it worked well. Felix On 11 December 2013 06:57, Stephen F Northover steve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com wrote: I was very interesting in heavyweight integration a while back but could not get anyone very enthusiastic about it. Steve On 2013-12-10 1:35 PM, Felix Bembrick wrote: Stephen, why do you refer to this discussion as academic? Felix On 11 December 2013 05:20, Stephen F Northover steve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com wrote: Yes, if it helps an application ship using the components and technology they need to make their product successful. In any case, this discussion is academic. Steve On 2013-12-10 12:25 PM, Anthony Petrov wrote: We have implemented HW/LW components mixing for AWT/Swing in the past [1]. However, the feature is very limited (no transparency support, etc.), and the limitations come from native system capabilities that can't be worked around easily. Do we really want something limited like this in FX? [1] http://www.oracle.com/technetwork/articles/java/mixing-components-433992.html -- best regards, Anthony On 12/10/2013 06:14 AM, Stephen F Northover wrote: At one point, I was very interested in seeing this happen but there wasn't the band width and resources. Steve On 2013-12-09 1:00 PM, Felix Bembrick wrote: What can we expect from the JavaFX team in this regard in the future? I know we have talked about mixing lightweight and heavyweight controls in the same context but is it going to happen? Is this planned for JFX9 perhaps? Is it *really* even feasible? On 10 Dec 2013,
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
This isn't directly related to native Look and Feel, but it is related to the ability to embed native controls in specific cases where they are needed... I want to be able to get some way to render in native code onto my JavaFX app. One option that was discussed was to have some sort of native surface that could be placed into the scene that we could render to with native code (e.g. a Direct3D or OpenGL surface). Even something as simple as getting access to the window handle of a Stage from native code much like what was done with JAWT would help. At least then we could manage our own native surface that was in a proper child of the main app window. Are Skins properly documented and supported in JavaFX 8? I know that Behaviours are not yet in that state. When Jasper wrote about ..option open to have a set of skins that use the native heavy weight controls if we wanted that option. We already do that on platforms like iOS where there is just no way to emulate a text field for example with all the complex touch editing. I wondered if it would be possible to get a native rendering surface into a desktop app just by making a custom skin? Could we make something as simple as a HeavyweightPanel and populate it with whatever native widgets we want via JNI? In my opinion restricting the use of true native controls to JNI access only isn't entirely unreasonable, but I don't know how it can be done with a JavaFX app currently as we just don't have the access to the native window. Having only JNI access forces one to deal with the platform specifics that Anthony Petrov has mentioned (the limitations come from native system capabilities that can't be worked around easily.) up front - that may be a good thing. Scott On Wed, Dec 11, 2013 at 11:52 AM, Jasper Potts jasper.po...@oracle.comwrote: I feel it's possible to emulate native well enough that vast majority of users would not notice. But I don't think it's commercially viable as the cost to create and maintain is just too high. I worked for years with apps using Swing native LAF and later on worked on Swing team on LAFs including creating the complete new Nimbus LAF. So I have felt the effort involved in full LAFs. When I started the direction for JavaFX skins and looks we made a very conscious decision to not do native looks. What we decided is to separate the look from the feel. There were already a good proportion of windows apps including Microsofts own Office that did not use the native look. Though they all tried to feel native, bar some new concepts each added like a ribbon control. So with FX we decided to go for single modern look with a native like feel. We went to a lot of effort to do a look that would not looks out of place on current platforms. Also in other areas we have put huge efforts in to be native like font rendering and file dialogs as they just have to be native. We never ruled out native look and feel in FX and I think technically its possible but decided we would not provide one as our resources were better focused in other areas. I also have amazing respect for Claudine Zillmann, Hendrik Ebbers etc. As they have done amazing job with Aqua look and I hope the community keeps working on cool projects like theirs. I dissagree that there are cases that can't be handled with Skin and CSS because all our controls implementation is in the skin so replacing that gives you 100% control. It was designed to leave the option open to have a set of skins that use the native heavy weight controls if we wanted that option. We already do that on platforms like iOS where there is just no way to emulate a text field for example with all the complex touch editing. Jasper On Dec 11, 2013, at 6:23 AM, Robert Krüger krue...@lesspain.de wrote: Amen and +1. On Tue, Dec 10, 2013 at 9:11 PM, Stephen F Northover steve.x.northo...@oracle.com wrote: As I said before, it would be up to the application. If it was critical that your application do something like embed Excel, then it could live with the limitations. Perhaps you work in a company where you have a custom native control that you are already embedding in Swing and you want to migrate to FX. These sorts of applications could live with the limitations. Steve On 2013-12-10 3:03 PM, Felix Bembrick wrote: Do you think it's either feasible or viable to the extent that a successful implementation would not have the limitations such as lack of transparency or be limited by the inability to apply Node transforms and functionality to native controls? I mean, such a large undertaking would only made sense if the end result gave us something we don't have now and that it worked well. Felix On 11 December 2013 06:57, Stephen F Northover steve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com wrote: I was very interesting in heavyweight integration a while back but could not get anyone
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
We have implemented HW/LW components mixing for AWT/Swing in the past [1]. However, the feature is very limited (no transparency support, etc.), and the limitations come from native system capabilities that can't be worked around easily. Do we really want something limited like this in FX? [1] http://www.oracle.com/technetwork/articles/java/mixing-components-433992.html -- best regards, Anthony On 12/10/2013 06:14 AM, Stephen F Northover wrote: At one point, I was very interested in seeing this happen but there wasn't the band width and resources. Steve On 2013-12-09 1:00 PM, Felix Bembrick wrote: What can we expect from the JavaFX team in this regard in the future? I know we have talked about mixing lightweight and heavyweight controls in the same context but is it going to happen? Is this planned for JFX9 perhaps? Is it *really* even feasible? On 10 Dec 2013, at 4:55, Stephen F Northover steve.x.northo...@oracle.com wrote: Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Yes, if it helps an application ship using the components and technology they need to make their product successful. In any case, this discussion is academic. Steve On 2013-12-10 12:25 PM, Anthony Petrov wrote: We have implemented HW/LW components mixing for AWT/Swing in the past [1]. However, the feature is very limited (no transparency support, etc.), and the limitations come from native system capabilities that can't be worked around easily. Do we really want something limited like this in FX? [1] http://www.oracle.com/technetwork/articles/java/mixing-components-433992.html -- best regards, Anthony On 12/10/2013 06:14 AM, Stephen F Northover wrote: At one point, I was very interested in seeing this happen but there wasn't the band width and resources. Steve On 2013-12-09 1:00 PM, Felix Bembrick wrote: What can we expect from the JavaFX team in this regard in the future? I know we have talked about mixing lightweight and heavyweight controls in the same context but is it going to happen? Is this planned for JFX9 perhaps? Is it *really* even feasible? On 10 Dec 2013, at 4:55, Stephen F Northover steve.x.northo...@oracle.com wrote: Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Stephen, why do you refer to this discussion as academic? Felix On 11 December 2013 05:20, Stephen F Northover steve.x.northo...@oracle.com wrote: Yes, if it helps an application ship using the components and technology they need to make their product successful. In any case, this discussion is academic. Steve On 2013-12-10 12:25 PM, Anthony Petrov wrote: We have implemented HW/LW components mixing for AWT/Swing in the past [1]. However, the feature is very limited (no transparency support, etc.), and the limitations come from native system capabilities that can't be worked around easily. Do we really want something limited like this in FX? [1] http://www.oracle.com/technetwork/articles/java/ mixing-components-433992.html -- best regards, Anthony On 12/10/2013 06:14 AM, Stephen F Northover wrote: At one point, I was very interested in seeing this happen but there wasn't the band width and resources. Steve On 2013-12-09 1:00 PM, Felix Bembrick wrote: What can we expect from the JavaFX team in this regard in the future? I know we have talked about mixing lightweight and heavyweight controls in the same context but is it going to happen? Is this planned for JFX9 perhaps? Is it *really* even feasible? On 10 Dec 2013, at 4:55, Stephen F Northover steve.x.northo...@oracle.com wrote: Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
I was very interesting in heavyweight integration a while back but could not get anyone very enthusiastic about it. Steve On 2013-12-10 1:35 PM, Felix Bembrick wrote: Stephen, why do you refer to this discussion as academic? Felix On 11 December 2013 05:20, Stephen F Northover steve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com wrote: Yes, if it helps an application ship using the components and technology they need to make their product successful. In any case, this discussion is academic. Steve On 2013-12-10 12:25 PM, Anthony Petrov wrote: We have implemented HW/LW components mixing for AWT/Swing in the past [1]. However, the feature is very limited (no transparency support, etc.), and the limitations come from native system capabilities that can't be worked around easily. Do we really want something limited like this in FX? [1] http://www.oracle.com/technetwork/articles/java/mixing-components-433992.html -- best regards, Anthony On 12/10/2013 06:14 AM, Stephen F Northover wrote: At one point, I was very interested in seeing this happen but there wasn't the band width and resources. Steve On 2013-12-09 1:00 PM, Felix Bembrick wrote: What can we expect from the JavaFX team in this regard in the future? I know we have talked about mixing lightweight and heavyweight controls in the same context but is it going to happen? Is this planned for JFX9 perhaps? Is it *really* even feasible? On 10 Dec 2013, at 4:55, Stephen F Northover steve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com wrote: Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Do you think it's either feasible or viable to the extent that a successful implementation would not have the limitations such as lack of transparency or be limited by the inability to apply Node transforms and functionality to native controls? I mean, such a large undertaking would only made sense if the end result gave us something we don't have now and that it worked well. Felix On 11 December 2013 06:57, Stephen F Northover steve.x.northo...@oracle.com wrote: I was very interesting in heavyweight integration a while back but could not get anyone very enthusiastic about it. Steve On 2013-12-10 1:35 PM, Felix Bembrick wrote: Stephen, why do you refer to this discussion as academic? Felix On 11 December 2013 05:20, Stephen F Northover steve.x.northo...@oracle.com wrote: Yes, if it helps an application ship using the components and technology they need to make their product successful. In any case, this discussion is academic. Steve On 2013-12-10 12:25 PM, Anthony Petrov wrote: We have implemented HW/LW components mixing for AWT/Swing in the past [1]. However, the feature is very limited (no transparency support, etc.), and the limitations come from native system capabilities that can't be worked around easily. Do we really want something limited like this in FX? [1] http://www.oracle.com/technetwork/articles/java/mixing-components-433992.html -- best regards, Anthony On 12/10/2013 06:14 AM, Stephen F Northover wrote: At one point, I was very interested in seeing this happen but there wasn't the band width and resources. Steve On 2013-12-09 1:00 PM, Felix Bembrick wrote: What can we expect from the JavaFX team in this regard in the future? I know we have talked about mixing lightweight and heavyweight controls in the same context but is it going to happen? Is this planned for JFX9 perhaps? Is it *really* even feasible? On 10 Dec 2013, at 4:55, Stephen F Northover steve.x.northo...@oracle.com wrote: Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Right, I guess what I was really asking was is there any way to craft a LW/HW integration solution that *doesn't* have nasty limitations? On 11 December 2013 07:11, Stephen F Northover steve.x.northo...@oracle.com wrote: As I said before, it would be up to the application. If it was critical that your application do something like embed Excel, then it could live with the limitations. Perhaps you work in a company where you have a custom native control that you are already embedding in Swing and you want to migrate to FX. These sorts of applications could live with the limitations. Steve On 2013-12-10 3:03 PM, Felix Bembrick wrote: Do you think it's either feasible or viable to the extent that a successful implementation would not have the limitations such as lack of transparency or be limited by the inability to apply Node transforms and functionality to native controls? I mean, such a large undertaking would only made sense if the end result gave us something we don't have now and that it worked well. Felix On 11 December 2013 06:57, Stephen F Northover steve.x.northo...@oracle.com wrote: I was very interesting in heavyweight integration a while back but could not get anyone very enthusiastic about it. Steve On 2013-12-10 1:35 PM, Felix Bembrick wrote: Stephen, why do you refer to this discussion as academic? Felix On 11 December 2013 05:20, Stephen F Northover steve.x.northo...@oracle.com wrote: Yes, if it helps an application ship using the components and technology they need to make their product successful. In any case, this discussion is academic. Steve On 2013-12-10 12:25 PM, Anthony Petrov wrote: We have implemented HW/LW components mixing for AWT/Swing in the past [1]. However, the feature is very limited (no transparency support, etc.), and the limitations come from native system capabilities that can't be worked around easily. Do we really want something limited like this in FX? [1] http://www.oracle.com/technetwork/articles/java/mixing-components-433992.html -- best regards, Anthony On 12/10/2013 06:14 AM, Stephen F Northover wrote: At one point, I was very interested in seeing this happen but there wasn't the band width and resources. Steve On 2013-12-09 1:00 PM, Felix Bembrick wrote: What can we expect from the JavaFX team in this regard in the future? I know we have talked about mixing lightweight and heavyweight controls in the same context but is it going to happen? Is this planned for JFX9 perhaps? Is it *really* even feasible? On 10 Dec 2013, at 4:55, Stephen F Northover steve.x.northo...@oracle.com wrote: Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be
To Be Or Not To Be (Native), was:Look and feel mechanism?
Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry and the drive of these fantastic people. Their work will undoubtedly be extremely useful to many developers worldwide. I want to make all that *perfectly clear* because now I am going to explain why I (probably) will not be one of those people and (hopefully) do it with the utmost respect for the aforementioned rock stars :-) Right, so back to the issue of whether to or not to implement or use a native Look and Feel. Some of the following comments have already been made by me on other networks and in other forums so apologies if it seems a bit repetitive to some. At first glance, the idea of a native Look and Feel seems almost like the proverbial Holy Grail. I mean, if such a thing were truly possible and viable, who wouldn't want one? You still have your single codebase across all platforms and you just just plug-in the particular native Look and Feel for your target platform and voila! World domination will surely soon follow! Well, not quite. It's a great idea but I am going out on a limb to claim that it has *never* worked. Ever! And by work I mean so that your not-so-native app looks and feels (which includes all aspects of behaviour, not just appearance) *exactly* like a true native app and *no one* could tell you that it *wasn't* a native app. Yes, I know there are masses now screaming at their monitors who will undoubtedly cite the numerous success stories of Swing apps or maybe even Qt or some other cross-platform UI toolkit and maybe my standards/criteria are harsher than others but I stand by my claim that this has *never ever* really, really, really worked. OK, so why not? Here's my first point: I postulate that such a noble goal is *not actually achievable*. It is not actually achievable for a number of reasons. It is not actually achievable because, in most cases, we do not have access to the code that implements the native controls on each OS so, at best, we are guessing when we try to emulate all aspects of their appearance and behaviour. Try as we may, we will never get *every* control exactly right and I firmly believe that anything that purports to be something else needs to be *identical*. It is not actually achievable because just as you feel you have reached an acceptable level of compliance (which I again wager is never 100%), the goal posts will move. That is, the OS vendor will release an update and even the minor ones can change either the appearance or behaviour of controls, sometimes in subtle ways, sometimes in not so subtle ways. Either way, there is then going to be a period of time where you are playing a futile game of catch-up and during that time your native controls will be surely exposed for the impostors they are. It is not
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
BTW, I was wanting to refer to a comment on this topic made my Pedro DV on Twitter today. Pedro has been doing stunningly good work on a Metro Look and Feel for JavaFX and, when questioned by me, stated that while he may attempt such a Look and Feel for Android, he wouldn't try to do one for iOS for reasons which he did not completely explain. Pedro, do you mind expanding on those thoughts here? When you referred to the numerous issue with iOS were you referring to iOS itself or to trying to emulate iOS with JavaFX? Thanks, Felix On 9 December 2013 20:24, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry and the drive of these fantastic people. Their work will undoubtedly be extremely useful to many developers worldwide. I want to make all that *perfectly clear* because now I am going to explain why I (probably) will not be one of those people and (hopefully) do it with the utmost respect for the aforementioned rock stars :-) Right, so back to the issue of whether to or not to implement or use a native Look and Feel. Some of the following comments have already been made by me on other networks and in other forums so apologies if it seems a bit repetitive to some. At first glance, the idea of a native Look and Feel seems almost like the proverbial Holy Grail. I mean, if such a thing were truly possible and viable, who wouldn't want one? You still have your single codebaseacross all platforms and you just just plug-in the particular native Look and Feel for your target platform and voila! World domination will surely soon follow! Well, not quite. It's a great idea but I am going out on a limb to claim that it has *never* worked. Ever! And by work I mean so that your not-so-native app looks and feels (which includes all aspects of behaviour, not just appearance) *exactly* like a true native app and *no one* could tell you that it *wasn't* a native app. Yes, I know there are masses now screaming at their monitors who will undoubtedly cite the numerous success stories of Swing apps or maybe even Qt or some other cross-platform UI toolkit and maybe my standards/criteria are harsher than others but I stand by my claim that this has *never ever* really, really, really worked. OK, so why not? Here's my first point: I postulate that such a noble goal is *not actually achievable*. It is not actually achievable for a number of reasons. It is not actually achievable because, in most cases, we do not have access to the code that implements the native controls on each OS so, at best, we are guessing when we try to emulate all aspects of their appearance and behaviour. Try as we may, we will never get *every*
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Hi, when talking about mobile LFs like iOS and Android a lot more stuff need to be done. All the mobile UIs have different layout contains and a lot of default animations. When creating a Look and Feel for mobile systems a set of additinal panes / layout containers need to be created. Hendrik Am 09.12.2013 um 10:36 schrieb Felix Bembrick felix.bembr...@gmail.com: BTW, I was wanting to refer to a comment on this topic made my Pedro DV on Twitter today. Pedro has been doing stunningly good work on a Metro Look and Feel for JavaFX and, when questioned by me, stated that while he may attempt such a Look and Feel for Android, he wouldn't try to do one for iOS for reasons which he did not completely explain. Pedro, do you mind expanding on those thoughts here? When you referred to the numerous issue with iOS were you referring to iOS itself or to trying to emulate iOS with JavaFX? Thanks, Felix On 9 December 2013 20:24, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry and the drive of these fantastic people. Their work will undoubtedly be extremely useful to many developers worldwide. I want to make all that *perfectly clear* because now I am going to explain why I (probably) will not be one of those people and (hopefully) do it with the utmost respect for the aforementioned rock stars :-) Right, so back to the issue of whether to or not to implement or use a native Look and Feel. Some of the following comments have already been made by me on other networks and in other forums so apologies if it seems a bit repetitive to some. At first glance, the idea of a native Look and Feel seems almost like the proverbial Holy Grail. I mean, if such a thing were truly possible and viable, who wouldn't want one? You still have your single codebaseacross all platforms and you just just plug-in the particular native Look and Feel for your target platform and voila! World domination will surely soon follow! Well, not quite. It's a great idea but I am going out on a limb to claim that it has *never* worked. Ever! And by work I mean so that your not-so-native app looks and feels (which includes all aspects of behaviour, not just appearance) *exactly* like a true native app and *no one* could tell you that it *wasn't* a native app. Yes, I know there are masses now screaming at their monitors who will undoubtedly cite the numerous success stories of Swing apps or maybe even Qt or some other cross-platform UI toolkit and maybe my standards/criteria are harsher than others but I stand by my claim that this has *never ever* really, really, really worked. OK, so why not? Here's my first
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
That's correct Hendrik and this only adds weight to my argument. Clearly the mobile platforms (Android and especially iOS) are even harder-to-hit targets than desktop platforms. And if you are not able to develop a viable native Look and Feel for every platform then the paradigm of deploying your app using a native Look and Feel to *every* device breaks down... On 9 December 2013 20:57, Hendrik Ebbers hendrik.ebb...@me.com wrote: Hi, when talking about mobile LFs like iOS and Android a lot more stuff need to be done. All the mobile UIs have different layout contains and a lot of default animations. When creating a Look and Feel for mobile systems a set of additinal panes / layout containers need to be created. Hendrik Am 09.12.2013 um 10:36 schrieb Felix Bembrick felix.bembr...@gmail.com : BTW, I was wanting to refer to a comment on this topic made my Pedro DV on Twitter today. Pedro has been doing stunningly good work on a Metro Look and Feel for JavaFX and, when questioned by me, stated that while he may attempt such a Look and Feel for Android, he wouldn't try to do one for iOS for reasons which he did not completely explain. Pedro, do you mind expanding on those thoughts here? When you referred to the numerous issue with iOS were you referring to iOS itself or to trying to emulate iOS with JavaFX? Thanks, Felix On 9 December 2013 20:24, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry and the drive of these fantastic people. Their work will undoubtedly be extremely useful to many developers worldwide. I want to make all that *perfectly clear* because now I am going to explain why I (probably) will not be one of those people and (hopefully) do it with the utmost respect for the aforementioned rock stars :-) Right, so back to the issue of whether to or not to implement or use a native Look and Feel. Some of the following comments have already been made by me on other networks and in other forums so apologies if it seems a bit repetitive to some. At first glance, the idea of a native Look and Feel seems almost like the proverbial Holy Grail. I mean, if such a thing were truly possible and viable, who wouldn't want one? You still have your single codebaseacross all platforms and you just just plug-in the particular native Look and Feel for your target platform and voila! World domination will surely soon follow! Well, not quite. It's a great idea but I am going out on a limb to claim that it has *never* worked. Ever! And by work I mean so that your not-so-native app looks and feels (which
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry and the drive of these fantastic people. Their work will undoubtedly be extremely useful to many developers worldwide. I want to make all that *perfectly clear* because now I am going to explain why I (probably) will not be one of those people and (hopefully) do it with the utmost respect for the aforementioned rock stars :-) Right, so back to the issue of whether to or not to implement or use a native Look and Feel. Some of the following comments have already been made by me on other networks and in other forums so apologies if it seems a bit repetitive to some. At first glance, the idea of a native Look and Feel seems almost like the proverbial Holy Grail. I mean, if such a thing were truly possible and viable, who wouldn't want one? You still have your single codebase across all platforms and you just just plug-in the particular native Look and Feel for your target platform and voila! World domination will surely soon follow! Well, not quite. It's a great idea but I am going out on a limb to claim that it has *never* worked. Ever! And by work I mean so that your not-so-native app looks and feels (which includes all aspects of behaviour, not just appearance) *exactly* like a true native app and *no one* could tell you that it *wasn't* a native app. Yes, I know there are masses now screaming at their monitors who will undoubtedly cite the numerous success stories of Swing apps or maybe even Qt or some other cross-platform UI toolkit and maybe my standards/criteria are harsher than others but I stand by my claim that this has
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry and the drive of these fantastic people. Their work will undoubtedly be extremely useful to many developers worldwide. I want to make all that *perfectly clear* because now I am going to explain why I (probably) will not be one of those people and (hopefully) do it with the utmost respect for the aforementioned rock stars :-) Right, so back to the issue of whether to or not to implement or use a native Look and Feel. Some of the following comments have already been made by me on other networks and in other forums so apologies if it seems a bit repetitive to some. At first glance, the idea of a native Look and Feel seems almost like the proverbial Holy Grail. I mean, if such a thing were truly possible and viable, who wouldn't want one? You still have your single codebase across all platforms and you just just plug-in the particular native Look and Feel for your target platform and voila! World domination will surely soon follow! Well, not quite. It's a great idea but I am going out on a limb to claim that it has *never* worked. Ever! And by work I mean so that your not-so-native app looks
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry and the drive of these fantastic people. Their work will undoubtedly be extremely useful to many developers worldwide. I want to make all that *perfectly clear* because now I am going to explain why I (probably) will not be one of those people and (hopefully) do it with the utmost respect for the aforementioned rock stars :-) Right,
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
There are a few critical elements that must conform to platform-specific look and feel: - app installer - management of app icons - system dialogs: file open, save and save, print - os x system menu bar Apart from these elements, native look and feel should be optional. On Mon, Dec 9, 2013 at 12:31 PM, Felix Bembrick felix.bembr...@gmail.com wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
I would go further by saying that those things you have mentioned should be truly native, not just native look and feel. Consider the Swing file chooser using Windows look and feel for example. That just never worked or looked right. On 10 Dec 2013, at 4:47, Rick Walker thoughtslin...@gmail.com wrote: There are a few critical elements that must conform to platform-specific look and feel: - app installer - management of app icons - system dialogs: file open, save and save, print - os x system menu bar Apart from these elements, native look and feel should be optional. On Mon, Dec 9, 2013 at 12:31 PM, Felix Bembrick felix.bembr...@gmail.com wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in (trying ever so hard) to bring native Look and Feel to various OS/platforms with JavaFX. I cannot put in words how much I am in awe of the commitment, the attention to detail, the technical prowess, the artistry and the drive of these fantastic people. Their work will undoubtedly be extremely useful to many developers worldwide. I want to make all that *perfectly clear* because now I am going to explain why I (probably) will not be
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
What can we expect from the JavaFX team in this regard in the future? I know we have talked about mixing lightweight and heavyweight controls in the same context but is it going to happen? Is this planned for JFX9 perhaps? Is it *really* even feasible? On 10 Dec 2013, at 4:55, Stephen F Northover steve.x.northo...@oracle.com wrote: Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve On 2013-12-09 9:49 AM, Scott Palmer wrote: I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has been brought up already. But that isn't even the most important one. Things like shortcut keys. CTRL-C to copy on windows, Command-C to copy on Mac. Standard menu layouts, right-click behaviour and standard context menus. They just have to be in the right place. That they look different doesn't matter as much. And this doesn't mean that you can't try new ideas for UI. But basic things that users expect to work should still work. E.g. Command-Q on OS X better quit the app :-) As noted already with my reference to Office and browsers.. Fully native apps can be non-compliant with the platforms look and feel. So this isn't really a Java-specific issue. Scott On Dec 9, 2013, at 4:24 AM, Felix Bembrick felix.bembr...@gmail.com wrote: Spoiler: This is something I have become intensely passionate about so this is likely to be a long post... OK, so this (hijacked) thread started out as a discussion of options in JavaFX for implementing Look and Feel. I think everyone agrees that even with CSS and skins, JavaFX lacks the built-in ability to define a true Look *and* Feel. Further to this, there has been discussion on Twitter and elsewhere regarding *native* Look and Feel and the merits of attempting such an animal with JavaFX. It is on this topic that I would like to add my 2 bits (as I am known to do)! I was going to use my blog http://justmy2bits.com but decided I would be much more likely to be able to engage fellow JavaFX developers in a positive, polite and respectful conversation here. First, anyone who may follow me on Twitter, in this forum or when I post in other forums (anyone?) will probably be a little bit confused as to where I actually stand on this issue. Well, this stems from the fact that I have been giving confusing (if not conflicting) input into various threads on this topic for quite a while. Why? Well, because until very recently, I myself was completely torn on the subject of native Look and Feel. In fact, I seemed to oscillate on an almost daily basis from thinking it's a great, achievable idea to dismissing such an idea on various grounds. I am swaying so much because I have so much riding on successful ports of JavaFX to iOS and Android and because those ports depend heavily on resolving this issue once and for all. Now I have had something of an epiphany and reached a conclusion. I now do not believe that pouring large (massive?) amounts of resources into the painstaking task of building a fully compliant, fully performant native Look and Feel is justifiable or worth the effort. And let's be clear about this: it is a *lot* of effort! But before I proceed I just want to say categorically how much I admire the thoroughly awesome work/efforts of the likes of Pedro DV, Claudine Zillmann, Hendrik Ebbers et. al. in
Re: To Be Or Not To Be (Native), was:Look and feel mechanism?
Doesn’t this also imply that you are using AWT/Swing? JavaFX has no way to be hosted in anything other than a JFXPanel or a JavaFX Stage. Only the JFXPanel can be hosted in a windows that allows heavy weight (native) controls, or even allows JNI code to get the window handle so you can integrate your JavaFX with other native bits. Scott On Dec 9, 2013, at 12:55 PM, Stephen F Northover steve.x.northo...@oracle.com wrote: Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the support for native widgets in JavaFX? And isn't the real Holy Grail being able to mix native and non-native widgets in the same app with all features of Node being available to every widget, with all the effects and transforms, all the CSS/styling and with all the performance? Could JavaFX ever be such a toolkit? On 10 Dec 2013, at 2:24, Stephen F Northover steve.x.northo...@oracle.com wrote: Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the preference pages will be native and other parts will not. JavaFX is the best choice for non-native widgets and we are committed to making it the best toolkit all around. Steve
