Re: @import in CSS

I suspected as much, and that really is a shame because it cripples the declaration based behavior. The parser could of course declare any property it does not know at the time of parsing as needed to be looked up. Ultimately I cannot move the colorschemes into a separate file, so they are

javapackager

It was indicated that this might be the list for questions on javapackager. This could very well just be that some OS X customization hasn’t been done yet for the java 9 early access but a javapackager application gets the following error if I replace the default Java 8 jdk with the java 9 and

Re: @import in CSS

Hm. That would mean this should work, but it does not. So instead of moving the lines 216 and up to a separate file, I moved them to the front, but the colorschemes are not working then. The lines must be after the first (.SimpleMetroArcGauge) block. I don't understand why this matters, if it

Re: Private APIs not usable in Java 9?

Right. The specific list of JavaFX internal packages is listed in the JIRA I filed, but if you just grep for 'com.sun' that will hit all of them. -- Kevin David DeHaven wrote: You can see any com.sun.* usage by running jdeps -v some.jar. You'll have to sort it all out manually, but it's all

Private APIs not usable in Java 9?

I just asked about this on the adoption-disc...@openjdk.java.net list and the answer from Martijn Verburg is: --- Hi Chris, I think the strong advice for those using private APIs is to run the jdeps tool to see where they are using APIs that will go away / be moved. I'd then get them to post

Re: Private APIs not usable in Java 9?

On 08.04.2015 23:03, Stefan Fuchs wrote: Anyway I think especially for webstart applications, which have no control over the installed jre should have the possibility to access private apis. I would suggest reading http://openjdk.java.net/jeps/200 , http://openjdk.java.net/jeps/201 ,

Re: Private APIs not usable in Java 9? - behind the scene

Tom Schindl wrote:So to summerize the most lacking API is in the font/text rendering space What I find lacking too, coming from AWT/Swing, is some low-level (for JavaFX) features :- Something like WritableImage.getGraphicsContext() (as we have Image.getGraphics()).- Something like

Re: Private APIs not usable in Java 9?

I guess a good place to start would be to eliminate usage of private APIs from scene builder. I understand that it doesn't seem to be supported any more but it'd be extremely weird and embarrassing for Oracle if the UI builder tool broke on Java 9 given all the work that went into it. On 9 Apr

Re: Private APIs not usable in Java 9?

You can see any com.sun.* usage by running jdeps -v some.jar. You'll have to sort it all out manually, but it's all there. -DrD- I'll second the recommendation to run jdeps on your apps. I note that it doesn't currently flag internal FX packages as internal. I filed the following RFE to

Re: @import in CSS

Yes. The details are in http://www.w3.org/TR/CSS2/cascade.html#cascading-order, but here is the excerpt that matters: if two declarations have the same weight, origin and specificity, the latter specified wins. Declarations in imported style sheets are considered to be before any declarations

Re: Private APIs not usable in Java 9?

For what it is worth, investigations are underway in relation to UI control skins and behaviors. It's too early for anything definitive to announce, but it is not inconceivable that com.sun.javafx.scene.control.skin may become javafx.scene.control.skin, more or less (with a lot of work

Re: @import in CSS

Take -fxx-needle-color (from SimpleMetroArcGauge.css) as an example. Its declaration appears in the .SimpleMetroArcGauge rule and is then used in the -fx-fill declaration of the .needle rule. The CSS parser is pretty dumb. It collects up the property names as it parses and if any of those

[9] post-commit notification: RT-40271 Use application locale setting in WebView language header

JIRA: https://javafx-jira.kenai.com/browse/RT-40271 Changeset: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/ecf20572029f Regards, Anton.

Re: Private APIs not usable in Java 9?

I'll second the recommendation to run jdeps on your apps. I note that it doesn't currently flag internal FX packages as internal. I filed the following RFE to address this: https://bugs.openjdk.java.net/browse/JDK-8077349 -- Kevin Chris Newland wrote: I just asked about this on the

Re: Private APIs not usable in Java 9?

On Wed, Apr 8, 2015 at 11:03 PM, Stefan Fuchs snfu...@gmx.de wrote: But in all artificial restrictions to implement your own workarounds using private apis its another minus on our assessment of the risks involved, when investing in the javafx technology. Others are the diminishing plugin

Re: Private APIs not usable in Java 9?

I guess a good place to start would be to eliminate usage of private APIs from scene builder. Agreed. I noted the needed to fix SceneBuilder in a comment in https://javafx-jira.kenai.com/browse/RT-40184 (wherein I said I would file a new JIRA, but hadn't done that yet). Jonathan has already

Re: Canvas performance on Mac OS

This is important Thanks guys Sent from my iPhone On Apr 8, 2015, at 9:25 AM, Chris Newland cnewl...@chrisnewland.com wrote: Hi Jim, I'll post the verbose prism output from my iMac when I get home. Just tried this on my Linux workstation and the performance gap is the same between

Re: Private APIs not usable in Java 9? - behind the scene

[Re-sending with more line breaks (hopefully - looked fine when sent but most were gone when I received it)] Tom Schindl wrote:So to summerize the most lacking API is in the font/text rendering space What I find lacking too, coming from AWT/Swing, is some low-level (for JavaFX) features : -