Review request: RT-35783,ScrollPane is not refreshing its contents

[Martin Sladecek]

Jonathan, Jim,

please review:

https://javafx-jira.kenai.com/browse/RT-35783
http://cr.openjdk.java.net/~msladecek/rt-35783/webrev.00/

Thanks,
-Martin

Re: Layout issue

[John Hendrikx]

I've tried to create a simple test application in 
https://javafx-jira.kenai.com/browse/RT-35830.


It is still fairly long, but it shows the problem right from the start 
when the Stage pops up.


Thanks :)
--John

On 11/02/2014 20:41, Jonathan Giles wrote:

If you can create a simple test application it would be great if you
can log this as a Jira issue so that we can take a proper look into
this for you.

Thanks,
-- Jonathan

On Wednesday, 12 February 2014 5:50:15 a.m., John Hendrikx wrote:

 From an earlier posting on this list, I came to understand that in
JavaFX 8 it is no longer allowed to modify the children list in
layoutChildren, and that such modifications may need to be moved to
the computerPref* methods.

However, I get a different odd issue, and I'm wondering exactly what
is allowed and what isn't when it comes to layout (any documentation
on this?)

What's happening is the following:

I got a (subclass of) BorderPane, at the top I have a tab-like control
(let's call it a FilterControl).  At the center I got a TreeView.

When the BorderPane gets laid out, I set up the content for both the
TreeView and the FilterControl.  I do this in layoutChildren or in
computerPref* of the BorderPane -- it makes no difference.  Setting up
the content for the FilterControl involves changing its children
list.  The TreeView probably will do the same (adding/removing Cells
as needed).

Now, I'm seeing layout issues.  The BorderPane for example is often
putting the TreeView right on top of the FilterControl (stuff is
transparent, so I can see it).  With other attempts, the FilterControl
is not visible at all (zero height).  Forcing an update (by changing
focus) usually clears up the issue and the FilterControl will take its
rightful spot and force the TreeView to be a little less high.

I'm thinking this is somekind of issue with layout and that I'm
approaching this wrong causing the layout problems.  However, I don't
quite understand what I'm possibly doing wrong -- modifying the
children of the Top node of the BorderPane during BorderPane's own
computePref/layoutChildren call should be perfectly fine right?

Any help appreciated!

--John

Re: Layout issue

[John Hendrikx]

On 11/02/2014 21:09, Martin Sladecek wrote:
The rule of thumb in case you modify content during the layout is that 
content should depend on layout pane size, not the other way around. 
It means that changing the content won't modify the min/pref/max size 
of the pane as that would trigger another layout pass (possibly 
falling into a loop).


BorderPane
  +- (TOP) Filter (subclass of FlowPane)
  +- (CENTER) TreeView

I modify the content during the compute* method of the BorderPane.  For 
TreeView I change the root; for the Filter (FlowPane) I add/remove children.


For some reason that seems to be the "wrong" time to do it, despite the 
fact that this happens almost as the first thing during the layout 
process.  LayoutChildren will get called later on BorderPane, and no 
more changes were made, and the layout is incorrect.  Then when the 
focus changes, the compute* methods get called again (but I change 
nothing since everything is valid still) and layoutChildren gets called 
again on BorderPane... and then everything looks correct.


This is why it's not recommended to change children during the layout, 
as default computation of min/pref/max size depends on the children. 
But if you modify compute* methods and return something that is not 
dependent on the children, you can safely modify them while doing the 
layout.


So, e.g. your filter control might return pref size that is approx. 
for 2-3 "tabs" (or whatnot). Since BorderPane resizes top to the full 
width, you would always get the maximum width you can get. Based on 
the assigned width, you can then compute the layout and add as much 
tabs as you can. Since that would not change the pref width, the 
layout is done.
It is actually a FlowPane -- I'd like it to accomodate the tabs as well 
as possible, and even add an extra row if they don't all fit.  Since I 
donot myself override its compute* methods, I didn't think the issue 
might be in that area (see the Filter class included in the JIRA I 
created -- it's really simple).
Anyway, as Jonathan already noted, a JIRA issue with some sample would 
be great.

Yes, I just did, RT-35830 has a nice sample.

Thanks for giving some more insight in the layout process.

--John


Thanks,
-Martin

On 02/11/2014 05:50 PM, John Hendrikx wrote:
From an earlier posting on this list, I came to understand that in 
JavaFX 8 it is no longer allowed to modify the children list in 
layoutChildren, and that such modifications may need to be moved to 
the computerPref* methods.


However, I get a different odd issue, and I'm wondering exactly what 
is allowed and what isn't when it comes to layout (any documentation 
on this?)


What's happening is the following:

I got a (subclass of) BorderPane, at the top I have a tab-like 
control (let's call it a FilterControl).  At the center I got a 
TreeView.


When the BorderPane gets laid out, I set up the content for both the 
TreeView and the FilterControl.  I do this in layoutChildren or in 
computerPref* of the BorderPane -- it makes no difference. Setting up 
the content for the FilterControl involves changing its children 
list.  The TreeView probably will do the same (adding/removing Cells 
as needed).


Now, I'm seeing layout issues.  The BorderPane for example is often 
putting the TreeView right on top of the FilterControl (stuff is 
transparent, so I can see it).  With other attempts, the 
FilterControl is not visible at all (zero height).  Forcing an update 
(by changing focus) usually clears up the issue and the FilterControl 
will take its rightful spot and force the TreeView to be a little 
less high.


I'm thinking this is somekind of issue with layout and that I'm 
approaching this wrong causing the layout problems.  However, I don't 
quite understand what I'm possibly doing wrong -- modifying the 
children of the Top node of the BorderPane during BorderPane's own 
computePref/layoutChildren call should be perfectly fine right?


Any help appreciated!

--John

Re: Layout issue

[Tomas Mikula]

Hi John,

I'm replying to your question from JIRA:

> Is there perhaps a better place to hook into when you want to have a
> chance to update the layout as a result of deferred property changes?

I took your example and modified it:
https://gist.github.com/TomasMikula/6c5d97edc51ec8fa3d9e

Perhaps look at the diff to see the changes I made:
https://gist.github.com/TomasMikula/6c5d97edc51ec8fa3d9e/revisions

Advantages of this solution:
  (+) no calls requestLayout() or applyCss();
  (+) no need to override layoutChildren() or compute*() methods.

Disadvantage:
  (-) adds a dependency on the ReactFX library
(-) which requires JDK8


The main idea of this solution is this:
  1. you have an observable boolean value (beingUpdated in the
example) that you set to true while changes to you TreeListPane are
being performed and set to false when you are done with changes.
  2. the changes you perform may mark the layout as invalid
(treeInvalidations.push(null); in the example).
  3. whenever updating finishes (beingUpdated changes to false), you
do the layout (buildTree()), but only if the layout has been
invalidated.
buildTreeImpulse = emit(treeInvalidations).on(beingUpdated.offs());
buildTreeImpulse.subscribe(impulse -> buildTree());

You could recreate this pattern without ReactFX, I just find it
convenient to use event streams for the job.

Best,
Tomas

On Wed, Feb 12, 2014 at 11:34 AM, John Hendrikx  wrote:
> On 11/02/2014 21:09, Martin Sladecek wrote:
>>
>> The rule of thumb in case you modify content during the layout is that
>> content should depend on layout pane size, not the other way around. It
>> means that changing the content won't modify the min/pref/max size of the
>> pane as that would trigger another layout pass (possibly falling into a
>> loop).
>
>
> BorderPane
>   +- (TOP) Filter (subclass of FlowPane)
>   +- (CENTER) TreeView
>
> I modify the content during the compute* method of the BorderPane.  For
> TreeView I change the root; for the Filter (FlowPane) I add/remove children.
>
> For some reason that seems to be the "wrong" time to do it, despite the fact
> that this happens almost as the first thing during the layout process.
> LayoutChildren will get called later on BorderPane, and no more changes were
> made, and the layout is incorrect.  Then when the focus changes, the
> compute* methods get called again (but I change nothing since everything is
> valid still) and layoutChildren gets called again on BorderPane... and then
> everything looks correct.
>
>> This is why it's not recommended to change children during the layout, as
>> default computation of min/pref/max size depends on the children. But if you
>> modify compute* methods and return something that is not dependent on the
>> children, you can safely modify them while doing the layout.
>>
>> So, e.g. your filter control might return pref size that is approx. for
>> 2-3 "tabs" (or whatnot). Since BorderPane resizes top to the full width, you
>> would always get the maximum width you can get. Based on the assigned width,
>> you can then compute the layout and add as much tabs as you can. Since that
>> would not change the pref width, the layout is done.
>
> It is actually a FlowPane -- I'd like it to accomodate the tabs as well as
> possible, and even add an extra row if they don't all fit.  Since I donot
> myself override its compute* methods, I didn't think the issue might be in
> that area (see the Filter class included in the JIRA I created -- it's
> really simple).
>>
>> Anyway, as Jonathan already noted, a JIRA issue with some sample would be
>> great.
>
> Yes, I just did, RT-35830 has a nice sample.
>
> Thanks for giving some more insight in the layout process.
>
> --John
>>
>>
>> Thanks,
>> -Martin
>>
>>
>> On 02/11/2014 05:50 PM, John Hendrikx wrote:
>>>
>>> From an earlier posting on this list, I came to understand that in JavaFX
>>> 8 it is no longer allowed to modify the children list in layoutChildren, and
>>> that such modifications may need to be moved to the computerPref* methods.
>>>
>>> However, I get a different odd issue, and I'm wondering exactly what is
>>> allowed and what isn't when it comes to layout (any documentation on this?)
>>>
>>> What's happening is the following:
>>>
>>> I got a (subclass of) BorderPane, at the top I have a tab-like control
>>> (let's call it a FilterControl).  At the center I got a TreeView.
>>>
>>> When the BorderPane gets laid out, I set up the content for both the
>>> TreeView and the FilterControl.  I do this in layoutChildren or in
>>> computerPref* of the BorderPane -- it makes no difference. Setting up the
>>> content for the FilterControl involves changing its children list.  The
>>> TreeView probably will do the same (adding/removing Cells as needed).
>>>
>>> Now, I'm seeing layout issues.  The BorderPane for example is often
>>> putting the TreeView right on top of the FilterControl (stuff is
>>> transparent, so I can see it).  With other attempts, the Filte

hg: openjfx/8u-dev/rt: [TOYS] giving FXSlideShow a nbproject

[hang . vo]

Changeset: c8fb432d8a42
Author:ddhill
Date:  2014-02-12 11:21 -0500
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c8fb432d8a42

[TOYS] giving FXSlideShow a nbproject

+ apps/toys/FXSlideShow/build.xml
+ apps/toys/FXSlideShow/nbproject/build-impl.xml
+ apps/toys/FXSlideShow/nbproject/genfiles.properties
+ apps/toys/FXSlideShow/nbproject/project.properties
+ apps/toys/FXSlideShow/nbproject/project.xml

hg: openjfx/8u-dev/rt: RT-35629: IDE Tooling for JavaFX Packager

[hang . vo]

Changeset: 24be04fee37b
Author:shemnon
Date:  2014-02-12 13:56 -0700
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/24be04fee37b

RT-35629: IDE Tooling for JavaFX Packager

* Fix Mac Tests by using the TestPackager class for test bundles
* Don't require jfxrt.jar to be in the Mac JDK

! build.gradle
! 
modules/fxpackager/src/main/java/com/sun/javafx/tools/packager/bundlers/MacAppBundler.java
! modules/fxpackager/src/test/java/com/oracle/bundlers/BundlersTest.java
! 
modules/fxpackager/src/test/java/com/oracle/bundlers/linux/LinuxAppBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/bundlers/linux/LinuxDebBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/bundlers/linux/LinuxRpmBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/bundlers/mac/MacAppBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/bundlers/mac/MacDMGBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/bundlers/mac/MacPKGBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/bundlers/windows/WinAppBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/bundlers/windows/WinEXEBundlerTest.java
! 
modules/fxpackager/src/test/java/com/oracle/bundlers/windows/WinMSIBundlerTest.java
- modules/fxpackager/src/test/java/hello/HelloRectangle.java
! modules/fxpackager/src/test/resources/com/sun/javafx/tools/ant/bundleargs.xml

TestFX and popup

[Tom Eugelink]

I'm using a Popup and need TestFX to click some buttons that are in the popup, 
but the nodes are not found. How is a Popup hooked into an existing node tree?

The code in a.o. PopupWindow seems to only reference one way; from the popup 
towards the owner, but not the other way. Only if the owning window is a 
PopupWindow is the popup added to its children. But if the owning window is a 
simple stage, then I see no way to get to the Popup.

What I (and TestFX) would need is some way to bridge from the stage over to the 
popup.

Failure to find any font (probably on Embedded)

[David Hill]

I am chasing a edge case that probably only happens in certain Embedded 
configurations. If we don't find *any* fonts, then we quietly fail and blame it 
on CSS :-)

I say blame it on CSS because the resulting hard failure is:
Exception in thread "JavaFX Application Thread" java.lang.NoClassDefFoundError: 
Could not initialize class javafx.scene.CssStyleHelper
This is because CSS needs a font for various calculations.

With Embedded, if libfontconfig is not present (or improperly configured) you 
will not find any fonts.

I would like thoughts on my putting a more informative error message out, and 
making zero fonts an earlier hard failure.

What I would really like to do is to be able to put a URL to a Fonts wiki page 
(like: https://wiki.openjdk.java.net/display/OpenJFX/Font+Setup) but not sure 
how well that would stand up to the test of time.

The code point in FontConfigManager is:

if (anyFont == null) {
if (debugFonts) {
System.err.println("Fontconfig returned no fonts at all.");
}
fontConfigFailed = true;
return;

--
David Hill 
Java Embedded Development

"A common mistake that people make when trying to design something completely 
foolproof is to underestimate the ingenuity of complete fools."
-- Douglas Adams

Re: Failure to find any font (probably on Embedded)

[Kevin Rushforth]

A more informative message and an earlier detection both sound good. Not 
sure about the pointer to the Wiki page, though. We haven't done that in 
the past that I am aware of. If we do want to go down that path, I would 
suggest a pointer to a single, "well-known" support page that could 
describe various end-user configuration issues that we might want to 
document.


-- Kevin


David Hill wrote:


I am chasing a edge case that probably only happens in certain 
Embedded configurations. If we don't find *any* fonts, then we quietly 
fail and blame it on CSS :-)


I say blame it on CSS because the resulting hard failure is:
Exception in thread "JavaFX Application Thread" 
java.lang.NoClassDefFoundError: Could not initialize class 
javafx.scene.CssStyleHelper

This is because CSS needs a font for various calculations.

With Embedded, if libfontconfig is not present (or improperly 
configured) you will not find any fonts.


I would like thoughts on my putting a more informative error message 
out, and making zero fonts an earlier hard failure.


What I would really like to do is to be able to put a URL to a Fonts 
wiki page (like: 
https://wiki.openjdk.java.net/display/OpenJFX/Font+Setup) but not sure 
how well that would stand up to the test of time.


The code point in FontConfigManager is:

if (anyFont == null) {
if (debugFonts) {
System.err.println("Fontconfig returned no fonts at 
all.");

}
fontConfigFailed = true;
return;

Re: Failure to find any font (probably on Embedded)

[Stephen F Northover]

Embedding URL's in code ... a recipe for stale URL's.  I suppose that we 
put URL's in JavaDoc though.


Steve

On 2014-02-12 1:53 PM, Kevin Rushforth wrote:
A more informative message and an earlier detection both sound good. 
Not sure about the pointer to the Wiki page, though. We haven't done 
that in the past that I am aware of. If we do want to go down that 
path, I would suggest a pointer to a single, "well-known" support page 
that could describe various end-user configuration issues that we 
might want to document.


-- Kevin


David Hill wrote:


I am chasing a edge case that probably only happens in certain 
Embedded configurations. If we don't find *any* fonts, then we 
quietly fail and blame it on CSS :-)


I say blame it on CSS because the resulting hard failure is:
Exception in thread "JavaFX Application Thread" 
java.lang.NoClassDefFoundError: Could not initialize class 
javafx.scene.CssStyleHelper

This is because CSS needs a font for various calculations.

With Embedded, if libfontconfig is not present (or improperly 
configured) you will not find any fonts.


I would like thoughts on my putting a more informative error message 
out, and making zero fonts an earlier hard failure.


What I would really like to do is to be able to put a URL to a Fonts 
wiki page (like: 
https://wiki.openjdk.java.net/display/OpenJFX/Font+Setup) but not 
sure how well that would stand up to the test of time.


The code point in FontConfigManager is:

if (anyFont == null) {
if (debugFonts) {
System.err.println("Fontconfig returned no fonts at 
all.");

}
fontConfigFailed = true;
return;

Re: Launching JavaFX apps

[Florian Brunner]

Could someone elaborate on this?

Thanks!

-Florian

Am Samstag, 18. Januar 2014, 13.27:07 schrieb Florian Brunner:
> Hi Kevin,
> 
> Thanks for this clarifiacation! I'm also interested in this kind of 
> information as I'm in the process of upgrading Drombler FX to JavaFX 8 and 
> Drombler FX comes with a custom Maven Plugin, which makes sure the 
> application can start.
> 
> Another related question:
> 
> While the Ant task for JavaFX 2.x added the following Manifest entries:
> 
> JavaFX-Version: 2.2
> JavaFX-Application-Class: myPackage.MyApplication
> JavaFX-Class-Path: 
> Main-Class: com/javafx/main/Main
> 
> 
> the Ant task for JavaFX 8 added the following Manifest entries:
> JavaFX-Version: 2.2
> Class-Path: 
> Main-Class: myPackage.MyApplication
> 
> So it seems "JavaFX-Application-Class" is not used anymore if one doesn't use 
> com.javafx.main.Main to start the JavaFX application, and "JavaFX-Class-Path" 
> has been replaced with the standard "Class-Path" entry.
> 
> The "JavaFX-Version" seems still to be needed, however. For what is it used? 
> An why is this version set to "2.2" for JavaFX 8 applications? Shouldn't it 
> be "8.0" or something?
> Can I get this version from somewhere? Either the JavaFX API or from the 
> ant-javafx.jar?
> 
> -Florian
> 
> Am Mittwoch, 8. Januar 2014, 06.45:36 schrieb Kevin Rushforth:
> > Hi Scott,
> > 
> > The Java 8 launcher has been modified to recognize JavaFX applications 
> > -- that is, classes that extend javafx.application.Application -- and 
> > launch them directly by calling into the JavaFX launcher code. See 
> > JDK-8001533 . This is 
> > why the com.javafx.main.Main class is no longer needed.
> > 
> > Somewhat independent of this, for standalone applications (but not 
> > applets or web start applications) the JavaFX launcher code will now 
> > call the main() method if it is present (see RT-28755 
> > ), but will still happily 
> > launch the application if it isn't. So the main() method is still 
> > optional. If present, it must call Application.launch() in order to 
> > launch the application.
> > 
> > So yes, it does seem that Netbeans should modify the wording of their 
> > javadoc comment for the main() method of a JavaFX application.
> > 
> > -- Kevin
> > 
> > 
> > Scott Palmer wrote:
> > > Based on the discussion I saw in the comments for RT-34236 I discovered
> > > that using com.javafx.main.Main is not the way JavaFX 8 is supposed to
> > > work. There are comments that read, "...making sure their Application 
> > > class
> > > has a main that calls launcher(String[] args)."
> > >
> > > This seems to imply that a main method is now required in the Application
> > > class when writing apps for JavaFX 8.
> > >
> > > Is this correct?
> > >
> > > If so. Somebody should tell NetBeans to stop injecting this comment in the
> > > generated application class for JavaFX projects:
> > > /**
> > >  * The main() method is ignored in correctly deployed JavaFX application.
> > >  * main() serves only as fallback in case the application can not be
> > >  * launched through deployment artifacts, e.g., in IDEs with limited FX
> > >  * support. NetBeans ignores main().
> > >  *
> > >  * @param args the command line arguments
> > >  */
> > >
> > > Are the changes to the launching of JavaFX apps docuemtned somewhere?  Is
> > > using javafxpackager or the ant task the *only* supported way of creating
> > > JavaFX applications?  I'm currently using my own stub that runs on Java 7
> > > and adds the jfxrt.jar to the classpath if required and then calls the
> > > launch method on the Applicaiton class.
> > >
> > > Regards,
> > >
> > > Scott
> > >   
> 

[8u] review RT-35778 - duplicate dtjava.js files

[Danno Ferrin]

Kevin, Thomas, please review:

webrev: http://cr.openjdk.java.net/~shemnon/RT-35778/webrev.00/
jira: https://javafx-jira.kenai.com/browse/RT-35778

thanks,
—Danno

Re: Failure to find any font (probably on Embedded)

[Daniel Blaukopf]

Unless someone has removed font files from the Java directory tree - in which 
case all bets are off - this won’t happen with the JRE or JDK for any platform. 
It will only happen with Java SE Embedded Compact Profiles. So referring them 
to “the release notes for Java SE Embedded” seems reasonable. We can verify 
with the version system properties that this is actually SE Embedded before 
showing that message.
Daniel

On Feb 12, 2014, at 1:53 PM, Kevin Rushforth  wrote:

> A more informative message and an earlier detection both sound good. Not sure 
> about the pointer to the Wiki page, though. We haven't done that in the past 
> that I am aware of. If we do want to go down that path, I would suggest a 
> pointer to a single, "well-known" support page that could describe various 
> end-user configuration issues that we might want to document.
> 
> -- Kevin
> 
> 
> David Hill wrote:
>> 
>> I am chasing a edge case that probably only happens in certain Embedded 
>> configurations. If we don't find *any* fonts, then we quietly fail and blame 
>> it on CSS :-)
>> 
>> I say blame it on CSS because the resulting hard failure is:
>> Exception in thread "JavaFX Application Thread" 
>> java.lang.NoClassDefFoundError: Could not initialize class 
>> javafx.scene.CssStyleHelper
>> This is because CSS needs a font for various calculations.
>> 
>> With Embedded, if libfontconfig is not present (or improperly configured) 
>> you will not find any fonts.
>> 
>> I would like thoughts on my putting a more informative error message out, 
>> and making zero fonts an earlier hard failure.
>> 
>> What I would really like to do is to be able to put a URL to a Fonts wiki 
>> page (like: https://wiki.openjdk.java.net/display/OpenJFX/Font+Setup) but 
>> not sure how well that would stand up to the test of time.
>> 
>> The code point in FontConfigManager is:
>> 
>>if (anyFont == null) {
>>if (debugFonts) {
>>System.err.println("Fontconfig returned no fonts at all.");
>>}
>>fontConfigFailed = true;
>>return;
>> 

Re: Failure to find any font (probably on Embedded)

[Kevin Rushforth]

> Embedding URL's in code ... a recipe for stale URL's.

Yeah, that's why I'm not sure I like it...

-- Kevin


Stephen F Northover wrote:
Embedding URL's in code ... a recipe for stale URL's.  I suppose that 
we put URL's in JavaDoc though.


Steve

On 2014-02-12 1:53 PM, Kevin Rushforth wrote:
A more informative message and an earlier detection both sound good. 
Not sure about the pointer to the Wiki page, though. We haven't done 
that in the past that I am aware of. If we do want to go down that 
path, I would suggest a pointer to a single, "well-known" support 
page that could describe various end-user configuration issues that 
we might want to document.


-- Kevin


David Hill wrote:


I am chasing a edge case that probably only happens in certain 
Embedded configurations. If we don't find *any* fonts, then we 
quietly fail and blame it on CSS :-)


I say blame it on CSS because the resulting hard failure is:
Exception in thread "JavaFX Application Thread" 
java.lang.NoClassDefFoundError: Could not initialize class 
javafx.scene.CssStyleHelper

This is because CSS needs a font for various calculations.

With Embedded, if libfontconfig is not present (or improperly 
configured) you will not find any fonts.


I would like thoughts on my putting a more informative error message 
out, and making zero fonts an earlier hard failure.


What I would really like to do is to be able to put a URL to a Fonts 
wiki page (like: 
https://wiki.openjdk.java.net/display/OpenJFX/Font+Setup) but not 
sure how well that would stand up to the test of time.


The code point in FontConfigManager is:

if (anyFont == null) {
if (debugFonts) {
System.err.println("Fontconfig returned no fonts at 
all.");

}
fontConfigFailed = true;
return;

Re: Launching JavaFX apps

[David DeHaven]

Use of JavaFX-Class-Path is supported but highly discouraged as it leads to 
ClassLoader juggling, it was required when there was no SE launcher support for 
JavaFX. It is only supported for backward compatibility, new applications 
should NOT use it.

Either JavaFX-Application-Class or Main-Class can be used to specify the main 
entry point for the application. If both are present, then 
JavaFX-Application-Class will be used. Whichever is used, the presence of main 
is not required if it's a JavaFX application as the entire launch process is 
handed over to the JavaFX launcher impl. As with JavaFX-Class-Path, use of 
JavaFX-Application-Class is now discouraged but not quite as strongly.

The SE launcher ignores JavaFX-Version. I don't think it's used any more in 
JavaFX either, the only mention of it is "// If we ever need to check 
JavaFX-Version, do that here..." in LauncherImpl.java.


History:
JDK-8001533 allowed Main-Class to specify a JavaFX application as the main 
class, but it ignored JavaFX-Application-Class (among others)
JDK-8004547 fixed the above issue, the SE launcher now checks for J-A-C in the 
manifest and uses it as the Main-Class if present

-DrD-

On Feb 12, 2014, at 2:07 PM, Florian Brunner  wrote:

> Could someone elaborate on this?
> 
> Thanks!
> 
> -Florian
> 
> Am Samstag, 18. Januar 2014, 13.27:07 schrieb Florian Brunner:
>> Hi Kevin,
>> 
>> Thanks for this clarifiacation! I'm also interested in this kind of 
>> information as I'm in the process of upgrading Drombler FX to JavaFX 8 and 
>> Drombler FX comes with a custom Maven Plugin, which makes sure the 
>> application can start.
>> 
>> Another related question:
>> 
>> While the Ant task for JavaFX 2.x added the following Manifest entries:
>> 
>> JavaFX-Version: 2.2
>> JavaFX-Application-Class: myPackage.MyApplication
>> JavaFX-Class-Path: 
>> Main-Class: com/javafx/main/Main
>> 
>> 
>> the Ant task for JavaFX 8 added the following Manifest entries:
>> JavaFX-Version: 2.2
>> Class-Path: 
>> Main-Class: myPackage.MyApplication
>> 
>> So it seems "JavaFX-Application-Class" is not used anymore if one doesn't 
>> use com.javafx.main.Main to start the JavaFX application, and 
>> "JavaFX-Class-Path" has been replaced with the standard "Class-Path" entry.
>> 
>> The "JavaFX-Version" seems still to be needed, however. For what is it used? 
>> An why is this version set to "2.2" for JavaFX 8 applications? Shouldn't it 
>> be "8.0" or something?
>> Can I get this version from somewhere? Either the JavaFX API or from the 
>> ant-javafx.jar?
>> 
>> -Florian
>> 
>> Am Mittwoch, 8. Januar 2014, 06.45:36 schrieb Kevin Rushforth:
>>> Hi Scott,
>>> 
>>> The Java 8 launcher has been modified to recognize JavaFX applications 
>>> -- that is, classes that extend javafx.application.Application -- and 
>>> launch them directly by calling into the JavaFX launcher code. See 
>>> JDK-8001533 . This is 
>>> why the com.javafx.main.Main class is no longer needed.
>>> 
>>> Somewhat independent of this, for standalone applications (but not 
>>> applets or web start applications) the JavaFX launcher code will now 
>>> call the main() method if it is present (see RT-28755 
>>> ), but will still happily 
>>> launch the application if it isn't. So the main() method is still 
>>> optional. If present, it must call Application.launch() in order to 
>>> launch the application.
>>> 
>>> So yes, it does seem that Netbeans should modify the wording of their 
>>> javadoc comment for the main() method of a JavaFX application.
>>> 
>>> -- Kevin
>>> 
>>> 
>>> Scott Palmer wrote:
 Based on the discussion I saw in the comments for RT-34236 I discovered
 that using com.javafx.main.Main is not the way JavaFX 8 is supposed to
 work. There are comments that read, "...making sure their Application class
 has a main that calls launcher(String[] args)."
 
 This seems to imply that a main method is now required in the Application
 class when writing apps for JavaFX 8.
 
 Is this correct?
 
 If so. Somebody should tell NetBeans to stop injecting this comment in the
 generated application class for JavaFX projects:
 /**
 * The main() method is ignored in correctly deployed JavaFX application.
 * main() serves only as fallback in case the application can not be
 * launched through deployment artifacts, e.g., in IDEs with limited FX
 * support. NetBeans ignores main().
 *
 * @param args the command line arguments
 */
 
 Are the changes to the launching of JavaFX apps docuemtned somewhere?  Is
 using javafxpackager or the ant task the *only* supported way of creating
 JavaFX applications?  I'm currently using my own stub that runs on Java 7
 and adds the jfxrt.jar to the classpath if required and then calls the
 launch method on the Applicaiton class.
 
 Regards,
 
 Sco

hg: openjfx/8u-dev/rt: 3 new changesets

[hang . vo]

Changeset: 8f4ded00fb69
Author:Martin Sladecek 
Date:  2014-02-13 08:20 +0100
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8f4ded00fb69

RT-35783 ScrollPane is not refreshing its contents
Reviewed by: jgiles, flar

! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java
! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java

Changeset: 75de1d53cbb1
Author:Martin Sladecek 
Date:  2014-02-13 08:23 +0100
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/75de1d53cbb1

RT-21664 TableView does not follow a finger when Scroll gesture direction not 
vertical or horizontal
Reviewed by: jgiles

! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java

Changeset: cf0dc4a50687
Author:Martin Sladecek 
Date:  2014-02-13 08:25 +0100
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/cf0dc4a50687

RT-23406 [ScrollBar, touch] Dragging scrollbar from the track on touchscreen 
causes flickering
Reviewed by: jgiles

! 
modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/ScrollBarBehavior.java
! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollBarSkin.java

hg: openjfx/8u-dev/rt: RT-33833 [2d traversal] Nonmousetraversal functionality does not work in expected way on ListView when moving right

[hang . vo]

Changeset: 4cd4ea8e412d
Author:Martin Sladecek 
Date:  2014-02-13 08:16 +0100
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/4cd4ea8e412d

RT-33833 [2d traversal] Nonmousetraversal functionality does not work in 
expected way on ListView when moving right
Reviewed by: jgiles

! 
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ListViewSkin.java