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
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
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
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?
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].
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
21 matches
Mail list logo
