Re: [API Review]: Node validation
Hello, one more discussion topic: perhaps the validate name is too general? Maybe we can come up with more descriptive name? There are all kinds of nodes and sometimes this name can be misleading (not ringing the layout bell at all). For example TextField.validate() may look like validating the input. Also I wouldn't be surprised if users run into problems with custom nodes having their validate methods for different purposes. Pavel On 3.7.2013 14:33, Martin Sladecek wrote: Hi, JIRA: https://javafx-jira.kenai.com/browse/RT-31133 I propose a single method public final void validate() to be added to Node class. The validate method would ensure that the metrics (layout bounds) of the Node are valid with regards to the current scenegraph (CSS layout). Together with this change, Parent.layout() will be deprecated. In my current implementation, validate() method works only if the Node is in a Scene. To make it work without a Scene, we'd need to do do some small adjustments to CSS (doesn't work with getScene() == null). But I'm not sure if such feature would be useful. Regards, -Martin
hg: openjfx/8/graphics/rt: Fixed since for FC initial file name
Changeset: 2f9f7e525e2d Author:Lubomir Nerad lubomir.ne...@oracle.com Date: 2013-07-08 13:36 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2f9f7e525e2d Fixed since for FC initial file name ! modules/graphics/src/main/java/javafx/stage/FileChooser.java
Re: [API Review]: Node validation
The plan is to have a final validate() method. Anyway, does anybody have a better suggestion? The validate should do both CSS and layout and I would like to avoid method name that's too descriptive (like validateLayoutAndCSS()) if possible. I think the most important thing about the method is that it validates the bounds/metrics of the Node, so maybe validateBounds() ? -Martin On 07/08/2013 01:52 PM, Anthony Petrov wrote: +1 The validate()/isValid() in AWT/Swing are often overridden by user apps for tasks that have nothing to do with the layout. And this causes a lot of problems. -- best regards, Anthony On 07/08/13 15:20, Pavel Safrata wrote: Hello, one more discussion topic: perhaps the validate name is too general? Maybe we can come up with more descriptive name? There are all kinds of nodes and sometimes this name can be misleading (not ringing the layout bell at all). For example TextField.validate() may look like validating the input. Also I wouldn't be surprised if users run into problems with custom nodes having their validate methods for different purposes. Pavel On 3.7.2013 14:33, Martin Sladecek wrote: Hi, JIRA: https://javafx-jira.kenai.com/browse/RT-31133 I propose a single method public final void validate() to be added to Node class. The validate method would ensure that the metrics (layout bounds) of the Node are valid with regards to the current scenegraph (CSS layout). Together with this change, Parent.layout() will be deprecated. In my current implementation, validate() method works only if the Node is in a Scene. To make it work without a Scene, we'd need to do do some small adjustments to CSS (doesn't work with getScene() == null). But I'm not sure if such feature would be useful. Regards, -Martin
Re: [API Review]: Node validation
just my suggestions: validation is a side effect free concept. but your validate contains css layout processing for Node, so validate is very poor name in this case. May be better use computeBounds instead. But alternates for validate( if method is a side effect free): verify() verfifyNode() verifyBounds() checkNode() checkBounds() best Regards Ali Ebrahimi On Mon, Jul 8, 2013 at 4:50 PM, Martin Sladecek martin.slade...@oracle.comwrote: The plan is to have a final validate() method. Anyway, does anybody have a better suggestion? The validate should do both CSS and layout and I would like to avoid method name that's too descriptive (like validateLayoutAndCSS()) if possible. I think the most important thing about the method is that it validates the bounds/metrics of the Node, so maybe validateBounds() ? -Martin On 07/08/2013 01:52 PM, Anthony Petrov wrote: +1 The validate()/isValid() in AWT/Swing are often overridden by user apps for tasks that have nothing to do with the layout. And this causes a lot of problems. -- best regards, Anthony On 07/08/13 15:20, Pavel Safrata wrote: Hello, one more discussion topic: perhaps the validate name is too general? Maybe we can come up with more descriptive name? There are all kinds of nodes and sometimes this name can be misleading (not ringing the layout bell at all). For example TextField.validate() may look like validating the input. Also I wouldn't be surprised if users run into problems with custom nodes having their validate methods for different purposes. Pavel On 3.7.2013 14:33, Martin Sladecek wrote: Hi, JIRA: https://javafx-jira.kenai.com/**browse/RT-31133https://javafx-jira.kenai.com/browse/RT-31133 I propose a single method public final void validate() to be added to Node class. The validate method would ensure that the metrics (layout bounds) of the Node are valid with regards to the current scenegraph (CSS layout). Together with this change, Parent.layout() will be deprecated. In my current implementation, validate() method works only if the Node is in a Scene. To make it work without a Scene, we'd need to do do some small adjustments to CSS (doesn't work with getScene() == null). But I'm not sure if such feature would be useful. Regards, -Martin
Re: [API Review]: Node validation
On Mon, 2013-07-08 at 14:20 +0200, Martin Sladecek wrote: The plan is to have a final validate() method. Anyway, does anybody have a better suggestion? The validate should do both CSS and layout and I would like to avoid method name that's too descriptive (like validateLayoutAndCSS()) if possible. I think the most important thing about the method is that it validates the bounds/metrics of the Node, so maybe validateBounds() ? What about simply doLayout()? It seems to me that layouting is strictly correlated to CSS, and doLayout seems a pretty descriptive name for that purpose. Cheers, Mario
Gradle build, one step forward, two backward :)
Hi all! I tried to compile JavaFX with the gradle build, and here are my results, with different settings: 1. *** Closed Everything *** JAVA_HOME=/closed/jdk-8-ea-96/ BINARY_STUB=/closed/jdk-8-ea-96/jre/lib/ext/jfxrt.jar [neugens@galactica rt]$ gradle jfxrt Loading ... :jfxrtLinux :jfxrt BUILD SUCCESSFUL Running an Hello World with the same configuration, but removing the closed jfxrt.jar still fails: Caused by: java.lang.NullPointerException at com.sun.javafx.font.PrismFontLoader.loadFont(PrismFontLoader.java:220) at javafx.scene.text.Font.init(Font.java:318) at javafx.scene.text.Font.getDefault(Font.java:85) at javafx.scene.CssStyleHelper.clinit(CssStyleHelper.java:1329) :( Was't the font code open sourced? 2. *** OpenJDK with closed jfxrt.jar *** The OpenJDK build fails before getting anywhere, which is very surprising to me: JAVA_HOME=/open/jdk-8/ BINARY_STUB=/closed/jdk-8-ea-96/jre/lib/ext/jfxrt.jar [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on artifact cache (/home/neugens/.gradle/caches/artifacts-23). [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Finished executing task ':graphics:compileJava' [ERROR] [org.gradle.BuildExceptionReporter] FAILURE: Build failed with an exception. * What went wrong: Could not resolve all dependencies for configuration ':graphics:compile'. Could not find :plugin:. Required by: rt:graphics:unspecified * Exception is: org.gradle.api.artifacts.ResolveException: Could not resolve all dependencies for configuration ':graphics:compile'. at org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration.rethrowFailure(DefaultLenientConfiguration.java:52) at org.gradle.api.internal.artifacts.ivyservice.DefaultResolvedConfiguration.rethrowFailure(DefaultResolvedConfiguration.java:36) Any help here would be great... I don't see why OpenJDK is not able to build OpenJFX, even having the closed jar in the path. 3. *** Closed JDK with openjfxrt.jar *** This fails. I expected this, but the build goes very far it seems: public final class AudioClipBuilder implements javafx.util.Builderjavafx.scene.media.AudioClip [...] symbol: class WebEvent location: class WebEngineBuilder error: cannot find symbol [...] 4. *** OpenJDK with just created open jfxrt.jar *** Well, you guessed this fails too... I wonder how the iOS people got their code working at all... Is there any secret repository you guys are using? 5. *** Running OpenJDK with closed jfxrt.jar *** This is even nicer: Graphics Device initialization failed for : es2, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found [...] Caused by: java.lang.RuntimeException: No toolkit found at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:213) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:181) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:637) at com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:345) at com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:304) I think the OpenJDK build (2.) and running closed jfrt.jar + OpenJDK (5.) are the most serious issues at the moment. I remember that running closed jfx with OpenJDK used to work, but maybe I'm wrong. Any plans to address that, or hints where I can start looking to help out? Cheers, Mario
Re: Gradle build, one step forward, two backward :)
Caused by: java.lang.NullPointerException at com.sun.javafx.font.PrismFontLoader.loadFont(PrismFontLoader.java:220) at javafx.scene.text.Font.init(Font.java:318) at javafx.scene.text.Font.getDefault(Font.java:85) at javafx.scene.CssStyleHelper.clinit(CssStyleHelper.java:1329) :( Was't the font code open sourced? You are on Linux I'm guessing (educated guess). The open source linux implementation was I believe just barely pushed. Which repo are you building from (master or graphics)? 2. *** OpenJDK with closed jfxrt.jar *** The OpenJDK build fails before getting anywhere, which is very surprising to me: JAVA_HOME=/open/jdk-8/ BINARY_STUB=/closed/jdk-8-ea-96/jre/lib/ext/jfxrt.jar [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on artifact cache (/home/neugens/.gradle/caches/artifacts-23). [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Finished executing task ':graphics:compileJava' [ERROR] [org.gradle.BuildExceptionReporter] FAILURE: Build failed with an exception. * What went wrong: Could not resolve all dependencies for configuration ':graphics:compile'. Could not find :plugin:. Required by: rt:graphics:unspecified * Exception is: org.gradle.api.artifacts.ResolveException: Could not resolve all dependencies for configuration ':graphics:compile'. at org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration.rethrowFailure(DefaultLenientConfiguration.java:52) at org.gradle.api.internal.artifacts.ivyservice.DefaultResolvedConfiguration.rethrowFailure(DefaultResolvedConfiguration.java:36) Any help here would be great... I don't see why OpenJDK is not able to build OpenJFX, even having the closed jar in the path. Ah. OK. The problem here is that a couple of the modules require the plugin.jar because of JSObject.java. Possibly if we move the file from web module to base (or graphics module) then we wouldn't need this dependency. If you edit build.gradle and comment out the plugin dependency and do a build, you should see where the build failures occur. I did a search and see JSObject.java in two places, web and graphics modules. Yikes. 3. *** Closed JDK with openjfxrt.jar *** This fails. I expected this, but the build goes very far it seems: public final class AudioClipBuilder implements javafx.util.Builderjavafx.scene.media.AudioClip [...] symbol: class WebEvent location: class WebEngineBuilder error: cannot find symbol […] I guess this is looking for media files. When they are open sourced hopefully this will work. 4. *** OpenJDK with just created open jfxrt.jar *** Well, you guessed this fails too... I wonder how the iOS people got their code working at all... Is there any secret repository you guys are using? Probably the same issue as #3? The iOS folks are skipping media web I believe. 5. *** Running OpenJDK with closed jfxrt.jar *** This is even nicer: Graphics Device initialization failed for : es2, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found [...] Caused by: java.lang.RuntimeException: No toolkit found at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:213) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:181) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:637) at com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:345) at com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:304) This happens if the native libraries cannot be found. They need to be located relative to the jfxrt.jar that you are using. How are you running this application? I think the OpenJDK build (2.) and running closed jfrt.jar + OpenJDK (5.) are the most serious issues at the moment. I remember that running closed jfx with OpenJDK used to work, but maybe I'm wrong. Any plans to address that, or hints where I can start looking to help out? Actually I think we should start here with just a fully open build. Anything using media will fail at runtime, but we should still be able to compile and I think the native font stuff for linux is out there, along with build changes by Peter to support fully open builds of web view. I'm going to fire up a new VM with a completely clean Ubuntu system and try building with OpenJDK so I can follow along. Richard
Re: [API Review]: Node validation
OK, just throwing something wild out there. Right now we have a layout pass and a css pass. Can they be combined? Can we combine them just into something that happens during layout? And can the existing layout() method be the thing that kicks it all off? Wild and crazy but just throwing it out there (personally I'm uncomfortable conflating CSS and layout as I believe there will be use cases to do one and not the other at times). Richard On Jul 8, 2013, at 9:27 AM, Scott Palmer swpal...@gmail.com wrote: Since CSS is implicitly tied to layout, validateLayout() seems to be enough. I don't like verify or check - To me, these imply a method that is doing checks only and not changing state. A verify method would be something that returns a boolean or throws an exception. Scott On Mon, Jul 8, 2013 at 9:07 AM, Ali Ebrahimi ali.ebrahimi1...@gmail.comwrote: just my suggestions: validation is a side effect free concept. but your validate contains css layout processing for Node, so validate is very poor name in this case. May be better use computeBounds instead. But alternates for validate( if method is a side effect free): verify() verfifyNode() verifyBounds() checkNode() checkBounds() best Regards Ali Ebrahimi On Mon, Jul 8, 2013 at 4:50 PM, Martin Sladecek martin.slade...@oracle.comwrote: The plan is to have a final validate() method. Anyway, does anybody have a better suggestion? The validate should do both CSS and layout and I would like to avoid method name that's too descriptive (like validateLayoutAndCSS()) if possible. I think the most important thing about the method is that it validates the bounds/metrics of the Node, so maybe validateBounds() ? -Martin On 07/08/2013 01:52 PM, Anthony Petrov wrote: +1 The validate()/isValid() in AWT/Swing are often overridden by user apps for tasks that have nothing to do with the layout. And this causes a lot of problems. -- best regards, Anthony On 07/08/13 15:20, Pavel Safrata wrote: Hello, one more discussion topic: perhaps the validate name is too general? Maybe we can come up with more descriptive name? There are all kinds of nodes and sometimes this name can be misleading (not ringing the layout bell at all). For example TextField.validate() may look like validating the input. Also I wouldn't be surprised if users run into problems with custom nodes having their validate methods for different purposes. Pavel On 3.7.2013 14:33, Martin Sladecek wrote: Hi, JIRA: https://javafx-jira.kenai.com/**browse/RT-31133 https://javafx-jira.kenai.com/browse/RT-31133 I propose a single method public final void validate() to be added to Node class. The validate method would ensure that the metrics (layout bounds) of the Node are valid with regards to the current scenegraph (CSS layout). Together with this change, Parent.layout() will be deprecated. In my current implementation, validate() method works only if the Node is in a Scene. To make it work without a Scene, we'd need to do do some small adjustments to CSS (doesn't work with getScene() == null). But I'm not sure if such feature would be useful. Regards, -Martin
Re: Node bounds documentation issue?
I think you are right and the docs should be updated to indicate this. If you would like to file a JIRA and a patch that would be awesome. Thanks Richard On Jul 8, 2013, at 9:20 AM, Scott Palmer swpal...@gmail.com wrote: The javadocs discussing Bounding Rectangles for Node state: The images show a filled and stroked rectangle and their bounds. The first rectangle [x:10.0 y:10.0 width:100.0 height:100.0 strokeWidth:0] has the following bounds bounds: [x:10.0 y:10.0 width:100.0 height:100.0]. The second rectangle [x:10.0 y:10.0 width:100.0 height:100.0 strokeWidth:5] has the following bounds: [x:5.0 y:5.0 width:110.0 height:110.0]. Since neither of the rectangles has any transformation applied, boundsInParent and boundsInLocal are the same. But I think that is wrong, or at least incomplete and potentially misleading. Rectangle is a Shape so the StrokeType matters here and the default StrokeType is CENTERED. (Though when I drop one on the Scene in Scene Builder, it defaults to INSIDE, something that I think should be considered a SceneBuilder bug.) So by default the bounds would be only extending 2.5 on each side for a total width and height of 105 and x and y coordinates of 7.5. Scott
Re: [API Review]: Node validation
validateVisuals() ? Or something with the word visual as it combines layout and other CSS information. Scott On Mon, Jul 8, 2013 at 12:31 PM, Richard Bair richard.b...@oracle.comwrote: OK, just throwing something wild out there. Right now we have a layout pass and a css pass. Can they be combined? Can we combine them just into something that happens during layout? And can the existing layout() method be the thing that kicks it all off? Wild and crazy but just throwing it out there (personally I'm uncomfortable conflating CSS and layout as I believe there will be use cases to do one and not the other at times). Richard On Jul 8, 2013, at 9:27 AM, Scott Palmer swpal...@gmail.com wrote: Since CSS is implicitly tied to layout, validateLayout() seems to be enough. I don't like verify or check - To me, these imply a method that is doing checks only and not changing state. A verify method would be something that returns a boolean or throws an exception. Scott On Mon, Jul 8, 2013 at 9:07 AM, Ali Ebrahimi ali.ebrahimi1...@gmail.com wrote: just my suggestions: validation is a side effect free concept. but your validate contains css layout processing for Node, so validate is very poor name in this case. May be better use computeBounds instead. But alternates for validate( if method is a side effect free): verify() verfifyNode() verifyBounds() checkNode() checkBounds() best Regards Ali Ebrahimi On Mon, Jul 8, 2013 at 4:50 PM, Martin Sladecek martin.slade...@oracle.comwrote: The plan is to have a final validate() method. Anyway, does anybody have a better suggestion? The validate should do both CSS and layout and I would like to avoid method name that's too descriptive (like validateLayoutAndCSS()) if possible. I think the most important thing about the method is that it validates the bounds/metrics of the Node, so maybe validateBounds() ? -Martin On 07/08/2013 01:52 PM, Anthony Petrov wrote: +1 The validate()/isValid() in AWT/Swing are often overridden by user apps for tasks that have nothing to do with the layout. And this causes a lot of problems. -- best regards, Anthony On 07/08/13 15:20, Pavel Safrata wrote: Hello, one more discussion topic: perhaps the validate name is too general? Maybe we can come up with more descriptive name? There are all kinds of nodes and sometimes this name can be misleading (not ringing the layout bell at all). For example TextField.validate() may look like validating the input. Also I wouldn't be surprised if users run into problems with custom nodes having their validate methods for different purposes. Pavel On 3.7.2013 14:33, Martin Sladecek wrote: Hi, JIRA: https://javafx-jira.kenai.com/**browse/RT-31133 https://javafx-jira.kenai.com/browse/RT-31133 I propose a single method public final void validate() to be added to Node class. The validate method would ensure that the metrics (layout bounds) of the Node are valid with regards to the current scenegraph (CSS layout). Together with this change, Parent.layout() will be deprecated. In my current implementation, validate() method works only if the Node is in a Scene. To make it work without a Scene, we'd need to do do some small adjustments to CSS (doesn't work with getScene() == null). But I'm not sure if such feature would be useful. Regards, -Martin
Re: [API Review]: Node validation
I say validate should also not change state, otherwise computeBounds would be better name for method. Consider validate in input validation. On Mon, Jul 8, 2013 at 8:57 PM, Scott Palmer swpal...@gmail.com wrote: Since CSS is implicitly tied to layout, validateLayout() seems to be enough. I don't like verify or check - To me, these imply a method that is doing checks only and not changing state. A verify method would be something that returns a boolean or throws an exception. Scott On Mon, Jul 8, 2013 at 9:07 AM, Ali Ebrahimi ali.ebrahimi1...@gmail.com wrote: just my suggestions: validation is a side effect free concept. but your validate contains css layout processing for Node, so validate is very poor name in this case. May be better use computeBounds instead. But alternates for validate( if method is a side effect free): verify() verfifyNode() verifyBounds() checkNode() checkBounds() best Regards Ali Ebrahimi On Mon, Jul 8, 2013 at 4:50 PM, Martin Sladecek martin.slade...@oracle.comwrote: The plan is to have a final validate() method. Anyway, does anybody have a better suggestion? The validate should do both CSS and layout and I would like to avoid method name that's too descriptive (like validateLayoutAndCSS()) if possible. I think the most important thing about the method is that it validates the bounds/metrics of the Node, so maybe validateBounds() ? -Martin On 07/08/2013 01:52 PM, Anthony Petrov wrote: +1 The validate()/isValid() in AWT/Swing are often overridden by user apps for tasks that have nothing to do with the layout. And this causes a lot of problems. -- best regards, Anthony On 07/08/13 15:20, Pavel Safrata wrote: Hello, one more discussion topic: perhaps the validate name is too general? Maybe we can come up with more descriptive name? There are all kinds of nodes and sometimes this name can be misleading (not ringing the layout bell at all). For example TextField.validate() may look like validating the input. Also I wouldn't be surprised if users run into problems with custom nodes having their validate methods for different purposes. Pavel On 3.7.2013 14:33, Martin Sladecek wrote: Hi, JIRA: https://javafx-jira.kenai.com/**browse/RT-31133 https://javafx-jira.kenai.com/browse/RT-31133 I propose a single method public final void validate() to be added to Node class. The validate method would ensure that the metrics (layout bounds) of the Node are valid with regards to the current scenegraph (CSS layout). Together with this change, Parent.layout() will be deprecated. In my current implementation, validate() method works only if the Node is in a Scene. To make it work without a Scene, we'd need to do do some small adjustments to CSS (doesn't work with getScene() == null). But I'm not sure if such feature would be useful. Regards, -Martin
Re: API REVIEW for TabPane tab content loading and fixed content size
Hi Paru, I have a few questions. The first is, why does it make a difference whether the tab content is added to the scene graph or not? If a node is marked visible=false, it *should* be essentially the same as not being in the graph. That entire branch shouldn't be picked, etc. I don't doubt that you are seeing a performance difference, but I wonder whether the right answer is to fix the places in the SG (if possible) that are causing this problem (perhaps, for example, layout?) rather than adding an API which controls when the tab contents are added to the SG. In particular, we know we have a problem when it comes to computing the preferred size of the TabPane. On Jul 3, 2013, at 2:03 PM, Paru Somashekar parvathi.somashe...@oracle.com wrote: There might be a situation where the TabContentSceneGraphPolicy is set to SELECTED_TAB in which case only the content of the selected tab is loaded and user does not set fixed size. In such a case, we can either do one of the following, 1) hardcode a fixed size if it is not already set 2) measure the selected tab only and grow in size only if the size of the next selected tab is bigger than the previous one. 3) throw an exception if SELECTED_TAB is chosen and fixed size is not set. I prefer option either 1 or 2, that way we do not force the developer to set a fixed size for the tab content. Thoughts suggestions welcome, I shall go with option 1 if I don't hear any. This I think is the real question, how to deal with the pref size of a TabPane? Right now, we will ask each tab for its pref size, and then take the max pref width / pref height from the tabs, add on the tab pane insets etc and return that. Is that correct? So is the large cost in adding the tab content to the SG just that it is being included in these computations, or is there something else? I'm worried that the TabContentSceneGraphPolicy is going to exacerbate the problem, because the pref size will change as tabs are changed and *by default* this will probably lead to the tab pane changing its size on people (depending on the layout container, but imagine an HBox or something for example). One answer is backwards incompatible: change tabbed pane to have a hard-coded pref size. Not a very nice answer. Another solution is to add an enum which indicates how the tabbed pane should compute its pref size: - based on the pref size of all tabs - based on the pref size of the initial tab - based on the pref size of the selected tab? Is this one useful? And then always leave all tab content in the SG but just change how the pref size is being computed. By default it is all tabs, but can be set to initial tab or hard-coded by the developer? Do we know why having tab pane content in the SG when it is not visible is a performance problem? Thanks Richard
hg: openjfx/8/graphics/rt: Added standalone IntelliJ Project for 3DViewer App
Changeset: 228c5ed14f8f Author:Jasper Potts Date: 2013-07-08 14:23 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/228c5ed14f8f Added standalone IntelliJ Project for 3DViewer App + apps/experiments/3DViewer/.idea/.name + apps/experiments/3DViewer/.idea/compiler.xml + apps/experiments/3DViewer/.idea/copyright/profiles_settings.xml + apps/experiments/3DViewer/.idea/encodings.xml + apps/experiments/3DViewer/.idea/misc.xml + apps/experiments/3DViewer/.idea/modules.xml + apps/experiments/3DViewer/.idea/runConfigurations/3DViewer.xml + apps/experiments/3DViewer/.idea/scopes/scope_settings.xml + apps/experiments/3DViewer/.idea/vcs.xml + apps/experiments/3DViewer/3DViewer.iml
hg: openjfx/8/controls/rt: 7 new changesets
Changeset: d6d09c8c7236 Author:jgiles Date: 2013-07-05 12:02 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d6d09c8c7236 Fix small regression due to RT-31173: custom skins could no longer be set on PopupControl but now they can. Thanks to Claudine Zillmann for notification of this. ! modules/controls/src/main/java/javafx/scene/control/Control.java Changeset: 51cabebc81a9 Author:jgiles Date: 2013-07-08 17:58 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/51cabebc81a9 RT-31460: Allow VirtualContainerBase and derived classes to use a pre-existing instance of a subclass of VirtualFlow ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualContainerBase.java Changeset: 1788f06e4db6 Author:jgiles Date: 2013-07-09 10:14 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1788f06e4db6 RT-31459: Make VirtualFlow derivable. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/VirtualFlow.java Changeset: f20fb68594aa Author:jgiles Date: 2013-07-09 10:21 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f20fb68594aa RT-31475: Move a Property into the CSS on TableColumnHeader ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/caspian/caspian.css ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 3ff782c8ad7b Author:jgiles Date: 2013-07-09 10:23 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3ff782c8ad7b RT-31477: Null used in TableCellBehavior ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TableCellBehavior.java Changeset: 31136be6a98a Author:jgiles Date: 2013-07-09 11:02 +1200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/31136be6a98a Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 7e373b49ebaa Author:leifs Date: 2013-07-08 16:26 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7e373b49ebaa RT-30549: DatePicker doesn't allow to type date when using non-ISO chronology ! modules/controls/src/main/java/javafx/scene/control/DatePicker.java
