Re: Backwards compatibility issue?
the JIRA mentioned is not public - we the e(fx)clipse project are working on such a feature as well for one of our next releases - so if openjfx does provide it we could spend our time on other important improvements! Tom On 31.05.13 19:54, Richard Bair wrote: What's so horrid about css to bss compiling? A) It's broken B) What's the point? Not trying to be unduly critical but is it for some performance gain or something? Surely the load time is minimal. Given that I have a dozen XML config files, a handful of property files and a thousand FXML files that are being loaded by my app it seems like a whole lot of extra complexity and space for bugs to crawl in for no gain. Maybe I'm missing some benefit of this? The benefit is performance. It is much faster to deserialize the binary format than to invoke the parser. And we're talking orders of magnitude here. And don't forget about iOS / Android / PI / Beagle / and friends. We didn't do bss because we thought it was cool, I can promise you that. Neither are we looking at compiling FXML into class files (RT-23527) for the fun of it ;-).
Re: Dumping the rendering process in JavaFX
I've started working on a JavaFX-Scene to FXML dumper but its not yet really useable. Tom On 07.06.13 14:34, Hervé Girod wrote: Hello, We are porting a swing application in JavaFX, and we had various unit tests where we created for testing purposes a dummy Graphics2D which stored the list of its shapes and transformations. This allowed us to perform unit tests for the rendering of some of our graphic components or Look and Feels. We tried to do the same thing in JavaFX by using the swing -JavaFX bridge and forcing a j2d prism rendering. It works, but JavaFX nodes are rendered as images, so it's not the right way to do it ;) Is there a way to dump some kind of list of graphic orders in the current state of JavaFX (2.2 or 8) ? Hervé Sent from my iPhone
Re: [Review request] Make Cell.updateItem(item, empty) public, rather than protected
Hi, I must not (although most of the code out there which specialized Cell kept it protected and hence is broken) and all I did was to point out that this is and will be a breaking changeing. Whether this justifies breaking code is up to the openjfx team, simply saying it does not break compatibility to get some API approved is not the way to go. Tom On 09.07.13 15:17, David Ray wrote: I don't see what the problem is? Why must you reduce the visibility? You wouldn't do that for any other public method you've overridden? That would be clinging to a memory of what the API used to be. I would understand if I had to set my protected method public after updating my jdk - it's necessary to improve things. Why must we suffer for all of time just because some API designer wasn't omniscient in the beginning? Code must evolve or we might as well go back to swing - we're already making a hugely painful and inconvenient investment in time by putting off the next release for over 6 whole months. Frankly, adopters aren't falling out of the sky and we need to protect the future of fx by having sturdy code coming out of the gate. The decisions made now are imminently more crucial than you might think. /end speach Sorry but it was an opportune time... Retiring thumbs, David Sent from my iPhone On Jul 9, 2013, at 12:28 AM, Tom Schindl tom.schi...@bestsolution.at wrote: On 09.07.13 04:10, Jonathan Giles wrote: Hi all, This request is to change the API for Cell.updateItem(T item, boolean empty) from protected to public. Clearly this will not be a breaking change, but it does make the API more public than ideal :-) This is a breaking change. If I subclassed Cell and overloaded it (still leaving it protected) I'll then get a compiler error because I can't reduce visibility in a subclass. Tom
Re: [Review request] Make Cell.updateItem(item, empty) public, rather than protected
Whether this justifies breaking code is up to the openjfx team, simply saying it does not break compatibility to get some API approved is not the way to go. I don't want to imply that Jonathan did this! I know it was an oversight. Tom
Re: [API Review]: Node validation
On 09.07.13 22:59, David Grieve wrote: Since there is already a requestLayout() which defers to the next pulse, what about demandLayout()? then I would go for forceLayout() Tom
Re: JDK 8 for ARM Early Access Releases (with JavaFX)
Hi David Daniel, Is there a version which works on a beagleboard (or beagleboard like hardware) as well? IIRC hard float does not work there. Tom On 10.07.13 18:49, David Hill wrote: On 7/10/13 Jul 10, 10:22 AM, Gerrit Grunwald wrote: I just saw some problems with complex -fx-shape based paths. Hi Gerrit, If you have a test case you can share, I would appreciate a Jira filed :-) Simple test cases make me a happy person. Please add in the description that it is a PI issue so if gets routed to us embedded guys. We have been working through the known issues for the ARM hard float on the PI, and have been getting better over time. And of course our efforts to improve performance on the PI have lead to overall JFX improvements. So feedback, both good and bad is appreciated.
Re: Building sources for jfxrt.jar and missing packages
If you do that, you might be interested that e(fx)clipse by default searches for the fx-sources in a file named javafx-src.zip which is located next to your src.zip and attaches them to the Library-Path-Entry. [...] Is this the correct way to go about it? I also noticed that the jfxrt.jar from the latest JDK1.8 snapshot includes com.sun.media.* packages which are not yet part of OpenJFX (at least I don´t think so, as my modules/media directory is empty). Is there a reason for this? Not opensourced yet IIRC Tom
Re: Building sources for jfxrt.jar and missing packages
Do you already have an idea of the nameing location? Or will it be
part of src.zip?
Tom
On 16.07.13 13:35, Kevin Rushforth wrote:
I´m trying to build a jar containing all sources for jfxrt.jar, so I
can attach it in Eclipse. For this I´ve added the following lines to
the root build.gradle:
...
Is this the correct way to go about it?
This looks like the right approach, yes (although rather than excluding
a list of files, I would just include *.java). Btw, there is a JIRA on
my plate to produce this for the production build -- RT-21415
https://javafx-jira.kenai.com/browse/RT-21415 -- but it was put on
hold, due to the work on the gradle build among other things.
I also noticed that the jfxrt.jar from the latest JDK1.8 snapshot
includes com.sun.media.* packages which are not yet part of OpenJFX
(at least I don´t think so, as my modules/media directory is empty).
Is there a reason for this?
Media has not yet been open-sourced, but that work is in progress.
-- Kevin
Robert Fisher wrote:
Hi everyone,
I´m trying to build a jar containing all sources for jfxrt.jar, so I
can attach it in Eclipse. For this I´ve added the following lines to
the root build.gradle:
build.gradle:
task jfxrtSources()
compileTargets{
...
def jfxrtSourcesTask = task(jfxrtSources$t.capital, type: Jar) {
group = Basic;
description = Creates the jfxrt-sources.jar for the $t.name
target;
archiveName = build/${t.name}-sdk/rt/lib/ext/jfxrt-sources.jar;
includeEmptyDirs = false;
from(modules/base/src/main/java,
modules/builders/src/main/java,
modules/controls/src/main/java,
modules/designTime/src/main/java,
modules/fxml/src/main/java,
modules/fxpackager/src/main/java,
modules/graphics/src/main/java,
modules/web/src/main/java);
if (COMPILE_SWING) from (modules/swing/src/main/java);
if (COMPILE_SWT) from (modules/swt/src/main/java);
exclude(targetProperties.jfxrtJarExcludes);
}
jfxrtSources.dependsOn(jfxrtSourcesTask);
...
}
Is this the correct way to go about it?
I also noticed that the jfxrt.jar from the latest JDK1.8 snapshot
includes com.sun.media.* packages which are not yet part of OpenJFX
(at least I don´t think so, as my modules/media directory is empty).
Is there a reason for this?
Thanks in advance,
Rob
Mit freundlichen Grüßen
Best Regards
Dr. Robert Fisher
TESIS DYNAware
Technische Simulation Dynamischer Systeme GmbH
Baierbrunner Str. 15
D-81379 München
Tel: +49-89-747377-7440
Fax: +49-89-747377-99
http://www.tesis-dynaware.com
robert.fis...@tesis.de
Geschäftsführung / Board of Directors
Dr.-Ing. Cornelius Chucholowski - Dipl. Ing. Christian Zahn
Amtsgericht München, HRB 115649
TESIS DYNAware simulation software is in use at Audi, BMW, Ford,
MAGNA, MAN, VW and elsewhere.
Read more: http://www.tesis-dynaware.com/customers
Re: Can JavaFX do CAD?
On 25.07.13 13:44, Pavel Safrata wrote: Hi Richard, I have a comment to one of your questions: On 24.7.2013 21:06, Richard Bair wrote: - Would we benefit from a full lazy model for properties where we only instantiate them if somebody adds a listener We've done that in javafx.scene.transform.Affine. This is a class representing a general Affine transformation matrix, so it has twelve double properties. I'm probably not able to find the actual numbers we measured back then, but here is what I can remember. We used the 3D music chart JavaOne demo which operated with the matrices incredibly heavily. In this case the properties made a big difference in performance; with all the properties instantiated, even DoubleProperty.get() shone brightly in profiler results. So we introduced the full lazy properties which helped. Then we looked into it a bit more but were not able to create similar condition with any other use-case; the property getter is just a null check and a couple of calls in addition. It seemed that the transform matrices were a special case where some 3D algorithms call the matrix element getters too much, so we've left it at that. Regarding memory requirements of the full lazy properties, let me state the obvious: - if the property is not used at all, we have a reference and a double instead of just a reference (worse unless in bucket) - if getters/setters are called, we still have a reference and a double instead of full instantiated property (better) - if a listener is added, we have instantiated property and a double instead of just the property (slightly worse) So it looks like it would make best sense to introduce this for properties that are often get/set but usually don't have listeners on them. I'm not sure if such set exists and can be identified. If there are really a lot of properties of the same (primitive) type would it make sense to store their primitive values inside arrays instead of single fields? Not sure how arrays preform memory and access. If there are many booleans they could be store inside an short/int/long. Tom
Code style guide lines
Hi, I'm once more doing a clean up pass to get out of the way warnings in the control codebase - RT-31907. Do you guys follow any coding guide lines? Wouldn't it be good if the JavaFX codebase would follow http://openjdk.java.net/guide/codeConventions.html Tom
Re: Code style guide lines
Hi, Well what I'm interested more is things like: * Should a switch always have a default-case? - According to the Java guidelines this should be! * Why are so many things not generified but use the raw types? - It looks like you are all running with raw-type warnings off, which has the effect that you don't even spot APIs who are not generified (and can't even be fixed because it would be an API breakage). * What should be done with fields declared but never used? I think you should also write down the policy when a Simple*Property used? - we discussed that same months ago already Tom On 25.07.13 20:10, Richard Bair wrote: I started a guide on our wiki a while ago: https://wiki.openjdk.java.net/display/OpenJFX/Policies+and+Processes But I only started it I never actually finished it or even asked anybody else what they thought of it :-). In general we follow the standard sun guidelines. We use spaces, not tabs. 4 spaces per indent, 8 for line continuation (usually). Comments should be the standard /* */ or //. We did go non-standard in our use of @Override by putting it on the same line as the method, although it is not consistent. I always do my for loops like: for (int i=0; i10; i++) (Notice the lack of spaces around = and ). This drives Kevin nuts who likes to have spaces around the = and . Probably the best way to go is, as you find things that are suspicious or look wrong, lets bring it up and add it to the wiki and grow the wiki to have all the standards (rather than build up a list ahead of time). The Java code conventions should be seen as the rule book, unless we've explicitly modified it and documented it. Richard On Jul 25, 2013, at 10:39 AM, Tom Schindl tom.schi...@bestsolution.at wrote: Hi, I'm once more doing a clean up pass to get out of the way warnings in the control codebase - RT-31907. Do you guys follow any coding guide lines? Wouldn't it be good if the JavaFX codebase would follow http://openjdk.java.net/guide/codeConventions.html Tom
Re: Code style guide lines
On 25.07.13 20:59, Richard Bair wrote: * Should a switch always have a default-case? - According to the Java guidelines this should be! I would say definitely yes. The default clause should throw an AssertionError if it really is unexpected. This will catch cases where we add an enum type and don't add the right clause to a switch statement. ok * Why are so many things not generified but use the raw types? - It looks like you are all running with raw-type warnings off, which has the effect that you don't even spot APIs who are not generified (and can't even be fixed because it would be an API breakage). Could be! * What should be done with fields declared but never used? We ought to remove anything not being used. The only trick is making sure it isn't be used evilly through reflection (most of the time this is not the case). Understood but if that is the case it should be marked and commented. I think you should also write down the policy when a Simple*Property used? - we discussed that same months ago already I'd be happy to put it in the wiki if you give me some words. I'm overloaded and drowning :) Ok. Let me see if I can come up with some words on this. Wouldn't it make sense to turn on things like static code analysis and compiler warnings in the grade build? I know that there was some effort in OpenJDK to compile -Xlint:all -Werror by default instead of suppressing them? At least I think this should be a target, not? Tom
Re: Detecting when a TreeItem is no more used
Correct, but then i1 is not referenced anymore and so GC should free it, not? Tom On 26.07.13 21:45, Fabrizio Giudici wrote: On Fri, 26 Jul 2013 13:47:50 +0200, Tom Schindl tom.schi...@bestsolution.at wrote: Not sure but what is reused is the TreeCell, the TreeItem is not freed and has to exists as long as you show the tree! TreeItem... i1 = new TreeItem...(); treeView.setRoot(i1); TreeItem... i2 = new TreeItem...(); treeView.setRoot(i2); I'd say that when you change the root to i2, i1 is no more needed, right?
Re: New Layout Panes in JavaFX 8
There are external panes e.g. MiglayoutPane, I have ports of the SWT-Layouts (Fill,Grid,Row). Tom On 27.07.13 16:06, Peter Penzov wrote: I would like to ask you are you planning to add new Layout Panes in JavaFX 8?
Re: JavaFX 2 memory leaks in StyleManager (making FX2 completely unusable for application development)
Ok - our problem has nothing to do with switching stylesheets! It simply happens while running the application. Too me it looks like when ever the CSS-Engine reapplies styles (e.g. because of pseudostate change) it creates an image object instead of reusing the old one. Tom On 30.07.13 14:37, Ali Ebrahimi wrote: This is issue: https://javafx-jira.kenai.com/browse/RT-29055 Can you try this? On Tue, Jul 30, 2013 at 4:38 PM, Sven Reimers sven.reim...@gmail.com mailto:sven.reim...@gmail.com wrote: Any chance you can track down why it is leaking? -Sven On Tue, Jul 30, 2013 at 1:46 PM, Ali Ebrahimi ali.ebrahimi1...@gmail.com mailto:ali.ebrahimi1...@gmail.com wrote: I sent a similar memory leak report a while ago for Modena demo app, and they just close issue As Not producible. But I can see the same issue just Now. On Tue, Jul 30, 2013 at 3:58 PM, Tom Schindl tom.schi...@bestsolution.at mailto:tom.schi...@bestsolution.atwrote: [resending because mail was blocked yesterday because of included images] Hi, I've been debugging a JavaFX application with a customer and we've found a tremendous memory leak in StyleManager when using icons. This bug makes JavaFX 2.x completely unusable because the application is using up to 1.5GB and more within a few mintues! Has anyone seen this and if I file a bug could I expect a bugfix in FX2? The screenshots from the Memory Analyzer can be seen at: http://www.efxclipse.org/image001.png http://www.efxclipse.org/image002.png Tom -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497
Re: JavaFX and iOS - it will remain a dream
I don't think it is a good idea to use fxml on embedded and mobile, we are working on a fxml = java converter so you can add it to your build process. Tom Von meinem iPhone gesendet Am 31.07.2013 um 08:11 schrieb Niklas Therning nik...@therning.org: after many days trying to really build iOS apps with JavaFX and RoboVM or Avian I’m very frustrated because of the following things: Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t know the reason - maybe it’s the rendering model of JavaFX - maybe it’s the currently unoptimized RoboVM One big problem of RoboVM is it’s dependence of the Android library, it does not support the OpenJDK. That’s a big reason for many many problems when using JavaFX. So currently it’s not possible to use fxml files (FXMLoader) because of the missing Stax xml parser and classes like XMLInputFactory in the android library… There's now a compatibility library for the jfx78 backport which includes the missing sun.* classes from OpenJDK [1]. So that will not be a problem when running on RoboVM/Android. Daniel Zwolenski is working on getting this into Maven which will make it nice and easy to develop with RoboVM+OpenJFX. FXMLLoader relies an StAX and the Java Scripting API. Those can both be made to work on RoboVM/Android. The POM of the compat project [1] contains optional dependencies on the StAX API and JSR 223 API. For StAX you'll also need a StAX provider [2][3]. For scripting you'll need a JSR 223 implementation of the scripting language you're using, like Rhino for JavaScript [4][5]. Please note that I haven't tested FXML but it should work (in theory at least ;-) ). Please give it a go. It will be a great blog story if you can make it work on iOS. As for the performance issues with RoboVM+OpenJFX: those WILL be addressed! You can either wait for it to happen or you can help out. One way to do that would be sample code that exercises the code paths that need to be optimized (e.g. the button rendering you posted about earlier). Preferably the sample should run repeatedly without user interaction. You should then be able to run Apple's Instruments application to profile this sample. This will help us determine what needs to be optimized. /Niklas [1] https://github.com/robovm/robovm-jfx78-compat [2] https://github.com/FasterXML/aalto-xml [3] http://woodstox.codehaus.org/ [4] https://developer.mozilla.org/en-US/docs/Rhino [5] https://java.net/projects/scripting/sources/svn/show/trunk/engines/javascript?rev=236
Re: JavaFX and iOS - it will remain a dream
On constrainted devices it is simply too slow because of all the reflection happening, you need to look up classes, decide on what a property means, doing type conversions from String to int, bool, ... this all eats up CPU-time! Tom On 31.07.13 09:15, John C. Turnbull wrote: Tom, why do you think FXML on mobiles is a bad idea? Performance? -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Tom Schindl Sent: Wednesday, 31 July 2013 16:29 To: Niklas Therning Cc: openjfx-dev@openjdk.java.net Mailing Subject: Re: JavaFX and iOS - it will remain a dream I don't think it is a good idea to use fxml on embedded and mobile, we are working on a fxml = java converter so you can add it to your build process. Tom Von meinem iPhone gesendet Am 31.07.2013 um 08:11 schrieb Niklas Therning nik...@therning.org: after many days trying to really build iOS apps with JavaFX and RoboVM or Avian I’m very frustrated because of the following things: Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t know the reason - maybe it’s the rendering model of JavaFX - maybe it’s the currently unoptimized RoboVM One big problem of RoboVM is it’s dependence of the Android library, it does not support the OpenJDK. That’s a big reason for many many problems when using JavaFX. So currently it’s not possible to use fxml files (FXMLoader) because of the missing Stax xml parser and classes like XMLInputFactory in the android library… There's now a compatibility library for the jfx78 backport which includes the missing sun.* classes from OpenJDK [1]. So that will not be a problem when running on RoboVM/Android. Daniel Zwolenski is working on getting this into Maven which will make it nice and easy to develop with RoboVM+OpenJFX. FXMLLoader relies an StAX and the Java Scripting API. Those can both be made to work on RoboVM/Android. The POM of the compat project [1] contains optional dependencies on the StAX API and JSR 223 API. For StAX you'll also need a StAX provider [2][3]. For scripting you'll need a JSR 223 implementation of the scripting language you're using, like Rhino for JavaScript [4][5]. Please note that I haven't tested FXML but it should work (in theory at least ;-) ). Please give it a go. It will be a great blog story if you can make it work on iOS. As for the performance issues with RoboVM+OpenJFX: those WILL be addressed! You can either wait for it to happen or you can help out. One way to do that would be sample code that exercises the code paths that need to be optimized (e.g. the button rendering you posted about earlier). Preferably the sample should run repeatedly without user interaction. You should then be able to run Apple's Instruments application to profile this sample. This will help us determine what needs to be optimized. /Niklas [1] https://github.com/robovm/robovm-jfx78-compat [2] https://github.com/FasterXML/aalto-xml [3] http://woodstox.codehaus.org/ [4] https://developer.mozilla.org/en-US/docs/Rhino [5] https://java.net/projects/scripting/sources/svn/show/trunk/engines/javascript?rev=236
Re: JavaFX and iOS - it will remain a dream
It will spit out a .java-Class which you run through javac and get bytecode - for robovm this is going to be completely transparent because it gets a java-class file. Tom On 31.07.13 09:57, Niklas Therning wrote: Will this converter be able to precompile embedded JavaScript? That would be very cool. If I remember correctly Rhino can compile JS to bytecode AOT. RoboVM would then be able to compile that bytecode to machine code. On Wed, Jul 31, 2013 at 8:28 AM, Tom Schindl tom.schi...@bestsolution.at mailto:tom.schi...@bestsolution.at wrote: I don't think it is a good idea to use fxml on embedded and mobile, we are working on a fxml = java converter so you can add it to your build process. Tom Von meinem iPhone gesendet Am 31.07.2013 um 08:11 schrieb Niklas Therning nik...@therning.org mailto:nik...@therning.org: after many days trying to really build iOS apps with JavaFX and RoboVM or Avian I’m very frustrated because of the following things: Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t know the reason - maybe it’s the rendering model of JavaFX - maybe it’s the currently unoptimized RoboVM One big problem of RoboVM is it’s dependence of the Android library, it does not support the OpenJDK. That’s a big reason for many many problems when using JavaFX. So currently it’s not possible to use fxml files (FXMLoader) because of the missing Stax xml parser and classes like XMLInputFactory in the android library… There's now a compatibility library for the jfx78 backport which includes the missing sun.* classes from OpenJDK [1]. So that will not be a problem when running on RoboVM/Android. Daniel Zwolenski is working on getting this into Maven which will make it nice and easy to develop with RoboVM+OpenJFX. FXMLLoader relies an StAX and the Java Scripting API. Those can both be made to work on RoboVM/Android. The POM of the compat project [1] contains optional dependencies on the StAX API and JSR 223 API. For StAX you'll also need a StAX provider [2][3]. For scripting you'll need a JSR 223 implementation of the scripting language you're using, like Rhino for JavaScript [4][5]. Please note that I haven't tested FXML but it should work (in theory at least ;-) ). Please give it a go. It will be a great blog story if you can make it work on iOS. As for the performance issues with RoboVM+OpenJFX: those WILL be addressed! You can either wait for it to happen or you can help out. One way to do that would be sample code that exercises the code paths that need to be optimized (e.g. the button rendering you posted about earlier). Preferably the sample should run repeatedly without user interaction. You should then be able to run Apple's Instruments application to profile this sample. This will help us determine what needs to be optimized. /Niklas [1] https://github.com/robovm/robovm-jfx78-compat [2] https://github.com/FasterXML/aalto-xml [3] http://woodstox.codehaus.org/ [4] https://developer.mozilla.org/en-US/docs/Rhino [5] https://java.net/projects/scripting/sources/svn/show/trunk/engines/javascript?rev=236
Re: JavaFX and iOS - it will remain a dream
Hi, If you want to take a look at the sources, they are available at http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/tooling/org.eclipse.fx.ide.fxml.compiler. Code is written in xtend - don't judge the code yet, I simply want something going. The process of the conversion looks like this: FXML = Internal Memory Model = Java ^^ SaxParser Converter So I think your request to have different languages as output is possible by implementing e.g. a JavaScript converter. For you second request: Yes there's a helper class named ExtendedFXMLLoader which you feed a FXML-Path and which at first tries to load a compiled class and falling back to FXML if not found (see attached sample). The biggest problem I have with Controller-Fields and Methods who are NOT public or package private (depends on the location of the FXML relative to its controller) because there I still need to use reflection. Anyone a good idea to get around reflection in case I can't directly access them? For the initial version I'll simply immediately fallback to reflection and we could get smarter later on. I'll expect a first version which supports the most basic stuff to get out in the next few days. Attached you see my current state. You'll notice the most basic things already work: * Simple properties * Sub-Trees including default properties * Static properties * Properties who need to be created through Builders But naturally there's still a lot left to do ;-) Tom On 31.07.13 16:42, Danno Ferrin wrote: Where is the code base for this converter? Done properly it can also be written to spit out the generated stubs, as well as output in any language the user may prefer. A top grade implementation could integrate with FXMLLoader for a seamless experience ala .bss files. On Tuesday, July 30, 2013, Tom Schindl wrote: I don't think it is a good idea to use fxml on embedded and mobile, we are working on a fxml = java converter so you can add it to your build process. Tom Von meinem iPhone gesendet Am 31.07.2013 um 08:11 schrieb Niklas Therning nik...@therning.org javascript:;: after many days trying to really build iOS apps with JavaFX and RoboVM or Avian I’m very frustrated because of the following things: Based on RoboVM, JavaFX on iOS runs unacceptable slow - I don’t know the reason - maybe it’s the rendering model of JavaFX - maybe it’s the currently unoptimized RoboVM One big problem of RoboVM is it’s dependence of the Android library, it does not support the OpenJDK. That’s a big reason for many many problems when using JavaFX. So currently it’s not possible to use fxml files (FXMLoader) because of the missing Stax xml parser and classes like XMLInputFactory in the android library… There's now a compatibility library for the jfx78 backport which includes the missing sun.* classes from OpenJDK [1]. So that will not be a problem when running on RoboVM/Android. Daniel Zwolenski is working on getting this into Maven which will make it nice and easy to develop with RoboVM+OpenJFX. FXMLLoader relies an StAX and the Java Scripting API. Those can both be made to work on RoboVM/Android. The POM of the compat project [1] contains optional dependencies on the StAX API and JSR 223 API. For StAX you'll also need a StAX provider [2][3]. For scripting you'll need a JSR 223 implementation of the scripting language you're using, like Rhino for JavaScript [4][5]. Please note that I haven't tested FXML but it should work (in theory at least ;-) ). Please give it a go. It will be a great blog story if you can make it work on iOS. As for the performance issues with RoboVM+OpenJFX: those WILL be addressed! You can either wait for it to happen or you can help out. One way to do that would be sample code that exercises the code paths that need to be optimized (e.g. the button rendering you posted about earlier). Preferably the sample should run repeatedly without user interaction. You should then be able to run Apple's Instruments application to profile this sample. This will help us determine what needs to be optimized. /Niklas [1] https://github.com/robovm/robovm-jfx78-compat [2] https://github.com/FasterXML/aalto-xml [3] http://woodstox.codehaus.org/ [4] https://developer.mozilla.org/en-US/docs/Rhino [5] https://java.net/projects/scripting/sources/svn/show/trunk/engines/javascript?rev=236 package test; import java.io.IOException; import org.eclipse.fx.core.fxml.ExtendedFXMLLoader; import javafx.application.Application; import javafx.scene.Scene; import
Is Node.setClip() expected detect changes to the clip-Node?
Hi,
I've been hunting a bug in TitledPaneSkin [1] which makes me wonder if
maybe the control code is using the Clip-Feature in appropriately.
The code in general looks like this:
public class BlaSkin extends Node {
private Rectangle rect;
public BlaSki() {
rect = new Rectangle();
setClip(rect);
}
public void changeSize(double x, double y) {
rect.setWidth(x);
rect.setHeight(y);
}
}
so the clipping node changes its size while the code is running but it
looks like the rendering code does not know about this and never updates
the peer's clipNode (in impl_updatePeer) now I guess this is simply an
optimization introduced in FX8 so my question is is Node expected to
detect its clip node changes or is the developer forced to somehow tell
the Node to do so (my first direct work around was to set the clip to
null and back to the rectangle which fixes the problem)?
Tom
[1]https://javafx-jira.kenai.com/browse/RT-32117
Re: Is Node.setClip() expected detect changes to the clip-Node?
I think I've nailed it down now - the problem is that the clip's
treeVisible-Property is not update appropiately, hence it is never taken
into account and synced because the system thinks it is invisible after
the first initialization.
Tom
On 05.08.13 15:26, Tom Schindl wrote:
https://javafx-jira.kenai.com/browse/RT-32123
Tom
On 05.08.13 15:07, Pavel Safrata wrote:
Hi Tom,
this is definitely a bug, clip node has to be synced automatically.
Would you please file a Jira issue?
Thanks,
Pavel
On 5.8.2013 13:55, Tom Schindl wrote:
Hi,
I've been hunting a bug in TitledPaneSkin [1] which makes me wonder if
maybe the control code is using the Clip-Feature in appropriately.
The code in general looks like this:
public class BlaSkin extends Node {
private Rectangle rect;
public BlaSki() {
rect = new Rectangle();
setClip(rect);
}
public void changeSize(double x, double y) {
rect.setWidth(x);
rect.setHeight(y);
}
}
so the clipping node changes its size while the code is running but it
looks like the rendering code does not know about this and never updates
the peer's clipNode (in impl_updatePeer) now I guess this is simply an
optimization introduced in FX8 so my question is is Node expected to
detect its clip node changes or is the developer forced to somehow tell
the Node to do so (my first direct work around was to set the clip to
null and back to the rectangle which fixes the problem)?
Tom
[1]https://javafx-jira.kenai.com/browse/RT-32117
Re: Proposal to move default style-class from Control to SkinBase
Oh and one more thing: IIRC you can run e.g. less in rhino so feeding it a less file with -fx properties should get you css file which you can pass on to FX. Tom On 07.08.13 22:56, Tom Schindl wrote: If I get your complain right what you want has nothing to do with CSS but you are requesting that the complete FX API is remodeled, CSS is simply a way to set properties of your Nodes in the SceneGraph, in a none intrusive way. You need to differiate between CSS as a language and the properties one can set on DOM/SceneGraph-Nodes. From the selector point (language) of view FX-CSS support all important selector types, but because the nodes in the DOM (=SceneGraph in FX) are different you have other properties. So if you invent the same node-types you have on the web (lets face it there's only a handful of them most important are most likely div,span) and give them the same properties you know from the web you can copy your Web-CSS stylesheet to your FX-Application. Tom On 07.08.13 22:41, Pedro Duque Vieira wrote: Hi David, I'm not going to directly answer your question but I'm rather gonna touch on a problem I see regarding JavaFX CSS. Forgive me for not directly sticking to the subject of your email. The issue I see is that JavaFX CSS significantly differs from W3C CSS, that is the CSS that is used on the web. I've already touch this subject before but didn't have much answer from this mailing list. The reason why I bring it back again is that the more I do web development the more this seems unappropriated. Having JavaFX CSS differ from W3C CSS has the following disadvantages: - Designers coming from web development (they are the majority) will struggle with JavaFX CSS - Cannot use CSS pre-processors like SASS, LESS, Compass thus missing out on this tooling that significantly enhances CSS. You can do really cool stuff with Compass. - Cannot reuse what already is out there on the web. And there are a huge amount of examples there. - Re-inventing the wheel. My personal opinion is that you should try to harness the work that already exists especially when you have few resources. People have already spent some time on this, tested and fixed issues with it. So why not stand on the shoulder of giants. I'm not saying you should introduce CSS layout, that is a headache and a problem that they're trying to solve in CSS3, but all the rest can be changed to be the same as CSS. You can even have both working side by side, the current JavaFX CSS and a newer more W3C conforming CSS so that you don't break existing apps. I don't see any advantage of having a CSS different from W3C one, if I was going to make one different I would have created a newer more simpler language to express an apps appearance. Not used CSS. Thanks, best regards,
Re: JavaFX CSS significantly differs from W3C CSS (Forked from RE: Proposal to move default style-class from Control to SkinBase)
to be a highly requested feature. Regards, John -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Tom Schindl Sent: Wednesday, August 07, 2013 2:01 PM To: openjfx-dev@openjdk.java.net Subject: Re: Proposal to move default style-class from Control to SkinBase Oh and one more thing: IIRC you can run e.g. less in rhino so feeding it a less file with -fx properties should get you css file which you can pass on to FX. Tom On 07.08.13 22:56, Tom Schindl wrote: If I get your complain right what you want has nothing to do with CSS but you are requesting that the complete FX API is remodeled, CSS is simply a way to set properties of your Nodes in the SceneGraph, in a none intrusive way. You need to differiate between CSS as a language and the properties one can set on DOM/SceneGraph-Nodes. From the selector point (language) of view FX-CSS support all important selector types, but because the nodes in the DOM (=SceneGraph in FX) are different you have other properties. So if you invent the same node-types you have on the web (lets face it there's only a handful of them most important are most likely div,span) and give them the same properties you know from the web you can copy your Web-CSS stylesheet to your FX-Application. Tom On 07.08.13 22:41, Pedro Duque Vieira wrote: Hi David, I'm not going to directly answer your question but I'm rather gonna touch on a problem I see regarding JavaFX CSS. Forgive me for not directly sticking to the subject of your email. The issue I see is that JavaFX CSS significantly differs from W3C CSS, that is the CSS that is used on the web. I've already touch this subject before but didn't have much answer from this mailing list. The reason why I bring it back again is that the more I do web development the more this seems unappropriated. Having JavaFX CSS differ from W3C CSS has the following disadvantages: - Designers coming from web development (they are the majority) will struggle with JavaFX CSS - Cannot use CSS pre-processors like SASS, LESS, Compass thus missing out on this tooling that significantly enhances CSS. You can do really cool stuff with Compass. - Cannot reuse what already is out there on the web. And there are a huge amount of examples there. - Re-inventing the wheel. My personal opinion is that you should try to harness the work that already exists especially when you have few resources. People have already spent some time on this, tested and fixed issues with it. So why not stand on the shoulder of giants. I'm not saying you should introduce CSS layout, that is a headache and a problem that they're trying to solve in CSS3, but all the rest can be changed to be the same as CSS. You can even have both working side by side, the current JavaFX CSS and a newer more W3C conforming CSS so that you don't break existing apps. I don't see any advantage of having a CSS different from W3C one, if I was going to make one different I would have created a newer more simpler language to express an apps appearance. Not used CSS. Thanks, best regards,
Re: JavaFX CSS significantly differs from W3C CSS (Forked from RE: Proposal to move default style-class from Control to SkinBase)
Hi Pedro, on CSS as a spec: You are right the spec does not only hold a language definition but also the definition of e.g. the box-model, ... who simply can not be applied to FX unless you completely revamp how it works on CSS: The grammer of the CSS-Language is at http://www.w3.org/TR/CSS2/grammar.html with a descrption at http://www.w3.org/TR/CSS2/syndata.html with updates in later specs and CSS can not only be applied to HTML-Doms but e.g. also to SVG where you have completely different attributes. See www.w3.org/TR/2011/REC-SVG11-20110816/styling.html how few properties SVG and HTML-CSS share! So to me it looks like the authors of SVG see CSS in the same way the JavaFX-Team does it as a styleing DSL leaving out things like the Box-Model, ... on SASS: I see no reason it can not be used. Like I said SASS is simply syntatic sugar above the CSS Language, but it does not really care about how the properties are named! I've attached you a sample of scss file derived from the projects website using JavaFX properties and to me the output looks correct, maybe there are advanced features I'm not aware of - I haven't used SASS at all on Compass: This one does not work with FX because it somehow deals with the properties on reusing CSS-HTML-Properties: I think the confusion would be getting worse if we'd start mixing HTML-CSS-Property names with -fx ones (which we need in any case) - even if we can get them 100% HTML-CSS compliant. I don't see me blindly copying a HTML-CSS which assumes the Box-Model, element-types who are not existing in FX at all Tom On 08.08.13 02:58, Pedro Duque Vieira wrote: Go to the CSS W3C website and read the spec, you'll see that it's not only a language. No SASS can't be used with JavaFX unless you make a SASS of your own that works like the original but with JavaFX CSS files. Thanks, regards, On Thu, Aug 8, 2013 at 1:38 AM, Tom Schindl tom.schi...@bestsolution.at mailto:tom.schi...@bestsolution.at wrote: SASS can be used as well in fx, it is simply a preprocessor, like LESS, and for CSS the language and selectors there is a grammer! CSS is simply a DSL and its most important part are the selectors and its cascading nature. Tom Von meinem iPhone gesendet Am 08.08.2013 um 02:11 schrieb Pedro Duque Vieira pedro.duquevie...@gmail.com mailto:pedro.duquevie...@gmail.com: I might have jumped the gun when talking about LESS, I'm not actually familiar with it and thought it would be along the same lines like SASS. But still you can't use SASS or Compass with JavaFX CSS. Cheers, On Thu, Aug 8, 2013 at 1:05 AM, Pedro Duque Vieira pedro.duquevie...@gmail.com mailto:pedro.duquevie...@gmail.com wrote: So if you invent the same node-types you have on the web (lets face it there's only a handful of them most important are most likely div,span) and give them the same properties you know from the web you can copy your Web-CSS stylesheet to your FX-Application. +1 to this idea (in a 3rd party lib). The issue I see is that JavaFX CSS significantly differs from W3C CSS It surprises me that this issue comes up so rarely in JavaFX forums (almost never) - perhaps it is because JavaFX developers tend to be Java developers rather than designers. A related open jira request is http://javafx-jira.kenai.com/browse/RT-9272 need to reconcile JavaFX CSS with W3C CSS3 0 votes (no interest at all?). In terms of conversion of existing html css resources to javafx css, you may be interested in a QA with a developer who converted the Foundation look and feel to JavaFX (https://forums.oracle.com/thread/2490009) - from his point of view the conversion process was quite straight-forward - though perhaps that was partially luck of the draw. Below is a copy and paste from an earlier JavaFX forum post on this topic: You know, sometimes I find JavaFX's lack of certain css features refreshing. It is nice to have all, well, almost all, of the JavaFX CSS documented on one page. I think if you were to do the same thing for w3c css then it would end up with a much larger, more difficult to understand document and even what the contents of that document should be would probably be pretty controversial, in the same kind of way that the HTML5 specification ended up being. Microsoft contributed over 7000
PrefWidth/Height calculations only works if stage is shown
Hi, I've been trying to open a window in the minimal dimension needed by components but it looks like size calculations prefHeight/prefWidth only works if the stage is shown. I need the dimensions before showing the stage because I want to position it on the lower right of the screen before showing the stage because if doing it afterwards leads to flickering. BorderPane g = new BorderPane(); TableViewString v = new TableViewString(); g.setCenter(v); Scene s = new Scene(g); primaryStage.setScene(s); System.err.println(g.prefWidth(-1)); // 0 primaryStage.show(); System.err.println(g.prefWidth(-1)); // 248 Is this working as designed? Tom
Re: PrefWidth/Height calculations only works if stage is shown
No same result! BorderPane g = new BorderPane(); TableViewString v = new TableViewString(); g.setCenter(v); Scene s = new Scene(g); primaryStage.setScene(s); g.impl_reapplyCSS(); System.err.println(g.prefWidth(-1)); // 0 primaryStage.show(); Could it be that this does not work because if a stage is not yet shown the peers have not been created? Tom On 08.08.13 23:29, Richard Bair wrote: Yes, the problem is that CSS has not been executed yet. If you call reapplyCSS (did we add that API yet? or is it still that impl_?) then you can get a proper size from the control. Richard On Aug 8, 2013, at 2:26 PM, Tom Schindl tom.schi...@bestsolution.at wrote: Hi, I've been trying to open a window in the minimal dimension needed by components but it looks like size calculations prefHeight/prefWidth only works if the stage is shown. I need the dimensions before showing the stage because I want to position it on the lower right of the screen before showing the stage because if doing it afterwards leads to flickering. BorderPane g = new BorderPane(); TableViewString v = new TableViewString(); g.setCenter(v); Scene s = new Scene(g); primaryStage.setScene(s); System.err.println(g.prefWidth(-1)); // 0 primaryStage.show(); System.err.println(g.prefWidth(-1)); // 248 Is this working as designed? Tom
Re: PrefWidth/Height calculations only works if stage is shown
Prefect! Tom On 08.08.13 23:40, Richard Bair wrote: The peers don't impact the preferred sizes at all. Use this one instead of impl_reapplyCSS (wrong one) impl_processCSS(true) On Aug 8, 2013, at 2:35 PM, Tom Schindl tom.schi...@bestsolution.at wrote: No same result! BorderPane g = new BorderPane(); TableViewString v = new TableViewString(); g.setCenter(v); Scene s = new Scene(g); primaryStage.setScene(s); g.impl_reapplyCSS(); System.err.println(g.prefWidth(-1)); // 0 primaryStage.show(); Could it be that this does not work because if a stage is not yet shown the peers have not been created? Tom On 08.08.13 23:29, Richard Bair wrote: Yes, the problem is that CSS has not been executed yet. If you call reapplyCSS (did we add that API yet? or is it still that impl_?) then you can get a proper size from the control. Richard On Aug 8, 2013, at 2:26 PM, Tom Schindl tom.schi...@bestsolution.at wrote: Hi, I've been trying to open a window in the minimal dimension needed by components but it looks like size calculations prefHeight/prefWidth only works if the stage is shown. I need the dimensions before showing the stage because I want to position it on the lower right of the screen before showing the stage because if doing it afterwards leads to flickering. BorderPane g = new BorderPane(); TableViewString v = new TableViewString(); g.setCenter(v); Scene s = new Scene(g); primaryStage.setScene(s); System.err.println(g.prefWidth(-1)); // 0 primaryStage.show(); System.err.println(g.prefWidth(-1)); // 248 Is this working as designed? Tom
Re: Unchecked conversion warning
Hi Sven, I'm building from master and don't see this. Do you build with gradle or inside your IDE? I've so many type warnings in Eclipse (~12.000) that I probably don't spot this warning. In the gradle build I think all warnings are simply turned off. Tom On 13.08.13 15:29, Sven Reimers wrote: Hi guys, trying to compile ReadOnlyObjectPropertyWorker.State stateProperty = task.stateProperty(); leads to warning: [unchecked] unchecked conversion ReadOnlyObjectPropertyWorker.State stateProperty = task.stateProperty(); required: ReadOnlyObjectPropertyState found:ReadOnlyObjectProperty Not sure if this is something broken om my dev machine - can anyone confirm? Thanks -Sven
Re: Unchecked conversion warning
No warning in Eclipse so: a) it is javac (Eclipse uses its own compiler) b) it is netbeans use of javac Tom On 13.08.13 16:20, Sven Reimers wrote: Just use b102 create a new file and type the line... -Sven On Tue, Aug 13, 2013 at 4:01 PM, Tom Schindl tom.schi...@bestsolution.at mailto:tom.schi...@bestsolution.at wrote: Hi Sven, I'm building from master and don't see this. Do you build with gradle or inside your IDE? I've so many type warnings in Eclipse (~12.000) that I probably don't spot this warning. In the gradle build I think all warnings are simply turned off. Tom On 13.08.13 15:29, Sven Reimers wrote: Hi guys, trying to compile ReadOnlyObjectPropertyWorker.State stateProperty = task.stateProperty(); leads to warning: [unchecked] unchecked conversion ReadOnlyObjectPropertyWorker.State stateProperty = task.stateProperty(); required: ReadOnlyObjectPropertyState found:ReadOnlyObjectProperty Not sure if this is something broken om my dev machine - can anyone confirm? Thanks -Sven -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * Duke's Choice Award Winner 2009 * Blog: http://nbguru.blogspot.com * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497
Re: Call static content
This is more a user group question! A node can be shown only in one
place. If you want to reuse the same image load the image into
javafx.scene.Image and set it to different ImageView-Nodes.
Tom
On 24.08.13 21:01, Peter Penzov wrote:
I have this code from JavaFX application:
private static final ImageView ncpic;
static {
ncpic = new
ImageView(TabContent.class.getResource(/images/6.jpg).toExternalForm());
}
I noticed that I can use this picture only once. When I use it twice the
scene where I call it it's empty. How I can use this picture twice or more
times? Maybe this is caused by the static java method which I call to
display the picture?
quick example:
public class TabContent {
private static final ImageView ncpic;
static {
ncpic = new
ImageView(TabContent.class.getResource(/images/6.jpg).toExternalForm());
}
private static StackPane generalConfiguration() {
StackPane stack = new StackPane();
stack.getChildren().addAll(ncpic); // Add the picture
and the Label
return stack;
}}
I use it this way: TabContent.generalConfiguration() And second time in
different Java Class.
Re: Creating custom chart - XYBarChart
The problem is not the javadocs but that one makes internals of a class API and has to live with it forever. Tom Von meinem iPhone gesendet Am 02.09.2013 um 02:09 schrieb Pedro Duque Vieira pedro.duquevie...@gmail.com: Hi, Sorry for sending in several emails to the mailing list at once. I'm having some issues while creating a custom chart - a XYBarChart, which is a BarChart that can have both axis as ValueAxis. The main issue I'm having is that there are a lot of fields and methods which are package private and I need to access them. I see there is already another person in this mailing list that is also having trouble extending some other part of the framework because of package private fields/methods. Maybe there should be more inclination towards making things protected rather than package private. I can see the problem that this could potentially flood the javadocs with methods and fields but I think that not being able to extend some framework class is worse. Thanks, best regards, -- Pedro Duque Vieira
Re: replace a section of ObservableList in one operation?
I don't think there's API for this so the only idea is to copy the list to an ArrayList, do the replace there and afterwards call ObservableList#setAll(). Tom On 02.09.13 14:22, Tomas Mikula wrote: Hi, I cannot find a way to replace a section of ObservableList in one operation. I'm looking for something like ObservableListE#setAll(int from, int to, Collection? extends E col) or list.subList(from, to).setAll(col). In the latter case, ObservableList#subList() would have to return an instance of ObservableList, not just List. I know I can use a pair of remove() and addAll(), but my objective is to generate just 1 change event. Is there a way to achieve this? Thank you, Tomas
ScrollBar visibleAmount value
Hi, Before fileing a bug I wanted to post here because maybe I get this completely wrong. Say we have have a scrollbar with min = 0 max = 100 visualAmount = 50. I would have expected like in Swing SWT that the maximum value of the scrollbar is 50 (=max - visualAmount) but the value is still 100. Is this desired or an oversight? I can work around this problem by calculating the value back using ((max-visualAmount)/max)*value but like I said this is unexpected when coming from the other toolkits. Tom
Re: ScrollBar visibleAmount value
Well like I said Swing SWT do interpret this different! To me the value always meant to the upper ending of the thumb. If you think about edge cases of 99 (value still goes from 0..100) and 100 (value can 0 only). Anyways from your answer I guess the current behavior is correct and no ticket needs to be filed and I have to do the calculation from below to match API contract of the library. Tom On 03.09.13 01:40, Richard Bair wrote: Oh interesting, I always considered visibleAmount as being an independent state that affected the size of the scroll bar thumb, but not really anything more. The reason why was for virtualized uses like with ListView where the height of the thumb might change as you scroll. On Sep 2, 2013, at 1:38 PM, Tom Schindl tom.schi...@bestsolution.at wrote: Hi, Before fileing a bug I wanted to post here because maybe I get this completely wrong. Say we have have a scrollbar with min = 0 max = 100 visualAmount = 50. I would have expected like in Swing SWT that the maximum value of the scrollbar is 50 (=max - visualAmount) but the value is still 100. Is this desired or an oversight? I can work around this problem by calculating the value back using ((max-visualAmount)/max)*value but like I said this is unexpected when coming from the other toolkits. Tom
Re: ServiceLoader
Well once we have a replacement for builders this is not needed anymore so I don't think there's a JIRA needed. When we discussed replacements for builders in context of FXML the consensus was to have annotations on the constructor to map the arguments appropriately. Eva suggested @ConstructorProperties, I was more in favor of explicit @FXMLValue annotation on each argument. Tom On 03.09.13 22:53, Tom Eugelink wrote: No, but there is a less-than-optimal-but-fast approach, and that is to write a custom BuilderFactory with if statements for all 3rd party controls. On 2013-09-03 20:46, Richard Bair wrote: It is a real problem though (how to support 3rd party controls well). Is there a JIRA for this case? Richard On Sep 3, 2013, at 11:44 AM, Tom Eugelink t...@tbee.org wrote: True, so we'll leave it JFXtras then. On 2013-09-03 20:28, Richard Bair wrote: The only knee-jerk reaction to the service loader is that it can be bad at startup, because for the service loader to work, it has to scan all jar files, which means downloading all jar files. Maybe with Jigsaw we'll have a better mechanism for this such that we can just read the first few bytes of a module and determine whether it supports a certain service or not. Richard On Sep 3, 2013, at 9:43 AM, Tom Eugelink t...@tbee.org wrote: On 2013-09-03 17:49, Richard Bair wrote: In this case, since JavaFX is Free Software! you can actually suggest the fix, prototype and propose the patch yourself, limiting the round trip time substantially. That said, in JFXtras I've created an extended FactoryBuilder that dynamically loads builder classes using Java's standard ServiceLoader approach. Would this be of interest for inclusion directly into JavaFX? https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/labs/fxml/JFXtrasBuilderFactory.java It does require a slightly extended Builder interface though. https://github.com/JFXtras/jfxtras-labs/blob/2.2/src/main/java/jfxtras/fxml/BuilderService.java A little blabla about this on this blog entry: http://tbeernot.wordpress.com/2013/08/25/fxml-builders-detection/ Tom
Re: How to attach files to Jira?
This was turned off long time ago to avoid spam and upload of viruses. What I don't understand is why people who e.g. filed 10bug reports or made 10 comments, asked for upload permission at this very list, ... don't get the possibility. Another option would be to only allow patches / text files. Tom On 29.09.13 16:53, Pedro Duque Vieira wrote: Hi, How can you attach files to Jira? In the past I was able to do this but not anymore. Have you disabled this feature for non Oracle folks? Thanks, best regards,
Re: FXMLLoader templates
In case someone needs extra performance I can point you to my FXML =
Java-Converter which will give you the best performance ;-)
Tom
On 01.10.13 09:15, Martin Sladecek wrote:
After discussion with Richard, we decided to remove the template flag
from FXMLLoader for 8.0.
This API is not mature yet, due to the reasons described below and
should be completely re-designed for some next release.
This means that loading the same fxml multiple times will still require
multiple FXMLLoader instances.
Any comments?
Thanks,
-Martin
On 09/20/2013 02:22 PM, Martin Sladecek wrote:
Hi,
I would like to discuss a 8.0 feature of FXMLLoader - the template flag.
I was introduced with this issue:
https://javafx-jira.kenai.com/browse/RT-23413, but unfortunately, it
never worked: https://javafx-jira.kenai.com/browse/RT-28121. I was
trying to fix the issue, but the whole concept of a flag for loading
templates seems hardly usable and incorrect to me and should be
replaced with something more appropriate.
The reason is the handling of root, controller and the namespace
before and after the load. Both are treated in 2 different ways.
Before the load, they are used to adjust the following load - by
setting the root (for fx:root tag), setting the namespace and a
controller.
However, after the load, these properties (though not FX-properties)
can be used to query what was just loaded. The root of the FXML, the
namespace with all ids and the controller.
Now that's not very useful when you want to use template loading. My
solution for RT-28121 (when keeping the old API) is to save the
namespace after setTemplate(true) was called, using this namespace on
each load(), clearing it at the begging of load() + disallow
setController() for this mode.
But that doesn't cover all of the relevant use-cases I can think of.
Actually, without changing the API, I doubt we can support all such
use-cases.
Here's the set I'm working with:
1) setup some template namespace, n times do { adjust namespace
(based on template namespace) , load) }
2) n times do {load, query id from namespace}
3) n times do {setController(new Controller) load }
4) n times do {load, query newly created controller}
5,6) same as 3,4 but with root
So while in 1,3 we would need to clear namespace/controller after each
load, in 2,4 we need to clear it before each load. In case 3),
forgetting to set a new controller would otherwise result in 2
instances with the same controller.
One solution might be to split this to 2 independent calls.
setController/getLoadedController, ObservableMap getNamespace() and
Map getLoadedNamespace (unmodifiable).
Another might be a completely new class FXMLTemplate.
It might yield new pre-set FXMLLoaders that can be adjusted and
loaded, but it means generating a temporary object for each call.
Also, FXMLLoader would need to be updated, so that it's only possible
to call load() once.
Other ideas / use-cases?
Thanks,
-Martin
Re: Lambdafication (was Re: Default methods in JFX-8)
... I can't see any real improvement for using lambdas beside that you
killed off warnings which could be fixed otherwise as well.
So I really don't get what it would help us beside making e.g. RoboVM
our sole chance to get FX on iOS harder to maintain.
Tom
On 07.10.13 16:16, Sven Reimers wrote:
Ok. So I will file a P4 saying Lambdafication for Controls
and send the diff to Richard/Kevin/Jonathan to be attached..
should I base the change on b110 (master)?
I could create a public bitbucket branch based on master and add my changes
there - better idea?
What approach is most simple for review?
Should I split test and library code changes?
-Sven
P.S. Shall I try to get this done as well for other modules? Which would be
preferred? (Just in case I have some more time to spend)
On Mon, Oct 7, 2013 at 1:26 PM, Kevin Rushforth
kevin.rushfo...@oracle.comwrote:
**
5. Should we enable more -Xlint warnings in OpenJFX build?
6. Any chances anything of this can still go in 8 (e.g. get rid of warnings
We have 2 weeks where we can still accept P4-P5 bugs into FX 8, and
getting rid of warnings would be a P4 bug. I guess it depends on how
intrusive the changes are and whether someone has time to review it in the
next two weeks.
-- Kevin
Sven Reimers wrote:
Ok. So here are the results of trying to add lambda and diamond to the
controls module:
1. A lot of generics and typing to be fixed (esp. in tests). Seems you can
get some anonymous inner classes type checked by the compiler, but not the
lambda equivalent.. very interesting.
2. 279 Files modified (including tests)
3. A lot of the automatic replacements could probably be nicer e.g.
ft.setOnFinished(new EventHandlerActionEvent() {
@Override public void handle(ActionEvent
actionEvent) {
getChildren().remove(tm.textNode);
}
});
was replaced to:
ft.setOnFinished((ActionEvent actionEvent) - {
getChildren().remove(tm.textNode);
});
most unobtrusive code probably:
ft.setOnFinished((actionEvent) - getChildren().remove(tm.textNode));
4. A lot of illegal forward reference errors - these were result of missing
this in the automatic transformation from anonymous inner to lambdas (seems
the rules are not identical - you have to add this. as prefix if using
lambdas - not sure this is the expected way it should work)
5. Should we enable more -Xlint warnings in OpenJFX build?
6. Any chances anything of this can still go in 8 (e.g. get rid of warnings
7. Probably more things I just can't think of at the moment...
How to take this forward? If there is interest in the change I could make
available...
Comments? Ideas?
-Sven
On Fri, Oct 4, 2013 at 2:19 PM, Sven Reimers sven.reim...@gmail.com
sven.reim...@gmail.com wrote:
Oh and btw - would you go for lambda with or without additional type info
before parameter name?
-Sven
On Fri, Oct 4, 2013 at 2:05 PM, Sven Reimers sven.reim...@gmail.com
sven.reim...@gmail.comwrote:
Ok. Here you go...
I just did an inspection run for the controls module and my IDE came up
with (drum roll) 888 possible lambda conversions..
Looking through them I discovered that usage of (aka diamond syntax)
is not used (or at least not used a lot) in at least the controls
modules. My IDE showed me 1171 occurrences.
Is there a good reason not to use diamonds?
Will now try to apply all those changes and figure out if this still
builds... up next: go through the other modules...
-Sven
On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair richard.b...@oracle.com
richard.b...@oracle.comwrote:
Brian was telling me at J1 that whether parallel gets you performance or
not depends on the size of the collection and the complexity of the work to
perform. There is definitely a point at which parallel helps -- and a point
at which it hurts.
Richard
On Oct 3, 2013, at 3:33 PM, Hervé Girod herve.gi...@gmail.com
herve.gi...@gmail.com wrote:
Here is a nice example, taking advantage of the ease of going
parallel. Apparently the performance without parallel will also further
improve.http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/
Hervé
Sent from my iPad
On 4 oct. 2013, at 00:20, David Grieve david.gri...@oracle.com
david.gri...@oracle.com
wrote:
And what about Stream? I like the declarative code that comes from
using Stream and I can see places in the code where Stream could be used,
but I wonder about its performance relative to iterators and/or enhanced
for loops.
On Oct 3, 2013, at 4:45 PM, Richard Bair richard.b...@oracle.com
richard.b...@oracle.com
wrote:
Hello, OpenJFX Community.
There's a question about using Java 8 features in FX.
I've been working on the support for InputMethods in JFXPanel which
is an important feature for many users who speak
Re: hg: openjfx/8/graphics/rt: 3 new changesets
So where the src.zip end up, so that k can adjust the tooling? Tom Von meinem iPhone gesendet Am 08.10.2013 um 18:32 schrieb hang...@oracle.com: Changeset: 61727bf6e832 Author:kcr Date: 2013-10-08 09:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/61727bf6e832 [TEST-ONLY] RT-32950: Enable excluded tests in gradle build Reviewed-by: Chien ! build.gradle ! modules/base/src/test/java/javafx/binding/expression/AbstractNumberExpressionTest.java Changeset: 093ea25436c7 Author:kcr Date: 2013-10-08 09:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/093ea25436c7 RT-21415: Need to add javafx-src.zip to JDK 8 distribution Reviewed-by: David Hill, Felipe ! build.gradle ! gradle.properties.template Changeset: ab9489903f7b Author:Yao Wang yao.w.w...@oracle.com Date: 2013-10-08 09:30 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ab9489903f7b RT-26587: 3D Data validation AND RT-30451: FX 8 3D: Need to validate Mesh's data size Summary: Validate input data during FX-NG sync stage. AND Need to validate the size and range of these arrays. Reviewed-by: kcr and cyang ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGShape3D.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGTriangleMesh.java ! modules/graphics/src/main/java/com/sun/prism/impl/BaseMesh.java ! modules/graphics/src/main/java/javafx/scene/shape/Box.java ! modules/graphics/src/main/java/javafx/scene/shape/Cylinder.java ! modules/graphics/src/main/java/javafx/scene/shape/Sphere.java ! modules/graphics/src/main/java/javafx/scene/shape/TriangleMesh.java
Re: JAVAFX on ANDROID
So when I compile my own FX what target to I compile to? I guess I compile on linux, right? Tom On 10.10.13 22:01, Tomas Brandalik wrote: Hi Tobi and Philippe, Android port is being developed in open source so all developers can see every progress. There is nothing to hide. You can understand it as an example of porting javafx runtime to a linux based platform not a product with a roadmap. As you've noticed there are 2 launchers DalvikLauncher and JavaSELauncher. Have a look at DalvikLauncher it is quite simple how it launches an application. What you need to try it out is an java6 (dalvik vm limitation) compatible javafx fork. On the other hand JavaSELauncher uses standalone vm which is not part of the port. It expects that the vm is packaged with an apk. The launcher unpacks vm, installs it, setup classpath, main class debug port etc (all specified in manifest) and launches it . These are the 2 options which can be further extended by the community. best regards -Tomas On 10/10/2013 06:10 PM, Tobias Bley wrote: Tomas from Oracle is working on the Android port of JavaFX. He has developed a DalvikLauncher and a JavaSELauncher. So he is able to tell you (and me :)) more about that important theme „JavaFX on Android“. Best regards, Tobi Am 10.10.2013 um 16:55 schrieb Philippe TIFFEAUphilippe.tiff...@steria.com: Hello, Someone can make a clear answer about JavaFX on ANDROID ? If it works how to use ? Otherwise the roadmap is Best Regard. This email and any attachments may contain confidential information and intellectual property (including copyright material). It is only for the use of the addressee(s) in accordance with any instructions contained within it. If you are not the addressee, you are prohibited from copying, forwarding, disclosing, saving or otherwise using it in any way. If you receive this email in error, please immediately advise the sender and delete it. Steria may monitor the content of emails within its network to ensure compliance with its policies and procedures. Emails are susceptible to alteration and their integrity (including origin) cannot be assured. Steria shall not be liable for any modification to a message, or for messages falsely sent.
Re: JAVAFX on ANDROID
FX78 should be compatible with Java6 because RoboVM is built on dalvik classlib and JavaFX works there! Tom On 10.10.13 22:42, Tobi wrote: Hi Tomas, How did you test the Dalviklauncher? Do you have a Java6 compatible jFX version? And how did you test the JavaSELauncher? Do you have a JVM for android? Where can we download it? Am 10.10.2013 um 22:01 schrieb Tomas Brandalik tomas.branda...@oracle.com: Hi Tobi and Philippe, Android port is being developed in open source so all developers can see every progress. There is nothing to hide. You can understand it as an example of porting javafx runtime to a linux based platform not a product with a roadmap. As you've noticed there are 2 launchers DalvikLauncher and JavaSELauncher. Have a look at DalvikLauncher it is quite simple how it launches an application. What you need to try it out is an java6 (dalvik vm limitation) compatible javafx fork. On the other hand JavaSELauncher uses standalone vm which is not part of the port. It expects that the vm is packaged with an apk. The launcher unpacks vm, installs it, setup classpath, main class debug port etc (all specified in manifest) and launches it . These are the 2 options which can be further extended by the community. best regards -Tomas On 10/10/2013 06:10 PM, Tobias Bley wrote: Tomas from Oracle is working on the Android port of JavaFX. He has developed a DalvikLauncher and a JavaSELauncher. So he is able to tell you (and me :)) more about that important theme „JavaFX on Android“. Best regards, Tobi Am 10.10.2013 um 16:55 schrieb Philippe TIFFEAUphilippe.tiff...@steria.com: Hello, Someone can make a clear answer about JavaFX on ANDROID ? If it works how to use ? Otherwise the roadmap is Best Regard. This email and any attachments may contain confidential information and intellectual property (including copyright material). It is only for the use of the addressee(s) in accordance with any instructions contained within it. If you are not the addressee, you are prohibited from copying, forwarding, disclosing, saving or otherwise using it in any way. If you receive this email in error, please immediately advise the sender and delete it. Steria may monitor the content of emails within its network to ensure compliance with its policies and procedures. Emails are susceptible to alteration and their integrity (including origin) cannot be assured. Steria shall not be liable for any modification to a message, or for messages falsely sent.
Re: JAVAFX on ANDROID
On 11.10.13 18:10, Matthias Hänel wrote: Hi Tomas, today, I took the time to investigate a little more time on this. 1. I build an entirely new openjfx78 build for android 2. starting this gave me several errors that lead me to the conclusion that I need a java6 openjfx 3. based on openjfx78 I ported it back to java6 (adapted gradled scripts, and tons of java source code) 4. Now it's almost running on an 18th android. All libraries are firing up until the CssStyleHelper is called with a static call to createStyleHelper. That looks like the font stuff is not in jfx78. That's why new Font returns with null and therefore On OS-X font stuff is definately there in jfx78, but the low-level font stuff is loaded using reflection (at least this was the cause on robovm)! Tom
Re: Constructor annotation
On 16.10.13 11:22, Eva Krejcirova wrote:
Hi All,
when we retired builders, we caused a problem for FXML which doesn't
have a way to create classes without default constructors. Back then we
decided to use an annotation for this but never actually got to
implement it and we need to fix this for FX8. I am in the process of
adding this functionality to FXMLLoader but we need to decide how the
annotation will look like and I could use some help with this.
We cannot use already existing ConstructorProperties for this, because
it's java.beans package and we don't want to create to dependency on
this package in JavaFX, so we need to introduce a new annotation.
We have two options:
1. Annotate the whole constructor:
e.g.
@ConstructorArguments({a, b, list})
public ImmutableClass(int a, int b, Integer... list)
2. Annotate the arguments:
e.g.
public ImmutableClass(@FXMLArgument(a) int a,
@FXMLArgument(b)int b, @FXMLArgument(list)Integer... list)
Which option do you like more and how should the annotation be named?
Option 2, but does it really have to hold FXML in the annotation name?
Where would you put the annotation? I think it should NOT be in the
FXML-Package-Namespace because the core should NOT depend on FXML!
I'd go with @Argument or simply @NamedArgument (@Named is already used
by javax.inject)
Tom
Re: Constructor annotation
To me the JavaBean solution with one annotation looks error prone, does
anybody know why they did not use an annotation per field?
Tom
On 16.10.13 16:58, Stephen F Northover wrote:
+1 for base. Should we not follow closely what Java Beans is doing for
consistency? I realize that we can't have the reference.
Steve
On 2013-10-16 10:53 AM, Kevin Rushforth wrote:
Not to mention Tom's point that it can't be in the fxml module without
created unwanted (and circular) module dependencies. Seems like it
needs to be in the base module then, right?
-- Kevin
Richard Bair wrote:
+1 this is my preference. It is useful for things other than FXML,
and should be considered part of our javafx.beans API.
On Oct 16, 2013, at 4:20 AM, Tom Schindl
tom.schi...@bestsolution.at wrote:
On 16.10.13 11:22, Eva Krejcirova wrote:
Hi All,
when we retired builders, we caused a problem for FXML which doesn't
have a way to create classes without default constructors. Back
then we
decided to use an annotation for this but never actually got to
implement it and we need to fix this for FX8. I am in the process of
adding this functionality to FXMLLoader but we need to decide how the
annotation will look like and I could use some help with this.
We cannot use already existing ConstructorProperties for this, because
it's java.beans package and we don't want to create to dependency on
this package in JavaFX, so we need to introduce a new annotation.
We have two options:
1. Annotate the whole constructor:
e.g.
@ConstructorArguments({a, b, list})
public ImmutableClass(int a, int b, Integer... list)
2. Annotate the arguments:
e.g.
public ImmutableClass(@FXMLArgument(a) int a,
@FXMLArgument(b)int b, @FXMLArgument(list)Integer... list)
Which option do you like more and how should the annotation be named?
Option 2, but does it really have to hold FXML in the annotation name?
Where would you put the annotation? I think it should NOT be in the
FXML-Package-Namespace because the core should NOT depend on FXML!
I'd go with @Argument or simply @NamedArgument (@Named is already used
by javax.inject)
Tom
Re: Constructor annotation
One thing that just came to my mind is that maybe also need a way to
define the default value to be used, with a builder I could e.g. define
that the default for fields are different from their real native default.
class MyBuilder {
private boolean a = true;
private int x = -1;
private Insets i = new Insets(10);
}
If we want to have a full replacement for builders the annotation must
have the possibility define this (in future).
public @interface NamedArgument {
String value();
String defaultValue();
ClassConverter converterClass();
}
If no converterClass is given we'd have to do our best to auto-convert
the String. I don't want to say that we should implement the default
value definition in FX8 but it would feel more natural with an
annotation per argument.
Tom
On 16.10.13 17:12, Tom Schindl wrote:
To me the JavaBean solution with one annotation looks error prone, does
anybody know why they did not use an annotation per field?
Tom
On 16.10.13 16:58, Stephen F Northover wrote:
+1 for base. Should we not follow closely what Java Beans is doing for
consistency? I realize that we can't have the reference.
Steve
On 2013-10-16 10:53 AM, Kevin Rushforth wrote:
Not to mention Tom's point that it can't be in the fxml module without
created unwanted (and circular) module dependencies. Seems like it
needs to be in the base module then, right?
-- Kevin
Richard Bair wrote:
+1 this is my preference. It is useful for things other than FXML,
and should be considered part of our javafx.beans API.
On Oct 16, 2013, at 4:20 AM, Tom Schindl
tom.schi...@bestsolution.at wrote:
On 16.10.13 11:22, Eva Krejcirova wrote:
Hi All,
when we retired builders, we caused a problem for FXML which doesn't
have a way to create classes without default constructors. Back
then we
decided to use an annotation for this but never actually got to
implement it and we need to fix this for FX8. I am in the process of
adding this functionality to FXMLLoader but we need to decide how the
annotation will look like and I could use some help with this.
We cannot use already existing ConstructorProperties for this, because
it's java.beans package and we don't want to create to dependency on
this package in JavaFX, so we need to introduce a new annotation.
We have two options:
1. Annotate the whole constructor:
e.g.
@ConstructorArguments({a, b, list})
public ImmutableClass(int a, int b, Integer... list)
2. Annotate the arguments:
e.g.
public ImmutableClass(@FXMLArgument(a) int a,
@FXMLArgument(b)int b, @FXMLArgument(list)Integer... list)
Which option do you like more and how should the annotation be named?
Option 2, but does it really have to hold FXML in the annotation name?
Where would you put the annotation? I think it should NOT be in the
FXML-Package-Namespace because the core should NOT depend on FXML!
I'd go with @Argument or simply @NamedArgument (@Named is already used
by javax.inject)
Tom
JavaFX on rPi iOS with RoboVM
Hi, I've been working on some samples for my presentation at EclipseCon Europe and wanted share my findings. 1. rpi (opendjk b113) - As a demo i used Gerrit Grunwalds imagerollover [1] which in principle works great but at a certain point crashes with an exception so something in the OpenGL implementation there does not work. You should be able to reproduce yourself by running the code. 2. iOS -- I've been running on jfx78 backport from about 2 weeks ago. I saw some commits for iOS but I don't think that matters. a) Image rollover I delambdarized Gerrits code to run on JDK6 (which RoboVM is) and while the animations are smooth (in the simulator and real iPad-Device) there's a lot of what Steve calls screenscheese. I don't think that RoboVM is the cause for this. b) Charts [2] PieCharts are not working completely there are certain segments in the pie missing (on the Simulator it is ok, on the device it is broken!), BarCharts work ok. x/y translate animations: animation them e.g. by sliding them in from is lags a lot. I know that charts are not the easiest components but anyways I think sliding a chart in and out must be smooth. fade animation: lags and is not smooth It might be that my animation code is not doing the right things [3] but I doubt that it is that wrong. I don't know how much Java-Bound this animation code is so RoboVM could be one cause of the problem although I doubt that because e.g. for the x/y translate animations the smaller the area I animate the smoother it gets. Tom [1]https://bitbucket.org/hansolo/imagerollover [2]http://tomsondev.bestsolution.at/2013/10/25/javafx-on-ios-with-the-help-of-robovm/ [3]http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.ui.mobile/src/org/eclipse/fx/ui/mobile/animations/TransitionDelegate.java
Re: JavaFX on rPi iOS with RoboVM
[...] x/y translate animations: animation them e.g. by sliding them in from is lags a lot. I know that charts are not the easiest components but anyways I think sliding a chart in and out must be smooth. In real english - Animating the charts by e.g. sliding them in from right to left lags a lot. I know that charts are not the simplest components but anyways I think sliding a chart in and out must be smooth! Tom
Re: enterNestedEventLoop as public API?
What bothers me with the API as it is today is that I have call
enter/exit, I would find it more easy to work with an API like:
---8---
WaitCondition c = new WaitCondition();
Dialog d = new Dialog() {
public void onClose() {
c.release();
}
}
Platform.spinNestedEventLoop(c);
---8---
Tom
On 13.11.13 11:18, Artem Ananiev wrote:
I also think it's a good request for public API. In AWT/Swing, people
had been using ugly workarounds with modal dialogs just to enter a
nested event loop, until public java.awt API was finally provided:
http://docs.oracle.com/javase/7/docs/api/java/awt/SecondaryLoop.html
http://docs.oracle.com/javase/7/docs/api/java/awt/EventQueue.html#createSecondaryLoop()
The same is here in JavaFX: unless Toolkit.enter/exitNestedEventLoop()
is exposed at javafx.* level, people will have to workaround it by using
Stage, or calling into com.sun.javafx.*, which is not good.
Thanks,
Artem
On 11/13/2013 10:15 AM, John Hendrikx wrote:
Hi List,
Any chance that Toolkit.getToolkit().enterNestedEventLoop() will in the
future become public API?
I'm currently using this to create Dialogs based on a Pane to avoid
creating Stages (which have the nice show and showAndWait
functionality). I duplicated this functionality in a Pane, allowing me
to create Dialogs on top of existing Scenes without creating a Stage,
and it makes use of the enterNestedEventLoop and exitNestedEventLoop
functions in com.sun.javafx.tk.Toolkit.
The reason I'm avoiding the Stages is because they donot play well with
an application that never has the mouse or keyboard focus (my
application is fully remote controlled) -- creating a Stage, even one to
just show a Dialog, will cause Windows to try and attract the user's
attention by flashing its taskbar button (for which I filed a
bug/feature request) and this is undesired.
Regards,
John
(Here's a part of the DialogPane to show and close it:)
public R showDialog(Scene scene, boolean synchronous) {
this.synchronous = synchronous;
this.scene = scene;
this.oldFocusOwner = scene.getFocusOwner();
Parent root = scene.getRoot();
stackPane.getChildren().add(root);
stackPane.getChildren().add(this);
scene.setRoot(stackPane);
requestFocus();
if(synchronous) {
return (R)Toolkit.getToolkit().enterNestedEventLoop(this);
}
return null;
}
public void close() {
Parent originalRoot = (Parent)stackPane.getChildren().remove(0);
scene.setRoot(originalRoot);
scene = null;
if(oldFocusOwner != null) {
oldFocusOwner.requestFocus();
}
if(synchronous) {
Toolkit.getToolkit().exitNestedEventLoop(this, getResult());
}
}
Re: enterNestedEventLoop as public API?
Currently the API requires to pass the same object to enter and exit how would
your code work with multiple nested event loops?
Tom
Von meinem iPhone gesendet
Am 13.11.2013 um 16:35 schrieb Stephen F Northover
steve.x.northo...@oracle.com:
What is the difference?
Dialog d = new Dialog() {
public void onClose() {
Platform.exitNestedEventLoop();
}
}
Platform.enterNestedEventLoop();
Steve
On 2013-11-13 5:28 AM, Tom Schindl wrote:
What bothers me with the API as it is today is that I have call
enter/exit, I would find it more easy to work with an API like:
---8---
WaitCondition c = new WaitCondition();
Dialog d = new Dialog() {
public void onClose() {
c.release();
}
}
Platform.spinNestedEventLoop(c);
---8---
Tom
On 13.11.13 11:18, Artem Ananiev wrote:
I also think it's a good request for public API. In AWT/Swing, people
had been using ugly workarounds with modal dialogs just to enter a
nested event loop, until public java.awt API was finally provided:
http://docs.oracle.com/javase/7/docs/api/java/awt/SecondaryLoop.html
http://docs.oracle.com/javase/7/docs/api/java/awt/EventQueue.html#createSecondaryLoop()
The same is here in JavaFX: unless Toolkit.enter/exitNestedEventLoop()
is exposed at javafx.* level, people will have to workaround it by using
Stage, or calling into com.sun.javafx.*, which is not good.
Thanks,
Artem
On 11/13/2013 10:15 AM, John Hendrikx wrote:
Hi List,
Any chance that Toolkit.getToolkit().enterNestedEventLoop() will in the
future become public API?
I'm currently using this to create Dialogs based on a Pane to avoid
creating Stages (which have the nice show and showAndWait
functionality). I duplicated this functionality in a Pane, allowing me
to create Dialogs on top of existing Scenes without creating a Stage,
and it makes use of the enterNestedEventLoop and exitNestedEventLoop
functions in com.sun.javafx.tk.Toolkit.
The reason I'm avoiding the Stages is because they donot play well with
an application that never has the mouse or keyboard focus (my
application is fully remote controlled) -- creating a Stage, even one to
just show a Dialog, will cause Windows to try and attract the user's
attention by flashing its taskbar button (for which I filed a
bug/feature request) and this is undesired.
Regards,
John
(Here's a part of the DialogPane to show and close it:)
public R showDialog(Scene scene, boolean synchronous) {
this.synchronous = synchronous;
this.scene = scene;
this.oldFocusOwner = scene.getFocusOwner();
Parent root = scene.getRoot();
stackPane.getChildren().add(root);
stackPane.getChildren().add(this);
scene.setRoot(stackPane);
requestFocus();
if(synchronous) {
return (R)Toolkit.getToolkit().enterNestedEventLoop(this);
}
return null;
}
public void close() {
Parent originalRoot = (Parent)stackPane.getChildren().remove(0);
scene.setRoot(originalRoot);
scene = null;
if(oldFocusOwner != null) {
oldFocusOwner.requestFocus();
}
if(synchronous) {
Toolkit.getToolkit().exitNestedEventLoop(this, getResult());
}
}
Compiling jfx78 backport for iOS
Hi, I'm failing to jfx78 backport. I'm executing the following command: gradle --debug -PCOMPILE_TARGETS=ios -PUSE_LIPO=true -PGENERATE_SYMBOLS=true -PBUILD_IOS_TOOLS=false -PIOS_VERSION=7.0 clean sdk Below is the log. I'm not sure but my guess is that the error comes from: 01:21:42.353 [ERROR] [system.err] Error: Class javafx.util.Duration could not be found. but the Duration.java is there in: ./modules/base/src/main/java/javafx/util/Duration.java Anyone an idea what's going wrong? 1:21:41.851 [DEBUG] [org.gradle.process.internal.ExecHandleRunner] waiting until streams are handled... 01:21:41.852 [INFO] [org.gradle.process.internal.DefaultExecHandle] Successfully started process 'command '/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/bin/javah'' 01:21:42.353 [ERROR] [system.err] Error: Class javafx.util.Duration could not be found. 01:21:42.363 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: FAILED 01:21:42.363 [INFO] [org.gradle.process.internal.DefaultExecHandle] Process 'command '/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/bin/javah'' finished with exit value 1 (state: FAILED) 01:21:42.364 [DEBUG] [org.gradle.logging.internal.DefaultLoggingConfigurer] Finished configuring with level: DEBUG, configurers: [org.gradle.logging.internal.OutputEventRenderer@560c9447, org.gradle.logging.internal.logback.LogbackLoggingConfigurer@53daed73, org.gradle.logging.internal.JavaUtilLoggingConfigurer@4a1b4407] 01:21:42.364 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire exclusive lock on task artifact state cache (/Users/tomschindl/Documents/e-workspaces/robovm/jfx78/.gradle/1.4/taskArtifacts). 01:21:42.364 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired. 01:21:42.364 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Finished executing task ':extensions:javahIosExtensions' 01:21:42.365 [LIFECYCLE] [org.gradle.TaskExecutionLogger] :extensions:javahIosExtensions FAILED 01:21:42.370 [ERROR] [org.gradle.BuildExceptionReporter] 01:21:42.371 [ERROR] [org.gradle.BuildExceptionReporter] FAILURE: Build failed with an exception. 01:21:42.371 [ERROR] [org.gradle.BuildExceptionReporter] 01:21:42.371 [ERROR] [org.gradle.BuildExceptionReporter] * What went wrong: 01:21:42.371 [ERROR] [org.gradle.BuildExceptionReporter] Execution failed for task ':extensions:javahIosExtensions'. 01:21:42.371 [ERROR] [org.gradle.BuildExceptionReporter] Process 'command '/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/bin/javah'' finished with non-zero exit value 1 01:21:42.375 [ERROR] [org.gradle.BuildExceptionReporter] 01:21:42.375 [ERROR] [org.gradle.BuildExceptionReporter] * Exception is: 01:21:42.376 [ERROR] [org.gradle.BuildExceptionReporter] org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':extensions:javahIosExtensions'. 01:21:42.376 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:72) 01:21:42.377 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:49) 01:21:42.377 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:34) 01:21:42.377 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.changedetection.CacheLockHandlingTaskExecuter$1.run(CacheLockHandlingTaskExecuter.java:34) 01:21:42.377 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.internal.Factories$1.create(Factories.java:22) 01:21:42.378 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.cache.internal.DefaultCacheAccess.longRunningOperation(DefaultCacheAccess.java:179) 01:21:42.378 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.cache.internal.DefaultCacheAccess.longRunningOperation(DefaultCacheAccess.java:232) 01:21:42.378 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.cache.internal.DefaultPersistentDirectoryStore.longRunningOperation(DefaultPersistentDirectoryStore.java:142) 01:21:42.378 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.changedetection.DefaultTaskArtifactStateCacheAccess.longRunningOperation(DefaultTaskArtifactStateCacheAccess.java:83) 01:21:42.378 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.changedetection.CacheLockHandlingTaskExecuter.execute(CacheLockHandlingTaskExecuter.java:32) 01:21:42.379 [ERROR] [org.gradle.BuildExceptionReporter] at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:55) 01:21:42.379 [ERROR]
libjfxmedia.a libextensions_ios.a
Hi, In case I try to link both of them into my application. I get duplicate symbol errors: [exec] duplicate symbol _OBJC_IVAR_$_IPodAccess.query in: [exec] /Users/tomschindl/git/ece_2013/iFondApp/robovm-build/jfx78/libextensions_ios.a(iPodAccess.obj) [exec] /Users/tomschindl/git/ece_2013/iFondApp/robovm-build/jfx78/libjfxmedia.a(iPodAccess.obj) [exec] duplicate symbol _OBJC_CLASS_$_IPodAccess in: [exec] /Users/tomschindl/git/ece_2013/iFondApp/robovm-build/jfx78/libextensions_ios.a(iPodAccess.obj) [exec] /Users/tomschindl/git/ece_2013/iFondApp/robovm-build/jfx78/libjfxmedia.a(iPodAccess.obj) [exec] duplicate symbol _OBJC_METACLASS_$_IPodAccess in: [exec] /Users/tomschindl/git/ece_2013/iFondApp/robovm-build/jfx78/libextensions_ios.a(iPodAccess.obj) [exec] /Users/tomschindl/git/ece_2013/iFondApp/robovm-build/jfx78/libjfxmedia.a(iPodAccess.obj) Any idea? Tom
Re: Scene Builder is now open source!
Amazing News! Von meinem iPhone gesendet Am 03.12.2013 um 16:04 schrieb Simon Vienot simon.vie...@oracle.com: Hello OpenJFXers ! We're very happy to announce that Scene Builder is now open source, as a part of the OpenJFX project. The whole Scene Builder functionality is available, including the SB Kit API as well as the standalone SB application. The only part of the product which remains closed is the native packaging/installer code. SB code is available in rt/apps/scenebuilder/ under the terms of a BSD-style license, similar to JavaFX samples. You are all welcome to contribute. Thanks, -Simon.
Re: 8 review request: RT-34389: [doc] cssref.html copyright is incorrect
Hi Kevin, I checked the file at http://cr.openjdk.java.net/~kcr/RT-34389/javafx-samples-8.0.0-ea/src/Ensemble8/cssref/cssref.html and this is what I would expect to get! Tom On 07.12.13 18:41, Kevin Rushforth wrote: David, Please review the following: https://javafx-jira.kenai.com/browse/RT-34389 Tom: can you make sure that the output is what you expect? Thanks. -- Kevin
Re: Reloading stylesheets
That doesn't work in 2.x because the CSS is cached on a scene base! A trick that could work is to load the CSS with an URL like this like: my.css?timestamp=123456789 but I have not tried that and don't know if this would work. Tom On 10.12.13 13:41, Scott Palmer wrote: Have you tried simply removing and re-adding the stylesheet to the scene? Scott On Tue, Dec 10, 2013 at 7:21 AM, Werner Lehmann lehm...@media-interactive.de wrote: Hi, is there a way to reload previously loaded stylesheets (in FX2)? Currently I have to restart the application each time I am changing the css. It would be nice to just close and reopen that window instead to see the new styles. I'd like to unload css automatically when closing a window - in debug mode - in order to avoid the application restart. Or, even better, define a hotkey to update css immediately. Much like shift+ctrl+8 for ScenicView (only works in FX2 as far as I know). Rgds Werner
Re: Reloading stylesheets
No on FX8 you need to remove and readd them! So the only thing different
is that you omit the reload-call on FX8.
Tom
On 10.12.13 16:10, Werner Lehmann wrote:
Got it. The key was to move the stylesheets from the root node to the
scene before reloading them:
scene.styleSheets.clear
scene.styleSheets.addAll(root.styleSheets)
root.styleSheets.clear
styleManager.reload(scene)
The hotkey also works now: shift+ctrl+7 reloads CSS while the scene is
visible. This works by using a custom scene, overriding
impl_processKeyEvent. Even better would be automatic change-detection
(in debug mode only) but I don't have time to do this now. Previously
you said that reloading is not needed on FX8... does this work out of
the box then?
Werner
On 10.12.2013 14:10, Tom Schindl wrote:
My code does:
// Force CSS-Reloading
if( isJavaFX2() ) {
ReflectiveInvoke.onStyleManagerClass(scene);
}
scene.getStylesheets().clear();
scene.getStylesheets().addAll(contentData.cssFiles);
A difference I see is that your stylesheets are on the Root-Container
whereas mine are directly on the Scene.
Tom
JavaFX JavaDoc and IDEs
Hi,
I can't speak for Netbeans and IntelliJ but now that JavaFX ships the
source with the JDK and Eclipse recgonizes this there's a small
problem with the way JavaFX is using JavaDoc.
Take for example Window#onCloseRequest
/**
* Called when there is an external request to close this {@code Window}.
* The installed event handler can prevent window closing by consuming the
* received event.
*/
private ObjectPropertyEventHandlerWindowEvent onCloseRequest;
public final void setOnCloseRequest(EventHandlerWindowEvent value) {
onCloseRequestProperty().set(value);
}
public final EventHandlerWindowEvent getOnCloseRequest() {
return (onCloseRequest != null) ? onCloseRequest.get() : null;
}
public final ObjectPropertyEventHandlerWindowEvent
onCloseRequestProperty() {
You'll notice that the documentation is only made on the property but
not on the real API methods.
I guess the build process copies the documentation somehow at the right
position when generating the doc (see
http://docs.oracle.com/javafx/2/api/javafx/stage/Window.html#setOnCloseRequest%28javafx.event.EventHandler%29)
which doesn't help people with an (Eclipse)IDE which takes the source
code as the authority and presents an empty JavaDoc window :-(
This is a major feature loss!
Tom
Re: JavaFX JavaDoc and IDEs
Hi Kevin,
I guess there's no formal spec for this? Maybe at least
http://download.java.net/jdk8/docs/technotes/tools/windows/javadoc.html
should mention this? Maybe this impossible because FX is JSRed?
Tom
On 17.12.13 23:48, Kevin Rushforth wrote:
That's basically what the doclet does. Here is the JDK JIRA for this
(first introduced in 7u6...I hadn't remembered it was that early):
https://bugs.openjdk.java.net/browse/JDK-7112427
And here is the JDK 8 changeset that implements it:
http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/ccbe7ffdd867
-- Kevin
Tom Schindl wrote:
So you say the IDEs must learn that when they encounter a method which
has no JavaDoc to search for the property definition and show that one?
Tom
On 17.12.13 23:12, Kevin Rushforth wrote:
Actually, the JDK 8 doclet that handles this automatically. They added
support for FX-style properties, among other things, in JDK 8 so we no
longer have a custom doclet for FX.
-- Kevin
Tom Schindl wrote:
Hi,
I can't speak for Netbeans and IntelliJ but now that JavaFX ships the
source with the JDK and Eclipse recgonizes this there's a small
problem with the way JavaFX is using JavaDoc.
Take for example Window#onCloseRequest
/**
* Called when there is an external request to close this {@code
Window}.
* The installed event handler can prevent window closing by
consuming the
* received event.
*/
private ObjectPropertyEventHandlerWindowEvent onCloseRequest;
public final void setOnCloseRequest(EventHandlerWindowEvent value) {
onCloseRequestProperty().set(value);
}
public final EventHandlerWindowEvent getOnCloseRequest() {
return (onCloseRequest != null) ? onCloseRequest.get() : null;
}
public final ObjectPropertyEventHandlerWindowEvent
onCloseRequestProperty() {
You'll notice that the documentation is only made on the property but
not on the real API methods.
I guess the build process copies the documentation somehow at the right
position when generating the doc (see
http://docs.oracle.com/javafx/2/api/javafx/stage/Window.html#setOnCloseRequest%28javafx.event.EventHandler%29)
which doesn't help people with an (Eclipse)IDE which takes the source
code as the authority and presents an empty JavaDoc window :-(
This is a major feature loss!
Tom
Font.font() says it is point size but it looks like it are pixels
Hi,
The JavaDoc of Font.font says:
-8-
size - The point size of the font. This can be a fractional value, but
must not be negative. If the size is 0 the default size will be used.
-8-
I highly doubt this is correct (see attached picture from Linux where
you see native, qt and javafx) and a sample FX-Code using setFont and
using CSS (see at the end of this mail)
The result is correct if CSS is used and looking up the code in the CSS
shows that values are calculated back to pixels when passed to the
Font-factory method (FontConverter.convert!).
I guess one can not fix this Font.font API to really work with points
(which would be the natural expectation at least to me) but the JavaDoc
has to be fixed!
Another thing I came across is that the DPI calculation is fixed to 96
DPI - which i don't fully understand why it is fixed because the DPI can
vary between devices and monitors. Is this because of multi-monitors and
you are applying a transformation based on the screen the text is
rendered on?
Tom
---
HBox h = new HBox();
{
Text t = new Text(Hello World);
t.setFont(Font.font(50));
h.getChildren().add(t);
}
{
Text t = new Text(Hello World);
t.setStyle(-fx-font-size: 50pt;);
h.getChildren().add(t);
}
primaryStage.setScene(new Scene(h,300,300));
primaryStage.show();
Re: custom FXML builders in SceneBuilder
IIRC we agreed while talking about the annotation replacement for builders that we'll later add a possibility to set a converter on properties through annotations - back then we only talked about constructors but this could be expanded to any property. Tom On 03.01.14 12:12, Tom Eugelink wrote: I think there are two usages of builders: - construct compontents / controls programatically (ending in the build() call). - mapping of FXML attributes to node properties, because in FXML everything must be a string. For example, CalendarTextField has no builder class in the first sense (I used withers for that), but does have a class that converts the dateFormats (list of SimpleDateFormat strings) in an fxml file to an actual list of DateFormats instances. https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/java/jfxtras/labs/fxml/CalendarTextFieldBuilder.java If you can explain to me how to do this without a builder, but also without polluting CalendarTextField with FXML aspects, then I'll change the code. Tom On 2014-1-3 11:44, Eric Le Ponner wrote: When Scene Builder 2.0 found a custom components, it instantiates it using FXMLLoader without making any specific builder setup. So FXMLLoader uses the default JavaFX builder factory. Since builders are deprecated, I'm not sure it make sense for SB to have dependency on them. Eric Le 3 janv. 2014 à 10:55, Tom Eugelink t...@tbee.org a écrit : I had no problems adding the JFXtras components to SceneBuilder, but one of the controls has a custom FXML builder. It is present in the same jar, but how do I tell SceneBuilder to use it? Now when I try to load an fxml file an exception (unable to coerse) is shown by SceneBuilder. Tom
Re: Android Port: Next Steps
Have you managed to get an JavaFX running on the emulator. I've tested with one of ours and while it works great on the real device. It crashes in the emulator. V/GLASS ( 1121): JNI call notifyViewEvent to lensView 0x1d30041a W/System.err( 1121): java.lang.UnsupportedOperationException: Pixel format BYTE_BGRA_PRE not supported on this device W/System.err( 1121): at com.sun.prism.es2.ES2Texture.create(ES2Texture.java:103) W/System.err( 1121): at com.sun.prism.es2.ES2ResourceFactory.createTexture(ES2ResourceFactory.java:86) W/System.err( 1121): at com.sun.prism.impl.ps.PaintHelper.initGradientTextures(PaintHelper.java:118) W/System.err( 1121): at com.sun.prism.impl.ps.PaintHelper.getGradientTexture(PaintHelper.java:141) W/System.err( 1121): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:450) W/System.err( 1121): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:385) W/System.err( 1121): at com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedPgram(BaseShaderGraphics.java:847) W/System.err( 1121): at com.sun.prism.impl.ps.BaseShaderGraphics.renderGeneralRoundedRect(BaseShaderGraphics.java:607) W/System.err( 1121): at com.sun.prism.impl.ps.BaseShaderGraphics.fillRoundRect(BaseShaderGraphics.java:1549) W/System.err( 1121): at com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectanglesDirectly(NGRegion.java:1110) W/System.err( 1121): at com.sun.javafx.sg.prism.NGRegion.renderBackgroundRectangle(NGRegion.java:847) W/System.err( 1121): at com.sun.javafx.sg.prism.NGRegion.renderAsRectangle(NGRegion.java:750) W/System.err( 1121): at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:571) W/System.err( 1121): at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2043) W/System.err( 1121): at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1951) W/System.err( 1121): at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:225) W/System.err( 1121): at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) W/System.err( 1121): at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2043) W/System.err( 1121): at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1951) W/System.err( 1121): at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:225) W/System.err( 1121): at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) W/System.err( 1121): at com.sun.javafx.sg.prism.NGNode.renderForClip(NGNode.java:2282) W/System.err( 1121): at com.sun.javafx.sg.prism.NGNode.renderRectClip(NGNode.java:2176) W/System.err( 1121): at com.sun.javafx.sg.prism.NGNode.renderClip(NGNode.java:2202) W/System.err( 1121): at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2037) W/System.err( 1121): at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1951) W/System.err( 1121): at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:225) W/System.err( 1121): at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:575) W/System.err( 1121): at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2043) W/System.err( 1121): at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1951) W/System.err( 1121): at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:469) W/System.err( 1121): at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:324) W/System.err( 1121): at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:97) W/System.err( 1121): at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:422) W/System.err( 1121): at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:279) W/System.err( 1121): at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) W/System.err( 1121): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112) W/System.err( 1121): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587) W/System.err( 1121): at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129) W/System.err( 1121): at java.lang.Thread.run(Thread.java:841) I have to say that I've never seen a crapier thing than this emulator. Could we produce x86 binaries so that we can use genymotion? Tom On 09.01.14 11:05, Johan Vos wrote: Hi Steve, Doing this step by step, we probably need a solution on the use of JDK 8 language features first. As you mentioned in https://javafx-jira.kenai.com/browse/RT-35165, there is probably (unfortunately) no real option apart from having different source directories. How do we tackle this? I think we only need to have the affected files in a different directory, but then we need a build mechanism that use the alternate directory first in the Android(/iOS?) case. How can this be done without polluting the build system? Also, we need to make sure that general changes in affected
Re: OpenGL on Windows
Would it be better to work on a jogl prism pipeline itself? Tom Von meinem iPhone gesendet Am 14.01.2014 um 16:15 schrieb Stephen F Northover steve.x.northo...@oracle.com: It should all just work. The first step is to go and build OpenJFX. If something doesn't work, we can help you through JIRA and this list. Steve On 2014-01-14 6:57 AM, Felix Bembrick wrote: Thanks Stephen. If I were to build an OpenGL-based platform for Windows, would the font rendering technique need to change? That is, could DirectWrite still be used to rasterise the glyphs (if that's what's currently happening) and would there be any reason for the text rendering quality to degrade? You mentioned that ES2 code is not there: was that just an example or will I really have to address this problem? Thanks, Felix On 14 January 2014 06:28, Stephen F Northover steve.x.northo...@oracle.com mailto:steve.x.northo...@oracle.com wrote: Essentially, OpenGL on Windows would be another platform to support. If you build your own OpenJFX for Windows, it will work but it is completely unsupported. https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX If you run into any problems after you have successfully built (ie. the ES2 code is not there), open a JIRA request for OpenGL support on Windows and we can follow up there. Even if we don't fix the JIRA, we can capture the information for other that might want to do the same thing. Steve On 2014-01-13 1:19 PM, Felix Bembrick wrote: Having watched the presentation from Stephen and Felipe about integrating JavaFX and native technologies such as OpenGL, I am inspired to work on a solution for my own needs for fast rendering of thousands of objects using the techniques in the video which I would then contribute to the community. However, it's quite clear that any OpenGL based solution is not going to work on Windows because OpenGL is not enabled on that platform. Given that I don't want to write code that supports both OpenGL and D3D, could someone answer these questions? 1. Why is OpenGL not enabled on Windows? Is it a performance thing? Is it because of poor text rendering with OpenGL? 2. What's involved in hacking Prism to enable OpenGL? 3. If 2 is not possible, is there some way to develop an abstraction layer on top of both OpenGL and D3D? Thanks, Felix
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
On 22.01.14 11:07, Martin Sladecek wrote:
Hi all,
I would like to start discussion about an addition to API in Observable,
ObservableValue and all Observable collections.
There were multiple requests for a way how to avoid duplicates in
listeners lists. The way RT-25613 solves this is that it introduces
public boolean hasListener(ListenerType listener) which would return
true if the provided listener is already registered.
This has one significant drawback that all of Observable* are actually
interfaces. Means we can only add hasListener as a defender method. The
problem is with the default implementation. We cannot return anything
meaningful, so we have to throw an UnsupportedOperationException. The
problem is that this might blow up unexpectedly when some older
Observable implementation is used. Also, it might be easy to miss when
implementing the interface, since the IDE might not force you to
implement it.
So as an alternative solution, I propose adding something like:
ensureListener(ListenerType listener)
which would make sure the listener is on the list and if a listener is
already present, the number of times listener is registered on the
Observable will NOT grow after this call.
The default implementation (for Observable) would look like this:
public default void ensureListener(InvalidationListener listener) {
removeListener(listener);
addListener(listener);
}
subclasses might do something more effective. The same would apply to
ObservableValue and ChangeListener and Observable[List|Set|Map] and
[List|Set|Map]ChangeListener.
Well this would destroy the order! I expect listeners to be called in
the correct order not? Why doing a remove and not simply check if the
listener has already been added?
Tom
Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method
[...] Actually even when you would rely on the order, in situations when you call ensureListener, you don't really know if the listener is already there. So you might really expect that listener would be added at this point as the last. It's just that will always be the outcome if the default implementation is used. It would be even worse if this would be different in none default implementations. Tom
Re: -fx-background
Right - this would help tools as well because currently it is a bit hard to identify them - problem is that current names can not be changed. At least having a (structured) documentation above variables would certainly help! Tom On 19.02.14 01:18, Pedro Duque Vieira wrote: I found out what it is.. sorry if I made anyone waist there time. It is a css variable that is being defined and not a css property. Perhaps having some convention of starting variables differently than -fx- would make tracking down which ones are variables and which ones are css properties easier. On Wed, Feb 19, 2014 at 12:11 AM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: Hi, Inside the javafx sdk in modena.css I see this property -fx-background being used several times. This is not documented in the css document for javafx8: http://download.java.net/jdk8/jfxdocs/javafx/scene/doc-files/cssref.html#cell What does it do? Thanks in advance, -- Pedro Duque Vieira
Re: hg: openjfx/8u-dev/rt: RT-34472 Add annotation processor for @FXML annotation
Can you make the bug public? Tom On 25.02.14 12:48, hang...@oracle.com wrote: Changeset: 876e334f748a Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-02-25 12:41 +0100 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/876e334f748a RT-34472 Add annotation processor for @FXML annotation Reviewed by: dgrieve + modules/fxml/src/main/java/com/sun/javafx/fxml/annotation/FXMLAnnotationProcessor.java + modules/fxml/src/main/resources/META-INF/services/javax.annotation.processing.Processor
Re: CSS Font size in points doesn't match Node.Font.Size
There was a thread some time ago on this List with explainations of this behavior! Tom Von meinem iPhone gesendet Am 05.03.2014 um 01:03 schrieb Jeff Martin j...@reportmill.com: I can't quite wrap my head around why when I specify an -fx-font-size of 9pt in CSS, it turns into a 12 pt font in my rendered node. I suppose CSS is upscaling for my 96 dpi device, but it makes other measurements that depend on that setting potentially wrong. Any suggestions on how I should be thinking about this (other than that this is a bug :-)? jeff
Re: CSS Font size in points doesn't match Node.Font.Size
From my tests the font size generated by CSS is what one gets with the same point size and font using native apps and Qt - my complaint was the font size when using the Java API. Tom Von meinem iPhone gesendet Am 05.03.2014 um 23:03 schrieb Felipe Heidrich felipe.heidr...@oracle.com: The problem is that point size used by Node and point size used by CSS are not the same. One uses a 72 DPI and the other 96. Thus the final pixel sizes are different. I don’t see how to change one or the other without breaking a ton of people. Maybe adding a global font DPI so that Node can be made to match CSS ? Suggestions ? Felipe On Mar 5, 2014, at 12:39 PM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: Hi Tom, Jeff, Felipe... Having bugs stay in to maintain backwards compatibility sounds very weird to me IMHO. If we go down that road aren't we creating a library that will some day have too many glitches and as such less appeal to programmers looking for UI libraries? Thanks, Hi On Mar 4, 2014, at 4:42 PM, Jeff Martin j...@reportmill.com wrote: Thanks Tom! I assume the thread was this one: Font.font() says it is point size but it looks like it are pixels http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-January/012398.html I guess the final word is that CSS assumes 1pt==1/92in, Yes and Nodes convert that to the real world on render? On the printer yes, on the display it assumes 72 (pt=px). And that this is basically a bug, but it can't be fixed due to legacy considerations? Yes Felipe -- Pedro Duque Vieira
Opacity in Image.getPixelReader.getColor()
Hi,
Maybe I'm completely wrong but to me it looks like the opacity I get
from Image.getPixelReader.getColor() is wrong.
If not mistaken the relation between alpha and opacity is expressed with:
opacity = (255 - alpha) / 255.0
which means:
opacity 0 = alpha 255
opacity 1 = alpha 0
Running the following programm on a gif
public class OpacityBug extends Application {
@Override
public void start(Stage primaryStage) throws Exception {
Image image = new
Image(getClass().getResourceAsStream(methpri_obj.gif));
int width = (int) image.getWidth();
int height = (int) image.getHeight();
PixelReader reader = image.getPixelReader();
for (int x = width - 1; x = 0; x--) {
for (int y = height - 1; y = 0; y--) {
int argb = reader.getArgb(x, y);
int alphaArgb = (argb 24) 0xFF;
Color color = reader.getColor(x, y);
double opacity = color.getOpacity();
System.err.println(x+,+y + = alpha: +
alphaArgb + op: + opacity + op-alpha: + opacityToAlpha(opacity) +
color: + color);
}
}
}
private static int opacityToAlpha(double opacity) {
return (int)Math.roundopacity * 255.0) - 255) * -1));
}
public static void main(String[] args) {
Application.launch(args);
}
}
produces and output like:
15,15 = alpha: 0 op: 0.0 op-alpha: 255 color: 0x
which to my understanding is wrong. The argb value is correct (if
compared to the image because the pixel at 15,15 is fully transparent)
but then the the opacity should be 1.0 but is the opposite.
Looking at the code in Image I see:
@Override
public Color getColor(int x, int y) {
int argb = getArgb(x, y);
int a = argb 24;
int r = (argb 16) 0xff;
int g = (argb 8) 0xff;
int b = (argb ) 0xff;
return Color.rgb(r, g, b, a / 255.0);
}
which means that:
a) my formula from the above is wrong
b) or there's the bug because it should be
return Color.rgb(r, g, b, (255 - a) / 255.0);
May I also suggest to add get a
- Color.argb(int r,int g,int b,int alpha)
maybe it is just me but I'm so much more used to alpha than opacity that
I always have to look it up when i need it.
Tom
Re: Opacity in Image.getPixelReader.getColor()
Hi,
Yes it looks like i mixed this up with transparency!
Tom
On 17.03.14 10:03, Kevin Rushforth wrote:
I'm sure Jim could word this better, but here goes...
Opacity and alpha are mostly used interchangeably. Whether the range is
expressed as a normalized value [0.0,1.0] or an 8-bit pixel value
[0,255], the meaning is the same. A value of 0 means that the color is
completely transparent. When using the default SRC_OVER blend equation,
a pixel with this color will have no effect. A value of 1.0 (if using a
normalized value) or 255 (if using an 8-bit integer value) means that
the color is fully opaque. When using the default SRC_OVER blend
equation, a pixel with this color will overwrite whatever is underneath it.
Perhaps Tom is thinking of transparency which, if we were to have such
an attribute, would be defined as (1.0-opacity).
-- Kevin
Jasper Potts wrote:
My understanding is alpha and opacity are same just different range.
Opacity is 0.0 to 1.0
Alpha is 0 to 255
Jim or Kevin will be authority on this.
Jasper
On Mar 16, 2014, at 5:55 AM, Tom Schindl
tom.schi...@bestsolution.at wrote:
Hi,
Maybe I'm completely wrong but to me it looks like the opacity I get
from Image.getPixelReader.getColor() is wrong.
If not mistaken the relation between alpha and opacity is expressed
with:
opacity = (255 - alpha) / 255.0
which means:
opacity 0 = alpha 255
opacity 1 = alpha 0
Running the following programm on a gif
public class OpacityBug extends Application {
@Override
public void start(Stage primaryStage) throws Exception {
Image image = new
Image(getClass().getResourceAsStream(methpri_obj.gif));
int width = (int) image.getWidth();
int height = (int) image.getHeight();
PixelReader reader = image.getPixelReader();
for (int x = width - 1; x = 0; x--) {
for (int y = height - 1; y = 0; y--) {
int argb = reader.getArgb(x, y);
int alphaArgb = (argb 24) 0xFF;
Color color = reader.getColor(x, y);
double opacity = color.getOpacity();
System.err.println(x+,+y + = alpha: +
alphaArgb + op: + opacity + op-alpha: +
opacityToAlpha(opacity) + color: + color);
}
}
}
private static int opacityToAlpha(double opacity) {
return (int)Math.roundopacity * 255.0) - 255) * -1));
}
public static void main(String[] args) {
Application.launch(args);
}
}
produces and output like:
15,15 = alpha: 0 op: 0.0 op-alpha: 255 color: 0x
which to my understanding is wrong. The argb value is correct (if
compared to the image because the pixel at 15,15 is fully transparent)
but then the the opacity should be 1.0 but is the opposite.
Looking at the code in Image I see:
@Override
public Color getColor(int x, int y) {
int argb = getArgb(x, y);
int a = argb 24;
int r = (argb 16) 0xff;
int g = (argb 8) 0xff;
int b = (argb ) 0xff;
return Color.rgb(r, g, b, a / 255.0);
}
which means that:
a) my formula from the above is wrong
b) or there's the bug because it should be
return Color.rgb(r, g, b, (255 - a) / 255.0);
May I also suggest to add get a
- Color.argb(int r,int g,int b,int alpha)
maybe it is just me but I'm so much more used to alpha than opacity that
I always have to look it up when i need it.
Tom
Proposal on getting warning free (controls) packages
Hi,
I've just started looking into getting the controls package warning free
and/or suppress them in case not fixable.
Most of the generic warnings I've come accross in a first pass involve
StyleableProperty cast like this:
((StyleableProperty)graphicProperty()).applyStyle(origin, null);
In fact above code has 2 warnings:
a) unchecked type cast
b) usage of raw-type
the raw type in this case can be fixed with:
((StyleablePropertyNode)graphicProperty()).applyStyle(origin, null);
leaving us with the unchecked cast so we could add:
@SuppressWarnings({ unchecked })
e.g. on the method but I'm uncertain this is a good idea because it
might hide unchecked warnings we have a possibility to fix.
So what are other options:
a) Create a static helper in Util to make the cast and for us (we could
even add it as a static method in the StyleableProperty-interface)
b) provide a private/package-scoped method the public one delegates
Both of them work but have different problems where I think b) has the
bigger ones like blowing up class-file, modification of the field to be
of type StyleableObjectProperty.
I'd really like to get the source warning free.
Thoughts?
Tom
Re: Lambda Lambda
If I do that in eclipse and hover it I see it still attaches a InvalidationListener! To me it looks like the compiler does not care about what you are trying to tell him because this syntax does only have a meaning on methods who don't declare a generic type in its signature! Tom On 20.03.14 13:03, Scott Palmer wrote: n.managedProperty().ChangeListeneraddListener(x - test(x));
Re: *PropertyBase vs Simple*Property
Hi Richard,
Coming back to this old thread and now that we are using lamdas all over
I guess we could take one more look into that.
I've prototyped an initial version by introducing a new internal type
named InvalidatedSimpleObjectProperty (not the best name ever!) - see
code pasted below.
And now one can write code like this:
public final ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new InvalidatedSimpleObjectProperty(this,
viewport, (o) - {
invalidateWidthHeight();
impl_markDirty(DirtyBits.NODE_VIEWPORT);
impl_geomChanged();
} );
}
return viewport;
}
instead of
public final ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new ObjectPropertyBaseRectangle2D() {
@Override
protected void invalidated() {
invalidateWidthHeight();
impl_markDirty(DirtyBits.NODE_VIEWPORT);
impl_geomChanged();
}
@Override
public Object getBean() {
return ImageView.this;
}
@Override
public String getName() {
return viewport;
}
};
}
return viewport;
}
Which allows us to get rid of most of the ObjectPropertyBase sublcasses.
Tom
package com.sun.javafx.property;
import java.util.function.Consumer;
import javafx.beans.property.SimpleObjectProperty;
public final class InvalidatedSimpleObjectPropertyT extends
SimpleObjectPropertyT {
private final ConsumerInvalidatedSimpleObjectPropertyT
invalidationConsumer;
/**
* The constructor of {@code ObjectProperty}
*
* @param initialValue
*the initial value of the wrapped value
* @param invalidationConsumer
* the consumer to be called when the bean is
invalidated
*/
public InvalidatedSimpleObjectProperty(T initialValue, final
ConsumerInvalidatedSimpleObjectPropertyT invalidationConsumer) {
super(initialValue);
if( invalidationConsumer == null ) {
throw new IllegalArgumentException(Consumer can not be null);
}
this.invalidationConsumer = invalidationConsumer;
}
/**
* The constructor of {@code ObjectProperty}
*
* @param bean
*the bean of this {@code ObjectProperty}
* @param name
*the name of this {@code ObjectProperty}
* @param invalidationConsumer
* the consumer to be called when the bean is
invalidated
*/
public InvalidatedSimpleObjectProperty(Object bean, String name, final
ConsumerInvalidatedSimpleObjectPropertyT invalidationConsumer) {
super(bean, name);
if( invalidationConsumer == null ) {
throw new IllegalArgumentException(Consumer can not be null);
}
this.invalidationConsumer = invalidationConsumer;
}
/**
* The constructor of {@code ObjectProperty}
*
* @param bean
*the bean of this {@code ObjectProperty}
* @param name
*the name of this {@code ObjectProperty}
* @param initialValue
*the initial value of the wrapped value
* @param invalidationConsumer
* the consumer to be called when the bean is
invalidated
*/
public InvalidatedSimpleObjectProperty(Object bean, String name, T
initialValue, final ConsumerInvalidatedSimpleObjectPropertyT
invalidationConsumer) {
super(bean,name,initialValue);
if( invalidationConsumer == null ) {
throw new IllegalArgumentException(Consumer can not be null);
}
this.invalidationConsumer = invalidationConsumer;
}
@Override
protected void invalidated() {
invalidationConsumer.accept(this);
}
}
On 22.01.13 10:30, Richard Bair wrote:
Is the Java8 plan still there if not should the current Simple*Property
subclasses who overload invalidated be changed to PropertyBase?
It is unlikely that we'll be able to do anything major here in Java 8 just
because we don't really have Lambda yet that we can play with, and changing
over every property is a big job. Unless we knew it would be a major win. I
would say, if you encounter a Simple* property that has been subclassed, then
we should fix it up as we go to be a PropertyBase* guy instead.
Re: *PropertyBase vs Simple*Property
Why not i expect the property to be fully initialize so this would be a
breaking change in behavior.
Tom
Von meinem iPhone gesendet
Am 22.03.2014 um 14:54 schrieb Tomas Mikula tomas.mik...@gmail.com:
On Fri, Mar 21, 2014 at 8:53 PM, Tom Schindl
tom.schi...@bestsolution.at wrote:
Hi Richard,
Coming back to this old thread and now that we are using lamdas all over
I guess we could take one more look into that.
I've prototyped an initial version by introducing a new internal type
named InvalidatedSimpleObjectProperty (not the best name ever!) - see
code pasted below.
And now one can write code like this:
public final ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new InvalidatedSimpleObjectProperty(this,
viewport, (o) - {
invalidateWidthHeight();
impl_markDirty(DirtyBits.NODE_VIEWPORT);
impl_geomChanged();
} );
}
return viewport;
}
instead of
public final ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new ObjectPropertyBaseRectangle2D() {
@Override
protected void invalidated() {
invalidateWidthHeight();
impl_markDirty(DirtyBits.NODE_VIEWPORT);
impl_geomChanged();
}
@Override
public Object getBean() {
return ImageView.this;
}
@Override
public String getName() {
return viewport;
}
};
}
return viewport;
}
Nice idea. Just to get the comparison to status quo more fair, you
don't need to override getBean() and getName() methods:
public final ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new SimpleObjectPropertyRectangle2D(this, viewport) {
@Override
protected void invalidated() {
invalidateWidthHeight();
impl_markDirty(DirtyBits.NODE_VIEWPORT);
impl_geomChanged();
}
};
}
return viewport;
}
Regards,
Tomas
Which allows us to get rid of most of the ObjectPropertyBase sublcasses.
Tom
package com.sun.javafx.property;
import java.util.function.Consumer;
import javafx.beans.property.SimpleObjectProperty;
public final class InvalidatedSimpleObjectPropertyT extends
SimpleObjectPropertyT {
private final ConsumerInvalidatedSimpleObjectPropertyT
invalidationConsumer;
/**
* The constructor of {@code ObjectProperty}
*
* @param initialValue
*the initial value of the wrapped value
* @param invalidationConsumer
* the consumer to be called when the bean is
invalidated
*/
public InvalidatedSimpleObjectProperty(T initialValue, final
ConsumerInvalidatedSimpleObjectPropertyT invalidationConsumer) {
super(initialValue);
if( invalidationConsumer == null ) {
throw new IllegalArgumentException(Consumer can not be null);
}
this.invalidationConsumer = invalidationConsumer;
}
/**
* The constructor of {@code ObjectProperty}
*
* @param bean
*the bean of this {@code ObjectProperty}
* @param name
*the name of this {@code ObjectProperty}
* @param invalidationConsumer
* the consumer to be called when the bean is
invalidated
*/
public InvalidatedSimpleObjectProperty(Object bean, String name, final
ConsumerInvalidatedSimpleObjectPropertyT invalidationConsumer) {
super(bean, name);
if( invalidationConsumer == null ) {
throw new IllegalArgumentException(Consumer can not be null);
}
this.invalidationConsumer = invalidationConsumer;
}
/**
* The constructor of {@code ObjectProperty}
*
* @param bean
*the bean of this {@code ObjectProperty}
* @param name
*the name of this {@code ObjectProperty}
* @param initialValue
*the initial value of the wrapped value
* @param invalidationConsumer
* the consumer to be called when the bean is
invalidated
*/
public InvalidatedSimpleObjectProperty(Object bean, String name, T
initialValue, final ConsumerInvalidatedSimpleObjectPropertyT
invalidationConsumer) {
super(bean,name,initialValue);
if( invalidationConsumer == null ) {
throw new IllegalArgumentException(Consumer can not be null);
}
this.invalidationConsumer = invalidationConsumer;
}
@Override
protected void invalidated() {
invalidationConsumer.accept(this);
}
}
On 22.01.13 10:30, Richard
Re: *PropertyBase vs Simple*Property
Ah i missed you passing them to the constructor.
Still i don't see this as much an improvement because we still create a vast
amount of anon inner classes.
Tom
Von meinem iPhone gesendet
Am 22.03.2014 um 16:23 schrieb Tom Schindl tom.schi...@bestsolution.at:
Why not i expect the property to be fully initialize so this would be a
breaking change in behavior.
Tom
Von meinem iPhone gesendet
Am 22.03.2014 um 14:54 schrieb Tomas Mikula tomas.mik...@gmail.com:
On Fri, Mar 21, 2014 at 8:53 PM, Tom Schindl
tom.schi...@bestsolution.at wrote:
Hi Richard,
Coming back to this old thread and now that we are using lamdas all over
I guess we could take one more look into that.
I've prototyped an initial version by introducing a new internal type
named InvalidatedSimpleObjectProperty (not the best name ever!) - see
code pasted below.
And now one can write code like this:
public final ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new InvalidatedSimpleObjectProperty(this,
viewport, (o) - {
invalidateWidthHeight();
impl_markDirty(DirtyBits.NODE_VIEWPORT);
impl_geomChanged();
} );
}
return viewport;
}
instead of
public final ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new ObjectPropertyBaseRectangle2D() {
@Override
protected void invalidated() {
invalidateWidthHeight();
impl_markDirty(DirtyBits.NODE_VIEWPORT);
impl_geomChanged();
}
@Override
public Object getBean() {
return ImageView.this;
}
@Override
public String getName() {
return viewport;
}
};
}
return viewport;
}
Nice idea. Just to get the comparison to status quo more fair, you
don't need to override getBean() and getName() methods:
public final ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new SimpleObjectPropertyRectangle2D(this, viewport) {
@Override
protected void invalidated() {
invalidateWidthHeight();
impl_markDirty(DirtyBits.NODE_VIEWPORT);
impl_geomChanged();
}
};
}
return viewport;
}
Regards,
Tomas
Which allows us to get rid of most of the ObjectPropertyBase sublcasses.
Tom
package com.sun.javafx.property;
import java.util.function.Consumer;
import javafx.beans.property.SimpleObjectProperty;
public final class InvalidatedSimpleObjectPropertyT extends
SimpleObjectPropertyT {
private final ConsumerInvalidatedSimpleObjectPropertyT
invalidationConsumer;
/**
* The constructor of {@code ObjectProperty}
*
* @param initialValue
*the initial value of the wrapped value
* @param invalidationConsumer
* the consumer to be called when the bean is
invalidated
*/
public InvalidatedSimpleObjectProperty(T initialValue, final
ConsumerInvalidatedSimpleObjectPropertyT invalidationConsumer) {
super(initialValue);
if( invalidationConsumer == null ) {
throw new IllegalArgumentException(Consumer can not be null);
}
this.invalidationConsumer = invalidationConsumer;
}
/**
* The constructor of {@code ObjectProperty}
*
* @param bean
*the bean of this {@code ObjectProperty}
* @param name
*the name of this {@code ObjectProperty}
* @param invalidationConsumer
* the consumer to be called when the bean is
invalidated
*/
public InvalidatedSimpleObjectProperty(Object bean, String name, final
ConsumerInvalidatedSimpleObjectPropertyT invalidationConsumer) {
super(bean, name);
if( invalidationConsumer == null ) {
throw new IllegalArgumentException(Consumer can not be null);
}
this.invalidationConsumer = invalidationConsumer;
}
/**
* The constructor of {@code ObjectProperty}
*
* @param bean
*the bean of this {@code ObjectProperty}
* @param name
*the name of this {@code ObjectProperty}
* @param initialValue
*the initial value of the wrapped value
* @param invalidationConsumer
* the consumer to be called when the bean is
invalidated
*/
public InvalidatedSimpleObjectProperty(Object bean, String name, T
initialValue, final ConsumerInvalidatedSimpleObjectPropertyT
invalidationConsumer) {
super(bean,name,initialValue);
if( invalidationConsumer == null ) {
throw new IllegalArgumentException(Consumer can not be null
Re: *PropertyBase vs Simple*Property
(=);
long s = System.currentTimeMillis();
for( int i = 0; i oneIteration; i++ ) {
target.get(i).invalidate();
}
long e = System.currentTimeMillis();
long diff = e - s;
System.err.println(Total time calls: + diff);
System.err.println(Time per call: + diff * 1.0 /
invokationOverheadCallCount);
}
{
System.err.println();
System.err.println(Test invokation multiple times);
System.err.println(===);
long s = System.currentTimeMillis();
for( int i = 0; i invokationOverheadCallCount; i++ ) {
}
long e = System.currentTimeMillis();
long diff = e - s;
System.err.println(Total time calls: + diff);
System.err.println(Time per call calls: + diff *
1.0 / invokationOverheadCallCount);
}
}
public static class LamdaInvalidationPropertyT extends
SimpleObjectPropertyT {
private ConsumerLamdaInvalidationPropertyT c;
public LamdaInvalidationProperty(Object bean, String name,
ConsumerLamdaInvalidationPropertyT c) {
super(bean, name);
this.c = c;
}
@Override
protected void invalidated() {
c.accept(this);
}
}
public interface TestObject {
public void invalidate();
}
public static class SimpleLambdaBean implements TestObject {
private AtomicInteger i = new AtomicInteger();
private ObjectPropertyObject sample = new
LamdaInvalidationProperty(this, sample, (e) - {
i.incrementAndGet();
});
public void invalidate() {
sample.setValue(new Object());
}
}
public static class SimpleSubclassBean implements TestObject {
private AtomicInteger i = new AtomicInteger();
private ObjectPropertyObject sample = new
ObjectPropertyBaseObject() {
@Override
public Object getBean() {
return SimpleSubclassBean.this;
}
public String getName() {
return sample;
}
public Object getValue() {
return null;
}
protected void invalidated() {
i.incrementAndGet();
}
};
public void invalidate() {
sample.setValue(new Object());
}
}
}
On 21.03.14 23:26, Kevin Rushforth wrote:
It does seem promising. We'll also need data to show the trade-offs to
help inform whether it is worth making such a massive change.
-- Kevin
Stephen F Northover wrote:
This looks good. I wonder if we should make this (massive) change
before we lambda graphics and controls? Probably doesn't matter.
We'll need a JIRA and someone assigned to it in order to track the work.
Steve
On 2014-03-21 12:53 PM, Tom Schindl wrote:
Hi Richard,
Coming back to this old thread and now that we are using lamdas all over
I guess we could take one more look into that.
I've prototyped an initial version by introducing a new internal type
named InvalidatedSimpleObjectProperty (not the best name ever!) - see
code pasted below.
And now one can write code like this:
public final ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new InvalidatedSimpleObjectProperty(this,
viewport, (o) - {
invalidateWidthHeight();
impl_markDirty(DirtyBits.NODE_VIEWPORT);
impl_geomChanged();
} );
}
return viewport;
}
instead of
public final ObjectPropertyRectangle2D viewportProperty() {
if (viewport == null) {
viewport = new ObjectPropertyBaseRectangle2D() {
@Override
protected void invalidated() {
invalidateWidthHeight();
impl_markDirty
Re: *PropertyBase vs Simple*Property
The code I run is attached in the mail copy it to your env and run it
and flip the testLambda from true to false.
I might have been something dumb wrong but this is what I came up with.
Tom
On 24.03.14 23:31, Kevin Rushforth wrote:
Those results are surprising. Is this an apples-to-apples comparison
with the only difference being a Lambda versus an equivalent anonymous
inner class?
-- Kevin
Tom Schindl wrote:
Hi,
I've written a small sample to see what it gets me to check:
* creation overhead
* memory overhead
* call overhead
I'm not very good at this kind of thing so someone who knows to write
benchmarks might know a lot better - need to check out JMH most likely.
Anyways here are the numbers:
TopicLambda Subclass
--
Create10M372ms (0.3723) 220ms (0.2205)
Mem 108byte / instance 84byte / instance
Call-1M*10 42ms (0.042)35ms (0.035)
Call-1*1M11ms (0.011)10ms (0.010)
So Lamda is considerable slower 40% and takes 20% more space, call
behavior is fairly the same. I'll try to learn about JMH.
Tom
package hello;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.function.Consumer;
import javafx.beans.property.ObjectProperty;
import javafx.beans.property.ObjectPropertyBase;
import javafx.beans.property.SimpleObjectProperty;
public class TestMemory {
private static int oneIteration = 1_000_000;
private static int iterationCount = 10;
private static int invokationOverheadCallCount = 1_000_000;
private static boolean testLambda = false;
private static void testLambda(int iterations, ListTestObject
storage) {
for( int i = 0; i iterations; i++ ) {
storage.add(new SimpleLambdaBean());
}
}
private static void testSubclass(int iterations, ListTestObject
storage) {
for( int i = 0; i iterations; i++ ) {
storage.add(new SimpleSubclassBean());
}
}
public static void main(String[] args) {
System.err.println(Test Creation time);
System.err.println(==);
{
long timeDiffTotal = 0;
for( int i = 0; i iterationCount; i++ ) {
System.err.println(Working for objects:
+ (i * oneIteration) + - + ((i+1) * oneIteration) );
System.err.println(
-);
long s = System.currentTimeMillis();
if( testLambda ) {
testLambda(oneIteration, new
ArrayList());
} else {
testSubclass(oneIteration, new
ArrayList());
}
long e = System.currentTimeMillis();
long diff = e - s;
timeDiffTotal+=diff;
System.err.println(Creation time: + diff
+ (+diff * 1.0 / oneIteration+));
System.err.println(
-);
}
System.err.println(Average time: + timeDiffTotal
* 1.0 / (iterationCount * oneIteration));
}
ListTestObject target = new
ArrayListTestObject(iterationCount * oneIteration);
{
System.err.println();
System.err.println(Test Creation memory);
System.err.println(==);
for( int i = 0; i iterationCount; i++ ) {
System.err.println(Working for objects:
+ (i * oneIteration) + - + ((i+1) * oneIteration) );
System.err.println(
-);
if( testLambda ) {
testLambda(oneIteration, target);
} else {
testSubclass(oneIteration, target);
}
long freeDiff =
Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
System.err.println(Memory: + freeDiff +
(+freeDiff * 1.0 / target.size()+));
System.err.println(
-);
}
System.err.println(Total
Re: *PropertyBase vs Simple*Property
();
System.err.println(Test invokation multiple times);
System.err.println(===);
long s = System.currentTimeMillis();
TestObject o = target.get(0);
for( int i = 0; i invokationOverheadCallCount; i++ ) {
o.invalidate();
}
long e = System.currentTimeMillis();
long diff = e - s;
System.err.println(Total time calls: + diff);
System.err.println(Time per call calls: + diff *
1.0 / invokationOverheadCallCount);
}
}
public static class LamdaInvalidationPropertyT extends
SimpleObjectPropertyT {
private ConsumerLamdaInvalidationPropertyT c;
public LamdaInvalidationProperty(Object bean, String name,
ConsumerLamdaInvalidationPropertyT c) {
super(bean, name);
this.c = c;
}
@Override
protected void invalidated() {
c.accept(this);
}
}
public interface TestObject {
public void invalidate();
}
public static class SimpleLambdaBean implements TestObject {
private AtomicInteger i = new AtomicInteger();
private ObjectPropertyObject sample = new
LamdaInvalidationProperty(this, sample, (e) - {
i.incrementAndGet();
});
public void invalidate() {
sample.setValue(new Object());
}
}
public static class SimpleSubclassBean implements TestObject {
private AtomicInteger i = new AtomicInteger();
private ObjectPropertyObject sample = new
ObjectPropertyBaseObject() {
@Override
public Object getBean() {
return SimpleSubclassBean.this;
}
public String getName() {
return sample;
}
public Object getValue() {
return null;
}
protected void invalidated() {
i.incrementAndGet();
}
};
public void invalidate() {
sample.setValue(new Object());
}
}
}
On 24.03.14 23:36, Tom Schindl wrote:
The code I run is attached in the mail copy it to your env and run it
and flip the testLambda from true to false.
I might have been something dumb wrong but this is what I came up with.
Tom
On 24.03.14 23:31, Kevin Rushforth wrote:
Those results are surprising. Is this an apples-to-apples comparison
with the only difference being a Lambda versus an equivalent anonymous
inner class?
-- Kevin
Tom Schindl wrote:
Hi,
I've written a small sample to see what it gets me to check:
* creation overhead
* memory overhead
* call overhead
I'm not very good at this kind of thing so someone who knows to write
benchmarks might know a lot better - need to check out JMH most likely.
Anyways here are the numbers:
Topic Lambda Subclass
--
Create10M 372ms (0.3723) 220ms (0.2205)
Mem 108byte / instance 84byte / instance
Call-1M*10 42ms (0.042)35ms (0.035)
Call-1*1M 11ms (0.011)10ms (0.010)
So Lamda is considerable slower 40% and takes 20% more space, call
behavior is fairly the same. I'll try to learn about JMH.
Tom
package hello;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.function.Consumer;
import javafx.beans.property.ObjectProperty;
import javafx.beans.property.ObjectPropertyBase;
import javafx.beans.property.SimpleObjectProperty;
public class TestMemory {
private static int oneIteration = 1_000_000;
private static int iterationCount = 10;
private static int invokationOverheadCallCount = 1_000_000;
private static boolean testLambda = false;
private static void testLambda(int iterations, ListTestObject
storage) {
for( int i = 0; i iterations; i++ ) {
storage.add(new SimpleLambdaBean());
}
}
private static void testSubclass(int iterations, ListTestObject
storage) {
for( int i = 0; i iterations; i
Re: *PropertyBase vs Simple*Property
Arghhh time for bed:
Number is 179 vs 150 but I only ran it once so the numbers might be
completely bogus!
Tom
On 24.03.14 23:40, Tom Schindl wrote:
Ups there was an error in my test for the last Call line so the numbers
there are:
38 (lambda) vs 32 (subclass)
package hello;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.function.Consumer;
import javafx.beans.property.ObjectProperty;
import javafx.beans.property.ObjectPropertyBase;
import javafx.beans.property.SimpleObjectProperty;
public class TestMemory {
private static int oneIteration = 1_000_000;
private static int iterationCount = 10;
private static int invokationOverheadCallCount = 1_000_000;
private static boolean testLambda = false;
private static void testLambda(int iterations, ListTestObject
storage) {
for( int i = 0; i iterations; i++ ) {
storage.add(new SimpleLambdaBean());
}
}
private static void testSubclass(int iterations, ListTestObject
storage) {
for( int i = 0; i iterations; i++ ) {
storage.add(new SimpleSubclassBean());
}
}
public static void main(String[] args) {
System.err.println(Test Creation time);
System.err.println(==);
{
long timeDiffTotal = 0;
for( int i = 0; i iterationCount; i++ ) {
System.err.println(Working for objects:
+ (i * oneIteration) + - + ((i+1) * oneIteration) );
System.err.println(
-);
long s = System.currentTimeMillis();
if( testLambda ) {
testLambda(oneIteration, new
ArrayList());
} else {
testSubclass(oneIteration, new
ArrayList());
}
long e = System.currentTimeMillis();
long diff = e - s;
timeDiffTotal+=diff;
System.err.println(Creation time: + diff
+ (+diff * 1.0 / oneIteration+));
System.err.println(
-);
}
System.err.println(Average time: + timeDiffTotal
* 1.0 / (iterationCount * oneIteration));
}
ListTestObject target = new
ArrayListTestObject(iterationCount * oneIteration);
{
System.err.println();
System.err.println(Test Creation memory);
System.err.println(==);
for( int i = 0; i iterationCount; i++ ) {
System.err.println(Working for objects:
+ (i * oneIteration) + - + ((i+1) * oneIteration) );
System.err.println(
-);
if( testLambda ) {
testLambda(oneIteration, target);
} else {
testSubclass(oneIteration, target);
}
long freeDiff =
Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
System.err.println(Memory: + freeDiff +
(+freeDiff * 1.0 / target.size()+));
System.err.println(
-);
}
System.err.println(Total objects created: +
target.size());
}
{
System.err.println();
System.err.println(Test invokation overhead (all then
times));
System.err.println(=);
long s = System.currentTimeMillis();
for( int i = 0; i oneIteration; i++ ) {
target.get(i).invalidate();
}
long e = System.currentTimeMillis();
long diff = e - s;
System.err.println(Total time calls: + diff);
System.err.println(Time per call: + diff * 1.0 /
invokationOverheadCallCount
Why is com.sun.glass.ui.swt part of graphics-module
Hi Steve others, Why is com.sun.glass.ui.swt part of the graphics module? Should it go into the swt one? I think it should be shipped with swtfx.jar not else we get back to classloader hell because the extension classloader tries to load classes from swt which it naturally can not find. Tom
Re: Fractional Metrics
If you don't mind using internal APIs then: TextLayoutFactory factory = Toolkit.getToolkit().getTextLayoutFactory(); TextLayout layout = factory.createLayout(); layout.setContent(BlaBla, Font.getDefault().impl_getNativeFont()); BaseBounds b = layout.getBounds(); I find it strange the canvas does not have an API to calculate the boudsn of a string. Tom On 04.04.14 18:48, Phil Race wrote: On 4/4/2014 6:41 AM, ngalarn...@abinitio.com wrote: I'm sorry if this is redundant, but does this mean there is no way to find out the size (length height) of a String as it will appear on the screen? What about the size of a String as it will be printed? No it does not mean that. The way to do this is to get the bounds of a Text node containing the string. -phil. Neil From: Phil Race philip.r...@oracle.com To: Jeff Martin j...@reportmill.com, openjfx-dev@openjdk.java.net Mailing openjfx-dev@openjdk.java.net Date: 04/03/2014 10:40 PM Subject: Re: Fractional Metrics Sent by: openjfx-dev openjfx-dev-boun...@openjdk.java.net On 4/3/14 6:13 PM, Jeff Martin wrote: Is there a way to turn off FractionalMetrics in Canvas.fillText() or Text? No. At least not via any supported API. Also, does text rendering perform kerning, and if so, can I disable that? No. What I really need is to know the x position (or advance) of each character in a rendered string. It would need new API. And characters != glyphs. Counting char advances has been doomed for decades ... -phil. jeff 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: JavaFX 2 + with LWJGL ( OpenGL )
There is a talk from Felipe and Steve at J1 last year how to embed OpenGL into FX using *internal* API! Search for it on parleys - this does not help you on Win32 which uses directx instead of javafx. BTW there are people doing a JOGL pipeline https://bitbucket.org/dejayberlin/joglfxpipeline/src! Tom Von meinem iPhone gesendet Am 06.04.2014 um 17:25 schrieb Exo Verse tora...@gmail.com: Yea its a shame that using JavaFX as an option along with OpenGL wasn't even thought of to begin with. I don't understand why they limit you like they do. Them trying to recreate the wheel and make their own version of a 3D interface is just plain stupid if it can't run low level. I can see 2D games and applications with a LOT of usage for JavaFX and its 2D graphics API. But True 3D needs low level other wise its a waste of time. Well, thanks for the replies. Guess I'll have to stick with using other sources for my GUI. It's just that I like JavaFX version of its GUI because it is so simple to use. But not worth it if you can't use it for the reason that we the people need it for. Like in my case, game dev. Cheers. Torak On Sun, Apr 6, 2014 at 10:48 AM, Philipp Dörfler phdoerf...@gmail.comwrote: It is not possible to combine JavaFX and OpenGL as it is right now. This was discussed on this mailing list some time before as a _possible_ future addition, but I'd be very surprised if Oracle actually chose to implement this. Starting with JavaFX 8 there is indeed some kind of 3D support but the 3D API allows only for the most basic operations. It is still completely scene graph based and you have to live with all restrictions that JavaFX imposes on you. Not wanting to say that the 3D API is completely useless, but I'm afraid that even WPF is more flexible when it comes to 3D than JavaFX is. For example: As far as I know you can not even change the shading model from GL_SMOOTH to GL_FLAT. You could work around that by setting the normals yourself though (Same for WPF). Also render quality is bad when you render an instance of Text in 3D and scale it down for example. At least it was when I tried that last time (few months ago). Again, not to say that one can't work with JavaFX's 3D API, but it's not raw OpenGL either. As far as I know the JavaFX team wants to be able to let the user use his own OpenGL context and let JavaFX render on top of that or add the possibility to ask JavaFX for the underlying context and mess with that but this is not even officially planned or included on any roadmap (AFAIK) so we can only keep our fingers crossed for that to happen. Like you I would absolutely LOVE to use JavaFX as a GUI on top of my OpenGL games. Cheers Philipp Dörfler Am 06.04.2014 um 16:31 schrieb Exo Verse tora...@gmail.com: Can you please explain what True 3D means in terms of Low Level API ? Because with LWJGL I can use Low Level API to talk directly to my Video Card. As a game dev, I need every ounce of umph from the card I can get, and using a browser or any other kind of wrapper hasn't proven very efficient. I love LWJGL because of its simplicity. Anything extra I need, I am allowed to make on my own. Example, my own Game Engine. And that is where I am at. So if your speaking about Nodes, I am aware there is a hierarchy to the JavaFX2 when setting up the GUI, but that is the only thing I knew existed. Could you please elaborate what makes JavaFX8 a True 3D Low Level interface API ? Because from the presentation, you have to go through two layers before you have to get to the OpenGL layer. Where as if I can use LWJGL, I can skip a level. If I am misinformed on something, please, explain. Because I am new to JavaFX. Cheers, Torak On Sun, Apr 6, 2014 at 10:24 AM, Hervé Girod herve.gi...@gmail.com wrote: With Java 8 (JavaFX 8), you now have true 3D Nodes, with camera, texturing, etc... However it would still be very interesting to be able to control the low-level rendering of JavaFX, such as using LWJGL for example. This would allow to render JavaFx content in an external OpenGL context for example. Hervé Sent from my iPad On 6 avr. 2014, at 14:42, Exo Verse tora...@gmail.com wrote: Hello, I have been working with OpenGL and LWJGL for over 5 years now. I want to switch over to using JavaFX 2, because of its GUI abilities and still use LWJGL with it. But I can't seem to find a way to do this. I saw a 2 hour video that described the features of JavaFX 2 and it even shown the layout.. OpenGL was there at the bottom with D3D with Prism above both of them in the hierarchy. I have searched the web and I can't find prism, I can't find info on how to talk to opengl and I can't find any tutorials anywhere. So I am posting here to see what I can find. I do NOT like JOGL. I prefer LWJGL. So far, the only thing related to 3D with regards to JavaFX is the very resource intensive Canvas3D, which I can't stand.
Re: JavaFX 2 + with LWJGL ( OpenGL )
JavaFX does not ship OpenGL binaries on windows you have to build it your own. Please note: a) if there are people who manage to write a prism pipeline on jogl why should you not be able to do the same with lwjgl? b) the talk i mentionned from felipe and steve show how to get access to the native OpenGL context and there from you can use any API you like can't remember which one they used Tom Von meinem iPhone gesendet Am 06.04.2014 um 18:18 schrieb Exo Verse tora...@gmail.com: Thanks, but as I mentioned in my original post, I don't like JOGL. It doesn't work with my setup. I use LWJGL because its only about the OpenGL and not other libraries, and its an easy API wrapper to use. There are many many reason I hate JOGL.. but this thread is not about hating on JOGL, its about finding a way to use LWJGL with JavaFX2+. Also, Win32 API calls can use both DirectX and OpenGL APIs. And it doesn't matter what Windows OS you're using. I have tested this out from Windows XP all the way to Windows 7 - 32/64 Bit with no problem. Cheers Torak On Sun, Apr 6, 2014 at 11:52 AM, Tom Schindl tom.schi...@bestsolution.atwrote: There is a talk from Felipe and Steve at J1 last year how to embed OpenGL into FX using *internal* API! Search for it on parleys - this does not help you on Win32 which uses directx instead of javafx. BTW there are people doing a JOGL pipeline https://bitbucket.org/dejayberlin/joglfxpipeline/src! Tom Von meinem iPhone gesendet Am 06.04.2014 um 17:25 schrieb Exo Verse tora...@gmail.com: Yea its a shame that using JavaFX as an option along with OpenGL wasn't even thought of to begin with. I don't understand why they limit you like they do. Them trying to recreate the wheel and make their own version of a 3D interface is just plain stupid if it can't run low level. I can see 2D games and applications with a LOT of usage for JavaFX and its 2D graphics API. But True 3D needs low level other wise its a waste of time. Well, thanks for the replies. Guess I'll have to stick with using other sources for my GUI. It's just that I like JavaFX version of its GUI because it is so simple to use. But not worth it if you can't use it for the reason that we the people need it for. Like in my case, game dev. Cheers. Torak On Sun, Apr 6, 2014 at 10:48 AM, Philipp Dörfler phdoerf...@gmail.com wrote: It is not possible to combine JavaFX and OpenGL as it is right now. This was discussed on this mailing list some time before as a _possible_ future addition, but I'd be very surprised if Oracle actually chose to implement this. Starting with JavaFX 8 there is indeed some kind of 3D support but the 3D API allows only for the most basic operations. It is still completely scene graph based and you have to live with all restrictions that JavaFX imposes on you. Not wanting to say that the 3D API is completely useless, but I'm afraid that even WPF is more flexible when it comes to 3D than JavaFX is. For example: As far as I know you can not even change the shading model from GL_SMOOTH to GL_FLAT. You could work around that by setting the normals yourself though (Same for WPF). Also render quality is bad when you render an instance of Text in 3D and scale it down for example. At least it was when I tried that last time (few months ago). Again, not to say that one can't work with JavaFX's 3D API, but it's not raw OpenGL either. As far as I know the JavaFX team wants to be able to let the user use his own OpenGL context and let JavaFX render on top of that or add the possibility to ask JavaFX for the underlying context and mess with that but this is not even officially planned or included on any roadmap (AFAIK) so we can only keep our fingers crossed for that to happen. Like you I would absolutely LOVE to use JavaFX as a GUI on top of my OpenGL games. Cheers Philipp Dörfler Am 06.04.2014 um 16:31 schrieb Exo Verse tora...@gmail.com: Can you please explain what True 3D means in terms of Low Level API ? Because with LWJGL I can use Low Level API to talk directly to my Video Card. As a game dev, I need every ounce of umph from the card I can get, and using a browser or any other kind of wrapper hasn't proven very efficient. I love LWJGL because of its simplicity. Anything extra I need, I am allowed to make on my own. Example, my own Game Engine. And that is where I am at. So if your speaking about Nodes, I am aware there is a hierarchy to the JavaFX2 when setting up the GUI, but that is the only thing I knew existed. Could you please elaborate what makes JavaFX8 a True 3D Low Level interface API ? Because from the presentation, you have to go through two layers before you have to get to the OpenGL layer. Where as if I can use LWJGL, I can skip a level. If I am misinformed on something, please, explain. Because I am new to JavaFX. Cheers, Torak On Sun, Apr 6, 2014 at 10:24 AM, Hervé Girod
Re: JavaFX 2 + with LWJGL ( OpenGL )
My wording was incorrect better worded: javafx does not ship an OpenGL prism pipeline on Windows. And to repeat if you get a native OpenGLContext i thought you could use any other library to mix in custom OpenGL code into your javafx application, not? Tom Von meinem iPhone gesendet Am 06.04.2014 um 18:41 schrieb Exo Verse tora...@gmail.com: Yea the OpenGL comes with your graphics drivers for your video card. So your correct that it doesn't ship with JavaFX. What I have been going on about is trying to find a way to use JavaFX with LWJGL. In case you are unaware, LWJGL just means Light Weight Java OpenGL and its a wrapper for the OpenGL API. It's an alternative to JOGL. On another note, as I did a search, Thanks to Tom showing me that link I examined that code and I found something of interest in the JOGL code interface.. well it lead me to a google search, and viola.. LWJGL with JavaFX. :) LINK : https://github.com/Spasi/LWJGL-FX So just wanted to post the link here and say thanks for all of your help. :) Cheers, Torak On Sun, Apr 6, 2014 at 12:35 PM, Tom Schindl tom.schi...@bestsolution.atwrote: JavaFX does not ship OpenGL binaries on windows you have to build it your own. Please note: a) if there are people who manage to write a prism pipeline on jogl why should you not be able to do the same with lwjgl? b) the talk i mentionned from felipe and steve show how to get access to the native OpenGL context and there from you can use any API you like can't remember which one they used Tom Von meinem iPhone gesendet Am 06.04.2014 um 18:18 schrieb Exo Verse tora...@gmail.com: Thanks, but as I mentioned in my original post, I don't like JOGL. It doesn't work with my setup. I use LWJGL because its only about the OpenGL and not other libraries, and its an easy API wrapper to use. There are many many reason I hate JOGL.. but this thread is not about hating on JOGL, its about finding a way to use LWJGL with JavaFX2+. Also, Win32 API calls can use both DirectX and OpenGL APIs. And it doesn't matter what Windows OS you're using. I have tested this out from Windows XP all the way to Windows 7 - 32/64 Bit with no problem. Cheers Torak On Sun, Apr 6, 2014 at 11:52 AM, Tom Schindl tom.schi...@bestsolution.atwrote: There is a talk from Felipe and Steve at J1 last year how to embed OpenGL into FX using *internal* API! Search for it on parleys - this does not help you on Win32 which uses directx instead of javafx. BTW there are people doing a JOGL pipeline https://bitbucket.org/dejayberlin/joglfxpipeline/src! Tom Von meinem iPhone gesendet Am 06.04.2014 um 17:25 schrieb Exo Verse tora...@gmail.com: Yea its a shame that using JavaFX as an option along with OpenGL wasn't even thought of to begin with. I don't understand why they limit you like they do. Them trying to recreate the wheel and make their own version of a 3D interface is just plain stupid if it can't run low level. I can see 2D games and applications with a LOT of usage for JavaFX and its 2D graphics API. But True 3D needs low level other wise its a waste of time. Well, thanks for the replies. Guess I'll have to stick with using other sources for my GUI. It's just that I like JavaFX version of its GUI because it is so simple to use. But not worth it if you can't use it for the reason that we the people need it for. Like in my case, game dev. Cheers. Torak On Sun, Apr 6, 2014 at 10:48 AM, Philipp Dörfler phdoerf...@gmail.com wrote: It is not possible to combine JavaFX and OpenGL as it is right now. This was discussed on this mailing list some time before as a _possible_ future addition, but I'd be very surprised if Oracle actually chose to implement this. Starting with JavaFX 8 there is indeed some kind of 3D support but the 3D API allows only for the most basic operations. It is still completely scene graph based and you have to live with all restrictions that JavaFX imposes on you. Not wanting to say that the 3D API is completely useless, but I'm afraid that even WPF is more flexible when it comes to 3D than JavaFX is. For example: As far as I know you can not even change the shading model from GL_SMOOTH to GL_FLAT. You could work around that by setting the normals yourself though (Same for WPF). Also render quality is bad when you render an instance of Text in 3D and scale it down for example. At least it was when I tried that last time (few months ago). Again, not to say that one can't work with JavaFX's 3D API, but it's not raw OpenGL either. As far as I know the JavaFX team wants to be able to let the user use his own OpenGL context and let JavaFX render on top of that or add the possibility to ask JavaFX for the underlying context and mess with that but this is not even officially planned or included on any roadmap (AFAIK) so we can only keep our fingers crossed for that to happen
Setup IDE for development instructions
Hi, I try to follow the guide at https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE to setup my Eclipse workspace but the description how to preconfigure the JDK is a ambiguous. The ambiguous information is the cd PATH TO JFX which could me (I take my OS-X install as the reference) * cd /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk_nofx/Contents/Home/jre/lib/ext * cd /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk_nofx/Contents/Home/ BTW for Eclipse there's no an easier way to get Java8 support you can grab a prebuilt distro from http://www.eclipse.org/downloads/index-java8.php Tom
Re: Setup IDE for development instructions
More stuff that does not work. If you import the projects you have build-path errors because source folders are missing in: * base: - src/main/resources - src/test/resources * builders - src/main/resources - src/test/resources * designTime - src/main/resources * fxml - src/main/resources * media - src/test/java - src/test/resources * swing - src/main/resources - src/test/java - src/test/resources * swt - src/main/resources - src/test/java - src/test/resources * web - src/main/native/WebKitBuild/Release/WebCore/generated/java Libraries are not found in buildSrc: It looks like you are using relative-paths but at least my eclipse does not like that but e.g. wants to detect them as rt/build/libs/ant-1.8.2.jar and not ../build/libs/ant-1.8.2.jar * graphics to compile without errors needs swt-debug.jar in the library path. * swt to compile without errors needs swt-debug.jar in the library path * scenebuilder needs to reference all projects but not rt-project Tom On 24.04.14 22:29, Tom Schindl wrote: Hi, I try to follow the guide at https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE to setup my Eclipse workspace but the description how to preconfigure the JDK is a ambiguous. The ambiguous information is the cd PATH TO JFX which could me (I take my OS-X install as the reference) * cd /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk_nofx/Contents/Home/jre/lib/ext * cd /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk_nofx/Contents/Home/ BTW for Eclipse there's no an easier way to get Java8 support you can grab a prebuilt distro from http://www.eclipse.org/downloads/index-java8.php Tom
Re: Setup IDE for development instructions
Hi, I once built with gradle sdk maybe that was wrong? Tom On 24.04.14 23:37, Stephen F Northover wrote: Did you build once outside the IDE? Type gradle in the rt directory. Steve On 2014-04-24 5:28 PM, Tom Schindl wrote: More stuff that does not work. If you import the projects you have build-path errors because source folders are missing in: * base: - src/main/resources - src/test/resources * builders - src/main/resources - src/test/resources * designTime - src/main/resources * fxml - src/main/resources * media - src/test/java - src/test/resources * swing - src/main/resources - src/test/java - src/test/resources * swt - src/main/resources - src/test/java - src/test/resources * web - src/main/native/WebKitBuild/Release/WebCore/generated/java Libraries are not found in buildSrc: It looks like you are using relative-paths but at least my eclipse does not like that but e.g. wants to detect them as rt/build/libs/ant-1.8.2.jar and not ../build/libs/ant-1.8.2.jar * graphics to compile without errors needs swt-debug.jar in the library path. * swt to compile without errors needs swt-debug.jar in the library path * scenebuilder needs to reference all projects but not rt-project Tom On 24.04.14 22:29, Tom Schindl wrote: Hi, I try to follow the guide at https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE to setup my Eclipse workspace but the description how to preconfigure the JDK is a ambiguous. The ambiguous information is the cd PATH TO JFX which could me (I take my OS-X install as the reference) * cd /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk_nofx/Contents/Home/jre/lib/ext * cd /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk_nofx/Contents/Home/ BTW for Eclipse there's no an easier way to get Java8 support you can grab a prebuilt distro from http://www.eclipse.org/downloads/index-java8.php Tom
Re: Why can Scene's only be constructed on the UI thread?
On 26.04.14 11:42, Mike Hearn wrote: I'm trying (mostly in vain) to optimise the startup time of my app. It takes about a second to build the main GUI via FXMLLoader.load() - probably because the GUI is getting a little bit complex but I think mostly because it's all running interpreted, as it's one of the first things the app does. Later loads of the same GUI take more like 100-200msec, presumably because HotSpot went in and compiled it. But that's kind of useless for me. It's the first load that counts. So I figured I'd bring up a stage of the right size early with just a logo and a loading indicator, and load the root Node of my UI on a background thread so the user has something to look at for a moment whilst it's hauling itself into memory. My first attempt was to show the splash and then load the UI. Didn't work of course, because the UI thread didn't get a chance to render. So then I put it inside a Platform.runLater which also didn't work, the splash didn't appear quickly enough. So then I tried putting it in a background thread. This got the right splash behaviour but it didn't work out of the box: my GUI has tooltips and context menus in it. These attempt to construct a Scene at load time, which of course fails because it's not on the GUI thread. Once I commented those out, I got the behaviour I wanted, but of course at the cost of features. I think you are seeing https://javafx-jira.kenai.com/browse/RT-17716 Given that these Scene's are not being rendered as they're not visible or interactable, what's the reason they have to be built on the UI thread? Also does anyone have any advice for making JFX8 apps that start really fast? I tried parallelising most of the work my app is doing at startup and annoyingly it hardly helped at all. Not sure why yet: perhaps the JVM or the operating system is busy using the other core so all my threads get scheduled onto the same chip. At e(fx)clipse we have an FXML to Java translator who removes all the reflection overhead from FXML. It does not yet support all FXML features but we are steadily improving it and with test cases we are able to fix problems quite fast. Maybe this is an option for you? We provide currently only commandline ant integration and require to run on Java8 (you don't need to use Eclipse to make use of it!) Tom
Re: Why can Scene's only be constructed on the UI thread?
If you don't use Tooltips context menus you can construct the scenegraph in any thread. Tom Von meinem iPhone gesendet Am 26.04.2014 um 21:48 schrieb Tony Anecito adanec...@yahoo.com: Hi Tom this is also true for Swing and the EDT. I had heard years ago jre 8 was going to address this via 2 drawing threads and modularity but jigsaw was delayed and not sure what happened to the 2 drawing thread idea. I really wish we could instantiate windows in memory and when needed draw them. The user experience and perception of java would be so much better for the client side. If someone on the java client side knows how to do this I would love to try it to verify it. Best Regards, Tony Anecito On Saturday, April 26, 2014 11:39 AM, Mike Hearn m...@plan99.net wrote: At e(fx)clipse we have an FXML to Java translator who removes all the reflection overhead from FXML. It does not yet support all FXML features but we are steadily improving it and with test cases we are able to fix problems quite fast. Maybe this is an option for you? That would be very interesting to try, yes please! Where can I find it? My project is Java 8 based so that's no problem.
Re: Why can Scene's only be constructed on the UI thread?
Read the jira ticket i referenced in my initial reply - tooltips and context menus create a window instance (=glass) and calls on glass have to be made on the javafx thread. Tom Von meinem iPhone gesendet Am 27.04.2014 um 05:14 schrieb Felix Bembrick felix.bembr...@gmail.com: Why do tooltips and context menus matter? Is it because they will later be instantiated on the wrong thread when they pop up? On 27 Apr 2014, at 7:04, Tom Schindl tom.schi...@bestsolution.at wrote: If you don't use Tooltips context menus you can construct the scenegraph in any thread. Tom Von meinem iPhone gesendet Am 26.04.2014 um 21:48 schrieb Tony Anecito adanec...@yahoo.com: Hi Tom this is also true for Swing and the EDT. I had heard years ago jre 8 was going to address this via 2 drawing threads and modularity but jigsaw was delayed and not sure what happened to the 2 drawing thread idea. I really wish we could instantiate windows in memory and when needed draw them. The user experience and perception of java would be so much better for the client side. If someone on the java client side knows how to do this I would love to try it to verify it. Best Regards, Tony Anecito On Saturday, April 26, 2014 11:39 AM, Mike Hearn m...@plan99.net wrote: At e(fx)clipse we have an FXML to Java translator who removes all the reflection overhead from FXML. It does not yet support all FXML features but we are steadily improving it and with test cases we are able to fix problems quite fast. Maybe this is an option for you? That would be very interesting to try, yes please! Where can I find it? My project is Java 8 based so that's no problem.
Re: Setup IDE for development instructions
Hi, Just to finish this. The real problem with is that I've clone the hg-repo directly to my workspace-folder (which is the default in the Eclipse-hg-plugin) which is causing all the troubles! Once I move the clone next to the workspace-folder things started to operate the way they should. Tom On 24.04.14 23:58, Stephen F Northover wrote: H . I can't look at this now but will look at it tomorrow. I am running: Eclipse SDK Version: 4.3.2 Build id: M20140221-1700 I will get the latest and greatest from the Eclipse download page and follow the steps. Eclipse has this funky optional classpath syntax. Is this burning us? classpathentry kind=src exported=true path=src/test/java attributes attribute name=optional value=true/ /attributes /classpathentry Anyhow, tomorrow! Steve On 2014-04-24 5:51 PM, Kevin Rushforth wrote: The default task in build.gradle is sdk so gradle and gradle sdk are equivalent. -- Kevin Tom Schindl wrote: Hi, I once built with gradle sdk maybe that was wrong? Tom On 24.04.14 23:37, Stephen F Northover wrote: Did you build once outside the IDE? Type gradle in the rt directory. Steve On 2014-04-24 5:28 PM, Tom Schindl wrote: More stuff that does not work. If you import the projects you have build-path errors because source folders are missing in: * base: - src/main/resources - src/test/resources * builders - src/main/resources - src/test/resources * designTime - src/main/resources * fxml - src/main/resources * media - src/test/java - src/test/resources * swing - src/main/resources - src/test/java - src/test/resources * swt - src/main/resources - src/test/java - src/test/resources * web - src/main/native/WebKitBuild/Release/WebCore/generated/java Libraries are not found in buildSrc: It looks like you are using relative-paths but at least my eclipse does not like that but e.g. wants to detect them as rt/build/libs/ant-1.8.2.jar and not ../build/libs/ant-1.8.2.jar * graphics to compile without errors needs swt-debug.jar in the library path. * swt to compile without errors needs swt-debug.jar in the library path * scenebuilder needs to reference all projects but not rt-project Tom On 24.04.14 22:29, Tom Schindl wrote: Hi, I try to follow the guide at https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE to setup my Eclipse workspace but the description how to preconfigure the JDK is a ambiguous. The ambiguous information is the cd PATH TO JFX which could me (I take my OS-X install as the reference) * cd /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk_nofx/Contents/Home/jre/lib/ext * cd /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk_nofx/Contents/Home/ BTW for Eclipse there's no an easier way to get Java8 support you can grab a prebuilt distro from http://www.eclipse.org/downloads/index-java8.php Tom
Re: Cleaning up Control codebase - How to deal with StyleableProperty cast
Hi,
According to Eclipse Compiler people we probably found a bug in javac.
They cited the following paragraph from the spec:
A cast from a type S to a parameterized type (§4.5) T is unchecked
unless at least one of the following is true:
* S : T
* All of the type arguments (§4.5.1) of T are unbounded wildcards
* T : S and S has no subtype X other than T where the type arguments
of X are not contained in the type arguments of T.
Tom
On 29.04.14 00:00, Jonathan Giles wrote:
IntelliJ says the following:
=
Unchecked cast: 'javafx.beans.property.BooleanProperty' to
'javafx.css.StyleablePropertyjava.lang.Boolean'
*JDK 5.0 only.*
Signals places where an unchecked warning is issued by the compiler, for
example:
|void f(HashMap map) {
map.put(key, value);
}
|=
Perhaps the 'JDK 5.0 only' is significant? I honestly don't know
-- Jonathan
On 29/04/2014 9:57 a.m., Tom Schindl wrote:
Hi,
Interesting is that only the Eclipse Java Compiler shows a warning.
javac is fine with original code.
Let me see what the Eclipse compiler guys have to say about that!
Tom
On 28.04.14 23:33, Tom Schindl wrote:
Hi,
I've been cleaning up the warnings inside the controls code base and one
of the warnings left (beside many generic problems in the *View-classes)
is the casting from *Property to *StyleableProperty.
final StyleablePropertyBoolean prop =
(StyleablePropertyBoolean)focusTraversableProperty();
now I think I found a way to get away with out an unchecked cast warning
by writing
final StyleablePropertyBoolean prop =
(StyleablePropertyBoolean)(WritableValueBoolean)focusTraversableProperty();
Anyone having a better idea?
Tom
Re: Cleaning up Control codebase - How to deal with StyleableProperty cast
Hi, On 29.04.14 14:35, David Grieve wrote: I've found that this works: final StyleableBooleanProperty prop = (StyleableBooleanProperty)focusTraversableProperty(); Right i can confirm that. The problem is that we are then relying even more on the fact the upstream code does not change. If someone because of what ever reason decides to replace the StyleableBooleanProperty through a custom implementation StyleablePropertyBoolean we get broken. In case of focusTraversableProperty() we are even crossing module boundaries in this case which worries me a bit. Tom
Re: Cleaning up Control codebase - How to deal with StyleableProperty cast
Hi Jonathan David, do you have any opinion on this? I would spend some time tomorrow to bring down the warning count. Maybe we should use the Styleable*Property cast when we control both the API implementation and reside to the more save (StyleablePropertyBoolean)(WritableValueBoolean) e.g. if we don't e.g. because code is owned by the graphics module? One could naturally look at this from another angle and say the Syleable interface should have been shown in the API but I guess this not going to change so we need to live with casts and the implementation detail. Tom On 30.04.14 15:39, Tom Schindl wrote: Hi, On 29.04.14 14:35, David Grieve wrote: I've found that this works: final StyleableBooleanProperty prop = (StyleableBooleanProperty)focusTraversableProperty(); Right i can confirm that. The problem is that we are then relying even more on the fact the upstream code does not change. If someone because of what ever reason decides to replace the StyleableBooleanProperty through a custom implementation StyleablePropertyBoolean we get broken. In case of focusTraversableProperty() we are even crossing module boundaries in this case which worries me a bit. Tom
Re: Cleaning up Control codebase - How to deal with StyleableProperty cast
Hi, Yes if i turn on this unnecessary type cast warning in Eclipse I get that as well. Currently the only solution to get around with ANY warning suppression I found is to use an intermediate variable. Tom On 28.04.14 23:57, Jonathan Giles wrote: This seems to look fine - IntelliJ still complains about an unnecessary cast, but it is better than having an unchecked cast. I'm happy for this to be done, but I think it would be best to get David Grieve's +1 first too. Thanks for your help so far - it is making the JavaFX code base much nicer. I've just switched IntelliJ to make warnings far more obvious to me, so I'll be trying to keep on top of them also. -- Jonathan On 29/04/2014 9:33 a.m., Tom Schindl wrote: Hi, I've been cleaning up the warnings inside the controls code base and one of the warnings left (beside many generic problems in the *View-classes) is the casting from *Property to *StyleableProperty. final StyleablePropertyBoolean prop = (StyleablePropertyBoolean)focusTraversableProperty(); now I think I found a way to get away with out an unchecked cast warning by writing final StyleablePropertyBoolean prop = (StyleablePropertyBoolean)(WritableValueBoolean)focusTraversableProperty(); Anyone having a better idea? Tom
Re: Setup IDE for development instructions
The path to to the libraries is wrong. It is
-Djava.library.path=${workspace_loc:rt}/build/sdk/rt/lib
Tom
On 28.04.14 23:36, Stephen F Northover wrote:
I fixed the wiki to warn Eclipse users not to do this.
Steve
On 2014-04-28 4:55 PM, Stephen F Northover wrote:
Thanks Tom. Felipe ran into this way back when. Initially, the repo
was in the workspace, but having outside allows is how most people
develop and so I moved it out.
Steve
On 2014-04-28 4:45 PM, Tom Schindl wrote:
Hi,
Just to finish this. The real problem with is that I've clone the
hg-repo directly to my workspace-folder (which is the default in the
Eclipse-hg-plugin) which is causing all the troubles!
Once I move the clone next to the workspace-folder things started to
operate the way they should.
Tom
On 24.04.14 23:58, Stephen F Northover wrote:
H . I can't look at this now but will look at it tomorrow. I am
running:
Eclipse SDK
Version: 4.3.2
Build id: M20140221-1700
I will get the latest and greatest from the Eclipse download page and
follow the steps.
Eclipse has this funky optional classpath syntax. Is this burning us?
classpathentry kind=src exported=true path=src/test/java
attributes
attribute name=optional value=true/
/attributes
/classpathentry
Anyhow, tomorrow!
Steve
On 2014-04-24 5:51 PM, Kevin Rushforth wrote:
The default task in build.gradle is sdk so gradle and gradle sdk
are equivalent.
-- Kevin
Tom Schindl wrote:
Hi,
I once built with gradle sdk maybe that was wrong?
Tom
On 24.04.14 23:37, Stephen F Northover wrote:
Did you build once outside the IDE? Type gradle in the rt
directory.
Steve
On 2014-04-24 5:28 PM, Tom Schindl wrote:
More stuff that does not work.
If you import the projects you have build-path errors because
source
folders are missing in:
* base:
- src/main/resources
- src/test/resources
* builders
- src/main/resources
- src/test/resources
* designTime
- src/main/resources
* fxml
- src/main/resources
* media
- src/test/java
- src/test/resources
* swing
- src/main/resources
- src/test/java
- src/test/resources
* swt
- src/main/resources
- src/test/java
- src/test/resources
* web
- src/main/native/WebKitBuild/Release/WebCore/generated/java
Libraries are not found in buildSrc:
It looks like you are using relative-paths but at least my eclipse
does
not like that but e.g. wants to detect them as
rt/build/libs/ant-1.8.2.jar and not ../build/libs/ant-1.8.2.jar
* graphics to compile without errors needs swt-debug.jar in the
library
path.
* swt to compile without errors needs swt-debug.jar in the library
path
* scenebuilder needs to reference all projects but not rt-project
Tom
On 24.04.14 22:29, Tom Schindl wrote:
Hi,
I try to follow the guide at
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE to
setup my
Eclipse workspace but the description how to preconfigure the JDK
is a
ambiguous.
The ambiguous information is the cd PATH TO JFX which could
me (I
take my OS-X install as the reference)
* cd
/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk_nofx/Contents/Home/jre/lib/ext
* cd
/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk_nofx/Contents/Home/
BTW for Eclipse there's no an easier way to get Java8 support
you can
grab a prebuilt distro from
http://www.eclipse.org/downloads/index-java8.php
Tom
Getting some interesting output on master
Hi, I'm getting some interesting outputs/errors when running on 8u-dev/rt: a) When I shutdown i sometimes get Java has been detached already, but someone is still trying to use it at -[GlassRunnable run]:/Users/tomschindl/Documents/e-workspaces/OpenJFX-master/modules/graphics/src/main/native-glass/mac/GlassApplication.m:92 Java has been detached already, but someone is still trying to use it at -[GlassRunnable dealloc]:/Users/tomschindl/Documents/e-workspaces/OpenJFX-master/modules/graphics/src/main/native-glass/mac/GlassApplication.m:106 b) Also on shutdown I got (just once) java.lang.NullPointerException at com.sun.glass.ui.Application.invokeLater(Application.java:472) at com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:396) at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$12(QuantumToolkit.java:300) at com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$42/435457674.run(Unknown Source) Anyone else ever seen those? I'm currently working on DnD so this might be involved but I'm not able to reproduce is all time. Tom
Dragboard#setDragViewOffsetX/Y limitations
Hi, Using Dragboard#setDragViewOffsetX/Y allows me to offset the drag image but it looks like this x/y is constrainted to the image.width/2 image.height/2. Is this OS specific, a general limitation or a bug? If it is 1 or 2 I think information on that in the JavaDoc would help understand that. Tom
Embedding JavaFX in SWT on Linux (Gtk3)
Hi, Starting with Eclipse Luna (released in end of June) the default mode of SWT on Linux is to make use of Gtk3. As far as I understand the situation Glass on Linux is linked against Gtk2 so JavaFX components that need glass (=fairly everything beside javafx-properties) will fail to load - in fact i got reports that the JVM crashes. IIRC i read that monocole has a port that directly uses X11 would it be a work-around to run with this port when running in swt-embedding? Am I right that the webkit binaries are also linked against gtk2 or do I remember this wrong? Tom
Re: Embedding JavaFX in SWT on Linux (Gtk3)
Ok that's good to know so if we can get rid of glass-gtk we could at least run on gtk3 - as long as one does not use swing-awt in fx - i think all is better than nothing. Tom Von meinem iPhone gesendet Am 14.05.2014 um 19:03 schrieb Anthony Petrov anthony.pet...@oracle.com: Hi Tom, I ran ldd for libjfxwebkit.so, and I see that it doesn't link to GTK libraries. However, libjfxmedia.so does, so if you play any media files (either directly, or on a webpage open in webkit), then the GTK2 libraries will be loaded. -- best regards, Anthony On 5/14/2014 4:54 PM, Tom Schindl wrote: Hi, Starting with Eclipse Luna (released in end of June) the default mode of SWT on Linux is to make use of Gtk3. As far as I understand the situation Glass on Linux is linked against Gtk2 so JavaFX components that need glass (=fairly everything beside javafx-properties) will fail to load - in fact i got reports that the JVM crashes. IIRC i read that monocole has a port that directly uses X11 would it be a work-around to run with this port when running in swt-embedding? Am I right that the webkit binaries are also linked against gtk2 or do I remember this wrong? Tom
Re: Embedding JavaFX in SWT on Linux (Gtk3)
Even if dnd doesn't work that's better than no fx! Looks like webkit does not link into gtk which is good! Tom Von meinem iPhone gesendet Am 14.05.2014 um 17:09 schrieb Stephen F Northover steve.x.northo...@oracle.com: Hi Tom, https://javafx-jira.kenai.com/browse/RT-35264 There is no plan to move to gtk3 at this point. If we move to gtk3, FX will no longer be compatible with AWT/Swing which uses GTK2. The monocle port uses only X11 and this could be investigated, however, things like Drag and Drop are unlikely to work. I'll add all this information including Webkit use of GTK to RT-35264. Steve On 2014-05-14 8:54 AM, Tom Schindl wrote: Hi, Starting with Eclipse Luna (released in end of June) the default mode of SWT on Linux is to make use of Gtk3. As far as I understand the situation Glass on Linux is linked against Gtk2 so JavaFX components that need glass (=fairly everything beside javafx-properties) will fail to load - in fact i got reports that the JVM crashes. IIRC i read that monocole has a port that directly uses X11 would it be a work-around to run with this port when running in swt-embedding? Am I right that the webkit binaries are also linked against gtk2 or do I remember this wrong? Tom
