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

2013-12-11 Thread Robert Krüger
Amen and +1. On Tue, Dec 10, 2013 at 9:11 PM, Stephen F Northover steve.x.northo...@oracle.com wrote: As I said before, it would be up to the application. If it was critical that your application do something like embed Excel, then it could live with the limitations. Perhaps you work in a

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

2013-12-11 Thread Jasper Potts
I feel it's possible to emulate native well enough that vast majority of users would not notice. But I don't think it's commercially viable as the cost to create and maintain is just too high. I worked for years with apps using Swing native LAF and later on worked on Swing team on LAFs

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

2013-12-11 Thread Scott Palmer
This isn't directly related to native Look and Feel, but it is related to the ability to embed native controls in specific cases where they are needed... I want to be able to get some way to render in native code onto my JavaFX app. One option that was discussed was to have some sort of native

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

2013-12-10 Thread Anthony Petrov
We have implemented HW/LW components mixing for AWT/Swing in the past [1]. However, the feature is very limited (no transparency support, etc.), and the limitations come from native system capabilities that can't be worked around easily. Do we really want something limited like this in FX?

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

2013-12-10 Thread Stephen F Northover
Yes, if it helps an application ship using the components and technology they need to make their product successful. In any case, this discussion is academic. Steve On 2013-12-10 12:25 PM, Anthony Petrov wrote: We have implemented HW/LW components mixing for AWT/Swing in the past [1].

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

2013-12-10 Thread Felix Bembrick
Stephen, why do you refer to this discussion as academic? Felix On 11 December 2013 05:20, Stephen F Northover steve.x.northo...@oracle.com wrote: Yes, if it helps an application ship using the components and technology they need to make their product successful. In any case, this

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

2013-12-10 Thread Stephen F Northover
I was very interesting in heavyweight integration a while back but could not get anyone very enthusiastic about it. Steve On 2013-12-10 1:35 PM, Felix Bembrick wrote: Stephen, why do you refer to this discussion as academic? Felix On 11 December 2013 05:20, Stephen F Northover

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

2013-12-10 Thread Felix Bembrick
Do you think it's either feasible or viable to the extent that a successful implementation would not have the limitations such as lack of transparency or be limited by the inability to apply Node transforms and functionality to native controls? I mean, such a large undertaking would only made

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

2013-12-10 Thread Felix Bembrick
Right, I guess what I was really asking was is there any way to craft a LW/HW integration solution that *doesn't* have nasty limitations? On 11 December 2013 07:11, Stephen F Northover steve.x.northo...@oracle.com wrote: As I said before, it would be up to the application. If it was

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

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

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

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

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

2013-12-09 Thread Felix Bembrick
That's correct Hendrik and this only adds weight to my argument. Clearly the mobile platforms (Android and especially iOS) are even harder-to-hit targets than desktop platforms. And if you are not able to develop a viable native Look and Feel for every platform then the paradigm of deploying

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

2013-12-09 Thread Scott Palmer
I agree that perfect sync with native look and feels is not what is required and not worth the effort. I do think though that major concepts in the platform's look and feel should (must!) be followed or the user experience is ruined. The example of the order of the ok and cancel buttons has

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

2013-12-09 Thread Stephen F Northover
Here are my thoughts on the matter. Give people the choice of whether to use native or non-native components. In some applications, everything will be non-native. In others, only the main content area will be non-native and the rest will be native. In some mobile applications, perhaps the

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

2013-12-09 Thread Felix Bembrick
Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets which is precisely my point. They are the kind of apps perfect for using JavaFX. But you refer to giving people the choice to go native where appropriate. How can I exercise that choice? Where is the

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

2013-12-09 Thread Rick Walker
There are a few critical elements that must conform to platform-specific look and feel: - app installer - management of app icons - system dialogs: file open, save and save, print - os x system menu bar Apart from these elements, native look and feel should be optional. On Mon, Dec 9, 2013 at

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

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

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

2013-12-09 Thread Stephen F Northover
Today, you can only exercise the choice by writing native code and you face heavyweight / lightweight issues depending on the platform and API. Steve On 2013-12-09 12:31 PM, Felix Bembrick wrote: Stephen, I thoroughly agree that JavaFX is by far the best choice for non-native apps/widgets

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

2013-12-09 Thread Felix Bembrick
What can we expect from the JavaFX team in this regard in the future? I know we have talked about mixing lightweight and heavyweight controls in the same context but is it going to happen? Is this planned for JFX9 perhaps? Is it *really* even feasible? On 10 Dec 2013, at 4:55, Stephen F

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

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