Re: CFV: New OpenJFX Committer: Vadim Pakhnushev

[Petr Pchelko]

Vote: YES.

With best regards. Petr.

On 12.12.2013, at 1:17, David Hill  wrote:

> 
> I hereby nominate Vadim Pakhnushev to OpenJFX Committer.
> 
> Vadim is a member of JavaFX Embedded team at Oracle. Vadim's changes are in 
> Glass Windows/D3d:
> 
>  hg log -M -u "vadim"
> 
> An incomplete list of Vadim's commits and reviews is also available by the 
> following link:
> 
> http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=vadim
> 
> Votes are due by Dec 25, 2013.
> 
> Only current OpenJFX Committers [1] are eligible to vote on this nomination. 
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2]. Nomination to a project 
> Committer is described in [3].
> 
> [1] http://openjdk.java.net/census#openjfx
> 
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> 
> [3] http://openjdk.java.net/projects#project-committer
> 
> Thanks,
> 
> Dave
> 
> 
> 

hg: openjfx/8u-dev/rt: RT-34442 Enable build for Linux/ARM targets on OS X

[hang . vo]

Changeset: 005c29b27adf
Author:Daniel Blaukopf 
Date:  2013-12-12 00:38 +0200
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/005c29b27adf

RT-34442 Enable build for Linux/ARM targets on OS X
Reviewed-by: ddhill

! buildSrc/armv6hf.gradle
! buildSrc/armv6sf.gradle

Option to keep Stages always on top on JavaFX 8 ?

[Herve Girod]

I know that this option is not available for JavaFX 2.2, but is it planned
for Java 8, and for what time frame if the answer is yes (for example, for
initial release or later ?) .

This is an important feature for us, because we need to show JavaFX content
on top of Windows created on other programs (for example, elements on top
of a cartographic system produced by a C++ program, but it's just an
example).

As there is no alwaysOnTop API on Stage in JavaFX, a workaround is to
create a Swing Window, put a JFXPanel in it, and the Scene in the JFXPanel.
However, multitouch gestures are not handled by Swing, so these are not
working in this case.

Our only option is then to put a Stage toFront(), and hope that the other
content won't pop on top of JavaFX while the user click on it.

This is OK if no part of our Stage need to be transparent to user events,
and also if all of the other Windows are created prior to the JavaFX stage
is created, but it is not always possible, and we envision cases where our
workaround won't work.

Regards,

Hervé

hg: openjfx/8u-dev/rt: RT-34774: [RTL] Arrow keys navigation doesn't respect TableView orientation

[hang . vo]

Changeset: de2103867529
Author:leifs
Date:  2013-12-11 13:34 -0800
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/de2103867529

RT-34774: [RTL] Arrow keys navigation doesn't respect TableView orientation

! 
modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java

Re: b119 layout issues

[Felix Bembrick]

I am seeing these issues too...

> On 12 Dec 2013, at 7:44, Scott Palmer  wrote:
> 
> This appears to be a significant regression in JavaFX 8.  I have created
> https://javafx-jira.kenai.com/browse/RT-34849 with a test case.
> 
> Scott
> 
> 
> 
>> On Wed, Dec 11, 2013 at 10:58 AM, Scott Palmer  wrote:
>> 
>> I'm seeing very significant layout issues in b119.
>> Content is rendering outside of it's parent container when it shouldn't
>> be. The parent should be re-sizing to accomodate the content, but it isn't,
>> or it is resizing based on an old size of the child content.
>> 
>> Borders are not painting properly when a component resizes. Sometimes the
>> border remains at the old, larger, size while the background and content is
>> painted at the newer smaller size.
>> 
>> I have a feeling it is going to take some effort to make a reproducible
>> test case.  Are there known layout issues with b119?
>> 
>> 
>> Scott
>> 

Fwd: CFV: New OpenJFX Committer: Vadim Pakhnushev

[David Hill]

I hereby nominate Vadim Pakhnushev to OpenJFX Committer.

Vadim is a member of JavaFX Embedded team at Oracle. Vadim's changes are in 
Glass Windows/D3d:

  hg log -M -u "vadim"

An incomplete list of Vadim's commits and reviews is also available by the 
following link:

http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=vadim

Votes are due by Dec 25, 2013.

Only current OpenJFX Committers [1] are eligible to vote on this nomination. 
Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [2]. Nomination to a project 
Committer is described in [3].

[1] http://openjdk.java.net/census#openjfx

[2] http://openjdk.java.net/bylaws#lazy-consensus

[3] http://openjdk.java.net/projects#project-committer

Thanks,

Dave

Re: b119 layout issues

[Scott Palmer]

This appears to be a significant regression in JavaFX 8.  I have created
https://javafx-jira.kenai.com/browse/RT-34849 with a test case.

Scott



On Wed, Dec 11, 2013 at 10:58 AM, Scott Palmer  wrote:

> I'm seeing very significant layout issues in b119.
> Content is rendering outside of it's parent container when it shouldn't
> be. The parent should be re-sizing to accomodate the content, but it isn't,
> or it is resizing based on an old size of the child content.
>
> Borders are not painting properly when a component resizes. Sometimes the
> border remains at the old, larger, size while the background and content is
> painted at the newer smaller size.
>
> I have a feeling it is going to take some effort to make a reproducible
> test case.  Are there known layout issues with b119?
>
>
> Scott
>

Re: Please put release number in review requests

[Stephen F Northover]

This is a great idea.  I have seen Anthony doing this already.

Steve

On 2013-12-11 1:49 PM, Kevin Rushforth wrote:
It would be helpful if the release for which a review is requested is 
in the subject line now that we have multiple releases in flight. A 
suggestion for this (from the Wiki 
) is:


   8 review request: RT-12345: summary of the bug
   8u20 review request:  RT-12345: summary of the bug

Thanks.

-- Kevin

Please put release number in review requests

[Kevin Rushforth]

It would be helpful if the release for which a review is requested is in 
the subject line now that we have multiple releases in flight. A 
suggestion for this (from the Wiki 
) is:


   8 review request: RT-12345: summary of the bug
   8u20 review request:  RT-12345: summary of the bug

Thanks.

-- Kevin

hg: openjfx/8/graphics/rt: RT-34244: fx applet hangs if java console is not shown

[hang . vo]

Changeset: b7940b612df5
Author:Felipe Heidrich 
Date:  2013-12-06 13:32 -0800
URL:   http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b7940b612df5

RT-34244: fx applet hangs if java console is not shown
Reviewed-by: Kevin, Anthony, Thomas

! modules/graphics/src/main/java/com/sun/javafx/font/FontFactory.java
! modules/graphics/src/main/java/com/sun/javafx/font/LogicalFont.java
! modules/graphics/src/main/java/com/sun/javafx/font/PrismFontFactory.java
! modules/graphics/src/main/java/com/sun/javafx/font/PrismFontLoader.java
! modules/graphics/src/main/java/com/sun/prism/j2d/J2DFontFactory.java

Re: Reloading stylesheets

[David Grieve]

There is clearly a bug there somewhere. Would you mind filing an issue on 
javafx-jira.kenai.com?

On Dec 11, 2013, at 11:51 AM, ngalarn...@abinitio.com wrote:

> Hi David,
> 
> I have stylesheet SWITCHING working fine. I can switch between 2 different 
> stylesheets on disk without tearing down & rebuilding my Scene. To do this 
> I simply do:
>scene.stylesheets.clear()
>scene.stylesheets.add(differentStylesheet)
> and the changes show up immediately (I'm assuming those 2 lines cause a 
> .css recalculation & a pulse).
> 
> I would like to get stylesheet RELOADING to work in my JavaFX 8 app. By 
> this I mean picking up changes in a single .css file. This would allow the 
> developers to tweak the stylesheet & reload to see the effects 
> immediately.
> 
> Unfortunately, it feels like the Filename of the stylesheet is the Key in 
> a cache that isn't getting cleared by my code above. Nothing visible 
> happens when I do:
>scene.stylesheets.clear()
>scene.stylesheets.add(sameStylesheet)
> 
> Given your description below, my impression is that RELOADING should also 
> work...
> 
> Thank you for any suggestions,
> 
> Neil
> 
> 
> 
> 
> From:   David Grieve 
> To: Werner Lehmann 
> Cc: openjfx-dev@openjdk.java.net
> Date:   12/10/2013 11:10 AM
> Subject:Re: Reloading stylesheets
> Sent by:openjfx-dev-boun...@openjdk.java.net
> 
> 
> 
> The way it works in 8.0 is that there is a cache of loaded stylesheets. 
> When a scene or parent adds a stylesheet, the stylesheet is added to the 
> cache. Any other scene or parent that uses the same stylesheet will get 
> the one from cache. If a scene or parent later removes the stylesheet, the 
> stylesheet is removed from the cache and the css style cache for any scene 
> or parent that referenced that stylesheet is cleared (since the set of 
> styles may have changed). Any scene or parent that referenced the now 
> removed stylesheet is told to reapply its styles. Since the stylesheet is 
> no longer in cache, it will be re-parsed (or reloaded if there is a binary 
> version of the stylesheet) when it is called for by a scene or parent.
> 
> The way it worked in 2.x was an abomination.
> 
> On Dec 10, 2013, at 10:30 AM, Werner Lehmann 
>  wrote:
> 
>> Interesting. Assuming the stylesheets are still cached, how would it 
> know when to reload and not use the cached sheet? Or has sheet processing 
> been optimized so much that caching is not necessary anymore...
>> 
>> On 10.12.2013 16:15, Tom Schindl wrote:
>>> No on FX8 you need to remove and readd them! So the only thing 
> different
>>> is that you omit the reload-call on FX8.
> 
> 
> 
> 
> 
> NOTICE from Ab Initio: This email (including any attachments) may contain 
> information that is subject to confidentiality obligations or is legally 
> privileged, and sender does not waive confidentiality or privilege. If 
> received in error, please notify the sender, delete this email, and make 
> no further use, disclosure, or distribution. 

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

[Scott Palmer]

This isn't directly related to native Look and Feel, but it is related to
the ability to embed native controls in specific cases where they are
needed...
I want to be able to get some way to render in native code onto my JavaFX
app.  One option that was discussed was to have some sort of native surface
that could be placed into the scene that we could render to with native
code (e.g. a Direct3D or OpenGL surface).  Even something as simple as
getting access to the window handle of a Stage from native code much like
what was done with JAWT would help.  At least then we could manage our own
native surface that was in a proper child of the main app window.

Are Skins properly documented and supported in JavaFX 8?  I know that
Behaviours are not yet in that state.  When Jasper wrote about "..option
open to have a set of skins that use the native heavy weight controls if we
wanted that option. We already do that on platforms like iOS where there is
just no way to emulate a text field for example with all the complex touch
editing."  I wondered if it would be possible to get a native rendering
surface into a desktop app just by making a custom skin?  Could we make
something as simple as a HeavyweightPanel and populate it with whatever
native widgets we want via JNI?  In my opinion restricting the use of true
native controls to JNI access only isn't entirely unreasonable, but I don't
know how it can be done with a JavaFX app currently as we just don't have
the access to the native window.  Having only JNI access forces one to deal
with the platform specifics that Anthony Petrov has mentioned ("the
limitations come from native system capabilities that can't be worked
around easily.") up front - that may be a good thing.


Scott


On Wed, Dec 11, 2013 at 11:52 AM, Jasper Potts wrote:

> I feel it's possible to emulate native well enough that vast majority of
> users would not notice. But I don't think it's commercially viable as the
> cost to create and maintain is just too high. I worked for years with apps
> using Swing native LAF and later on worked on Swing team on LAFs including
> creating the complete new Nimbus LAF. So I have felt the effort involved in
> full LAFs. When I started the direction for JavaFX skins and looks we made
> a very conscious decision to not do native looks. What we decided is to
> separate the look from the feel. There were already a good proportion of
> windows apps including Microsofts own Office that did not use the native
> look. Though they all tried to feel native, bar some new concepts each
> added like a ribbon control. So with FX we decided to go for single modern
> look with a native like feel. We went to a lot of effort to do a look that
> would not looks out of place on current platforms. Also in other areas we
> have put huge efforts in to be native like font rendering and file dialogs
> as they just have to be native. We never ruled out native look and feel in
> FX and I think technically its possible but decided we would not provide
> one as our resources were better focused in other areas.
>
> I also have amazing respect for Claudine Zillmann, Hendrik Ebbers etc. As
> they have done amazing job with Aqua look and I hope the community keeps
> working on cool projects like theirs.
>
> I dissagree that there are cases that can't be handled with Skin and CSS
> because all our controls implementation is in the skin so replacing that
> gives you 100% control. It was designed to leave the option open to have a
> set of skins that use the native heavy weight controls if we wanted that
> option. We already do that on platforms like iOS where there is just no way
> to emulate a text field for example with all the complex touch editing.
>
> Jasper
>
> > On Dec 11, 2013, at 6:23 AM, Robert Krüger  wrote:
> >
> > Amen and +1.
> >
> > On Tue, Dec 10, 2013 at 9:11 PM, Stephen F Northover
> >  wrote:
> >> As I said before, it would be up to the application.  If it was critical
> >> that your application do something like embed Excel, then it could live
> with
> >> the limitations.  Perhaps you work in a company where you have a custom
> >> native control that you are already embedding in Swing and you want to
> >> migrate to FX.  These sorts of applications could live with the
> limitations.
> >>
> >> Steve
> >>
> >>> On 2013-12-10 3:03 PM, Felix Bembrick wrote:
> >>>
> >>> Do you think it's either feasible or viable to the extent that a
> >>> successful implementation would not have the limitations such as lack
> of
> >>> transparency or be limited by the inability to apply Node transforms
> and
> >>> functionality to native controls?  I mean, such a large undertaking
> would
> >>> only made sense if the end result gave us something we don't have now
> and
> >>> that it worked well.
> >>>
> >>> Felix
> >>>
> >>>
> >>>
> >>> On 11 December 2013 06:57, Stephen F Northover
> >>> mailto:steve.x.northo...@oracle.com>>
> wrote:
> >>>
> >>>I was very interesting in heavyweight integratio

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

[Jasper Potts]

I feel it's possible to emulate native well enough that vast majority of users 
would not notice. But I don't think it's commercially viable as the cost to 
create and maintain is just too high. I worked for years with apps using Swing 
native LAF and later on worked on Swing team on LAFs including creating the 
complete new Nimbus LAF. So I have felt the effort involved in full LAFs. When 
I started the direction for JavaFX skins and looks we made a very conscious 
decision to not do native looks. What we decided is to separate the look from 
the feel. There were already a good proportion of windows apps including 
Microsofts own Office that did not use the native look. Though they all tried 
to feel native, bar some new concepts each added like a ribbon control. So with 
FX we decided to go for single modern look with a native like feel. We went to 
a lot of effort to do a look that would not looks out of place on current 
platforms. Also in other areas we have put huge efforts in to be native like 
font rendering and file dialogs as they just have to be native. We never ruled 
out native look and feel in FX and I think technically its possible but decided 
we would not provide one as our resources were better focused in other areas. 

I also have amazing respect for Claudine Zillmann, Hendrik Ebbers etc. As they 
have done amazing job with Aqua look and I hope the community keeps working on 
cool projects like theirs. 

I dissagree that there are cases that can't be handled with Skin and CSS 
because all our controls implementation is in the skin so replacing that gives 
you 100% control. It was designed to leave the option open to have a set of 
skins that use the native heavy weight controls if we wanted that option. We 
already do that on platforms like iOS where there is just no way to emulate a 
text field for example with all the complex touch editing. 

Jasper

> On Dec 11, 2013, at 6:23 AM, Robert Krüger  wrote:
> 
> Amen and +1.
> 
> On Tue, Dec 10, 2013 at 9:11 PM, Stephen F Northover
>  wrote:
>> As I said before, it would be up to the application.  If it was critical
>> that your application do something like embed Excel, then it could live with
>> the limitations.  Perhaps you work in a company where you have a custom
>> native control that you are already embedding in Swing and you want to
>> migrate to FX.  These sorts of applications could live with the limitations.
>> 
>> Steve
>> 
>>> On 2013-12-10 3:03 PM, Felix Bembrick wrote:
>>> 
>>> Do you think it's either feasible or viable to the extent that a
>>> successful implementation would not have the limitations such as lack of
>>> transparency or be limited by the inability to apply Node transforms and
>>> functionality to native controls?  I mean, such a large undertaking would
>>> only made sense if the end result gave us something we don't have now and
>>> that it worked well.
>>> 
>>> Felix
>>> 
>>> 
>>> 
>>> On 11 December 2013 06:57, Stephen F Northover
>>> mailto:steve.x.northo...@oracle.com>> wrote:
>>> 
>>>I was very interesting in heavyweight integration a while back but
>>>could not get anyone very enthusiastic about it.
>>> 
>>>Steve
>>> 
>>> 
On 2013-12-10 1:35 PM, Felix Bembrick wrote:
 
Stephen, why do you refer to this discussion as "academic"?
 
Felix
 
 
 
On 11 December 2013 05:20, Stephen F Northover
>>>> wrote:
 
Yes, if it helps an application ship using the components and
technology they need to make their product successful.  In
any case, this discussion is academic.
 
Steve
 
 
On 2013-12-10 12:25 PM, Anthony Petrov wrote:
 
We have implemented HW/LW components mixing for AWT/Swing
in the past [1]. However, the feature is very limited (no
transparency support, etc.), and the limitations come
from native system capabilities that can't be worked
around easily.
 
Do we really want something limited like this in FX?
 
[1]
 
 http://www.oracle.com/technetwork/articles/java/mixing-components-433992.html
 
-- best regards,
Anthony
 
On 12/10/2013 06:14 AM, Stephen F Northover wrote:
 
At one point,  I was very interested in seeing this
happen but there
wasn't the band width and resources.
 
Steve
 
On 2013-12-09 1:00 PM, Felix Bembrick wrote:
 
What can we expect from the JavaFX team in this
regard in the future?
I know we have talked about mixing lightweight
and heavyweight
controls in the same context b

Re: Reloading stylesheets

[ngalarneau]

Hi David,

I have stylesheet SWITCHING working fine. I can switch between 2 different 
stylesheets on disk without tearing down & rebuilding my Scene. To do this 
I simply do:
scene.stylesheets.clear()
scene.stylesheets.add(differentStylesheet)
and the changes show up immediately (I'm assuming those 2 lines cause a 
.css recalculation & a pulse).

I would like to get stylesheet RELOADING to work in my JavaFX 8 app. By 
this I mean picking up changes in a single .css file. This would allow the 
developers to tweak the stylesheet & reload to see the effects 
immediately.

Unfortunately, it feels like the Filename of the stylesheet is the Key in 
a cache that isn't getting cleared by my code above. Nothing visible 
happens when I do:
scene.stylesheets.clear()
scene.stylesheets.add(sameStylesheet)

Given your description below, my impression is that RELOADING should also 
work...

Thank you for any suggestions,

Neil




From:   David Grieve 
To: Werner Lehmann 
Cc: openjfx-dev@openjdk.java.net
Date:   12/10/2013 11:10 AM
Subject:Re: Reloading stylesheets
Sent by:openjfx-dev-boun...@openjdk.java.net



The way it works in 8.0 is that there is a cache of loaded stylesheets. 
When a scene or parent adds a stylesheet, the stylesheet is added to the 
cache. Any other scene or parent that uses the same stylesheet will get 
the one from cache. If a scene or parent later removes the stylesheet, the 
stylesheet is removed from the cache and the css style cache for any scene 
or parent that referenced that stylesheet is cleared (since the set of 
styles may have changed). Any scene or parent that referenced the now 
removed stylesheet is told to reapply its styles. Since the stylesheet is 
no longer in cache, it will be re-parsed (or reloaded if there is a binary 
version of the stylesheet) when it is called for by a scene or parent.

The way it worked in 2.x was an abomination.

On Dec 10, 2013, at 10:30 AM, Werner Lehmann 
 wrote:

> Interesting. Assuming the stylesheets are still cached, how would it 
know when to reload and not use the cached sheet? Or has sheet processing 
been optimized so much that caching is not necessary anymore...
> 
> On 10.12.2013 16:15, Tom Schindl wrote:
>> No on FX8 you need to remove and readd them! So the only thing 
different
>> is that you omit the reload-call on FX8.




 
NOTICE from Ab Initio: This email (including any attachments) may contain 
information that is subject to confidentiality obligations or is legally 
privileged, and sender does not waive confidentiality or privilege. If 
received in error, please notify the sender, delete this email, and make 
no further use, disclosure, or distribution. 

b119 layout issues

[Scott Palmer]

I'm seeing very significant layout issues in b119.
Content is rendering outside of it's parent container when it shouldn't be.
The parent should be re-sizing to accomodate the content, but it isn't, or
it is resizing based on an old size of the child content.

Borders are not painting properly when a component resizes. Sometimes the
border remains at the old, larger, size while the background and content is
painted at the newer smaller size.

I have a feeling it is going to take some effort to make a reproducible
test case.  Are there known layout issues with b119?


Scott

Review request: RT-29816,Custom cursor lost over ComboBox options

[Martin Sladecek]

Hi Kevin,
please review: https://javafx-jira.kenai.com/browse/RT-29816
webrev: http://cr.openjdk.java.net/~msladecek/rt-29816/webrev.00/

Thanks,
-Martin

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

[Robert Krüger]

Amen and +1.

On Tue, Dec 10, 2013 at 9:11 PM, Stephen F Northover
 wrote:
> As I said before, it would be up to the application.  If it was critical
> that your application do something like embed Excel, then it could live with
> the limitations.  Perhaps you work in a company where you have a custom
> native control that you are already embedding in Swing and you want to
> migrate to FX.  These sorts of applications could live with the limitations.
>
> Steve
>
> On 2013-12-10 3:03 PM, Felix Bembrick wrote:
>>
>> Do you think it's either feasible or viable to the extent that a
>> successful implementation would not have the limitations such as lack of
>> transparency or be limited by the inability to apply Node transforms and
>> functionality to native controls?  I mean, such a large undertaking would
>> only made sense if the end result gave us something we don't have now and
>> that it worked well.
>>
>> Felix
>>
>>
>>
>> On 11 December 2013 06:57, Stephen F Northover
>> mailto:steve.x.northo...@oracle.com>> wrote:
>>
>> I was very interesting in heavyweight integration a while back but
>> could not get anyone very enthusiastic about it.
>>
>> Steve
>>
>>
>> On 2013-12-10 1:35 PM, Felix Bembrick wrote:
>>>
>>> Stephen, why do you refer to this discussion as "academic"?
>>>
>>> Felix
>>>
>>>
>>>
>>> On 11 December 2013 05:20, Stephen F Northover
>>> >> > wrote:
>>>
>>> Yes, if it helps an application ship using the components and
>>> technology they need to make their product successful.  In
>>> any case, this discussion is academic.
>>>
>>> Steve
>>>
>>>
>>> On 2013-12-10 12:25 PM, Anthony Petrov wrote:
>>>
>>> We have implemented HW/LW components mixing for AWT/Swing
>>> in the past [1]. However, the feature is very limited (no
>>> transparency support, etc.), and the limitations come
>>> from native system capabilities that can't be worked
>>> around easily.
>>>
>>> Do we really want something limited like this in FX?
>>>
>>> [1]
>>>
>>> http://www.oracle.com/technetwork/articles/java/mixing-components-433992.html
>>>
>>> -- best regards,
>>> Anthony
>>>
>>> On 12/10/2013 06:14 AM, Stephen F Northover wrote:
>>>
>>> At one point,  I was very interested in seeing this
>>> happen but there
>>> wasn't the band width and resources.
>>>
>>> Steve
>>>
>>> On 2013-12-09 1:00 PM, Felix Bembrick wrote:
>>>
>>> What can we expect from the JavaFX team in this
>>> regard in the future?
>>> I know we have talked about mixing lightweight
>>> and heavyweight
>>> controls in the same context but is it going to
>>> happen? Is this
>>> planned for JFX9 perhaps? Is it *really* even
>>> feasible?
>>>
>>> On 10 Dec 2013, at 4:55, Stephen F Northover
>>> >> > wrote:
>>>
>>> Today, you can only exercise the choice by
>>> writing native code and
>>> you face heavyweight / lightweight issues
>>> depending on the platform
>>> and API.
>>>
>>> Steve
>>>
>>> On 2013-12-09 12:31 PM, Felix Bembrick wrote:
>>> Stephen, I thoroughly agree that JavaFX
>>> is by far the best choice
>>> for non-native apps/widgets which is
>>> precisely my point. They are
>>> the kind of apps perfect for using JavaFX.
>>>
>>> But you refer to giving people the choice
>>> to go native where
>>> appropriate. How can I exercise that
>>> choice? Where is the support
>>> for native widgets in JavaFX?
>>>
>>> And isn't the real Holy Grail being able
>>> to mix native and
>>> non-native widgets in the same app with
>>> all features of Node being
>>> available to every widget, with all the
>>> effects and transforms, all
>>> the CSS/styling and with all the performance?
>>>
>>> Could JavaFX ever be such a toolkit?
>>>
>>> On 10 Dec 2013, at 2:24, Stephen F
>>>