From yennick.trevels at gmail.com Fri Feb 1 00:16:23 2013 From: yennick.trevels at gmail.com (Yennick Trevels) Date: Fri, 1 Feb 2013 09:16:23 +0100 Subject: JavaFx system requirements: Intel GMA 4500MHD: driver update problem In-Reply-To: References: Message-ID: Anyone has any thoughts on this? Is there a compatibility mode that I can turn on? On Wed, Jan 30, 2013 at 7:59 PM, Yennick Trevels wrote: > Hi, > > I'm having a problem getting JavaFx to work on my laptop because of the > currently installed display driver. > I'm always getting the following error when I try to run my JavaFx > application: > > Device "Mobile Intel(R) 4 Series Express Chipset Family" > (\\.\DISPLAY1) initialization failed : > WARNING: bad driver version detected, device disabled. Please update > your driver to at least version 8.15.10.2302 > > Now, this message is very clear on what I need to do, but I can't update > my drivers to that version even though my graphics card should be supported > according to the official system requirements of JavaFx ( > http://docs.oracle.com/javafx/2/system_requirements_2-2-4/jfxpub-system_requirements_2-2-4.htm > ). > > My laptop is a Sony Vaio VGN-BZ13XN with a Mobile Intel? Graphics Media > Accelerator 4500MHD graphics card (which is in the supported list). I > updated my drivers with the VAIO Update program, but it's only upgrading to > driver version 8.15.10.1855. > I tried downloading the updated driver directly from the Intel site, but > it refuses to execute the installation because it detects that I'm on a > Sony device. > > Is there a solution for this? If not, then maybe the system requirements > page should indicate the driver version instead of the graphics card model. > Also, my laptop isn't new, but not really old (5+years) either, it's only > about 3 years old. So this could become a problem to deploy JavaFx > applications in an enterprise environment where pc's/laptops aren't > upgraded every few years. > > Thanks, > Yennick > From tobi at ultramixer.com Fri Feb 1 00:38:46 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Fri, 1 Feb 2013 09:38:46 +0100 Subject: SkinBehaviour and JavaFX 8? Message-ID: <23D5144B-7038-4EB6-BC29-E3D6AA43A7AF@ultramixer.com> Hi, there seams to be some changes from JavaFX 2 to JavaFX8 concerning SkinBase and SkinBehavior. In JFX2 you could call the constructor from SkinBase with a component (e.g. slider) and a skin behavior. In JFX8 it's not possible any more, I could only call the constructor of SkinBase with the control, not with the SkinBehavior. So my question is: How do I have to specify the SkinBehavior in JavaFX8? Best regards, Tobi From martin.sladecek at oracle.com Fri Feb 1 00:58:55 2013 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Fri, 01 Feb 2013 09:58:55 +0100 Subject: What the Duration of negative Infinity mean? In-Reply-To: <12F3DF67-FD28-4E1A-A8CC-2CBF3848078D@gmail.com> References: <74F5A60A-E19A-49E2-9823-072F8920521A@oracle.com> <510A278B.5070108@oracle.com> <389E3887-D38B-47A2-86F7-6E0874076AB0@oracle.com> <510A97AA.90700@oracle.com> <1314512F-7117-4392-91D5-B64E9B8ACA6D@oracle.com> <510AAD0E.3050503@oracle.com> <12F3DF67-FD28-4E1A-A8CC-2CBF3848078D@gmail.com> Message-ID: <510B83CF.3070600@oracle.com> Scott is right here, we shouldn't check for wrong values in Duration, but rather in the API that accepts Duration. This means negative infinity is just negative infinity. It's up to the API how it will treated, we don't need to disallow it or have some special name for it. But as for all of our API so far, all negative values are illegal, so is the negative infinity. -Martin On 02/01/2013 03:07 AM, Scott Palmer wrote: > On 2013-01-31, at 12:42 PM, Martin Sladecek wrote: > >> The other option is not to throw the exception and keep the Duration values above zero. If a > b, then b.subtract(a) will result in 0. > This may just be an intermediate value that is later added as in Richard's example. > > > But, I think this is over complicating things. What exactly are we trying to accomplish? A negative duration doesn't make sense as a *final value*, so in the context of setting the actual duration to use for an interval, I think it makes sense to disallow negative values, even though the Duration object is allowed to hold them. It's no different than an API that takes integers where you must supply a positive value for the API to accept your input. > > The SchedulerService can't use a negative duration unless you've incorporated time travel into it. > > For a general Duration, POSITIVE_INFINITY can map to isIndefinite, and NEGATIVE_INFINITY can be illegal or indefinite, either makes sense. > > Scott > From jonathan.giles at oracle.com Fri Feb 1 01:17:12 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Fri, 01 Feb 2013 22:17:12 +1300 Subject: SkinBehaviour and JavaFX 8? In-Reply-To: <23D5144B-7038-4EB6-BC29-E3D6AA43A7AF@ultramixer.com> References: <23D5144B-7038-4EB6-BC29-E3D6AA43A7AF@ultramixer.com> Message-ID: <510B8818.8030409@oracle.com> Tobi, To start with I need to be clear that in JavaFX 2.x SkinBase and BehaviorBase were private APIs (that is, they both resided in com.sun.* packages). This means that they shouldn't have been used by third parties. Instead, third parties should have been building from the Skin interface. Of course, most people used SkinBase, and whenever I went to conferences I would promise people that the day of reckoning would come when I broke them. Well, that day is fast approaching.... :-) JavaFX 8.0 brings SkinBase to public API, but we are not prepared to bring BehaviorBase along with it just yet. This is because the concept of a behavior needs to be fleshed out further in a number of directions, including: * Making behaviors less opaque (i.e. more easily accessible to developers via the control - in other words bringing the concepts of actions and input/action maps to JavaFX), * Improving toolability of behaviors / actions (so tools such as Scene Builder can know that a TextField offers cut/copy/paste, for example), * Making it possible for developers to override and provide custom input mappings / actions more easily. It's late here and I'm sure there were other reasons for wanting more bake time on behaviors, but this was the general gist of things. What this means is that SkinBase in JavaFX 8.0 has no notion whatsoever of a behavior for specifying key/mouse input event handling. In other words, your code will need to manually handle keyboard and mouse interactions. In the future I am sure we will get to this point, but we are not there yet. Finally, don't look at how we in the UI controls team do it. I wouldn't want you to see the (very private!!!) BehaviorSkinBase class that is essentially a drop-in replacement for the old SkinBase class. Of course, if you did see this I'm sure you wouldn't use it as it is private API that I (once again) promise to change in the future when we resolve the behavior discussion. -- Jonathan On 1/02/2013 9:38 p.m., Tobias Bley wrote: > Hi, > > there seams to be some changes from JavaFX 2 to JavaFX8 concerning SkinBase and SkinBehavior. In JFX2 you could call the constructor from SkinBase with a component (e.g. slider) and a skin behavior. In JFX8 it's not possible any more, I could only call the constructor of SkinBase with the control, not with the SkinBehavior. > > So my question is: How do I have to specify the SkinBehavior in JavaFX8? > > Best regards, > Tobi > From kevin.rushforth at oracle.com Fri Feb 1 06:25:30 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 01 Feb 2013 06:25:30 -0800 Subject: JavaFx system requirements: Intel GMA 4500MHD: driver update problem In-Reply-To: References: Message-ID: <510BD05A.80508@oracle.com> You can bypass the driver version check with a system property: java -Dprism.forceGPU=true ... Note that there are (or were) known bugs with this driver version that you may run into. -- Kevin Yennick Trevels wrote: > Anyone has any thoughts on this? Is there a compatibility mode that I can > turn on? > > > On Wed, Jan 30, 2013 at 7:59 PM, Yennick Trevels > wrote: > > >> Hi, >> >> I'm having a problem getting JavaFx to work on my laptop because of the >> currently installed display driver. >> I'm always getting the following error when I try to run my JavaFx >> application: >> >> Device "Mobile Intel(R) 4 Series Express Chipset Family" >> (\\.\DISPLAY1) initialization failed : >> WARNING: bad driver version detected, device disabled. Please update >> your driver to at least version 8.15.10.2302 >> >> Now, this message is very clear on what I need to do, but I can't update >> my drivers to that version even though my graphics card should be supported >> according to the official system requirements of JavaFx ( >> http://docs.oracle.com/javafx/2/system_requirements_2-2-4/jfxpub-system_requirements_2-2-4.htm >> ). >> >> My laptop is a Sony Vaio VGN-BZ13XN with a Mobile Intel? Graphics Media >> Accelerator 4500MHD graphics card (which is in the supported list). I >> updated my drivers with the VAIO Update program, but it's only upgrading to >> driver version 8.15.10.1855. >> I tried downloading the updated driver directly from the Intel site, but >> it refuses to execute the installation because it detects that I'm on a >> Sony device. >> >> Is there a solution for this? If not, then maybe the system requirements >> page should indicate the driver version instead of the graphics card model. >> Also, my laptop isn't new, but not really old (5+years) either, it's only >> about 3 years old. So this could become a problem to deploy JavaFx >> applications in an enterprise environment where pc's/laptops aren't >> upgraded every few years. >> >> Thanks, >> Yennick >> >> From hang.vo at oracle.com Fri Feb 1 06:48:47 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 01 Feb 2013 14:48:47 +0000 Subject: hg: openjfx/8/graphics/rt: Fix for "coverage" target running on JDK7 Message-ID: <20130201144852.9B08447753@hg.openjdk.java.net> Changeset: 12bef5a3a874 Author: Martin Sladecek Date: 2013-02-01 15:34 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/12bef5a3a874 Fix for "coverage" target running on JDK7 ! build-defs.xml From hang.vo at oracle.com Fri Feb 1 07:33:53 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 01 Feb 2013 15:33:53 +0000 Subject: hg: openjfx/8/controls/rt: RT-28130 : Resolve Findbugs issues in com.sun.javafx.scene.control.ScrollBar Message-ID: <20130201153358.A139747756@hg.openjdk.java.net> Changeset: cc7fed4a834c Author: mickf Date: 2013-02-01 15:27 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/cc7fed4a834c RT-28130 : Resolve Findbugs issues in com.sun.javafx.scene.control.ScrollBar ! javafx-ui-controls/src/javafx/scene/control/ScrollBar.java From hang.vo at oracle.com Fri Feb 1 08:18:34 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 01 Feb 2013 16:18:34 +0000 Subject: hg: openjfx/8/controls/rt: RT-25288: add support for functional pseudo-class :dir() Message-ID: <20130201161836.98DD347758@hg.openjdk.java.net> Changeset: 74802b5965e1 Author: David Grieve Date: 2013-02-01 11:16 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/74802b5965e1 RT-25288: add support for functional pseudo-class :dir() ! javafx-ui-common/src/com/sun/javafx/css/Match.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java ! javafx-ui-common/src/javafx/scene/Scene.java + javafx-ui-common/test/unit/javafx/scene/Node_effectiveOrientation_Css_Test.java From pavel.safrata at oracle.com Fri Feb 1 08:51:52 2013 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Fri, 01 Feb 2013 17:51:52 +0100 Subject: [API Review] RT-28129: event coordinates with perspective camera Message-ID: <510BF2A8.9080307@oracle.com> Hello, this is related to the 3D support planned for FX8, yet it is a bugfix of an existing issue. With perspective camera, events delivered to any node that's not lying flat on the XY plane contain wrong local coordinates - they ignore the projection transformations. It's enough to rotate a rectangle along X axis and the coordinates become useless. http://javafx-jira.kenai.com/browse/RT-28129 Solution to this problem requires API changes, because we need to compute in 3D to get proper numbers. So I propose to add a "double getZ()" method to all picking-based events, with the following semantics: the event's getSceneX(), getSceneY() values still represent the 2D coordinates of the mouse in the window content pixels (screen coordinates minus window position and decorations); the getX(), getY(), getZ() represent the hit point in the local 3D space (which may now be different even for scene because of the perspective transform). If no node is picked, the hit point with the scene will be found on the projection plane. Note that nothing changes for the 2D case, for the 3D case we now have correct 3D coordinates instead of a complete nonsense. There is one more issue - how to pass the correct coordinates to the event constructors. Instead of creating more construrctors with the three additional coordinates, I propose to use a concept called PickResult which was briefly discussed earlier and will soon be part of a 3D API review. In short, it is an object that contains information about the pick for the event - the picked node, local coordinates of the hit and some 3D-specific stuff. For proper 3D support, it will anyway be necessary to pass the PickResult to the events and allow access to it; once this is done, the event can compute the coordinates from it. So I propose adding PickResult to the event constructors. Note that they've not been released yet, so we can modify them instead of adding new ones. Also note that for convenience of 2D use-cases, the constructors will accept a null PickResult and in this case compute PickResult values based on the passed event target and scene coordinates (which is sufficient for 2D case). Side note for those who remember the previous 3D API discussion: the PickResult is no longer restricted to 3d shapes, it is present always, with the 3D-specific fields having null values where not applicable. Summary of this proposal: Affected classes: MouseEvent, MouseDragEvent, DragEvent, GestureEvent, ContextMenuEvent and TouchPoint new methods: getZ(), getPickResult() (and extended semantics of event local coordinates for 3D case) modified methods: added PickResult to all constructors Concrete description of the PickResult and the proposed picking API can be found here: https://wikis.oracle.com/display/OpenJDK/Picking3dAPI Thanks, Pavel From hang.vo at oracle.com Fri Feb 1 09:04:31 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 01 Feb 2013 17:04:31 +0000 Subject: hg: openjfx/8/graphics/rt: Partial RT-28089 Message-ID: <20130201170435.356264775C@hg.openjdk.java.net> Changeset: f77dec4adb2a Author: Richard Bair Date: 2013-02-01 08:57 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f77dec4adb2a Partial RT-28089 Summary: Moved build.gradle & settings.gradle to rt. renamed generator.gradle to build.gradle. + build.gradle + settings.gradle From richard.bair at oracle.com Fri Feb 1 09:07:12 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 1 Feb 2013 09:07:12 -0800 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: References: Message-ID: <1B3DF0AE-C47D-4EE8-A8CF-58BE0539AC4E@oracle.com> I just pushed to the rt repo my two "work in progress" gradle scripts, build.gradle and settings.gradle. You will find that these don't work. The reason is that I have another (still closed) "generator" gradle script which takes the existing sources and munges them around into a directory structure that the new gradle scripts work against. I'm working with the full set of sources and trying to get the new build to work with the full set of sources. I'm targeting the end of the month (Feb) for having the build system sorted out. For example my "generator" script looks like: task generate << { // Copy over the new gradle build file copy { from "." into "javafx" include "build.gradle", "settings.gradle" } // Create the build-tools project copy { from "rt/javafx-annotation-processor/src", "rt/decora-compiler/src" into "javafx/build-tools/src/main/java" exclude "META-INF/**", "**/*.properties", "**/*.stg", "**/JSL.g" } copy { from "rt/javafx-annotation-processor/src", "rt/decora-compiler/src" into "javafx/build-tools/src/main/resources" include "META-INF/**", "**/*.properties", "**/*.stg" } copy { from "rt/decora-compiler/src/com/sun/scenario/effect/compiler/JSL.g" into "javafx/build-tools/src/main/antlr" } copy { from "rt-closed/javafx-beans/src" into "javafx/build-tools/src/main/java" include "com/sun/javafx/beans/annotations/**", "com/sun/javafx/collections/annotations/**" } ?. and lots more } You can see some paths are "rt/" and some are "rt-closed/". What I can do is create a generator.gradle file in rt that contains only the portion that is already open so that people in the community can try out the new structure / contribute / etc? The main gradle build file then needs to just include jfxrt.jar on the build path as the binary plug. Thoughts? Richard On Oct 19, 2012, at 7:24 AM, Danno Ferrin wrote: > > > On Fri, Oct 19, 2012 at 7:31 AM, Mario Torre wrote: > > Further more, you should be able to do "find usages" in your IDE and get EVERYTHING IN THE UNIVERSE, rather than right now where in NB it doesn't have enough information about the 160 other projects in our system to be able to do this. This is bad. > > > > Right now we build with ant. Many of you have suggested Maven. Some of you at JavaOne suggested Gradle. I am presently looking into Gradle. The key things I like about Gradle are: > > > > 1) It isn't XML > > 2) Like Ivy & Maven, it handles dependencies well > > > > We presently have a pile of XML files and nasty build logic for downloading dependencies (this is all in the closed repo, but you would be exposed to the horror if we just made it all public). I wanted instead to use Ivy at the very least, but rather if I can get better build happiness from another setup entirely (like Gradle) then I might as well give it a try. > > I kind of like Gradle, but let me put the cart before the horse here > (I don't know if this sounds as well in English as it is in Italian, > where we actually use the oxen, but well :) > > While Maven is a well understood tool, Gradle is fairly new. This > turns to be especially problematic when building and shipping on Linux > distributions because there are some constraints and limitation on > what can go or not in a given release (btw, I think this could be > considered a problem on Windows and OSX installations in some > environments where you can't simply install any tool you want). > > Maven, on the other end, is pretty likely sitting on your machine > already (as are Make, GCC and Configure most of the time on developers > machines), so I suspect it will be easier for the average folk as well > as heavily filled packager to take care of the build bits. > > Gradle has a "wrapper" script that can be checked in with the build (the gradlew script), it will download the specific version of gradle and build it in place, from the build. So having Gradle on your machine is not a requirement, the gradle script will build with it in place like it was an external library. > > Plus, Android has just shifted to building user projects with Gradle instead of Ant. So there will be many Linux distros that will ship and approve Gradle just for that reason. > > > Oh my, I would have never thought I would try to sell Maven myself! Of > course, don't make this stop evolutionary attempts at solving the > build process, but I thought it's one consideration to take into > account when deciding what build system to use, since it's such a > fundamental part of the code. > > Ultimately, the build infrastructure should be what makes more sense > for the project obviously. > > > 1) I'll make sure cross builds all continue to work > > 2) Partial builds (for native code particularly) will continue to work such that you don't HAVE to build native code > > 3) It will produce bit-for-bit compatible output in the artifacts/ directory, so all our RE (Release Engineering) scripts continue to work with little or no modification > > > > Also, in my tests so far the speed of the build is dramatically faster -- but then I don't have everything in yet so that might just be wishful thinking. I hope and expect it to be faster though. > > > > We generate code in our build system for the following reasons: > > > > 1) We have a VersionInfo class which the build system will update with version information. It is a com.sun.something class > > 2) We have an annotation processor which generates all of the builders > > 3) We have two grammars that Antlr has process to produce parsers -- one for JSL (for our shaders) and one for CSS > > 4) We have a "decora compiler" which takes JSL files and feeds it through the JSL parser and produces code / shaders > > > > In addition to code generation, we also build a ton of native code (gstreamer, webkit, prism, fonts, glass, image loading). So that has to fit into the build system. Building native code is SLOW, so being able to avoid it for "normal" developers, and being able to avoid native builds when nothing changed in the native code, is important. > > Speaking about this, I wonder if we will end up doing like IcedTea > with OpenJDK, since most of those probably have an OS counterpart we > would rather want to use (in other words, make those elements somehow > pluggable). > > > I have found that some of our unit tests are written such that they require more of the platform, rather than just one class. So for example, there are tests in the scene graph which might want to use a UI control for some purpose. I'm thinking the easiest thing to do is to have a test directory at the top level which houses all the tests, and break them up based on whether they are part of the smoke test, integration test, or manual test suite. Smoke tests are those that are run continuously. They must be headless, and they must be completely automated, and they must execute within some reasonable amount of time (since hudson is going to be doing it continuously). The integration tests are the rest of the automated tests that need to be run between every integration with "master". Finally the manual tests are not run as part of the integration / smoke tests, but really are just little "toys" or apps we've written that are useful when developing a feature or whatnot. We've got a ton of these little guys (mostly of the "HelloWorld" variety), and these would go into "manual". > > This is one advantage of maven, in that you are somehow forced to have > this layout. Maven supports the idea of modules, they are a hierarchy > that pretty much resembles what the project structure you depict later > looks, and for each of those modules you would have unit tests. > Integration tests could simply go into an high level module, the same > for the manual tests. > > The problem with Maven is when you get off the beaten path (like running your own annotation processor, shipping source code in the jar, custom build languages) the build script gets very verbose and hard to read. All the XML creates more noise. Yes, you can do it, but it becomes difficult to maintain. Build scripts for Maven projects that follow the maven conventions are dead simple, but OpenJFX is not one of those run of the mill builds. > > > > > We also will have an apps directory, where we will place all the samples (like Ensemble) and experiments (like the JavaOne Schedule Builder). > > > > And I want to have a "benchmarks" directory where all of our benchmarks will live. The only problem with this one is that we have a dependency on JRockit benchmark harness, and I'm not sure how to resolve that with the open source bits. Maybe the JRockit benchmark harness is already open source, I haven't dug into it yet to find out. However I believe we *must* have benchmarks open, as well as the SQE tests. My goal is to run OpenJFX in the open and to have meaningful contributions -- how can that happen if we're keeping back essential verification tools? How can somebody submit a patch and not know whether it is going to impact performance? So I want to get the benchmarks all out, but we need to figure out what to do about this dependency. Another option is to replace this dependency with one of the other open source benchmark harnesses, but this would need to be carefully considered as it would disrupt our benchmark reporting for some period of time. But ultimately having public numbers and public tests would, I think, be very beneficial across the board. > > As a side note, we're developing a monitoring tool for OpenJDK > (Thermostat). I don't want to put Thermostat in competition with > JRockit (well, I did so already!), but by the time the full code is > out, we will be quite likely ready for prime time. There are also > other tools that do pretty good job, like VisualVM and JConsole. > Depending on the harness you have (which I assume means loads of > binary files with dumps and performance related data), we can either > try to make them compatible with all those tools, or better yet, > develop some kind exchange format for Performance Analysis (so that we > are not really depending on any tool). This can be a cool > collaboration between some other teams (I suspect such an effort would > go beyond JavaFX of course). In any case, having the harness in the > code doesn't hurt (as soon as we don't depend on them to build the > final code). > > Cheers, > Mario > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > IcedRobot: www.icedrobot.org > Proud GNU Classpath developer: http://www.classpath.org/ > Read About us at: http://planet.classpath.org > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ > > > > -- > There is nothing that will hold me back. I know who I am.... > I remember wher I came from, and I feel stronger for knowing. > Zane, Ninja of Ice. Ninjago S01E07 > From sven.reimers at gmail.com Fri Feb 1 09:23:03 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Fri, 1 Feb 2013 18:23:03 +0100 Subject: createSymbols Property not available on AreaChart Message-ID: Hi, just thought I check here first before opening a RFE on JIRA. LineChart has a createSymbols Property to switch on/off creation of symbols where data points are in the chart. The same property would be nice to have on AreaChart as well, since it is way more easy to get rid of the symbols with such a property in comparison to be forced doing this via CSS and in terms of API it would be more consistent with LineChart. So how about adding createSymbols property to AreaChart? Desired API change: -- snip -- /** * Indicates whether symbols for data points will be created or not. * * @return true if symbols for data points will be created and false otherwise. */ public final boolean getCreateSymbols() { return createSymbols.getValue(); } public final void setCreateSymbols(boolean value) { createSymbols.setValue(value); } public final BooleanProperty createSymbolsProperty() { return createSymbols; } --snip --- Comments? 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 From sven.reimers at gmail.com Fri Feb 1 09:25:30 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Fri, 1 Feb 2013 18:25:30 +0100 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <1B3DF0AE-C47D-4EE8-A8CF-58BE0539AC4E@oracle.com> References: <1B3DF0AE-C47D-4EE8-A8CF-58BE0539AC4E@oracle.com> Message-ID: Sound great! -Sven On Fri, Feb 1, 2013 at 6:07 PM, Richard Bair wrote: > I just pushed to the rt repo my two "work in progress" gradle scripts, > build.gradle and settings.gradle. You will find that these don't work. The > reason is that I have another (still closed) "generator" gradle script > which takes the existing sources and munges them around into a directory > structure that the new gradle scripts work against. > > I'm working with the full set of sources and trying to get the new build > to work with the full set of sources. I'm targeting the end of the month > (Feb) for having the build system sorted out. > > For example my "generator" script looks like: > > task generate << { > // Copy over the new gradle build file > copy { > from "." > into "javafx" > include "build.gradle", "settings.gradle" > } > > // Create the build-tools project > copy { > from "rt/javafx-annotation-processor/src", > "rt/decora-compiler/src" > into "javafx/build-tools/src/main/java" > exclude "META-INF/**", "**/*.properties", "**/*.stg", "**/JSL.g" > } > copy { > from "rt/javafx-annotation-processor/src", > "rt/decora-compiler/src" > into "javafx/build-tools/src/main/resources" > include "META-INF/**", "**/*.properties", "**/*.stg" > } > copy { > from > "rt/decora-compiler/src/com/sun/scenario/effect/compiler/JSL.g" > into "javafx/build-tools/src/main/antlr" > } > copy { > from "rt-closed/javafx-beans/src" > into "javafx/build-tools/src/main/java" > include "com/sun/javafx/beans/annotations/**", > "com/sun/javafx/collections/annotations/**" > } > > ?. and lots more > } > > You can see some paths are "rt/" and some are "rt-closed/". What I can do > is create a generator.gradle file in rt that contains only the portion that > is already open so that people in the community can try out the new > structure / contribute / etc? The main gradle build file then needs to just > include jfxrt.jar on the build path as the binary plug. > > Thoughts? > Richard > > On Oct 19, 2012, at 7:24 AM, Danno Ferrin > wrote: > > > > > > > On Fri, Oct 19, 2012 at 7:31 AM, Mario Torre < > neugens.limasoftware at gmail.com> wrote: > > > Further more, you should be able to do "find usages" in your IDE and > get EVERYTHING IN THE UNIVERSE, rather than right now where in NB it > doesn't have enough information about the 160 other projects in our system > to be able to do this. This is bad. > > > > > > Right now we build with ant. Many of you have suggested Maven. Some of > you at JavaOne suggested Gradle. I am presently looking into Gradle. The > key things I like about Gradle are: > > > > > > 1) It isn't XML > > > 2) Like Ivy & Maven, it handles dependencies well > > > > > > We presently have a pile of XML files and nasty build logic for > downloading dependencies (this is all in the closed repo, but you would be > exposed to the horror if we just made it all public). I wanted instead to > use Ivy at the very least, but rather if I can get better build happiness > from another setup entirely (like Gradle) then I might as well give it a > try. > > > > I kind of like Gradle, but let me put the cart before the horse here > > (I don't know if this sounds as well in English as it is in Italian, > > where we actually use the oxen, but well :) > > > > While Maven is a well understood tool, Gradle is fairly new. This > > turns to be especially problematic when building and shipping on Linux > > distributions because there are some constraints and limitation on > > what can go or not in a given release (btw, I think this could be > > considered a problem on Windows and OSX installations in some > > environments where you can't simply install any tool you want). > > > > Maven, on the other end, is pretty likely sitting on your machine > > already (as are Make, GCC and Configure most of the time on developers > > machines), so I suspect it will be easier for the average folk as well > > as heavily filled packager to take care of the build bits. > > > > Gradle has a "wrapper" script that can be checked in with the build (the > gradlew script), it will download the specific version of gradle and build > it in place, from the build. So having Gradle on your machine is not a > requirement, the gradle script will build with it in place like it was an > external library. > > > > Plus, Android has just shifted to building user projects with Gradle > instead of Ant. So there will be many Linux distros that will ship and > approve Gradle just for that reason. > > > > > > Oh my, I would have never thought I would try to sell Maven myself! Of > > course, don't make this stop evolutionary attempts at solving the > > build process, but I thought it's one consideration to take into > > account when deciding what build system to use, since it's such a > > fundamental part of the code. > > > > Ultimately, the build infrastructure should be what makes more sense > > for the project obviously. > > > > > 1) I'll make sure cross builds all continue to work > > > 2) Partial builds (for native code particularly) will continue > to work such that you don't HAVE to build native code > > > 3) It will produce bit-for-bit compatible output in the > artifacts/ directory, so all our RE (Release Engineering) scripts continue > to work with little or no modification > > > > > > Also, in my tests so far the speed of the build is dramatically faster > -- but then I don't have everything in yet so that might just be wishful > thinking. I hope and expect it to be faster though. > > > > > > We generate code in our build system for the following reasons: > > > > > > 1) We have a VersionInfo class which the build system will > update with version information. It is a com.sun.something class > > > 2) We have an annotation processor which generates all of the > builders > > > 3) We have two grammars that Antlr has process to produce > parsers -- one for JSL (for our shaders) and one for CSS > > > 4) We have a "decora compiler" which takes JSL files and feeds > it through the JSL parser and produces code / shaders > > > > > > In addition to code generation, we also build a ton of native code > (gstreamer, webkit, prism, fonts, glass, image loading). So that has to fit > into the build system. Building native code is SLOW, so being able to avoid > it for "normal" developers, and being able to avoid native builds when > nothing changed in the native code, is important. > > > > Speaking about this, I wonder if we will end up doing like IcedTea > > with OpenJDK, since most of those probably have an OS counterpart we > > would rather want to use (in other words, make those elements somehow > > pluggable). > > > > > I have found that some of our unit tests are written such that they > require more of the platform, rather than just one class. So for example, > there are tests in the scene graph which might want to use a UI control for > some purpose. I'm thinking the easiest thing to do is to have a test > directory at the top level which houses all the tests, and break them up > based on whether they are part of the smoke test, integration test, or > manual test suite. Smoke tests are those that are run continuously. They > must be headless, and they must be completely automated, and they must > execute within some reasonable amount of time (since hudson is going to be > doing it continuously). The integration tests are the rest of the automated > tests that need to be run between every integration with "master". Finally > the manual tests are not run as part of the integration / smoke tests, but > really are just little "toys" or apps we've written that are useful when > developing a feature or whatnot. We've got a ton of these little guys > (mostly of the "HelloWorld" variety), and these would go into "manual". > > > > This is one advantage of maven, in that you are somehow forced to have > > this layout. Maven supports the idea of modules, they are a hierarchy > > that pretty much resembles what the project structure you depict later > > looks, and for each of those modules you would have unit tests. > > Integration tests could simply go into an high level module, the same > > for the manual tests. > > > > The problem with Maven is when you get off the beaten path (like running > your own annotation processor, shipping source code in the jar, custom > build languages) the build script gets very verbose and hard to read. All > the XML creates more noise. Yes, you can do it, but it becomes difficult > to maintain. Build scripts for Maven projects that follow the maven > conventions are dead simple, but OpenJFX is not one of those run of the > mill builds. > > > > > > > > > We also will have an apps directory, where we will place all the > samples (like Ensemble) and experiments (like the JavaOne Schedule Builder). > > > > > > And I want to have a "benchmarks" directory where all of our > benchmarks will live. The only problem with this one is that we have a > dependency on JRockit benchmark harness, and I'm not sure how to resolve > that with the open source bits. Maybe the JRockit benchmark harness is > already open source, I haven't dug into it yet to find out. However I > believe we *must* have benchmarks open, as well as the SQE tests. My goal > is to run OpenJFX in the open and to have meaningful contributions -- how > can that happen if we're keeping back essential verification tools? How can > somebody submit a patch and not know whether it is going to impact > performance? So I want to get the benchmarks all out, but we need to figure > out what to do about this dependency. Another option is to replace this > dependency with one of the other open source benchmark harnesses, but this > would need to be carefully considered as it would disrupt our benchmark > reporting for some period of time. But ultimately having public numbers and > public tests would, I think, be very beneficial across the board. > > > > As a side note, we're developing a monitoring tool for OpenJDK > > (Thermostat). I don't want to put Thermostat in competition with > > JRockit (well, I did so already!), but by the time the full code is > > out, we will be quite likely ready for prime time. There are also > > other tools that do pretty good job, like VisualVM and JConsole. > > Depending on the harness you have (which I assume means loads of > > binary files with dumps and performance related data), we can either > > try to make them compatible with all those tools, or better yet, > > develop some kind exchange format for Performance Analysis (so that we > > are not really depending on any tool). This can be a cool > > collaboration between some other teams (I suspect such an effort would > > go beyond JavaFX of course). In any case, having the harness in the > > code doesn't hurt (as soon as we don't depend on them to build the > > final code). > > > > Cheers, > > Mario > > > > -- > > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > > > IcedRobot: www.icedrobot.org > > Proud GNU Classpath developer: http://www.classpath.org/ > > Read About us at: http://planet.classpath.org > > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > > > Please, support open standards: > > http://endsoftpatents.org/ > > > > > > > > -- > > There is nothing that will hold me back. I know who I am.... > > I remember wher I came from, and I feel stronger for knowing. > > Zane, Ninja of Ice. Ninjago S01E07 > > > > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * 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 From hang.vo at oracle.com Fri Feb 1 09:33:30 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 01 Feb 2013 17:33:30 +0000 Subject: hg: openjfx/8/graphics/rt: Partial RT-28089 Message-ID: <20130201173331.DA23647762@hg.openjdk.java.net> Changeset: 871e03bb7fb9 Author: Richard Bair Date: 2013-02-01 09:19 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/871e03bb7fb9 Partial RT-28089 Summary: Added open portion of generator script. Will generate a new "javafx" directory that is a sibling of "rt" + generator.gradle From richard.bair at oracle.com Fri Feb 1 10:29:34 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 1 Feb 2013 10:29:34 -0800 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: References: <1B3DF0AE-C47D-4EE8-A8CF-58BE0539AC4E@oracle.com> Message-ID: OK, I've split the generation script into two pieces -- one is closed and one is open. The open one contains all the logic for creating a "javafx" directory sibling of rt and copying sources etc into it, in the new directory layout. It doesn't build yet unless jfxrt.jar is on the class path. If you manage to get the right version of the file it should build -- modulo the printing build break that is awaiting the next weekly build. Richard From jasper.potts at oracle.com Fri Feb 1 10:33:29 2013 From: jasper.potts at oracle.com (Jasper Potts) Date: Fri, 1 Feb 2013 10:33:29 -0800 Subject: createSymbols Property not available on AreaChart In-Reply-To: References: Message-ID: <21C4C53A-E6EC-4B0C-9944-F0094E63CCC3@oracle.com> Hi, Seems like a good idea. If you file a JIRA Tweak that would be great, a patch would also be most welcome :-) Thanks Jasper On Feb 1, 2013, at 9:23 AM, Sven Reimers wrote: > Hi, > > just thought I check here first before opening a RFE on JIRA. > > LineChart has a createSymbols Property to switch on/off creation of symbols > where data points are in the chart. The same property would be nice to have > on AreaChart as well, since it is way more easy to get rid of the symbols > with such a property in comparison to be forced doing this via CSS and in > terms of API it would be more consistent with LineChart. > > So how about adding createSymbols property to AreaChart? > > > Desired API change: > -- snip -- > > /** > * Indicates whether symbols for data points will be created or not. > * > * @return true if symbols for data points will be created and false > otherwise. > */ > public final boolean getCreateSymbols() { return > createSymbols.getValue(); } > public final void setCreateSymbols(boolean value) { > createSymbols.setValue(value); } > public final BooleanProperty createSymbolsProperty() { return > createSymbols; } > > --snip --- > > Comments? > > 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 From hang.vo at oracle.com Fri Feb 1 10:33:57 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 01 Feb 2013 18:33:57 +0000 Subject: hg: openjfx/8/graphics/rt: Partial RT-28089 Message-ID: <20130201183358.EF8B94776C@hg.openjdk.java.net> Changeset: 4499eedd0789 Author: Richard Bair Date: 2013-02-01 10:26 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4499eedd0789 Partial RT-28089 Summary: Fixed so that it generates correctly whether run from rt or run from the closed build file that includes all the closed sources. ! generator.gradle From chien.yang at oracle.com Fri Feb 1 10:57:13 2013 From: chien.yang at oracle.com (Chien Yang) Date: Fri, 01 Feb 2013 10:57:13 -0800 Subject: [API Review] RT-28129: event coordinates with perspective camera In-Reply-To: <510BF2A8.9080307@oracle.com> References: <510BF2A8.9080307@oracle.com> Message-ID: <510C1009.4080005@oracle.com> Looks good to me. This proposed change will also provide a consistent picking framework for 2D and 3D primitives. Thanks, - Chien On 2/1/2013 8:51 AM, Pavel Safrata wrote: > Hello, > this is related to the 3D support planned for FX8, yet it is a bugfix > of an existing issue. > > With perspective camera, events delivered to any node that's not lying > flat on the XY plane contain wrong local coordinates - they ignore the > projection transformations. It's enough to rotate a rectangle along X > axis and the coordinates become useless. > > http://javafx-jira.kenai.com/browse/RT-28129 > > Solution to this problem requires API changes, because we need to > compute in 3D to get proper numbers. So I propose to add a "double > getZ()" method to all picking-based events, with the following > semantics: the event's getSceneX(), getSceneY() values still represent > the 2D coordinates of the mouse in the window content pixels (screen > coordinates minus window position and decorations); the getX(), > getY(), getZ() represent the hit point in the local 3D space (which > may now be different even for scene because of the perspective > transform). If no node is picked, the hit point with the scene will be > found on the projection plane. Note that nothing changes for the 2D > case, for the 3D case we now have correct 3D coordinates instead of a > complete nonsense. > > There is one more issue - how to pass the correct coordinates to the > event constructors. Instead of creating more construrctors with the > three additional coordinates, I propose to use a concept called > PickResult which was briefly discussed earlier and will soon be part > of a 3D API review. In short, it is an object that contains > information about the pick for the event - the picked node, local > coordinates of the hit and some 3D-specific stuff. For proper 3D > support, it will anyway be necessary to pass the PickResult to the > events and allow access to it; once this is done, the event can > compute the coordinates from it. So I propose adding PickResult to the > event constructors. Note that they've not been released yet, so we can > modify them instead of adding new ones. Also note that for convenience > of 2D use-cases, the constructors will accept a null PickResult and in > this case compute PickResult values based on the passed event target > and scene coordinates (which is sufficient for 2D case). > > Side note for those who remember the previous 3D API discussion: the > PickResult is no longer restricted to 3d shapes, it is present always, > with the 3D-specific fields having null values where not applicable. > > > Summary of this proposal: > Affected classes: MouseEvent, MouseDragEvent, DragEvent, GestureEvent, > ContextMenuEvent and TouchPoint > new methods: getZ(), getPickResult() (and extended semantics of event > local coordinates for 3D case) > modified methods: added PickResult to all constructors > > Concrete description of the PickResult and the proposed picking API > can be found here: > https://wikis.oracle.com/display/OpenJDK/Picking3dAPI > > Thanks, > Pavel > From richard.bair at oracle.com Fri Feb 1 11:01:08 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 1 Feb 2013 11:01:08 -0800 Subject: [API Review] RT-28129: event coordinates with perspective camera In-Reply-To: <510C1009.4080005@oracle.com> References: <510BF2A8.9080307@oracle.com> <510C1009.4080005@oracle.com> Message-ID: <1D6C761B-5E46-4D38-BA9C-A2DC78247ACC@oracle.com> Only thing that got my attention was: getIntersectedTexCoord Is the rest of the 3D API using shortened names like "tex" and "coord" as well? Richard On Feb 1, 2013, at 10:57 AM, Chien Yang wrote: > Looks good to me. This proposed change will also provide a consistent picking framework for 2D and 3D primitives. > > Thanks, > - Chien > > On 2/1/2013 8:51 AM, Pavel Safrata wrote: >> Hello, >> this is related to the 3D support planned for FX8, yet it is a bugfix of an existing issue. >> >> With perspective camera, events delivered to any node that's not lying flat on the XY plane contain wrong local coordinates - they ignore the projection transformations. It's enough to rotate a rectangle along X axis and the coordinates become useless. >> >> http://javafx-jira.kenai.com/browse/RT-28129 >> >> Solution to this problem requires API changes, because we need to compute in 3D to get proper numbers. So I propose to add a "double getZ()" method to all picking-based events, with the following semantics: the event's getSceneX(), getSceneY() values still represent the 2D coordinates of the mouse in the window content pixels (screen coordinates minus window position and decorations); the getX(), getY(), getZ() represent the hit point in the local 3D space (which may now be different even for scene because of the perspective transform). If no node is picked, the hit point with the scene will be found on the projection plane. Note that nothing changes for the 2D case, for the 3D case we now have correct 3D coordinates instead of a complete nonsense. >> >> There is one more issue - how to pass the correct coordinates to the event constructors. Instead of creating more construrctors with the three additional coordinates, I propose to use a concept called PickResult which was briefly discussed earlier and will soon be part of a 3D API review. In short, it is an object that contains information about the pick for the event - the picked node, local coordinates of the hit and some 3D-specific stuff. For proper 3D support, it will anyway be necessary to pass the PickResult to the events and allow access to it; once this is done, the event can compute the coordinates from it. So I propose adding PickResult to the event constructors. Note that they've not been released yet, so we can modify them instead of adding new ones. Also note that for convenience of 2D use-cases, the constructors will accept a null PickResult and in this case compute PickResult values based on the passed event target and scene coordinates (which is sufficient for 2D case). >> >> Side note for those who remember the previous 3D API discussion: the PickResult is no longer restricted to 3d shapes, it is present always, with the 3D-specific fields having null values where not applicable. >> >> >> Summary of this proposal: >> Affected classes: MouseEvent, MouseDragEvent, DragEvent, GestureEvent, ContextMenuEvent and TouchPoint >> new methods: getZ(), getPickResult() (and extended semantics of event local coordinates for 3D case) >> modified methods: added PickResult to all constructors >> >> Concrete description of the PickResult and the proposed picking API can be found here: >> https://wikis.oracle.com/display/OpenJDK/Picking3dAPI >> >> Thanks, >> Pavel >> > From sven.reimers at gmail.com Fri Feb 1 11:06:56 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Fri, 1 Feb 2013 20:06:56 +0100 Subject: createSymbols Property not available on AreaChart In-Reply-To: <21C4C53A-E6EC-4B0C-9944-F0094E63CCC3@oracle.com> References: <21C4C53A-E6EC-4B0C-9944-F0094E63CCC3@oracle.com> Message-ID: Ok. Will file issue and try to provide patch. -Sven Am 01.02.2013 19:33 schrieb "Jasper Potts" : > Hi, > > Seems like a good idea. If you file a JIRA Tweak that would be great, a > patch would also be most welcome :-) > > Thanks > > Jasper > > On Feb 1, 2013, at 9:23 AM, Sven Reimers wrote: > > > Hi, > > > > just thought I check here first before opening a RFE on JIRA. > > > > LineChart has a createSymbols Property to switch on/off creation of > symbols > > where data points are in the chart. The same property would be nice to > have > > on AreaChart as well, since it is way more easy to get rid of the symbols > > with such a property in comparison to be forced doing this via CSS and in > > terms of API it would be more consistent with LineChart. > > > > So how about adding createSymbols property to AreaChart? > > > > > > Desired API change: > > -- snip -- > > > > /** > > * Indicates whether symbols for data points will be created or not. > > * > > * @return true if symbols for data points will be created and false > > otherwise. > > */ > > public final boolean getCreateSymbols() { return > > createSymbols.getValue(); } > > public final void setCreateSymbols(boolean value) { > > createSymbols.setValue(value); } > > public final BooleanProperty createSymbolsProperty() { return > > createSymbols; } > > > > --snip --- > > > > Comments? > > > > 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 > > From chien.yang at oracle.com Fri Feb 1 11:12:14 2013 From: chien.yang at oracle.com (Chien Yang) Date: Fri, 01 Feb 2013 11:12:14 -0800 Subject: [API Review] RT-28129: event coordinates with perspective camera In-Reply-To: <1D6C761B-5E46-4D38-BA9C-A2DC78247ACC@oracle.com> References: <510BF2A8.9080307@oracle.com> <510C1009.4080005@oracle.com> <1D6C761B-5E46-4D38-BA9C-A2DC78247ACC@oracle.com> Message-ID: <510C138E.4080906@oracle.com> Yes we do, texCoord (texture coordinate) is a commonly used term in the computer graphics world, for example, OpenGL has methods such as glTexCoord4f(x, y, z, w ), and glTexCoordPointer(4,GL_FLOAT,0,0). - Chien On 2/1/2013 11:01 AM, Richard Bair wrote: > Only thing that got my attention was: getIntersectedTexCoord > > Is the rest of the 3D API using shortened names like "tex" and "coord" > as well? > > Richard > > On Feb 1, 2013, at 10:57 AM, Chien Yang > wrote: > >> Looks good to me. This proposed change will also provide a consistent >> picking framework for 2D and 3D primitives. >> >> Thanks, >> - Chien >> >> On 2/1/2013 8:51 AM, Pavel Safrata wrote: >>> Hello, >>> this is related to the 3D support planned for FX8, yet it is a >>> bugfix of an existing issue. >>> >>> With perspective camera, events delivered to any node that's not >>> lying flat on the XY plane contain wrong local coordinates - they >>> ignore the projection transformations. It's enough to rotate a >>> rectangle along X axis and the coordinates become useless. >>> >>> http://javafx-jira.kenai.com/browse/RT-28129 >>> >>> Solution to this problem requires API changes, because we need to >>> compute in 3D to get proper numbers. So I propose to add a "double >>> getZ()" method to all picking-based events, with the following >>> semantics: the event's getSceneX(), getSceneY() values still >>> represent the 2D coordinates of the mouse in the window content >>> pixels (screen coordinates minus window position and decorations); >>> the getX(), getY(), getZ() represent the hit point in the local 3D >>> space (which may now be different even for scene because of the >>> perspective transform). If no node is picked, the hit point with the >>> scene will be found on the projection plane. Note that nothing >>> changes for the 2D case, for the 3D case we now have correct 3D >>> coordinates instead of a complete nonsense. >>> >>> There is one more issue - how to pass the correct coordinates to the >>> event constructors. Instead of creating more construrctors with the >>> three additional coordinates, I propose to use a concept called >>> PickResult which was briefly discussed earlier and will soon be part >>> of a 3D API review. In short, it is an object that contains >>> information about the pick for the event - the picked node, local >>> coordinates of the hit and some 3D-specific stuff. For proper 3D >>> support, it will anyway be necessary to pass the PickResult to the >>> events and allow access to it; once this is done, the event can >>> compute the coordinates from it. So I propose adding PickResult to >>> the event constructors. Note that they've not been released yet, so >>> we can modify them instead of adding new ones. Also note that for >>> convenience of 2D use-cases, the constructors will accept a null >>> PickResult and in this case compute PickResult values based on the >>> passed event target and scene coordinates (which is sufficient for >>> 2D case). >>> >>> Side note for those who remember the previous 3D API discussion: the >>> PickResult is no longer restricted to 3d shapes, it is present >>> always, with the 3D-specific fields having null values where not >>> applicable. >>> >>> >>> Summary of this proposal: >>> Affected classes: MouseEvent, MouseDragEvent, DragEvent, >>> GestureEvent, ContextMenuEvent and TouchPoint >>> new methods: getZ(), getPickResult() (and extended semantics of >>> event local coordinates for 3D case) >>> modified methods: added PickResult to all constructors >>> >>> Concrete description of the PickResult and the proposed picking API >>> can be found here: >>> https://wikis.oracle.com/display/OpenJDK/Picking3dAPI >>> >>> Thanks, >>> Pavel >>> >> > From richard.bair at oracle.com Fri Feb 1 11:16:46 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 1 Feb 2013 11:16:46 -0800 Subject: [API Review] RT-28129: event coordinates with perspective camera In-Reply-To: <510C138E.4080906@oracle.com> References: <510BF2A8.9080307@oracle.com> <510C1009.4080005@oracle.com> <1D6C761B-5E46-4D38-BA9C-A2DC78247ACC@oracle.com> <510C138E.4080906@oracle.com> Message-ID: Do we want to continue that tradition? There is a long history of crappy names in C APIs, not all of which we brought with us to Java :-) Richard On Feb 1, 2013, at 11:12 AM, Chien Yang wrote: > Yes we do, texCoord (texture coordinate) is a commonly used term in the computer graphics world, for example, OpenGL has methods such as glTexCoord4f(x, y, z, w ), and glTexCoordPointer(4,GL_FLOAT,0,0). > > - Chien > > On 2/1/2013 11:01 AM, Richard Bair wrote: >> Only thing that got my attention was: getIntersectedTexCoord >> >> Is the rest of the 3D API using shortened names like "tex" and "coord" as well? >> >> Richard >> >> On Feb 1, 2013, at 10:57 AM, Chien Yang wrote: >> >>> Looks good to me. This proposed change will also provide a consistent picking framework for 2D and 3D primitives. >>> >>> Thanks, >>> - Chien >>> >>> On 2/1/2013 8:51 AM, Pavel Safrata wrote: >>>> Hello, >>>> this is related to the 3D support planned for FX8, yet it is a bugfix of an existing issue. >>>> >>>> With perspective camera, events delivered to any node that's not lying flat on the XY plane contain wrong local coordinates - they ignore the projection transformations. It's enough to rotate a rectangle along X axis and the coordinates become useless. >>>> >>>> http://javafx-jira.kenai.com/browse/RT-28129 >>>> >>>> Solution to this problem requires API changes, because we need to compute in 3D to get proper numbers. So I propose to add a "double getZ()" method to all picking-based events, with the following semantics: the event's getSceneX(), getSceneY() values still represent the 2D coordinates of the mouse in the window content pixels (screen coordinates minus window position and decorations); the getX(), getY(), getZ() represent the hit point in the local 3D space (which may now be different even for scene because of the perspective transform). If no node is picked, the hit point with the scene will be found on the projection plane. Note that nothing changes for the 2D case, for the 3D case we now have correct 3D coordinates instead of a complete nonsense. >>>> >>>> There is one more issue - how to pass the correct coordinates to the event constructors. Instead of creating more construrctors with the three additional coordinates, I propose to use a concept called PickResult which was briefly discussed earlier and will soon be part of a 3D API review. In short, it is an object that contains information about the pick for the event - the picked node, local coordinates of the hit and some 3D-specific stuff. For proper 3D support, it will anyway be necessary to pass the PickResult to the events and allow access to it; once this is done, the event can compute the coordinates from it. So I propose adding PickResult to the event constructors. Note that they've not been released yet, so we can modify them instead of adding new ones. Also note that for convenience of 2D use-cases, the constructors will accept a null PickResult and in this case compute PickResult values based on the passed event target and scene coordinates (which is sufficient for 2D case). >>>> >>>> Side note for those who remember the previous 3D API discussion: the PickResult is no longer restricted to 3d shapes, it is present always, with the 3D-specific fields having null values where not applicable. >>>> >>>> >>>> Summary of this proposal: >>>> Affected classes: MouseEvent, MouseDragEvent, DragEvent, GestureEvent, ContextMenuEvent and TouchPoint >>>> new methods: getZ(), getPickResult() (and extended semantics of event local coordinates for 3D case) >>>> modified methods: added PickResult to all constructors >>>> >>>> Concrete description of the PickResult and the proposed picking API can be found here: >>>> https://wikis.oracle.com/display/OpenJDK/Picking3dAPI >>>> >>>> Thanks, >>>> Pavel >>>> >>> >> > From kevin.rushforth at oracle.com Fri Feb 1 11:26:50 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 01 Feb 2013 11:26:50 -0800 Subject: [API Review] RT-28129: event coordinates with perspective camera In-Reply-To: References: <510BF2A8.9080307@oracle.com> <510C1009.4080005@oracle.com> <1D6C761B-5E46-4D38-BA9C-A2DC78247ACC@oracle.com> <510C138E.4080906@oracle.com> Message-ID: <510C16FA.6070007@oracle.com> Chien: what do we use in the Mesh APIs? -- Kevin Richard Bair wrote: > Do we want to continue that tradition? There is a long history of crappy names in C APIs, not all of which we brought with us to Java :-) > > Richard > > On Feb 1, 2013, at 11:12 AM, Chien Yang wrote: > > >> Yes we do, texCoord (texture coordinate) is a commonly used term in the computer graphics world, for example, OpenGL has methods such as glTexCoord4f(x, y, z, w ), and glTexCoordPointer(4,GL_FLOAT,0,0). >> >> - Chien >> >> On 2/1/2013 11:01 AM, Richard Bair wrote: >> >>> Only thing that got my attention was: getIntersectedTexCoord >>> >>> Is the rest of the 3D API using shortened names like "tex" and "coord" as well? >>> >>> Richard >>> >>> On Feb 1, 2013, at 10:57 AM, Chien Yang wrote: >>> >>> >>>> Looks good to me. This proposed change will also provide a consistent picking framework for 2D and 3D primitives. >>>> >>>> Thanks, >>>> - Chien >>>> >>>> On 2/1/2013 8:51 AM, Pavel Safrata wrote: >>>> >>>>> Hello, >>>>> this is related to the 3D support planned for FX8, yet it is a bugfix of an existing issue. >>>>> >>>>> With perspective camera, events delivered to any node that's not lying flat on the XY plane contain wrong local coordinates - they ignore the projection transformations. It's enough to rotate a rectangle along X axis and the coordinates become useless. >>>>> >>>>> http://javafx-jira.kenai.com/browse/RT-28129 >>>>> >>>>> Solution to this problem requires API changes, because we need to compute in 3D to get proper numbers. So I propose to add a "double getZ()" method to all picking-based events, with the following semantics: the event's getSceneX(), getSceneY() values still represent the 2D coordinates of the mouse in the window content pixels (screen coordinates minus window position and decorations); the getX(), getY(), getZ() represent the hit point in the local 3D space (which may now be different even for scene because of the perspective transform). If no node is picked, the hit point with the scene will be found on the projection plane. Note that nothing changes for the 2D case, for the 3D case we now have correct 3D coordinates instead of a complete nonsense. >>>>> >>>>> There is one more issue - how to pass the correct coordinates to the event constructors. Instead of creating more construrctors with the three additional coordinates, I propose to use a concept called PickResult which was briefly discussed earlier and will soon be part of a 3D API review. In short, it is an object that contains information about the pick for the event - the picked node, local coordinates of the hit and some 3D-specific stuff. For proper 3D support, it will anyway be necessary to pass the PickResult to the events and allow access to it; once this is done, the event can compute the coordinates from it. So I propose adding PickResult to the event constructors. Note that they've not been released yet, so we can modify them instead of adding new ones. Also note that for convenience of 2D use-cases, the constructors will accept a null PickResult and in this case compute PickResult values based on the passed event target and scene coordinates (which is sufficient for 2D case). >>>>> >>>>> Side note for those who remember the previous 3D API discussion: the PickResult is no longer restricted to 3d shapes, it is present always, with the 3D-specific fields having null values where not applicable. >>>>> >>>>> >>>>> Summary of this proposal: >>>>> Affected classes: MouseEvent, MouseDragEvent, DragEvent, GestureEvent, ContextMenuEvent and TouchPoint >>>>> new methods: getZ(), getPickResult() (and extended semantics of event local coordinates for 3D case) >>>>> modified methods: added PickResult to all constructors >>>>> >>>>> Concrete description of the PickResult and the proposed picking API can be found here: >>>>> https://wikis.oracle.com/display/OpenJDK/Picking3dAPI >>>>> >>>>> Thanks, >>>>> Pavel >>>>> >>>>> > > From chien.yang at oracle.com Fri Feb 1 11:33:06 2013 From: chien.yang at oracle.com (Chien Yang) Date: Fri, 01 Feb 2013 11:33:06 -0800 Subject: [API Review] RT-28129: event coordinates with perspective camera In-Reply-To: References: <510BF2A8.9080307@oracle.com> <510C1009.4080005@oracle.com> <1D6C761B-5E46-4D38-BA9C-A2DC78247ACC@oracle.com> <510C138E.4080906@oracle.com> Message-ID: <510C1872.5080502@oracle.com> Good point. This is worth a consideration. I'm fineto change if it doesn't go well with the JavaFX API as a whole. However I've a preference towards texCoord as it is used in all major graphics APIs that I'm aware of including D3D. Nothing to do with its length, really. ;-) - Chien On 2/1/2013 11:16 AM, Richard Bair wrote: > Do we want to continue that tradition? There is a long history of > crappy names in C APIs, not all of which we brought with us to Java :-) > > Richard > > On Feb 1, 2013, at 11:12 AM, Chien Yang > wrote: > >> Yes we do, texCoord (texture coordinate) is a commonly used term in >> the computer graphics world, for example, OpenGL has methods such as >> glTexCoord4f(x, y, z, w ), and glTexCoordPointer(4,GL_FLOAT,0,0). >> >> - Chien >> >> On 2/1/2013 11:01 AM, Richard Bair wrote: >>> Only thing that got my attention was: getIntersectedTexCoord >>> >>> Is the rest of the 3D API using shortened names like "tex" and >>> "coord" as well? >>> >>> Richard >>> >>> On Feb 1, 2013, at 10:57 AM, Chien Yang >> > wrote: >>> >>>> Looks good to me. This proposed change will also provide a >>>> consistent picking framework for 2D and 3D primitives. >>>> >>>> Thanks, >>>> - Chien >>>> >>>> On 2/1/2013 8:51 AM, Pavel Safrata wrote: >>>>> Hello, >>>>> this is related to the 3D support planned for FX8, yet it is a >>>>> bugfix of an existing issue. >>>>> >>>>> With perspective camera, events delivered to any node that's not >>>>> lying flat on the XY plane contain wrong local coordinates - they >>>>> ignore the projection transformations. It's enough to rotate a >>>>> rectangle along X axis and the coordinates become useless. >>>>> >>>>> http://javafx-jira.kenai.com/browse/RT-28129 >>>>> >>>>> Solution to this problem requires API changes, because we need to >>>>> compute in 3D to get proper numbers. So I propose to add a "double >>>>> getZ()" method to all picking-based events, with the following >>>>> semantics: the event's getSceneX(), getSceneY() values still >>>>> represent the 2D coordinates of the mouse in the window content >>>>> pixels (screen coordinates minus window position and decorations); >>>>> the getX(), getY(), getZ() represent the hit point in the local 3D >>>>> space (which may now be different even for scene because of the >>>>> perspective transform). If no node is picked, the hit point with >>>>> the scene will be found on the projection plane. Note that nothing >>>>> changes for the 2D case, for the 3D case we now have correct 3D >>>>> coordinates instead of a complete nonsense. >>>>> >>>>> There is one more issue - how to pass the correct coordinates to >>>>> the event constructors. Instead of creating more construrctors >>>>> with the three additional coordinates, I propose to use a concept >>>>> called PickResult which was briefly discussed earlier and will >>>>> soon be part of a 3D API review. In short, it is an object that >>>>> contains information about the pick for the event - the picked >>>>> node, local coordinates of the hit and some 3D-specific stuff. For >>>>> proper 3D support, it will anyway be necessary to pass the >>>>> PickResult to the events and allow access to it; once this is >>>>> done, the event can compute the coordinates from it. So I propose >>>>> adding PickResult to the event constructors. Note that they've not >>>>> been released yet, so we can modify them instead of adding new >>>>> ones. Also note that for convenience of 2D use-cases, the >>>>> constructors will accept a null PickResult and in this case >>>>> compute PickResult values based on the passed event target and >>>>> scene coordinates (which is sufficient for 2D case). >>>>> >>>>> Side note for those who remember the previous 3D API discussion: >>>>> the PickResult is no longer restricted to 3d shapes, it is present >>>>> always, with the 3D-specific fields having null values where not >>>>> applicable. >>>>> >>>>> >>>>> Summary of this proposal: >>>>> Affected classes: MouseEvent, MouseDragEvent, DragEvent, >>>>> GestureEvent, ContextMenuEvent and TouchPoint >>>>> new methods: getZ(), getPickResult() (and extended semantics of >>>>> event local coordinates for 3D case) >>>>> modified methods: added PickResult to all constructors >>>>> >>>>> Concrete description of the PickResult and the proposed picking >>>>> API can be found here: >>>>> https://wikis.oracle.com/display/OpenJDK/Picking3dAPI >>>>> >>>>> Thanks, >>>>> Pavel >>>>> >>>> >>> >> > From hang.vo at oracle.com Fri Feb 1 11:33:54 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 01 Feb 2013 19:33:54 +0000 Subject: hg: openjfx/8/graphics/rt: 46 new changesets Message-ID: <20130201193512.0A61647772@hg.openjdk.java.net> Changeset: 03e2f608b30d Author: dcherepanov Date: 2013-01-29 22:27 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/03e2f608b30d RT-27957: packager generates invalid Info.plist on Mac Reviewed-by: cbensen, mhowe ! deploy/packager/src/com/sun/javafx/tools/resource/mac/Info.plist.template Changeset: f4cfa58747b6 Author: ngthomas Date: 2013-01-30 12:09 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f4cfa58747b6 Merge - javafx-ui-common/test/unit/com/sun/javafx/test/OrientationHelper.java Changeset: 768175f757de Author: Richard Bair Date: 2013-01-23 14:27 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/768175f757de RT-16288: Add a TextField.setFont method Summary: Moved the font property to TextInputControl, so that it now has a font, the same as Labeled controls. This is properly spec'd for cases where the TextInputControl is rich text, and is styleable from CSS. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextAreaSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextFieldSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/javafx/scene/control/SkinBase.java ! javafx-ui-controls/src/javafx/scene/control/TextField.java ! javafx-ui-controls/src/javafx/scene/control/TextInputControl.java Changeset: 19fcfc090bf7 Author: "Jasper Potts" Date: 2013-01-23 14:41 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/19fcfc090bf7 Modena test app, make it reload CSS when clicking on refresh button ! apps/experiments/Modena/src/modena/Modena.java Changeset: 572702f272c1 Author: "Jasper Potts" Date: 2013-01-23 14:43 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/572702f272c1 Fixed RT-14734: SplitMenuButton: right internal inset is too large. Also fixed for combo and choice box. Also hights were incostant and not scaling with em units. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: 682e0e60b780 Author: "Jasper Potts" Date: 2013-01-23 15:26 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/682e0e60b780 Fixed RT-27877: Caspian style tabs look really bad ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: a57a751e71ea Author: Richard Bair Date: 2013-01-23 15:29 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a57a751e71ea RT-16689: TextInputControl: css "-fx-columns" doesn't work Summary: Added -fx-pref-column-count to TextField and TextArea, -fx-pref-row-count to TextArea, and -fx-wrap-text to TextArea. Added documentation in cssref. Added unit tests. ! javafx-ui-common/src/javafx/scene/doc-files/cssref.html ! javafx-ui-controls/src/javafx/scene/control/TextArea.java ! javafx-ui-controls/src/javafx/scene/control/TextField.java ! javafx-ui-controls/test/javafx/scene/control/TextAreaTest.java ! javafx-ui-controls/test/javafx/scene/control/TextFieldTest.java ! javafx-ui-controls/test/javafx/scene/control/TextInputControlTest.java Changeset: 5344223bc71f Author: Paru Somashekar Date: 2013-01-23 17:08 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5344223bc71f fix RT-27874 HelloMenu: radio/checkbox menu items do not display intial state. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java Changeset: 307525172dfc Author: "Jasper Potts" Date: 2013-01-23 15:35 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/307525172dfc Modena.css removed workaround for RT-27627 ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: cc5cb90e7ead Author: "Jasper Potts" Date: 2013-01-24 11:55 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/cc5cb90e7ead Modena, added combinations test and improved combinations CSS + apps/experiments/Modena/src/modena/CombinationTest.fxml ! apps/experiments/Modena/src/modena/Modena.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 4dacc125104a Author: "Jasper Potts" Date: 2013-01-24 11:55 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4dacc125104a Merge Changeset: 08c5e5a1685e Author: "Jasper Potts" Date: 2013-01-24 15:04 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/08c5e5a1685e Modena, added customer example tab ! apps/experiments/Modena/src/modena/Modena.java + apps/experiments/Modena/src/modena/ScottSelvia.fxml Changeset: 0ccbad343185 Author: jgiles Date: 2013-01-24 11:02 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0ccbad343185 TreeView branches should expand / collapse on shift + double click (from RT-27173). ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java Changeset: 2bf8fb004f5f Author: jgiles Date: 2013-01-25 13:45 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2bf8fb004f5f Brought a number of keyboard-related unit tests back to life (although they may crash hudson as they used to). I have also copied the all TreeView and TableView keyboard tests into a new test class for TreeTableView. In the process of doing this I have created new unit tests and fixed the following bugs: RT-14451: TableView: Shift-Home and Shift-End do not work as expected RT-26835: [TreeView] Cmd + Home doesn't move focus to the first item. RT-27175: [TreeTableView] ctrl+shift+home don't update focus ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ListViewSkin.java + javafx-ui-controls/test/com/sun/javafx/scene/control/behavior/TreeTableViewAnchorRetriever.java ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java + javafx-ui-controls/test/javafx/scene/control/TreeTableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewKeyInputTest.java Changeset: 01946a0fd0c1 Author: jgiles Date: 2013-01-25 13:47 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/01946a0fd0c1 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 800d70f1b63a Author: jgiles Date: 2013-01-25 14:37 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/800d70f1b63a RT-13294: TitledPane : add animation to the title arrow ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TitledPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css Changeset: 7ae28be2f5e9 Author: "Jasper Potts" Date: 2013-01-24 19:38 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7ae28be2f5e9 Modena, tweeked accent and default colors to better fit with windows. Added new simple window test to test app. ! apps/experiments/Modena/src/modena/CombinationTest.fxml + apps/experiments/Modena/src/modena/CombinationTest.fxml.bak ! apps/experiments/Modena/src/modena/Modena.java ! apps/experiments/Modena/src/modena/SamplePage.java + apps/experiments/Modena/src/modena/SimpleWindowPage.java ! apps/experiments/Modena/src/modena/TestApp.css + apps/experiments/Modena/src/modena/mac-window-frame.png + apps/experiments/Modena/src/modena/simple-window.fxml + apps/experiments/Modena/src/modena/simple-window.fxml.bak + apps/experiments/Modena/src/modena/windows8-window-frame.png ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 877d9ed09020 Author: jgiles Date: 2013-01-25 17:46 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/877d9ed09020 RT-27925: Animate the movement of the Slider thumb when the user clicks on the Slider track ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SliderSkin.java Changeset: cb54a85f5493 Author: jgiles Date: 2013-01-25 17:52 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/cb54a85f5493 RT-27925: Animate the movement of the Slider thumb when the user clicks on the Slider track (only animate when the track is clicked - not when the Slider is resized or when the thumb is dragged). ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/SliderSkin.java Changeset: 504ddc731dbe Author: jgiles Date: 2013-01-25 18:00 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/504ddc731dbe Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: b67e4058ac0b Author: mo.chicharro Date: 2013-01-25 20:20 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b67e4058ac0b Modean tweaks - Pagination styling ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 8d02cc0f0e9f Author: Paru Somashekar Date: 2013-01-25 16:21 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8d02cc0f0e9f fix RT-22726 chart legend resize & RT-19859 CustomMenuItem style issue ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java Changeset: c876ca2ee99b Author: Alexander Kouznetsov Date: 2013-01-26 16:36 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c876ca2ee99b Modena: Some more changes to support ModenaTest ! apps/experiments/Modena/src/modena/Modena.java Changeset: 83d00772245f Author: Alexander Kouznetsov Date: 2013-01-26 16:45 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/83d00772245f ModenaTest: Fix for RT-27868 Extend test to cover multiple font and color combinations ! apps/experiments/ModenaTest/test/modenatest/ModenaTest.java Changeset: 8e69b7d8d19c Author: David Grieve Date: 2013-01-28 12:20 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8e69b7d8d19c RT-27873: fix raw types in css code ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java ! javafx-ui-charts/src/javafx/scene/chart/Chart.java ! javafx-ui-charts/src/javafx/scene/chart/LineChart.java ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java ! javafx-ui-charts/src/javafx/scene/chart/StackedAreaChart.java ! javafx-ui-charts/src/javafx/scene/chart/StackedBarChart.java ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java ! javafx-ui-common/src/com/sun/javafx/css/StyleConverterImpl.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/com/sun/javafx/css/Styleable.java ! javafx-ui-common/src/com/sun/javafx/css/converters/BooleanConverter.java ! javafx-ui-common/src/com/sun/javafx/css/converters/ColorConverter.java ! javafx-ui-common/src/com/sun/javafx/css/converters/CursorConverter.java ! javafx-ui-common/src/com/sun/javafx/css/converters/EffectConverter.java ! javafx-ui-common/src/com/sun/javafx/css/converters/EnumConverter.java ! javafx-ui-common/src/com/sun/javafx/css/converters/FontConverter.java ! javafx-ui-common/src/com/sun/javafx/css/converters/InsetsConverter.java ! javafx-ui-common/src/com/sun/javafx/css/converters/PaintConverter.java ! javafx-ui-common/src/com/sun/javafx/css/converters/ShapeConverter.java ! javafx-ui-common/src/com/sun/javafx/css/converters/SizeConverter.java ! javafx-ui-common/src/com/sun/javafx/css/converters/StringConverter.java ! javafx-ui-common/src/com/sun/javafx/css/converters/URLConverter.java ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java ! javafx-ui-common/src/com/sun/javafx/scene/layout/region/BackgroundPositionConverter.java ! javafx-ui-common/src/com/sun/javafx/scene/layout/region/BorderImageWidthConverter.java ! javafx-ui-common/src/com/sun/javafx/scene/layout/region/BorderImageWidthsSequenceConverter.java ! javafx-ui-common/src/com/sun/javafx/scene/layout/region/BorderStyleConverter.java ! javafx-ui-common/src/com/sun/javafx/scene/layout/region/LayeredBackgroundPositionConverter.java ! javafx-ui-common/src/com/sun/javafx/scene/layout/region/Margins.java ! javafx-ui-common/src/javafx/css/CssMetaData.java ! javafx-ui-common/src/javafx/css/FontCssMetaData.java ! javafx-ui-common/src/javafx/css/ParsedValue.java ! javafx-ui-common/src/javafx/css/PseudoClass.java ! javafx-ui-common/src/javafx/css/SimpleStyleableBooleanProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableDoubleProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableFloatProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableIntegerProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableLongProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableObjectProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableStringProperty.java ! javafx-ui-common/src/javafx/css/StyleConverter.java ! javafx-ui-common/src/javafx/css/StyleableProperty.java ! javafx-ui-common/src/javafx/css/package.html ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/src/javafx/scene/layout/Background.java ! javafx-ui-common/src/javafx/scene/layout/BackgroundConverter.java ! javafx-ui-common/src/javafx/scene/layout/Border.java ! javafx-ui-common/src/javafx/scene/layout/BorderConverter.java ! javafx-ui-common/src/javafx/scene/layout/FlowPane.java ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/src/javafx/scene/layout/HBox.java ! javafx-ui-common/src/javafx/scene/layout/Region.java ! javafx-ui-common/src/javafx/scene/layout/StackPane.java ! javafx-ui-common/src/javafx/scene/layout/TilePane.java ! javafx-ui-common/src/javafx/scene/layout/VBox.java ! javafx-ui-common/src/javafx/scene/shape/Rectangle.java ! javafx-ui-common/src/javafx/scene/shape/Shape.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/src/javafx/scene/text/TextFlow.java ! javafx-ui-common/test/unit/com/sun/javafx/css/CssMetaDataTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/FontSizeTypeTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/FontStyleTypeTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/FontTypeTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/FontWeightTypeTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/ParsedValueTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/TestNode.java ! javafx-ui-common/test/unit/com/sun/javafx/css/TestNodeBase.java ! javafx-ui-common/test/unit/com/sun/javafx/css/converters/URLConverterTest.java ! javafx-ui-common/test/unit/com/sun/javafx/test/CssMethodsTestBase.java ! javafx-ui-common/test/unit/javafx/scene/CSSNode.java ! javafx-ui-common/test/unit/javafx/scene/Node_onInvalidate_Test.java ! javafx-ui-common/test/unit/javafx/scene/shape/ShapeTest.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CellSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledImpl.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/javafx/scene/chart/Axis.java ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java ! javafx-ui-controls/src/javafx/scene/chart/NumberAxis.java ! javafx-ui-controls/src/javafx/scene/chart/ValueAxis.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/MenuBar.java ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/ScrollBar.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java ! javafx-ui-controls/src/javafx/scene/control/Separator.java ! javafx-ui-controls/src/javafx/scene/control/SkinBase.java ! javafx-ui-controls/src/javafx/scene/control/Slider.java ! javafx-ui-controls/src/javafx/scene/control/SplitPane.java ! javafx-ui-controls/src/javafx/scene/control/Tab.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TextArea.java ! javafx-ui-controls/src/javafx/scene/control/TextField.java ! javafx-ui-controls/src/javafx/scene/control/TextInputControl.java ! javafx-ui-controls/src/javafx/scene/control/TitledPane.java ! javafx-ui-controls/src/javafx/scene/control/ToolBar.java ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabeledImplTest.java ! javafx-ui-controls/test/javafx/scene/control/ControlTest.java Changeset: b82965d681ce Author: jgiles Date: 2013-01-26 08:44 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b82965d681ce RT-27831: TreeTableView column resizing is very slow ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java Changeset: 29637a83da29 Author: jgiles Date: 2013-01-28 10:23 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/29637a83da29 RT-21406: ComboBox do not show initial text value ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 4a29da2916ad Author: jgiles Date: 2013-01-29 08:47 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4a29da2916ad RT-27830: ComboBox sized and positioned incorrectly on first showing ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: dcd222447449 Author: jgiles Date: 2013-01-29 08:49 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dcd222447449 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 26a8ebfb548e Author: David Grieve Date: 2013-01-28 15:49 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/26a8ebfb548e [TEST-ONLY] fix compile error in ParsedValueTest ! javafx-ui-common/test/unit/com/sun/javafx/css/ParsedValueTest.java Changeset: 6865c1d670b0 Author: David Grieve Date: 2013-01-28 15:49 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6865c1d670b0 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/rt Changeset: 072637dbaa78 Author: jgiles Date: 2013-01-29 09:56 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/072637dbaa78 RT-24630: TableView.scrollTo() always scrolls to the end of the table ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualContainerBase.java ! javafx-ui-controls/src/javafx/scene/control/ControlUtils.java Changeset: ef4d0ec8db0e Author: jgiles Date: 2013-01-29 11:06 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ef4d0ec8db0e RT-27782: Changing TreeColumn property on TreeTableView at runtime does not update visuals until a manual refresh occurs ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java Changeset: 44e38bba7dda Author: jgiles Date: 2013-01-29 11:18 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/44e38bba7dda RT-26026: [ComboBox] Right-click opens both popup and context menu. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ComboBoxBaseBehavior.java Changeset: c8905e3c12dc Author: jgiles Date: 2013-01-29 14:48 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c8905e3c12dc [TEST ONLY] Adding more TreeTableView unit tests (taken from relevant TreeView and TableView unit tests) + javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java Changeset: e6856e34243c Author: jgiles Date: 2013-01-29 15:08 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e6856e34243c RT-27181: TreeView item focus shifts to wrong item on expand and collapse ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: cc6dc48ed105 Author: jgiles Date: 2013-01-29 16:28 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/cc6dc48ed105 RT-27185: TreeView item selection shifts to wrong item on expand and collapse ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: 3cd6a2231637 Author: jgiles Date: 2013-01-30 09:03 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3cd6a2231637 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 9b5e79bd9e0e Author: jgiles Date: 2013-01-30 10:47 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9b5e79bd9e0e RT-26824: ComboBoxTableCell startEdit method should set converter when ComboBox is created ! javafx-ui-controls/src/javafx/scene/control/cell/CellUtils.java ! javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxTreeTableCell.java Changeset: c3cb7059c873 Author: jgiles Date: 2013-01-30 15:38 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c3cb7059c873 RT-27654: clearSelection on ComboBox disallows making the same selection ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/test/javafx/scene/control/ComboBoxTest.java Changeset: d8802f0ed0bf Author: jgiles Date: 2013-01-30 16:24 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d8802f0ed0bf RT-27834: ComboBox styles are inconsistent depending on how the selected element is set ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 2dbbd46cd3d1 Author: David Grieve Date: 2013-01-30 11:03 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2dbbd46cd3d1 branch merge ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/layout/FlowPane.java ! javafx-ui-common/src/javafx/scene/layout/HBox.java ! javafx-ui-common/src/javafx/scene/layout/Region.java ! javafx-ui-common/src/javafx/scene/layout/StackPane.java ! javafx-ui-common/src/javafx/scene/layout/TilePane.java ! javafx-ui-common/src/javafx/scene/layout/VBox.java ! javafx-ui-common/src/javafx/scene/text/Text.java - javafx-ui-common/test/unit/com/sun/javafx/test/OrientationHelper.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java Changeset: b3da6fe789cd Author: David Grieve Date: 2013-01-30 13:27 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b3da6fe789cd [TEST ONLY] @Ignore javafx.scene.control.*KeyInputTest since the do not run on Mac ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewKeyInputTest.java Changeset: 51946c2cfc6e Author: David Grieve Date: 2013-01-30 17:41 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/51946c2cfc6e branch merge Changeset: 0b33c9c1d41e Author: hudson Date: 2013-01-31 13:56 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0b33c9c1d41e Added tag 8.0-b75 for changeset 51946c2cfc6e ! .hgtags Changeset: 7721377d1f70 Author: jgodinez Date: 2013-02-01 11:25 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7721377d1f70 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-concurrent/test/javafx/concurrent/AbstractService.java - javafx-sg-common/src/com/sun/javafx/sg/PGSpan.java ! javafx-sg-common/src/com/sun/javafx/sg/PGText.java - javafx-sg-common/src/com/sun/javafx/sg/PGTextHelper.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGSpan.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGText.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGTextHelper.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/src/javafx/scene/text/TextFlow.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubSpan.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubText.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextHelper.java From chien.yang at oracle.com Fri Feb 1 11:40:17 2013 From: chien.yang at oracle.com (Chien Yang) Date: Fri, 01 Feb 2013 11:40:17 -0800 Subject: [API Review] RT-28129: event coordinates with perspective camera In-Reply-To: <510C16FA.6070007@oracle.com> References: <510BF2A8.9080307@oracle.com> <510C1009.4080005@oracle.com> <1D6C761B-5E46-4D38-BA9C-A2DC78247ACC@oracle.com> <510C138E.4080906@oracle.com> <510C16FA.6070007@oracle.com> Message-ID: <510C1A21.1010602@oracle.com> Hi Kevin, We use texCoord in TriangleMesh, the concrete class of Mesh: public final int getTexCoordCount() public ReadOnlyIntegerProperty texCoordCountProperty() - Chien On 2/1/2013 11:26 AM, Kevin Rushforth wrote: > Chien: what do we use in the Mesh APIs? > > -- Kevin > > > Richard Bair wrote: >> Do we want to continue that tradition? There is a long history of crappy names in C APIs, not all of which we brought with us to Java :-) >> >> Richard >> >> On Feb 1, 2013, at 11:12 AM, Chien Yang wrote: >> >> >>> Yes we do, texCoord (texture coordinate) is a commonly used term in the computer graphics world, for example, OpenGL has methods such as glTexCoord4f(x, y, z, w ), and glTexCoordPointer(4,GL_FLOAT,0,0). >>> >>> - Chien >>> >>> On 2/1/2013 11:01 AM, Richard Bair wrote: >>> >>>> Only thing that got my attention was: getIntersectedTexCoord >>>> >>>> Is the rest of the 3D API using shortened names like "tex" and "coord" as well? >>>> >>>> Richard >>>> >>>> On Feb 1, 2013, at 10:57 AM, Chien Yang wrote: >>>> >>>> >>>>> Looks good to me. This proposed change will also provide a consistent picking framework for 2D and 3D primitives. >>>>> >>>>> Thanks, >>>>> - Chien >>>>> >>>>> On 2/1/2013 8:51 AM, Pavel Safrata wrote: >>>>> >>>>>> Hello, >>>>>> this is related to the 3D support planned for FX8, yet it is a bugfix of an existing issue. >>>>>> >>>>>> With perspective camera, events delivered to any node that's not lying flat on the XY plane contain wrong local coordinates - they ignore the projection transformations. It's enough to rotate a rectangle along X axis and the coordinates become useless. >>>>>> >>>>>> http://javafx-jira.kenai.com/browse/RT-28129 >>>>>> >>>>>> Solution to this problem requires API changes, because we need to compute in 3D to get proper numbers. So I propose to add a "double getZ()" method to all picking-based events, with the following semantics: the event's getSceneX(), getSceneY() values still represent the 2D coordinates of the mouse in the window content pixels (screen coordinates minus window position and decorations); the getX(), getY(), getZ() represent the hit point in the local 3D space (which may now be different even for scene because of the perspective transform). If no node is picked, the hit point with the scene will be found on the projection plane. Note that nothing changes for the 2D case, for the 3D case we now have correct 3D coordinates instead of a complete nonsense. >>>>>> >>>>>> There is one more issue - how to pass the correct coordinates to the event constructors. Instead of creating more construrctors with the three additional coordinates, I propose to use a concept called PickResult which was briefly discussed earlier and will soon be part of a 3D API review. In short, it is an object that contains information about the pick for the event - the picked node, local coordinates of the hit and some 3D-specific stuff. For proper 3D support, it will anyway be necessary to pass the PickResult to the events and allow access to it; once this is done, the event can compute the coordinates from it. So I propose adding PickResult to the event constructors. Note that they've not been released yet, so we can modify them instead of adding new ones. Also note that for convenience of 2D use-cases, the constructors will accept a null PickResult and in this case compute PickResult values based on the passed event target and scene coordinates (which is sufficient f >>>>>> or 2D case). >>>>>> >>>>>> Side note for those who remember the previous 3D API discussion: the PickResult is no longer restricted to 3d shapes, it is present always, with the 3D-specific fields having null values where not applicable. >>>>>> >>>>>> >>>>>> Summary of this proposal: >>>>>> Affected classes: MouseEvent, MouseDragEvent, DragEvent, GestureEvent, ContextMenuEvent and TouchPoint >>>>>> new methods: getZ(), getPickResult() (and extended semantics of event local coordinates for 3D case) >>>>>> modified methods: added PickResult to all constructors >>>>>> >>>>>> Concrete description of the PickResult and the proposed picking API can be found here: >>>>>> https://wikis.oracle.com/display/OpenJDK/Picking3dAPI >>>>>> >>>>>> Thanks, >>>>>> Pavel >>>>>> >>>>>> >> >> From chien.yang at oracle.com Fri Feb 1 11:46:21 2013 From: chien.yang at oracle.com (Chien Yang) Date: Fri, 01 Feb 2013 11:46:21 -0800 Subject: [API Review] FX 8 3D API Message-ID: <510C1B8D.4060302@oracle.com> Hi all, We would like to seek a formal approval for the proposed 3D API that were sent to this alias in October last year. We have been actively working on it since then and we are now ready to make it part of the JavaFX 8 API. JIRA: http://javafx-jira.kenai.com/browse/RT-17401 : 3D geometry support http://javafx-jira.kenai.com/browse/RT-24008 : 3D attributes The proposed API Class Hierarchy: Please see the 3D Feature page and the JavaFX API doc for detail description: https://wikis.oracle.com/display/OpenJDK/3D+Features http://javafx-jira.kenai.com/secure/attachment/35194/API-Review-Final-docs.zip Camera ----------- javafx.scene.Node javafx.scene.Camera (abstract) javafx.scene.ParallelCamera javafx.scene.PerspectiveCamera 3D primitives ------------------- Shape3D: javafx.scene.Node javafx.scene.shape3d.Shape3D (abstract) javafx.scene.shape3d.MeshView javafx.scene.shape3d.Box javafx.scene.shape3d.Cylinder javafx.scene.shape3d.Sphere Mesh: java.lang.Object javafx.scene.shape3d.Mesh (abstract) javafx.scene.shape3d.TriangleMesh 3D attributes -------------------- Light: javafx.scene.Node javafx.scene.light.LightBase (abstract) javafx.scene.light.AmbientLight javafx.scene.light.PointLight Material: java.lang.Object javafx.scene.material.Material (abstract) javafx.scene.material.PhongMaterial SubScene --------------- javafx.scene.Node javafx.scene.SubScene 3D Picking --------------- java.lang.Object javafx.scene.input.PickResult Methods and Properties added to Node --------------------------------------------------------- LOD helper property: /** * A read only property that stores the computed area of this * {@code Node} projected onto the physical screen in pixel unit. */ public final double getAreaInScreen() public final javafx.beans.property.ReadOnlyDoubleProperty areaInScreenProperty() 3D transform methods: public Point3D sceneToLocal(Point3D scenePoint) public Point3D sceneToLocal(double sceneX, double sceneY, double sceneZ) public Point3D localToScene(Point3D localPoint) public Point3D localToScene(double x, double y, double z) public Point3D parentToLocal(Point3D parentPoint) public Point3D parentToLocal(double parentX, double parentY, double parentZ) public Point3D localToParent(Point3D localPoint) public Point3D localToParent(double x, double y, double z) Thanks, - Chien From richard.bair at oracle.com Fri Feb 1 12:55:43 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 1 Feb 2013 12:55:43 -0800 Subject: [API Review] RT-28129: event coordinates with perspective camera In-Reply-To: <510C1872.5080502@oracle.com> References: <510BF2A8.9080307@oracle.com> <510C1009.4080005@oracle.com> <1D6C761B-5E46-4D38-BA9C-A2DC78247ACC@oracle.com> <510C138E.4080906@oracle.com> <510C1872.5080502@oracle.com> Message-ID: <058DDA26-F09B-4B26-9756-F8E637B93DB4@oracle.com> I'm not necessarily against it either. On Feb 1, 2013, at 11:33 AM, Chien Yang wrote: > Good point. This is worth a consideration. I'm fineto change if it doesn't go well with the JavaFX API as a whole. However I've a preference towards texCoord as it is used in all major graphics APIs that I'm aware of including D3D. Nothing to do with its length, really. ;-) > > - Chien > > > On 2/1/2013 11:16 AM, Richard Bair wrote: >> Do we want to continue that tradition? There is a long history of crappy names in C APIs, not all of which we brought with us to Java :-) >> >> Richard >> >> On Feb 1, 2013, at 11:12 AM, Chien Yang wrote: >> >>> Yes we do, texCoord (texture coordinate) is a commonly used term in the computer graphics world, for example, OpenGL has methods such as glTexCoord4f(x, y, z, w ), and glTexCoordPointer(4,GL_FLOAT,0,0). >>> >>> - Chien >>> >>> On 2/1/2013 11:01 AM, Richard Bair wrote: >>>> Only thing that got my attention was: getIntersectedTexCoord >>>> >>>> Is the rest of the 3D API using shortened names like "tex" and "coord" as well? >>>> >>>> Richard >>>> >>>> On Feb 1, 2013, at 10:57 AM, Chien Yang wrote: >>>> >>>>> Looks good to me. This proposed change will also provide a consistent picking framework for 2D and 3D primitives. >>>>> >>>>> Thanks, >>>>> - Chien >>>>> >>>>> On 2/1/2013 8:51 AM, Pavel Safrata wrote: >>>>>> Hello, >>>>>> this is related to the 3D support planned for FX8, yet it is a bugfix of an existing issue. >>>>>> >>>>>> With perspective camera, events delivered to any node that's not lying flat on the XY plane contain wrong local coordinates - they ignore the projection transformations. It's enough to rotate a rectangle along X axis and the coordinates become useless. >>>>>> >>>>>> http://javafx-jira.kenai.com/browse/RT-28129 >>>>>> >>>>>> Solution to this problem requires API changes, because we need to compute in 3D to get proper numbers. So I propose to add a "double getZ()" method to all picking-based events, with the following semantics: the event's getSceneX(), getSceneY() values still represent the 2D coordinates of the mouse in the window content pixels (screen coordinates minus window position and decorations); the getX(), getY(), getZ() represent the hit point in the local 3D space (which may now be different even for scene because of the perspective transform). If no node is picked, the hit point with the scene will be found on the projection plane. Note that nothing changes for the 2D case, for the 3D case we now have correct 3D coordinates instead of a complete nonsense. >>>>>> >>>>>> There is one more issue - how to pass the correct coordinates to the event constructors. Instead of creating more construrctors with the three additional coordinates, I propose to use a concept called PickResult which was briefly discussed earlier and will soon be part of a 3D API review. In short, it is an object that contains information about the pick for the event - the picked node, local coordinates of the hit and some 3D-specific stuff. For proper 3D support, it will anyway be necessary to pass the PickResult to the events and allow access to it; once this is done, the event can compute the coordinates from it. So I propose adding PickResult to the event constructors. Note that they've not been released yet, so we can modify them instead of adding new ones. Also note that for convenience of 2D use-cases, the constructors will accept a null PickResult and in this case compute PickResult values based on the passed event target and scene coordinates (which is sufficient for 2D case). >>>>>> >>>>>> Side note for those who remember the previous 3D API discussion: the PickResult is no longer restricted to 3d shapes, it is present always, with the 3D-specific fields having null values where not applicable. >>>>>> >>>>>> >>>>>> Summary of this proposal: >>>>>> Affected classes: MouseEvent, MouseDragEvent, DragEvent, GestureEvent, ContextMenuEvent and TouchPoint >>>>>> new methods: getZ(), getPickResult() (and extended semantics of event local coordinates for 3D case) >>>>>> modified methods: added PickResult to all constructors >>>>>> >>>>>> Concrete description of the PickResult and the proposed picking API can be found here: >>>>>> https://wikis.oracle.com/display/OpenJDK/Picking3dAPI >>>>>> >>>>>> Thanks, >>>>>> Pavel >>>>>> >>>>> >>>> >>> >> > From zonski at gmail.com Fri Feb 1 13:49:46 2013 From: zonski at gmail.com (Daniel Zwolenski) Date: Sat, 2 Feb 2013 08:49:46 +1100 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: References: <1B3DF0AE-C47D-4EE8-A8CF-58BE0539AC4E@oracle.com> Message-ID: <74671CC2-7BD5-459F-A624-ACB8ADD740D4@gmail.com> Will this cover building the deployment/packaging libraries (currently a mess)? On 02/02/2013, at 5:29 AM, Richard Bair wrote: > OK, I've split the generation script into two pieces -- one is closed and one is open. The open one contains all the logic for creating a "javafx" directory sibling of rt and copying sources etc into it, in the new directory layout. > > It doesn't build yet unless jfxrt.jar is on the class path. If you manage to get the right version of the file it should build -- modulo the printing build break that is awaiting the next weekly build. > > Richard From richard.bair at oracle.com Fri Feb 1 13:50:53 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 1 Feb 2013 13:50:53 -0800 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <74671CC2-7BD5-459F-A624-ACB8ADD740D4@gmail.com> References: <1B3DF0AE-C47D-4EE8-A8CF-58BE0539AC4E@oracle.com> <74671CC2-7BD5-459F-A624-ACB8ADD740D4@gmail.com> Message-ID: <9750123A-8149-4D8A-B08B-1895918F2447@oracle.com> In terms of where the code lives and such, or in terms of how the deployment tools work? On Feb 1, 2013, at 1:49 PM, Daniel Zwolenski wrote: > Will this cover building the deployment/packaging libraries (currently a mess)? > > > > On 02/02/2013, at 5:29 AM, Richard Bair wrote: > >> OK, I've split the generation script into two pieces -- one is closed and one is open. The open one contains all the logic for creating a "javafx" directory sibling of rt and copying sources etc into it, in the new directory layout. >> >> It doesn't build yet unless jfxrt.jar is on the class path. If you manage to get the right version of the file it should build -- modulo the printing build break that is awaiting the next weekly build. >> >> Richard From pavel.safrata at oracle.com Fri Feb 1 14:16:34 2013 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Fri, 01 Feb 2013 23:16:34 +0100 Subject: [API Review] RT-28129: event coordinates with perspective camera In-Reply-To: <058DDA26-F09B-4B26-9756-F8E637B93DB4@oracle.com> References: <510BF2A8.9080307@oracle.com> <510C1009.4080005@oracle.com> <1D6C761B-5E46-4D38-BA9C-A2DC78247ACC@oracle.com> <510C138E.4080906@oracle.com> <510C1872.5080502@oracle.com> <058DDA26-F09B-4B26-9756-F8E637B93DB4@oracle.com> Message-ID: <510C3EC2.90500@oracle.com> I don't have a strong opinion either. When I saw it for the first time, it stroke me immediately as inconsistent with our other naming. Having said that, personally I'd prefer to stick with the texCoord because of the verbosity of beasts like getIntersectedTextureCoordinates or NUM_COMPONENTS_PER_TEXTURE_COORDINATES. I think users will get the meaning of texCoord even if they are not familiar with the other APIs. The term will be used often enough in the code to justify avoiding the verbosity. Also there is the advantage of "coord" meaning coordinates of a single point and "coords" meaning coordinates of multiple points, which would be lost with "coordinates". Pavel On 1.2.2013 21:55, Richard Bair wrote: > I'm not necessarily against it either. > > On Feb 1, 2013, at 11:33 AM, Chien Yang wrote: > >> Good point. This is worth a consideration. I'm fineto change if it doesn't go well with the JavaFX API as a whole. However I've a preference towards texCoord as it is used in all major graphics APIs that I'm aware of including D3D. Nothing to do with its length, really. ;-) >> >> - Chien >> >> >> On 2/1/2013 11:16 AM, Richard Bair wrote: >>> Do we want to continue that tradition? There is a long history of crappy names in C APIs, not all of which we brought with us to Java :-) >>> >>> Richard >>> >>> On Feb 1, 2013, at 11:12 AM, Chien Yang wrote: >>> >>>> Yes we do, texCoord (texture coordinate) is a commonly used term in the computer graphics world, for example, OpenGL has methods such as glTexCoord4f(x, y, z, w ), and glTexCoordPointer(4,GL_FLOAT,0,0). >>>> >>>> - Chien >>>> >>>> On 2/1/2013 11:01 AM, Richard Bair wrote: >>>>> Only thing that got my attention was: getIntersectedTexCoord >>>>> >>>>> Is the rest of the 3D API using shortened names like "tex" and "coord" as well? >>>>> >>>>> Richard >>>>> >>>>> On Feb 1, 2013, at 10:57 AM, Chien Yang wrote: >>>>> >>>>>> Looks good to me. This proposed change will also provide a consistent picking framework for 2D and 3D primitives. >>>>>> >>>>>> Thanks, >>>>>> - Chien >>>>>> >>>>>> On 2/1/2013 8:51 AM, Pavel Safrata wrote: >>>>>>> Hello, >>>>>>> this is related to the 3D support planned for FX8, yet it is a bugfix of an existing issue. >>>>>>> >>>>>>> With perspective camera, events delivered to any node that's not lying flat on the XY plane contain wrong local coordinates - they ignore the projection transformations. It's enough to rotate a rectangle along X axis and the coordinates become useless. >>>>>>> >>>>>>> http://javafx-jira.kenai.com/browse/RT-28129 >>>>>>> >>>>>>> Solution to this problem requires API changes, because we need to compute in 3D to get proper numbers. So I propose to add a "double getZ()" method to all picking-based events, with the following semantics: the event's getSceneX(), getSceneY() values still represent the 2D coordinates of the mouse in the window content pixels (screen coordinates minus window position and decorations); the getX(), getY(), getZ() represent the hit point in the local 3D space (which may now be different even for scene because of the perspective transform). If no node is picked, the hit point with the scene will be found on the projection plane. Note that nothing changes for the 2D case, for the 3D case we now have correct 3D coordinates instead of a complete nonsense. >>>>>>> >>>>>>> There is one more issue - how to pass the correct coordinates to the event constructors. Instead of creating more construrctors with the three additional coordinates, I propose to use a concept called PickResult which was briefly discussed earlier and will soon be part of a 3D API review. In short, it is an object that contains information about the pick for the event - the picked node, local coordinates of the hit and some 3D-specific stuff. For proper 3D support, it will anyway be necessary to pass the PickResult to the events and allow access to it; once this is done, the event can compute the coordinates from it. So I propose adding PickResult to the event constructors. Note that they've not been released yet, so we can modify them instead of adding new ones. Also note that for convenience of 2D use-cases, the constructors will accept a null PickResult and in this case compute PickResult values based on the passed event target and scene coordinates (which is sufficient for 2D case). >>>>>>> >>>>>>> Side note for those who remember the previous 3D API discussion: the PickResult is no longer restricted to 3d shapes, it is present always, with the 3D-specific fields having null values where not applicable. >>>>>>> >>>>>>> >>>>>>> Summary of this proposal: >>>>>>> Affected classes: MouseEvent, MouseDragEvent, DragEvent, GestureEvent, ContextMenuEvent and TouchPoint >>>>>>> new methods: getZ(), getPickResult() (and extended semantics of event local coordinates for 3D case) >>>>>>> modified methods: added PickResult to all constructors >>>>>>> >>>>>>> Concrete description of the PickResult and the proposed picking API can be found here: >>>>>>> https://wikis.oracle.com/display/OpenJDK/Picking3dAPI >>>>>>> >>>>>>> Thanks, >>>>>>> Pavel >>>>>>> From zonski at gmail.com Fri Feb 1 14:25:26 2013 From: zonski at gmail.com (Daniel Zwolenski) Date: Sat, 2 Feb 2013 09:25:26 +1100 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <9750123A-8149-4D8A-B08B-1895918F2447@oracle.com> References: <1B3DF0AE-C47D-4EE8-A8CF-58BE0539AC4E@oracle.com> <74671CC2-7BD5-459F-A624-ACB8ADD740D4@gmail.com> <9750123A-8149-4D8A-B08B-1895918F2447@oracle.com> Message-ID: <348E8C76-E2B3-4A9F-A8B7-1E96BCF885D6@gmail.com> In terms of building the various assets, like jfx-ant-tools.jar (or whatever its called), winlauncher.exe, etc. Currently the ant scripts for doing this don't work out of the box and need fixing. The Oracle guys who have inherited them have/had as much issues as me trying to build on the various platforms. So just wondering if these gradle scripts make life any better in any way in this respect and also wondering about the consistency here: gradle for one, gradle for all, or every module for himself? On 02/02/2013, at 8:50 AM, Richard Bair wrote: > In terms of where the code lives and such, or in terms of how the deployment tools work? > > On Feb 1, 2013, at 1:49 PM, Daniel Zwolenski wrote: > >> Will this cover building the deployment/packaging libraries (currently a mess)? >> >> >> >> On 02/02/2013, at 5:29 AM, Richard Bair wrote: >> >>> OK, I've split the generation script into two pieces -- one is closed and one is open. The open one contains all the logic for creating a "javafx" directory sibling of rt and copying sources etc into it, in the new directory layout. >>> >>> It doesn't build yet unless jfxrt.jar is on the class path. If you manage to get the right version of the file it should build -- modulo the printing build break that is awaiting the next weekly build. >>> >>> Richard > From richard.bair at oracle.com Fri Feb 1 14:33:05 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 1 Feb 2013 14:33:05 -0800 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <348E8C76-E2B3-4A9F-A8B7-1E96BCF885D6@gmail.com> References: <1B3DF0AE-C47D-4EE8-A8CF-58BE0539AC4E@oracle.com> <74671CC2-7BD5-459F-A624-ACB8ADD740D4@gmail.com> <9750123A-8149-4D8A-B08B-1895918F2447@oracle.com> <348E8C76-E2B3-4A9F-A8B7-1E96BCF885D6@gmail.com> Message-ID: <510865A0-64DE-43BE-86E8-83C573DB8172@oracle.com> > In terms of building the various assets, like jfx-ant-tools.jar (or whatever its called), winlauncher.exe, etc. > > Currently the ant scripts for doing this don't work out of the box and need fixing. The Oracle guys who have inherited them have/had as much issues as me trying to build on the various platforms. > > So just wondering if these gradle scripts make life any better in any way in this respect and also wondering about the consistency here: gradle for one, gradle for all, or every module for himself? All for one and one for all. I haven't got very far yet though. Richard From danno.ferrin at shemnon.com Fri Feb 1 14:49:42 2013 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Fri, 1 Feb 2013 15:49:42 -0700 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <510865A0-64DE-43BE-86E8-83C573DB8172@oracle.com> References: <1B3DF0AE-C47D-4EE8-A8CF-58BE0539AC4E@oracle.com> <74671CC2-7BD5-459F-A624-ACB8ADD740D4@gmail.com> <9750123A-8149-4D8A-B08B-1895918F2447@oracle.com> <348E8C76-E2B3-4A9F-A8B7-1E96BCF885D6@gmail.com> <510865A0-64DE-43BE-86E8-83C573DB8172@oracle.com> Message-ID: Tangent alert: all the rest of the code. So now that 7u13 is out what are teh remaining gating factors on getting the rest of the OpenJFX stuff out? I am sure the Developer Preview of JDK8 will be consuming alot of bandwidth, but are there any other aspects we should be aware of? On Fri, Feb 1, 2013 at 3:33 PM, Richard Bair wrote: > > In terms of building the various assets, like jfx-ant-tools.jar (or > whatever its called), winlauncher.exe, etc. > > > > Currently the ant scripts for doing this don't work out of the box and > need fixing. The Oracle guys who have inherited them have/had as much > issues as me trying to build on the various platforms. > > > > So just wondering if these gradle scripts make life any better in any > way in this respect and also wondering about the consistency here: gradle > for one, gradle for all, or every module for himself? > > All for one and one for all. I haven't got very far yet though. > > Richard -- There is nothing that will hold me back. I know who I am.... I remember wher I came from, and I feel stronger for knowing. Zane, Ninja of Ice. Ninjago S01E07 From zonski at gmail.com Fri Feb 1 15:08:15 2013 From: zonski at gmail.com (Daniel Zwolenski) Date: Sat, 2 Feb 2013 10:08:15 +1100 Subject: How does JFX get built for official release Message-ID: <54A79A91-B2AD-4CAD-9912-97C5B5796DDD@gmail.com> There's a lot of complicated, disjoint build scripts for the whole jfx platform, some of which is platform dependent, some is specific only to the jdk and not the jre (like deploy tools). When it's time to release a version to the public, how do these assets get built? Is there a little farm of pc's (or vm's) that are automated to build everything into a deliverable or is it more piecemeal, where bob builds one bit cause he's on mac and then Sam's pc gets used to build the win64 bit? How then does it get integrated into the jre and jdk. Are the build scripts run as part of that or are the built assets delivered to the jre build for inclusion on next jre build? Is there a difference in this process between oracle jdk and open jdk? From hang.vo at oracle.com Fri Feb 1 15:20:30 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 01 Feb 2013 23:20:30 +0000 Subject: hg: openjfx/2.2.6/master/rt: Added tag 2.2.6-b12 for changeset 0920ee3d8395 Message-ID: <20130201232033.13D7E47792@hg.openjdk.java.net> Changeset: 5e46c05d5247 Author: hudson Date: 2013-02-01 10:15 -0800 URL: http://hg.openjdk.java.net/openjfx/2.2.6/master/rt/rev/5e46c05d5247 Added tag 2.2.6-b12 for changeset 0920ee3d8395 ! .hgtags From richard.bair at oracle.com Fri Feb 1 15:23:18 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 1 Feb 2013 15:23:18 -0800 Subject: How does JFX get built for official release In-Reply-To: <54A79A91-B2AD-4CAD-9912-97C5B5796DDD@gmail.com> References: <54A79A91-B2AD-4CAD-9912-97C5B5796DDD@gmail.com> Message-ID: <559017AB-2024-4DF4-852A-79A8D22374E3@oracle.com> We do have a (large) lab of machines that build / test a large number of configurations (different hardware, OS, browsers, embedded, etc). However the process of getting a build out the door includes running various scripts & such across three different organizations: dev, sqe (quality), re (release engineering). The "true" RE builds require licensed software that costs a few $10K per seat. Because of this, there are only a few people who can actually create a build that is put on the web. In addition, not everybody has access to the signing certificate which is used to sign the official builds. The OpenJDK side is built off free software, so it is "easy" for anybody to take the JDK and produce a build. What we are getting to is a setup where anybody can build OpenJDK / OpenJFX / JDK / JFX from their system. True one-button continuous integration / continuous delivery concept. dev / sqe / re are working closely together to pull the entire build / test system together into something that is "easy" for anybody to do. I put "easy" in quotes because of course building anything of this magnitude (with a bunch of native code) is going to have various pre-requisites per-platform that have to be documented and configured correctly. The JDK is moving to heavily using make as the main build system. I want to use Gradle on our side, but haven't yet figured out how to do the native builds on FX with Gradle (maybe we'll also use Make and then just call gradle from make or make from Gradle). It will always be the case that a build has to travel from dev -> sqe -> re before it is finally released to the public. However it will be possible for anybody to produce a build that would be byte-for-byte compatible with what RE finally releases -- except for the code signing -- as long as that person has all the appropriate software installed on their system. For the open source side, of course, it is a lot easier because we'll build everything on free software and so the tools / libraries will be readily available to anybody. Richard On Feb 1, 2013, at 3:08 PM, Daniel Zwolenski wrote: > There's a lot of complicated, disjoint build scripts for the whole jfx platform, some of which is platform dependent, some is specific only to the jdk and not the jre (like deploy tools). > > When it's time to release a version to the public, how do these assets get built? Is there a little farm of pc's (or vm's) that are automated to build everything into a deliverable or is it more piecemeal, where bob builds one bit cause he's on mac and then Sam's pc gets used to build the win64 bit? > > How then does it get integrated into the jre and jdk. Are the build scripts run as part of that or are the built assets delivered to the jre build for inclusion on next jre build? > > Is there a difference in this process between oracle jdk and open jdk? From richard.bair at oracle.com Fri Feb 1 15:35:25 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 1 Feb 2013 15:35:25 -0800 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: References: <1B3DF0AE-C47D-4EE8-A8CF-58BE0539AC4E@oracle.com> <74671CC2-7BD5-459F-A624-ACB8ADD740D4@gmail.com> <9750123A-8149-4D8A-B08B-1895918F2447@oracle.com> <348E8C76-E2B3-4A9F-A8B7-1E96BCF885D6@gmail.com> <510865A0-64DE-43BE-86E8-83C573DB8172@oracle.com> Message-ID: <3EA241C3-80EF-496F-9BCD-F8DDB15DED11@oracle.com> > Tangent alert: all the rest of the code. > > So now that 7u13 is out what are teh remaining gating factors on getting the rest of the OpenJFX stuff out? I am sure the Developer Preview of JDK8 will be consuming alot of bandwidth, but are there any other aspects we should be aware of? The rest of the code falls into 1 of 3 categories: 1) Code that was waiting for 7u13. This code is now cleared to go out and we should see it come out in the next couple weeks. Artem just about has javafx-embed-swing and javafx-embed-swt ready to go. I think the following will also be ready to go late next week / early week after (but need to double check): decora-d3d decora-jsw decora-prism decora-prism-ps decora-prism-sw decora-runtime decora-sse glass javafx-beans javafx-iio prism-j2d prism-ps prism-util 2) Code that is still going through the meat grinder. With the security work ongoing, our schedule is being impacted -- some of these may well be able to come sooner and some a little later: javafx-ui-quantum javafx-ui-webnode prism-common prism-d3d prism-sw webkit webnode-prism prism-es2 prism-es2-eglf prism-es2-eglx11 prism-es2-mac prism-es2-win prism-es2-x11 javafx-ui-desktop media 3) Code that won't be opened or needs an open equivalent to be written. javafx-deploy javafx-font javafx-deploy has applet deployment specific code (the non-applet stuff such as the app co-bundling / javafxpackager code is out / going out). javafx-font has the proprietary T2K dependencies. This dependency needs to be replaced so we can then have a fully open build. I want Felipe to prototype an implementation that delegates directly to the native font code for measurement / glyph generation / layout / etc, rather than using Freetype on all platforms. We need to then get performance #'s on this. I want Felipe to work on this in the open source from the start. The only issue here is that Felipe is also fundamentally involved in bug fixing and our backlog is growing quite large. That's what I know today. I've emailed the team to find out specifics about those items in #2 above to see if any of them (such as quantum / web node) can get moved into category #1 (or at least make it out by the end of February). Some of the embedded related code is tied up in legal approvals and will hopefully be resolved soon. But with legal -- you know how that goes (so prism-es2-eglf, prism-es2-eglx11). However getting the embedded code open is a high priority item so I'm optimistic on it. Thanks for the patience, we're going as fast as we can. Richard From hang.vo at oracle.com Fri Feb 1 15:48:17 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 01 Feb 2013 23:48:17 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130201234821.5C28047794@hg.openjdk.java.net> Changeset: f440bb18e36e Author: David Grieve Date: 2013-02-01 12:41 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f440bb18e36e RT-25288: previous changeset for this bug introduced an index out of bounds exception coming from PseudoClassSet ! javafx-ui-common/src/com/sun/javafx/css/PseudoClassSet.java Changeset: 3b32a4d8521d Author: David Grieve Date: 2013-02-01 12:56 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3b32a4d8521d RT-27472: check if term returns null. if so, skip expr ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java From richard.bair at oracle.com Fri Feb 1 16:11:58 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 1 Feb 2013 16:11:58 -0800 Subject: StubToolkit must go! Message-ID: <60A32258-24E3-4E27-A1E1-7E50C60EB5E3@oracle.com> Well, at least that is what I'm hoping to do. The problem is that we have a bunch of unit tests. 20K+. Some of them rely on StubToolkit, some of them rely on the real deal. In the "source cleanup" operation I'm on, when we combine all the "graphics" tests together, we have a problem where these two different types of tests are together and one set will fail to execute depending on whether we launch with the real toolkit or the stub toolkit. My plan is to yank out StubToolkit and update all the tests that relied on it to instead work with the real toolkit (quantum and prism). I suspect this is going to be painful. Richard From hang.vo at oracle.com Fri Feb 1 16:19:12 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 02 Feb 2013 00:19:12 +0000 Subject: hg: openjfx/8/graphics/rt: Partial RT-28089 Message-ID: <20130202001915.053EE47796@hg.openjdk.java.net> Changeset: dd34f7bd08cd Author: Richard Bair Date: 2013-02-01 16:14 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dd34f7bd08cd Partial RT-28089 Summary: Added the graphics tests. They don't execute unfortunately, silly old StubToolkit. ! build.gradle ! generator.gradle From hang.vo at oracle.com Fri Feb 1 16:33:37 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 02 Feb 2013 00:33:37 +0000 Subject: hg: openjfx/8/controls/rt: fix RT-27901 LineChart series colors are not unique & Message-ID: <20130202003339.3E1F447797@hg.openjdk.java.net> Changeset: ec3108783ed1 Author: Paru Somashekar Date: 2013-02-01 16:31 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ec3108783ed1 fix RT-27901 LineChart series colors are not unique & RT-28090 PieChart throws IAE when elements are sorted ! javafx-ui-charts/src/javafx/scene/chart/AreaChart.java ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java ! javafx-ui-charts/src/javafx/scene/chart/LineChart.java ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java From danno.ferrin at shemnon.com Fri Feb 1 19:06:03 2013 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Fri, 1 Feb 2013 20:06:03 -0700 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: <3EA241C3-80EF-496F-9BCD-F8DDB15DED11@oracle.com> References: <1B3DF0AE-C47D-4EE8-A8CF-58BE0539AC4E@oracle.com> <74671CC2-7BD5-459F-A624-ACB8ADD740D4@gmail.com> <9750123A-8149-4D8A-B08B-1895918F2447@oracle.com> <348E8C76-E2B3-4A9F-A8B7-1E96BCF885D6@gmail.com> <510865A0-64DE-43BE-86E8-83C573DB8172@oracle.com> <3EA241C3-80EF-496F-9BCD-F8DDB15DED11@oracle.com> Message-ID: Currently it is breaking on the JSL compilers (like CompileBlend). Are those files in the first group? On Fri, Feb 1, 2013 at 4:35 PM, Richard Bair wrote: > > Tangent alert: all the rest of the code. > > > > So now that 7u13 is out what are teh remaining gating factors on getting > the rest of the OpenJFX stuff out? I am sure the Developer Preview of JDK8 > will be consuming alot of bandwidth, but are there any other aspects we > should be aware of? > > The rest of the code falls into 1 of 3 categories: > > 1) Code that was waiting for 7u13. This code is now cleared to go out and > we should see it come out in the next couple weeks. Artem just about has > javafx-embed-swing and javafx-embed-swt ready to go. I think the following > will also be ready to go late next week / early week after (but need to > double check): > > decora-d3d > decora-jsw > decora-prism > decora-prism-ps > decora-prism-sw > decora-runtime > decora-sse > glass > javafx-beans > javafx-iio > prism-j2d > prism-ps > prism-util > > 2) Code that is still going through the meat grinder. With the security > work ongoing, our schedule is being impacted -- some of these may well be > able to come sooner and some a little later: > > javafx-ui-quantum > javafx-ui-webnode > prism-common > prism-d3d > prism-sw > webkit > webnode-prism > prism-es2 > prism-es2-eglf > prism-es2-eglx11 > prism-es2-mac > prism-es2-win > prism-es2-x11 > javafx-ui-desktop > media > > 3) Code that won't be opened or needs an open equivalent to be written. > javafx-deploy > javafx-font > > javafx-deploy has applet deployment specific code (the non-applet stuff > such as the app co-bundling / javafxpackager code is out / going out). > > javafx-font has the proprietary T2K dependencies. This dependency needs to > be replaced so we can then have a fully open build. I want Felipe to > prototype an implementation that delegates directly to the native font code > for measurement / glyph generation / layout / etc, rather than using > Freetype on all platforms. We need to then get performance #'s on this. I > want Felipe to work on this in the open source from the start. The only > issue here is that Felipe is also fundamentally involved in bug fixing and > our backlog is growing quite large. > > That's what I know today. I've emailed the team to find out specifics > about those items in #2 above to see if any of them (such as quantum / web > node) can get moved into category #1 (or at least make it out by the end of > February). > > Some of the embedded related code is tied up in legal approvals and will > hopefully be resolved soon. But with legal -- you know how that goes (so > prism-es2-eglf, prism-es2-eglx11). However getting the embedded code open > is a high priority item so I'm optimistic on it. > > Thanks for the patience, we're going as fast as we can. > > Richard > -- There is nothing that will hold me back. I know who I am.... I remember wher I came from, and I feel stronger for knowing. Zane, Ninja of Ice. Ninjago S01E07 From james.graham at oracle.com Fri Feb 1 20:25:50 2013 From: james.graham at oracle.com (Jim Graham) Date: Fri, 01 Feb 2013 20:25:50 -0800 Subject: [API Review] RT-28129: event coordinates with perspective camera In-Reply-To: <510BF2A8.9080307@oracle.com> References: <510BF2A8.9080307@oracle.com> Message-ID: <510C954E.1080104@oracle.com> Would a 3D program need to know the direction the pick ray came into the object from? Knowing the xyz of the location on your surface tells you where they hit your object, and I'm not sure how much they get from the distance, but the direction could tell them whether to, say, apply english to a cue ball as it spins away from the touch/click... Also, perhaps it goes without saying, but I'm guessing that if you have a regular 2D node then the getZ() would be 0 because it represents the touch point that was transformed into your local coordinate system which is a plane? ...jim On 2/1/13 8:51 AM, Pavel Safrata wrote: > Hello, > this is related to the 3D support planned for FX8, yet it is a bugfix of > an existing issue. > > With perspective camera, events delivered to any node that's not lying > flat on the XY plane contain wrong local coordinates - they ignore the > projection transformations. It's enough to rotate a rectangle along X > axis and the coordinates become useless. > > http://javafx-jira.kenai.com/browse/RT-28129 > > Solution to this problem requires API changes, because we need to > compute in 3D to get proper numbers. So I propose to add a "double > getZ()" method to all picking-based events, with the following > semantics: the event's getSceneX(), getSceneY() values still represent > the 2D coordinates of the mouse in the window content pixels (screen > coordinates minus window position and decorations); the getX(), getY(), > getZ() represent the hit point in the local 3D space (which may now be > different even for scene because of the perspective transform). If no > node is picked, the hit point with the scene will be found on the > projection plane. Note that nothing changes for the 2D case, for the 3D > case we now have correct 3D coordinates instead of a complete nonsense. > > There is one more issue - how to pass the correct coordinates to the > event constructors. Instead of creating more construrctors with the > three additional coordinates, I propose to use a concept called > PickResult which was briefly discussed earlier and will soon be part of > a 3D API review. In short, it is an object that contains information > about the pick for the event - the picked node, local coordinates of the > hit and some 3D-specific stuff. For proper 3D support, it will anyway be > necessary to pass the PickResult to the events and allow access to it; > once this is done, the event can compute the coordinates from it. So I > propose adding PickResult to the event constructors. Note that they've > not been released yet, so we can modify them instead of adding new ones. > Also note that for convenience of 2D use-cases, the constructors will > accept a null PickResult and in this case compute PickResult values > based on the passed event target and scene coordinates (which is > sufficient for 2D case). > > Side note for those who remember the previous 3D API discussion: the > PickResult is no longer restricted to 3d shapes, it is present always, > with the 3D-specific fields having null values where not applicable. > > > Summary of this proposal: > Affected classes: MouseEvent, MouseDragEvent, DragEvent, GestureEvent, > ContextMenuEvent and TouchPoint > new methods: getZ(), getPickResult() (and extended semantics of event > local coordinates for 3D case) > modified methods: added PickResult to all constructors > > Concrete description of the PickResult and the proposed picking API can > be found here: > https://wikis.oracle.com/display/OpenJDK/Picking3dAPI > > Thanks, > Pavel > From yennick.trevels at gmail.com Sat Feb 2 08:06:50 2013 From: yennick.trevels at gmail.com (Yennick Trevels) Date: Sat, 2 Feb 2013 17:06:50 +0100 Subject: JavaFx system requirements: Intel GMA 4500MHD: driver update problem In-Reply-To: <510BD05A.80508@oracle.com> References: <510BD05A.80508@oracle.com> Message-ID: Thanks, that worked! On Fri, Feb 1, 2013 at 3:25 PM, Kevin Rushforth wrote: > You can bypass the driver version check with a system property: > > java -Dprism.forceGPU=true ... > > Note that there are (or were) known bugs with this driver version that you > may run into. > > -- Kevin > > > > Yennick Trevels wrote: > >> Anyone has any thoughts on this? Is there a compatibility mode that I can >> turn on? >> >> >> On Wed, Jan 30, 2013 at 7:59 PM, Yennick Trevels >> **wrote: >> >> >> >>> Hi, >>> >>> I'm having a problem getting JavaFx to work on my laptop because of the >>> currently installed display driver. >>> I'm always getting the following error when I try to run my JavaFx >>> application: >>> >>> Device "Mobile Intel(R) 4 Series Express Chipset Family" >>> (\\.\DISPLAY1) initialization failed : >>> WARNING: bad driver version detected, device disabled. Please update >>> your driver to at least version 8.15.10.2302 >>> >>> Now, this message is very clear on what I need to do, but I can't update >>> my drivers to that version even though my graphics card should be >>> supported >>> according to the official system requirements of JavaFx ( >>> http://docs.oracle.com/javafx/**2/system_requirements_2-2-4/** >>> jfxpub-system_requirements_2-**2-4.htm >>> ). >>> >>> My laptop is a Sony Vaio VGN-BZ13XN with a Mobile Intel? Graphics Media >>> Accelerator 4500MHD graphics card (which is in the supported list). I >>> updated my drivers with the VAIO Update program, but it's only upgrading >>> to >>> driver version 8.15.10.1855. >>> I tried downloading the updated driver directly from the Intel site, but >>> it refuses to execute the installation because it detects that I'm on a >>> Sony device. >>> >>> Is there a solution for this? If not, then maybe the system requirements >>> page should indicate the driver version instead of the graphics card >>> model. >>> Also, my laptop isn't new, but not really old (5+years) either, it's only >>> about 3 years old. So this could become a problem to deploy JavaFx >>> applications in an enterprise environment where pc's/laptops aren't >>> upgraded every few years. >>> >>> Thanks, >>> Yennick >>> >>> >>> >> From sven.reimers at gmail.com Sat Feb 2 09:47:02 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Sat, 2 Feb 2013 18:47:02 +0100 Subject: createSymbols Property not available on AreaChart In-Reply-To: References: <21C4C53A-E6EC-4B0C-9944-F0094E63CCC3@oracle.com> Message-ID: Enhancement request filed: http://javafx-jira.kenai.com/browse/RT-28148 Next step: working on a patch -Sven On Fri, Feb 1, 2013 at 8:06 PM, Sven Reimers wrote: > Ok. Will file issue and try to provide patch. > > -Sven > Am 01.02.2013 19:33 schrieb "Jasper Potts" : > > Hi, >> >> Seems like a good idea. If you file a JIRA Tweak that would be great, a >> patch would also be most welcome :-) >> >> Thanks >> >> Jasper >> >> On Feb 1, 2013, at 9:23 AM, Sven Reimers wrote: >> >> > Hi, >> > >> > just thought I check here first before opening a RFE on JIRA. >> > >> > LineChart has a createSymbols Property to switch on/off creation of >> symbols >> > where data points are in the chart. The same property would be nice to >> have >> > on AreaChart as well, since it is way more easy to get rid of the >> symbols >> > with such a property in comparison to be forced doing this via CSS and >> in >> > terms of API it would be more consistent with LineChart. >> > >> > So how about adding createSymbols property to AreaChart? >> > >> > >> > Desired API change: >> > -- snip -- >> > >> > /** >> > * Indicates whether symbols for data points will be created or not. >> > * >> > * @return true if symbols for data points will be created and false >> > otherwise. >> > */ >> > public final boolean getCreateSymbols() { return >> > createSymbols.getValue(); } >> > public final void setCreateSymbols(boolean value) { >> > createSymbols.setValue(value); } >> > public final BooleanProperty createSymbolsProperty() { return >> > createSymbols; } >> > >> > --snip --- >> > >> > Comments? >> > >> > 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 >> >> -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * 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 From mark.howe at oracle.com Sun Feb 3 00:05:51 2013 From: mark.howe at oracle.com (Mark Howe) Date: Sun, 3 Feb 2013 00:05:51 -0800 Subject: Mac JNILIB Self-Contained DMG In-Reply-To: <50fee9c6.2605650a.1e3b.ffffa545@mx.google.com> References: <50e5c630.07cf640a.19dd.ffff870a@mx.google.com> <50fee9c6.2605650a.1e3b.ffffa545@mx.google.com> Message-ID: <54AF95D5-5C0D-48B9-A9AC-B1F323338B36@oracle.com> Hi Will, sorry took so long to respond Don't have a really solid answer yet, but our suggestion for "best practice", is drop all the dylibs in the Resources/Java folder along with the jars and set java.library.path to /path/to/bundle/Contents/Resources/Java. Does that help? Mark On Jan 22, 2013, at 11:34 AM, Will Hoover wrote: > Thanks Mark! > > -----Original Message----- > From: Mark Howe [mailto:mark.howe at oracle.com] > Sent: Tuesday, January 22, 2013 1:31 PM > To: Will Hoover > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Mac JNILIB Self-Contained DMG > > Hi Will, I will look into this and get back to you > > Mark > > On Jan 3, 2013, at 9:56 AM, Will Hoover wrote: > >> I would like to get some feedback on best practices for including a >> JNILIB in a self-contained JavaFX application (with bundled JRE using > ). >> In Windows we can use a drop-in DLL resource by including >> /package/windows/runtime/jre/bin/some.dll to be included in the >> bundled JRE, but on a Mac I'm not sure what the correct approach would >> be. I was thinking of something like: >> >> >> >> >> >> ...but that seems like it would be a bit clunky. >> >> Is there a way to do this on an OSX build that is similar to the >> Windows approach (i.e. in /package/macosx/runtime/jre/bin/some.jnilib)? >> >> > From sven.reimers at gmail.com Sun Feb 3 09:35:35 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Sun, 3 Feb 2013 18:35:35 +0100 Subject: Preferred way to test custom builds with latest JDK 8 binaries Message-ID: Hi, since the latest binaries (b75) now have JavaFX on it's classpath by default, I am interested in the best (quick) way to test changes using custom builds with openjfxrt.jar. Any ideas? -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 From hang.vo at oracle.com Sun Feb 3 20:18:31 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Feb 2013 04:18:31 +0000 Subject: hg: openjfx/8/controls/rt: 8 new changesets Message-ID: <20130204041846.50C5F477CF@hg.openjdk.java.net> Changeset: 33ec77bbf951 Author: jgiles Date: 2013-02-01 14:29 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/33ec77bbf951 [TEST ONLY] Added two unit tests for RT-28113: [TreeView, TreeTableView] Focus jumps to TreeItem sibling when child TreeItem is removed. Both tests are @Ignore'd at the moment, pending a chance to resolve the bug. ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: 66a0f97af26d Author: jgiles Date: 2013-02-01 17:17 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/66a0f97af26d Remove accidental println. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java Changeset: c954f63ec612 Author: jgiles Date: 2013-02-02 09:43 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c954f63ec612 RT-25142: ComboBox accepts setItems(null) but later throws NPE when layout() is called. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 84b84a9d3d5d Author: jgiles Date: 2013-02-04 14:49 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/84b84a9d3d5d Further work on RT-28100: Make internal KeyBinding class consistent with key events and simplify cross-platform controls behaviour code. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/KeyBinding.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/OrientedKeyBinding.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java ! javafx-ui-controls/test/javafx/scene/control/KeyEventFirer.java ! javafx-ui-controls/test/javafx/scene/control/KeyModifier.java Changeset: 8727876146cb Author: jgiles Date: 2013-02-04 14:49 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8727876146cb [TEST ONLY] Added unit tests for RT-28065 (although the tests are disabled until a fix is in place). ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewKeyInputTest.java Changeset: b7bfb47e2654 Author: jgiles Date: 2013-02-04 15:13 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b7bfb47e2654 RT-27829: Clean up controls compilation warnings (part two) Contributed-By: Tom Schindl Reviewed-By: jgiles ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java ! javafx-ui-controls/src/javafx/scene/control/ScrollToEvent.java ! javafx-ui-controls/src/javafx/scene/control/Separator.java ! javafx-ui-controls/src/javafx/scene/control/Tab.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TablePosition.java ! javafx-ui-controls/src/javafx/scene/control/TitledPane.java ! javafx-ui-controls/src/javafx/scene/control/ToggleButton.java ! javafx-ui-controls/src/javafx/scene/control/ToolBar.java ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java ! javafx-ui-controls/src/javafx/scene/control/TreeCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeItem.java ! javafx-ui-controls/src/javafx/scene/control/TreeTablePosition.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableRow.java Changeset: 0e085e2dce76 Author: jgiles Date: 2013-02-04 15:17 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0e085e2dce76 RT-28128: TableColumnBase.DEFAULT_COMPARATOR can lead to CCE Contributed-By: Tom Schindl Reviewed-By: jgiles ! javafx-ui-controls/src/javafx/scene/control/TableColumnBase.java Changeset: 29207ea36ee0 Author: jgiles Date: 2013-02-04 17:03 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/29207ea36ee0 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt From hang.vo at oracle.com Sun Feb 3 22:03:18 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Feb 2013 06:03:18 +0000 Subject: hg: openjfx/8/controls/rt: Significantly improved keyboard navigation support for ListView, TreeView, TableView and TreeTableView on Mac OS (as part of RT-27658). Additionally, I have fixed up all the *KeyInputTest unit tests to run and pass on Mac OS, although due to memory limitations of the build servers they continue to be @Ignore'd. Message-ID: <20130204060320.DC533477D2@hg.openjdk.java.net> Changeset: 8252bde86002 Author: Jonathan Giles Date: 2013-02-04 19:00 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8252bde86002 Significantly improved keyboard navigation support for ListView, TreeView, TableView and TreeTableView on Mac OS (as part of RT-27658). Additionally, I have fixed up all the *KeyInputTest unit tests to run and pass on Mac OS, although due to memory limitations of the build servers they continue to be @Ignore'd. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewKeyInputTest.java From tom.schindl at bestsolution.at Mon Feb 4 00:25:09 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 04 Feb 2013 09:25:09 +0100 Subject: [API Review] RT-24916 - TableView.scrollTo(TableColumn) Message-ID: <510F7065.3020101@bestsolution.at> hi, We (Jonathan and myself) are requesting an API review to add the following public APIs: New APIS: --------- * ListView: scrollTo(T) : void * TableView: scrollTo(S) : void scrollToColumn(TableColumn) : void scrollToColumnIndex(int) : void setOnScrollToColumn(EventHandler>>): void getOnScrollToColumn() : EventHandler>> onScrollToColumnProperty(): ObjectProperty>>> * TreeTableView scrollToColumn(TableColumn column) : void scrollToColumnIndex(int columnIndex) : void setOnScrollToColumn(EventHandler>> value) : void getOnScrollToColumn() : EventHandler>> onScrollToColumnProperty() : ObjectProperty>>> * ScrollToEvent: static > scrollToColumn() : EventType> Modified APIS: -------------- To align better we'd like to change the ScrollToEvent-API to be consitent and use static accessor methods instead of public static fields: * SCROLL_TO_NODE => scrollToNode() : EventType> * SCROLL_TO_TOP_INDEX => scrollToTopIndex() : EventType> Thanks Jonathan + Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From pavel.safrata at oracle.com Mon Feb 4 01:29:11 2013 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 04 Feb 2013 10:29:11 +0100 Subject: StubToolkit must go! In-Reply-To: <60A32258-24E3-4E27-A1E1-7E50C60EB5E3@oracle.com> References: <60A32258-24E3-4E27-A1E1-7E50C60EB5E3@oracle.com> Message-ID: <510F7F67.3020408@oracle.com> Hi Richard, I strongly object. I've had this discussion with Kevin a year ago, quoting myself from the old discussion: Scenegraph unit tests are there to test scenegraph. I believe that unit tests should by their definition test single units isolated from the rest of the system, not the system as a whole - for this we should have functional tests developed by QA. Our tests make sure that scenegraph works correctly given that the underlying platform behaves as expected. Including live toolkit/glass in running the tests would IMHO seriously damage purpose of those tests - they wouldn't give any reliable evidence of scenegraph's stability any more. Other important thing is that the code doesn't change over time (so it tests regressions in scenegraph) and also the test can make it behave in more different ways (and test scenegraph robustness). Thanks, Pavel On 2.2.2013 1:11, Richard Bair wrote: > Well, at least that is what I'm hoping to do. The problem is that we have a bunch of unit tests. 20K+. Some of them rely on StubToolkit, some of them rely on the real deal. In the "source cleanup" operation I'm on, when we combine all the "graphics" tests together, we have a problem where these two different types of tests are together and one set will fail to execute depending on whether we launch with the real toolkit or the stub toolkit. > > My plan is to yank out StubToolkit and update all the tests that relied on it to instead work with the real toolkit (quantum and prism). I suspect this is going to be painful. > > Richard From pavel.safrata at oracle.com Mon Feb 4 02:32:43 2013 From: pavel.safrata at oracle.com (Pavel Safrata) Date: Mon, 04 Feb 2013 11:32:43 +0100 Subject: [API Review] RT-28129: event coordinates with perspective camera In-Reply-To: <510C954E.1080104@oracle.com> References: <510BF2A8.9080307@oracle.com> <510C954E.1080104@oracle.com> Message-ID: <510F8E4B.9060508@oracle.com> Hi Jim, On 2.2.2013 5:25, Jim Graham wrote: > Would a 3D program need to know the direction the pick ray came into > the object from? Knowing the xyz of the location on your surface > tells you where they hit your object, and I'm not sure how much they > get from the distance, but the direction could tell them whether to, > say, apply english to a cue ball as it spins away from the touch/click... I'll let people with more 3D background decide. From the technical point of view, it can be added quite easily. > > Also, perhaps it goes without saying, but I'm guessing that if you > have a regular 2D node then the getZ() would be 0 because it > represents the touch point that was transformed into your local > coordinate system which is a plane? It will be 0 when delivered to the event target. However, not necessarily during the capturing/bubbling phases. For example, if you have a rectangle in a group, and the rectangle has setTranslateZ(10), the event will have z=0 when delivered to the rectangle, but z=10 when delivered to the group. Pavel > > ...jim > > On 2/1/13 8:51 AM, Pavel Safrata wrote: >> Hello, >> this is related to the 3D support planned for FX8, yet it is a bugfix of >> an existing issue. >> >> With perspective camera, events delivered to any node that's not lying >> flat on the XY plane contain wrong local coordinates - they ignore the >> projection transformations. It's enough to rotate a rectangle along X >> axis and the coordinates become useless. >> >> http://javafx-jira.kenai.com/browse/RT-28129 >> >> Solution to this problem requires API changes, because we need to >> compute in 3D to get proper numbers. So I propose to add a "double >> getZ()" method to all picking-based events, with the following >> semantics: the event's getSceneX(), getSceneY() values still represent >> the 2D coordinates of the mouse in the window content pixels (screen >> coordinates minus window position and decorations); the getX(), getY(), >> getZ() represent the hit point in the local 3D space (which may now be >> different even for scene because of the perspective transform). If no >> node is picked, the hit point with the scene will be found on the >> projection plane. Note that nothing changes for the 2D case, for the 3D >> case we now have correct 3D coordinates instead of a complete nonsense. >> >> There is one more issue - how to pass the correct coordinates to the >> event constructors. Instead of creating more construrctors with the >> three additional coordinates, I propose to use a concept called >> PickResult which was briefly discussed earlier and will soon be part of >> a 3D API review. In short, it is an object that contains information >> about the pick for the event - the picked node, local coordinates of the >> hit and some 3D-specific stuff. For proper 3D support, it will anyway be >> necessary to pass the PickResult to the events and allow access to it; >> once this is done, the event can compute the coordinates from it. So I >> propose adding PickResult to the event constructors. Note that they've >> not been released yet, so we can modify them instead of adding new ones. >> Also note that for convenience of 2D use-cases, the constructors will >> accept a null PickResult and in this case compute PickResult values >> based on the passed event target and scene coordinates (which is >> sufficient for 2D case). >> >> Side note for those who remember the previous 3D API discussion: the >> PickResult is no longer restricted to 3d shapes, it is present always, >> with the 3D-specific fields having null values where not applicable. >> >> >> Summary of this proposal: >> Affected classes: MouseEvent, MouseDragEvent, DragEvent, GestureEvent, >> ContextMenuEvent and TouchPoint >> new methods: getZ(), getPickResult() (and extended semantics of event >> local coordinates for 3D case) >> modified methods: added PickResult to all constructors >> >> Concrete description of the PickResult and the proposed picking API can >> be found here: >> https://wikis.oracle.com/display/OpenJDK/Picking3dAPI >> >> Thanks, >> Pavel >> From hjohn at xs4all.nl Mon Feb 4 03:02:43 2013 From: hjohn at xs4all.nl (John Hendrikx) Date: Mon, 04 Feb 2013 12:02:43 +0100 Subject: [API Review] RT-24916 - TableView.scrollTo(TableColumn) In-Reply-To: <510F7065.3020101@bestsolution.at> References: <510F7065.3020101@bestsolution.at> Message-ID: <510F9553.3060408@xs4all.nl> Hi, I'm not specifically commenting on this API, but I do would like to comment on the usefulness of scrollTo() in general. I've found that scrollTo() is very unreliable when cells are not fixed-height, and are still in flux (ie, images being loaded in the background) after the call to scrollTo(). Basically, what is happening is: 1) Create control, populate model 2) Call scrollTo() / focus() to restore the previous position the user left the control/cursor at 3) More images get loaded, cells change height and the View moves accordingly but completely ignores the last scrollTo() call and currently focused cell and ends up at some random location (with the focused item often not even in View). 4) User has to take a navigation action to get the focused item visible again I donot know of any acceptable work-arounds, as the problem is mainly that the scrollTo() call is a fire-and-forget type action that will be completely lost when Cells are still in flux. What it should do is remember this position and keep adjusting the View when no other form of input overrides the current location (keyboard, mouse scrolling, scrollbars). Furthermore, scrollTo(), although a nice high level API, does not allow me to "return" to an exact previous state (where the exact scroll position of the control is restored). I'd have to keep the control in memory to be able to provide this functionality, instead of just creating it when needed and positioning it back to where it was. This occurs for example when Views are used for navigation purposes where when an item is selected a different set of items is displayed. Navigating back restores the previous set of items, but unfortunately not the exact position the user came from. All this is currently leading me into the direction of reskinning the TreeView control, with the goal of providing reliable and stable behavior when it comes to dealing with cells that are in flux. --John On 04/02/2013 09:25, Tom Schindl wrote: > hi, > > We (Jonathan and myself) are requesting an API review to add the > following public APIs: > > New APIS: > --------- > * ListView: > scrollTo(T) : void > > * TableView: > scrollTo(S) : void > scrollToColumn(TableColumn) : void > scrollToColumnIndex(int) : void > setOnScrollToColumn(EventHandler>>): void > getOnScrollToColumn() : EventHandler>> > onScrollToColumnProperty(): > ObjectProperty>>> > > * TreeTableView > scrollToColumn(TableColumn column) : void > scrollToColumnIndex(int columnIndex) : void > setOnScrollToColumn(EventHandler>> > value) : void > getOnScrollToColumn() : EventHandler>> > onScrollToColumnProperty() : > ObjectProperty>>> > > * ScrollToEvent: > static > scrollToColumn() : > EventType> > > Modified APIS: > -------------- > To align better we'd like to change the ScrollToEvent-API to be > consitent and use static accessor methods instead of public static fields: > * SCROLL_TO_NODE => scrollToNode() : EventType> > * SCROLL_TO_TOP_INDEX => scrollToTopIndex() : > EventType> > > > Thanks > > Jonathan + Tom > From hang.vo at oracle.com Mon Feb 4 03:18:16 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Feb 2013 11:18:16 +0000 Subject: hg: openjfx/8/graphics/rt: Fix for RT-28165: Move javafx-embed-swing and javafx-embed-swt to open Message-ID: <20130204111822.B2825477D7@hg.openjdk.java.net> Changeset: fa747ba3156b Author: Artem Ananiev Date: 2013-02-04 15:12 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fa747ba3156b Fix for RT-28165: Move javafx-embed-swing and javafx-embed-swt to open Reviewed-by: Kevin Rushforth ! .classpath ! .idea/modules.xml ! build.xml + javafx-embed-swing/build-closed.xml + javafx-embed-swing/build-common.xml + javafx-embed-swing/build.xml + javafx-embed-swing/javafx-embed-swing.iml + javafx-embed-swing/nbproject/project.xml + javafx-embed-swing/project.properties + javafx-embed-swing/src/javafx/embed/swing/DataFlavorUtils.java + javafx-embed-swing/src/javafx/embed/swing/JFXPanel.java + javafx-embed-swing/src/javafx/embed/swing/SwingCursors.java + javafx-embed-swing/src/javafx/embed/swing/SwingDnD.java + javafx-embed-swing/src/javafx/embed/swing/SwingDragSource.java + javafx-embed-swing/src/javafx/embed/swing/SwingEvents.java + javafx-embed-swing/src/javafx/embed/swing/SwingFXUtils.java + javafx-embed-swing/src/javafx/embed/swing/package.html + javafx-embed-swt/build-closed.xml + javafx-embed-swt/build-common.xml + javafx-embed-swt/build.xml + javafx-embed-swt/javafx-embed-swt.iml + javafx-embed-swt/nbproject/project.xml + javafx-embed-swt/project.properties + javafx-embed-swt/src/javafx/embed/swt/CustomTransfer.java + javafx-embed-swt/src/javafx/embed/swt/FXCanvas.java + javafx-embed-swt/src/javafx/embed/swt/SWTCursors.java + javafx-embed-swt/src/javafx/embed/swt/SWTEvents.java + javafx-embed-swt/src/javafx/embed/swt/SWTFXUtils.java + javafx-embed-swt/src/javafx/embed/swt/package.html From artem.ananiev at oracle.com Mon Feb 4 03:19:11 2013 From: artem.ananiev at oracle.com (artem.ananiev at oracle.com) Date: Mon, 04 Feb 2013 11:19:11 +0000 Subject: hg: openjfx/8/graphics: Introducing SWT_DIR env variable and swt.path ant property to build JavaFX/SWT classes Message-ID: <20130204111911.67314477D8@hg.openjdk.java.net> Changeset: fa2593dfacea Author: art Date: 2013-02-04 15:16 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rev/fa2593dfacea Introducing SWT_DIR env variable and swt.path ant property to build JavaFX/SWT classes ! build-defs.xml ! build-src/build-environment.xml From artem.ananiev at oracle.com Mon Feb 4 05:26:27 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Mon, 04 Feb 2013 17:26:27 +0400 Subject: JavaFX/Swing and JavaFX/SWT classes are open-sourced Message-ID: <510FB703.6060201@oracle.com> Hi, OpenJFX members, as Richard wrote in the previous email, both JavaFX/Swing (JFXPanel) and JavaFX/SWT (FXCanvas) components were the next candidates to be open-sourced. Now the candidates are no longer candidates, they are in open. The changes are pushed via Graphics forest: http://hg.openjdk.java.net/openjfx/8/graphics http://hg.openjdk.java.net/openjfx/8/graphics/rt and should be in the master forest in a week or so. Now some technical details. rt/javafx-embed-swing is built as any other component in rt/, rt/javafx-embed-swt is a little bit more complicated. These classes depend on SWT, so you need to have swt.jar in classpath in compile time to build them. It can be done in two ways, either with a new env variable: SWT_DIR=/path/to/swt ant dist or with an ant property: ant -Dswt.path=/path/to/swt dist where /path/to/swt is a folder that contains swt.jar If neither SWT_DIR nor swt.path are specified, rt/javafx-embed-swt will not be built, but imported from the bootstrap jfxrt.jar as any other classes that are not open-sourced yet. Thanks, Artem From hang.vo at oracle.com Mon Feb 4 05:33:22 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Feb 2013 13:33:22 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130204133325.C36BC477DD@hg.openjdk.java.net> Changeset: c2fb1c411133 Author: Martin Sladecek Date: 2013-02-04 14:18 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c2fb1c411133 RT-28166 Animation methods accept illegal Duration values that are not expected in the Animation code. ! javafx-anim/src/javafx/animation/Animation.java ! javafx-anim/src/javafx/animation/Timeline.java ! javafx-ui-common/src/javafx/animation/FadeTransition.java ! javafx-ui-common/src/javafx/animation/FillTransition.java ! javafx-ui-common/src/javafx/animation/PathTransition.java ! javafx-ui-common/src/javafx/animation/PauseTransition.java ! javafx-ui-common/src/javafx/animation/RotateTransition.java ! javafx-ui-common/src/javafx/animation/ScaleTransition.java ! javafx-ui-common/src/javafx/animation/StrokeTransition.java ! javafx-ui-common/src/javafx/animation/TranslateTransition.java Changeset: 7425eab5722d Author: Martin Sladecek Date: 2013-02-04 14:25 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7425eab5722d merge From sven.reimers at gmail.com Mon Feb 4 06:52:08 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 4 Feb 2013 15:52:08 +0100 Subject: Preferred way to test custom builds with latest JDK 8 binaries In-Reply-To: References: Message-ID: Update: I tried so far: -endorsed: does not work classloading fails -prepending bootclasspath: does not work classloading fails So it seems I need to have the ability to create full jfxrt.jar else both approaces fail. So any ideas besides creating a local copy of my jdk and patching the original jfxrt.jar in some way to incorporate my changes? Thanks -Sven On Sun, Feb 3, 2013 at 6:35 PM, Sven Reimers wrote: > Hi, > > since the latest binaries (b75) now have JavaFX on it's classpath by > default, I am interested in the best (quick) way to test changes using > custom builds with openjfxrt.jar. > > Any ideas? > > -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 > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * 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 From hang.vo at oracle.com Mon Feb 4 07:03:50 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Feb 2013 15:03:50 +0000 Subject: hg: openjfx/8/controls/rt: RT-22977 : Keyboard focus Traversal : Non-mouse Traversal Input Message-ID: <20130204150353.E1F08477E4@hg.openjdk.java.net> Changeset: 3408eed98c2c Author: mickf Date: 2013-02-04 14:58 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3408eed98c2c RT-22977 : Keyboard focus Traversal : Non-mouse Traversal Input ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ChoiceBoxBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ComboBoxBaseBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/SliderBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/Utils.java From hang.vo at oracle.com Mon Feb 4 07:33:04 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Feb 2013 15:33:04 +0000 Subject: hg: openjfx/8/graphics/rt: RT-14730: Drag and drop needs support for drag view. Reviewed by Pavel Safrata Message-ID: <20130204153307.C98D7477E6@hg.openjdk.java.net> Changeset: 2a0b0d0d4dd1 Author: Eva Krejcirova Date: 2013-02-04 16:29 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2a0b0d0d4dd1 RT-14730: Drag and drop needs support for drag view. Reviewed by Pavel Safrata ! javafx-ui-common/src/com/sun/javafx/tk/TKClipboard.java ! javafx-ui-common/src/javafx/scene/input/DataFormat.java ! javafx-ui-common/src/javafx/scene/input/Dragboard.java ! javafx-ui-common/test/unit/javafx/scene/input/DragAndDropTest.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java From hang.vo at oracle.com Mon Feb 4 08:03:36 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Feb 2013 16:03:36 +0000 Subject: hg: openjfx/8/controls/rt: RT-28042 : Resolve Findbugs issues in com.sun.javafx.scene.control.skin.Utils Message-ID: <20130204160339.DBE00477E9@hg.openjdk.java.net> Changeset: 1310b65cbceb Author: mickf Date: 2013-02-04 15:54 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1310b65cbceb RT-28042 : Resolve Findbugs issues in com.sun.javafx.scene.control.skin.Utils ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/Utils.java From hang.vo at oracle.com Mon Feb 4 08:17:44 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Feb 2013 16:17:44 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130204161749.46B3F477EA@hg.openjdk.java.net> Changeset: d715d9ce4dff Author: Martin Sladecek Date: 2013-02-04 17:09 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d715d9ce4dff Fixed failing tests ! javafx-anim/src/javafx/animation/Animation.java Changeset: d5735f8fd0a7 Author: Martin Sladecek Date: 2013-02-04 17:09 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d5735f8fd0a7 merge From chien.yang at oracle.com Mon Feb 4 08:55:02 2013 From: chien.yang at oracle.com (Chien Yang) Date: Mon, 04 Feb 2013 08:55:02 -0800 Subject: [API Review] RT-28129: event coordinates with perspective camera In-Reply-To: <510F8E4B.9060508@oracle.com> References: <510BF2A8.9080307@oracle.com> <510C954E.1080104@oracle.com> <510F8E4B.9060508@oracle.com> Message-ID: <510FE7E6.1040602@oracle.com> On 2/4/2013 2:32 AM, Pavel Safrata wrote: > Hi Jim, > > On 2.2.2013 5:25, Jim Graham wrote: >> Would a 3D program need to know the direction the pick ray came into >> the object from? Knowing the xyz of the location on your surface >> tells you where they hit your object, and I'm not sure how much they >> get from the distance, but the direction could tell them whether to, >> say, apply english to a cue ball as it spins away from the >> touch/click... > > I'll let people with more 3D background decide. From the technical > point of view, it can be added quite easily. With the PickResult object, a user can construct this direction vector from the Camera position and the return intersected point. - Chien > >> >> Also, perhaps it goes without saying, but I'm guessing that if you >> have a regular 2D node then the getZ() would be 0 because it >> represents the touch point that was transformed into your local >> coordinate system which is a plane? > > It will be 0 when delivered to the event target. However, not > necessarily during the capturing/bubbling phases. For example, if you > have a rectangle in a group, and the rectangle has setTranslateZ(10), > the event will have z=0 when delivered to the rectangle, but z=10 when > delivered to the group. > > Pavel > >> >> ...jim >> >> On 2/1/13 8:51 AM, Pavel Safrata wrote: >>> Hello, >>> this is related to the 3D support planned for FX8, yet it is a >>> bugfix of >>> an existing issue. >>> >>> With perspective camera, events delivered to any node that's not lying >>> flat on the XY plane contain wrong local coordinates - they ignore the >>> projection transformations. It's enough to rotate a rectangle along X >>> axis and the coordinates become useless. >>> >>> http://javafx-jira.kenai.com/browse/RT-28129 >>> >>> Solution to this problem requires API changes, because we need to >>> compute in 3D to get proper numbers. So I propose to add a "double >>> getZ()" method to all picking-based events, with the following >>> semantics: the event's getSceneX(), getSceneY() values still represent >>> the 2D coordinates of the mouse in the window content pixels (screen >>> coordinates minus window position and decorations); the getX(), getY(), >>> getZ() represent the hit point in the local 3D space (which may now be >>> different even for scene because of the perspective transform). If no >>> node is picked, the hit point with the scene will be found on the >>> projection plane. Note that nothing changes for the 2D case, for the 3D >>> case we now have correct 3D coordinates instead of a complete nonsense. >>> >>> There is one more issue - how to pass the correct coordinates to the >>> event constructors. Instead of creating more construrctors with the >>> three additional coordinates, I propose to use a concept called >>> PickResult which was briefly discussed earlier and will soon be part of >>> a 3D API review. In short, it is an object that contains information >>> about the pick for the event - the picked node, local coordinates of >>> the >>> hit and some 3D-specific stuff. For proper 3D support, it will >>> anyway be >>> necessary to pass the PickResult to the events and allow access to it; >>> once this is done, the event can compute the coordinates from it. So I >>> propose adding PickResult to the event constructors. Note that they've >>> not been released yet, so we can modify them instead of adding new >>> ones. >>> Also note that for convenience of 2D use-cases, the constructors will >>> accept a null PickResult and in this case compute PickResult values >>> based on the passed event target and scene coordinates (which is >>> sufficient for 2D case). >>> >>> Side note for those who remember the previous 3D API discussion: the >>> PickResult is no longer restricted to 3d shapes, it is present always, >>> with the 3D-specific fields having null values where not applicable. >>> >>> >>> Summary of this proposal: >>> Affected classes: MouseEvent, MouseDragEvent, DragEvent, GestureEvent, >>> ContextMenuEvent and TouchPoint >>> new methods: getZ(), getPickResult() (and extended semantics of event >>> local coordinates for 3D case) >>> modified methods: added PickResult to all constructors >>> >>> Concrete description of the PickResult and the proposed picking API can >>> be found here: >>> https://wikis.oracle.com/display/OpenJDK/Picking3dAPI >>> >>> Thanks, >>> Pavel >>> > From kevin.rushforth at oracle.com Mon Feb 4 08:59:42 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 04 Feb 2013 08:59:42 -0800 Subject: [API Review] RT-28129: event coordinates with perspective camera In-Reply-To: <510F8E4B.9060508@oracle.com> References: <510BF2A8.9080307@oracle.com> <510C954E.1080104@oracle.com> <510F8E4B.9060508@oracle.com> Message-ID: <510FE8FE.1080906@oracle.com> I think the PickRay would be a good addition when we provide a user-initiated picking API that takes a PickRay provided by the user (right now picking is only done as part of the mouse event handling system). Until then, this is probably not needed, although as Pavel indicated, could be added pretty easily. Chien: what do you think? -- Kevin Pavel Safrata wrote: > Hi Jim, > > On 2.2.2013 5:25, Jim Graham wrote: >> Would a 3D program need to know the direction the pick ray came into >> the object from? Knowing the xyz of the location on your surface >> tells you where they hit your object, and I'm not sure how much they >> get from the distance, but the direction could tell them whether to, >> say, apply english to a cue ball as it spins away from the >> touch/click... > > I'll let people with more 3D background decide. From the technical > point of view, it can be added quite easily. > >> >> Also, perhaps it goes without saying, but I'm guessing that if you >> have a regular 2D node then the getZ() would be 0 because it >> represents the touch point that was transformed into your local >> coordinate system which is a plane? > > It will be 0 when delivered to the event target. However, not > necessarily during the capturing/bubbling phases. For example, if you > have a rectangle in a group, and the rectangle has setTranslateZ(10), > the event will have z=0 when delivered to the rectangle, but z=10 when > delivered to the group. > > Pavel > >> >> ...jim >> >> On 2/1/13 8:51 AM, Pavel Safrata wrote: >>> Hello, >>> this is related to the 3D support planned for FX8, yet it is a >>> bugfix of >>> an existing issue. >>> >>> With perspective camera, events delivered to any node that's not lying >>> flat on the XY plane contain wrong local coordinates - they ignore the >>> projection transformations. It's enough to rotate a rectangle along X >>> axis and the coordinates become useless. >>> >>> http://javafx-jira.kenai.com/browse/RT-28129 >>> >>> Solution to this problem requires API changes, because we need to >>> compute in 3D to get proper numbers. So I propose to add a "double >>> getZ()" method to all picking-based events, with the following >>> semantics: the event's getSceneX(), getSceneY() values still represent >>> the 2D coordinates of the mouse in the window content pixels (screen >>> coordinates minus window position and decorations); the getX(), getY(), >>> getZ() represent the hit point in the local 3D space (which may now be >>> different even for scene because of the perspective transform). If no >>> node is picked, the hit point with the scene will be found on the >>> projection plane. Note that nothing changes for the 2D case, for the 3D >>> case we now have correct 3D coordinates instead of a complete nonsense. >>> >>> There is one more issue - how to pass the correct coordinates to the >>> event constructors. Instead of creating more construrctors with the >>> three additional coordinates, I propose to use a concept called >>> PickResult which was briefly discussed earlier and will soon be part of >>> a 3D API review. In short, it is an object that contains information >>> about the pick for the event - the picked node, local coordinates of >>> the >>> hit and some 3D-specific stuff. For proper 3D support, it will >>> anyway be >>> necessary to pass the PickResult to the events and allow access to it; >>> once this is done, the event can compute the coordinates from it. So I >>> propose adding PickResult to the event constructors. Note that they've >>> not been released yet, so we can modify them instead of adding new >>> ones. >>> Also note that for convenience of 2D use-cases, the constructors will >>> accept a null PickResult and in this case compute PickResult values >>> based on the passed event target and scene coordinates (which is >>> sufficient for 2D case). >>> >>> Side note for those who remember the previous 3D API discussion: the >>> PickResult is no longer restricted to 3d shapes, it is present always, >>> with the 3D-specific fields having null values where not applicable. >>> >>> >>> Summary of this proposal: >>> Affected classes: MouseEvent, MouseDragEvent, DragEvent, GestureEvent, >>> ContextMenuEvent and TouchPoint >>> new methods: getZ(), getPickResult() (and extended semantics of event >>> local coordinates for 3D case) >>> modified methods: added PickResult to all constructors >>> >>> Concrete description of the PickResult and the proposed picking API can >>> be found here: >>> https://wikis.oracle.com/display/OpenJDK/Picking3dAPI >>> >>> Thanks, >>> Pavel >>> > From kevin.rushforth at oracle.com Mon Feb 4 09:09:17 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 04 Feb 2013 09:09:17 -0800 Subject: Preferred way to test custom builds with latest JDK 8 binaries In-Reply-To: References: Message-ID: <510FEB3D.6000208@oracle.com> > -prepending bootclasspath: does not work classloading fails I would suggest appending openjfxrt.jar to the bootclasspath (there is a known bug when prepending...I'll dig up the bug ID if you are interested). -- Kevin Sven Reimers wrote: > Update: > > I tried so far: > > -endorsed: does not work classloading fails > -prepending bootclasspath: does not work classloading fails > > So it seems I need to have the ability to create full jfxrt.jar else both > approaces fail. > > So any ideas besides creating a local copy of my jdk and patching the > original jfxrt.jar in some way to incorporate my changes? > > Thanks > > -Sven > > > On Sun, Feb 3, 2013 at 6:35 PM, Sven Reimers wrote: > > >> Hi, >> >> since the latest binaries (b75) now have JavaFX on it's classpath by >> default, I am interested in the best (quick) way to test changes using >> custom builds with openjfxrt.jar. >> >> Any ideas? >> >> -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 >> >> > > > > From sven.reimers at gmail.com Mon Feb 4 09:45:20 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 4 Feb 2013 18:45:20 +0100 Subject: Preferred way to test custom builds with latest JDK 8 binaries In-Reply-To: <510FEB3D.6000208@oracle.com> References: <510FEB3D.6000208@oracle.com> Message-ID: Just tried it, but it tells me ClassNotFoundException com/sun/javafx/tk/quantum/QuantumToolkit and because of this I think RuntimeException: No Toolkit found I think this is because this is still not open sourced and as such missing in my openjfxrt.jar.. Should the openjfxrt.jar be a drop in replacement for jfxrt.jar already? Thanks for your help -Sven On Mon, Feb 4, 2013 at 6:09 PM, Kevin Rushforth wrote: > ** > > -prepending bootclasspath: does not work classloading fails > > I would suggest appending openjfxrt.jar to the bootclasspath (there is a > known bug when prepending...I'll dig up the bug ID if you are interested). > > -- Kevin > > > > Sven Reimers wrote: > > Update: > > I tried so far: > > -endorsed: does not work classloading fails > -prepending bootclasspath: does not work classloading fails > > So it seems I need to have the ability to create full jfxrt.jar else both > approaces fail. > > So any ideas besides creating a local copy of my jdk and patching the > original jfxrt.jar in some way to incorporate my changes? > > Thanks > > -Sven > > > On Sun, Feb 3, 2013 at 6:35 PM, Sven Reimers wrote: > > > > Hi, > > since the latest binaries (b75) now have JavaFX on it's classpath by > default, I am interested in the best (quick) way to test changes using > custom builds with openjfxrt.jar. > > Any ideas? > > -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 > > > > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * 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 From kevin.rushforth at oracle.com Mon Feb 4 09:49:12 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 04 Feb 2013 09:49:12 -0800 Subject: Preferred way to test custom builds with latest JDK 8 binaries In-Reply-To: References: <510FEB3D.6000208@oracle.com> Message-ID: <510FF498.6050000@oracle.com> > Should the openjfxrt.jar be a drop in replacement for jfxrt.jar already? No, it isn't (and won't be for a few months). If you put openjfxrt.jar and jfxrt.jar on the boot classpath with -Xbootclasspath/a does that work? I would expect that it should. -- Kevin Sven Reimers wrote: > Just tried it, but it tells me > > ClassNotFoundException com/sun/javafx/tk/quantum/QuantumToolkit > > and because of this I think > > RuntimeException: No Toolkit found > > I think this is because this is still not open sourced and as such > missing in my openjfxrt.jar.. > > Should the openjfxrt.jar be a drop in replacement for jfxrt.jar already? > > Thanks for your help > > -Sven > > > On Mon, Feb 4, 2013 at 6:09 PM, Kevin Rushforth > > wrote: > > > -prepending bootclasspath: does not work classloading fails > > I would suggest appending openjfxrt.jar to the bootclasspath > (there is a known bug when prepending...I'll dig up the bug ID if > you are interested). > > -- Kevin > > > > Sven Reimers wrote: >> Update: >> >> I tried so far: >> >> -endorsed: does not work classloading fails >> -prepending bootclasspath: does not work classloading fails >> >> So it seems I need to have the ability to create full jfxrt.jar else both >> approaces fail. >> >> So any ideas besides creating a local copy of my jdk and patching the >> original jfxrt.jar in some way to incorporate my changes? >> >> Thanks >> >> -Sven >> >> >> On Sun, Feb 3, 2013 at 6:35 PM, Sven Reimers wrote: >> >> >>> Hi, >>> >>> since the latest binaries (b75) now have JavaFX on it's classpath by >>> default, I am interested in the best (quick) way to test changes using >>> custom builds with openjfxrt.jar. >>> >>> Any ideas? >>> >>> -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 >>> >>> >> > > > > > -- > Sven Reimers > > * Senior Expert Software Architect > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * NetBeans Governance Board Member: > http://netbeans.org/about/os/governance.html > * 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 From richard.bair at oracle.com Mon Feb 4 07:41:45 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 4 Feb 2013 07:41:45 -0800 Subject: StubToolkit must go! In-Reply-To: <510F7F67.3020408@oracle.com> References: <60A32258-24E3-4E27-A1E1-7E50C60EB5E3@oracle.com> <510F7F67.3020408@oracle.com> Message-ID: <993F6F47-AF3C-4BFA-B6B7-405EEEEEAC7E@oracle.com> Hi Pavel, Removing StubToolkit _does not imply_ that we have to test with a live toolkit / glass. For example, the PolygonTest wants to test that during synchronization the array of floats it expected to be passed to the peer is the actual set that got passed. @Test public void testBounds_oddPointsLength() { final double[] initialPoints = { 100, 100, 200, 100, 200, 200, 150, 300 }; final Polygon polygon = new PolygonMock(initialPoints); assertBoundsEqual(box(100, 100, 100, 200), polygon.getBoundsInLocal()); final ObservableList polygonPoints = polygon.getPoints(); polygonPoints.remove(6); assertBoundsEqual(box(100, 100, 100, 100), polygon.getBoundsInLocal()); } This can easily be done by using a special subclass of Polygon that, in impl_createPGNode, creates a special subclass of NGPolygon: private static final class PolygonMock extends Polygon { public PolygonMock() { super(); } public PolygonMock(double... points) { super(points); } @Override protected PGNode impl_createPGNode() { return new StubPolygon(); } } private static final class StubPolygon extends NGPolygon { float[] points; @Override public void updatePolygon(float[] points) { this.points = points; super.updatePolygon(points); } } Running this test does not require that we fire up multiple threads or open a glass window etc. I haven't finished combing through all the usages of StubToolkit, but I'm confident we can remove it without changing the nature of the tests. Richard On Feb 4, 2013, at 1:29 AM, Pavel Safrata wrote: > Hi Richard, > I strongly object. I've had this discussion with Kevin a year ago, quoting myself from the old discussion: > > Scenegraph unit tests are there to test scenegraph. I believe that unit tests should by their definition test single units isolated from the rest of the system, not the system as a whole - for this we should have functional tests developed by QA. Our tests make sure that scenegraph works correctly given that the underlying platform behaves as expected. Including live toolkit/glass in running the tests would IMHO seriously damage purpose of those tests - they wouldn't give any reliable evidence of scenegraph's stability any more. Other important thing is that the code doesn't change over time (so it tests regressions in scenegraph) and also the test can make it behave in more different ways (and test scenegraph robustness). > > Thanks, > Pavel > > On 2.2.2013 1:11, Richard Bair wrote: >> Well, at least that is what I'm hoping to do. The problem is that we have a bunch of unit tests. 20K+. Some of them rely on StubToolkit, some of them rely on the real deal. In the "source cleanup" operation I'm on, when we combine all the "graphics" tests together, we have a problem where these two different types of tests are together and one set will fail to execute depending on whether we launch with the real toolkit or the stub toolkit. >> >> My plan is to yank out StubToolkit and update all the tests that relied on it to instead work with the real toolkit (quantum and prism). I suspect this is going to be painful. >> >> Richard > From hang.vo at oracle.com Mon Feb 4 11:03:16 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Feb 2013 19:03:16 +0000 Subject: hg: openjfx/8/graphics/rt: 20 new changesets Message-ID: <20130204190345.DABCC477F6@hg.openjdk.java.net> Changeset: 3e556868fc53 Author: kcr Date: 2012-11-05 08:27 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3e556868fc53 RT-25322: Improve utility methods (bugdb 14672404) Reviewed-by: Steve Northover, Phil Race, Artem Ananiev, Marc Schoenefeld ! javafx-ui-common/src/com/sun/javafx/Utils.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 11a05268d086 Author: kcr Date: 2012-11-10 06:47 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/11a05268d086 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-controls/src/javafx/scene/control/Control.java Changeset: 2da5fd244217 Author: kcr Date: 2012-11-20 07:24 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2da5fd244217 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/com/sun/javafx/Utils.java Changeset: 001ec302d141 Author: kcr Date: 2012-11-30 14:04 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/001ec302d141 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 8c4be8679422 Author: kcr Date: 2012-12-07 09:29 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8c4be8679422 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: fc3d9c1c40be Author: kcr Date: 2012-12-13 18:49 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fc3d9c1c40be Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/com/sun/javafx/Utils.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: bf7b298cab88 Author: kcr Date: 2012-11-16 12:35 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bf7b298cab88 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/com/sun/javafx/Utils.java Changeset: 99bb0131ebc9 Author: Milan Kubec Date: 2012-11-26 16:22 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/99bb0131ebc9 fix of classpath related to move of the project from rt-closed repo to rt repo ! javafx-fxml/nbproject/project.xml Changeset: 5fbc473c6c5d Author: Artem Ananiev Date: 2012-11-29 19:57 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5fbc473c6c5d RT-26578: Improve Glass thread handling Reviewed-by: Andrew Gross, Kevin Rushforth, Marc Schoenefeld ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/com/sun/javafx/tk/TKScene.java ! javafx-ui-common/src/com/sun/javafx/tk/TKStage.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-common/src/javafx/stage/Window.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubScene.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubStage.java Changeset: 61c721a2f027 Author: kcr Date: 2012-11-30 15:40 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/61c721a2f027 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8-cpu-225/dev/jfx/rt ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 6046b51aa28f Author: kcr Date: 2012-12-07 10:16 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6046b51aa28f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8-cpu-225/dev/jfx/rt Changeset: d3c9ba231203 Author: kcr Date: 2012-12-13 19:04 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d3c9ba231203 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8-cpu-225/dev/jfx/rt ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: e2e77aed2a96 Author: kcr Date: 2012-12-20 18:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e2e77aed2a96 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 79e549a30585 Author: kcr Date: 2013-01-03 16:11 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/79e549a30585 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: ee1f55c99b71 Author: kcr Date: 2013-01-12 11:17 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ee1f55c99b71 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 9d69c7de9bfe Author: Milan Kubec Date: 2013-01-21 10:47 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9d69c7de9bfe RT-26596: fwd-port to FX8 of Reuse standard utility classes for method calls ! javafx-fxml/project.properties ! javafx-fxml/src/com/sun/javafx/fxml/BeanAdapter.java ! javafx-fxml/src/javafx/fxml/FXMLLoader.java ! javafx-fxml/src/javafx/fxml/JavaFXBuilderFactory.java Changeset: 00328d63df9e Author: kcr Date: 2013-01-21 07:33 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/00328d63df9e Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-fxml/src/javafx/fxml/FXMLLoader.java ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 1585db3ed50d Author: kcr Date: 2013-01-26 08:41 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1585db3ed50d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-fxml/src/com/sun/javafx/fxml/BeanAdapter.java ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 56dee48d8e94 Author: kcr Date: 2013-02-01 07:08 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/56dee48d8e94 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-fxml/project.properties ! javafx-fxml/src/javafx/fxml/FXMLLoader.java ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/com/sun/javafx/tk/TKStage.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-common/src/javafx/stage/Window.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubStage.java Changeset: 012c2fd4a6f9 Author: jgodinez Date: 2013-02-04 10:47 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/012c2fd4a6f9 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt - javafx-concurrent/test/javafx/concurrent/AbstractService.java - javafx-sg-common/src/com/sun/javafx/sg/PGSpan.java - javafx-sg-common/src/com/sun/javafx/sg/PGTextHelper.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGSpan.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGTextHelper.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubSpan.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextHelper.java From lehmann at media-interactive.de Mon Feb 4 11:43:58 2013 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 4 Feb 2013 20:43:58 +0100 Subject: SceneBuilder src, or how to drag/size controls Message-ID: <51100F7E.2010603@media-interactive.de> Hi, for an upcoming project I'll need to provide a subset of the SceneBuilder functionality. More specifically, controls such as a Label or TextField need to be dragged from a tool palette into a designing area where they can be selected, moved, and resized. Is the SceneBuilder src available? Otherwise, any recommendations on do's and dont's? Fortunately this week's links on FX-Experience include a just-in-time article on resizing regions: > http://andrewtill.blogspot.co.nz/2012/12/dragging-to-resize-javafx-region.html (Thanks, Andrew) Region would be interesting for custom "tools" but I'll need this for standard controls, too. Maybe I should wrap each of them into a stackpane to provide a clickable selection border with drag points? Rgds Werner From jonathan.giles at oracle.com Mon Feb 4 12:02:07 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 05 Feb 2013 09:02:07 +1300 Subject: [API Review] RT-24916 - TableView.scrollTo(TableColumn) In-Reply-To: <510F9553.3060408@xs4all.nl> References: <510F7065.3020101@bestsolution.at> <510F9553.3060408@xs4all.nl> Message-ID: <511013BF.6000100@oracle.com> This is a fair comment: scrollTo has been designed with a 'fire-and-forget' approach in mind, but I would be loath to add a means of requesting a self-correcting scrollTo function. Wouldn't a suitable workaround be to call scrollTo after the image loading has completed in all cells? Regarding a lower-level API for exact positioning, please file a jira tweak request. Thanks, -- Jonathan On 5/02/2013 12:02 a.m., John Hendrikx wrote: > Hi, > > I'm not specifically commenting on this API, but I do would like to > comment on the usefulness of scrollTo() in general. > > I've found that scrollTo() is very unreliable when cells are not > fixed-height, and are still in flux (ie, images being loaded in the > background) after the call to scrollTo(). Basically, what is > happening is: > > 1) Create control, populate model > 2) Call scrollTo() / focus() to restore the previous position the user > left the control/cursor at > 3) More images get loaded, cells change height and the View moves > accordingly but completely ignores the last scrollTo() call and > currently focused cell and ends up at some random location (with the > focused item often not even in View). > 4) User has to take a navigation action to get the focused item > visible again > > I donot know of any acceptable work-arounds, as the problem is mainly > that the scrollTo() call is a fire-and-forget type action that will be > completely lost when Cells are still in flux. What it should do is > remember this position and keep adjusting the View when no other form > of input overrides the current location (keyboard, mouse scrolling, > scrollbars). > > Furthermore, scrollTo(), although a nice high level API, does not > allow me to "return" to an exact previous state (where the exact > scroll position of the control is restored). I'd have to keep the > control in memory to be able to provide this functionality, instead of > just creating it when needed and positioning it back to where it was. > This occurs for example when Views are used for navigation purposes > where when an item is selected a different set of items is displayed. > Navigating back restores the previous set of items, but unfortunately > not the exact position the user came from. > > All this is currently leading me into the direction of reskinning the > TreeView control, with the goal of providing reliable and stable > behavior when it comes to dealing with cells that are in flux. > > --John > > On 04/02/2013 09:25, Tom Schindl wrote: >> hi, >> >> We (Jonathan and myself) are requesting an API review to add the >> following public APIs: >> >> New APIS: >> --------- >> * ListView: >> scrollTo(T) : void >> >> * TableView: >> scrollTo(S) : void >> scrollToColumn(TableColumn) : void >> scrollToColumnIndex(int) : void >> setOnScrollToColumn(EventHandler>>): >> void >> getOnScrollToColumn() : EventHandler> ?>>> >> onScrollToColumnProperty(): >> ObjectProperty>>> >> >> * TreeTableView >> scrollToColumn(TableColumn column) : void >> scrollToColumnIndex(int columnIndex) : void >> setOnScrollToColumn(EventHandler>> >> value) : void >> getOnScrollToColumn() : >> EventHandler>> >> onScrollToColumnProperty() : >> ObjectProperty>>> >> >> * ScrollToEvent: >> static > scrollToColumn() : >> EventType> >> >> Modified APIS: >> -------------- >> To align better we'd like to change the ScrollToEvent-API to be >> consitent and use static accessor methods instead of public static >> fields: >> * SCROLL_TO_NODE => scrollToNode() : EventType> >> * SCROLL_TO_TOP_INDEX => scrollToTopIndex() : >> EventType> >> >> >> Thanks >> >> Jonathan + Tom >> > From jonathan.giles at oracle.com Mon Feb 4 12:04:15 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 05 Feb 2013 09:04:15 +1300 Subject: SceneBuilder src, or how to drag/size controls In-Reply-To: <51100F7E.2010603@media-interactive.de> References: <51100F7E.2010603@media-interactive.de> Message-ID: <5110143F.6060405@oracle.com> I can't speak to the first part of your email, but regarding resizing standard controls: as of JavaFX 8.0 Control extends from Region, so whilst I haven't tested Andrew's code, this should theoretically work. It would be worth testing, anyway :-) -- Jonathan On 5/02/2013 8:43 a.m., Werner Lehmann wrote: > Hi, > > for an upcoming project I'll need to provide a subset of the > SceneBuilder functionality. More specifically, controls such as a > Label or TextField need to be dragged from a tool palette into a > designing area where they can be selected, moved, and resized. > > Is the SceneBuilder src available? Otherwise, any recommendations on > do's and dont's? Fortunately this week's links on FX-Experience > include a just-in-time article on resizing regions: > >> http://andrewtill.blogspot.co.nz/2012/12/dragging-to-resize-javafx-region.html >> > (Thanks, Andrew) > > Region would be interesting for custom "tools" but I'll need this for > standard controls, too. Maybe I should wrap each of them into a > stackpane to provide a clickable selection border with drag points? > > Rgds > Werner From joe.mcglynn at oracle.com Mon Feb 4 12:15:25 2013 From: joe.mcglynn at oracle.com (Joe McGlynn) Date: Mon, 4 Feb 2013 12:15:25 -0800 Subject: SceneBuilder src, or how to drag/size controls In-Reply-To: <51100F7E.2010603@media-interactive.de> References: <51100F7E.2010603@media-interactive.de> Message-ID: <03984064-67DE-4A15-AABD-B5ABBFF16EB0@oracle.com> SceneBuilder is not available in source form, sorry. On Feb 4, 2013, at 11:43 AM, Werner Lehmann wrote: > Hi, > > for an upcoming project I'll need to provide a subset of the SceneBuilder functionality. More specifically, controls such as a Label or TextField need to be dragged from a tool palette into a designing area where they can be selected, moved, and resized. > > Is the SceneBuilder src available? Otherwise, any recommendations on do's and dont's? Fortunately this week's links on FX-Experience include a just-in-time article on resizing regions: > >> http://andrewtill.blogspot.co.nz/2012/12/dragging-to-resize-javafx-region.html > (Thanks, Andrew) > > Region would be interesting for custom "tools" but I'll need this for standard controls, too. Maybe I should wrap each of them into a stackpane to provide a clickable selection border with drag points? > > Rgds > Werner From sven.reimers at gmail.com Mon Feb 4 12:51:26 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 4 Feb 2013 21:51:26 +0100 Subject: Preferred way to test custom builds with latest JDK 8 binaries In-Reply-To: <510FF498.6050000@oracle.com> References: <510FEB3D.6000208@oracle.com> <510FF498.6050000@oracle.com> Message-ID: Yes that worked. So this is what does the trick: -Xbootclasspath/a:pathToOpenJFX/dist/openjfxrt.jar:pathToJDK8/jre/libs/ext/jfxrt.jar -Sven On Mon, Feb 4, 2013 at 6:49 PM, Kevin Rushforth wrote: > ** > > Should the openjfxrt.jar be a drop in replacement for jfxrt.jar already? > > No, it isn't (and won't be for a few months). If you put openjfxrt.jar and > jfxrt.jar on the boot classpath with -Xbootclasspath/a does that work? I > would expect that it should. > > > -- Kevin > > > Sven Reimers wrote: > > Just tried it, but it tells me > > ClassNotFoundException com/sun/javafx/tk/quantum/QuantumToolkit > > and because of this I think > > RuntimeException: No Toolkit found > > I think this is because this is still not open sourced and as such > missing in my openjfxrt.jar.. > > Should the openjfxrt.jar be a drop in replacement for jfxrt.jar already? > > Thanks for your help > > -Sven > > > On Mon, Feb 4, 2013 at 6:09 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> > -prepending bootclasspath: does not work classloading fails >> >> I would suggest appending openjfxrt.jar to the bootclasspath (there is a >> known bug when prepending...I'll dig up the bug ID if you are interested). >> >> -- Kevin >> >> >> >> Sven Reimers wrote: >> >> Update: >> >> I tried so far: >> >> -endorsed: does not work classloading fails >> -prepending bootclasspath: does not work classloading fails >> >> So it seems I need to have the ability to create full jfxrt.jar else both >> approaces fail. >> >> So any ideas besides creating a local copy of my jdk and patching the >> original jfxrt.jar in some way to incorporate my changes? >> >> Thanks >> >> -Sven >> >> >> On Sun, Feb 3, 2013 at 6:35 PM, Sven Reimers wrote: >> >> >> >> Hi, >> >> since the latest binaries (b75) now have JavaFX on it's classpath by >> default, I am interested in the best (quick) way to test changes using >> custom builds with openjfxrt.jar. >> >> Any ideas? >> >> -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 >> >> > > > -- > Sven Reimers > > * Senior Expert Software Architect > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * NetBeans Governance Board Member: > http://netbeans.org/about/os/governance.html > * 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 > > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * 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 From hang.vo at oracle.com Mon Feb 4 13:33:01 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Feb 2013 21:33:01 +0000 Subject: hg: openjfx/8/controls/rt: 21 new changesets Message-ID: <20130204213332.10878477FE@hg.openjdk.java.net> Changeset: 0b33c9c1d41e Author: hudson Date: 2013-01-31 13:56 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0b33c9c1d41e Added tag 8.0-b75 for changeset 51946c2cfc6e ! .hgtags Changeset: 3e556868fc53 Author: kcr Date: 2012-11-05 08:27 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3e556868fc53 RT-25322: Improve utility methods (bugdb 14672404) Reviewed-by: Steve Northover, Phil Race, Artem Ananiev, Marc Schoenefeld ! javafx-ui-common/src/com/sun/javafx/Utils.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 11a05268d086 Author: kcr Date: 2012-11-10 06:47 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/11a05268d086 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-controls/src/javafx/scene/control/Control.java Changeset: 2da5fd244217 Author: kcr Date: 2012-11-20 07:24 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2da5fd244217 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/com/sun/javafx/Utils.java Changeset: 001ec302d141 Author: kcr Date: 2012-11-30 14:04 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/001ec302d141 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 8c4be8679422 Author: kcr Date: 2012-12-07 09:29 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8c4be8679422 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: fc3d9c1c40be Author: kcr Date: 2012-12-13 18:49 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fc3d9c1c40be Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/com/sun/javafx/Utils.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: bf7b298cab88 Author: kcr Date: 2012-11-16 12:35 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bf7b298cab88 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/com/sun/javafx/Utils.java Changeset: 99bb0131ebc9 Author: Milan Kubec Date: 2012-11-26 16:22 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/99bb0131ebc9 fix of classpath related to move of the project from rt-closed repo to rt repo ! javafx-fxml/nbproject/project.xml Changeset: 5fbc473c6c5d Author: Artem Ananiev Date: 2012-11-29 19:57 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5fbc473c6c5d RT-26578: Improve Glass thread handling Reviewed-by: Andrew Gross, Kevin Rushforth, Marc Schoenefeld ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/com/sun/javafx/tk/TKScene.java ! javafx-ui-common/src/com/sun/javafx/tk/TKStage.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-common/src/javafx/stage/Window.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubScene.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubStage.java Changeset: 61c721a2f027 Author: kcr Date: 2012-11-30 15:40 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/61c721a2f027 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8-cpu-225/dev/jfx/rt ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 6046b51aa28f Author: kcr Date: 2012-12-07 10:16 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6046b51aa28f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8-cpu-225/dev/jfx/rt Changeset: d3c9ba231203 Author: kcr Date: 2012-12-13 19:04 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d3c9ba231203 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8-cpu-225/dev/jfx/rt ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: e2e77aed2a96 Author: kcr Date: 2012-12-20 18:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e2e77aed2a96 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 79e549a30585 Author: kcr Date: 2013-01-03 16:11 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/79e549a30585 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: ee1f55c99b71 Author: kcr Date: 2013-01-12 11:17 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ee1f55c99b71 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 9d69c7de9bfe Author: Milan Kubec Date: 2013-01-21 10:47 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9d69c7de9bfe RT-26596: fwd-port to FX8 of Reuse standard utility classes for method calls ! javafx-fxml/project.properties ! javafx-fxml/src/com/sun/javafx/fxml/BeanAdapter.java ! javafx-fxml/src/javafx/fxml/FXMLLoader.java ! javafx-fxml/src/javafx/fxml/JavaFXBuilderFactory.java Changeset: 00328d63df9e Author: kcr Date: 2013-01-21 07:33 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/00328d63df9e Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-fxml/src/javafx/fxml/FXMLLoader.java ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 1585db3ed50d Author: kcr Date: 2013-01-26 08:41 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1585db3ed50d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-fxml/src/com/sun/javafx/fxml/BeanAdapter.java ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 56dee48d8e94 Author: kcr Date: 2013-02-01 07:08 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/56dee48d8e94 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-fxml/project.properties ! javafx-fxml/src/javafx/fxml/FXMLLoader.java ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/com/sun/javafx/tk/TKStage.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-common/src/javafx/stage/Window.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubStage.java Changeset: f6b77bf59fff Author: David Grieve Date: 2013-02-04 16:29 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f6b77bf59fff branch merge ! javafx-ui-common/src/javafx/scene/Scene.java From sven.reimers at gmail.com Mon Feb 4 14:01:05 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 4 Feb 2013 23:01:05 +0100 Subject: createSymbols Property not available on AreaChart In-Reply-To: References: <21C4C53A-E6EC-4B0C-9944-F0094E63CCC3@oracle.com> Message-ID: Here you go - patch attached (hope this makes it through) -Sven On Sat, Feb 2, 2013 at 6:47 PM, Sven Reimers wrote: > Enhancement request filed: > > http://javafx-jira.kenai.com/browse/RT-28148 > > Next step: working on a patch > > -Sven > > > On Fri, Feb 1, 2013 at 8:06 PM, Sven Reimers wrote: > >> Ok. Will file issue and try to provide patch. >> >> -Sven >> Am 01.02.2013 19:33 schrieb "Jasper Potts" : >> >> Hi, >>> >>> Seems like a good idea. If you file a JIRA Tweak that would be great, a >>> patch would also be most welcome :-) >>> >>> Thanks >>> >>> Jasper >>> >>> On Feb 1, 2013, at 9:23 AM, Sven Reimers wrote: >>> >>> > Hi, >>> > >>> > just thought I check here first before opening a RFE on JIRA. >>> > >>> > LineChart has a createSymbols Property to switch on/off creation of >>> symbols >>> > where data points are in the chart. The same property would be nice to >>> have >>> > on AreaChart as well, since it is way more easy to get rid of the >>> symbols >>> > with such a property in comparison to be forced doing this via CSS and >>> in >>> > terms of API it would be more consistent with LineChart. >>> > >>> > So how about adding createSymbols property to AreaChart? >>> > >>> > >>> > Desired API change: >>> > -- snip -- >>> > >>> > /** >>> > * Indicates whether symbols for data points will be created or not. >>> > * >>> > * @return true if symbols for data points will be created and false >>> > otherwise. >>> > */ >>> > public final boolean getCreateSymbols() { return >>> > createSymbols.getValue(); } >>> > public final void setCreateSymbols(boolean value) { >>> > createSymbols.setValue(value); } >>> > public final BooleanProperty createSymbolsProperty() { return >>> > createSymbols; } >>> > >>> > --snip --- >>> > >>> > Comments? >>> > >>> > 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 >>> >>> > > > -- > Sven Reimers > > * Senior Expert Software Architect > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * NetBeans Governance Board Member: > http://netbeans.org/about/os/governance.html > > * 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 > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * 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 From jonathan.giles at oracle.com Mon Feb 4 14:21:30 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 05 Feb 2013 11:21:30 +1300 Subject: createSymbols Property not available on AreaChart In-Reply-To: References: <21C4C53A-E6EC-4B0C-9944-F0094E63CCC3@oracle.com> Message-ID: <5110346A.1050106@oracle.com> Nope, attachments to openjfx-dev are stripped. Please email it to me and I'll attach it to the jira issue. -- Jonathan On 5/02/2013 11:01 a.m., Sven Reimers wrote: > Here you go - patch attached (hope this makes it through) > > -Sven > > > On Sat, Feb 2, 2013 at 6:47 PM, Sven Reimers wrote: > >> Enhancement request filed: >> >> http://javafx-jira.kenai.com/browse/RT-28148 >> >> Next step: working on a patch >> >> -Sven >> >> >> On Fri, Feb 1, 2013 at 8:06 PM, Sven Reimers wrote: >> >>> Ok. Will file issue and try to provide patch. >>> >>> -Sven >>> Am 01.02.2013 19:33 schrieb "Jasper Potts" : >>> >>> Hi, >>>> Seems like a good idea. If you file a JIRA Tweak that would be great, a >>>> patch would also be most welcome :-) >>>> >>>> Thanks >>>> >>>> Jasper >>>> >>>> On Feb 1, 2013, at 9:23 AM, Sven Reimers wrote: >>>> >>>>> Hi, >>>>> >>>>> just thought I check here first before opening a RFE on JIRA. >>>>> >>>>> LineChart has a createSymbols Property to switch on/off creation of >>>> symbols >>>>> where data points are in the chart. The same property would be nice to >>>> have >>>>> on AreaChart as well, since it is way more easy to get rid of the >>>> symbols >>>>> with such a property in comparison to be forced doing this via CSS and >>>> in >>>>> terms of API it would be more consistent with LineChart. >>>>> >>>>> So how about adding createSymbols property to AreaChart? >>>>> >>>>> >>>>> Desired API change: >>>>> -- snip -- >>>>> >>>>> /** >>>>> * Indicates whether symbols for data points will be created or not. >>>>> * >>>>> * @return true if symbols for data points will be created and false >>>>> otherwise. >>>>> */ >>>>> public final boolean getCreateSymbols() { return >>>>> createSymbols.getValue(); } >>>>> public final void setCreateSymbols(boolean value) { >>>>> createSymbols.setValue(value); } >>>>> public final BooleanProperty createSymbolsProperty() { return >>>>> createSymbols; } >>>>> >>>>> --snip --- >>>>> >>>>> Comments? >>>>> >>>>> 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 >>>> >> >> -- >> Sven Reimers >> >> * Senior Expert Software Architect >> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >> * NetBeans Governance Board Member: >> http://netbeans.org/about/os/governance.html >> >> * 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 >> > > From hang.vo at oracle.com Mon Feb 4 14:48:08 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 04 Feb 2013 22:48:08 +0000 Subject: hg: openjfx/8/graphics/rt: RT-25354 ImagePattern does not track changes Message-ID: <20130204224810.141C047807@hg.openjdk.java.net> Changeset: 41487f55d1d2 Author: "Joseph Andresen" Date: 2013-02-04 14:34 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/41487f55d1d2 RT-25354 ImagePattern does not track changes ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGRegion.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGShape.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-common/src/javafx/scene/ImageCursor.java ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java ! javafx-ui-common/src/javafx/scene/effect/ColorInput.java ! javafx-ui-common/src/javafx/scene/image/Image.java ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/src/javafx/scene/image/WritableImage.java ! javafx-ui-common/src/javafx/scene/paint/Color.java ! javafx-ui-common/src/javafx/scene/paint/ImagePattern.java ! javafx-ui-common/src/javafx/scene/paint/LinearGradient.java ! javafx-ui-common/src/javafx/scene/paint/Paint.java ! javafx-ui-common/src/javafx/scene/paint/RadialGradient.java ! javafx-ui-common/src/javafx/scene/shape/Shape.java ! javafx-ui-common/src/javafx/scene/text/Text.java From richard.bair at oracle.com Mon Feb 4 15:41:12 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 4 Feb 2013 15:41:12 -0800 Subject: Refactoring JavaFX Builds & Sources In-Reply-To: References: <1B3DF0AE-C47D-4EE8-A8CF-58BE0539AC4E@oracle.com> <74671CC2-7BD5-459F-A624-ACB8ADD740D4@gmail.com> <9750123A-8149-4D8A-B08B-1895918F2447@oracle.com> <348E8C76-E2B3-4A9F-A8B7-1E96BCF885D6@gmail.com> <510865A0-64DE-43BE-86E8-83C573DB8172@oracle.com> <3EA241C3-80EF-496F-9BCD-F8DDB15DED11@oracle.com> Message-ID: yes I believe so. On Feb 1, 2013, at 7:06 PM, Danno Ferrin wrote: > Currently it is breaking on the JSL compilers (like CompileBlend). Are those files in the first group? > > On Fri, Feb 1, 2013 at 4:35 PM, Richard Bair wrote: > > Tangent alert: all the rest of the code. > > > > So now that 7u13 is out what are teh remaining gating factors on getting the rest of the OpenJFX stuff out? I am sure the Developer Preview of JDK8 will be consuming alot of bandwidth, but are there any other aspects we should be aware of? > > The rest of the code falls into 1 of 3 categories: > > 1) Code that was waiting for 7u13. This code is now cleared to go out and we should see it come out in the next couple weeks. Artem just about has javafx-embed-swing and javafx-embed-swt ready to go. I think the following will also be ready to go late next week / early week after (but need to double check): > > decora-d3d > decora-jsw > decora-prism > decora-prism-ps > decora-prism-sw > decora-runtime > decora-sse > glass > javafx-beans > javafx-iio > prism-j2d > prism-ps > prism-util > > 2) Code that is still going through the meat grinder. With the security work ongoing, our schedule is being impacted -- some of these may well be able to come sooner and some a little later: > > javafx-ui-quantum > javafx-ui-webnode > prism-common > prism-d3d > prism-sw > webkit > webnode-prism > prism-es2 > prism-es2-eglf > prism-es2-eglx11 > prism-es2-mac > prism-es2-win > prism-es2-x11 > javafx-ui-desktop > media > > 3) Code that won't be opened or needs an open equivalent to be written. > javafx-deploy > javafx-font > > javafx-deploy has applet deployment specific code (the non-applet stuff such as the app co-bundling / javafxpackager code is out / going out). > > javafx-font has the proprietary T2K dependencies. This dependency needs to be replaced so we can then have a fully open build. I want Felipe to prototype an implementation that delegates directly to the native font code for measurement / glyph generation / layout / etc, rather than using Freetype on all platforms. We need to then get performance #'s on this. I want Felipe to work on this in the open source from the start. The only issue here is that Felipe is also fundamentally involved in bug fixing and our backlog is growing quite large. > > That's what I know today. I've emailed the team to find out specifics about those items in #2 above to see if any of them (such as quantum / web node) can get moved into category #1 (or at least make it out by the end of February). > > Some of the embedded related code is tied up in legal approvals and will hopefully be resolved soon. But with legal -- you know how that goes (so prism-es2-eglf, prism-es2-eglx11). However getting the embedded code open is a high priority item so I'm optimistic on it. > > Thanks for the patience, we're going as fast as we can. > > Richard > > > > -- > There is nothing that will hold me back. I know who I am.... > I remember wher I came from, and I feel stronger for knowing. > Zane, Ninja of Ice. Ninjago S01E07 From hang.vo at oracle.com Mon Feb 4 16:48:02 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Feb 2013 00:48:02 +0000 Subject: hg: openjfx/8/controls/rt: RT-23123 autoranging lead to charts incorrect appearance Message-ID: <20130205004806.5636C4780A@hg.openjdk.java.net> Changeset: 38b3163d69ac Author: Paru Somashekar Date: 2013-02-04 16:52 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/38b3163d69ac RT-23123 autoranging lead to charts incorrect appearance ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java From hang.vo at oracle.com Mon Feb 4 18:03:23 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Feb 2013 02:03:23 +0000 Subject: hg: openjfx/8/graphics/rt: Fix tests broken by fix for RT-25354 Message-ID: <20130205020326.C06114780C@hg.openjdk.java.net> Changeset: 254f69a9f5d5 Author: flar Date: 2013-02-04 17:59 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/254f69a9f5d5 Fix tests broken by fix for RT-25354 ! javafx-ui-common/test/unit/javafx/scene/effect/ColorInputTest.java ! javafx-ui-common/test/unit/javafx/scene/image/ImageTest.java ! javafx-ui-common/test/unit/javafx/scene/paint/ImagePatternTest.java ! javafx-ui-common/test/unit/javafx/scene/paint/LinearGradientTest.java ! javafx-ui-common/test/unit/javafx/scene/paint/RadialGradientTest.java From james.graham at oracle.com Mon Feb 4 18:06:46 2013 From: james.graham at oracle.com (Jim Graham) Date: Mon, 04 Feb 2013 18:06:46 -0800 Subject: StubToolkit must go! In-Reply-To: <993F6F47-AF3C-4BFA-B6B7-405EEEEEAC7E@oracle.com> References: <60A32258-24E3-4E27-A1E1-7E50C60EB5E3@oracle.com> <510F7F67.3020408@oracle.com> <993F6F47-AF3C-4BFA-B6B7-405EEEEEAC7E@oracle.com> Message-ID: <51106936.8080308@oracle.com> The problem with this approach is that you are testing PolygonMock instead of Polygon. Any bugs in the impl_ methods are untestable when you override them, and any future changes to Polygon which modify the way that the impl_ methods are used may introduce bugs that do not impact the testing you do with your Mock version because it hides those changes. Also, the impl_ methods are being slowly removed in favor of the Accessor paradigm. Many impl_ methods have already disappeared. These public implementation methods have always been a hack and they are currently only public (and overridable) because we haven't switched over to a better (and easier to keep secure in the long run) paradigm. Your testing methodology would require us to maintain implementation only methods as public interfaces which we are trying to move away from. If you are going to black box test the UI classes then you must treat them as a black box - that means using an external interface that is supported to instrument the testing. The only supported external interface we have is the Toolkit interface and the PG interfaces so you must continue to work behind those interfaces and evolve them if testing needs more instrumentation or you aren't really testing the UI classes, you are testing an approximation of them... ...jim On 2/4/13 7:41 AM, Richard Bair wrote: > Hi Pavel, > > Removing StubToolkit _does not imply_ that we have to test with a live toolkit / glass. For example, the PolygonTest wants to test that during synchronization the array of floats it expected to be passed to the peer is the actual set that got passed. > > @Test public void testBounds_oddPointsLength() { > final double[] initialPoints = { > 100, 100, 200, 100, 200, 200, 150, 300 > }; > > final Polygon polygon = new PolygonMock(initialPoints); > assertBoundsEqual(box(100, 100, 100, 200), polygon.getBoundsInLocal()); > > final ObservableList polygonPoints = polygon.getPoints(); > polygonPoints.remove(6); > > assertBoundsEqual(box(100, 100, 100, 100), polygon.getBoundsInLocal()); > } > > > This can easily be done by using a special subclass of Polygon that, in impl_createPGNode, creates a special subclass of NGPolygon: > > private static final class PolygonMock extends Polygon { > public PolygonMock() { > super(); > } > > public PolygonMock(double... points) { > super(points); > } > > @Override protected PGNode impl_createPGNode() { > return new StubPolygon(); > } > } > > private static final class StubPolygon extends NGPolygon { > float[] points; > @Override public void updatePolygon(float[] points) { > this.points = points; > super.updatePolygon(points); > } > } > > > Running this test does not require that we fire up multiple threads or open a glass window etc. > > I haven't finished combing through all the usages of StubToolkit, but I'm confident we can remove it without changing the nature of the tests. > > Richard > > On Feb 4, 2013, at 1:29 AM, Pavel Safrata wrote: > >> Hi Richard, >> I strongly object. I've had this discussion with Kevin a year ago, quoting myself from the old discussion: >> >> Scenegraph unit tests are there to test scenegraph. I believe that unit tests should by their definition test single units isolated from the rest of the system, not the system as a whole - for this we should have functional tests developed by QA. Our tests make sure that scenegraph works correctly given that the underlying platform behaves as expected. Including live toolkit/glass in running the tests would IMHO seriously damage purpose of those tests - they wouldn't give any reliable evidence of scenegraph's stability any more. Other important thing is that the code doesn't change over time (so it tests regressions in scenegraph) and also the test can make it behave in more different ways (and test scenegraph robustness). >> >> Thanks, >> Pavel >> >> On 2.2.2013 1:11, Richard Bair wrote: >>> Well, at least that is what I'm hoping to do. The problem is that we have a bunch of unit tests. 20K+. Some of them rely on StubToolkit, some of them rely on the real deal. In the "source cleanup" operation I'm on, when we combine all the "graphics" tests together, we have a problem where these two different types of tests are together and one set will fail to execute depending on whether we launch with the real toolkit or the stub toolkit. >>> >>> My plan is to yank out StubToolkit and update all the tests that relied on it to instead work with the real toolkit (quantum and prism). I suspect this is going to be painful. >>> >>> Richard >> > From swpalmer at gmail.com Mon Feb 4 19:00:18 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 4 Feb 2013 22:00:18 -0500 Subject: [API Review] RT-24916 - TableView.scrollTo(TableColumn) In-Reply-To: <511013BF.6000100@oracle.com> References: <510F7065.3020101@bestsolution.at> <510F9553.3060408@xs4all.nl> <511013BF.6000100@oracle.com> Message-ID: We shouldn't add an API for exact positioning to ListView or TableView. ScrollPane already has this... If the implicit ScrollPane in these controls were exposed, we could have all sorts of fun. Scott On 2013-02-04, at 3:02 PM, Jonathan Giles wrote: > This is a fair comment: scrollTo has been designed with a 'fire-and-forget' approach in mind, but I would be loath to add a means of requesting a self-correcting scrollTo function. Wouldn't a suitable workaround be to call scrollTo after the image loading has completed in all cells? > > Regarding a lower-level API for exact positioning, please file a jira tweak request. > > Thanks, > -- Jonathan > > On 5/02/2013 12:02 a.m., John Hendrikx wrote: >> Hi, >> >> I'm not specifically commenting on this API, but I do would like to comment on the usefulness of scrollTo() in general. >> >> I've found that scrollTo() is very unreliable when cells are not fixed-height, and are still in flux (ie, images being loaded in the background) after the call to scrollTo(). Basically, what is happening is: >> >> 1) Create control, populate model >> 2) Call scrollTo() / focus() to restore the previous position the user left the control/cursor at >> 3) More images get loaded, cells change height and the View moves accordingly but completely ignores the last scrollTo() call and currently focused cell and ends up at some random location (with the focused item often not even in View). >> 4) User has to take a navigation action to get the focused item visible again >> >> I donot know of any acceptable work-arounds, as the problem is mainly that the scrollTo() call is a fire-and-forget type action that will be completely lost when Cells are still in flux. What it should do is remember this position and keep adjusting the View when no other form of input overrides the current location (keyboard, mouse scrolling, scrollbars). >> >> Furthermore, scrollTo(), although a nice high level API, does not allow me to "return" to an exact previous state (where the exact scroll position of the control is restored). I'd have to keep the control in memory to be able to provide this functionality, instead of just creating it when needed and positioning it back to where it was. This occurs for example when Views are used for navigation purposes where when an item is selected a different set of items is displayed. Navigating back restores the previous set of items, but unfortunately not the exact position the user came from. >> >> All this is currently leading me into the direction of reskinning the TreeView control, with the goal of providing reliable and stable behavior when it comes to dealing with cells that are in flux. >> >> --John >> >> On 04/02/2013 09:25, Tom Schindl wrote: >>> hi, >>> >>> We (Jonathan and myself) are requesting an API review to add the >>> following public APIs: >>> >>> New APIS: >>> --------- >>> * ListView: >>> scrollTo(T) : void >>> >>> * TableView: >>> scrollTo(S) : void >>> scrollToColumn(TableColumn) : void >>> scrollToColumnIndex(int) : void >>> setOnScrollToColumn(EventHandler>>): void >>> getOnScrollToColumn() : EventHandler>> >>> onScrollToColumnProperty(): >>> ObjectProperty>>> >>> >>> * TreeTableView >>> scrollToColumn(TableColumn column) : void >>> scrollToColumnIndex(int columnIndex) : void >>> setOnScrollToColumn(EventHandler>> >>> value) : void >>> getOnScrollToColumn() : EventHandler>> >>> onScrollToColumnProperty() : >>> ObjectProperty>>> >>> >>> * ScrollToEvent: >>> static > scrollToColumn() : >>> EventType> >>> >>> Modified APIS: >>> -------------- >>> To align better we'd like to change the ScrollToEvent-API to be >>> consitent and use static accessor methods instead of public static fields: >>> * SCROLL_TO_NODE => scrollToNode() : EventType> >>> * SCROLL_TO_TOP_INDEX => scrollToTopIndex() : >>> EventType> >>> >>> >>> Thanks >>> >>> Jonathan + Tom >>> >> > From swpalmer at gmail.com Mon Feb 4 19:02:26 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 4 Feb 2013 22:02:26 -0500 Subject: SceneBuilder src, or how to drag/size controls In-Reply-To: <03984064-67DE-4A15-AABD-B5ABBFF16EB0@oracle.com> References: <51100F7E.2010603@media-interactive.de> <03984064-67DE-4A15-AABD-B5ABBFF16EB0@oracle.com> Message-ID: <74226571-B2AC-4886-9719-3F62516F076B@gmail.com> Is expected to be included in the Open Sourcing efforts, or is the plan for it to remain closed source? Scott On 2013-02-04, at 3:15 PM, Joe McGlynn wrote: > SceneBuilder is not available in source form, sorry. > > > On Feb 4, 2013, at 11:43 AM, Werner Lehmann wrote: > >> Hi, >> >> for an upcoming project I'll need to provide a subset of the SceneBuilder functionality. More specifically, controls such as a Label or TextField need to be dragged from a tool palette into a designing area where they can be selected, moved, and resized. >> >> Is the SceneBuilder src available? Otherwise, any recommendations on do's and dont's? Fortunately this week's links on FX-Experience include a just-in-time article on resizing regions: >> >>> http://andrewtill.blogspot.co.nz/2012/12/dragging-to-resize-javafx-region.html >> (Thanks, Andrew) >> >> Region would be interesting for custom "tools" but I'll need this for standard controls, too. Maybe I should wrap each of them into a stackpane to provide a clickable selection border with drag points? >> >> Rgds >> Werner > From jonathan.giles at oracle.com Mon Feb 4 19:05:35 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 05 Feb 2013 16:05:35 +1300 Subject: [API Review] RT-24916 - TableView.scrollTo(TableColumn) In-Reply-To: References: <510F7065.3020101@bestsolution.at> <510F9553.3060408@xs4all.nl> <511013BF.6000100@oracle.com> Message-ID: <511076FF.2010108@oracle.com> Unfortunately it is a little bit more complex than this - ListView, TreeView, TableView, and TreeTableView are all virtualised and do not use ScrollPane internally, and certainly I don't want to expose the actual internal implementation (it is rather complex). Therefore I'd rather have a discussion (probably best via Jira) on what API is desired in these controls. The kind of feature requests I occasionally hear include: * Support for determining what cell is at a given x/y position (for mouse input) * Support for getting the current x/y scroll position (as an offset from (0,0)) * Support for setting the x/y scroll position (as an offset from (0,0)) -- Jonathan On 5/02/2013 4:00 p.m., Scott Palmer wrote: > We shouldn't add an API for exact positioning to ListView or TableView. ScrollPane already has this... If the implicit ScrollPane in these controls were exposed, we could have all sorts of fun. > > Scott > > On 2013-02-04, at 3:02 PM, Jonathan Giles wrote: > >> This is a fair comment: scrollTo has been designed with a 'fire-and-forget' approach in mind, but I would be loath to add a means of requesting a self-correcting scrollTo function. Wouldn't a suitable workaround be to call scrollTo after the image loading has completed in all cells? >> >> Regarding a lower-level API for exact positioning, please file a jira tweak request. >> >> Thanks, >> -- Jonathan >> >> On 5/02/2013 12:02 a.m., John Hendrikx wrote: >>> Hi, >>> >>> I'm not specifically commenting on this API, but I do would like to comment on the usefulness of scrollTo() in general. >>> >>> I've found that scrollTo() is very unreliable when cells are not fixed-height, and are still in flux (ie, images being loaded in the background) after the call to scrollTo(). Basically, what is happening is: >>> >>> 1) Create control, populate model >>> 2) Call scrollTo() / focus() to restore the previous position the user left the control/cursor at >>> 3) More images get loaded, cells change height and the View moves accordingly but completely ignores the last scrollTo() call and currently focused cell and ends up at some random location (with the focused item often not even in View). >>> 4) User has to take a navigation action to get the focused item visible again >>> >>> I donot know of any acceptable work-arounds, as the problem is mainly that the scrollTo() call is a fire-and-forget type action that will be completely lost when Cells are still in flux. What it should do is remember this position and keep adjusting the View when no other form of input overrides the current location (keyboard, mouse scrolling, scrollbars). >>> >>> Furthermore, scrollTo(), although a nice high level API, does not allow me to "return" to an exact previous state (where the exact scroll position of the control is restored). I'd have to keep the control in memory to be able to provide this functionality, instead of just creating it when needed and positioning it back to where it was. This occurs for example when Views are used for navigation purposes where when an item is selected a different set of items is displayed. Navigating back restores the previous set of items, but unfortunately not the exact position the user came from. >>> >>> All this is currently leading me into the direction of reskinning the TreeView control, with the goal of providing reliable and stable behavior when it comes to dealing with cells that are in flux. >>> >>> --John >>> >>> On 04/02/2013 09:25, Tom Schindl wrote: >>>> hi, >>>> >>>> We (Jonathan and myself) are requesting an API review to add the >>>> following public APIs: >>>> >>>> New APIS: >>>> --------- >>>> * ListView: >>>> scrollTo(T) : void >>>> >>>> * TableView: >>>> scrollTo(S) : void >>>> scrollToColumn(TableColumn) : void >>>> scrollToColumnIndex(int) : void >>>> setOnScrollToColumn(EventHandler>>): void >>>> getOnScrollToColumn() : EventHandler>> >>>> onScrollToColumnProperty(): >>>> ObjectProperty>>> >>>> >>>> * TreeTableView >>>> scrollToColumn(TableColumn column) : void >>>> scrollToColumnIndex(int columnIndex) : void >>>> setOnScrollToColumn(EventHandler>> >>>> value) : void >>>> getOnScrollToColumn() : EventHandler>> >>>> onScrollToColumnProperty() : >>>> ObjectProperty>>> >>>> >>>> * ScrollToEvent: >>>> static > scrollToColumn() : >>>> EventType> >>>> >>>> Modified APIS: >>>> -------------- >>>> To align better we'd like to change the ScrollToEvent-API to be >>>> consitent and use static accessor methods instead of public static fields: >>>> * SCROLL_TO_NODE => scrollToNode() : EventType> >>>> * SCROLL_TO_TOP_INDEX => scrollToTopIndex() : >>>> EventType> >>>> >>>> >>>> Thanks >>>> >>>> Jonathan + Tom >>>> From swpalmer at gmail.com Mon Feb 4 19:16:04 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 4 Feb 2013 22:16:04 -0500 Subject: [API Review] RT-24916 - TableView.scrollTo(TableColumn) In-Reply-To: <511076FF.2010108@oracle.com> References: <510F7065.3020101@bestsolution.at> <510F9553.3060408@xs4all.nl> <511013BF.6000100@oracle.com> <511076FF.2010108@oracle.com> Message-ID: Interesting.. Though it makes me think: If *you* needed something more complex than ScrollPane for those controls, what makes you think *I* don't need the same? :-) I say this after already implementing my own ScrollPane from scratch via ScrollBars and fancy translations and clipping. (I had to work around some flickering issues in 2.2) The three points you have below seem like a reasonable starting point for that discussion though. Scott On 2013-02-04, at 10:05 PM, Jonathan Giles wrote: > Unfortunately it is a little bit more complex than this - ListView, TreeView, TableView, and TreeTableView are all virtualised and do not use ScrollPane internally, and certainly I don't want to expose the actual internal implementation (it is rather complex). > > Therefore I'd rather have a discussion (probably best via Jira) on what API is desired in these controls. The kind of feature requests I occasionally hear include: > > * Support for determining what cell is at a given x/y position (for mouse input) > * Support for getting the current x/y scroll position (as an offset from (0,0)) > * Support for setting the x/y scroll position (as an offset from (0,0)) > > -- Jonathan > > On 5/02/2013 4:00 p.m., Scott Palmer wrote: >> We shouldn't add an API for exact positioning to ListView or TableView. ScrollPane already has this... If the implicit ScrollPane in these controls were exposed, we could have all sorts of fun. >> >> Scott >> >> On 2013-02-04, at 3:02 PM, Jonathan Giles wrote: >> >>> This is a fair comment: scrollTo has been designed with a 'fire-and-forget' approach in mind, but I would be loath to add a means of requesting a self-correcting scrollTo function. Wouldn't a suitable workaround be to call scrollTo after the image loading has completed in all cells? >>> >>> Regarding a lower-level API for exact positioning, please file a jira tweak request. >>> >>> Thanks, >>> -- Jonathan >>> >>> On 5/02/2013 12:02 a.m., John Hendrikx wrote: >>>> Hi, >>>> >>>> I'm not specifically commenting on this API, but I do would like to comment on the usefulness of scrollTo() in general. >>>> >>>> I've found that scrollTo() is very unreliable when cells are not fixed-height, and are still in flux (ie, images being loaded in the background) after the call to scrollTo(). Basically, what is happening is: >>>> >>>> 1) Create control, populate model >>>> 2) Call scrollTo() / focus() to restore the previous position the user left the control/cursor at >>>> 3) More images get loaded, cells change height and the View moves accordingly but completely ignores the last scrollTo() call and currently focused cell and ends up at some random location (with the focused item often not even in View). >>>> 4) User has to take a navigation action to get the focused item visible again >>>> >>>> I donot know of any acceptable work-arounds, as the problem is mainly that the scrollTo() call is a fire-and-forget type action that will be completely lost when Cells are still in flux. What it should do is remember this position and keep adjusting the View when no other form of input overrides the current location (keyboard, mouse scrolling, scrollbars). >>>> >>>> Furthermore, scrollTo(), although a nice high level API, does not allow me to "return" to an exact previous state (where the exact scroll position of the control is restored). I'd have to keep the control in memory to be able to provide this functionality, instead of just creating it when needed and positioning it back to where it was. This occurs for example when Views are used for navigation purposes where when an item is selected a different set of items is displayed. Navigating back restores the previous set of items, but unfortunately not the exact position the user came from. >>>> >>>> All this is currently leading me into the direction of reskinning the TreeView control, with the goal of providing reliable and stable behavior when it comes to dealing with cells that are in flux. >>>> >>>> --John >>>> >>>> On 04/02/2013 09:25, Tom Schindl wrote: >>>>> hi, >>>>> >>>>> We (Jonathan and myself) are requesting an API review to add the >>>>> following public APIs: >>>>> >>>>> New APIS: >>>>> --------- >>>>> * ListView: >>>>> scrollTo(T) : void >>>>> >>>>> * TableView: >>>>> scrollTo(S) : void >>>>> scrollToColumn(TableColumn) : void >>>>> scrollToColumnIndex(int) : void >>>>> setOnScrollToColumn(EventHandler>>): void >>>>> getOnScrollToColumn() : EventHandler>> >>>>> onScrollToColumnProperty(): >>>>> ObjectProperty>>> >>>>> >>>>> * TreeTableView >>>>> scrollToColumn(TableColumn column) : void >>>>> scrollToColumnIndex(int columnIndex) : void >>>>> setOnScrollToColumn(EventHandler>> >>>>> value) : void >>>>> getOnScrollToColumn() : EventHandler>> >>>>> onScrollToColumnProperty() : >>>>> ObjectProperty>>> >>>>> >>>>> * ScrollToEvent: >>>>> static > scrollToColumn() : >>>>> EventType> >>>>> >>>>> Modified APIS: >>>>> -------------- >>>>> To align better we'd like to change the ScrollToEvent-API to be >>>>> consitent and use static accessor methods instead of public static fields: >>>>> * SCROLL_TO_NODE => scrollToNode() : EventType> >>>>> * SCROLL_TO_TOP_INDEX => scrollToTopIndex() : >>>>> EventType> >>>>> >>>>> >>>>> Thanks >>>>> >>>>> Jonathan + Tom >>>>> > From jonathan.giles at oracle.com Mon Feb 4 19:21:57 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 05 Feb 2013 16:21:57 +1300 Subject: [API Review] RT-24916 - TableView.scrollTo(TableColumn) In-Reply-To: References: <510F7065.3020101@bestsolution.at> <510F9553.3060408@xs4all.nl> <511013BF.6000100@oracle.com> <511076FF.2010108@oracle.com> Message-ID: <51107AD5.3010007@oracle.com> ScrollPane is a general purpose container to allow for scrolling a larger item within a smaller viewport - what we need internally for list/tree/table/treetable is a very specialised container for very performant and memory efficient layout of cells. In other words, you're putting words in my mouth if you're claiming that I said ScrollPane is the solution for every scrollpane-like requirement! :-) Use it if it suits your requirements, and roll your own if it doesn't. I would not suggest using the implementation we use for the virtualised controls as it will almost certainly be overkill unless you're looking to do something very similar to what is done in the virtualised controls. Anywho, regarding the API for scrollTo, lets take that to Jira to thrash out rather than bother everyone on list. -- Jonathan On 5/02/2013 4:16 p.m., Scott Palmer wrote: > Interesting.. Though it makes me think: If *you* needed something more complex than ScrollPane for those controls, what makes you think *I* don't need the same? > :-) > I say this after already implementing my own ScrollPane from scratch via ScrollBars and fancy translations and clipping. (I had to work around some flickering issues in 2.2) > > The three points you have below seem like a reasonable starting point for that discussion though. > > Scott > > On 2013-02-04, at 10:05 PM, Jonathan Giles wrote: > >> Unfortunately it is a little bit more complex than this - ListView, TreeView, TableView, and TreeTableView are all virtualised and do not use ScrollPane internally, and certainly I don't want to expose the actual internal implementation (it is rather complex). >> >> Therefore I'd rather have a discussion (probably best via Jira) on what API is desired in these controls. The kind of feature requests I occasionally hear include: >> >> * Support for determining what cell is at a given x/y position (for mouse input) >> * Support for getting the current x/y scroll position (as an offset from (0,0)) >> * Support for setting the x/y scroll position (as an offset from (0,0)) >> >> -- Jonathan >> >> On 5/02/2013 4:00 p.m., Scott Palmer wrote: >>> We shouldn't add an API for exact positioning to ListView or TableView. ScrollPane already has this... If the implicit ScrollPane in these controls were exposed, we could have all sorts of fun. >>> >>> Scott >>> >>> On 2013-02-04, at 3:02 PM, Jonathan Giles wrote: >>> >>>> This is a fair comment: scrollTo has been designed with a 'fire-and-forget' approach in mind, but I would be loath to add a means of requesting a self-correcting scrollTo function. Wouldn't a suitable workaround be to call scrollTo after the image loading has completed in all cells? >>>> >>>> Regarding a lower-level API for exact positioning, please file a jira tweak request. >>>> >>>> Thanks, >>>> -- Jonathan >>>> >>>> On 5/02/2013 12:02 a.m., John Hendrikx wrote: >>>>> Hi, >>>>> >>>>> I'm not specifically commenting on this API, but I do would like to comment on the usefulness of scrollTo() in general. >>>>> >>>>> I've found that scrollTo() is very unreliable when cells are not fixed-height, and are still in flux (ie, images being loaded in the background) after the call to scrollTo(). Basically, what is happening is: >>>>> >>>>> 1) Create control, populate model >>>>> 2) Call scrollTo() / focus() to restore the previous position the user left the control/cursor at >>>>> 3) More images get loaded, cells change height and the View moves accordingly but completely ignores the last scrollTo() call and currently focused cell and ends up at some random location (with the focused item often not even in View). >>>>> 4) User has to take a navigation action to get the focused item visible again >>>>> >>>>> I donot know of any acceptable work-arounds, as the problem is mainly that the scrollTo() call is a fire-and-forget type action that will be completely lost when Cells are still in flux. What it should do is remember this position and keep adjusting the View when no other form of input overrides the current location (keyboard, mouse scrolling, scrollbars). >>>>> >>>>> Furthermore, scrollTo(), although a nice high level API, does not allow me to "return" to an exact previous state (where the exact scroll position of the control is restored). I'd have to keep the control in memory to be able to provide this functionality, instead of just creating it when needed and positioning it back to where it was. This occurs for example when Views are used for navigation purposes where when an item is selected a different set of items is displayed. Navigating back restores the previous set of items, but unfortunately not the exact position the user came from. >>>>> >>>>> All this is currently leading me into the direction of reskinning the TreeView control, with the goal of providing reliable and stable behavior when it comes to dealing with cells that are in flux. >>>>> >>>>> --John >>>>> >>>>> On 04/02/2013 09:25, Tom Schindl wrote: >>>>>> hi, >>>>>> >>>>>> We (Jonathan and myself) are requesting an API review to add the >>>>>> following public APIs: >>>>>> >>>>>> New APIS: >>>>>> --------- >>>>>> * ListView: >>>>>> scrollTo(T) : void >>>>>> >>>>>> * TableView: >>>>>> scrollTo(S) : void >>>>>> scrollToColumn(TableColumn) : void >>>>>> scrollToColumnIndex(int) : void >>>>>> setOnScrollToColumn(EventHandler>>): void >>>>>> getOnScrollToColumn() : EventHandler>> >>>>>> onScrollToColumnProperty(): >>>>>> ObjectProperty>>> >>>>>> >>>>>> * TreeTableView >>>>>> scrollToColumn(TableColumn column) : void >>>>>> scrollToColumnIndex(int columnIndex) : void >>>>>> setOnScrollToColumn(EventHandler>> >>>>>> value) : void >>>>>> getOnScrollToColumn() : EventHandler>> >>>>>> onScrollToColumnProperty() : >>>>>> ObjectProperty>>> >>>>>> >>>>>> * ScrollToEvent: >>>>>> static > scrollToColumn() : >>>>>> EventType> >>>>>> >>>>>> Modified APIS: >>>>>> -------------- >>>>>> To align better we'd like to change the ScrollToEvent-API to be >>>>>> consitent and use static accessor methods instead of public static fields: >>>>>> * SCROLL_TO_NODE => scrollToNode() : EventType> >>>>>> * SCROLL_TO_TOP_INDEX => scrollToTopIndex() : >>>>>> EventType> >>>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> Jonathan + Tom >>>>>> From jonathan.giles at oracle.com Mon Feb 4 19:22:28 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 05 Feb 2013 16:22:28 +1300 Subject: [API Review] RT-24916 - TableView.scrollTo(TableColumn) In-Reply-To: References: <510F7065.3020101@bestsolution.at> <510F9553.3060408@xs4all.nl> <511013BF.6000100@oracle.com> <511076FF.2010108@oracle.com> Message-ID: <51107AF4.7060805@oracle.com> ScrollPane is a general purpose container to allow for scrolling a larger item within a smaller viewport - what we need internally for list/tree/table/treetable is a very specialised container for very performant and memory efficient layout of cells. In other words, you're putting words in my mouth if you're claiming that I said ScrollPane is the solution for every scrollpane-like requirement! :-) Use it if it suits your requirements, and roll your own if it doesn't. I would not suggest using the implementation we use for the virtualised controls as it will almost certainly be overkill unless you're looking to do something very similar to what is done in the virtualised controls. Anywho, regarding the API for scrollTo, lets take that to Jira to thrash out rather than bother everyone on list. And, ideally, it would be great to also have discussion on what Tom proposed in the original email! :-) -- Jonathan On 5/02/2013 4:16 p.m., Scott Palmer wrote: > Interesting.. Though it makes me think: If *you* needed something more complex than ScrollPane for those controls, what makes you think *I* don't need the same? > :-) > I say this after already implementing my own ScrollPane from scratch via ScrollBars and fancy translations and clipping. (I had to work around some flickering issues in 2.2) > > The three points you have below seem like a reasonable starting point for that discussion though. > > Scott > > On 2013-02-04, at 10:05 PM, Jonathan Giles wrote: > >> Unfortunately it is a little bit more complex than this - ListView, TreeView, TableView, and TreeTableView are all virtualised and do not use ScrollPane internally, and certainly I don't want to expose the actual internal implementation (it is rather complex). >> >> Therefore I'd rather have a discussion (probably best via Jira) on what API is desired in these controls. The kind of feature requests I occasionally hear include: >> >> * Support for determining what cell is at a given x/y position (for mouse input) >> * Support for getting the current x/y scroll position (as an offset from (0,0)) >> * Support for setting the x/y scroll position (as an offset from (0,0)) >> >> -- Jonathan >> >> On 5/02/2013 4:00 p.m., Scott Palmer wrote: >>> We shouldn't add an API for exact positioning to ListView or TableView. ScrollPane already has this... If the implicit ScrollPane in these controls were exposed, we could have all sorts of fun. >>> >>> Scott >>> >>> On 2013-02-04, at 3:02 PM, Jonathan Giles wrote: >>> >>>> This is a fair comment: scrollTo has been designed with a 'fire-and-forget' approach in mind, but I would be loath to add a means of requesting a self-correcting scrollTo function. Wouldn't a suitable workaround be to call scrollTo after the image loading has completed in all cells? >>>> >>>> Regarding a lower-level API for exact positioning, please file a jira tweak request. >>>> >>>> Thanks, >>>> -- Jonathan >>>> >>>> On 5/02/2013 12:02 a.m., John Hendrikx wrote: >>>>> Hi, >>>>> >>>>> I'm not specifically commenting on this API, but I do would like to comment on the usefulness of scrollTo() in general. >>>>> >>>>> I've found that scrollTo() is very unreliable when cells are not fixed-height, and are still in flux (ie, images being loaded in the background) after the call to scrollTo(). Basically, what is happening is: >>>>> >>>>> 1) Create control, populate model >>>>> 2) Call scrollTo() / focus() to restore the previous position the user left the control/cursor at >>>>> 3) More images get loaded, cells change height and the View moves accordingly but completely ignores the last scrollTo() call and currently focused cell and ends up at some random location (with the focused item often not even in View). >>>>> 4) User has to take a navigation action to get the focused item visible again >>>>> >>>>> I donot know of any acceptable work-arounds, as the problem is mainly that the scrollTo() call is a fire-and-forget type action that will be completely lost when Cells are still in flux. What it should do is remember this position and keep adjusting the View when no other form of input overrides the current location (keyboard, mouse scrolling, scrollbars). >>>>> >>>>> Furthermore, scrollTo(), although a nice high level API, does not allow me to "return" to an exact previous state (where the exact scroll position of the control is restored). I'd have to keep the control in memory to be able to provide this functionality, instead of just creating it when needed and positioning it back to where it was. This occurs for example when Views are used for navigation purposes where when an item is selected a different set of items is displayed. Navigating back restores the previous set of items, but unfortunately not the exact position the user came from. >>>>> >>>>> All this is currently leading me into the direction of reskinning the TreeView control, with the goal of providing reliable and stable behavior when it comes to dealing with cells that are in flux. >>>>> >>>>> --John >>>>> >>>>> On 04/02/2013 09:25, Tom Schindl wrote: >>>>>> hi, >>>>>> >>>>>> We (Jonathan and myself) are requesting an API review to add the >>>>>> following public APIs: >>>>>> >>>>>> New APIS: >>>>>> --------- >>>>>> * ListView: >>>>>> scrollTo(T) : void >>>>>> >>>>>> * TableView: >>>>>> scrollTo(S) : void >>>>>> scrollToColumn(TableColumn) : void >>>>>> scrollToColumnIndex(int) : void >>>>>> setOnScrollToColumn(EventHandler>>): void >>>>>> getOnScrollToColumn() : EventHandler>> >>>>>> onScrollToColumnProperty(): >>>>>> ObjectProperty>>> >>>>>> >>>>>> * TreeTableView >>>>>> scrollToColumn(TableColumn column) : void >>>>>> scrollToColumnIndex(int columnIndex) : void >>>>>> setOnScrollToColumn(EventHandler>> >>>>>> value) : void >>>>>> getOnScrollToColumn() : EventHandler>> >>>>>> onScrollToColumnProperty() : >>>>>> ObjectProperty>>> >>>>>> >>>>>> * ScrollToEvent: >>>>>> static > scrollToColumn() : >>>>>> EventType> >>>>>> >>>>>> Modified APIS: >>>>>> -------------- >>>>>> To align better we'd like to change the ScrollToEvent-API to be >>>>>> consitent and use static accessor methods instead of public static fields: >>>>>> * SCROLL_TO_NODE => scrollToNode() : EventType> >>>>>> * SCROLL_TO_TOP_INDEX => scrollToTopIndex() : >>>>>> EventType> >>>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> Jonathan + Tom >>>>>> From hang.vo at oracle.com Mon Feb 4 19:32:55 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Feb 2013 03:32:55 +0000 Subject: hg: openjfx/8/controls/rt: 3 new changesets Message-ID: <20130205033301.A07B647814@hg.openjdk.java.net> Changeset: 16b8b81ecfcd Author: jgiles Date: 2013-02-05 11:52 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/16b8b81ecfcd [TEST ONLY] Added unit test for RT-24412 ! javafx-ui-controls/test/javafx/scene/control/ComboBoxTest.java Changeset: 3f20a5e249d9 Author: jgiles Date: 2013-02-05 16:06 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3f20a5e249d9 RT-27852: [TreeView, TreeTableView] expanding/collapsing doesn't work when resetting the root of the TreeView. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeViewSkin.java Changeset: c46edc2e930f Author: jgiles Date: 2013-02-05 16:13 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c46edc2e930f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt From swpalmer at gmail.com Mon Feb 4 19:44:42 2013 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 4 Feb 2013 22:44:42 -0500 Subject: [API Review] RT-24916 - TableView.scrollTo(TableColumn) In-Reply-To: <51107AF4.7060805@oracle.com> References: <510F7065.3020101@bestsolution.at> <510F9553.3060408@xs4all.nl> <511013BF.6000100@oracle.com> <511076FF.2010108@oracle.com> <51107AF4.7060805@oracle.com> Message-ID: Ah.. Got it. This is about dynamically generating the content that "scrolls in" and throwing away the stuff that "scrolls out". I keep forgetting that. (And in my defence I did use a smiley) Is there a Jira issue yet? Scott On 2013-02-04, at 10:22 PM, Jonathan Giles wrote: > ScrollPane is a general purpose container to allow for scrolling a larger item within a smaller viewport - what we need internally for list/tree/table/treetable is a very specialised container for very performant and memory efficient layout of cells. > > In other words, you're putting words in my mouth if you're claiming that I said ScrollPane is the solution for every scrollpane-like requirement! :-) Use it if it suits your requirements, and roll your own if it doesn't. I would not suggest using the implementation we use for the virtualised controls as it will almost certainly be overkill unless you're looking to do something very similar to what is done in the virtualised controls. > > Anywho, regarding the API for scrollTo, lets take that to Jira to thrash out rather than bother everyone on list. > > And, ideally, it would be great to also have discussion on what Tom proposed in the original email! :-) > > -- Jonathan > > On 5/02/2013 4:16 p.m., Scott Palmer wrote: >> Interesting.. Though it makes me think: If *you* needed something more complex than ScrollPane for those controls, what makes you think *I* don't need the same? >> :-) >> I say this after already implementing my own ScrollPane from scratch via ScrollBars and fancy translations and clipping. (I had to work around some flickering issues in 2.2) >> >> The three points you have below seem like a reasonable starting point for that discussion though. >> >> Scott >> >> On 2013-02-04, at 10:05 PM, Jonathan Giles wrote: >> >>> Unfortunately it is a little bit more complex than this - ListView, TreeView, TableView, and TreeTableView are all virtualised and do not use ScrollPane internally, and certainly I don't want to expose the actual internal implementation (it is rather complex). >>> >>> Therefore I'd rather have a discussion (probably best via Jira) on what API is desired in these controls. The kind of feature requests I occasionally hear include: >>> >>> * Support for determining what cell is at a given x/y position (for mouse input) >>> * Support for getting the current x/y scroll position (as an offset from (0,0)) >>> * Support for setting the x/y scroll position (as an offset from (0,0)) >>> >>> -- Jonathan >>> >>> On 5/02/2013 4:00 p.m., Scott Palmer wrote: >>>> We shouldn't add an API for exact positioning to ListView or TableView. ScrollPane already has this... If the implicit ScrollPane in these controls were exposed, we could have all sorts of fun. >>>> >>>> Scott >>>> >>>> On 2013-02-04, at 3:02 PM, Jonathan Giles wrote: >>>> >>>>> This is a fair comment: scrollTo has been designed with a 'fire-and-forget' approach in mind, but I would be loath to add a means of requesting a self-correcting scrollTo function. Wouldn't a suitable workaround be to call scrollTo after the image loading has completed in all cells? >>>>> >>>>> Regarding a lower-level API for exact positioning, please file a jira tweak request. >>>>> >>>>> Thanks, >>>>> -- Jonathan >>>>> >>>>> On 5/02/2013 12:02 a.m., John Hendrikx wrote: >>>>>> Hi, >>>>>> >>>>>> I'm not specifically commenting on this API, but I do would like to comment on the usefulness of scrollTo() in general. >>>>>> >>>>>> I've found that scrollTo() is very unreliable when cells are not fixed-height, and are still in flux (ie, images being loaded in the background) after the call to scrollTo(). Basically, what is happening is: >>>>>> >>>>>> 1) Create control, populate model >>>>>> 2) Call scrollTo() / focus() to restore the previous position the user left the control/cursor at >>>>>> 3) More images get loaded, cells change height and the View moves accordingly but completely ignores the last scrollTo() call and currently focused cell and ends up at some random location (with the focused item often not even in View). >>>>>> 4) User has to take a navigation action to get the focused item visible again >>>>>> >>>>>> I donot know of any acceptable work-arounds, as the problem is mainly that the scrollTo() call is a fire-and-forget type action that will be completely lost when Cells are still in flux. What it should do is remember this position and keep adjusting the View when no other form of input overrides the current location (keyboard, mouse scrolling, scrollbars). >>>>>> >>>>>> Furthermore, scrollTo(), although a nice high level API, does not allow me to "return" to an exact previous state (where the exact scroll position of the control is restored). I'd have to keep the control in memory to be able to provide this functionality, instead of just creating it when needed and positioning it back to where it was. This occurs for example when Views are used for navigation purposes where when an item is selected a different set of items is displayed. Navigating back restores the previous set of items, but unfortunately not the exact position the user came from. >>>>>> >>>>>> All this is currently leading me into the direction of reskinning the TreeView control, with the goal of providing reliable and stable behavior when it comes to dealing with cells that are in flux. >>>>>> >>>>>> --John >>>>>> >>>>>> On 04/02/2013 09:25, Tom Schindl wrote: >>>>>>> hi, >>>>>>> >>>>>>> We (Jonathan and myself) are requesting an API review to add the >>>>>>> following public APIs: >>>>>>> >>>>>>> New APIS: >>>>>>> --------- >>>>>>> * ListView: >>>>>>> scrollTo(T) : void >>>>>>> >>>>>>> * TableView: >>>>>>> scrollTo(S) : void >>>>>>> scrollToColumn(TableColumn) : void >>>>>>> scrollToColumnIndex(int) : void >>>>>>> setOnScrollToColumn(EventHandler>>): void >>>>>>> getOnScrollToColumn() : EventHandler>> >>>>>>> onScrollToColumnProperty(): >>>>>>> ObjectProperty>>> >>>>>>> >>>>>>> * TreeTableView >>>>>>> scrollToColumn(TableColumn column) : void >>>>>>> scrollToColumnIndex(int columnIndex) : void >>>>>>> setOnScrollToColumn(EventHandler>> >>>>>>> value) : void >>>>>>> getOnScrollToColumn() : EventHandler>> >>>>>>> onScrollToColumnProperty() : >>>>>>> ObjectProperty>>> >>>>>>> >>>>>>> * ScrollToEvent: >>>>>>> static > scrollToColumn() : >>>>>>> EventType> >>>>>>> >>>>>>> Modified APIS: >>>>>>> -------------- >>>>>>> To align better we'd like to change the ScrollToEvent-API to be >>>>>>> consitent and use static accessor methods instead of public static fields: >>>>>>> * SCROLL_TO_NODE => scrollToNode() : EventType> >>>>>>> * SCROLL_TO_TOP_INDEX => scrollToTopIndex() : >>>>>>> EventType> >>>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Jonathan + Tom > From jonathan.giles at oracle.com Mon Feb 4 19:52:56 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 05 Feb 2013 16:52:56 +1300 Subject: [API Review] RT-24916 - TableView.scrollTo(TableColumn) In-Reply-To: References: <510F7065.3020101@bestsolution.at> <510F9553.3060408@xs4all.nl> <511013BF.6000100@oracle.com> <511076FF.2010108@oracle.com> <51107AF4.7060805@oracle.com> Message-ID: <51108218.5040706@oracle.com> Don't worry, I didn't take any offense - I was just teasing :-) There is a multitude of Jira issues related to this. Unfortunately digging them all up now would prove rather time-consuming, so I suggest we file a new umbrella tweak request to cover this and as time permits I will link all related jira issues to this umbrella issue (kind of like what I did for sorting [1] and keyboard navigation [2]) [1] http://javafx-jira.kenai.com/browse/RT-19479 [2] http://javafx-jira.kenai.com/browse/RT-27658 -- Jonathan On 5/02/2013 4:44 p.m., Scott Palmer wrote: > Ah.. Got it. This is about dynamically generating the content that "scrolls in" and throwing away the stuff that "scrolls out". I keep forgetting that. (And in my defence I did use a smiley) > > Is there a Jira issue yet? > > Scott > > On 2013-02-04, at 10:22 PM, Jonathan Giles wrote: > >> ScrollPane is a general purpose container to allow for scrolling a larger item within a smaller viewport - what we need internally for list/tree/table/treetable is a very specialised container for very performant and memory efficient layout of cells. >> >> In other words, you're putting words in my mouth if you're claiming that I said ScrollPane is the solution for every scrollpane-like requirement! :-) Use it if it suits your requirements, and roll your own if it doesn't. I would not suggest using the implementation we use for the virtualised controls as it will almost certainly be overkill unless you're looking to do something very similar to what is done in the virtualised controls. >> >> Anywho, regarding the API for scrollTo, lets take that to Jira to thrash out rather than bother everyone on list. >> >> And, ideally, it would be great to also have discussion on what Tom proposed in the original email! :-) >> >> -- Jonathan >> >> On 5/02/2013 4:16 p.m., Scott Palmer wrote: >>> Interesting.. Though it makes me think: If *you* needed something more complex than ScrollPane for those controls, what makes you think *I* don't need the same? >>> :-) >>> I say this after already implementing my own ScrollPane from scratch via ScrollBars and fancy translations and clipping. (I had to work around some flickering issues in 2.2) >>> >>> The three points you have below seem like a reasonable starting point for that discussion though. >>> >>> Scott >>> >>> On 2013-02-04, at 10:05 PM, Jonathan Giles wrote: >>> >>>> Unfortunately it is a little bit more complex than this - ListView, TreeView, TableView, and TreeTableView are all virtualised and do not use ScrollPane internally, and certainly I don't want to expose the actual internal implementation (it is rather complex). >>>> >>>> Therefore I'd rather have a discussion (probably best via Jira) on what API is desired in these controls. The kind of feature requests I occasionally hear include: >>>> >>>> * Support for determining what cell is at a given x/y position (for mouse input) >>>> * Support for getting the current x/y scroll position (as an offset from (0,0)) >>>> * Support for setting the x/y scroll position (as an offset from (0,0)) >>>> >>>> -- Jonathan >>>> >>>> On 5/02/2013 4:00 p.m., Scott Palmer wrote: >>>>> We shouldn't add an API for exact positioning to ListView or TableView. ScrollPane already has this... If the implicit ScrollPane in these controls were exposed, we could have all sorts of fun. >>>>> >>>>> Scott >>>>> >>>>> On 2013-02-04, at 3:02 PM, Jonathan Giles wrote: >>>>> >>>>>> This is a fair comment: scrollTo has been designed with a 'fire-and-forget' approach in mind, but I would be loath to add a means of requesting a self-correcting scrollTo function. Wouldn't a suitable workaround be to call scrollTo after the image loading has completed in all cells? >>>>>> >>>>>> Regarding a lower-level API for exact positioning, please file a jira tweak request. >>>>>> >>>>>> Thanks, >>>>>> -- Jonathan >>>>>> >>>>>> On 5/02/2013 12:02 a.m., John Hendrikx wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'm not specifically commenting on this API, but I do would like to comment on the usefulness of scrollTo() in general. >>>>>>> >>>>>>> I've found that scrollTo() is very unreliable when cells are not fixed-height, and are still in flux (ie, images being loaded in the background) after the call to scrollTo(). Basically, what is happening is: >>>>>>> >>>>>>> 1) Create control, populate model >>>>>>> 2) Call scrollTo() / focus() to restore the previous position the user left the control/cursor at >>>>>>> 3) More images get loaded, cells change height and the View moves accordingly but completely ignores the last scrollTo() call and currently focused cell and ends up at some random location (with the focused item often not even in View). >>>>>>> 4) User has to take a navigation action to get the focused item visible again >>>>>>> >>>>>>> I donot know of any acceptable work-arounds, as the problem is mainly that the scrollTo() call is a fire-and-forget type action that will be completely lost when Cells are still in flux. What it should do is remember this position and keep adjusting the View when no other form of input overrides the current location (keyboard, mouse scrolling, scrollbars). >>>>>>> >>>>>>> Furthermore, scrollTo(), although a nice high level API, does not allow me to "return" to an exact previous state (where the exact scroll position of the control is restored). I'd have to keep the control in memory to be able to provide this functionality, instead of just creating it when needed and positioning it back to where it was. This occurs for example when Views are used for navigation purposes where when an item is selected a different set of items is displayed. Navigating back restores the previous set of items, but unfortunately not the exact position the user came from. >>>>>>> >>>>>>> All this is currently leading me into the direction of reskinning the TreeView control, with the goal of providing reliable and stable behavior when it comes to dealing with cells that are in flux. >>>>>>> >>>>>>> --John >>>>>>> >>>>>>> On 04/02/2013 09:25, Tom Schindl wrote: >>>>>>>> hi, >>>>>>>> >>>>>>>> We (Jonathan and myself) are requesting an API review to add the >>>>>>>> following public APIs: >>>>>>>> >>>>>>>> New APIS: >>>>>>>> --------- >>>>>>>> * ListView: >>>>>>>> scrollTo(T) : void >>>>>>>> >>>>>>>> * TableView: >>>>>>>> scrollTo(S) : void >>>>>>>> scrollToColumn(TableColumn) : void >>>>>>>> scrollToColumnIndex(int) : void >>>>>>>> setOnScrollToColumn(EventHandler>>): void >>>>>>>> getOnScrollToColumn() : EventHandler>> >>>>>>>> onScrollToColumnProperty(): >>>>>>>> ObjectProperty>>> >>>>>>>> >>>>>>>> * TreeTableView >>>>>>>> scrollToColumn(TableColumn column) : void >>>>>>>> scrollToColumnIndex(int columnIndex) : void >>>>>>>> setOnScrollToColumn(EventHandler>> >>>>>>>> value) : void >>>>>>>> getOnScrollToColumn() : EventHandler>> >>>>>>>> onScrollToColumnProperty() : >>>>>>>> ObjectProperty>>> >>>>>>>> >>>>>>>> * ScrollToEvent: >>>>>>>> static > scrollToColumn() : >>>>>>>> EventType> >>>>>>>> >>>>>>>> Modified APIS: >>>>>>>> -------------- >>>>>>>> To align better we'd like to change the ScrollToEvent-API to be >>>>>>>> consitent and use static accessor methods instead of public static fields: >>>>>>>> * SCROLL_TO_NODE => scrollToNode() : EventType> >>>>>>>> * SCROLL_TO_TOP_INDEX => scrollToTopIndex() : >>>>>>>> EventType> >>>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Jonathan + Tom From hjohn at xs4all.nl Mon Feb 4 22:57:18 2013 From: hjohn at xs4all.nl (John Hendrikx) Date: Tue, 05 Feb 2013 07:57:18 +0100 Subject: [API Review] RT-24916 - TableView.scrollTo(TableColumn) In-Reply-To: <511013BF.6000100@oracle.com> References: <510F7065.3020101@bestsolution.at> <510F9553.3060408@xs4all.nl> <511013BF.6000100@oracle.com> Message-ID: <5110AD4E.6010500@xs4all.nl> On 4/02/2013 21:02, Jonathan Giles wrote: > This is a fair comment: scrollTo has been designed with a > 'fire-and-forget' approach in mind, but I would be loath to add a > means of requesting a self-correcting scrollTo function. Wouldn't a > suitable workaround be to call scrollTo after the image loading has > completed in all cells? The problem is that image loading occurs in the background, and it is not really predictable when all of them are completed. In my example application, these images are loaded from a database (when cached) or from the internet when not. It may take 10 seconds before one has been loaded if it wasn't cached. Waiting that long before I restore the position of the view for the user is not acceptable. Also, calling scrollTo may trigger more image loading (as new cells come into view), so I'd have to call it in a loop until no more images are getting loaded... I realize that self-correcting the position seems wierd, but on the other hand, why is the control adjusting position when some cell changes height? Should the View control not take every effort to stay in the same position? In other words, if my last interaction with the View class was to tell it "show me cell 313 nicely centered", and then cells 304-312 change their height, should they not simply be pushed up and out of view and keep my cell 313 centered? I think it should store its "position" not as some absolute Y coordinate (which would change whenever any intermediate cell changes height), but more relative to the cell. ie. the position is cell 313, centered at 45% down from the top of the control. That way when a cell changes, it will try to keep the position stable. I cannot predict when image loading will happen, nor when it will finish. Even if I could, I'd probably have to call scrollTo in a loop for a few times as it would not be acceptable to wait calling it. Also... as soon as I do call it, other cells are likely to scroll into view, triggering more image loading... > Regarding a lower-level API for exact positioning, please file a jira > tweak request. I've filed http://javafx-jira.kenai.com/browse/RT-28192 --John From Claus.Luethje at osys.ch Mon Feb 4 23:09:51 2013 From: Claus.Luethje at osys.ch (Claus Luethje) Date: Tue, 5 Feb 2013 07:09:51 +0000 Subject: [API Review] RT-24916 - TableView.scrollTo(TableColumn) In-Reply-To: <5110AD4E.6010500@xs4all.nl> References: <510F7065.3020101@bestsolution.at> <510F9553.3060408@xs4all.nl> <511013BF.6000100@oracle.com> <5110AD4E.6010500@xs4all.nl> Message-ID: <193FF4ED343AF14F8CDC65B4792C954D1348EE33@Jeri.osys.ch> +1. It makes more sense this way (= keeping the focus of the user). Just my 0.02$ Claus -----Original Message----- From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of John Hendrikx Sent: Dienstag, 5. Februar 2013 07:57 To: jonathan.giles at oracle.com Cc: openjfx-dev at openjdk.java.net Subject: Re: [API Review] RT-24916 - TableView.scrollTo(TableColumn) On 4/02/2013 21:02, Jonathan Giles wrote: > This is a fair comment: scrollTo has been designed with a > 'fire-and-forget' approach in mind, but I would be loath to add a > means of requesting a self-correcting scrollTo function. Wouldn't a > suitable workaround be to call scrollTo after the image loading has > completed in all cells? The problem is that image loading occurs in the background, and it is not really predictable when all of them are completed. In my example application, these images are loaded from a database (when cached) or from the internet when not. It may take 10 seconds before one has been loaded if it wasn't cached. Waiting that long before I restore the position of the view for the user is not acceptable. Also, calling scrollTo may trigger more image loading (as new cells come into view), so I'd have to call it in a loop until no more images are getting loaded... I realize that self-correcting the position seems wierd, but on the other hand, why is the control adjusting position when some cell changes height? Should the View control not take every effort to stay in the same position? In other words, if my last interaction with the View class was to tell it "show me cell 313 nicely centered", and then cells 304-312 change their height, should they not simply be pushed up and out of view and keep my cell 313 centered? I think it should store its "position" not as some absolute Y coordinate (which would change whenever any intermediate cell changes height), but more relative to the cell. ie. the position is cell 313, centered at 45% down from the top of the control. That way when a cell changes, it will try to keep the position stable. I cannot predict when image loading will happen, nor when it will finish. Even if I could, I'd probably have to call scrollTo in a loop for a few times as it would not be acceptable to wait calling it. Also... as soon as I do call it, other cells are likely to scroll into view, triggering more image loading... > Regarding a lower-level API for exact positioning, please file a jira > tweak request. I've filed http://javafx-jira.kenai.com/browse/RT-28192 --John From jonathan.giles at oracle.com Mon Feb 4 23:23:05 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 05 Feb 2013 20:23:05 +1300 Subject: [API Review] RT-24916 - TableView.scrollTo(TableColumn) In-Reply-To: <5110AD4E.6010500@xs4all.nl> References: <510F7065.3020101@bestsolution.at> <510F9553.3060408@xs4all.nl> <511013BF.6000100@oracle.com> <5110AD4E.6010500@xs4all.nl> Message-ID: <5110B359.2000303@oracle.com> On 5/02/2013 7:57 p.m., John Hendrikx wrote: > On 4/02/2013 21:02, Jonathan Giles wrote: >> This is a fair comment: scrollTo has been designed with a >> 'fire-and-forget' approach in mind, but I would be loath to add a >> means of requesting a self-correcting scrollTo function. Wouldn't a >> suitable workaround be to call scrollTo after the image loading has >> completed in all cells? > The problem is that image loading occurs in the background, and it is > not really predictable when all of them are completed. In my example > application, these images are loaded from a database (when cached) or > from the internet when not. It may take 10 seconds before one has > been loaded if it wasn't cached. Waiting that long before I restore > the position of the view for the user is not acceptable. Also, > calling scrollTo may trigger more image loading (as new cells come > into view), so I'd have to call it in a loop until no more images are > getting loaded... I'm confused by this statement (which isn't to say it is wrong, just that I don't see the distinction). Isn't the end result exactly the same whether you (externally) watch the progress of each of your image-loading cells and call scrollTo(index) as each cell completes the loading of the picture versus having code in the virtualisation system to react (internally) as the height of a cell changes (which means having to pay a not-inconsiderable overhead to watch the height of all visible cells in all cases, even when the user has no need for this overhead). Am I missing some nuance of your proposal that works around this? I should note that there is a very fine balancing act that needs to happen in this code between performance and reliability (i.e. pixel perfect scrollTo behavior). It used to be the case that scrollTo would measure the height of every cell down to the specified index, but this was deemed too slow and replaced with a more performant but less reliable algorithm. Striking the right balance is tough. Finally, I am operating far in excess of normal operational capacity, and can not imagine I will have any bandwidth to look at this, realistically, this year. If someone finds that the itch is unbearable, by all means scratch it and send me through the patch file :-). I have found working with external contributors has been very beneficial, so I am more than happy to work with more contributors in areas such as this. I do not mean to dismiss this discussion, I just want to be clear with expectations. -- Jonathan From tom.schindl at bestsolution.at Tue Feb 5 00:38:43 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 05 Feb 2013 09:38:43 +0100 Subject: [API Review] RT-24916 - TableView.scrollTo(TableColumn) In-Reply-To: <5110B359.2000303@oracle.com> References: <510F7065.3020101@bestsolution.at> <510F9553.3060408@xs4all.nl> <511013BF.6000100@oracle.com> <5110AD4E.6010500@xs4all.nl> <5110B359.2000303@oracle.com> Message-ID: <5110C513.1060609@bestsolution.at> I think this whole discussion moved away from the real API review we requested or did I miss how the stuff discussed here would modify the API? So can we get back to discussing this API and get approval or disapproval so that we can move on getting it fixed for JFX8. Tom Am 05.02.13 08:23, schrieb Jonathan Giles: > On 5/02/2013 7:57 p.m., John Hendrikx wrote: >> On 4/02/2013 21:02, Jonathan Giles wrote: >>> This is a fair comment: scrollTo has been designed with a >>> 'fire-and-forget' approach in mind, but I would be loath to add a >>> means of requesting a self-correcting scrollTo function. Wouldn't a >>> suitable workaround be to call scrollTo after the image loading has >>> completed in all cells? >> The problem is that image loading occurs in the background, and it is >> not really predictable when all of them are completed. In my example >> application, these images are loaded from a database (when cached) or >> from the internet when not. It may take 10 seconds before one has >> been loaded if it wasn't cached. Waiting that long before I restore >> the position of the view for the user is not acceptable. Also, >> calling scrollTo may trigger more image loading (as new cells come >> into view), so I'd have to call it in a loop until no more images are >> getting loaded... > > I'm confused by this statement (which isn't to say it is wrong, just > that I don't see the distinction). Isn't the end result exactly the same > whether you (externally) watch the progress of each of your > image-loading cells and call scrollTo(index) as each cell completes the > loading of the picture versus having code in the virtualisation system > to react (internally) as the height of a cell changes (which means > having to pay a not-inconsiderable overhead to watch the height of all > visible cells in all cases, even when the user has no need for this > overhead). Am I missing some nuance of your proposal that works around > this? > > I should note that there is a very fine balancing act that needs to > happen in this code between performance and reliability (i.e. pixel > perfect scrollTo behavior). It used to be the case that scrollTo would > measure the height of every cell down to the specified index, but this > was deemed too slow and replaced with a more performant but less > reliable algorithm. Striking the right balance is tough. > > Finally, I am operating far in excess of normal operational capacity, > and can not imagine I will have any bandwidth to look at this, > realistically, this year. If someone finds that the itch is unbearable, > by all means scratch it and send me through the patch file :-). I have > found working with external contributors has been very beneficial, so I > am more than happy to work with more contributors in areas such as this. > I do not mean to dismiss this discussion, I just want to be clear with > expectations. > > -- Jonathan > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From martin.sladecek at oracle.com Tue Feb 5 00:58:38 2013 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Tue, 05 Feb 2013 09:58:38 +0100 Subject: javafx-beans opensourced Message-ID: <5110C9BE.1020104@oracle.com> Hello, javafx-beans project has just been open-sourced. It contains FX beans, bindings and collections. Regards, -Martin From martin.sladecek at oracle.com Tue Feb 5 01:03:35 2013 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Tue, 05 Feb 2013 10:03:35 +0100 Subject: javafx-beans opensourced In-Reply-To: <5110C9BE.1020104@oracle.com> References: <5110C9BE.1020104@oracle.com> Message-ID: <5110CAE7.4000002@oracle.com> Just a note: the open-source was done through the graphics repository. -Martin On 02/05/2013 09:58 AM, Martin Sladecek wrote: > Hello, > javafx-beans project has just been open-sourced. It contains FX beans, > bindings and collections. > > Regards, > -Martin From hang.vo at oracle.com Tue Feb 5 01:04:15 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Feb 2013 09:04:15 +0000 Subject: hg: openjfx/8/graphics/rt: Open-source of javafx-beans Message-ID: <20130205090419.1F0AB47827@hg.openjdk.java.net> Changeset: 9daaff7ef6d5 Author: Martin Sladecek Date: 2013-02-05 09:47 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9daaff7ef6d5 Open-source of javafx-beans ! build.xml ! common.properties ! javafx-anim/build-closed.xml ! javafx-annotation-processor/build-closed.xml ! javafx-annotation-processor/nbproject/project.xml ! javafx-beans-dt/build-closed.xml ! javafx-beans-dt/project.properties + javafx-beans/build-closed.xml + javafx-beans/build-common.xml + javafx-beans/build.xml + javafx-beans/jar.jardesc + javafx-beans/javafx-beans.iml + javafx-beans/nbproject/project.xml + javafx-beans/project.properties + javafx-beans/src/com/sun/javafx/beans/IDProperty.java + javafx-beans/src/com/sun/javafx/beans/annotations/Default.java + javafx-beans/src/com/sun/javafx/beans/annotations/Delegate.java + javafx-beans/src/com/sun/javafx/beans/annotations/DuplicateInBuilderProperties.java + javafx-beans/src/com/sun/javafx/beans/annotations/NoBuilder.java + javafx-beans/src/com/sun/javafx/beans/annotations/NoInit.java + javafx-beans/src/com/sun/javafx/beans/annotations/NonNull.java + javafx-beans/src/com/sun/javafx/binding/BidirectionalBinding.java + javafx-beans/src/com/sun/javafx/binding/BidirectionalContentBinding.java + javafx-beans/src/com/sun/javafx/binding/BindingHelperObserver.java + javafx-beans/src/com/sun/javafx/binding/ContentBinding.java + javafx-beans/src/com/sun/javafx/binding/DoubleConstant.java + javafx-beans/src/com/sun/javafx/binding/ExpressionHelper.java + javafx-beans/src/com/sun/javafx/binding/ExpressionHelperBase.java + javafx-beans/src/com/sun/javafx/binding/FloatConstant.java + javafx-beans/src/com/sun/javafx/binding/IntegerConstant.java + javafx-beans/src/com/sun/javafx/binding/ListExpressionHelper.java + javafx-beans/src/com/sun/javafx/binding/Logging.java + javafx-beans/src/com/sun/javafx/binding/LongConstant.java + javafx-beans/src/com/sun/javafx/binding/MapExpressionHelper.java + javafx-beans/src/com/sun/javafx/binding/ObjectConstant.java + javafx-beans/src/com/sun/javafx/binding/SelectBinding.java + javafx-beans/src/com/sun/javafx/binding/SetExpressionHelper.java + javafx-beans/src/com/sun/javafx/binding/StringConstant.java + javafx-beans/src/com/sun/javafx/binding/StringFormatter.java + javafx-beans/src/com/sun/javafx/collections/BaseModifiableObservableList.java + javafx-beans/src/com/sun/javafx/collections/BaseObservableList.java + javafx-beans/src/com/sun/javafx/collections/ChangeHelper.java + javafx-beans/src/com/sun/javafx/collections/ElementObservableListDecorator.java + javafx-beans/src/com/sun/javafx/collections/ElementObserver.java + javafx-beans/src/com/sun/javafx/collections/ImmutableObservableList.java + javafx-beans/src/com/sun/javafx/collections/ListChangeBuilder.java + javafx-beans/src/com/sun/javafx/collections/ListListenerHelper.java + javafx-beans/src/com/sun/javafx/collections/MapAdapterChange.java + javafx-beans/src/com/sun/javafx/collections/MapListenerHelper.java + javafx-beans/src/com/sun/javafx/collections/MappingChange.java + javafx-beans/src/com/sun/javafx/collections/NonIterableChange.java + javafx-beans/src/com/sun/javafx/collections/ObservableListWrapper.java + javafx-beans/src/com/sun/javafx/collections/ObservableMapWrapper.java + javafx-beans/src/com/sun/javafx/collections/ObservableSetWrapper.java + javafx-beans/src/com/sun/javafx/collections/SetAdapterChange.java + javafx-beans/src/com/sun/javafx/collections/SetListenerHelper.java + javafx-beans/src/com/sun/javafx/collections/SortHelper.java + javafx-beans/src/com/sun/javafx/collections/SortableList.java + javafx-beans/src/com/sun/javafx/collections/SourceAdapterChange.java + javafx-beans/src/com/sun/javafx/collections/TrackableObservableList.java + javafx-beans/src/com/sun/javafx/collections/UnmodifiableListSet.java + javafx-beans/src/com/sun/javafx/collections/UnmodifiableObservableMap.java + javafx-beans/src/com/sun/javafx/collections/VetoableListDecorator.java + javafx-beans/src/com/sun/javafx/collections/annotations/ReturnsUnmodifiableCollection.java + javafx-beans/src/com/sun/javafx/collections/transformation/FilterableList.java + javafx-beans/src/com/sun/javafx/collections/transformation/FilteredList.java + javafx-beans/src/com/sun/javafx/collections/transformation/Matcher.java + javafx-beans/src/com/sun/javafx/collections/transformation/SortableList.java + javafx-beans/src/com/sun/javafx/collections/transformation/SortedList.java + javafx-beans/src/com/sun/javafx/collections/transformation/TransformationList.java + javafx-beans/src/com/sun/javafx/property/PropertyReference.java + javafx-beans/src/com/sun/javafx/property/adapter/JavaBeanPropertyBuilderHelper.java + javafx-beans/src/com/sun/javafx/property/adapter/PropertyDescriptor.java + javafx-beans/src/com/sun/javafx/property/adapter/ReadOnlyJavaBeanPropertyBuilderHelper.java + javafx-beans/src/com/sun/javafx/property/adapter/ReadOnlyPropertyDescriptor.java + javafx-beans/src/javafx/beans/DefaultProperty.java + javafx-beans/src/javafx/beans/InvalidationListener.java + javafx-beans/src/javafx/beans/Observable.java + javafx-beans/src/javafx/beans/WeakInvalidationListener.java + javafx-beans/src/javafx/beans/WeakListener.java + javafx-beans/src/javafx/beans/binding/Binding.java + javafx-beans/src/javafx/beans/binding/Bindings.java + javafx-beans/src/javafx/beans/binding/BooleanBinding.java + javafx-beans/src/javafx/beans/binding/BooleanExpression.java + javafx-beans/src/javafx/beans/binding/DoubleBinding.java + javafx-beans/src/javafx/beans/binding/DoubleExpression.java + javafx-beans/src/javafx/beans/binding/FloatBinding.java + javafx-beans/src/javafx/beans/binding/FloatExpression.java + javafx-beans/src/javafx/beans/binding/IntegerBinding.java + javafx-beans/src/javafx/beans/binding/IntegerExpression.java + javafx-beans/src/javafx/beans/binding/ListBinding.java + javafx-beans/src/javafx/beans/binding/ListExpression.java + javafx-beans/src/javafx/beans/binding/LongBinding.java + javafx-beans/src/javafx/beans/binding/LongExpression.java + javafx-beans/src/javafx/beans/binding/MapBinding.java + javafx-beans/src/javafx/beans/binding/MapExpression.java + javafx-beans/src/javafx/beans/binding/NumberBinding.java + javafx-beans/src/javafx/beans/binding/NumberExpression.java + javafx-beans/src/javafx/beans/binding/NumberExpressionBase.java + javafx-beans/src/javafx/beans/binding/ObjectBinding.java + javafx-beans/src/javafx/beans/binding/ObjectExpression.java + javafx-beans/src/javafx/beans/binding/SetBinding.java + javafx-beans/src/javafx/beans/binding/SetExpression.java + javafx-beans/src/javafx/beans/binding/StringBinding.java + javafx-beans/src/javafx/beans/binding/StringExpression.java + javafx-beans/src/javafx/beans/binding/When.java + javafx-beans/src/javafx/beans/binding/package.html + javafx-beans/src/javafx/beans/package.html + javafx-beans/src/javafx/beans/property/BooleanProperty.java + javafx-beans/src/javafx/beans/property/BooleanPropertyBase.java + javafx-beans/src/javafx/beans/property/DoubleProperty.java + javafx-beans/src/javafx/beans/property/DoublePropertyBase.java + javafx-beans/src/javafx/beans/property/FloatProperty.java + javafx-beans/src/javafx/beans/property/FloatPropertyBase.java + javafx-beans/src/javafx/beans/property/IntegerProperty.java + javafx-beans/src/javafx/beans/property/IntegerPropertyBase.java + javafx-beans/src/javafx/beans/property/ListProperty.java + javafx-beans/src/javafx/beans/property/ListPropertyBase.java + javafx-beans/src/javafx/beans/property/LongProperty.java + javafx-beans/src/javafx/beans/property/LongPropertyBase.java + javafx-beans/src/javafx/beans/property/MapProperty.java + javafx-beans/src/javafx/beans/property/MapPropertyBase.java + javafx-beans/src/javafx/beans/property/ObjectProperty.java + javafx-beans/src/javafx/beans/property/ObjectPropertyBase.java + javafx-beans/src/javafx/beans/property/Property.java + javafx-beans/src/javafx/beans/property/ReadOnlyBooleanProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyBooleanPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyBooleanWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyDoubleProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyDoublePropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyDoubleWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyFloatProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyFloatPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyFloatWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyIntegerProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyIntegerPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyIntegerWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyListProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyListPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyListWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyLongProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyLongPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyLongWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyMapProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyMapPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyMapWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyObjectProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyObjectPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyObjectWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlySetProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlySetPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlySetWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyStringProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyStringPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyStringWrapper.java + javafx-beans/src/javafx/beans/property/SetProperty.java + javafx-beans/src/javafx/beans/property/SetPropertyBase.java + javafx-beans/src/javafx/beans/property/SimpleBooleanProperty.java + javafx-beans/src/javafx/beans/property/SimpleDoubleProperty.java + javafx-beans/src/javafx/beans/property/SimpleFloatProperty.java + javafx-beans/src/javafx/beans/property/SimpleIntegerProperty.java + javafx-beans/src/javafx/beans/property/SimpleListProperty.java + javafx-beans/src/javafx/beans/property/SimpleLongProperty.java + javafx-beans/src/javafx/beans/property/SimpleMapProperty.java + javafx-beans/src/javafx/beans/property/SimpleObjectProperty.java + javafx-beans/src/javafx/beans/property/SimpleSetProperty.java + javafx-beans/src/javafx/beans/property/SimpleStringProperty.java + javafx-beans/src/javafx/beans/property/StringProperty.java + javafx-beans/src/javafx/beans/property/StringPropertyBase.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanBooleanProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanBooleanPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanDoubleProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanDoublePropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanFloatProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanFloatPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanIntegerProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanIntegerPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanLongProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanLongPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanObjectProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanObjectPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanStringProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanStringPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanBooleanProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanBooleanPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanDoubleProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanDoublePropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanFloatProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanFloatPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanIntegerProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanIntegerPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanLongProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanLongPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanObjectProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanObjectPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanStringProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanStringPropertyBuilder.java + javafx-beans/src/javafx/beans/property/package.html + javafx-beans/src/javafx/beans/value/ChangeListener.java + javafx-beans/src/javafx/beans/value/ObservableBooleanValue.java + javafx-beans/src/javafx/beans/value/ObservableDoubleValue.java + javafx-beans/src/javafx/beans/value/ObservableFloatValue.java + javafx-beans/src/javafx/beans/value/ObservableIntegerValue.java + javafx-beans/src/javafx/beans/value/ObservableListValue.java + javafx-beans/src/javafx/beans/value/ObservableLongValue.java + javafx-beans/src/javafx/beans/value/ObservableMapValue.java + javafx-beans/src/javafx/beans/value/ObservableNumberValue.java + javafx-beans/src/javafx/beans/value/ObservableObjectValue.java + javafx-beans/src/javafx/beans/value/ObservableSetValue.java + javafx-beans/src/javafx/beans/value/ObservableStringValue.java + javafx-beans/src/javafx/beans/value/ObservableValue.java + javafx-beans/src/javafx/beans/value/ObservableValueBase.java + javafx-beans/src/javafx/beans/value/WeakChangeListener.java + javafx-beans/src/javafx/beans/value/WritableBooleanValue.java + javafx-beans/src/javafx/beans/value/WritableDoubleValue.java + javafx-beans/src/javafx/beans/value/WritableFloatValue.java + javafx-beans/src/javafx/beans/value/WritableIntegerValue.java + javafx-beans/src/javafx/beans/value/WritableListValue.java + javafx-beans/src/javafx/beans/value/WritableLongValue.java + javafx-beans/src/javafx/beans/value/WritableMapValue.java + javafx-beans/src/javafx/beans/value/WritableNumberValue.java + javafx-beans/src/javafx/beans/value/WritableObjectValue.java + javafx-beans/src/javafx/beans/value/WritableSetValue.java + javafx-beans/src/javafx/beans/value/WritableStringValue.java + javafx-beans/src/javafx/beans/value/WritableValue.java + javafx-beans/src/javafx/beans/value/package.html + javafx-beans/src/javafx/collections/FXCollections.java + javafx-beans/src/javafx/collections/ListChangeListener.java + javafx-beans/src/javafx/collections/MapChangeListener.java + javafx-beans/src/javafx/collections/ObservableList.java + javafx-beans/src/javafx/collections/ObservableMap.java + javafx-beans/src/javafx/collections/ObservableSet.java + javafx-beans/src/javafx/collections/SetChangeListener.java + javafx-beans/src/javafx/collections/WeakListChangeListener.java + javafx-beans/src/javafx/collections/WeakMapChangeListener.java + javafx-beans/src/javafx/collections/WeakSetChangeListener.java + javafx-beans/src/javafx/collections/package.html + javafx-beans/test/com/sun/javafx/binding/BidirectionalBindingTest.java + javafx-beans/test/com/sun/javafx/binding/BidirectionalBindingWithConversionTest.java + javafx-beans/test/com/sun/javafx/binding/BidirectionalContentBindingListTest.java + javafx-beans/test/com/sun/javafx/binding/BidirectionalContentBindingMapTest.java + javafx-beans/test/com/sun/javafx/binding/BidirectionalContentBindingSetTest.java + javafx-beans/test/com/sun/javafx/binding/ContentBindingListTest.java + javafx-beans/test/com/sun/javafx/binding/ContentBindingMapTest.java + javafx-beans/test/com/sun/javafx/binding/ContentBindingSetTest.java + javafx-beans/test/com/sun/javafx/binding/ErrorLoggingUtiltity.java + javafx-beans/test/com/sun/javafx/binding/ExpressionHelperBaseTest.java + javafx-beans/test/com/sun/javafx/binding/ExpressionHelperTest.java + javafx-beans/test/com/sun/javafx/binding/ExpressionHelperUtility.java + javafx-beans/test/com/sun/javafx/binding/ExpressionHelperUtilityTest.java + javafx-beans/test/com/sun/javafx/binding/ListExpressionHelperTest.java + javafx-beans/test/com/sun/javafx/binding/SelectBindingTest.java + javafx-beans/test/com/sun/javafx/binding/StringFormatterTest.java + javafx-beans/test/com/sun/javafx/collections/ListChangeBuilderTest.java + javafx-beans/test/com/sun/javafx/collections/ListListenerHelperTest.java + javafx-beans/test/com/sun/javafx/collections/MapListenerHelperTest.java + javafx-beans/test/com/sun/javafx/collections/SetListenerHelperTest.java + javafx-beans/test/com/sun/javafx/property/adapter/JavaBeanPropertyBuilderHelperTest.java + javafx-beans/test/com/sun/javafx/property/adapter/PropertyDescriptorTest.java + javafx-beans/test/com/sun/javafx/property/adapter/ReadOnlyPropertyDescriptorTest.java + javafx-beans/test/javafx/beans/Foo.java + javafx-beans/test/javafx/beans/InvalidationListenerMock.java + javafx-beans/test/javafx/beans/Person.java + javafx-beans/test/javafx/beans/WeakInvalidationListenerMock.java + javafx-beans/test/javafx/beans/WeakInvalidationListenerTest.java + javafx-beans/test/javafx/beans/property/BooleanPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/BooleanPropertyTest.java + javafx-beans/test/javafx/beans/property/DoublePropertyBaseTest.java + javafx-beans/test/javafx/beans/property/DoublePropertyTest.java + javafx-beans/test/javafx/beans/property/FloatPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/FloatPropertyTest.java + javafx-beans/test/javafx/beans/property/IntegerPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/IntegerPropertyTest.java + javafx-beans/test/javafx/beans/property/ListPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ListPropertyTest.java + javafx-beans/test/javafx/beans/property/LongPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/LongPropertyTest.java + javafx-beans/test/javafx/beans/property/MapPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/MapPropertyTest.java + javafx-beans/test/javafx/beans/property/ObjectPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ObjectPropertyTest.java + javafx-beans/test/javafx/beans/property/PropertiesTest.java + javafx-beans/test/javafx/beans/property/PropertyReferenceTest.java + javafx-beans/test/javafx/beans/property/PropertyReferenceWithInterfacesTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyBooleanPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyBooleanPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyBooleanWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyDoublePropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyDoublePropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyDoubleWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyFloatPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyFloatPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyFloatWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyIntegerPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyIntegerPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyIntegerWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyListPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyListPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyListWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyLongPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyLongPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyLongWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyMapPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyMapPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyMapWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyObjectPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyObjectPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyObjectWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlySetPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlySetPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlySetWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyStringPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyStringPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyStringWrapperTest.java + javafx-beans/test/javafx/beans/property/SetPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/SetPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleBooleanPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleDoublePropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleFloatPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleIntegerPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleListPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleLongPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleObjectPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleStringPropertyTest.java + javafx-beans/test/javafx/beans/property/StringPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/StringPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanBooleanPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanBooleanProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanDoublePropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanDoubleProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanFloatPropertyBuilderaTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanFloatProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanIntegerPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanIntegerProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanLongPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanLongProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanObjectPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanPropertyTestBase.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanStringPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanBooleanPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanBooleanProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanDoublePropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanDoubleProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanFloatPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanFloatProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanIntegerPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanIntegerProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanLongPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanLongProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanObjectPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanPropertyBuilder_General_Test.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanPropertyTestBase.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanStringPropertyTest.java + javafx-beans/test/javafx/beans/value/ChangeListenerMock.java + javafx-beans/test/javafx/beans/value/ObservableBooleanValueStub.java + javafx-beans/test/javafx/beans/value/ObservableDoubleValueStub.java + javafx-beans/test/javafx/beans/value/ObservableFloatValueStub.java + javafx-beans/test/javafx/beans/value/ObservableIntegerValueStub.java + javafx-beans/test/javafx/beans/value/ObservableLongValueStub.java + javafx-beans/test/javafx/beans/value/ObservableObjectValueStub.java + javafx-beans/test/javafx/beans/value/ObservableStringValueStub.java + javafx-beans/test/javafx/beans/value/ObservableValueBaseTest.java + javafx-beans/test/javafx/beans/value/ObservableValueStub.java + javafx-beans/test/javafx/beans/value/WeakChangeListenerMock.java + javafx-beans/test/javafx/beans/value/WeakChangeListenerTest.java + javafx-beans/test/javafx/binding/BindingToStringTest.java + javafx-beans/test/javafx/binding/BindingsBooleanTest.java + javafx-beans/test/javafx/binding/BindingsCreateBindingTest.java + javafx-beans/test/javafx/binding/BindingsEqualsTest.java + javafx-beans/test/javafx/binding/BindingsIsNullTest.java + javafx-beans/test/javafx/binding/BindingsListTest.java + javafx-beans/test/javafx/binding/BindingsMapTest.java + javafx-beans/test/javafx/binding/BindingsNumberCalculationsTest.java + javafx-beans/test/javafx/binding/BindingsNumberCastTest.java + javafx-beans/test/javafx/binding/BindingsSetTest.java + javafx-beans/test/javafx/binding/DependencyUtils.java + javafx-beans/test/javafx/binding/GenericBindingTest.java + javafx-beans/test/javafx/binding/ListBindingTest.java + javafx-beans/test/javafx/binding/MapBindingTest.java + javafx-beans/test/javafx/binding/SetBindingTest.java + javafx-beans/test/javafx/binding/Variable.java + javafx-beans/test/javafx/binding/WhenTestBase.java + javafx-beans/test/javafx/binding/When_Boolean_Test.java + javafx-beans/test/javafx/binding/When_Double_Test.java + javafx-beans/test/javafx/binding/When_Float_Test.java + javafx-beans/test/javafx/binding/When_Integer_Test.java + javafx-beans/test/javafx/binding/When_Long_Test.java + javafx-beans/test/javafx/binding/When_Object_Test.java + javafx-beans/test/javafx/binding/When_String_Test.java + javafx-beans/test/javafx/binding/expression/AbstractNumberExpressionTest.java + javafx-beans/test/javafx/binding/expression/BooleanExpressionTest.java + javafx-beans/test/javafx/binding/expression/DoubleExpressionTest.java + javafx-beans/test/javafx/binding/expression/FloatExpressionTest.java + javafx-beans/test/javafx/binding/expression/IntegerExpressionTest.java + javafx-beans/test/javafx/binding/expression/ListExpressionTest.java + javafx-beans/test/javafx/binding/expression/LongExpressionTest.java + javafx-beans/test/javafx/binding/expression/MapExpressionTest.java + javafx-beans/test/javafx/binding/expression/ObjectExpressionTest.java + javafx-beans/test/javafx/binding/expression/SetExpressionTest.java + javafx-beans/test/javafx/binding/expression/StringExpressionTest.java + javafx-beans/test/javafx/collections/Callable.java + javafx-beans/test/javafx/collections/FXCollectionsTest.java + javafx-beans/test/javafx/collections/FilteredListTest.java + javafx-beans/test/javafx/collections/MockListObserver.java + javafx-beans/test/javafx/collections/MockMapObserver.java + javafx-beans/test/javafx/collections/MockSetObserver.java + javafx-beans/test/javafx/collections/ObservableListIteratorTestBase.java + javafx-beans/test/javafx/collections/ObservableListIterator_P1_Test.java + javafx-beans/test/javafx/collections/ObservableListIterator_P2_Test.java + javafx-beans/test/javafx/collections/ObservableListIterator_P3_Test.java + javafx-beans/test/javafx/collections/ObservableListTestBase.java + javafx-beans/test/javafx/collections/ObservableListTestBase_Empty.java + javafx-beans/test/javafx/collections/ObservableListWithExtractor.java + javafx-beans/test/javafx/collections/ObservableList_Empty_P1_Test.java + javafx-beans/test/javafx/collections/ObservableList_Empty_P2_Test.java + javafx-beans/test/javafx/collections/ObservableList_Empty_P3_Test.java + javafx-beans/test/javafx/collections/ObservableList_P1_Test.java + javafx-beans/test/javafx/collections/ObservableList_P2_Test.java + javafx-beans/test/javafx/collections/ObservableList_P3_Test.java + javafx-beans/test/javafx/collections/ObservableMapTestBase.java + javafx-beans/test/javafx/collections/ObservableMap_P1_Test.java + javafx-beans/test/javafx/collections/ObservableMap_P2_Test.java + javafx-beans/test/javafx/collections/ObservableMap_P3_Test.java + javafx-beans/test/javafx/collections/ObservableMap_P4_Test.java + javafx-beans/test/javafx/collections/ObservableSetTestBase.java + javafx-beans/test/javafx/collections/ObservableSet_P1_Test.java + javafx-beans/test/javafx/collections/ObservableSet_P2_Test.java + javafx-beans/test/javafx/collections/ObservableSet_P3_Test.java + javafx-beans/test/javafx/collections/ObservableSubListIteratorTestBase.java + javafx-beans/test/javafx/collections/ObservableSubListIterator_P1_Test.java + javafx-beans/test/javafx/collections/ObservableSubListIterator_P2_Test.java + javafx-beans/test/javafx/collections/ObservableSubListIterator_P3_Test.java + javafx-beans/test/javafx/collections/ObservableSubListTestBase.java + javafx-beans/test/javafx/collections/ObservableSubList_P1_Test.java + javafx-beans/test/javafx/collections/ObservableSubList_P2_Test.java + javafx-beans/test/javafx/collections/ObservableSubList_P3_Test.java + javafx-beans/test/javafx/collections/Person.java + javafx-beans/test/javafx/collections/SortedListTest.java + javafx-beans/test/javafx/collections/TestedObservableLists.java + javafx-beans/test/javafx/collections/TransformationListTest.java + javafx-beans/test/javafx/collections/UnmodifiableObservableMapTestBase.java + javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P1_Test.java + javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P2_Test.java + javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P3_Test.java + javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P4_Test.java + javafx-beans/test/javafx/collections/VetoableObservableListTest.java + javafx-beans/test/javafx/collections/WeakListChangeListenerMock.java + javafx-beans/test/javafx/collections/WeakListChangeListenerTest.java + javafx-beans/test/javafx/collections/WeakMapChangeListenerTest.java + javafx-beans/test/javafx/collections/WeakSetChangeListenerTest.java ! javafx-concurrent/build-closed.xml ! javafx-concurrent/project.properties ! javafx-designtime/build-closed.xml ! javafx-fxml/build-closed.xml ! javafx-fxml/nbproject/project.xml ! javafx-sg-common/project.properties ! javafx-ui-charts/build-closed.xml ! javafx-ui-common/build-closed.xml ! javafx-ui-common/nbproject/project.xml ! javafx-ui-controls/build-closed.xml ! javafx-ui-controls/build-common.xml ! javafx-util-converter/build-closed.xml From lehmann at media-interactive.de Tue Feb 5 01:07:54 2013 From: lehmann at media-interactive.de (Werner Lehmann) Date: Tue, 5 Feb 2013 10:07:54 +0100 Subject: SceneBuilder src, or how to drag/size controls In-Reply-To: <5110143F.6060405@oracle.com> References: <51100F7E.2010603@media-interactive.de> <5110143F.6060405@oracle.com> Message-ID: <5110CBEA.7080906@media-interactive.de> Yes, I saw that comment on your blog. It is certainly worth keeping this in mind. But as always (so it feels), it doesnt look as if I could benefit from 8 anytime soon. A problem I am sharing with a few other people I guess given the slow adoption process of any Java version in enterprises... (and that process can even only start in 6+ months). Werner On 04.02.2013 21:04, Jonathan Giles wrote: > I can't speak to the first part of your email, but regarding resizing > standard controls: as of JavaFX 8.0 Control extends from Region, so > whilst I haven't tested Andrew's code, this should theoretically work. > It would be worth testing, anyway :-) From lehmann at media-interactive.de Tue Feb 5 01:08:18 2013 From: lehmann at media-interactive.de (Werner Lehmann) Date: Tue, 5 Feb 2013 10:08:18 +0100 Subject: SceneBuilder src, or how to drag/size controls In-Reply-To: <03984064-67DE-4A15-AABD-B5ABBFF16EB0@oracle.com> References: <51100F7E.2010603@media-interactive.de> <03984064-67DE-4A15-AABD-B5ABBFF16EB0@oracle.com> Message-ID: <5110CC02.5000207@media-interactive.de> Ok, thanks for the info. On 04.02.2013 21:15, Joe McGlynn wrote: > SceneBuilder is not available in source form, sorry. From artem.ananiev at oracle.com Tue Feb 5 01:21:14 2013 From: artem.ananiev at oracle.com (artem.ananiev at oracle.com) Date: Tue, 05 Feb 2013 09:21:14 +0000 Subject: hg: openjfx/8/controls: Introducing SWT_DIR env variable and swt.path ant property to build JavaFX/SWT classes Message-ID: <20130205092114.7FC854782A@hg.openjdk.java.net> Changeset: fa2593dfacea Author: art Date: 2013-02-04 15:16 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rev/fa2593dfacea Introducing SWT_DIR env variable and swt.path ant property to build JavaFX/SWT classes ! build-defs.xml ! build-src/build-environment.xml From artem.ananiev at oracle.com Tue Feb 5 01:21:53 2013 From: artem.ananiev at oracle.com (artem.ananiev at oracle.com) Date: Tue, 05 Feb 2013 09:21:53 +0000 Subject: hg: openjfx/8/master: Introducing SWT_DIR env variable and swt.path ant property to build JavaFX/SWT classes Message-ID: <20130205092153.82F434782B@hg.openjdk.java.net> Changeset: fa2593dfacea Author: art Date: 2013-02-04 15:16 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rev/fa2593dfacea Introducing SWT_DIR env variable and swt.path ant property to build JavaFX/SWT classes ! build-defs.xml ! build-src/build-environment.xml From hjohn at xs4all.nl Tue Feb 5 02:25:23 2013 From: hjohn at xs4all.nl (John Hendrikx) Date: Tue, 05 Feb 2013 11:25:23 +0100 Subject: [API Review] RT-24916 - TableView.scrollTo(TableColumn) In-Reply-To: <5110B359.2000303@oracle.com> References: <510F7065.3020101@bestsolution.at> <510F9553.3060408@xs4all.nl> <511013BF.6000100@oracle.com> <5110AD4E.6010500@xs4all.nl> <5110B359.2000303@oracle.com> Message-ID: <5110DE13.50202@xs4all.nl> On 05/02/2013 08:23, Jonathan Giles wrote: > On 5/02/2013 7:57 p.m., John Hendrikx wrote: >> On 4/02/2013 21:02, Jonathan Giles wrote: >>> This is a fair comment: scrollTo has been designed with a >>> 'fire-and-forget' approach in mind, but I would be loath to add a >>> means of requesting a self-correcting scrollTo function. Wouldn't a >>> suitable workaround be to call scrollTo after the image loading has >>> completed in all cells? >> The problem is that image loading occurs in the background, and it is >> not really predictable when all of them are completed. In my example >> application, these images are loaded from a database (when cached) or >> from the internet when not. It may take 10 seconds before one has >> been loaded if it wasn't cached. Waiting that long before I restore >> the position of the view for the user is not acceptable. Also, >> calling scrollTo may trigger more image loading (as new cells come >> into view), so I'd have to call it in a loop until no more images are >> getting loaded... > > I'm confused by this statement (which isn't to say it is wrong, just > that I don't see the distinction). Isn't the end result exactly the > same whether you (externally) watch the progress of each of your > image-loading cells and call scrollTo(index) as each cell completes > the loading of the picture versus having code in the virtualisation > system to react (internally) as the height of a cell changes (which > means having to pay a not-inconsiderable overhead to watch the height > of all visible cells in all cases, even when the user has no need for > this overhead). Am I missing some nuance of your proposal that works > around this? I donot think it would be. All I can do to control the position of the View is use scrollTo. This function only makes the cell visible (afaik) and does not necessarily center it. In other words, if some cells that are growing are pushing my target cell down, scrollTo won't do anything until the target cell actually gets pushed out of the viewport. Once it gets pushed out of the viewport, then suddenly a call to scrollTo would center my target cell again causing a jump. Since the loading of images can take tens of seconds, the shifting of the target cell and occasional jumps back to center could occur quite a few times. With an internal implementation the target cell could be kept completely stationary regardless of how cells above or below are changing. For a simple scrollTo() implementation to work, I'd also have to track every other possible interaction with the View control (scrollbar being dragged, cursor keys used) to know whether or not I'm still allowed to call scrollTo to adjust the position or that I should be respecting the users positioning. With regards to overhead (but I may be completely wrong about this), I think you already get notified automatically when a cell changes height (for managed cells, when LayoutBounds changes it triggers a layout request up to the current layout root). I know the cells used by VirtualFlow are managed as I saw this in your code. > I should note that there is a very fine balancing act that needs to > happen in this code between performance and reliability (i.e. pixel > perfect scrollTo behavior). It used to be the case that scrollTo would > measure the height of every cell down to the specified index, but this > was deemed too slow and replaced with a more performant but less > reliable algorithm. Striking the right balance is tough. That is good news, I believe I filed a Jira issue with regards to scrollTo calculating the height of all the cells upto the specified index (it would trigger a lot of background loading for cells that weren't ever visible). I'm not expecting pixel perfect behavior, and I realize that without the height of every cell known you cannot make perfect calculations for for example the scrollbar size and position. This seems hard to avoid though as calculating the height of every cell when there are potentially tens of thousands seems contrary to the whole idea of using cells in the first place (ie. performance). Anyway, I fully realize this is not a simple problem or just a small bug fix. That is why I'm trying to create my own Skin as I donot expect this to be fixed on short notice, or even at all due to possible differences in viewpoint as to how the controls should work. But the way I'm thinking of solving this (in my own Skin) is to pay less attention to the cell heights, and more to the amount of cells available and which one should be visible. Basically, I want to introduce the concept of a target cell (which usually will be the focused one). The layout code will make every effort to keep this target cell stable at the position it was located (not necessarily centered, but at whatever position it was relative to the top of the viewport). This target cell will be used as a starting point for the layout. I get the height of the target cell, and then position it as closely as I can to where it was last time around. I then work my way up and down and add cells above and below the target cell until the viewport is filled. If any changes in height occur, another layout should be triggered (well I hope atleast), and the process starts again, "centering" the target cell and adding cells above and below until the viewport is filled. This should result in the target cell being "stable" while the cells around it can shift positions. > Finally, I am operating far in excess of normal operational capacity, > and can not imagine I will have any bandwidth to look at this, > realistically, this year. If someone finds that the itch is > unbearable, by all means scratch it and send me through the patch file > :-). I have found working with external contributors has been very > beneficial, so I am more than happy to work with more contributors in > areas such as this. I do not mean to dismiss this discussion, I just > want to be clear with expectations. Yes I understand, I know you are very busy and I'm glad you took the time to have this discussion. I'm not sure if whatever I'm cooking up will be contribution worthy (as I'm specifically looking at TreeView and vertical layouts), but if I do get it working satisfactory, we could take a look and see if it may be useful to you in some way. --John From hang.vo at oracle.com Tue Feb 5 05:03:56 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Feb 2013 13:03:56 +0000 Subject: hg: openjfx/8/graphics/rt: RT-16008: Dirty region of nodes under group with effect should adjust itself so that it covers every affected pixels Message-ID: <20130205130359.EBD3047836@hg.openjdk.java.net> Changeset: e573fa389ba7 Author: Radko Najman Date: 2013-02-05 13:45 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e573fa389ba7 RT-16008: Dirty region of nodes under group with effect should adjust itself so that it covers every affected pixels ! javafx-geom/src/com/sun/javafx/geom/BaseBounds.java ! javafx-geom/src/com/sun/javafx/geom/BoxBounds.java + javafx-geom/src/com/sun/javafx/geom/DirtyRegionContainer.java + javafx-geom/src/com/sun/javafx/geom/DirtyRegionPool.java ! javafx-geom/src/com/sun/javafx/geom/RectBounds.java + javafx-geom/test/com/sun/javafx/geom/DirtyRegionContainerTest.java ! javafx-sg-common/src/com/sun/javafx/sg/BaseNode.java - javafx-sg-common/src/com/sun/javafx/sg/DirtyRegionContainer.java - javafx-sg-common/src/com/sun/javafx/sg/DirtyRegionPool.java ! javafx-sg-common/test/com/sun/javafx/sg/CullingTest.java - javafx-sg-common/test/com/sun/javafx/sg/DirtyRegionContainerTest.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGCanvas.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGGroup.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGNode.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NodeEffectInput.java ! javafx-sg-prism/test/com/sun/javafx/sg/prism/DirtyRegionTestBase.java ! javafx-sg-prism/test/com/sun/javafx/sg/prism/NodeTestUtils.java From hang.vo at oracle.com Tue Feb 5 08:32:49 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Feb 2013 16:32:49 +0000 Subject: hg: openjfx/8/controls/rt: RT-23691: stylemanager leaks like a sieve. Message-ID: <20130205163252.414F74783D@hg.openjdk.java.net> Changeset: 3587d30fc228 Author: David Grieve Date: 2013-02-05 10:44 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3587d30fc228 RT-23691: stylemanager leaks like a sieve. ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/application/Application.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/stage/Window.java ! javafx-ui-common/test/unit/com/sun/javafx/css/CssMetaDataTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleManagerTest.java ! javafx-ui-common/test/unit/javafx/scene/Node_effectiveOrientation_Css_Test.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/test/javafx/scene/control/PopupControlTest.java From hang.vo at oracle.com Tue Feb 5 09:03:05 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Feb 2013 17:03:05 +0000 Subject: hg: openjfx/8/controls/rt: 3 new changesets Message-ID: <20130205170311.D64E647840@hg.openjdk.java.net> Changeset: 94130cc6c0a2 Author: Paru Somashekar Date: 2013-02-05 08:53 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/94130cc6c0a2 RT-24342 ColorPicker missing javadoc. ! javafx-ui-controls/src/javafx/scene/control/ColorPicker.java Changeset: 98da68b53ff0 Author: David Grieve Date: 2013-02-05 11:50 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/98da68b53ff0 RT-27155: if setting value raises exception, reset value the value to initial and thereafter skip setting the property ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: 6dea9882cca3 Author: David Grieve Date: 2013-02-05 11:51 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6dea9882cca3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/rt From sven.reimers at gmail.com Tue Feb 5 09:32:32 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Tue, 5 Feb 2013 18:32:32 +0100 Subject: createSymbols Property not available on AreaChart In-Reply-To: <5110346A.1050106@oracle.com> References: <21C4C53A-E6EC-4B0C-9944-F0094E63CCC3@oracle.com> <5110346A.1050106@oracle.com> Message-ID: Seems the patch is not yet good if series are changed dynamically... .. working on it .. BTW. We should do the same for StackedAreaChart (preparing the patch as well) - Shall I file a separate issue? -Sven On Mon, Feb 4, 2013 at 11:21 PM, Jonathan Giles wrote: > Nope, attachments to openjfx-dev are stripped. Please email it to me and > I'll attach it to the jira issue. > > -- Jonathan > > > On 5/02/2013 11:01 a.m., Sven Reimers wrote: > >> Here you go - patch attached (hope this makes it through) >> >> -Sven >> >> >> On Sat, Feb 2, 2013 at 6:47 PM, Sven Reimers >> wrote: >> >> Enhancement request filed: >>> >>> http://javafx-jira.kenai.com/**browse/RT-28148 >>> >>> Next step: working on a patch >>> >>> -Sven >>> >>> >>> On Fri, Feb 1, 2013 at 8:06 PM, Sven Reimers >> >wrote: >>> >>> Ok. Will file issue and try to provide patch. >>>> >>>> -Sven >>>> Am 01.02.2013 19:33 schrieb "Jasper Potts" : >>>> >>>> Hi, >>>> >>>>> Seems like a good idea. If you file a JIRA Tweak that would be great, a >>>>> patch would also be most welcome :-) >>>>> >>>>> Thanks >>>>> >>>>> Jasper >>>>> >>>>> On Feb 1, 2013, at 9:23 AM, Sven Reimers >>>>> wrote: >>>>> >>>>> Hi, >>>>>> >>>>>> just thought I check here first before opening a RFE on JIRA. >>>>>> >>>>>> LineChart has a createSymbols Property to switch on/off creation of >>>>>> >>>>> symbols >>>>> >>>>>> where data points are in the chart. The same property would be nice to >>>>>> >>>>> have >>>>> >>>>>> on AreaChart as well, since it is way more easy to get rid of the >>>>>> >>>>> symbols >>>>> >>>>>> with such a property in comparison to be forced doing this via CSS and >>>>>> >>>>> in >>>>> >>>>>> terms of API it would be more consistent with LineChart. >>>>>> >>>>>> So how about adding createSymbols property to AreaChart? >>>>>> >>>>>> >>>>>> Desired API change: >>>>>> -- snip -- >>>>>> >>>>>> /** >>>>>> * Indicates whether symbols for data points will be created or >>>>>> not. >>>>>> * >>>>>> * @return true if symbols for data points will be created and >>>>>> false >>>>>> otherwise. >>>>>> */ >>>>>> public final boolean getCreateSymbols() { return >>>>>> createSymbols.getValue(); } >>>>>> public final void setCreateSymbols(boolean value) { >>>>>> createSymbols.setValue(value); } >>>>>> public final BooleanProperty createSymbolsProperty() { return >>>>>> createSymbols; } >>>>>> >>>>>> --snip --- >>>>>> >>>>>> Comments? >>>>>> >>>>>> 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 >>>>>> >>>>> >>>>> >>> -- >>> Sven Reimers >>> >>> * Senior Expert Software Architect >>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org >>> * NetBeans Governance Board Member: >>> http://netbeans.org/about/os/**governance.html >>> >>> * 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 >>> >>> >> >> > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * 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 From hang.vo at oracle.com Tue Feb 5 09:33:03 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Feb 2013 17:33:03 +0000 Subject: hg: openjfx/8/graphics/rt: Fix RT-27964 - Load HiDPI images when available on HiDPI displays Message-ID: <20130205173308.1DBCC47844@hg.openjdk.java.net> Changeset: db6fc38a2116 Author: flar Date: 2013-02-05 09:28 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/db6fc38a2116 Fix RT-27964 - Load HiDPI images when available on HiDPI displays ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGCanvas.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGImageView.java ! javafx-ui-common/src/com/sun/javafx/tk/PlatformImage.java ! javafx-ui-common/src/javafx/scene/image/Image.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubFilterable.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubPlatformImage.java From richard.bair at oracle.com Tue Feb 5 13:43:33 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 5 Feb 2013 13:43:33 -0800 Subject: StubToolkit must go! In-Reply-To: <51106936.8080308@oracle.com> References: <60A32258-24E3-4E27-A1E1-7E50C60EB5E3@oracle.com> <510F7F67.3020408@oracle.com> <993F6F47-AF3C-4BFA-B6B7-405EEEEEAC7E@oracle.com> <51106936.8080308@oracle.com> Message-ID: All testing is only an approximation. Almost all of our unit tests are not black-box testing but white-box testing. SQE tests are presently black-box tests and they exercise the whole platform. We can run 20,000 unit tests in about the time it takes to run 50-100 SQE tests. There are other tradeoffs as well. For example the unit tests, when they fail, it is usually pretty easy to know what went wrong because you aren't testing very much of the platform -- only a very specific aspect of it (that is the inherent benefit of mocks). Black box testing on the other hand will find errors in places that you hadn't thought off, since it is testing more. Then again, when there is a failure, it is more work to diagnose where the failure occurred. And to do stringent testing takes many, many hours as often tests need to be fired up in separate VM's and will produce different results on different platforms, and you lose control of your OS while those tests run since it is actually driving the mouse / keyboard. So while there are downsides to using mocks like this, there are also upsides. I think you need both kinds of tests in the end. But this is really interim anyway. There is nothing in the NG nodes that dictates that we can't use them fully headless in a unit-test fashion. The problem is that javafx-sg-prism depends on javafx-ui-common, and we can't make javafx-ui-common (and all its tests) depend on javafx-sg-prism. In the "new world" I'm setting up, both of these projects (and a few others) will be merged into the "Graphics" component (module) and then we can get the tests cleaned up the right way. Richard On Feb 4, 2013, at 6:06 PM, Jim Graham wrote: > The problem with this approach is that you are testing PolygonMock instead of Polygon. Any bugs in the impl_ methods are untestable when you override them, and any future changes to Polygon which modify the way that the impl_ methods are used may introduce bugs that do not impact the testing you do with your Mock version because it hides those changes. > > Also, the impl_ methods are being slowly removed in favor of the Accessor paradigm. Many impl_ methods have already disappeared. These public implementation methods have always been a hack and they are currently only public (and overridable) because we haven't switched over to a better (and easier to keep secure in the long run) paradigm. Your testing methodology would require us to maintain implementation only methods as public interfaces which we are trying to move away from. > > If you are going to black box test the UI classes then you must treat them as a black box - that means using an external interface that is supported to instrument the testing. The only supported external interface we have is the Toolkit interface and the PG interfaces so you must continue to work behind those interfaces and evolve them if testing needs more instrumentation or you aren't really testing the UI classes, you are testing an approximation of them... > > ...jim > > On 2/4/13 7:41 AM, Richard Bair wrote: >> Hi Pavel, >> >> Removing StubToolkit _does not imply_ that we have to test with a live toolkit / glass. For example, the PolygonTest wants to test that during synchronization the array of floats it expected to be passed to the peer is the actual set that got passed. >> >> @Test public void testBounds_oddPointsLength() { >> final double[] initialPoints = { >> 100, 100, 200, 100, 200, 200, 150, 300 >> }; >> >> final Polygon polygon = new PolygonMock(initialPoints); >> assertBoundsEqual(box(100, 100, 100, 200), polygon.getBoundsInLocal()); >> >> final ObservableList polygonPoints = polygon.getPoints(); >> polygonPoints.remove(6); >> >> assertBoundsEqual(box(100, 100, 100, 100), polygon.getBoundsInLocal()); >> } >> >> >> This can easily be done by using a special subclass of Polygon that, in impl_createPGNode, creates a special subclass of NGPolygon: >> >> private static final class PolygonMock extends Polygon { >> public PolygonMock() { >> super(); >> } >> >> public PolygonMock(double... points) { >> super(points); >> } >> >> @Override protected PGNode impl_createPGNode() { >> return new StubPolygon(); >> } >> } >> >> private static final class StubPolygon extends NGPolygon { >> float[] points; >> @Override public void updatePolygon(float[] points) { >> this.points = points; >> super.updatePolygon(points); >> } >> } >> >> >> Running this test does not require that we fire up multiple threads or open a glass window etc. >> >> I haven't finished combing through all the usages of StubToolkit, but I'm confident we can remove it without changing the nature of the tests. >> >> Richard >> >> On Feb 4, 2013, at 1:29 AM, Pavel Safrata wrote: >> >>> Hi Richard, >>> I strongly object. I've had this discussion with Kevin a year ago, quoting myself from the old discussion: >>> >>> Scenegraph unit tests are there to test scenegraph. I believe that unit tests should by their definition test single units isolated from the rest of the system, not the system as a whole - for this we should have functional tests developed by QA. Our tests make sure that scenegraph works correctly given that the underlying platform behaves as expected. Including live toolkit/glass in running the tests would IMHO seriously damage purpose of those tests - they wouldn't give any reliable evidence of scenegraph's stability any more. Other important thing is that the code doesn't change over time (so it tests regressions in scenegraph) and also the test can make it behave in more different ways (and test scenegraph robustness). >>> >>> Thanks, >>> Pavel >>> >>> On 2.2.2013 1:11, Richard Bair wrote: >>>> Well, at least that is what I'm hoping to do. The problem is that we have a bunch of unit tests. 20K+. Some of them rely on StubToolkit, some of them rely on the real deal. In the "source cleanup" operation I'm on, when we combine all the "graphics" tests together, we have a problem where these two different types of tests are together and one set will fail to execute depending on whether we launch with the real toolkit or the stub toolkit. >>>> >>>> My plan is to yank out StubToolkit and update all the tests that relied on it to instead work with the real toolkit (quantum and prism). I suspect this is going to be painful. >>>> >>>> Richard >>> >> From james.graham at oracle.com Tue Feb 5 14:09:42 2013 From: james.graham at oracle.com (Jim Graham) Date: Tue, 05 Feb 2013 14:09:42 -0800 Subject: StubToolkit must go! In-Reply-To: References: <60A32258-24E3-4E27-A1E1-7E50C60EB5E3@oracle.com> <510F7F67.3020408@oracle.com> <993F6F47-AF3C-4BFA-B6B7-405EEEEEAC7E@oracle.com> <51106936.8080308@oracle.com> Message-ID: <51118326.2040402@oracle.com> And when the impl_ methods go away, then what? ...jim On 2/5/13 1:43 PM, Richard Bair wrote: > All testing is only an approximation. Almost all of our unit tests are not black-box testing but white-box testing. SQE tests are presently black-box tests and they exercise the whole platform. We can run 20,000 unit tests in about the time it takes to run 50-100 SQE tests. There are other tradeoffs as well. For example the unit tests, when they fail, it is usually pretty easy to know what went wrong because you aren't testing very much of the platform -- only a very specific aspect of it (that is the inherent benefit of mocks). Black box testing on the other hand will find errors in places that you hadn't thought off, since it is testing more. Then again, when there is a failure, it is more work to diagnose where the failure occurred. And to do stringent testing takes many, many hours as often tests need to be fired up in separate VM's and will produce different results on different platforms, and you lose control of your OS while those tests run since it is actually driv! ing the mo use / keyboard. > > So while there are downsides to using mocks like this, there are also upsides. I think you need both kinds of tests in the end. > > But this is really interim anyway. There is nothing in the NG nodes that dictates that we can't use them fully headless in a unit-test fashion. The problem is that javafx-sg-prism depends on javafx-ui-common, and we can't make javafx-ui-common (and all its tests) depend on javafx-sg-prism. In the "new world" I'm setting up, both of these projects (and a few others) will be merged into the "Graphics" component (module) and then we can get the tests cleaned up the right way. > > Richard > > On Feb 4, 2013, at 6:06 PM, Jim Graham wrote: > >> The problem with this approach is that you are testing PolygonMock instead of Polygon. Any bugs in the impl_ methods are untestable when you override them, and any future changes to Polygon which modify the way that the impl_ methods are used may introduce bugs that do not impact the testing you do with your Mock version because it hides those changes. >> >> Also, the impl_ methods are being slowly removed in favor of the Accessor paradigm. Many impl_ methods have already disappeared. These public implementation methods have always been a hack and they are currently only public (and overridable) because we haven't switched over to a better (and easier to keep secure in the long run) paradigm. Your testing methodology would require us to maintain implementation only methods as public interfaces which we are trying to move away from. >> >> If you are going to black box test the UI classes then you must treat them as a black box - that means using an external interface that is supported to instrument the testing. The only supported external interface we have is the Toolkit interface and the PG interfaces so you must continue to work behind those interfaces and evolve them if testing needs more instrumentation or you aren't really testing the UI classes, you are testing an approximation of them... >> >> ...jim >> >> On 2/4/13 7:41 AM, Richard Bair wrote: >>> Hi Pavel, >>> >>> Removing StubToolkit _does not imply_ that we have to test with a live toolkit / glass. For example, the PolygonTest wants to test that during synchronization the array of floats it expected to be passed to the peer is the actual set that got passed. >>> >>> @Test public void testBounds_oddPointsLength() { >>> final double[] initialPoints = { >>> 100, 100, 200, 100, 200, 200, 150, 300 >>> }; >>> >>> final Polygon polygon = new PolygonMock(initialPoints); >>> assertBoundsEqual(box(100, 100, 100, 200), polygon.getBoundsInLocal()); >>> >>> final ObservableList polygonPoints = polygon.getPoints(); >>> polygonPoints.remove(6); >>> >>> assertBoundsEqual(box(100, 100, 100, 100), polygon.getBoundsInLocal()); >>> } >>> >>> >>> This can easily be done by using a special subclass of Polygon that, in impl_createPGNode, creates a special subclass of NGPolygon: >>> >>> private static final class PolygonMock extends Polygon { >>> public PolygonMock() { >>> super(); >>> } >>> >>> public PolygonMock(double... points) { >>> super(points); >>> } >>> >>> @Override protected PGNode impl_createPGNode() { >>> return new StubPolygon(); >>> } >>> } >>> >>> private static final class StubPolygon extends NGPolygon { >>> float[] points; >>> @Override public void updatePolygon(float[] points) { >>> this.points = points; >>> super.updatePolygon(points); >>> } >>> } >>> >>> >>> Running this test does not require that we fire up multiple threads or open a glass window etc. >>> >>> I haven't finished combing through all the usages of StubToolkit, but I'm confident we can remove it without changing the nature of the tests. >>> >>> Richard >>> >>> On Feb 4, 2013, at 1:29 AM, Pavel Safrata wrote: >>> >>>> Hi Richard, >>>> I strongly object. I've had this discussion with Kevin a year ago, quoting myself from the old discussion: >>>> >>>> Scenegraph unit tests are there to test scenegraph. I believe that unit tests should by their definition test single units isolated from the rest of the system, not the system as a whole - for this we should have functional tests developed by QA. Our tests make sure that scenegraph works correctly given that the underlying platform behaves as expected. Including live toolkit/glass in running the tests would IMHO seriously damage purpose of those tests - they wouldn't give any reliable evidence of scenegraph's stability any more. Other important thing is that the code doesn't change over time (so it tests regressions in scenegraph) and also the test can make it behave in more different ways (and test scenegraph robustness). >>>> >>>> Thanks, >>>> Pavel >>>> >>>> On 2.2.2013 1:11, Richard Bair wrote: >>>>> Well, at least that is what I'm hoping to do. The problem is that we have a bunch of unit tests. 20K+. Some of them rely on StubToolkit, some of them rely on the real deal. In the "source cleanup" operation I'm on, when we combine all the "graphics" tests together, we have a problem where these two different types of tests are together and one set will fail to execute depending on whether we launch with the real toolkit or the stub toolkit. >>>>> >>>>> My plan is to yank out StubToolkit and update all the tests that relied on it to instead work with the real toolkit (quantum and prism). I suspect this is going to be painful. >>>>> >>>>> Richard >>>> >>> > From hang.vo at oracle.com Tue Feb 5 14:18:05 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Feb 2013 22:18:05 +0000 Subject: hg: openjfx/8/graphics/rt: [ECLIPSE_ONLY] javafx-beans & embedded swt open sourcing Message-ID: <20130205221809.E624547858@hg.openjdk.java.net> Changeset: 110d447262ce Author: Felipe Heidrich Date: 2013-02-05 13:33 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/110d447262ce [ECLIPSE_ONLY] javafx-beans & embedded swt open sourcing ! .classpath From richard.bair at oracle.com Tue Feb 5 14:33:35 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 5 Feb 2013 14:33:35 -0800 Subject: StubToolkit must go! In-Reply-To: <51118326.2040402@oracle.com> References: <60A32258-24E3-4E27-A1E1-7E50C60EB5E3@oracle.com> <510F7F67.3020408@oracle.com> <993F6F47-AF3C-4BFA-B6B7-405EEEEEAC7E@oracle.com> <51106936.8080308@oracle.com> <51118326.2040402@oracle.com> Message-ID: <2F1AC6D9-CD09-4339-BD13-F68300EC0262@oracle.com> Refactor. We can put test helpers in the right package to access package private stuff. It is the same as with toolkit -- we're trying to remove those abstractions and have the scene graph side talk to glass / prism directly. As we do so we have to fix the tests as we go. On Feb 5, 2013, at 2:09 PM, Jim Graham wrote: > And when the impl_ methods go away, then what? > > ...jim > > On 2/5/13 1:43 PM, Richard Bair wrote: >> All testing is only an approximation. Almost all of our unit tests are not black-box testing but white-box testing. SQE tests are presently black-box tests and they exercise the whole platform. We can run 20,000 unit tests in about the time it takes to run 50-100 SQE tests. There are other tradeoffs as well. For example the unit tests, when they fail, it is usually pretty easy to know what went wrong because you aren't testing very much of the platform -- only a very specific aspect of it (that is the inherent benefit of mocks). Black box testing on the other hand will find errors in places that you hadn't thought off, since it is testing more. Then again, when there is a failure, it is more work to diagnose where the failure occurred. And to do stringent testing takes many, many hours as often tests need to be fired up in separate VM's and will produce different results on different platforms, and you lose control of your OS while those tests run since it is actually driving the mo > use / keyboard. >> >> So while there are downsides to using mocks like this, there are also upsides. I think you need both kinds of tests in the end. >> >> But this is really interim anyway. There is nothing in the NG nodes that dictates that we can't use them fully headless in a unit-test fashion. The problem is that javafx-sg-prism depends on javafx-ui-common, and we can't make javafx-ui-common (and all its tests) depend on javafx-sg-prism. In the "new world" I'm setting up, both of these projects (and a few others) will be merged into the "Graphics" component (module) and then we can get the tests cleaned up the right way. >> >> Richard >> >> On Feb 4, 2013, at 6:06 PM, Jim Graham wrote: >> >>> The problem with this approach is that you are testing PolygonMock instead of Polygon. Any bugs in the impl_ methods are untestable when you override them, and any future changes to Polygon which modify the way that the impl_ methods are used may introduce bugs that do not impact the testing you do with your Mock version because it hides those changes. >>> >>> Also, the impl_ methods are being slowly removed in favor of the Accessor paradigm. Many impl_ methods have already disappeared. These public implementation methods have always been a hack and they are currently only public (and overridable) because we haven't switched over to a better (and easier to keep secure in the long run) paradigm. Your testing methodology would require us to maintain implementation only methods as public interfaces which we are trying to move away from. >>> >>> If you are going to black box test the UI classes then you must treat them as a black box - that means using an external interface that is supported to instrument the testing. The only supported external interface we have is the Toolkit interface and the PG interfaces so you must continue to work behind those interfaces and evolve them if testing needs more instrumentation or you aren't really testing the UI classes, you are testing an approximation of them... >>> >>> ...jim >>> >>> On 2/4/13 7:41 AM, Richard Bair wrote: >>>> Hi Pavel, >>>> >>>> Removing StubToolkit _does not imply_ that we have to test with a live toolkit / glass. For example, the PolygonTest wants to test that during synchronization the array of floats it expected to be passed to the peer is the actual set that got passed. >>>> >>>> @Test public void testBounds_oddPointsLength() { >>>> final double[] initialPoints = { >>>> 100, 100, 200, 100, 200, 200, 150, 300 >>>> }; >>>> >>>> final Polygon polygon = new PolygonMock(initialPoints); >>>> assertBoundsEqual(box(100, 100, 100, 200), polygon.getBoundsInLocal()); >>>> >>>> final ObservableList polygonPoints = polygon.getPoints(); >>>> polygonPoints.remove(6); >>>> >>>> assertBoundsEqual(box(100, 100, 100, 100), polygon.getBoundsInLocal()); >>>> } >>>> >>>> >>>> This can easily be done by using a special subclass of Polygon that, in impl_createPGNode, creates a special subclass of NGPolygon: >>>> >>>> private static final class PolygonMock extends Polygon { >>>> public PolygonMock() { >>>> super(); >>>> } >>>> >>>> public PolygonMock(double... points) { >>>> super(points); >>>> } >>>> >>>> @Override protected PGNode impl_createPGNode() { >>>> return new StubPolygon(); >>>> } >>>> } >>>> >>>> private static final class StubPolygon extends NGPolygon { >>>> float[] points; >>>> @Override public void updatePolygon(float[] points) { >>>> this.points = points; >>>> super.updatePolygon(points); >>>> } >>>> } >>>> >>>> >>>> Running this test does not require that we fire up multiple threads or open a glass window etc. >>>> >>>> I haven't finished combing through all the usages of StubToolkit, but I'm confident we can remove it without changing the nature of the tests. >>>> >>>> Richard >>>> >>>> On Feb 4, 2013, at 1:29 AM, Pavel Safrata wrote: >>>> >>>>> Hi Richard, >>>>> I strongly object. I've had this discussion with Kevin a year ago, quoting myself from the old discussion: >>>>> >>>>> Scenegraph unit tests are there to test scenegraph. I believe that unit tests should by their definition test single units isolated from the rest of the system, not the system as a whole - for this we should have functional tests developed by QA. Our tests make sure that scenegraph works correctly given that the underlying platform behaves as expected. Including live toolkit/glass in running the tests would IMHO seriously damage purpose of those tests - they wouldn't give any reliable evidence of scenegraph's stability any more. Other important thing is that the code doesn't change over time (so it tests regressions in scenegraph) and also the test can make it behave in more different ways (and test scenegraph robustness). >>>>> >>>>> Thanks, >>>>> Pavel >>>>> >>>>> On 2.2.2013 1:11, Richard Bair wrote: >>>>>> Well, at least that is what I'm hoping to do. The problem is that we have a bunch of unit tests. 20K+. Some of them rely on StubToolkit, some of them rely on the real deal. In the "source cleanup" operation I'm on, when we combine all the "graphics" tests together, we have a problem where these two different types of tests are together and one set will fail to execute depending on whether we launch with the real toolkit or the stub toolkit. >>>>>> >>>>>> My plan is to yank out StubToolkit and update all the tests that relied on it to instead work with the real toolkit (quantum and prism). I suspect this is going to be painful. >>>>>> >>>>>> Richard >>>>> >>>> >> From richard.bair at oracle.com Tue Feb 5 15:04:47 2013 From: richard.bair at oracle.com (Richard Bair) Date: Tue, 5 Feb 2013 15:04:47 -0800 Subject: StubToolkit must go! In-Reply-To: <2F1AC6D9-CD09-4339-BD13-F68300EC0262@oracle.com> References: <60A32258-24E3-4E27-A1E1-7E50C60EB5E3@oracle.com> <510F7F67.3020408@oracle.com> <993F6F47-AF3C-4BFA-B6B7-405EEEEEAC7E@oracle.com> <51106936.8080308@oracle.com> <51118326.2040402@oracle.com> <2F1AC6D9-CD09-4339-BD13-F68300EC0262@oracle.com> Message-ID: <543FD1AF-BE62-4F3A-9653-1E4CB92EC77C@oracle.com> Well, in any case StubToolkit was too powerful for me. There are unexpected API usages which indirectly cause Toolkit.getToolkit to be called (such as code that used PerformanceTracker). The problem is that when run without any toolkit on the class path (as the tests for javafx-ui-common are, without using StubToolkit), you end up with an exception in Toolkit.getToolkit(). So another option I explored was to have each test that needed to use stub toolkit to extend from a common base class which would in @BeforeClass and @AfterClass methods install / uninstall StubToolkit, and attempt to do so in a manner where if QuantumToolkit was already installed, it would restore it after having run its tests. That seems to work, but did require some changes to tests. I'm going to try what probably I should have tried first -- I know all the controls, charts, and ui-common tests use StubToolkit but nobody else does. So those tests I will put into ${module}/src/test/java and ${module}/src/test/stub (basically split them among two different test directories). Then just run them with different settings. That would require the least modification to the existing tests and I can continue on with the build system work. Ultimately though, what I want to do is combine the tests, get rid of StubToolkit and instead just use NG* directly etc. Another big issue is that right now each test class is fired up in its own VM and takes 10x longer (or thereabouts) to execute than if the tests could all just run in the same VM. Some tests need their own VM (related to initialization etc where we cannot easily reinitialize some code on subsequent test runs), whereas most of them could run concurrently. I'm looking into JTReg as the main system for invoking our tests, which is capable of calling TestNG tests or Jemmy tests or any other type of test out there we need to run (and is the same system used by OpenJDK). I mention this, although I am not going to do it yet (just in case those of you with loads of jtreg experience can help guide my way :-)). Richard On Feb 5, 2013, at 2:33 PM, Richard Bair wrote: > Refactor. We can put test helpers in the right package to access package private stuff. It is the same as with toolkit -- we're trying to remove those abstractions and have the scene graph side talk to glass / prism directly. As we do so we have to fix the tests as we go. > > On Feb 5, 2013, at 2:09 PM, Jim Graham wrote: > >> And when the impl_ methods go away, then what? >> >> ...jim >> >> On 2/5/13 1:43 PM, Richard Bair wrote: >>> All testing is only an approximation. Almost all of our unit tests are not black-box testing but white-box testing. SQE tests are presently black-box tests and they exercise the whole platform. We can run 20,000 unit tests in about the time it takes to run 50-100 SQE tests. There are other tradeoffs as well. For example the unit tests, when they fail, it is usually pretty easy to know what went wrong because you aren't testing very much of the platform -- only a very specific aspect of it (that is the inherent benefit of mocks). Black box testing on the other hand will find errors in places that you hadn't thought off, since it is testing more. Then again, when there is a failure, it is more work to diagnose where the failure occurred. And to do stringent testing takes many, many hours as often tests need to be fired up in separate VM's and will produce different results on different platforms, and you lose control of your OS while those tests run since it is actually driving the mo >> use / keyboard. >>> >>> So while there are downsides to using mocks like this, there are also upsides. I think you need both kinds of tests in the end. >>> >>> But this is really interim anyway. There is nothing in the NG nodes that dictates that we can't use them fully headless in a unit-test fashion. The problem is that javafx-sg-prism depends on javafx-ui-common, and we can't make javafx-ui-common (and all its tests) depend on javafx-sg-prism. In the "new world" I'm setting up, both of these projects (and a few others) will be merged into the "Graphics" component (module) and then we can get the tests cleaned up the right way. >>> >>> Richard >>> >>> On Feb 4, 2013, at 6:06 PM, Jim Graham wrote: >>> >>>> The problem with this approach is that you are testing PolygonMock instead of Polygon. Any bugs in the impl_ methods are untestable when you override them, and any future changes to Polygon which modify the way that the impl_ methods are used may introduce bugs that do not impact the testing you do with your Mock version because it hides those changes. >>>> >>>> Also, the impl_ methods are being slowly removed in favor of the Accessor paradigm. Many impl_ methods have already disappeared. These public implementation methods have always been a hack and they are currently only public (and overridable) because we haven't switched over to a better (and easier to keep secure in the long run) paradigm. Your testing methodology would require us to maintain implementation only methods as public interfaces which we are trying to move away from. >>>> >>>> If you are going to black box test the UI classes then you must treat them as a black box - that means using an external interface that is supported to instrument the testing. The only supported external interface we have is the Toolkit interface and the PG interfaces so you must continue to work behind those interfaces and evolve them if testing needs more instrumentation or you aren't really testing the UI classes, you are testing an approximation of them... >>>> >>>> ...jim >>>> >>>> On 2/4/13 7:41 AM, Richard Bair wrote: >>>>> Hi Pavel, >>>>> >>>>> Removing StubToolkit _does not imply_ that we have to test with a live toolkit / glass. For example, the PolygonTest wants to test that during synchronization the array of floats it expected to be passed to the peer is the actual set that got passed. >>>>> >>>>> @Test public void testBounds_oddPointsLength() { >>>>> final double[] initialPoints = { >>>>> 100, 100, 200, 100, 200, 200, 150, 300 >>>>> }; >>>>> >>>>> final Polygon polygon = new PolygonMock(initialPoints); >>>>> assertBoundsEqual(box(100, 100, 100, 200), polygon.getBoundsInLocal()); >>>>> >>>>> final ObservableList polygonPoints = polygon.getPoints(); >>>>> polygonPoints.remove(6); >>>>> >>>>> assertBoundsEqual(box(100, 100, 100, 100), polygon.getBoundsInLocal()); >>>>> } >>>>> >>>>> >>>>> This can easily be done by using a special subclass of Polygon that, in impl_createPGNode, creates a special subclass of NGPolygon: >>>>> >>>>> private static final class PolygonMock extends Polygon { >>>>> public PolygonMock() { >>>>> super(); >>>>> } >>>>> >>>>> public PolygonMock(double... points) { >>>>> super(points); >>>>> } >>>>> >>>>> @Override protected PGNode impl_createPGNode() { >>>>> return new StubPolygon(); >>>>> } >>>>> } >>>>> >>>>> private static final class StubPolygon extends NGPolygon { >>>>> float[] points; >>>>> @Override public void updatePolygon(float[] points) { >>>>> this.points = points; >>>>> super.updatePolygon(points); >>>>> } >>>>> } >>>>> >>>>> >>>>> Running this test does not require that we fire up multiple threads or open a glass window etc. >>>>> >>>>> I haven't finished combing through all the usages of StubToolkit, but I'm confident we can remove it without changing the nature of the tests. >>>>> >>>>> Richard >>>>> >>>>> On Feb 4, 2013, at 1:29 AM, Pavel Safrata wrote: >>>>> >>>>>> Hi Richard, >>>>>> I strongly object. I've had this discussion with Kevin a year ago, quoting myself from the old discussion: >>>>>> >>>>>> Scenegraph unit tests are there to test scenegraph. I believe that unit tests should by their definition test single units isolated from the rest of the system, not the system as a whole - for this we should have functional tests developed by QA. Our tests make sure that scenegraph works correctly given that the underlying platform behaves as expected. Including live toolkit/glass in running the tests would IMHO seriously damage purpose of those tests - they wouldn't give any reliable evidence of scenegraph's stability any more. Other important thing is that the code doesn't change over time (so it tests regressions in scenegraph) and also the test can make it behave in more different ways (and test scenegraph robustness). >>>>>> >>>>>> Thanks, >>>>>> Pavel >>>>>> >>>>>> On 2.2.2013 1:11, Richard Bair wrote: >>>>>>> Well, at least that is what I'm hoping to do. The problem is that we have a bunch of unit tests. 20K+. Some of them rely on StubToolkit, some of them rely on the real deal. In the "source cleanup" operation I'm on, when we combine all the "graphics" tests together, we have a problem where these two different types of tests are together and one set will fail to execute depending on whether we launch with the real toolkit or the stub toolkit. >>>>>>> >>>>>>> My plan is to yank out StubToolkit and update all the tests that relied on it to instead work with the real toolkit (quantum and prism). I suspect this is going to be painful. >>>>>>> >>>>>>> Richard >>>>>> >>>>> >>> From hang.vo at oracle.com Tue Feb 5 15:17:45 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 05 Feb 2013 23:17:45 +0000 Subject: hg: openjfx/8/controls/rt: RT-23091 PieChart data changed issue, Message-ID: <20130205231748.515464785C@hg.openjdk.java.net> Changeset: 7c234c222c85 Author: Paru Somashekar Date: 2013-02-05 15:18 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7c234c222c85 RT-23091 PieChart data changed issue, RT-24847 Grab testing NPE & RT-15291: Resetting data in LineChart issue ! javafx-ui-charts/src/javafx/scene/chart/LineChart.java ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java From hang.vo at oracle.com Tue Feb 5 16:03:33 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Feb 2013 00:03:33 +0000 Subject: hg: openjfx/8/graphics/rt: RT-27891 Multithreading issues in Quantum between user thread and rendering thread. Message-ID: <20130206000337.72A574785D@hg.openjdk.java.net> Changeset: 7132b587bdfb Author: David Hill Date: 2013-02-05 17:21 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7132b587bdfb RT-27891 Multithreading issues in Quantum between user thread and rendering thread. ! javafx-sg-prism/test/com/sun/javafx/sg/prism/TestGraphics.java From hang.vo at oracle.com Tue Feb 5 16:33:05 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Feb 2013 00:33:05 +0000 Subject: hg: openjfx/8/graphics/rt: Ignore all webrev related files in .hgignore Message-ID: <20130206003309.45EBD4785E@hg.openjdk.java.net> Changeset: 7500b8ef6c34 Author: flar Date: 2013-02-05 16:30 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7500b8ef6c34 Ignore all webrev related files in .hgignore ! .hgignore From hang.vo at oracle.com Tue Feb 5 17:17:53 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Feb 2013 01:17:53 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130206011758.5C10C4785F@hg.openjdk.java.net> Changeset: ffa3ff5846b9 Author: "Jasper Potts" Date: 2013-02-05 17:02 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ffa3ff5846b9 Modena test app, added new page and upated tests. ! apps/experiments/Modena/src/modena/Modena.java ! apps/experiments/Modena/src/modena/SamplePage.java ! apps/experiments/Modena/src/modena/SamplePageHelpers.java ! apps/experiments/Modena/src/modena/SimpleWindowPage.java ! apps/experiments/Modena/src/modena/TestApp.css ! apps/experiments/Modena/src/modena/simple-window.fxml ! apps/experiments/Modena/src/modena/simple-window.fxml.bak + apps/experiments/Modena/src/modena/ubuntu-window-frame.png ! apps/experiments/Modena/src/modena/ui-mosaic.fxml + apps/experiments/Modena/src/modena/ui-mosaic.fxml.bak + apps/experiments/Modena/src/modena/windows7-window-frame.png ! apps/experiments/Modena/src/modena/windows8-window-frame.png Changeset: 5fdb62478264 Author: "Jasper Potts" Date: 2013-02-05 17:02 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5fdb62478264 Modena theme, changed to less rounded corners and blue focus color. Lots of other little tweeks as a result ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From hang.vo at oracle.com Tue Feb 5 18:03:27 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Feb 2013 02:03:27 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28230: Media and Web need to be factored out of Prism Message-ID: <20130206020331.6CBBF47861@hg.openjdk.java.net> Changeset: ac6952f8fee4 Author: rbair Date: 2013-02-05 17:45 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ac6952f8fee4 RT-28230: Media and Web need to be factored out of Prism - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGMediaView.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGNode.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/PrismMediaFrameHandler.java ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java From hang.vo at oracle.com Tue Feb 5 18:48:09 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Feb 2013 02:48:09 +0000 Subject: hg: openjfx/8/graphics/rt: Partial RT-28089: Write Script to auto-generate the new repository layout Message-ID: <20130206024811.0D56B47864@hg.openjdk.java.net> Changeset: a0b4e4f589b5 Author: rbair Date: 2013-02-05 18:40 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a0b4e4f589b5 Partial RT-28089: Write Script to auto-generate the new repository layout Summary: Moved javafx-beans and javafx-embed-swing and javafx-embed-swt to the public gradle generator ! build.gradle ! generator.gradle From mohit.garg at appulse.com Wed Feb 6 01:20:34 2013 From: mohit.garg at appulse.com (Mohit Garg) Date: Wed, 6 Feb 2013 14:50:34 +0530 Subject: Hello Friends :) Message-ID: <001901ce044b$3aa73ce0$aff5b6a0$@appulse.com> Hello Friends, It's my first message to this mailing list. We are developing a product (Video Editor) in JavaFx for our client. We are facing some issues in the product. Would like to share with this community and get them resolved if possible. From hang.vo at oracle.com Wed Feb 6 04:33:08 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Feb 2013 12:33:08 +0000 Subject: hg: openjfx/8/graphics/rt: RT-26799 Implementation of the hasProperties() method of the Node class Message-ID: <20130206123312.1CFD447882@hg.openjdk.java.net> Changeset: 6af9a14ae71a Author: Martin Sladecek Date: 2013-02-06 13:22 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6af9a14ae71a RT-26799 Implementation of the hasProperties() method of the Node class ! javafx-ui-common/src/javafx/scene/Node.java From mohit.garg at appulse.com Wed Feb 6 04:53:00 2013 From: mohit.garg at appulse.com (Mohit Garg) Date: Wed, 6 Feb 2013 18:23:00 +0530 Subject: Problem Description : Seeking for guidance Message-ID: <00fc01ce0468$e7db4560$b791d020$@appulse.com> Hello all, We are developing a product since last 8 months . This product is a pretty basic video editor with mainly video cutting functionality. We chose JavaFx because the aim initially was to make a cross platform tool for Windows and Mac. Moreover it was also desired to run this application both as a desktop and as a web app. The good thing is that this product is running happily on Mac(with slight video seeking speed issue, anyways that's trivial for now) Now let's come to the problem part. The problem is windows. This product doesn't seem to fit for windows. On Windows when we launch the product it starts off cool, runs cool but as we start playing with the product virtual memory usage starts increasing(as visible from the task manager).As with any memory related problem we fired up the netbeans profiler, eclipse memory analyzer etc etc. After lots of analysis and grueling testing we decided that it's not the heap which is problem as heap is getting managed properly and profiler never showed heap going out of bounds. Moreover, we are not getting any OutOfMemoryException. The only thing we are getting is a crash, a proper windows process crash of java.exe with the following message : "Unspecified fatal error encountered, Aborting". As it is easy to guess, this message is not java/javafx specific ? Every time it crashes, windows points out to MSVCR100.dll file as fault module. As for the solution we have tried different profilers(but they are not helpful as problem seems to lie outside of profiler's scope) ? Can it be because of JNI calls Made by JVM/JavaFx library to render the video ? Or Display Driver ? I have tried dumping the java.exe process but couldn't find the required symbols to analyze in windbg or any other such debugging tool so that we could track down the error. We have also tried analyzing the heap memory of windows (and not java) using vmmap tool of sysinternals.com. This tool showed that there is continuous increase in windows heap memory with prolonged usage of the tool. This has hinted us that there is some memory leak in some native code but I am not very sure. We filed out a Jira about JavaFx Mediaview not closing file handles on video files even after playing is stopped(Initially we suspected this issue could be the cause of memory leak but even after getting around with this we couldn't stop leaking memory).Another activity which continually increases the memory usage is seeking of video file(and memory never comes down afterwards).However the problem escalated even more when I created a small testApp with no file handle issue(solved) and no seeking issue(no seeking used in testapp) but the memory was still leaking however slower than before. I am attaching the testApp link. This testapp is intended to play HD H.264 mp4 files which one can find everywhere. https://dl.dropbox.com/s/r9k32jpun3n8zri/TestApp.zip?dl=1 To reproduce the crash please run this on windows 7 machine. Load as many as 5 to 6 mp4 videos in the ListView and keep switching between videos rigorously. You can open the task manager in side and can view the continuous increase in virtual memory. I hope it will crash @ your end within minutes with same message "Unspecified fatal error encountered, Aborting". We are seriously stuck in this problem and looking for help from all veterans here. Please do the needful. Thanks in advance. Regards Mohit Garg From hang.vo at oracle.com Wed Feb 6 07:33:51 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Feb 2013 15:33:51 +0000 Subject: hg: openjfx/8/controls/rt: 31 new changesets Message-ID: <20130206153446.DAF4B47889@hg.openjdk.java.net> Changeset: 3565e21dd806 Author: Felipe Heidrich Date: 2013-01-29 14:41 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3565e21dd806 RT-26719: TextFlow doesn't provide a sensible minHeight(double) value ! javafx-ui-common/src/javafx/scene/text/TextFlow.java Changeset: 8e2421b550ae Author: Pavel Safrata Date: 2013-01-30 09:10 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8e2421b550ae RT-27087: added multiply(double) to points. ! javafx-ui-common/src/javafx/geometry/Point2D.java ! javafx-ui-common/src/javafx/geometry/Point3D.java ! javafx-ui-common/test/unit/javafx/geometry/Point2DTest.java ! javafx-ui-common/test/unit/javafx/geometry/Point3DTest.java Changeset: 1fa552fa870f Author: Richard Bair Date: 2013-01-30 09:32 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1fa552fa870f RT-18702: Add a ScheduledService which allows to auto-restart a service Summary: Added the ScheduledService -- we had previously discussed the API on openjfx-dev. Also added a pile of unit tests (nothing here for SQE to do as the concurrent classes are all tested via unit tests). + javafx-concurrent/src/javafx/concurrent/ScheduledService.java ! javafx-concurrent/src/javafx/concurrent/Service.java - javafx-concurrent/test/javafx/concurrent/AbstractService.java + javafx-concurrent/test/javafx/concurrent/ScheduledServiceTest.java ! javafx-concurrent/test/javafx/concurrent/ServiceExceptionTest.java ! javafx-concurrent/test/javafx/concurrent/ServiceLifecycleTest.java ! javafx-concurrent/test/javafx/concurrent/ServiceTest.java ! javafx-concurrent/test/javafx/concurrent/ServiceTestBase.java + javafx-concurrent/test/javafx/concurrent/TestServiceFactory.java Changeset: ec7e18a92765 Author: Richard Bair Date: 2013-01-30 09:34 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ec7e18a92765 RT-18820: Task needs to support incremental updates to the value Summary: Simply added a method updateValue and added documentation. Tests forthcoming. Tested manually using HelloTask (not checked in) which computed fib and constantly updated the window and it was great. ! javafx-concurrent/src/javafx/concurrent/Task.java ! javafx-concurrent/test/javafx/concurrent/TaskSwampEventQueueTest.java Changeset: ce7477ff2246 Author: prr Date: 2013-01-30 11:40 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ce7477ff2246 Fixed RT-28018: PageLayout constructor arg checking ! javafx-ui-common/src/javafx/print/PageLayout.java Changeset: e4577fd9c0f1 Author: Daniel Blaukopf Date: 2013-01-30 22:00 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e4577fd9c0f1 Fix for RT-28035 (Can't find embedded platform properties) and RT-27194 (Must set javafx.platform) ! javafx-common/src/com/sun/javafx/PlatformUtil.java Changeset: d36aa4dd0524 Author: Martin Sladecek Date: 2013-01-31 13:34 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d36aa4dd0524 RT-28066 Fix Tangent interpolator units + Javadoc update of Interpolator.TANGENT ! javafx-anim/src/com/sun/scenario/animation/NumberTangentInterpolator.java ! javafx-anim/src/com/sun/scenario/animation/shared/InterpolationInterval.java ! javafx-anim/src/javafx/animation/Interpolator.java + javafx-anim/src/javafx/animation/doc-files/tangent_interpolator.png ! javafx-anim/test/unit/com/sun/scenario/animation/NumberTangentInterpolatorTest.java ! javafx-anim/test/unit/javafx/animation/InterpolatorTest.java Changeset: 5a6d64b971ec Author: Martin Sladecek Date: 2013-01-31 13:35 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5a6d64b971ec merge Changeset: 9187bb46dd5f Author: Martin Sladecek Date: 2013-01-31 13:37 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9187bb46dd5f [JAVADOC] update of Interpolator javadoc ! javafx-anim/src/javafx/animation/Interpolator.java Changeset: a30a4db16376 Author: Martin Sladecek Date: 2013-01-31 13:37 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a30a4db16376 merge - apps/experiments/Modena/src/modena/Modena.css - javafx-concurrent/test/javafx/concurrent/AbstractService.java - javafx-ui-common/src/com/sun/javafx/css/parser/Css2Java.java - javafx-ui-common/test/unit/com/sun/javafx/test/OrientationHelper.java - javafx-ui-controls/src/com/preview/javafx/scene/control/DialogResources.java - javafx-ui-controls/src/com/preview/javafx/scene/control/DialogTemplate.java - javafx-ui-controls/src/com/preview/javafx/scene/control/Dialogs.java - javafx-ui-controls/src/com/preview/javafx/scene/control/ExceptionDialog.java - javafx-ui-controls/src/com/preview/javafx/scene/control/FXDialog.java - javafx-ui-controls/src/com/preview/javafx/scene/control/UITextArea.java - javafx-ui-controls/src/com/preview/javafx/scene/control/dialogs.css - javafx-ui-controls/src/com/sun/javafx/scene/control/FocusableTextField.java - javafx-ui-controls/src/javafx/scene/control/CellSpan.java - javafx-ui-controls/src/javafx/scene/control/SpanModel.java Changeset: 99aa53873cc0 Author: Felipe Heidrich Date: 2013-01-31 15:04 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/99aa53873cc0 RT-28099: Remove old/unused draw string code - part 1 - javafx-sg-common/src/com/sun/javafx/sg/PGText.java - javafx-sg-common/src/com/sun/javafx/sg/PGTextHelper.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGText.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGTextHelper.java ! javafx-sg-prism/test/com/sun/javafx/sg/prism/TestGraphics.java ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubText.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextHelper.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: e50a7a45723b Author: Felipe Heidrich Date: 2013-01-31 16:03 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e50a7a45723b RT-28099: Remove old/unused draw string code - part 2 - javafx-sg-common/src/com/sun/javafx/sg/PGSpan.java + javafx-sg-common/src/com/sun/javafx/sg/PGText.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGCanvas.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGSpan.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGText.java ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-common/src/javafx/scene/text/Text.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubSpan.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubText.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: 12bef5a3a874 Author: Martin Sladecek Date: 2013-02-01 15:34 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/12bef5a3a874 Fix for "coverage" target running on JDK7 ! build-defs.xml Changeset: f77dec4adb2a Author: Richard Bair Date: 2013-02-01 08:57 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f77dec4adb2a Partial RT-28089 Summary: Moved build.gradle & settings.gradle to rt. renamed generator.gradle to build.gradle. + build.gradle + settings.gradle Changeset: 871e03bb7fb9 Author: Richard Bair Date: 2013-02-01 09:19 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/871e03bb7fb9 Partial RT-28089 Summary: Added open portion of generator script. Will generate a new "javafx" directory that is a sibling of "rt" + generator.gradle Changeset: 4499eedd0789 Author: Richard Bair Date: 2013-02-01 10:26 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4499eedd0789 Partial RT-28089 Summary: Fixed so that it generates correctly whether run from rt or run from the closed build file that includes all the closed sources. ! generator.gradle Changeset: 7721377d1f70 Author: jgodinez Date: 2013-02-01 11:25 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7721377d1f70 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-concurrent/test/javafx/concurrent/AbstractService.java - javafx-sg-common/src/com/sun/javafx/sg/PGSpan.java ! javafx-sg-common/src/com/sun/javafx/sg/PGText.java - javafx-sg-common/src/com/sun/javafx/sg/PGTextHelper.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGSpan.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGText.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGTextHelper.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/src/javafx/scene/text/TextFlow.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubSpan.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubText.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextHelper.java Changeset: dd34f7bd08cd Author: Richard Bair Date: 2013-02-01 16:14 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/dd34f7bd08cd Partial RT-28089 Summary: Added the graphics tests. They don't execute unfortunately, silly old StubToolkit. ! build.gradle ! generator.gradle Changeset: fa747ba3156b Author: Artem Ananiev Date: 2013-02-04 15:12 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fa747ba3156b Fix for RT-28165: Move javafx-embed-swing and javafx-embed-swt to open Reviewed-by: Kevin Rushforth ! .classpath ! .idea/modules.xml ! build.xml + javafx-embed-swing/build-closed.xml + javafx-embed-swing/build-common.xml + javafx-embed-swing/build.xml + javafx-embed-swing/javafx-embed-swing.iml + javafx-embed-swing/nbproject/project.xml + javafx-embed-swing/project.properties + javafx-embed-swing/src/javafx/embed/swing/DataFlavorUtils.java + javafx-embed-swing/src/javafx/embed/swing/JFXPanel.java + javafx-embed-swing/src/javafx/embed/swing/SwingCursors.java + javafx-embed-swing/src/javafx/embed/swing/SwingDnD.java + javafx-embed-swing/src/javafx/embed/swing/SwingDragSource.java + javafx-embed-swing/src/javafx/embed/swing/SwingEvents.java + javafx-embed-swing/src/javafx/embed/swing/SwingFXUtils.java + javafx-embed-swing/src/javafx/embed/swing/package.html + javafx-embed-swt/build-closed.xml + javafx-embed-swt/build-common.xml + javafx-embed-swt/build.xml + javafx-embed-swt/javafx-embed-swt.iml + javafx-embed-swt/nbproject/project.xml + javafx-embed-swt/project.properties + javafx-embed-swt/src/javafx/embed/swt/CustomTransfer.java + javafx-embed-swt/src/javafx/embed/swt/FXCanvas.java + javafx-embed-swt/src/javafx/embed/swt/SWTCursors.java + javafx-embed-swt/src/javafx/embed/swt/SWTEvents.java + javafx-embed-swt/src/javafx/embed/swt/SWTFXUtils.java + javafx-embed-swt/src/javafx/embed/swt/package.html Changeset: c2fb1c411133 Author: Martin Sladecek Date: 2013-02-04 14:18 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c2fb1c411133 RT-28166 Animation methods accept illegal Duration values that are not expected in the Animation code. ! javafx-anim/src/javafx/animation/Animation.java ! javafx-anim/src/javafx/animation/Timeline.java ! javafx-ui-common/src/javafx/animation/FadeTransition.java ! javafx-ui-common/src/javafx/animation/FillTransition.java ! javafx-ui-common/src/javafx/animation/PathTransition.java ! javafx-ui-common/src/javafx/animation/PauseTransition.java ! javafx-ui-common/src/javafx/animation/RotateTransition.java ! javafx-ui-common/src/javafx/animation/ScaleTransition.java ! javafx-ui-common/src/javafx/animation/StrokeTransition.java ! javafx-ui-common/src/javafx/animation/TranslateTransition.java Changeset: 7425eab5722d Author: Martin Sladecek Date: 2013-02-04 14:25 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7425eab5722d merge Changeset: 2a0b0d0d4dd1 Author: Eva Krejcirova Date: 2013-02-04 16:29 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2a0b0d0d4dd1 RT-14730: Drag and drop needs support for drag view. Reviewed by Pavel Safrata ! javafx-ui-common/src/com/sun/javafx/tk/TKClipboard.java ! javafx-ui-common/src/javafx/scene/input/DataFormat.java ! javafx-ui-common/src/javafx/scene/input/Dragboard.java ! javafx-ui-common/test/unit/javafx/scene/input/DragAndDropTest.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: d715d9ce4dff Author: Martin Sladecek Date: 2013-02-04 17:09 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d715d9ce4dff Fixed failing tests ! javafx-anim/src/javafx/animation/Animation.java Changeset: d5735f8fd0a7 Author: Martin Sladecek Date: 2013-02-04 17:09 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d5735f8fd0a7 merge Changeset: 012c2fd4a6f9 Author: jgodinez Date: 2013-02-04 10:47 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/012c2fd4a6f9 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt - javafx-concurrent/test/javafx/concurrent/AbstractService.java - javafx-sg-common/src/com/sun/javafx/sg/PGSpan.java - javafx-sg-common/src/com/sun/javafx/sg/PGTextHelper.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGSpan.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGTextHelper.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubSpan.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextHelper.java Changeset: 41487f55d1d2 Author: "Joseph Andresen" Date: 2013-02-04 14:34 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/41487f55d1d2 RT-25354 ImagePattern does not track changes ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGRegion.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGShape.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-common/src/javafx/scene/ImageCursor.java ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java ! javafx-ui-common/src/javafx/scene/effect/ColorInput.java ! javafx-ui-common/src/javafx/scene/image/Image.java ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/src/javafx/scene/image/WritableImage.java ! javafx-ui-common/src/javafx/scene/paint/Color.java ! javafx-ui-common/src/javafx/scene/paint/ImagePattern.java ! javafx-ui-common/src/javafx/scene/paint/LinearGradient.java ! javafx-ui-common/src/javafx/scene/paint/Paint.java ! javafx-ui-common/src/javafx/scene/paint/RadialGradient.java ! javafx-ui-common/src/javafx/scene/shape/Shape.java ! javafx-ui-common/src/javafx/scene/text/Text.java Changeset: 254f69a9f5d5 Author: flar Date: 2013-02-04 17:59 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/254f69a9f5d5 Fix tests broken by fix for RT-25354 ! javafx-ui-common/test/unit/javafx/scene/effect/ColorInputTest.java ! javafx-ui-common/test/unit/javafx/scene/image/ImageTest.java ! javafx-ui-common/test/unit/javafx/scene/paint/ImagePatternTest.java ! javafx-ui-common/test/unit/javafx/scene/paint/LinearGradientTest.java ! javafx-ui-common/test/unit/javafx/scene/paint/RadialGradientTest.java Changeset: 9daaff7ef6d5 Author: Martin Sladecek Date: 2013-02-05 09:47 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9daaff7ef6d5 Open-source of javafx-beans ! build.xml ! common.properties ! javafx-anim/build-closed.xml ! javafx-annotation-processor/build-closed.xml ! javafx-annotation-processor/nbproject/project.xml ! javafx-beans-dt/build-closed.xml ! javafx-beans-dt/project.properties + javafx-beans/build-closed.xml + javafx-beans/build-common.xml + javafx-beans/build.xml + javafx-beans/jar.jardesc + javafx-beans/javafx-beans.iml + javafx-beans/nbproject/project.xml + javafx-beans/project.properties + javafx-beans/src/com/sun/javafx/beans/IDProperty.java + javafx-beans/src/com/sun/javafx/beans/annotations/Default.java + javafx-beans/src/com/sun/javafx/beans/annotations/Delegate.java + javafx-beans/src/com/sun/javafx/beans/annotations/DuplicateInBuilderProperties.java + javafx-beans/src/com/sun/javafx/beans/annotations/NoBuilder.java + javafx-beans/src/com/sun/javafx/beans/annotations/NoInit.java + javafx-beans/src/com/sun/javafx/beans/annotations/NonNull.java + javafx-beans/src/com/sun/javafx/binding/BidirectionalBinding.java + javafx-beans/src/com/sun/javafx/binding/BidirectionalContentBinding.java + javafx-beans/src/com/sun/javafx/binding/BindingHelperObserver.java + javafx-beans/src/com/sun/javafx/binding/ContentBinding.java + javafx-beans/src/com/sun/javafx/binding/DoubleConstant.java + javafx-beans/src/com/sun/javafx/binding/ExpressionHelper.java + javafx-beans/src/com/sun/javafx/binding/ExpressionHelperBase.java + javafx-beans/src/com/sun/javafx/binding/FloatConstant.java + javafx-beans/src/com/sun/javafx/binding/IntegerConstant.java + javafx-beans/src/com/sun/javafx/binding/ListExpressionHelper.java + javafx-beans/src/com/sun/javafx/binding/Logging.java + javafx-beans/src/com/sun/javafx/binding/LongConstant.java + javafx-beans/src/com/sun/javafx/binding/MapExpressionHelper.java + javafx-beans/src/com/sun/javafx/binding/ObjectConstant.java + javafx-beans/src/com/sun/javafx/binding/SelectBinding.java + javafx-beans/src/com/sun/javafx/binding/SetExpressionHelper.java + javafx-beans/src/com/sun/javafx/binding/StringConstant.java + javafx-beans/src/com/sun/javafx/binding/StringFormatter.java + javafx-beans/src/com/sun/javafx/collections/BaseModifiableObservableList.java + javafx-beans/src/com/sun/javafx/collections/BaseObservableList.java + javafx-beans/src/com/sun/javafx/collections/ChangeHelper.java + javafx-beans/src/com/sun/javafx/collections/ElementObservableListDecorator.java + javafx-beans/src/com/sun/javafx/collections/ElementObserver.java + javafx-beans/src/com/sun/javafx/collections/ImmutableObservableList.java + javafx-beans/src/com/sun/javafx/collections/ListChangeBuilder.java + javafx-beans/src/com/sun/javafx/collections/ListListenerHelper.java + javafx-beans/src/com/sun/javafx/collections/MapAdapterChange.java + javafx-beans/src/com/sun/javafx/collections/MapListenerHelper.java + javafx-beans/src/com/sun/javafx/collections/MappingChange.java + javafx-beans/src/com/sun/javafx/collections/NonIterableChange.java + javafx-beans/src/com/sun/javafx/collections/ObservableListWrapper.java + javafx-beans/src/com/sun/javafx/collections/ObservableMapWrapper.java + javafx-beans/src/com/sun/javafx/collections/ObservableSetWrapper.java + javafx-beans/src/com/sun/javafx/collections/SetAdapterChange.java + javafx-beans/src/com/sun/javafx/collections/SetListenerHelper.java + javafx-beans/src/com/sun/javafx/collections/SortHelper.java + javafx-beans/src/com/sun/javafx/collections/SortableList.java + javafx-beans/src/com/sun/javafx/collections/SourceAdapterChange.java + javafx-beans/src/com/sun/javafx/collections/TrackableObservableList.java + javafx-beans/src/com/sun/javafx/collections/UnmodifiableListSet.java + javafx-beans/src/com/sun/javafx/collections/UnmodifiableObservableMap.java + javafx-beans/src/com/sun/javafx/collections/VetoableListDecorator.java + javafx-beans/src/com/sun/javafx/collections/annotations/ReturnsUnmodifiableCollection.java + javafx-beans/src/com/sun/javafx/collections/transformation/FilterableList.java + javafx-beans/src/com/sun/javafx/collections/transformation/FilteredList.java + javafx-beans/src/com/sun/javafx/collections/transformation/Matcher.java + javafx-beans/src/com/sun/javafx/collections/transformation/SortableList.java + javafx-beans/src/com/sun/javafx/collections/transformation/SortedList.java + javafx-beans/src/com/sun/javafx/collections/transformation/TransformationList.java + javafx-beans/src/com/sun/javafx/property/PropertyReference.java + javafx-beans/src/com/sun/javafx/property/adapter/JavaBeanPropertyBuilderHelper.java + javafx-beans/src/com/sun/javafx/property/adapter/PropertyDescriptor.java + javafx-beans/src/com/sun/javafx/property/adapter/ReadOnlyJavaBeanPropertyBuilderHelper.java + javafx-beans/src/com/sun/javafx/property/adapter/ReadOnlyPropertyDescriptor.java + javafx-beans/src/javafx/beans/DefaultProperty.java + javafx-beans/src/javafx/beans/InvalidationListener.java + javafx-beans/src/javafx/beans/Observable.java + javafx-beans/src/javafx/beans/WeakInvalidationListener.java + javafx-beans/src/javafx/beans/WeakListener.java + javafx-beans/src/javafx/beans/binding/Binding.java + javafx-beans/src/javafx/beans/binding/Bindings.java + javafx-beans/src/javafx/beans/binding/BooleanBinding.java + javafx-beans/src/javafx/beans/binding/BooleanExpression.java + javafx-beans/src/javafx/beans/binding/DoubleBinding.java + javafx-beans/src/javafx/beans/binding/DoubleExpression.java + javafx-beans/src/javafx/beans/binding/FloatBinding.java + javafx-beans/src/javafx/beans/binding/FloatExpression.java + javafx-beans/src/javafx/beans/binding/IntegerBinding.java + javafx-beans/src/javafx/beans/binding/IntegerExpression.java + javafx-beans/src/javafx/beans/binding/ListBinding.java + javafx-beans/src/javafx/beans/binding/ListExpression.java + javafx-beans/src/javafx/beans/binding/LongBinding.java + javafx-beans/src/javafx/beans/binding/LongExpression.java + javafx-beans/src/javafx/beans/binding/MapBinding.java + javafx-beans/src/javafx/beans/binding/MapExpression.java + javafx-beans/src/javafx/beans/binding/NumberBinding.java + javafx-beans/src/javafx/beans/binding/NumberExpression.java + javafx-beans/src/javafx/beans/binding/NumberExpressionBase.java + javafx-beans/src/javafx/beans/binding/ObjectBinding.java + javafx-beans/src/javafx/beans/binding/ObjectExpression.java + javafx-beans/src/javafx/beans/binding/SetBinding.java + javafx-beans/src/javafx/beans/binding/SetExpression.java + javafx-beans/src/javafx/beans/binding/StringBinding.java + javafx-beans/src/javafx/beans/binding/StringExpression.java + javafx-beans/src/javafx/beans/binding/When.java + javafx-beans/src/javafx/beans/binding/package.html + javafx-beans/src/javafx/beans/package.html + javafx-beans/src/javafx/beans/property/BooleanProperty.java + javafx-beans/src/javafx/beans/property/BooleanPropertyBase.java + javafx-beans/src/javafx/beans/property/DoubleProperty.java + javafx-beans/src/javafx/beans/property/DoublePropertyBase.java + javafx-beans/src/javafx/beans/property/FloatProperty.java + javafx-beans/src/javafx/beans/property/FloatPropertyBase.java + javafx-beans/src/javafx/beans/property/IntegerProperty.java + javafx-beans/src/javafx/beans/property/IntegerPropertyBase.java + javafx-beans/src/javafx/beans/property/ListProperty.java + javafx-beans/src/javafx/beans/property/ListPropertyBase.java + javafx-beans/src/javafx/beans/property/LongProperty.java + javafx-beans/src/javafx/beans/property/LongPropertyBase.java + javafx-beans/src/javafx/beans/property/MapProperty.java + javafx-beans/src/javafx/beans/property/MapPropertyBase.java + javafx-beans/src/javafx/beans/property/ObjectProperty.java + javafx-beans/src/javafx/beans/property/ObjectPropertyBase.java + javafx-beans/src/javafx/beans/property/Property.java + javafx-beans/src/javafx/beans/property/ReadOnlyBooleanProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyBooleanPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyBooleanWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyDoubleProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyDoublePropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyDoubleWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyFloatProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyFloatPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyFloatWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyIntegerProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyIntegerPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyIntegerWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyListProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyListPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyListWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyLongProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyLongPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyLongWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyMapProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyMapPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyMapWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyObjectProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyObjectPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyObjectWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlySetProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlySetPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlySetWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyStringProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyStringPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyStringWrapper.java + javafx-beans/src/javafx/beans/property/SetProperty.java + javafx-beans/src/javafx/beans/property/SetPropertyBase.java + javafx-beans/src/javafx/beans/property/SimpleBooleanProperty.java + javafx-beans/src/javafx/beans/property/SimpleDoubleProperty.java + javafx-beans/src/javafx/beans/property/SimpleFloatProperty.java + javafx-beans/src/javafx/beans/property/SimpleIntegerProperty.java + javafx-beans/src/javafx/beans/property/SimpleListProperty.java + javafx-beans/src/javafx/beans/property/SimpleLongProperty.java + javafx-beans/src/javafx/beans/property/SimpleMapProperty.java + javafx-beans/src/javafx/beans/property/SimpleObjectProperty.java + javafx-beans/src/javafx/beans/property/SimpleSetProperty.java + javafx-beans/src/javafx/beans/property/SimpleStringProperty.java + javafx-beans/src/javafx/beans/property/StringProperty.java + javafx-beans/src/javafx/beans/property/StringPropertyBase.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanBooleanProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanBooleanPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanDoubleProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanDoublePropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanFloatProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanFloatPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanIntegerProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanIntegerPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanLongProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanLongPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanObjectProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanObjectPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanStringProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanStringPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanBooleanProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanBooleanPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanDoubleProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanDoublePropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanFloatProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanFloatPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanIntegerProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanIntegerPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanLongProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanLongPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanObjectProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanObjectPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanStringProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanStringPropertyBuilder.java + javafx-beans/src/javafx/beans/property/package.html + javafx-beans/src/javafx/beans/value/ChangeListener.java + javafx-beans/src/javafx/beans/value/ObservableBooleanValue.java + javafx-beans/src/javafx/beans/value/ObservableDoubleValue.java + javafx-beans/src/javafx/beans/value/ObservableFloatValue.java + javafx-beans/src/javafx/beans/value/ObservableIntegerValue.java + javafx-beans/src/javafx/beans/value/ObservableListValue.java + javafx-beans/src/javafx/beans/value/ObservableLongValue.java + javafx-beans/src/javafx/beans/value/ObservableMapValue.java + javafx-beans/src/javafx/beans/value/ObservableNumberValue.java + javafx-beans/src/javafx/beans/value/ObservableObjectValue.java + javafx-beans/src/javafx/beans/value/ObservableSetValue.java + javafx-beans/src/javafx/beans/value/ObservableStringValue.java + javafx-beans/src/javafx/beans/value/ObservableValue.java + javafx-beans/src/javafx/beans/value/ObservableValueBase.java + javafx-beans/src/javafx/beans/value/WeakChangeListener.java + javafx-beans/src/javafx/beans/value/WritableBooleanValue.java + javafx-beans/src/javafx/beans/value/WritableDoubleValue.java + javafx-beans/src/javafx/beans/value/WritableFloatValue.java + javafx-beans/src/javafx/beans/value/WritableIntegerValue.java + javafx-beans/src/javafx/beans/value/WritableListValue.java + javafx-beans/src/javafx/beans/value/WritableLongValue.java + javafx-beans/src/javafx/beans/value/WritableMapValue.java + javafx-beans/src/javafx/beans/value/WritableNumberValue.java + javafx-beans/src/javafx/beans/value/WritableObjectValue.java + javafx-beans/src/javafx/beans/value/WritableSetValue.java + javafx-beans/src/javafx/beans/value/WritableStringValue.java + javafx-beans/src/javafx/beans/value/WritableValue.java + javafx-beans/src/javafx/beans/value/package.html + javafx-beans/src/javafx/collections/FXCollections.java + javafx-beans/src/javafx/collections/ListChangeListener.java + javafx-beans/src/javafx/collections/MapChangeListener.java + javafx-beans/src/javafx/collections/ObservableList.java + javafx-beans/src/javafx/collections/ObservableMap.java + javafx-beans/src/javafx/collections/ObservableSet.java + javafx-beans/src/javafx/collections/SetChangeListener.java + javafx-beans/src/javafx/collections/WeakListChangeListener.java + javafx-beans/src/javafx/collections/WeakMapChangeListener.java + javafx-beans/src/javafx/collections/WeakSetChangeListener.java + javafx-beans/src/javafx/collections/package.html + javafx-beans/test/com/sun/javafx/binding/BidirectionalBindingTest.java + javafx-beans/test/com/sun/javafx/binding/BidirectionalBindingWithConversionTest.java + javafx-beans/test/com/sun/javafx/binding/BidirectionalContentBindingListTest.java + javafx-beans/test/com/sun/javafx/binding/BidirectionalContentBindingMapTest.java + javafx-beans/test/com/sun/javafx/binding/BidirectionalContentBindingSetTest.java + javafx-beans/test/com/sun/javafx/binding/ContentBindingListTest.java + javafx-beans/test/com/sun/javafx/binding/ContentBindingMapTest.java + javafx-beans/test/com/sun/javafx/binding/ContentBindingSetTest.java + javafx-beans/test/com/sun/javafx/binding/ErrorLoggingUtiltity.java + javafx-beans/test/com/sun/javafx/binding/ExpressionHelperBaseTest.java + javafx-beans/test/com/sun/javafx/binding/ExpressionHelperTest.java + javafx-beans/test/com/sun/javafx/binding/ExpressionHelperUtility.java + javafx-beans/test/com/sun/javafx/binding/ExpressionHelperUtilityTest.java + javafx-beans/test/com/sun/javafx/binding/ListExpressionHelperTest.java + javafx-beans/test/com/sun/javafx/binding/SelectBindingTest.java + javafx-beans/test/com/sun/javafx/binding/StringFormatterTest.java + javafx-beans/test/com/sun/javafx/collections/ListChangeBuilderTest.java + javafx-beans/test/com/sun/javafx/collections/ListListenerHelperTest.java + javafx-beans/test/com/sun/javafx/collections/MapListenerHelperTest.java + javafx-beans/test/com/sun/javafx/collections/SetListenerHelperTest.java + javafx-beans/test/com/sun/javafx/property/adapter/JavaBeanPropertyBuilderHelperTest.java + javafx-beans/test/com/sun/javafx/property/adapter/PropertyDescriptorTest.java + javafx-beans/test/com/sun/javafx/property/adapter/ReadOnlyPropertyDescriptorTest.java + javafx-beans/test/javafx/beans/Foo.java + javafx-beans/test/javafx/beans/InvalidationListenerMock.java + javafx-beans/test/javafx/beans/Person.java + javafx-beans/test/javafx/beans/WeakInvalidationListenerMock.java + javafx-beans/test/javafx/beans/WeakInvalidationListenerTest.java + javafx-beans/test/javafx/beans/property/BooleanPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/BooleanPropertyTest.java + javafx-beans/test/javafx/beans/property/DoublePropertyBaseTest.java + javafx-beans/test/javafx/beans/property/DoublePropertyTest.java + javafx-beans/test/javafx/beans/property/FloatPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/FloatPropertyTest.java + javafx-beans/test/javafx/beans/property/IntegerPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/IntegerPropertyTest.java + javafx-beans/test/javafx/beans/property/ListPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ListPropertyTest.java + javafx-beans/test/javafx/beans/property/LongPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/LongPropertyTest.java + javafx-beans/test/javafx/beans/property/MapPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/MapPropertyTest.java + javafx-beans/test/javafx/beans/property/ObjectPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ObjectPropertyTest.java + javafx-beans/test/javafx/beans/property/PropertiesTest.java + javafx-beans/test/javafx/beans/property/PropertyReferenceTest.java + javafx-beans/test/javafx/beans/property/PropertyReferenceWithInterfacesTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyBooleanPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyBooleanPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyBooleanWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyDoublePropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyDoublePropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyDoubleWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyFloatPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyFloatPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyFloatWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyIntegerPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyIntegerPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyIntegerWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyListPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyListPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyListWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyLongPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyLongPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyLongWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyMapPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyMapPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyMapWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyObjectPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyObjectPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyObjectWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlySetPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlySetPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlySetWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyStringPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyStringPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyStringWrapperTest.java + javafx-beans/test/javafx/beans/property/SetPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/SetPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleBooleanPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleDoublePropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleFloatPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleIntegerPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleListPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleLongPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleObjectPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleStringPropertyTest.java + javafx-beans/test/javafx/beans/property/StringPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/StringPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanBooleanPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanBooleanProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanDoublePropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanDoubleProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanFloatPropertyBuilderaTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanFloatProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanIntegerPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanIntegerProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanLongPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanLongProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanObjectPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanPropertyTestBase.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanStringPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanBooleanPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanBooleanProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanDoublePropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanDoubleProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanFloatPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanFloatProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanIntegerPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanIntegerProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanLongPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanLongProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanObjectPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanPropertyBuilder_General_Test.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanPropertyTestBase.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanStringPropertyTest.java + javafx-beans/test/javafx/beans/value/ChangeListenerMock.java + javafx-beans/test/javafx/beans/value/ObservableBooleanValueStub.java + javafx-beans/test/javafx/beans/value/ObservableDoubleValueStub.java + javafx-beans/test/javafx/beans/value/ObservableFloatValueStub.java + javafx-beans/test/javafx/beans/value/ObservableIntegerValueStub.java + javafx-beans/test/javafx/beans/value/ObservableLongValueStub.java + javafx-beans/test/javafx/beans/value/ObservableObjectValueStub.java + javafx-beans/test/javafx/beans/value/ObservableStringValueStub.java + javafx-beans/test/javafx/beans/value/ObservableValueBaseTest.java + javafx-beans/test/javafx/beans/value/ObservableValueStub.java + javafx-beans/test/javafx/beans/value/WeakChangeListenerMock.java + javafx-beans/test/javafx/beans/value/WeakChangeListenerTest.java + javafx-beans/test/javafx/binding/BindingToStringTest.java + javafx-beans/test/javafx/binding/BindingsBooleanTest.java + javafx-beans/test/javafx/binding/BindingsCreateBindingTest.java + javafx-beans/test/javafx/binding/BindingsEqualsTest.java + javafx-beans/test/javafx/binding/BindingsIsNullTest.java + javafx-beans/test/javafx/binding/BindingsListTest.java + javafx-beans/test/javafx/binding/BindingsMapTest.java + javafx-beans/test/javafx/binding/BindingsNumberCalculationsTest.java + javafx-beans/test/javafx/binding/BindingsNumberCastTest.java + javafx-beans/test/javafx/binding/BindingsSetTest.java + javafx-beans/test/javafx/binding/DependencyUtils.java + javafx-beans/test/javafx/binding/GenericBindingTest.java + javafx-beans/test/javafx/binding/ListBindingTest.java + javafx-beans/test/javafx/binding/MapBindingTest.java + javafx-beans/test/javafx/binding/SetBindingTest.java + javafx-beans/test/javafx/binding/Variable.java + javafx-beans/test/javafx/binding/WhenTestBase.java + javafx-beans/test/javafx/binding/When_Boolean_Test.java + javafx-beans/test/javafx/binding/When_Double_Test.java + javafx-beans/test/javafx/binding/When_Float_Test.java + javafx-beans/test/javafx/binding/When_Integer_Test.java + javafx-beans/test/javafx/binding/When_Long_Test.java + javafx-beans/test/javafx/binding/When_Object_Test.java + javafx-beans/test/javafx/binding/When_String_Test.java + javafx-beans/test/javafx/binding/expression/AbstractNumberExpressionTest.java + javafx-beans/test/javafx/binding/expression/BooleanExpressionTest.java + javafx-beans/test/javafx/binding/expression/DoubleExpressionTest.java + javafx-beans/test/javafx/binding/expression/FloatExpressionTest.java + javafx-beans/test/javafx/binding/expression/IntegerExpressionTest.java + javafx-beans/test/javafx/binding/expression/ListExpressionTest.java + javafx-beans/test/javafx/binding/expression/LongExpressionTest.java + javafx-beans/test/javafx/binding/expression/MapExpressionTest.java + javafx-beans/test/javafx/binding/expression/ObjectExpressionTest.java + javafx-beans/test/javafx/binding/expression/SetExpressionTest.java + javafx-beans/test/javafx/binding/expression/StringExpressionTest.java + javafx-beans/test/javafx/collections/Callable.java + javafx-beans/test/javafx/collections/FXCollectionsTest.java + javafx-beans/test/javafx/collections/FilteredListTest.java + javafx-beans/test/javafx/collections/MockListObserver.java + javafx-beans/test/javafx/collections/MockMapObserver.java + javafx-beans/test/javafx/collections/MockSetObserver.java + javafx-beans/test/javafx/collections/ObservableListIteratorTestBase.java + javafx-beans/test/javafx/collections/ObservableListIterator_P1_Test.java + javafx-beans/test/javafx/collections/ObservableListIterator_P2_Test.java + javafx-beans/test/javafx/collections/ObservableListIterator_P3_Test.java + javafx-beans/test/javafx/collections/ObservableListTestBase.java + javafx-beans/test/javafx/collections/ObservableListTestBase_Empty.java + javafx-beans/test/javafx/collections/ObservableListWithExtractor.java + javafx-beans/test/javafx/collections/ObservableList_Empty_P1_Test.java + javafx-beans/test/javafx/collections/ObservableList_Empty_P2_Test.java + javafx-beans/test/javafx/collections/ObservableList_Empty_P3_Test.java + javafx-beans/test/javafx/collections/ObservableList_P1_Test.java + javafx-beans/test/javafx/collections/ObservableList_P2_Test.java + javafx-beans/test/javafx/collections/ObservableList_P3_Test.java + javafx-beans/test/javafx/collections/ObservableMapTestBase.java + javafx-beans/test/javafx/collections/ObservableMap_P1_Test.java + javafx-beans/test/javafx/collections/ObservableMap_P2_Test.java + javafx-beans/test/javafx/collections/ObservableMap_P3_Test.java + javafx-beans/test/javafx/collections/ObservableMap_P4_Test.java + javafx-beans/test/javafx/collections/ObservableSetTestBase.java + javafx-beans/test/javafx/collections/ObservableSet_P1_Test.java + javafx-beans/test/javafx/collections/ObservableSet_P2_Test.java + javafx-beans/test/javafx/collections/ObservableSet_P3_Test.java + javafx-beans/test/javafx/collections/ObservableSubListIteratorTestBase.java + javafx-beans/test/javafx/collections/ObservableSubListIterator_P1_Test.java + javafx-beans/test/javafx/collections/ObservableSubListIterator_P2_Test.java + javafx-beans/test/javafx/collections/ObservableSubListIterator_P3_Test.java + javafx-beans/test/javafx/collections/ObservableSubListTestBase.java + javafx-beans/test/javafx/collections/ObservableSubList_P1_Test.java + javafx-beans/test/javafx/collections/ObservableSubList_P2_Test.java + javafx-beans/test/javafx/collections/ObservableSubList_P3_Test.java + javafx-beans/test/javafx/collections/Person.java + javafx-beans/test/javafx/collections/SortedListTest.java + javafx-beans/test/javafx/collections/TestedObservableLists.java + javafx-beans/test/javafx/collections/TransformationListTest.java + javafx-beans/test/javafx/collections/UnmodifiableObservableMapTestBase.java + javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P1_Test.java + javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P2_Test.java + javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P3_Test.java + javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P4_Test.java + javafx-beans/test/javafx/collections/VetoableObservableListTest.java + javafx-beans/test/javafx/collections/WeakListChangeListenerMock.java + javafx-beans/test/javafx/collections/WeakListChangeListenerTest.java + javafx-beans/test/javafx/collections/WeakMapChangeListenerTest.java + javafx-beans/test/javafx/collections/WeakSetChangeListenerTest.java ! javafx-concurrent/build-closed.xml ! javafx-concurrent/project.properties ! javafx-designtime/build-closed.xml ! javafx-fxml/build-closed.xml ! javafx-fxml/nbproject/project.xml ! javafx-sg-common/project.properties ! javafx-ui-charts/build-closed.xml ! javafx-ui-common/build-closed.xml ! javafx-ui-common/nbproject/project.xml ! javafx-ui-controls/build-closed.xml ! javafx-ui-controls/build-common.xml ! javafx-util-converter/build-closed.xml Changeset: e573fa389ba7 Author: Radko Najman Date: 2013-02-05 13:45 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e573fa389ba7 RT-16008: Dirty region of nodes under group with effect should adjust itself so that it covers every affected pixels ! javafx-geom/src/com/sun/javafx/geom/BaseBounds.java ! javafx-geom/src/com/sun/javafx/geom/BoxBounds.java + javafx-geom/src/com/sun/javafx/geom/DirtyRegionContainer.java + javafx-geom/src/com/sun/javafx/geom/DirtyRegionPool.java ! javafx-geom/src/com/sun/javafx/geom/RectBounds.java + javafx-geom/test/com/sun/javafx/geom/DirtyRegionContainerTest.java ! javafx-sg-common/src/com/sun/javafx/sg/BaseNode.java - javafx-sg-common/src/com/sun/javafx/sg/DirtyRegionContainer.java - javafx-sg-common/src/com/sun/javafx/sg/DirtyRegionPool.java ! javafx-sg-common/test/com/sun/javafx/sg/CullingTest.java - javafx-sg-common/test/com/sun/javafx/sg/DirtyRegionContainerTest.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGCanvas.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGGroup.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGNode.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NodeEffectInput.java ! javafx-sg-prism/test/com/sun/javafx/sg/prism/DirtyRegionTestBase.java ! javafx-sg-prism/test/com/sun/javafx/sg/prism/NodeTestUtils.java Changeset: db6fc38a2116 Author: flar Date: 2013-02-05 09:28 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/db6fc38a2116 Fix RT-27964 - Load HiDPI images when available on HiDPI displays ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGCanvas.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGImageView.java ! javafx-ui-common/src/com/sun/javafx/tk/PlatformImage.java ! javafx-ui-common/src/javafx/scene/image/Image.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubFilterable.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubPlatformImage.java Changeset: 27a5dff62edc Author: David Grieve Date: 2013-02-06 10:28 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/27a5dff62edc branch merge - javafx-concurrent/test/javafx/concurrent/AbstractService.java - javafx-sg-common/src/com/sun/javafx/sg/DirtyRegionContainer.java - javafx-sg-common/src/com/sun/javafx/sg/DirtyRegionPool.java - javafx-sg-common/src/com/sun/javafx/sg/PGSpan.java - javafx-sg-common/src/com/sun/javafx/sg/PGTextHelper.java - javafx-sg-common/test/com/sun/javafx/sg/DirtyRegionContainerTest.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGSpan.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGTextHelper.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubSpan.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextHelper.java From david.dehaven at oracle.com Wed Feb 6 07:57:13 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 6 Feb 2013 07:57:13 -0800 Subject: StubToolkit must go! In-Reply-To: <543FD1AF-BE62-4F3A-9653-1E4CB92EC77C@oracle.com> References: <60A32258-24E3-4E27-A1E1-7E50C60EB5E3@oracle.com> <510F7F67.3020408@oracle.com> <993F6F47-AF3C-4BFA-B6B7-405EEEEEAC7E@oracle.com> <51106936.8080308@oracle.com> <51118326.2040402@oracle.com> <2F1AC6D9-CD09-4339-BD13-F68300EC0262@oracle.com> <543FD1AF-BE62-4F3A-9653-1E4CB92EC77C@oracle.com> Message-ID: > Another big issue is that right now each test class is fired up in its own VM and takes 10x longer (or thereabouts) to execute than if the tests could all just run in the same VM. Some tests need their own VM (related to initialization etc where we cannot easily reinitialize some code on subsequent test runs), whereas most of them could run concurrently. I'm looking into JTReg as the main system for invoking our tests, which is capable of calling TestNG tests or Jemmy tests or any other type of test out there we need to run (and is the same system used by OpenJDK). I mention this, although I am not going to do it yet (just in case those of you with loads of jtreg experience can help guide my way :-)). The problem with running them all in the same VM is when something behaves poorly it tends to cascade and you end up with a big snowball effect of a bunch of problems and failures occurring later on, especially irritating to track down if the poorly behaving test does not cause a failure itself. I fully support moving to JTReg, my short stint in core-libs learned me it's on a slightly higher shelf than what we have now :) Another thought that was recently brought up is running JPRT jobs before integration, since we're integrated with the JDK now and becoming more so by the week. I believe that would require moving to jtreg and quite possibly some changes to JPRT. -DrD- From hang.vo at oracle.com Wed Feb 6 08:18:06 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Feb 2013 16:18:06 +0000 Subject: hg: openjfx/8/graphics/rt: Fix for RT-27209: Build failure in rt/deploy on Windows with VS2010 Express Message-ID: <20130206161810.2FC554788D@hg.openjdk.java.net> Changeset: 811c479d634b Author: Artem Ananiev Date: 2013-02-06 20:00 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/811c479d634b Fix for RT-27209: Build failure in rt/deploy on Windows with VS2010 Express ! deploy/packager/winlauncher/javafxpackager.rc From richard.bair at oracle.com Wed Feb 6 08:30:38 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 6 Feb 2013 08:30:38 -0800 Subject: StubToolkit must go! In-Reply-To: References: <60A32258-24E3-4E27-A1E1-7E50C60EB5E3@oracle.com> <510F7F67.3020408@oracle.com> <993F6F47-AF3C-4BFA-B6B7-405EEEEEAC7E@oracle.com> <51106936.8080308@oracle.com> <51118326.2040402@oracle.com> <2F1AC6D9-CD09-4339-BD13-F68300EC0262@oracle.com> <543FD1AF-BE62-4F3A-9653-1E4CB92EC77C@oracle.com> Message-ID: >> Another big issue is that right now each test class is fired up in its own VM and takes 10x longer (or thereabouts) to execute than if the tests could all just run in the same VM. Some tests need their own VM (related to initialization etc where we cannot easily reinitialize some code on subsequent test runs), whereas most of them could run concurrently. I'm looking into JTReg as the main system for invoking our tests, which is capable of calling TestNG tests or Jemmy tests or any other type of test out there we need to run (and is the same system used by OpenJDK). I mention this, although I am not going to do it yet (just in case those of you with loads of jtreg experience can help guide my way :-)). > > The problem with running them all in the same VM is when something behaves poorly it tends to cascade and you end up with a big snowball effect of a bunch of problems and failures occurring later on, especially irritating to track down if the poorly behaving test does not cause a failure itself. I think this is OK in our master plan. So the idea is that what we're going to do is to break our testing up into three different levels -- level 1 (pre-commit), level 2 (nightly), level 3 (release). We will define some set of tests that are reliable and fast and cover a sufficient amount of the platform such that, before any integration into master, all tests must pass on all platforms (see below). This should take ~ 5 minutes. The second level (nightly) is going to be a different configuration of tests -- maybe additional tests, maybe the same tests run differently, probably a combination of both. These run for 8+ hours and should require < 8 hours to analyze any failures. In this way, if you've introduced an error into master, then you'll get feedback on it most likely in 24 hours. The third level is the multi-week testing that does everything from stability testing (hence at least a 2 week cycle) to running all the tests in all configurations etc. This should catch the majority of bug escapes from our first two levels of testing, but in the grand scheme of things hopefully it isn't catching much (most of it being caught in the first two levels of testing). So my thought here is that if we can run 30,000 tests in < 5 min by allowing nearly all of them to be run in the same VM, then that is probably better than running 3,000 tests in separate VMs for the sake of our pre-commit testing. For the nightly run, we can certainly run them all in their same VM so that the analysis phase of failures is much simpler. > I fully support moving to JTReg, my short stint in core-libs learned me it's on a slightly higher shelf than what we have now :) Cool. I will play with it and see what the reports are like etc, might have to give some patches back to Jon Gibbons if the reports are nappy :) > Another thought that was recently brought up is running JPRT jobs before integration, since we're integrated with the JDK now and becoming more so by the week. I believe that would require moving to jtreg and quite possibly some changes to JPRT. Yes, this is part of our continuous integration plan -- whether JPRT or something like it is TBD. But the idea is that once we have our build/test humming along nicely with our pre-commit / nightly / release testing phases all ironed out, then what we'll do is change our workflow so that we don't do weekly integrations from team forests into master. Instead you'll submit your fix as a patch to a JPRT like system which will then integrate & build & test (pre-commit tests) on all platforms and then if it passes do an automatic integration. If it fails it kicks it out and sends you mail and you can fix up whatever wasn't working and resubmit. Of course there are times when you want a sandbox / team forest and in those cases you can still work on the side. But when you are ready to integrate to master, you end up sending your wad of patches to the system and it integrates & builds & tests just like everything else. Hopefully this will streamline the process, reducing the pain for weekly integrations for each forest, reducing the number of forests we need to know about etc, and also reduce the time to get a patch that has been reasonably well tested to get into master so SQE can start hammering away at it. Richard From david.dehaven at oracle.com Wed Feb 6 08:46:48 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 6 Feb 2013 08:46:48 -0800 Subject: StubToolkit must go! In-Reply-To: References: <60A32258-24E3-4E27-A1E1-7E50C60EB5E3@oracle.com> <510F7F67.3020408@oracle.com> <993F6F47-AF3C-4BFA-B6B7-405EEEEEAC7E@oracle.com> <51106936.8080308@oracle.com> <51118326.2040402@oracle.com> <2F1AC6D9-CD09-4339-BD13-F68300EC0262@oracle.com> <543FD1AF-BE62-4F3A-9653-1E4CB92EC77C@oracle.com> Message-ID: > So my thought here is that if we can run 30,000 tests in < 5 min by allowing nearly all of them to be run in the same VM, then that is probably better than running 3,000 tests in separate VMs for the sake of our pre-commit testing. For the nightly run, we can certainly run them all in their same VM so that the analysis phase of failures is much simpler. This sounds fine, so long as at the pre-commit level we have the option of running the full test suite in the "slow and steady" mode to isolate test instances. > Yes, this is part of our continuous integration plan -- whether JPRT or something like it is TBD. But the idea is that once we have our build/test humming along nicely with our pre-commit / nightly / release testing phases all ironed out, then what we'll do is change our workflow so that we don't do weekly integrations from team forests into master. Instead you'll submit your fix as a patch to a JPRT like system which will then integrate & build & test (pre-commit tests) on all platforms and then if it passes do an automatic integration. If it fails it kicks it out and sends you mail and you can fix up whatever wasn't working and resubmit. Of course there are times when you want a sandbox / team forest and in those cases you can still work on the side. But when you are ready to integrate to master, you end up sending your wad of patches to the system and it integrates & builds & tests just like everything else. > > Hopefully this will streamline the process, reducing the pain for weekly integrations for each forest, reducing the number of forests we need to know about etc, and also reduce the time to get a patch that has been reasonably well tested to get into master so SQE can start hammering away at it. That would be wonderful! Modifying JPRT to pull and build JavaFX artifacts would not quite be so wonderful, but luckily that's not my job ;) -DrD- From richard.bair at ORACLE.COM Wed Feb 6 08:49:30 2013 From: richard.bair at ORACLE.COM (Richard Bair) Date: Wed, 6 Feb 2013 08:49:30 -0800 Subject: StubToolkit must go! In-Reply-To: References: <60A32258-24E3-4E27-A1E1-7E50C60EB5E3@oracle.com> <510F7F67.3020408@oracle.com> <993F6F47-AF3C-4BFA-B6B7-405EEEEEAC7E@oracle.com> <51106936.8080308@oracle.com> <51118326.2040402@oracle.com> <2F1AC6D9-CD09-4339-BD13-F68300EC0262@oracle.com> <543FD1AF-BE62-4F3A-9653-1E4CB92EC77C@oracle.com> Message-ID: <8AD414CB-A748-4BB4-B7C6-A8B072C48F44@ORACLE.COM> >> So my thought here is that if we can run 30,000 tests in < 5 min by allowing nearly all of them to be run in the same VM, then that is probably better than running 3,000 tests in separate VMs for the sake of our pre-commit testing. For the nightly run, we can certainly run them all in their same VM so that the analysis phase of failures is much simpler. > > This sounds fine, so long as at the pre-commit level we have the option of running the full test suite in the "slow and steady" mode to isolate test instances. Yes, in fact *all* the tests (except security tests and big apps) will be both in our repo and open source, so that you can run any of the SQE tests, etc. Also you can run the full exact same build configuration etc. that SQE / RE uses. We'll all be operating off the exact same build scripts so that there is no mystery as to what is finally produced at the end. A developer *should* run the appropriate level of tests before pushing. For example if I'm making a little change, I'll just run the pre-commit and go. But if I'm doing a major amount of work on Region (for example) then I'm also going to make sure I run the SQE tests before I push so that I know I'm not going to fail a bunch of tests. All of that will be available to you. From richard.bair at oracle.com Wed Feb 6 10:13:43 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 6 Feb 2013 10:13:43 -0800 Subject: HG: /source/hg/javafx/8.0/scrum/graphics/rt: 2 new changesets In-Reply-To: References: Message-ID: <3B6A29DD-4700-4101-BDEF-E910A1FAA858@oracle.com> Hi Martin, > Changeset: c2fb1c411133 > Author: Martin Sladecek > Date: Mon Feb 04 14:18:22 2013 +0100 > URL: http://jfxsrc.us.oracle.com/javafx/8.0/scrum/graphics/rt/rev/c2fb1c411133 > > > Description: > RT-28166 Animation methods accept illegal Duration values that are not expected in the Animation code. I don't think this is the right thing for us to do. The issue here is this: protected void invalidated() { final Duration newDuration = get(); if (newDuration.lessThan(Duration.ZERO)) { if (isBound()) { unbind(); } set(Duration.ZERO); throw new IllegalArgumentException("Cannot set delay to negative value. Setting to Duration.ZERO"); } } This is an idiom we should really avoid (I've seen it in at least one other place before this change set, and I think it is an abomination there too :-)). The problem is that with a binding, you might end up in one of several intermediate states as the binding is reconfigured, and any such intermediate "illegal" state will cause the binding be silently unbound! Suppose the duration is based on some math based on two input variables: tx.cycleDurationProperty().bind(end.minus(start)); Somebody (using sliders, whatever) changes start to be > than end, but only temporarily because they're now about to set the end to be > than start. However now the binding is no longer working. Instead, we need to allow people to set the value to any valid Duration, specify what it will mean if the duration is < 0, and then get our implementation to handle it correctly. For example you could add a private / package helper method that gets the "normalizedDuration". Thanks Richard From richard.bair at oracle.com Wed Feb 6 10:25:13 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 6 Feb 2013 10:25:13 -0800 Subject: SceneBuilder src, or how to drag/size controls In-Reply-To: <74226571-B2AC-4886-9719-3F62516F076B@gmail.com> References: <51100F7E.2010603@media-interactive.de> <03984064-67DE-4A15-AABD-B5ABBFF16EB0@oracle.com> <74226571-B2AC-4886-9719-3F62516F076B@gmail.com> Message-ID: <089FE7E4-1FE2-4297-8A0A-2199A18DD8D9@oracle.com> It hasn't been entirely settled. There are benefits to open sourcing, but also costs in terms of process / etc (heck, we're still getting the final bits of OpenJFX out and we've been working at it for a while now :-)). If there is big demand for it to be open sourced I'm sure there would be some reprioritiziation. On Feb 4, 2013, at 7:02 PM, Scott Palmer wrote: > Is expected to be included in the Open Sourcing efforts, or is the plan for it to remain closed source? > > Scott > > On 2013-02-04, at 3:15 PM, Joe McGlynn wrote: > >> SceneBuilder is not available in source form, sorry. >> >> >> On Feb 4, 2013, at 11:43 AM, Werner Lehmann wrote: >> >>> Hi, >>> >>> for an upcoming project I'll need to provide a subset of the SceneBuilder functionality. More specifically, controls such as a Label or TextField need to be dragged from a tool palette into a designing area where they can be selected, moved, and resized. >>> >>> Is the SceneBuilder src available? Otherwise, any recommendations on do's and dont's? Fortunately this week's links on FX-Experience include a just-in-time article on resizing regions: >>> >>>> http://andrewtill.blogspot.co.nz/2012/12/dragging-to-resize-javafx-region.html >>> (Thanks, Andrew) >>> >>> Region would be interesting for custom "tools" but I'll need this for standard controls, too. Maybe I should wrap each of them into a stackpane to provide a clickable selection border with drag points? >>> >>> Rgds >>> Werner >> From richard.bair at oracle.com Wed Feb 6 10:35:35 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 6 Feb 2013 10:35:35 -0800 Subject: [API Review] RT-24916 - TableView.scrollTo(TableColumn) In-Reply-To: <5110AD4E.6010500@xs4all.nl> References: <510F7065.3020101@bestsolution.at> <510F9553.3060408@xs4all.nl> <511013BF.6000100@oracle.com> <5110AD4E.6010500@xs4all.nl> Message-ID: I agree, one of the things the VirtualFlow is supposed to do is to have a "stable view" regardless of what changes occur in the model. Suppose I have 10,001 items, and have time 5,000 in the middle of the view ports (my position is .5). Whether items 0-4,999 or 5,001->10,001 change heights (unless they all go to 0, but anyway), the view should never change its position (.5) and I should remain centered. However if the 5,000 cell changes height, I shouldn't keep re-centering it. Also, if I'm on the first cell, any cells below it that change shouldn't change the position. If I'm on the last cell, any cells above it that change shouldn't change the position either. I remember this was problematic figuring this out "right", but the theory was definitely that you didn't want to unnecessarily move around the position as the heights were changing. The same goes for when things are added / removed. That might cause the position to change (i.e.: if I remove the last 5,001-10,001 items, then 5,000 becomes the last), but we should change the position so that the previous item remains the current item (position would change to 1 so that 5,000 is still the current item). Richard On Feb 4, 2013, at 10:57 PM, John Hendrikx wrote: > On 4/02/2013 21:02, Jonathan Giles wrote: >> This is a fair comment: scrollTo has been designed with a 'fire-and-forget' approach in mind, but I would be loath to add a means of requesting a self-correcting scrollTo function. Wouldn't a suitable workaround be to call scrollTo after the image loading has completed in all cells? > The problem is that image loading occurs in the background, and it is not really predictable when all of them are completed. In my example application, these images are loaded from a database (when cached) or from the internet when not. It may take 10 seconds before one has been loaded if it wasn't cached. Waiting that long before I restore the position of the view for the user is not acceptable. Also, calling scrollTo may trigger more image loading (as new cells come into view), so I'd have to call it in a loop until no more images are getting loaded... > > I realize that self-correcting the position seems wierd, but on the other hand, why is the control adjusting position when some cell changes height? Should the View control not take every effort to stay in the same position? In other words, if my last interaction with the View class was to tell it "show me cell 313 nicely centered", and then cells 304-312 change their height, should they not simply be pushed up and out of view and keep my cell 313 centered? > > I think it should store its "position" not as some absolute Y coordinate (which would change whenever any intermediate cell changes height), but more relative to the cell. ie. the position is cell 313, centered at 45% down from the top of the control. That way when a cell changes, it will try to keep the position stable. > > I cannot predict when image loading will happen, nor when it will finish. Even if I could, I'd probably have to call scrollTo in a loop for a few times as it would not be acceptable to wait calling it. Also... as soon as I do call it, other cells are likely to scroll into view, triggering more image loading... > >> Regarding a lower-level API for exact positioning, please file a jira tweak request. > I've filed http://javafx-jira.kenai.com/browse/RT-28192 > > --John From richard.bair at oracle.com Wed Feb 6 10:36:50 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 6 Feb 2013 10:36:50 -0800 Subject: [API Review] RT-24916 - TableView.scrollTo(TableColumn) In-Reply-To: <510F7065.3020101@bestsolution.at> References: <510F7065.3020101@bestsolution.at> Message-ID: <9EAD226A-D5E8-4832-9739-DE8F474A8104@oracle.com> Looks OK to me. On Feb 4, 2013, at 12:25 AM, Tom Schindl wrote: > hi, > > We (Jonathan and myself) are requesting an API review to add the > following public APIs: > > New APIS: > --------- > * ListView: > scrollTo(T) : void > > * TableView: > scrollTo(S) : void > scrollToColumn(TableColumn) : void > scrollToColumnIndex(int) : void > setOnScrollToColumn(EventHandler>>): void > getOnScrollToColumn() : EventHandler>> > onScrollToColumnProperty(): > ObjectProperty>>> > > * TreeTableView > scrollToColumn(TableColumn column) : void > scrollToColumnIndex(int columnIndex) : void > setOnScrollToColumn(EventHandler>> > value) : void > getOnScrollToColumn() : EventHandler>> > onScrollToColumnProperty() : > ObjectProperty>>> > > * ScrollToEvent: > static > scrollToColumn() : > EventType> > > Modified APIS: > -------------- > To align better we'd like to change the ScrollToEvent-API to be > consitent and use static accessor methods instead of public static fields: > * SCROLL_TO_NODE => scrollToNode() : EventType> > * SCROLL_TO_TOP_INDEX => scrollToTopIndex() : > EventType> > > > Thanks > > Jonathan + Tom > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From richard.bair at oracle.com Wed Feb 6 10:40:13 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 6 Feb 2013 10:40:13 -0800 Subject: [API Review] FX 8 3D API In-Reply-To: <510C1B8D.4060302@oracle.com> References: <510C1B8D.4060302@oracle.com> Message-ID: <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> Hi Chien, > javafx.scene.light.LightBase (abstract) > javafx.scene.material.Material (abstract) I'm not jazzed about creating two new packages here. It seems like these things should all be grouped in the same place as camera, or shape3d. Ideas? > Methods and Properties added to Node > --------------------------------------------------------- > > LOD helper property: > > /** > * A read only property that stores the computed area of this > * {@code Node} projected onto the physical screen in pixel unit. > */ > public final double getAreaInScreen() > public final javafx.beans.property.ReadOnlyDoubleProperty areaInScreenProperty() Can this be efficiently implemented? We ripped out boundsInScene because it was impossible to get it fast enough. Why would this be any different? The rest looks good. Richard From kevin.rushforth at oracle.com Wed Feb 6 10:55:22 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 06 Feb 2013 10:55:22 -0800 Subject: [API Review] FX 8 3D API In-Reply-To: <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> References: <510C1B8D.4060302@oracle.com> <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> Message-ID: <5112A71A.50502@oracle.com> They could all be put in the shape3d package, but it seems inconsistent with 2D packages: shape, paint effect, etc. -- Kevin Richard Bair wrote: > Hi Chien, > > >> javafx.scene.light.LightBase (abstract) >> javafx.scene.material.Material (abstract) >> > > I'm not jazzed about creating two new packages here. It seems like these things should all be grouped in the same place as camera, or shape3d. Ideas? > > >> Methods and Properties added to Node >> --------------------------------------------------------- >> >> LOD helper property: >> >> /** >> * A read only property that stores the computed area of this >> * {@code Node} projected onto the physical screen in pixel unit. >> */ >> public final double getAreaInScreen() >> public final javafx.beans.property.ReadOnlyDoubleProperty areaInScreenProperty() >> > > Can this be efficiently implemented? We ripped out boundsInScene because it was impossible to get it fast enough. Why would this be any different? > > The rest looks good. > > Richard From richard.bair at oracle.com Wed Feb 6 11:06:17 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 6 Feb 2013 11:06:17 -0800 Subject: [API Review] FX 8 3D API In-Reply-To: <5112A71A.50502@oracle.com> References: <510C1B8D.4060302@oracle.com> <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> <5112A71A.50502@oracle.com> Message-ID: Then we should reuse those packages. Why don't we just put shape3d in the shape package etc? On Feb 6, 2013, at 10:55 AM, Kevin Rushforth wrote: > They could all be put in the shape3d package, but it seems inconsistent with 2D packages: shape, paint effect, etc. > > -- Kevin > > > Richard Bair wrote: >> >> Hi Chien, >> >> >>> javafx.scene.light.LightBase (abstract) >>> javafx.scene.material.Material (abstract) >>> >> >> I'm not jazzed about creating two new packages here. It seems like these things should all be grouped in the same place as camera, or shape3d. Ideas? >> >> >>> Methods and Properties added to Node >>> --------------------------------------------------------- >>> >>> LOD helper property: >>> >>> /** >>> * A read only property that stores the computed area of this >>> * {@code Node} projected onto the physical screen in pixel unit. >>> */ >>> public final double getAreaInScreen() >>> public final javafx.beans.property.ReadOnlyDoubleProperty areaInScreenProperty() >>> >> >> Can this be efficiently implemented? We ripped out boundsInScene because it was impossible to get it fast enough. Why would this be any different? >> >> The rest looks good. >> >> Richard From richard.bair at oracle.com Wed Feb 6 11:12:36 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 6 Feb 2013 11:12:36 -0800 Subject: [API Review] FX 8 3D API In-Reply-To: References: <510C1B8D.4060302@oracle.com> <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> <5112A71A.50502@oracle.com> Message-ID: <05C91D9D-9F6C-4138-B2C0-418BD145A387@oracle.com> I meant "then should we" On Feb 6, 2013, at 11:06 AM, Richard Bair wrote: > Then we should reuse those packages. Why don't we just put shape3d in the shape package etc? > > On Feb 6, 2013, at 10:55 AM, Kevin Rushforth wrote: > >> They could all be put in the shape3d package, but it seems inconsistent with 2D packages: shape, paint effect, etc. >> >> -- Kevin >> >> >> Richard Bair wrote: >>> >>> Hi Chien, >>> >>> >>>> javafx.scene.light.LightBase (abstract) >>>> javafx.scene.material.Material (abstract) >>>> >>> >>> I'm not jazzed about creating two new packages here. It seems like these things should all be grouped in the same place as camera, or shape3d. Ideas? >>> >>> >>>> Methods and Properties added to Node >>>> --------------------------------------------------------- >>>> >>>> LOD helper property: >>>> >>>> /** >>>> * A read only property that stores the computed area of this >>>> * {@code Node} projected onto the physical screen in pixel unit. >>>> */ >>>> public final double getAreaInScreen() >>>> public final javafx.beans.property.ReadOnlyDoubleProperty areaInScreenProperty() >>>> >>> >>> Can this be efficiently implemented? We ripped out boundsInScene because it was impossible to get it fast enough. Why would this be any different? >>> >>> The rest looks good. >>> >>> Richard > From hang.vo at oracle.com Wed Feb 6 11:17:50 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Feb 2013 19:17:50 +0000 Subject: hg: openjfx/8/controls/rt: RT-28252: ScrollBar Thumb doesn't snap to pixel Message-ID: <20130206191754.1CD9747897@hg.openjdk.java.net> Changeset: d28efedf73e3 Author: "Jasper Potts" Date: 2013-02-06 11:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d28efedf73e3 RT-28252: ScrollBar Thumb doesn't snap to pixel ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java From hang.vo at oracle.com Wed Feb 6 11:18:02 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Feb 2013 19:18:02 +0000 Subject: hg: openjfx/8/graphics/rt: [fix css warnings] fix missing semicolon in css files Message-ID: <20130206191805.9B38647898@hg.openjdk.java.net> Changeset: f94ae4f94775 Author: Felipe Heidrich Date: 2013-02-06 11:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f94ae4f94775 [fix css warnings] fix missing semicolon in css files ! apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/SchedulerStyleSheet.css ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/VirtualFlowTest.css From chien.yang at oracle.com Wed Feb 6 11:21:52 2013 From: chien.yang at oracle.com (Chien Yang) Date: Wed, 06 Feb 2013 11:21:52 -0800 Subject: [API Review] FX 8 3D API In-Reply-To: <5112A71A.50502@oracle.com> References: <510C1B8D.4060302@oracle.com> <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> <5112A71A.50502@oracle.com> Message-ID: <5112AD50.1040807@oracle.com> Hi Richard, The number of classes in shape3d, light and material packages will certainly grow in future releases too as we add more features. - Chien On 2/6/2013 10:55 AM, Kevin Rushforth wrote: > They could all be put in the shape3d package, but it seems > inconsistent with 2D packages: shape, paint effect, etc. > > -- Kevin > > > Richard Bair wrote: >> Hi Chien, >> >> >>> javafx.scene.light.LightBase (abstract) >>> javafx.scene.material.Material (abstract) >>> >> >> I'm not jazzed about creating two new packages here. It seems like these things should all be grouped in the same place as camera, or shape3d. Ideas? >> >> >>> Methods and Properties added to Node >>> --------------------------------------------------------- >>> >>> LOD helper property: >>> >>> /** >>> * A read only property that stores the computed area of this >>> * {@code Node} projected onto the physical screen in pixel unit. >>> */ >>> public final double getAreaInScreen() >>> public final javafx.beans.property.ReadOnlyDoubleProperty areaInScreenProperty() >>> >> >> Can this be efficiently implemented? We ripped out boundsInScene because it was impossible to get it fast enough. Why would this be any different? >> >> The rest looks good. >> >> Richard From richard.bair at oracle.com Wed Feb 6 11:22:24 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 6 Feb 2013 11:22:24 -0800 Subject: [API Review] FX 8 3D API In-Reply-To: <5112AD50.1040807@oracle.com> References: <510C1B8D.4060302@oracle.com> <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> <5112A71A.50502@oracle.com> <5112AD50.1040807@oracle.com> Message-ID: <268F341F-8FCE-4FB5-AB18-A54E873B3931@oracle.com> How much? On Feb 6, 2013, at 11:21 AM, Chien Yang wrote: > Hi Richard, > > The number of classes in shape3d, light and material packages will certainly grow in future releases too as we add more features. > > - Chien > > On 2/6/2013 10:55 AM, Kevin Rushforth wrote: >> They could all be put in the shape3d package, but it seems inconsistent with 2D packages: shape, paint effect, etc. >> >> -- Kevin >> >> >> Richard Bair wrote: >>> >>> Hi Chien, >>> >>> >>>> javafx.scene.light.LightBase (abstract) >>>> javafx.scene.material.Material (abstract) >>>> >>> >>> I'm not jazzed about creating two new packages here. It seems like these things should all be grouped in the same place as camera, or shape3d. Ideas? >>> >>> >>>> Methods and Properties added to Node >>>> --------------------------------------------------------- >>>> >>>> LOD helper property: >>>> >>>> /** >>>> * A read only property that stores the computed area of this >>>> * {@code Node} projected onto the physical screen in pixel unit. >>>> */ >>>> public final double getAreaInScreen() >>>> public final javafx.beans.property.ReadOnlyDoubleProperty areaInScreenProperty() >>>> >>> >>> Can this be efficiently implemented? We ripped out boundsInScene because it was impossible to get it fast enough. Why would this be any different? >>> >>> The rest looks good. >>> >>> Richard > From chien.yang at oracle.com Wed Feb 6 11:30:18 2013 From: chien.yang at oracle.com (Chien Yang) Date: Wed, 06 Feb 2013 11:30:18 -0800 Subject: [API Review] FX 8 3D API In-Reply-To: <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> References: <510C1B8D.4060302@oracle.com> <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> Message-ID: <5112AF4A.3050100@oracle.com> Hi Richard, Yes, this is my concern too. It is done so mainly to match JavaFX API pattern and our Sample team preferred it (if I remembered correctly). I would prefer to make it a getter method for now if it is fine with you. - Chien On 2/6/2013 10:40 AM, Richard Bair wrote: >> LOD helper property: >> > >> >/** >> >* A read only property that stores the computed area of this >> >* {@code Node} projected onto the physical screen in pixel unit. >> >*/ >> >public final double getAreaInScreen() >> >public final javafx.beans.property.ReadOnlyDoubleProperty areaInScreenProperty() > Can this be efficiently implemented? We ripped out boundsInScene because it was impossible to get it fast enough. Why would this be any different? From richard.bair at oracle.com Wed Feb 6 11:31:20 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 6 Feb 2013 11:31:20 -0800 Subject: [API Review] FX 8 3D API In-Reply-To: <5112AF4A.3050100@oracle.com> References: <510C1B8D.4060302@oracle.com> <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> <5112AF4A.3050100@oracle.com> Message-ID: <4F28EF86-8933-4E17-8A1B-DE02F74D5C1D@oracle.com> In this case we should name it something like 'computeAreaInScreen' rather than being a getter. Richard On Feb 6, 2013, at 11:30 AM, Chien Yang wrote: > Hi Richard, > > Yes, this is my concern too. It is done so mainly to match JavaFX API pattern and our Sample team preferred it (if I remembered correctly). I would prefer to make it a getter method for now if it is fine with you. > > - Chien > > On 2/6/2013 10:40 AM, Richard Bair wrote: >>> LOD helper property: >>> > >>> >/** >>> >* A read only property that stores the computed area of this >>> >* {@code Node} projected onto the physical screen in pixel unit. >>> >*/ >>> >public final double getAreaInScreen() >>> >public final javafx.beans.property.ReadOnlyDoubleProperty areaInScreenProperty() >> Can this be efficiently implemented? We ripped out boundsInScene because it was impossible to get it fast enough. Why would this be any different? > From chien.yang at oracle.com Wed Feb 6 12:48:26 2013 From: chien.yang at oracle.com (Chien Yang) Date: Wed, 06 Feb 2013 12:48:26 -0800 Subject: [API Review] FX 8 3D API In-Reply-To: <268F341F-8FCE-4FB5-AB18-A54E873B3931@oracle.com> References: <510C1B8D.4060302@oracle.com> <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> <5112A71A.50502@oracle.com> <5112AD50.1040807@oracle.com> <268F341F-8FCE-4FB5-AB18-A54E873B3931@oracle.com> Message-ID: <5112C19A.7050009@oracle.com> Don't exactly know at this point, but we did talk about adding high-order surfaces and additional light types at one point. We will very likely need to support more material types if we want to hold the line of not supporting user defined shader. - Chien On 2/6/2013 11:22 AM, Richard Bair wrote: > How much? > > On Feb 6, 2013, at 11:21 AM, Chien Yang wrote: > >> Hi Richard, >> >> The number of classes in shape3d, light and material packages will certainly grow in future releases too as we add more features. >> >> - Chien >> >> On 2/6/2013 10:55 AM, Kevin Rushforth wrote: >>> They could all be put in the shape3d package, but it seems inconsistent with 2D packages: shape, paint effect, etc. >>> >>> -- Kevin >>> >>> >>> Richard Bair wrote: >>>> Hi Chien, >>>> >>>> >>>>> javafx.scene.light.LightBase (abstract) >>>>> javafx.scene.material.Material (abstract) >>>>> >>>> I'm not jazzed about creating two new packages here. It seems like these things should all be grouped in the same place as camera, or shape3d. Ideas? >>>> >>>> >>>>> Methods and Properties added to Node >>>>> --------------------------------------------------------- >>>>> >>>>> LOD helper property: >>>>> >>>>> /** >>>>> * A read only property that stores the computed area of this >>>>> * {@code Node} projected onto the physical screen in pixel unit. >>>>> */ >>>>> public final double getAreaInScreen() >>>>> public final javafx.beans.property.ReadOnlyDoubleProperty areaInScreenProperty() >>>>> >>>> Can this be efficiently implemented? We ripped out boundsInScene because it was impossible to get it fast enough. Why would this be any different? >>>> >>>> The rest looks good. >>>> >>>> Richard From richard.bair at oracle.com Wed Feb 6 12:53:03 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 6 Feb 2013 12:53:03 -0800 Subject: [API Review] FX 8 3D API In-Reply-To: <5112C19A.7050009@oracle.com> References: <510C1B8D.4060302@oracle.com> <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> <5112A71A.50502@oracle.com> <5112AD50.1040807@oracle.com> <268F341F-8FCE-4FB5-AB18-A54E873B3931@oracle.com> <5112C19A.7050009@oracle.com> Message-ID: <3ACF3F09-8EF8-4A7A-ACCD-E1D3CB6F141C@oracle.com> I would hope we're going to support user defined shaders. That doesn't mean some additional materials aren't a good idea. But we're not talking about dozens of additional classes, right? On Feb 6, 2013, at 12:48 PM, Chien Yang wrote: > Don't exactly know at this point, but we did talk about adding high-order surfaces and additional light types at one point. We will very likely need to support more material types if we want to hold the line of not supporting user defined shader. > > - Chien > > On 2/6/2013 11:22 AM, Richard Bair wrote: >> How much? >> >> On Feb 6, 2013, at 11:21 AM, Chien Yang wrote: >> >>> Hi Richard, >>> >>> The number of classes in shape3d, light and material packages will certainly grow in future releases too as we add more features. >>> >>> - Chien >>> >>> On 2/6/2013 10:55 AM, Kevin Rushforth wrote: >>>> They could all be put in the shape3d package, but it seems inconsistent with 2D packages: shape, paint effect, etc. >>>> >>>> -- Kevin >>>> >>>> >>>> Richard Bair wrote: >>>>> Hi Chien, >>>>> >>>>> >>>>>> javafx.scene.light.LightBase (abstract) >>>>>> javafx.scene.material.Material (abstract) >>>>>> >>>>> I'm not jazzed about creating two new packages here. It seems like these things should all be grouped in the same place as camera, or shape3d. Ideas? >>>>> >>>>> >>>>>> Methods and Properties added to Node >>>>>> --------------------------------------------------------- >>>>>> >>>>>> LOD helper property: >>>>>> >>>>>> /** >>>>>> * A read only property that stores the computed area of this >>>>>> * {@code Node} projected onto the physical screen in pixel unit. >>>>>> */ >>>>>> public final double getAreaInScreen() >>>>>> public final javafx.beans.property.ReadOnlyDoubleProperty areaInScreenProperty() >>>>>> >>>>> Can this be efficiently implemented? We ripped out boundsInScene because it was impossible to get it fast enough. Why would this be any different? >>>>> >>>>> The rest looks good. >>>>> >>>>> Richard > From joseph.andresen at oracle.com Wed Feb 6 13:01:12 2013 From: joseph.andresen at oracle.com (Joe Andresen) Date: Wed, 6 Feb 2013 13:01:12 -0800 (PST) Subject: [API Review] FX 8 3D API Message-ID: <6a9c09a9-f11a-4cd6-a47a-d9447dc68594@default> There are many possibilities for us to expand our representation of a material and even shaders. I am not sure about it having its own package though. I would say put it with the paints... but you cannot add materials to 2d shapes so that would be misleading. -J ----- Original Message ----- From: richard.bair at oracle.com To: chien.yang at oracle.com Cc: openjfx-dev at openjdk.java.net Sent: Wednesday, February 6, 2013 12:56:11 PM GMT -08:00 US/Canada Pacific Subject: Re: [API Review] FX 8 3D API I would hope we're going to support user defined shaders. That doesn't mean some additional materials aren't a good idea. But we're not talking about dozens of additional classes, right? On Feb 6, 2013, at 12:48 PM, Chien Yang wrote: > Don't exactly know at this point, but we did talk about adding high-order surfaces and additional light types at one point. We will very likely need to support more material types if we want to hold the line of not supporting user defined shader. > > - Chien > > On 2/6/2013 11:22 AM, Richard Bair wrote: >> How much? >> >> On Feb 6, 2013, at 11:21 AM, Chien Yang wrote: >> >>> Hi Richard, >>> >>> The number of classes in shape3d, light and material packages will certainly grow in future releases too as we add more features. >>> >>> - Chien >>> >>> On 2/6/2013 10:55 AM, Kevin Rushforth wrote: >>>> They could all be put in the shape3d package, but it seems inconsistent with 2D packages: shape, paint effect, etc. >>>> >>>> -- Kevin >>>> >>>> >>>> Richard Bair wrote: >>>>> Hi Chien, >>>>> >>>>> >>>>>> javafx.scene.light.LightBase (abstract) >>>>>> javafx.scene.material.Material (abstract) >>>>>> >>>>> I'm not jazzed about creating two new packages here. It seems like these things should all be grouped in the same place as camera, or shape3d. Ideas? >>>>> >>>>> >>>>>> Methods and Properties added to Node >>>>>> --------------------------------------------------------- >>>>>> >>>>>> LOD helper property: >>>>>> >>>>>> /** >>>>>> * A read only property that stores the computed area of this >>>>>> * {@code Node} projected onto the physical screen in pixel unit. >>>>>> */ >>>>>> public final double getAreaInScreen() >>>>>> public final javafx.beans.property.ReadOnlyDoubleProperty areaInScreenProperty() >>>>>> >>>>> Can this be efficiently implemented? We ripped out boundsInScene because it was impossible to get it fast enough. Why would this be any different? >>>>> >>>>> The rest looks good. >>>>> >>>>> Richard > From chien.yang at oracle.com Wed Feb 6 13:10:24 2013 From: chien.yang at oracle.com (Chien Yang) Date: Wed, 06 Feb 2013 13:10:24 -0800 Subject: [API Review] FX 8 3D API In-Reply-To: <3ACF3F09-8EF8-4A7A-ACCD-E1D3CB6F141C@oracle.com> References: <510C1B8D.4060302@oracle.com> <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> <5112A71A.50502@oracle.com> <5112AD50.1040807@oracle.com> <268F341F-8FCE-4FB5-AB18-A54E873B3931@oracle.com> <5112C19A.7050009@oracle.com> <3ACF3F09-8EF8-4A7A-ACCD-E1D3CB6F141C@oracle.com> Message-ID: <5112C6C0.5020803@oracle.com> I don't foresee the need to add dozens, but an additional of 10 classes might be a reasonable expectation. :-) - Chien On 2/6/2013 12:53 PM, Richard Bair wrote: > I would hope we're going to support user defined shaders. That doesn't mean some additional materials aren't a good idea. But we're not talking about dozens of additional classes, right? > > On Feb 6, 2013, at 12:48 PM, Chien Yang wrote: > >> Don't exactly know at this point, but we did talk about adding high-order surfaces and additional light types at one point. We will very likely need to support more material types if we want to hold the line of not supporting user defined shader. >> >> - Chien >> >> On 2/6/2013 11:22 AM, Richard Bair wrote: >>> How much? >>> >>> On Feb 6, 2013, at 11:21 AM, Chien Yang wrote: >>> >>>> Hi Richard, >>>> >>>> The number of classes in shape3d, light and material packages will certainly grow in future releases too as we add more features. >>>> >>>> - Chien >>>> >>>> On 2/6/2013 10:55 AM, Kevin Rushforth wrote: >>>>> They could all be put in the shape3d package, but it seems inconsistent with 2D packages: shape, paint effect, etc. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Richard Bair wrote: >>>>>> Hi Chien, >>>>>> >>>>>> >>>>>>> javafx.scene.light.LightBase (abstract) >>>>>>> javafx.scene.material.Material (abstract) >>>>>>> >>>>>> I'm not jazzed about creating two new packages here. It seems like these things should all be grouped in the same place as camera, or shape3d. Ideas? >>>>>> >>>>>> >>>>>>> Methods and Properties added to Node >>>>>>> --------------------------------------------------------- >>>>>>> >>>>>>> LOD helper property: >>>>>>> >>>>>>> /** >>>>>>> * A read only property that stores the computed area of this >>>>>>> * {@code Node} projected onto the physical screen in pixel unit. >>>>>>> */ >>>>>>> public final double getAreaInScreen() >>>>>>> public final javafx.beans.property.ReadOnlyDoubleProperty areaInScreenProperty() >>>>>>> >>>>>> Can this be efficiently implemented? We ripped out boundsInScene because it was impossible to get it fast enough. Why would this be any different? >>>>>> >>>>>> The rest looks good. >>>>>> >>>>>> Richard From hang.vo at oracle.com Wed Feb 6 13:17:53 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 06 Feb 2013 21:17:53 +0000 Subject: hg: openjfx/8/controls/rt: Fixed RT-28163: [SplitMenuButton] Arrow button rendering has changed. Message-ID: <20130206211757.374044789D@hg.openjdk.java.net> Changeset: fb2dc010dd91 Author: "Jasper Potts" Date: 2013-02-06 13:12 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fb2dc010dd91 Fixed RT-28163: [SplitMenuButton] Arrow button rendering has changed. ! apps/experiments/Modena/src/modena/SamplePage.java ! javafx-ui-controls/src/javafx/scene/control/MenuButton.java From joseph.andresen at oracle.com Wed Feb 6 13:41:16 2013 From: joseph.andresen at oracle.com (Joe Andresen) Date: Wed, 6 Feb 2013 13:41:16 -0800 (PST) Subject: [API Review] FX 8 3D API Message-ID: what would these classes extend though? Materials are for the most part user defined... They are mostly classified by their shaders,textures. (ie transparent materials vs sprite vs lighting). If we were to provide more materials it would be because of their functionality, it would be because of their shaders, right? ----- Original Message ----- From: chien.yang at oracle.com To: richard.bair at oracle.com Cc: openjfx-dev at openjdk.java.net Sent: Wednesday, February 6, 2013 1:20:37 PM GMT -08:00 US/Canada Pacific Subject: Re: [API Review] FX 8 3D API I don't foresee the need to add dozens, but an additional of 10 classes might be a reasonable expectation. :-) - Chien On 2/6/2013 12:53 PM, Richard Bair wrote: > I would hope we're going to support user defined shaders. That doesn't mean some additional materials aren't a good idea. But we're not talking about dozens of additional classes, right? > > On Feb 6, 2013, at 12:48 PM, Chien Yang wrote: > >> Don't exactly know at this point, but we did talk about adding high-order surfaces and additional light types at one point. We will very likely need to support more material types if we want to hold the line of not supporting user defined shader. >> >> - Chien >> >> On 2/6/2013 11:22 AM, Richard Bair wrote: >>> How much? >>> >>> On Feb 6, 2013, at 11:21 AM, Chien Yang wrote: >>> >>>> Hi Richard, >>>> >>>> The number of classes in shape3d, light and material packages will certainly grow in future releases too as we add more features. >>>> >>>> - Chien >>>> >>>> On 2/6/2013 10:55 AM, Kevin Rushforth wrote: >>>>> They could all be put in the shape3d package, but it seems inconsistent with 2D packages: shape, paint effect, etc. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Richard Bair wrote: >>>>>> Hi Chien, >>>>>> >>>>>> >>>>>>> javafx.scene.light.LightBase (abstract) >>>>>>> javafx.scene.material.Material (abstract) >>>>>>> >>>>>> I'm not jazzed about creating two new packages here. It seems like these things should all be grouped in the same place as camera, or shape3d. Ideas? >>>>>> >>>>>> >>>>>>> Methods and Properties added to Node >>>>>>> --------------------------------------------------------- >>>>>>> >>>>>>> LOD helper property: >>>>>>> >>>>>>> /** >>>>>>> * A read only property that stores the computed area of this >>>>>>> * {@code Node} projected onto the physical screen in pixel unit. >>>>>>> */ >>>>>>> public final double getAreaInScreen() >>>>>>> public final javafx.beans.property.ReadOnlyDoubleProperty areaInScreenProperty() >>>>>>> >>>>>> Can this be efficiently implemented? We ripped out boundsInScene because it was impossible to get it fast enough. Why would this be any different? >>>>>> >>>>>> The rest looks good. >>>>>> >>>>>> Richard From joseph.andresen at oracle.com Wed Feb 6 14:46:05 2013 From: joseph.andresen at oracle.com (Joe Andresen) Date: Wed, 6 Feb 2013 14:46:05 -0800 (PST) Subject: [API Review] FX 8 3D API Message-ID: <8cd88f3d-9001-46cd-8bbd-3c92addc1963@default> typo... i meant If we were to provide more materials it would NOT be because of their functionality, it would be because of their shaders, right? -J ----- Original Message ----- From: joseph.andresen at oracle.com To: chien.yang at oracle.com Cc: openjfx-dev at openjdk.java.net Sent: Wednesday, February 6, 2013 1:58:39 PM GMT -08:00 US/Canada Pacific Subject: Re: [API Review] FX 8 3D API what would these classes extend though? Materials are for the most part user defined... They are mostly classified by their shaders,textures. (ie transparent materials vs sprite vs lighting). If we were to provide more materials it would be because of their functionality, it would be because of their shaders, right? ----- Original Message ----- From: chien.yang at oracle.com To: richard.bair at oracle.com Cc: openjfx-dev at openjdk.java.net Sent: Wednesday, February 6, 2013 1:20:37 PM GMT -08:00 US/Canada Pacific Subject: Re: [API Review] FX 8 3D API I don't foresee the need to add dozens, but an additional of 10 classes might be a reasonable expectation. :-) - Chien On 2/6/2013 12:53 PM, Richard Bair wrote: > I would hope we're going to support user defined shaders. That doesn't mean some additional materials aren't a good idea. But we're not talking about dozens of additional classes, right? > > On Feb 6, 2013, at 12:48 PM, Chien Yang wrote: > >> Don't exactly know at this point, but we did talk about adding high-order surfaces and additional light types at one point. We will very likely need to support more material types if we want to hold the line of not supporting user defined shader. >> >> - Chien >> >> On 2/6/2013 11:22 AM, Richard Bair wrote: >>> How much? >>> >>> On Feb 6, 2013, at 11:21 AM, Chien Yang wrote: >>> >>>> Hi Richard, >>>> >>>> The number of classes in shape3d, light and material packages will certainly grow in future releases too as we add more features. >>>> >>>> - Chien >>>> >>>> On 2/6/2013 10:55 AM, Kevin Rushforth wrote: >>>>> They could all be put in the shape3d package, but it seems inconsistent with 2D packages: shape, paint effect, etc. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Richard Bair wrote: >>>>>> Hi Chien, >>>>>> >>>>>> >>>>>>> javafx.scene.light.LightBase (abstract) >>>>>>> javafx.scene.material.Material (abstract) >>>>>>> >>>>>> I'm not jazzed about creating two new packages here. It seems like these things should all be grouped in the same place as camera, or shape3d. Ideas? >>>>>> >>>>>> >>>>>>> Methods and Properties added to Node >>>>>>> --------------------------------------------------------- >>>>>>> >>>>>>> LOD helper property: >>>>>>> >>>>>>> /** >>>>>>> * A read only property that stores the computed area of this >>>>>>> * {@code Node} projected onto the physical screen in pixel unit. >>>>>>> */ >>>>>>> public final double getAreaInScreen() >>>>>>> public final javafx.beans.property.ReadOnlyDoubleProperty areaInScreenProperty() >>>>>>> >>>>>> Can this be efficiently implemented? We ripped out boundsInScene because it was impossible to get it fast enough. Why would this be any different? >>>>>> >>>>>> The rest looks good. >>>>>> >>>>>> Richard From hang.vo at oracle.com Wed Feb 6 16:33:04 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Feb 2013 00:33:04 +0000 Subject: hg: openjfx/8/graphics/rt: [TEST ONLY] Updated Service tests -- made thread daemon, closed off running threads when done, and ignored the security manager test which appears to be bogus. Message-ID: <20130207003308.73634478A4@hg.openjdk.java.net> Changeset: beb638445101 Author: rbair Date: 2013-02-06 16:15 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/beb638445101 [TEST ONLY] Updated Service tests -- made thread daemon, closed off running threads when done, and ignored the security manager test which appears to be bogus. ! javafx-concurrent/test/javafx/concurrent/ServiceLifecycleTest.java ! javafx-concurrent/test/javafx/concurrent/ServiceTestBase.java ! javafx-concurrent/test/javafx/concurrent/ServiceWithSecurityManagerTest.java From james.graham at oracle.com Wed Feb 6 16:53:43 2013 From: james.graham at oracle.com (Jim Graham) Date: Wed, 06 Feb 2013 16:53:43 -0800 Subject: StubToolkit must go! In-Reply-To: References: <60A32258-24E3-4E27-A1E1-7E50C60EB5E3@oracle.com> <510F7F67.3020408@oracle.com> <993F6F47-AF3C-4BFA-B6B7-405EEEEEAC7E@oracle.com> <51106936.8080308@oracle.com> <51118326.2040402@oracle.com> <2F1AC6D9-CD09-4339-BD13-F68300EC0262@oracle.com> <543FD1AF-BE62-4F3A-9653-1E4CB92EC77C@oracle.com> Message-ID: <5112FB17.9060700@oracle.com> On 2/6/13 8:30 AM, Richard Bair wrote: > So my thought here is that if we can run 30,000 tests in < 5 min by allowing nearly all of them to be run in the same VM, then that is probably better than running 3,000 tests in separate VMs for the sake of our pre-commit testing. For the nightly run, we can certainly run them all in their same VM so that the analysis phase of failures is much simpler. For reliability testing running them all in the same VM would actually improve the coverage of our tests. If there is a snowball failure, then an option to run them in separate VMs to sanity check if a single test is causing the problem would be nice, but if we can't survive running them all in the same VM then something is wrong with the product and we should definitely know that... ...jim From richard.bair at oracle.com Wed Feb 6 16:59:50 2013 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 6 Feb 2013 16:59:50 -0800 Subject: StubToolkit must go! In-Reply-To: <5112FB17.9060700@oracle.com> References: <60A32258-24E3-4E27-A1E1-7E50C60EB5E3@oracle.com> <510F7F67.3020408@oracle.com> <993F6F47-AF3C-4BFA-B6B7-405EEEEEAC7E@oracle.com> <51106936.8080308@oracle.com> <51118326.2040402@oracle.com> <2F1AC6D9-CD09-4339-BD13-F68300EC0262@oracle.com> <543FD1AF-BE62-4F3A-9653-1E4CB92EC77C@oracle.com> <5112FB17.9060700@oracle.com> Message-ID: <52F2491A-9B06-48E1-A2A3-E843D8E614F4@oracle.com> Or something is wrong with the tests where they aren't cleaning up after themselves or leaving some static state in a state that other test code wasn't expecting, which should also be fixed. most of our tests are of the variety "create an object, test the object", where such things shouldn't really be a problem. Richard On Feb 6, 2013, at 4:53 PM, Jim Graham wrote: > > > On 2/6/13 8:30 AM, Richard Bair wrote: >> So my thought here is that if we can run 30,000 tests in < 5 min by allowing nearly all of them to be run in the same VM, then that is probably better than running 3,000 tests in separate VMs for the sake of our pre-commit testing. For the nightly run, we can certainly run them all in their same VM so that the analysis phase of failures is much simpler. > > For reliability testing running them all in the same VM would actually improve the coverage of our tests. If there is a snowball failure, then an option to run them in separate VMs to sanity check if a single test is causing the problem would be nice, but if we can't survive running them all in the same VM then something is wrong with the product and we should definitely know that... > > ...jim From hang.vo at oracle.com Wed Feb 6 17:48:10 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Feb 2013 01:48:10 +0000 Subject: hg: openjfx/8/graphics/rt: Updated copyright headers on decora-compiler .g and .stg files Message-ID: <20130207014813.94C06478AE@hg.openjdk.java.net> Changeset: c6fb5c694336 Author: Richard Bair Date: 2013-02-06 17:42 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c6fb5c694336 Updated copyright headers on decora-compiler .g and .stg files ! decora-compiler/src/com/sun/scenario/effect/compiler/JSL.g ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/jogl/JOGLGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/rsl/RSLGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/prism/PrismGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MEJavaGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MENativeGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSEJavaGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSENativeGlue.stg From hang.vo at oracle.com Wed Feb 6 18:33:02 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Feb 2013 02:33:02 +0000 Subject: hg: openjfx/8/graphics/rt: Fixed Pagination* copyright headers Message-ID: <20130207023304.45F64478B2@hg.openjdk.java.net> Changeset: 74bb20d3b013 Author: Richard Bair Date: 2013-02-06 18:19 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/74bb20d3b013 Fixed Pagination* copyright headers ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/PaginationBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java From hang.vo at oracle.com Wed Feb 6 19:33:01 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Feb 2013 03:33:01 +0000 Subject: hg: openjfx/8/controls/rt: Fixed RT-28255: Remove PSEUDO_CLASS_OVERRIDE from Node Message-ID: <20130207033305.684E9478B3@hg.openjdk.java.net> Changeset: 30fb7b4a2195 Author: "Jasper Potts" Date: 2013-02-06 19:18 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/30fb7b4a2195 Fixed RT-28255: Remove PSEUDO_CLASS_OVERRIDE from Node ! apps/experiments/Modena/src/modena/SamplePage.java ! javafx-ui-common/src/javafx/scene/Node.java From chien.yang at oracle.com Thu Feb 7 00:43:22 2013 From: chien.yang at oracle.com (Chien Yang) Date: Thu, 07 Feb 2013 00:43:22 -0800 Subject: [API Review] FX 8 3D API In-Reply-To: <5112C6C0.5020803@oracle.com> References: <510C1B8D.4060302@oracle.com> <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> <5112A71A.50502@oracle.com> <5112AD50.1040807@oracle.com> <268F341F-8FCE-4FB5-AB18-A54E873B3931@oracle.com> <5112C19A.7050009@oracle.com> <3ACF3F09-8EF8-4A7A-ACCD-E1D3CB6F141C@oracle.com> <5112C6C0.5020803@oracle.com> Message-ID: <5113692A.8020300@oracle.com> Just a quick update. Kevin, Richard and I have an offline discussion on grouping of new 3D classes. After talking through the pros and cons possible grouping approaches. We agreed to collapse the packages as follows: move all (9) classes from javafx.scene.shape3d ==> javafx.scene.shape move all (2) classes from javafx.scene.material ==> javafx.scene.paint move all (3) classes from javafx.scene.light ==> javafx.scene and also change LOD helper, Node.areaInScene, a read only property to a compute method. I will update the JIRA issue and generate a new API docs for approval tomorrow. - Chien On 2/6/2013 1:10 PM, Chien Yang wrote: > I don't foresee the need to add dozens, but an additional of 10 > classes might be a reasonable expectation. :-) > > - Chien > > On 2/6/2013 12:53 PM, Richard Bair wrote: >> I would hope we're going to support user defined shaders. That >> doesn't mean some additional materials aren't a good idea. But we're >> not talking about dozens of additional classes, right? >> >> On Feb 6, 2013, at 12:48 PM, Chien Yang wrote: >> >>> Don't exactly know at this point, but we did talk about adding >>> high-order surfaces and additional light types at one point. We >>> will very likely need to support more material types if we want to >>> hold the line of not supporting user defined shader. >>> >>> - Chien >>> >>> On 2/6/2013 11:22 AM, Richard Bair wrote: >>>> How much? >>>> >>>> On Feb 6, 2013, at 11:21 AM, Chien Yang wrote: >>>> >>>>> Hi Richard, >>>>> >>>>> The number of classes in shape3d, light and material packages >>>>> will certainly grow in future releases too as we add more features. >>>>> >>>>> - Chien >>>>> >>>>> On 2/6/2013 10:55 AM, Kevin Rushforth wrote: >>>>>> They could all be put in the shape3d package, but it seems >>>>>> inconsistent with 2D packages: shape, paint effect, etc. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Richard Bair wrote: >>>>>>> Hi Chien, >>>>>>> >>>>>>>> javafx.scene.light.LightBase (abstract) >>>>>>>> javafx.scene.material.Material (abstract) >>>>>>> I'm not jazzed about creating two new packages here. It seems >>>>>>> like these things should all be grouped in the same place as >>>>>>> camera, or shape3d. Ideas? >>>>>>> >>>>>>>> Methods and Properties added to Node >>>>>>>> --------------------------------------------------------- >>>>>>>> >>>>>>>> LOD helper property: >>>>>>>> >>>>>>>> /** >>>>>>>> * A read only property that stores the computed area of this >>>>>>>> * {@code Node} projected onto the physical screen in pixel unit. >>>>>>>> */ >>>>>>>> public final double getAreaInScreen() >>>>>>>> public final javafx.beans.property.ReadOnlyDoubleProperty >>>>>>>> areaInScreenProperty() >>>>>>> Can this be efficiently implemented? We ripped out boundsInScene >>>>>>> because it was impossible to get it fast enough. Why would this >>>>>>> be any different? >>>>>>> >>>>>>> The rest looks good. >>>>>>> >>>>>>> Richard > From hang.vo at oracle.com Thu Feb 7 01:04:10 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Feb 2013 09:04:10 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130207090417.48859478C3@hg.openjdk.java.net> Changeset: e1971713872e Author: Martin Sladecek Date: 2013-02-07 08:54 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e1971713872e Renamed AnimationMock in javafx-ui-common to avoid name clash with AnimationMock in javafx-anim + javafx-ui-common/test/unit/javafx/animation/AnimationDummy.java - javafx-ui-common/test/unit/javafx/animation/AnimationMock.java ! javafx-ui-common/test/unit/javafx/animation/ParallelTransitionTest.java ! javafx-ui-common/test/unit/javafx/animation/SequentialTransitionTest.java Changeset: 07a0f071ae9b Author: Martin Sladecek Date: 2013-02-07 09:47 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/07a0f071ae9b merge - javafx-ui-common/test/unit/javafx/animation/AnimationMock.java From alexandre.iline at oracle.com Thu Feb 7 04:55:54 2013 From: alexandre.iline at oracle.com (alexandre.iline at oracle.com) Date: Thu, 07 Feb 2013 12:55:54 +0000 Subject: hg: openjfx/8/master/tests: jfxrt.jar moved Message-ID: <20130207125555.93F63478D8@hg.openjdk.java.net> Changeset: 42dc091bb4f7 Author: Alexandre (Shura) Iline Date: 2013-02-07 16:53 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/42dc091bb4f7 jfxrt.jar moved ! .hgignore ! detect_javafx.xml ! tools/Jemmy/GlassImage/nbproject/project.properties ! tools/Jemmy/GlassRobot/nbproject/project.properties ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFXBrowser/nbproject/project.properties From hang.vo at oracle.com Thu Feb 7 05:33:01 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Feb 2013 13:33:01 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28028: Affine internal state was broken after unsuccessful invert. Message-ID: <20130207133311.7CB5F478D9@hg.openjdk.java.net> Changeset: 3919f556c448 Author: Pavel Safrata Date: 2013-02-07 13:19 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3919f556c448 RT-28028: Affine internal state was broken after unsuccessful invert. ! javafx-ui-common/src/javafx/scene/transform/Affine.java ! javafx-ui-common/test/unit/javafx/scene/transform/AffineOperationsTest.java From neugens at redhat.com Thu Feb 7 07:00:50 2013 From: neugens at redhat.com (Mario Torre) Date: Thu, 07 Feb 2013 16:00:50 +0100 Subject: How to build openjfx in its current state Message-ID: <1360249250.1911.8.camel@pegasus> Hi all! The build instructions for building OpenJFX seems a bit outdated (or I'm reading them wrong), and no matter how I try I always get compilation failures (I'm trying OpenJFX 8 :). Dalibor presentation at FOSDEM was about this how to build OpenJFX from sources, but I didn't take notes :) Is it possible to have a quick refresher? And speaking about that, I remember that Richard was doing some experiments with Gradle, did you made some progress in that regard or is there anything we can do to help on that? Cheers, Mario From richard.bair at oracle.com Thu Feb 7 08:18:52 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 7 Feb 2013 08:18:52 -0800 Subject: How to build openjfx in its current state In-Reply-To: <1360249250.1911.8.camel@pegasus> References: <1360249250.1911.8.camel@pegasus> Message-ID: <3EB531F7-F96C-4E28-8BC8-D05DBDAB102E@oracle.com> Hi Mario, I would love help! I've pushed both the gradle files (generator.gradle & build.gradle) into the rt repository. Danno reported that the build didn't succeed due to some decora issues -- I'm going to open source the rest of decora here in a few minutes and then work on the public-only build scripts to make sure that what is there will compile. There is a lot left to do on the scripts. I'm keeping a running list at the head of the file: * Tasks to complete: * - special tasks for common needs, such as: * - updating copyright headers * - stripping trailing whitespace (?) * - checkstyle * - findbugs * - re needs? * - testing * - build check -- making sure the final artifact has the right bits * - API change check * - JavaDoc * - Pushing results to a repo? * - VersionInfo needs to be parameterized so hudson can produce valid values * - partial builds for compileXXX shaders isn't working (they also get compiled) * - ServiceWithSecurityManagerTest fails to complete when run from gradle. This list is probably only 30% of the remaining tasks, as I find them I'm trying to keep it updated. The JIRA issues are: http://javafx-jira.kenai.com/browse/RT-28089 http://javafx-jira.kenai.com/browse/RT-28088 I'm learning Gradle as I'm going so in addition to just the normal work, there's a lot of learning going on. Also the build scripts are no doubt not factored optimally etc. I'm really enjoying Gradle though, there is a lot of convenience both for the script author and the normal developer just trying to do a build. Once the Decora bits are open, the next major issue is going to be building native code, figuring out how we are going to approach that. What I want is the ability to skip building natives and just reuse a pre-built native if it is available, but this will not work until continuous binaries are posted into a repository that we can download from. In the mean time, developers are going to need to make sure they have the appropriate open build tools installed. Also, we should update the build instructions on the wiki. I am all setup to do screencasts and would like to post some to YouTube as well and link them from our wiki in addition to normal textual instructions. Some of the things I've been keeping track of in that regard: ============================== Build System TOI ? Building ? gradle tasks ? gradle tasks --all ? gradle graphics:test ? gradle graphics:test -Dtest.single=FooBarTest ? debugging tests When setting up Intellij, the SDK MUST NOT HAVE JFXRT.JAR on the CLASSPATH!! ============================== Richard On Feb 7, 2013, at 7:00 AM, Mario Torre wrote: > Hi all! > > The build instructions for building OpenJFX seems a bit outdated (or I'm > reading them wrong), and no matter how I try I always get compilation > failures (I'm trying OpenJFX 8 :). > > Dalibor presentation at FOSDEM was about this how to build OpenJFX from > sources, but I didn't take notes :) > > Is it possible to have a quick refresher? > > And speaking about that, I remember that Richard was doing some > experiments with Gradle, did you made some progress in that regard or is > there anything we can do to help on that? > > Cheers, > Mario > > From richard.bair at oracle.com Thu Feb 7 08:25:44 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 7 Feb 2013 08:25:44 -0800 Subject: [API Review] FX 8 3D API In-Reply-To: <5113692A.8020300@oracle.com> References: <510C1B8D.4060302@oracle.com> <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> <5112A71A.50502@oracle.com> <5112AD50.1040807@oracle.com> <268F341F-8FCE-4FB5-AB18-A54E873B3931@oracle.com> <5112C19A.7050009@oracle.com> <3ACF3F09-8EF8-4A7A-ACCD-E1D3CB6F141C@oracle.com> <5112C6C0.5020803@oracle.com> <5113692A.8020300@oracle.com> Message-ID: <90D2394C-E9B2-4B9C-898F-DA74A15AAE86@oracle.com> +1 On Feb 7, 2013, at 12:43 AM, Chien Yang wrote: > Just a quick update. Kevin, Richard and I have an offline discussion on grouping of new 3D classes. After talking through the pros and cons possible grouping approaches. We agreed to collapse the packages as follows: > > move all (9) classes from javafx.scene.shape3d ==> javafx.scene.shape > move all (2) classes from javafx.scene.material ==> javafx.scene.paint > move all (3) classes from javafx.scene.light ==> javafx.scene > > and also change LOD helper, Node.areaInScene, a read only property to a compute method. I will update the JIRA issue and generate a new API docs for approval tomorrow. > > - Chien > > On 2/6/2013 1:10 PM, Chien Yang wrote: >> I don't foresee the need to add dozens, but an additional of 10 classes might be a reasonable expectation. :-) >> >> - Chien >> >> On 2/6/2013 12:53 PM, Richard Bair wrote: >>> I would hope we're going to support user defined shaders. That doesn't mean some additional materials aren't a good idea. But we're not talking about dozens of additional classes, right? >>> >>> On Feb 6, 2013, at 12:48 PM, Chien Yang wrote: >>> >>>> Don't exactly know at this point, but we did talk about adding high-order surfaces and additional light types at one point. We will very likely need to support more material types if we want to hold the line of not supporting user defined shader. >>>> >>>> - Chien >>>> >>>> On 2/6/2013 11:22 AM, Richard Bair wrote: >>>>> How much? >>>>> >>>>> On Feb 6, 2013, at 11:21 AM, Chien Yang wrote: >>>>> >>>>>> Hi Richard, >>>>>> >>>>>> The number of classes in shape3d, light and material packages will certainly grow in future releases too as we add more features. >>>>>> >>>>>> - Chien >>>>>> >>>>>> On 2/6/2013 10:55 AM, Kevin Rushforth wrote: >>>>>>> They could all be put in the shape3d package, but it seems inconsistent with 2D packages: shape, paint effect, etc. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> Richard Bair wrote: >>>>>>>> Hi Chien, >>>>>>>> >>>>>>>>> javafx.scene.light.LightBase (abstract) >>>>>>>>> javafx.scene.material.Material (abstract) >>>>>>>> I'm not jazzed about creating two new packages here. It seems like these things should all be grouped in the same place as camera, or shape3d. Ideas? >>>>>>>> >>>>>>>>> Methods and Properties added to Node >>>>>>>>> --------------------------------------------------------- >>>>>>>>> >>>>>>>>> LOD helper property: >>>>>>>>> >>>>>>>>> /** >>>>>>>>> * A read only property that stores the computed area of this >>>>>>>>> * {@code Node} projected onto the physical screen in pixel unit. >>>>>>>>> */ >>>>>>>>> public final double getAreaInScreen() >>>>>>>>> public final javafx.beans.property.ReadOnlyDoubleProperty areaInScreenProperty() >>>>>>>> Can this be efficiently implemented? We ripped out boundsInScene because it was impossible to get it fast enough. Why would this be any different? >>>>>>>> >>>>>>>> The rest looks good. >>>>>>>> >>>>>>>> Richard >> > From steve.x.northover at oracle.com Thu Feb 7 08:50:03 2013 From: steve.x.northover at oracle.com (steve.x.northover at oracle.com) Date: Thu, 07 Feb 2013 11:50:03 -0500 Subject: How to build openjfx in its current state In-Reply-To: <1360249250.1911.8.camel@pegasus> References: <1360249250.1911.8.camel@pegasus> Message-ID: <5113DB3B.3070005@oracle.com> This is the wiki that is kept up to date: https://wikis.oracle.com/display/OpenJDK/OpenJFX It is sad to say, but the OpenJDK project page is outdated (http://openjdk.java.net/projects/openjfx/getting-started.html). It turns out that trying to keep this page up to date is a pain in the ass. Yay, OpenJDK! Steve On 07/02/2013 10:00 AM, Mario Torre wrote: > Hi all! > > The build instructions for building OpenJFX seems a bit outdated (or I'm > reading them wrong), and no matter how I try I always get compilation > failures (I'm trying OpenJFX 8 :). > > Dalibor presentation at FOSDEM was about this how to build OpenJFX from > sources, but I didn't take notes :) > > Is it possible to have a quick refresher? > > And speaking about that, I remember that Richard was doing some > experiments with Gradle, did you made some progress in that regard or is > there anything we can do to help on that? > > Cheers, > Mario > > From hang.vo at oracle.com Thu Feb 7 08:48:12 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Feb 2013 16:48:12 +0000 Subject: hg: openjfx/8/graphics/rt: 36 new changesets Message-ID: <20130207164912.99F7E478E2@hg.openjdk.java.net> Changeset: ddcec14f0d81 Author: Jonathan Giles Date: 2013-02-01 09:58 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ddcec14f0d81 RT-28100: Make internal KeyBinding class consistent with key events and simplify cross-platform controls behaviour code. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/KeyBinding.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/OrientedKeyBinding.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextBinding.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/test/javafx/scene/control/KeyEventFirer.java ! javafx-ui-controls/test/javafx/scene/control/KeyModifier.java ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java Changeset: 46d18078dffd Author: Jonathan Giles Date: 2013-02-01 10:02 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/46d18078dffd Merge Changeset: 78544be55907 Author: jgiles Date: 2013-01-31 09:08 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/78544be55907 RT-24484: [TreeView, TreeTableView] Should support clickCounts greater than 2 (by expanding / collapsing branches when clickCount % 2 == 0) ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java Changeset: 9b7793501d71 Author: jgiles Date: 2013-01-31 09:11 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9b7793501d71 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 1877fab88c54 Author: jgiles Date: 2013-02-01 10:04 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1877fab88c54 RT-28098: [TreeView, TreeTableView] Disclosure nodes should animate when branches are expanded / collapsed Whilst a trivial tweak, I mainly did this to drill down into functional issues and performance of TreeView and TreeTableView. I believe performance is significantly improved now, but I am pushing to the repo to get performance numbers across the board from our perf tests. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css ! javafx-ui-controls/src/javafx/scene/control/TreeTableRow.java Changeset: fb32a5e26397 Author: jgiles Date: 2013-02-01 10:08 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fb32a5e26397 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: cc7fed4a834c Author: mickf Date: 2013-02-01 15:27 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/cc7fed4a834c RT-28130 : Resolve Findbugs issues in com.sun.javafx.scene.control.ScrollBar ! javafx-ui-controls/src/javafx/scene/control/ScrollBar.java Changeset: 74802b5965e1 Author: David Grieve Date: 2013-02-01 11:16 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/74802b5965e1 RT-25288: add support for functional pseudo-class :dir() ! javafx-ui-common/src/com/sun/javafx/css/Match.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java ! javafx-ui-common/src/javafx/scene/Scene.java + javafx-ui-common/test/unit/javafx/scene/Node_effectiveOrientation_Css_Test.java Changeset: f440bb18e36e Author: David Grieve Date: 2013-02-01 12:41 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f440bb18e36e RT-25288: previous changeset for this bug introduced an index out of bounds exception coming from PseudoClassSet ! javafx-ui-common/src/com/sun/javafx/css/PseudoClassSet.java Changeset: 3b32a4d8521d Author: David Grieve Date: 2013-02-01 12:56 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3b32a4d8521d RT-27472: check if term returns null. if so, skip expr ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java Changeset: ec3108783ed1 Author: Paru Somashekar Date: 2013-02-01 16:31 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ec3108783ed1 fix RT-27901 LineChart series colors are not unique & RT-28090 PieChart throws IAE when elements are sorted ! javafx-ui-charts/src/javafx/scene/chart/AreaChart.java ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java ! javafx-ui-charts/src/javafx/scene/chart/LineChart.java ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java Changeset: 33ec77bbf951 Author: jgiles Date: 2013-02-01 14:29 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/33ec77bbf951 [TEST ONLY] Added two unit tests for RT-28113: [TreeView, TreeTableView] Focus jumps to TreeItem sibling when child TreeItem is removed. Both tests are @Ignore'd at the moment, pending a chance to resolve the bug. ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: 66a0f97af26d Author: jgiles Date: 2013-02-01 17:17 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/66a0f97af26d Remove accidental println. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java Changeset: c954f63ec612 Author: jgiles Date: 2013-02-02 09:43 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c954f63ec612 RT-25142: ComboBox accepts setItems(null) but later throws NPE when layout() is called. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 84b84a9d3d5d Author: jgiles Date: 2013-02-04 14:49 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/84b84a9d3d5d Further work on RT-28100: Make internal KeyBinding class consistent with key events and simplify cross-platform controls behaviour code. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/KeyBinding.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/OrientedKeyBinding.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java ! javafx-ui-controls/test/javafx/scene/control/KeyEventFirer.java ! javafx-ui-controls/test/javafx/scene/control/KeyModifier.java Changeset: 8727876146cb Author: jgiles Date: 2013-02-04 14:49 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8727876146cb [TEST ONLY] Added unit tests for RT-28065 (although the tests are disabled until a fix is in place). ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewKeyInputTest.java Changeset: b7bfb47e2654 Author: jgiles Date: 2013-02-04 15:13 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b7bfb47e2654 RT-27829: Clean up controls compilation warnings (part two) Contributed-By: Tom Schindl Reviewed-By: jgiles ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java ! javafx-ui-controls/src/javafx/scene/control/ScrollToEvent.java ! javafx-ui-controls/src/javafx/scene/control/Separator.java ! javafx-ui-controls/src/javafx/scene/control/Tab.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TablePosition.java ! javafx-ui-controls/src/javafx/scene/control/TitledPane.java ! javafx-ui-controls/src/javafx/scene/control/ToggleButton.java ! javafx-ui-controls/src/javafx/scene/control/ToolBar.java ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java ! javafx-ui-controls/src/javafx/scene/control/TreeCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeItem.java ! javafx-ui-controls/src/javafx/scene/control/TreeTablePosition.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableRow.java Changeset: 0e085e2dce76 Author: jgiles Date: 2013-02-04 15:17 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0e085e2dce76 RT-28128: TableColumnBase.DEFAULT_COMPARATOR can lead to CCE Contributed-By: Tom Schindl Reviewed-By: jgiles ! javafx-ui-controls/src/javafx/scene/control/TableColumnBase.java Changeset: 29207ea36ee0 Author: jgiles Date: 2013-02-04 17:03 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/29207ea36ee0 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 8252bde86002 Author: Jonathan Giles Date: 2013-02-04 19:00 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8252bde86002 Significantly improved keyboard navigation support for ListView, TreeView, TableView and TreeTableView on Mac OS (as part of RT-27658). Additionally, I have fixed up all the *KeyInputTest unit tests to run and pass on Mac OS, although due to memory limitations of the build servers they continue to be @Ignore'd. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewKeyInputTest.java Changeset: 3408eed98c2c Author: mickf Date: 2013-02-04 14:58 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3408eed98c2c RT-22977 : Keyboard focus Traversal : Non-mouse Traversal Input ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ChoiceBoxBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ComboBoxBaseBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/SliderBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/Utils.java Changeset: 1310b65cbceb Author: mickf Date: 2013-02-04 15:54 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1310b65cbceb RT-28042 : Resolve Findbugs issues in com.sun.javafx.scene.control.skin.Utils ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/Utils.java Changeset: f6b77bf59fff Author: David Grieve Date: 2013-02-04 16:29 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f6b77bf59fff branch merge ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 38b3163d69ac Author: Paru Somashekar Date: 2013-02-04 16:52 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/38b3163d69ac RT-23123 autoranging lead to charts incorrect appearance ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java Changeset: 16b8b81ecfcd Author: jgiles Date: 2013-02-05 11:52 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/16b8b81ecfcd [TEST ONLY] Added unit test for RT-24412 ! javafx-ui-controls/test/javafx/scene/control/ComboBoxTest.java Changeset: 3f20a5e249d9 Author: jgiles Date: 2013-02-05 16:06 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3f20a5e249d9 RT-27852: [TreeView, TreeTableView] expanding/collapsing doesn't work when resetting the root of the TreeView. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeViewSkin.java Changeset: c46edc2e930f Author: jgiles Date: 2013-02-05 16:13 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c46edc2e930f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 3587d30fc228 Author: David Grieve Date: 2013-02-05 10:44 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3587d30fc228 RT-23691: stylemanager leaks like a sieve. ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/application/Application.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/stage/Window.java ! javafx-ui-common/test/unit/com/sun/javafx/css/CssMetaDataTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleManagerTest.java ! javafx-ui-common/test/unit/javafx/scene/Node_effectiveOrientation_Css_Test.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/test/javafx/scene/control/PopupControlTest.java Changeset: 94130cc6c0a2 Author: Paru Somashekar Date: 2013-02-05 08:53 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/94130cc6c0a2 RT-24342 ColorPicker missing javadoc. ! javafx-ui-controls/src/javafx/scene/control/ColorPicker.java Changeset: 98da68b53ff0 Author: David Grieve Date: 2013-02-05 11:50 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/98da68b53ff0 RT-27155: if setting value raises exception, reset value the value to initial and thereafter skip setting the property ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: 6dea9882cca3 Author: David Grieve Date: 2013-02-05 11:51 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6dea9882cca3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/rt Changeset: 7c234c222c85 Author: Paru Somashekar Date: 2013-02-05 15:18 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7c234c222c85 RT-23091 PieChart data changed issue, RT-24847 Grab testing NPE & RT-15291: Resetting data in LineChart issue ! javafx-ui-charts/src/javafx/scene/chart/LineChart.java ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java Changeset: ffa3ff5846b9 Author: "Jasper Potts" Date: 2013-02-05 17:02 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ffa3ff5846b9 Modena test app, added new page and upated tests. ! apps/experiments/Modena/src/modena/Modena.java ! apps/experiments/Modena/src/modena/SamplePage.java ! apps/experiments/Modena/src/modena/SamplePageHelpers.java ! apps/experiments/Modena/src/modena/SimpleWindowPage.java ! apps/experiments/Modena/src/modena/TestApp.css ! apps/experiments/Modena/src/modena/simple-window.fxml ! apps/experiments/Modena/src/modena/simple-window.fxml.bak + apps/experiments/Modena/src/modena/ubuntu-window-frame.png ! apps/experiments/Modena/src/modena/ui-mosaic.fxml + apps/experiments/Modena/src/modena/ui-mosaic.fxml.bak + apps/experiments/Modena/src/modena/windows7-window-frame.png ! apps/experiments/Modena/src/modena/windows8-window-frame.png Changeset: 5fdb62478264 Author: "Jasper Potts" Date: 2013-02-05 17:02 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5fdb62478264 Modena theme, changed to less rounded corners and blue focus color. Lots of other little tweeks as a result ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 27a5dff62edc Author: David Grieve Date: 2013-02-06 10:28 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/27a5dff62edc branch merge - javafx-concurrent/test/javafx/concurrent/AbstractService.java - javafx-sg-common/src/com/sun/javafx/sg/DirtyRegionContainer.java - javafx-sg-common/src/com/sun/javafx/sg/DirtyRegionPool.java - javafx-sg-common/src/com/sun/javafx/sg/PGSpan.java - javafx-sg-common/src/com/sun/javafx/sg/PGTextHelper.java - javafx-sg-common/test/com/sun/javafx/sg/DirtyRegionContainerTest.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGSpan.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGTextHelper.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubSpan.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextHelper.java Changeset: ee1e4c0502d4 Author: jgodinez Date: 2013-02-07 08:37 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ee1e4c0502d4 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGMediaView.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/PrismMediaFrameHandler.java ! javafx-ui-common/src/javafx/scene/Node.java - javafx-ui-common/test/unit/javafx/animation/AnimationMock.java From neugens at redhat.com Thu Feb 7 09:10:52 2013 From: neugens at redhat.com (Mario Torre) Date: Thu, 07 Feb 2013 18:10:52 +0100 Subject: How to build openjfx in its current state In-Reply-To: <5113DB3B.3070005@oracle.com> References: <1360249250.1911.8.camel@pegasus> <5113DB3B.3070005@oracle.com> Message-ID: <1360257052.1911.11.camel@pegasus> Il giorno gio, 07/02/2013 alle 11.50 -0500, steve.x.northover at oracle.com ha scritto: > This is the wiki that is kept up to date: > https://wikis.oracle.com/display/OpenJDK/OpenJFX > > It is sad to say, but the OpenJDK project page is outdated > (http://openjdk.java.net/projects/openjfx/getting-started.html). It > turns out that trying to keep this page up to date is a pain in the > ass. Yay, OpenJDK! Yeah, I know this from experience... Perhaps the page could just link to the wiki? There is no need really to have the OpenJDK page, it can just link to the appropriate page, and it would be way less confusing. I can provide with the html changes if you point me to the web page sources, so you just need to push the change. Cheers, Mario From chien.yang at oracle.com Thu Feb 7 09:19:44 2013 From: chien.yang at oracle.com (Chien Yang) Date: Thu, 07 Feb 2013 09:19:44 -0800 Subject: [API Review] FX 8 3D API In-Reply-To: <90D2394C-E9B2-4B9C-898F-DA74A15AAE86@oracle.com> References: <510C1B8D.4060302@oracle.com> <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> <5112A71A.50502@oracle.com> <5112AD50.1040807@oracle.com> <268F341F-8FCE-4FB5-AB18-A54E873B3931@oracle.com> <5112C19A.7050009@oracle.com> <3ACF3F09-8EF8-4A7A-ACCD-E1D3CB6F141C@oracle.com> <5112C6C0.5020803@oracle.com> <5113692A.8020300@oracle.com> <90D2394C-E9B2-4B9C-898F-DA74A15AAE86@oracle.com> Message-ID: <5113E230.4080302@oracle.com> Thanks Richard! I have updated the 3D Features wiki and generated the API docs that only include the affected packages: 3D Features planned for JavaFX 8: https://wikis.oracle.com/display/OpenJDK/3D+Features API docs: http://javafx-jira.kenai.com/secure/attachment/35325/API-Review-Final-docs-v2.zip Please check it out if you are interested. - Chien On 2/7/2013 8:25 AM, Richard Bair wrote: > +1 > > On Feb 7, 2013, at 12:43 AM, Chien Yang wrote: > >> Just a quick update. Kevin, Richard and I have an offline discussion on grouping of new 3D classes. After talking through the pros and cons possible grouping approaches. We agreed to collapse the packages as follows: >> >> move all (9) classes from javafx.scene.shape3d ==> javafx.scene.shape >> move all (2) classes from javafx.scene.material ==> javafx.scene.paint >> move all (3) classes from javafx.scene.light ==> javafx.scene >> >> and also change LOD helper, Node.areaInScene, a read only property to a compute method. I will update the JIRA issue and generate a new API docs for approval tomorrow. >> >> - Chien >> >> On 2/6/2013 1:10 PM, Chien Yang wrote: >>> I don't foresee the need to add dozens, but an additional of 10 classes might be a reasonable expectation. :-) >>> >>> - Chien >>> >>> On 2/6/2013 12:53 PM, Richard Bair wrote: >>>> I would hope we're going to support user defined shaders. That doesn't mean some additional materials aren't a good idea. But we're not talking about dozens of additional classes, right? >>>> >>>> On Feb 6, 2013, at 12:48 PM, Chien Yang wrote: >>>> >>>>> Don't exactly know at this point, but we did talk about adding high-order surfaces and additional light types at one point. We will very likely need to support more material types if we want to hold the line of not supporting user defined shader. >>>>> >>>>> - Chien >>>>> >>>>> On 2/6/2013 11:22 AM, Richard Bair wrote: >>>>>> How much? >>>>>> >>>>>> On Feb 6, 2013, at 11:21 AM, Chien Yang wrote: >>>>>> >>>>>>> Hi Richard, >>>>>>> >>>>>>> The number of classes in shape3d, light and material packages will certainly grow in future releases too as we add more features. >>>>>>> >>>>>>> - Chien >>>>>>> >>>>>>> On 2/6/2013 10:55 AM, Kevin Rushforth wrote: >>>>>>>> They could all be put in the shape3d package, but it seems inconsistent with 2D packages: shape, paint effect, etc. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> Richard Bair wrote: >>>>>>>>> Hi Chien, >>>>>>>>> >>>>>>>>>> javafx.scene.light.LightBase (abstract) >>>>>>>>>> javafx.scene.material.Material (abstract) >>>>>>>>> I'm not jazzed about creating two new packages here. It seems like these things should all be grouped in the same place as camera, or shape3d. Ideas? >>>>>>>>> >>>>>>>>>> Methods and Properties added to Node >>>>>>>>>> --------------------------------------------------------- >>>>>>>>>> >>>>>>>>>> LOD helper property: >>>>>>>>>> >>>>>>>>>> /** >>>>>>>>>> * A read only property that stores the computed area of this >>>>>>>>>> * {@code Node} projected onto the physical screen in pixel unit. >>>>>>>>>> */ >>>>>>>>>> public final double getAreaInScreen() >>>>>>>>>> public final javafx.beans.property.ReadOnlyDoubleProperty areaInScreenProperty() >>>>>>>>> Can this be efficiently implemented? We ripped out boundsInScene because it was impossible to get it fast enough. Why would this be any different? >>>>>>>>> >>>>>>>>> The rest looks good. >>>>>>>>> >>>>>>>>> Richard From neugens at redhat.com Thu Feb 7 10:13:52 2013 From: neugens at redhat.com (Mario Torre) Date: Thu, 07 Feb 2013 19:13:52 +0100 Subject: How to build openjfx in its current state In-Reply-To: <5113DB3B.3070005@oracle.com> References: <1360249250.1911.8.camel@pegasus> <5113DB3B.3070005@oracle.com> Message-ID: <1360260832.1911.13.camel@pegasus> Il giorno gio, 07/02/2013 alle 11.50 -0500, steve.x.northover at oracle.com ha scritto: > This is the wiki that is kept up to date: > https://wikis.oracle.com/display/OpenJDK/OpenJFX Actually, the jfxrt.jar was moved recently into lib/ext. If you agree I will edit the wikipage to reflect that change. Cheers, Mario From David.Hill at Oracle.com Thu Feb 7 10:19:06 2013 From: David.Hill at Oracle.com (David Hill) Date: Thu, 07 Feb 2013 13:19:06 -0500 Subject: How to build openjfx in its current state In-Reply-To: <1360260832.1911.13.camel@pegasus> References: <1360249250.1911.8.camel@pegasus> <5113DB3B.3070005@oracle.com> <1360260832.1911.13.camel@pegasus> Message-ID: <5113F01A.8060808@Oracle.com> On 2/7/13 Feb 7, 1:13 PM, Mario Torre wrote: > Il giorno gio, 07/02/2013 alle 11.50 -0500, steve.x.northover at oracle.com > ha scritto: >> This is the wiki that is kept up to date: >> https://wikis.oracle.com/display/OpenJDK/OpenJFX > Actually, the jfxrt.jar was moved recently into lib/ext. > > If you agree I will edit the wikipage to reflect that change. > > Cheers, > Mario > Mario - it just so happens that I was about to change the wiki.... check in 5 to make sure it look good :-) Dave -- David Hill Java Embedded Development Truth is more of a stranger than fiction. -- Mark Twain From neugens at redhat.com Thu Feb 7 10:34:47 2013 From: neugens at redhat.com (Mario Torre) Date: Thu, 07 Feb 2013 19:34:47 +0100 Subject: How to build openjfx in its current state In-Reply-To: <5113F01A.8060808@Oracle.com> References: <1360249250.1911.8.camel@pegasus> <5113DB3B.3070005@oracle.com> <1360260832.1911.13.camel@pegasus> <5113F01A.8060808@Oracle.com> Message-ID: <1360262087.1911.14.camel@pegasus> Il giorno gio, 07/02/2013 alle 13.19 -0500, David Hill ha scritto: > On 2/7/13 Feb 7, 1:13 PM, Mario Torre wrote: > > Il giorno gio, 07/02/2013 alle 11.50 -0500, steve.x.northover at oracle.com > > ha scritto: > >> This is the wiki that is kept up to date: > >> https://wikis.oracle.com/display/OpenJDK/OpenJFX > > Actually, the jfxrt.jar was moved recently into lib/ext. > > > > If you agree I will edit the wikipage to reflect that change. > > > > Cheers, > > Mario > > > Mario - it just so happens that I was about to change the wiki.... check in 5 to make sure it look good :-) Hehe, cool :) Thanks, Mario From neugens at redhat.com Thu Feb 7 11:06:48 2013 From: neugens at redhat.com (Mario Torre) Date: Thu, 07 Feb 2013 20:06:48 +0100 Subject: How to build openjfx in its current state In-Reply-To: <3EB531F7-F96C-4E28-8BC8-D05DBDAB102E@oracle.com> References: <1360249250.1911.8.camel@pegasus> <3EB531F7-F96C-4E28-8BC8-D05DBDAB102E@oracle.com> Message-ID: <1360264008.1911.28.camel@pegasus> Il giorno gio, 07/02/2013 alle 08.18 -0800, Richard Bair ha scritto: > Hi Mario, > > I would love help! I've pushed both the gradle files (generator.gradle > & build.gradle) into the rt repository. Danno reported that the build > didn't succeed due to some decora issues -- I'm going to open source > the rest of decora here in a few minutes and then work on the > public-only build scripts to make sure that what is there will > compile. Great, I'll give a look at it as soon as decora is out. I guess I need to wait that everything gets synced in the master repo, right? > When setting up Intellij, the SDK MUST NOT HAVE JFXRT.JAR on the > CLASSPATH!! You know if it works with NetBeans too? I would love to keep using NetBeans :) Or will you keep the ant and ide specific files around? Cheers, Mario From neugens at redhat.com Thu Feb 7 11:22:45 2013 From: neugens at redhat.com (Mario Torre) Date: Thu, 07 Feb 2013 20:22:45 +0100 Subject: How to build openjfx in its current state In-Reply-To: <1360249250.1911.8.camel@pegasus> References: <1360249250.1911.8.camel@pegasus> Message-ID: <1360264965.1911.35.camel@pegasus> Il giorno gio, 07/02/2013 alle 16.00 +0100, Mario Torre ha scritto: > Hi all! > > The build instructions for building OpenJFX seems a bit outdated (or I'm > reading them wrong), and no matter how I try I always get compilation > failures (I'm trying OpenJFX 8 :). Just a quick follow up: [neugens at pegasus rt]$ ls dist openjfxrt.jar This is built with OpenJDK, no closed JDK :) I had to copy the jfxrt.jar into the lib/ext directory though. Is the artifacts/sdk/rt/lib/jfxrt.jar actually really used to build OpenJFX? It would be nice if we could just rely on that rather than use the JDK embedded copy of the jar. What is the content of the openjfx,jar? Does it contain also the closed classes or is purely the open ones? Cheers, Mario From joseph.andresen at oracle.com Thu Feb 7 12:01:35 2013 From: joseph.andresen at oracle.com (Joseph Andresen) Date: Thu, 7 Feb 2013 12:01:35 -0800 Subject: [API Review] FX 8 3D API In-Reply-To: <5113692A.8020300@oracle.com> References: <510C1B8D.4060302@oracle.com> <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> <5112A71A.50502@oracle.com> <5112AD50.1040807@oracle.com> <268F341F-8FCE-4FB5-AB18-A54E873B3931@oracle.com> <5112C19A.7050009@oracle.com> <3ACF3F09-8EF8-4A7A-ACCD-E1D3CB6F141C@oracle.com> <5112C6C0.5020803@oracle.com> <5113692A.8020300@oracle.com> Message-ID: <2DEB510B-1B78-4CA7-9818-5A747866E91E@oracle.com> Nice! On Feb 7, 2013, at 12:43 AM, Chien Yang wrote: > Just a quick update. Kevin, Richard and I have an offline discussion on grouping of new 3D classes. After talking through the pros and cons possible grouping approaches. We agreed to collapse the packages as follows: > > move all (9) classes from javafx.scene.shape3d ==> javafx.scene.shape > move all (2) classes from javafx.scene.material ==> javafx.scene.paint > move all (3) classes from javafx.scene.light ==> javafx.scene > > and also change LOD helper, Node.areaInScene, a read only property to a compute method. I will update the JIRA issue and generate a new API docs for approval tomorrow. > > - Chien > > On 2/6/2013 1:10 PM, Chien Yang wrote: >> I don't foresee the need to add dozens, but an additional of 10 classes might be a reasonable expectation. :-) >> >> - Chien >> >> On 2/6/2013 12:53 PM, Richard Bair wrote: >>> I would hope we're going to support user defined shaders. That doesn't mean some additional materials aren't a good idea. But we're not talking about dozens of additional classes, right? >>> >>> On Feb 6, 2013, at 12:48 PM, Chien Yang wrote: >>> >>>> Don't exactly know at this point, but we did talk about adding high-order surfaces and additional light types at one point. We will very likely need to support more material types if we want to hold the line of not supporting user defined shader. >>>> >>>> - Chien >>>> >>>> On 2/6/2013 11:22 AM, Richard Bair wrote: >>>>> How much? >>>>> >>>>> On Feb 6, 2013, at 11:21 AM, Chien Yang wrote: >>>>> >>>>>> Hi Richard, >>>>>> >>>>>> The number of classes in shape3d, light and material packages will certainly grow in future releases too as we add more features. >>>>>> >>>>>> - Chien >>>>>> >>>>>> On 2/6/2013 10:55 AM, Kevin Rushforth wrote: >>>>>>> They could all be put in the shape3d package, but it seems inconsistent with 2D packages: shape, paint effect, etc. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> Richard Bair wrote: >>>>>>>> Hi Chien, >>>>>>>> >>>>>>>>> javafx.scene.light.LightBase (abstract) >>>>>>>>> javafx.scene.material.Material (abstract) >>>>>>>> I'm not jazzed about creating two new packages here. It seems like these things should all be grouped in the same place as camera, or shape3d. Ideas? >>>>>>>> >>>>>>>>> Methods and Properties added to Node >>>>>>>>> --------------------------------------------------------- >>>>>>>>> >>>>>>>>> LOD helper property: >>>>>>>>> >>>>>>>>> /** >>>>>>>>> * A read only property that stores the computed area of this >>>>>>>>> * {@code Node} projected onto the physical screen in pixel unit. >>>>>>>>> */ >>>>>>>>> public final double getAreaInScreen() >>>>>>>>> public final javafx.beans.property.ReadOnlyDoubleProperty areaInScreenProperty() >>>>>>>> Can this be efficiently implemented? We ripped out boundsInScene because it was impossible to get it fast enough. Why would this be any different? >>>>>>>> >>>>>>>> The rest looks good. >>>>>>>> >>>>>>>> Richard > From hang.vo at oracle.com Thu Feb 7 13:33:06 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Feb 2013 21:33:06 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28274: Open Source Decora Projects Message-ID: <20130207213310.5C97C478EF@hg.openjdk.java.net> Changeset: 7507d0eacf70 Author: rbair Date: 2013-02-07 13:14 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7507d0eacf70 RT-28274: Open Source Decora Projects Summary: Moved Decora to open source + build-decora.xml ! build.gradle + decora-d3d/build.xml + decora-d3d/decora-d3d.iml + decora-d3d/nbproject/project.xml + decora-d3d/project.properties + decora-d3d/src/com/sun/scenario/effect/impl/hw/d3d/D3DShaderSource.java + decora-es2/build.xml + decora-es2/decora-es2.iml + decora-es2/nbproject/project.xml + decora-es2/project.properties + decora-es2/src/com/sun/scenario/effect/impl/es2/ES2ShaderSource.java + decora-jsw/build.xml + decora-jsw/decora-jsw.iml + decora-jsw/nbproject/project.xml + decora-jsw/project.properties + decora-jsw/src/com/sun/scenario/effect/impl/sw/java/JSWBoxBlurPeer.java + decora-jsw/src/com/sun/scenario/effect/impl/sw/java/JSWBoxShadowPeer.java + decora-jsw/src/com/sun/scenario/effect/impl/sw/java/JSWEffectPeer.java + decora-jsw/src/com/sun/scenario/effect/impl/sw/java/JSWLinearConvolvePeer.java + decora-jsw/src/com/sun/scenario/effect/impl/sw/java/JSWLinearConvolveShadowPeer.java + decora-jsw/src/com/sun/scenario/effect/impl/sw/java/JSWRendererDelegate.java + decora-prism-ps/build.xml + decora-prism-ps/decora-prism-ps.iml + decora-prism-ps/nbproject/project.xml + decora-prism-ps/project.properties + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPSDrawable.java + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPSEffectPeer.java + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPSOneSamplerPeer.java + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPSRenderer.java + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPSTwoSamplerPeer.java + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPSZeroSamplerPeer.java + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPStoPSWDisplacementMapPeer.java + decora-prism-sw/build.xml + decora-prism-sw/decora-prism-sw.iml + decora-prism-sw/nbproject/project.xml + decora-prism-sw/project.properties + decora-prism-sw/src/com/sun/scenario/effect/impl/prism/sw/PSWDrawable.java + decora-prism-sw/src/com/sun/scenario/effect/impl/prism/sw/PSWRenderer.java + decora-prism/build.xml + decora-prism/decora-prism.iml + decora-prism/nbproject/project.xml + decora-prism/project.properties + decora-prism/src/com/sun/scenario/effect/impl/prism/PrCropPeer.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrDrawable.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrEffectHelper.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrFilterContext.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrFloodPeer.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrImage.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrMergePeer.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrReflectionPeer.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrRenderInfo.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrRenderer.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrTexture.java + decora-runtime/build.xml + decora-runtime/decora-runtime.iml + decora-runtime/generator/CompileBlend.java + decora-runtime/generator/CompileBoxBlur.java + decora-runtime/generator/CompileExternal.java + decora-runtime/generator/CompileGaussian.java + decora-runtime/generator/CompileJSL.java + decora-runtime/generator/CompileLinearConvolve.java + decora-runtime/generator/CompilePhong.java + decora-runtime/generator/CompileZoomRadialBlur.java + decora-runtime/jsl/Blend.jsl + decora-runtime/jsl/Blend_ADD.jsl + decora-runtime/jsl/Blend_BLUE.jsl + decora-runtime/jsl/Blend_COLOR_BURN.jsl + decora-runtime/jsl/Blend_COLOR_DODGE.jsl + decora-runtime/jsl/Blend_DARKEN.jsl + decora-runtime/jsl/Blend_DIFFERENCE.jsl + decora-runtime/jsl/Blend_EXCLUSION.jsl + decora-runtime/jsl/Blend_GREEN.jsl + decora-runtime/jsl/Blend_HARD_LIGHT.jsl + decora-runtime/jsl/Blend_LIGHTEN.jsl + decora-runtime/jsl/Blend_MULTIPLY.jsl + decora-runtime/jsl/Blend_OVERLAY.jsl + decora-runtime/jsl/Blend_RED.jsl + decora-runtime/jsl/Blend_SCREEN.jsl + decora-runtime/jsl/Blend_SOFT_LIGHT.jsl + decora-runtime/jsl/Blend_SRC_ATOP.jsl + decora-runtime/jsl/Blend_SRC_IN.jsl + decora-runtime/jsl/Blend_SRC_OUT.jsl + decora-runtime/jsl/Blend_SRC_OVER.jsl + decora-runtime/jsl/BoxBlur.jsl + decora-runtime/jsl/Brightpass.jsl + decora-runtime/jsl/ColorAdjust.jsl + decora-runtime/jsl/DisplacementMap.jsl + decora-runtime/jsl/GaussianBlur.jsl + decora-runtime/jsl/InvertMask.jsl + decora-runtime/jsl/LinearConvolve.jsl + decora-runtime/jsl/LinearConvolveShadow.jsl + decora-runtime/jsl/PerspectiveTransform.jsl + decora-runtime/jsl/PhongLighting.jsl + decora-runtime/jsl/SepiaTone.jsl + decora-runtime/jsl/ZoomRadialBlur.jsl + decora-runtime/nbproject/project.xml + decora-runtime/project.properties + decora-runtime/src/com/sun/scenario/effect/AbstractShadow.java + decora-runtime/src/com/sun/scenario/effect/Blend.java + decora-runtime/src/com/sun/scenario/effect/Bloom.java + decora-runtime/src/com/sun/scenario/effect/BoxBlur.java + decora-runtime/src/com/sun/scenario/effect/BoxShadow.java + decora-runtime/src/com/sun/scenario/effect/Brightpass.java + decora-runtime/src/com/sun/scenario/effect/Color4f.java + decora-runtime/src/com/sun/scenario/effect/ColorAdjust.java + decora-runtime/src/com/sun/scenario/effect/CoreEffect.java + decora-runtime/src/com/sun/scenario/effect/Crop.java + decora-runtime/src/com/sun/scenario/effect/DelegateEffect.java + decora-runtime/src/com/sun/scenario/effect/DisplacementMap.java + decora-runtime/src/com/sun/scenario/effect/DropShadow.java + decora-runtime/src/com/sun/scenario/effect/Effect.java + decora-runtime/src/com/sun/scenario/effect/FilterContext.java + decora-runtime/src/com/sun/scenario/effect/FilterEffect.java + decora-runtime/src/com/sun/scenario/effect/Filterable.java + decora-runtime/src/com/sun/scenario/effect/FloatMap.java + decora-runtime/src/com/sun/scenario/effect/Flood.java + decora-runtime/src/com/sun/scenario/effect/GaussianBlur.java + decora-runtime/src/com/sun/scenario/effect/GaussianShadow.java + decora-runtime/src/com/sun/scenario/effect/GeneralShadow.java + decora-runtime/src/com/sun/scenario/effect/Glow.java + decora-runtime/src/com/sun/scenario/effect/Identity.java + decora-runtime/src/com/sun/scenario/effect/ImageData.java + decora-runtime/src/com/sun/scenario/effect/ImageDataRenderer.java + decora-runtime/src/com/sun/scenario/effect/InnerShadow.java + decora-runtime/src/com/sun/scenario/effect/InvertMask.java + decora-runtime/src/com/sun/scenario/effect/Merge.java + decora-runtime/src/com/sun/scenario/effect/MotionBlur.java + decora-runtime/src/com/sun/scenario/effect/Offset.java + decora-runtime/src/com/sun/scenario/effect/PerspectiveTransform.java + decora-runtime/src/com/sun/scenario/effect/PhongLighting.java + decora-runtime/src/com/sun/scenario/effect/Reflection.java + decora-runtime/src/com/sun/scenario/effect/SepiaTone.java + decora-runtime/src/com/sun/scenario/effect/ZoomRadialBlur.java + decora-runtime/src/com/sun/scenario/effect/impl/BufferUtil.java + decora-runtime/src/com/sun/scenario/effect/impl/EffectPeer.java + decora-runtime/src/com/sun/scenario/effect/impl/HeapImage.java + decora-runtime/src/com/sun/scenario/effect/impl/ImagePool.java + decora-runtime/src/com/sun/scenario/effect/impl/Renderer.java + decora-runtime/src/com/sun/scenario/effect/impl/RendererFactory.java + decora-runtime/src/com/sun/scenario/effect/impl/hw/Drawable.java + decora-runtime/src/com/sun/scenario/effect/impl/hw/RendererDelegate.java + decora-runtime/src/com/sun/scenario/effect/impl/hw/Shader.java + decora-runtime/src/com/sun/scenario/effect/impl/hw/ShaderSource.java + decora-runtime/src/com/sun/scenario/effect/impl/hw/Texture.java + decora-runtime/src/com/sun/scenario/effect/impl/state/AccessHelper.java + decora-runtime/src/com/sun/scenario/effect/impl/state/BoxBlurState.java + decora-runtime/src/com/sun/scenario/effect/impl/state/BoxShadowState.java + decora-runtime/src/com/sun/scenario/effect/impl/state/GaussianBlurState.java + decora-runtime/src/com/sun/scenario/effect/impl/state/GaussianShadowState.java + decora-runtime/src/com/sun/scenario/effect/impl/state/HVSeparableKernel.java + decora-runtime/src/com/sun/scenario/effect/impl/state/LinearConvolveKernel.java + decora-runtime/src/com/sun/scenario/effect/impl/state/LinearConvolvePeer.java + decora-runtime/src/com/sun/scenario/effect/impl/state/LinearConvolveShadowPeer.java + decora-runtime/src/com/sun/scenario/effect/impl/state/MotionBlurState.java + decora-runtime/src/com/sun/scenario/effect/impl/state/PerspectiveTransformState.java + decora-runtime/src/com/sun/scenario/effect/impl/state/ZoomRadialBlurState.java + decora-runtime/src/com/sun/scenario/effect/impl/sw/RendererDelegate.java + decora-runtime/src/com/sun/scenario/effect/light/DistantLight.java + decora-runtime/src/com/sun/scenario/effect/light/Light.java + decora-runtime/src/com/sun/scenario/effect/light/PointLight.java + decora-runtime/src/com/sun/scenario/effect/light/SpotLight.java + decora-runtime/test/com/sun/scenario/effect/Test1.java + decora-runtime/test/com/sun/scenario/effect/Test2.java + decora-runtime/test/com/sun/scenario/effect/rt_5239/RT_5239Test.java + decora-runtime/testjsl/Test1.jsl + decora-runtime/testjsl/Test2.jsl + decora-sse-native/Makefile + decora-sse-native/SSEBoxBlurPeer.cc + decora-sse-native/SSEBoxShadowPeer.cc + decora-sse-native/SSELinearConvolvePeer.cc + decora-sse-native/SSELinearConvolveShadowPeer.cc + decora-sse-native/SSEUtils.cc + decora-sse-native/SSEUtils.h + decora-sse-native/nbproject/Makefile-Debug.mk + decora-sse-native/nbproject/Makefile-Release.mk + decora-sse-native/nbproject/Makefile-impl.mk + decora-sse-native/nbproject/configurations.xml + decora-sse-native/nbproject/project.xml + decora-sse/build-macosx.xml + decora-sse/build-windows.xml + decora-sse/build.xml + decora-sse/decora-sse.iml + decora-sse/nbproject/project.xml + decora-sse/project.properties + decora-sse/src/com/sun/scenario/effect/impl/sw/sse/SSEBoxBlurPeer.java + decora-sse/src/com/sun/scenario/effect/impl/sw/sse/SSEBoxShadowPeer.java + decora-sse/src/com/sun/scenario/effect/impl/sw/sse/SSEEffectPeer.java + decora-sse/src/com/sun/scenario/effect/impl/sw/sse/SSELinearConvolvePeer.java + decora-sse/src/com/sun/scenario/effect/impl/sw/sse/SSELinearConvolveShadowPeer.java + decora-sse/src/com/sun/scenario/effect/impl/sw/sse/SSERendererDelegate.java ! generator.gradle ! javafx-ui-controls/src/javafx/scene/control/Pagination.java From neugens at redhat.com Thu Feb 7 13:39:19 2013 From: neugens at redhat.com (Mario Torre) Date: Thu, 07 Feb 2013 22:39:19 +0100 Subject: hg: openjfx/8/graphics/rt: RT-28274: Open Source Decora Projects In-Reply-To: <20130207213310.5C97C478EF@hg.openjdk.java.net> References: <20130207213310.5C97C478EF@hg.openjdk.java.net> Message-ID: <1360273159.1911.36.camel@pegasus> Il giorno gio, 07/02/2013 alle 21.33 +0000, hang.vo at oracle.com ha scritto: > Changeset: 7507d0eacf70 > Author: rbair > Date: 2013-02-07 13:14 -0800 > URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7507d0eacf70 > > RT-28274: Open Source Decora Projects > Summary: Moved Decora to open source Cheers! Mario From richard.bair at oracle.com Thu Feb 7 13:55:19 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 7 Feb 2013 13:55:19 -0800 Subject: hg: openjfx/8/graphics/rt: RT-28274: Open Source Decora Projects In-Reply-To: <1360273159.1911.36.camel@pegasus> References: <20130207213310.5C97C478EF@hg.openjdk.java.net> <1360273159.1911.36.camel@pegasus> Message-ID: Thanks! Now I'm working from the pure-open side to make sure everything will build etc. All the build changes are the hardest part of this process :) Richard On Feb 7, 2013, at 1:39 PM, Mario Torre wrote: > Il giorno gio, 07/02/2013 alle 21.33 +0000, hang.vo at oracle.com ha > scritto: >> Changeset: 7507d0eacf70 >> Author: rbair >> Date: 2013-02-07 13:14 -0800 >> URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7507d0eacf70 >> >> RT-28274: Open Source Decora Projects >> Summary: Moved Decora to open source > > Cheers! > > Mario > From richard.bair at oracle.com Thu Feb 7 14:31:39 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 7 Feb 2013 14:31:39 -0800 Subject: How to build openjfx in its current state In-Reply-To: <1360264008.1911.28.camel@pegasus> References: <1360249250.1911.8.camel@pegasus> <3EB531F7-F96C-4E28-8BC8-D05DBDAB102E@oracle.com> <1360264008.1911.28.camel@pegasus> Message-ID: <6B193580-3104-4EC4-B053-0C5088D3E89B@oracle.com> > Great, I'll give a look at it as soon as decora is out. I guess I need > to wait that everything gets synced in the master repo, right? Ya. >> When setting up Intellij, the SDK MUST NOT HAVE JFXRT.JAR on the >> CLASSPATH!! > > You know if it works with NetBeans too? I would love to keep using > NetBeans :) Of course! We're agnostic here, let everybody use their preferred IDE and be productive :-). > Or will you keep the ant and ide specific files around? Geertjan reached out to me recently to try out the NB gradle plugin. In theory if we setup the gradle builds correctly you should be able to just open in NB and everything will "just work". In practice there will be bugs to fix etc I'm sure. Really if we can avoid having the IDE specific files in then that's cool with me. Richard From richard.bair at oracle.com Thu Feb 7 14:33:42 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 7 Feb 2013 14:33:42 -0800 Subject: How to build openjfx in its current state In-Reply-To: <1360264965.1911.35.camel@pegasus> References: <1360249250.1911.8.camel@pegasus> <1360264965.1911.35.camel@pegasus> Message-ID: <52B0B373-396E-485B-927C-FD87E93A2A73@oracle.com> >> The build instructions for building OpenJFX seems a bit outdated (or I'm >> reading them wrong), and no matter how I try I always get compilation >> failures (I'm trying OpenJFX 8 :). > > Just a quick follow up: > > [neugens at pegasus rt]$ ls dist > openjfxrt.jar > > This is built with OpenJDK, no closed JDK :) > > I had to copy the jfxrt.jar into the lib/ext directory though. Is the > artifacts/sdk/rt/lib/jfxrt.jar actually really used to build OpenJFX? > > It would be nice if we could just rely on that rather than use the JDK > embedded copy of the jar. > > What is the content of the openjfx,jar? Does it contain also the closed > classes or is purely the open ones? I'm not entirely sure, going through this process myself. I would expect that openjfx.jar contains only the open bits, so that you would be free to redistribute it as you see fit subject to the GPLv2 w/classpath exception. If it combined our binary plug stuff then you'd not be able to redistribute it. So that would suggest you must prepend openjfxrt.jar onto the boot class path BEFORE jfxrt.jar or your modifications won't get picked up. Richard From richard.bair at oracle.com Thu Feb 7 14:35:05 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 7 Feb 2013 14:35:05 -0800 Subject: How to build openjfx in its current state In-Reply-To: <1360257052.1911.11.camel@pegasus> References: <1360249250.1911.8.camel@pegasus> <5113DB3B.3070005@oracle.com> <1360257052.1911.11.camel@pegasus> Message-ID: <419FA6B3-FE6C-40DD-A989-412C4903EEDC@oracle.com> >> This is the wiki that is kept up to date: >> https://wikis.oracle.com/display/OpenJDK/OpenJFX >> >> It is sad to say, but the OpenJDK project page is outdated >> (http://openjdk.java.net/projects/openjfx/getting-started.html). It >> turns out that trying to keep this page up to date is a pain in the >> ass. Yay, OpenJDK! > > Yeah, I know this from experience... > > Perhaps the page could just link to the wiki? > > There is no need really to have the OpenJDK page, it can just link to > the appropriate page, and it would be way less confusing. > > I can provide with the html changes if you point me to the web page > sources, so you just need to push the change. Hmm, the link to the repo I have points at a "closedjdk" URL. Are the other OpenJDK web pages publicly available? From danno.ferrin at shemnon.com Thu Feb 7 14:37:42 2013 From: danno.ferrin at shemnon.com (Danno Ferrin) Date: Thu, 7 Feb 2013 15:37:42 -0700 Subject: How to build openjfx in its current state In-Reply-To: <6B193580-3104-4EC4-B053-0C5088D3E89B@oracle.com> References: <1360249250.1911.8.camel@pegasus> <3EB531F7-F96C-4E28-8BC8-D05DBDAB102E@oracle.com> <1360264008.1911.28.camel@pegasus> <6B193580-3104-4EC4-B053-0C5088D3E89B@oracle.com> Message-ID: On Thu, Feb 7, 2013 at 3:31 PM, Richard Bair wrote: > > Great, I'll give a look at it as soon as decora is out. I guess I need > > to wait that everything gets synced in the master repo, right? > > Ya. > > >> When setting up Intellij, the SDK MUST NOT HAVE JFXRT.JAR on the > >> CLASSPATH!! > > > > You know if it works with NetBeans too? I would love to keep using > > NetBeans :) > > Of course! We're agnostic here, let everybody use their preferred IDE and > be productive :-). > > > Or will you keep the ant and ide specific files around? > > Geertjan reached out to me recently to try out the NB gradle plugin. In > theory if we setup the gradle builds correctly you should be able to just > open in NB and everything will "just work". In practice there will be bugs > to fix etc I'm sure. Really if we can avoid having the IDE specific files > in then that's cool with me. > > Even though I am an IntelliJ user I have to admit the Gradle Plugin for NetBeans has be best IDE integration of any of the Gradle IDE plugins out there. You don't even know you are using Gradle if you don't hack at the build file. From hang.vo at oracle.com Thu Feb 7 14:48:14 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Feb 2013 22:48:14 +0000 Subject: hg: openjfx/8/controls/rt: Modena: Added extra border to scroll bar, adjusted height of some controls to match new Button height. Message-ID: <20130207224816.52C7B478F0@hg.openjdk.java.net> Changeset: 4bd39477ff95 Author: "Jasper Potts" Date: 2013-02-07 14:33 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4bd39477ff95 Modena: Added extra border to scroll bar, adjusted height of some controls to match new Button height. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From richard.bair at oracle.com Thu Feb 7 14:58:26 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 7 Feb 2013 14:58:26 -0800 Subject: How to build openjfx in its current state In-Reply-To: <1360257052.1911.11.camel@pegasus> References: <1360249250.1911.8.camel@pegasus> <5113DB3B.3070005@oracle.com> <1360257052.1911.11.camel@pegasus> Message-ID: <84F20A3B-A014-47FB-9870-6A9566632A37@oracle.com> Hey Mario, I just updated the project page. Not sure how long it takes to be reflected in the public pages. Now it just points to stable URLs and we let everything else (build instructions, etc) reside in the wiki. Richard On Feb 7, 2013, at 9:10 AM, Mario Torre wrote: > Il giorno gio, 07/02/2013 alle 11.50 -0500, steve.x.northover at oracle.com > ha scritto: >> This is the wiki that is kept up to date: >> https://wikis.oracle.com/display/OpenJDK/OpenJFX >> >> It is sad to say, but the OpenJDK project page is outdated >> (http://openjdk.java.net/projects/openjfx/getting-started.html). It >> turns out that trying to keep this page up to date is a pain in the >> ass. Yay, OpenJDK! > > Yeah, I know this from experience... > > Perhaps the page could just link to the wiki? > > There is no need really to have the OpenJDK page, it can just link to > the appropriate page, and it would be way less confusing. > > I can provide with the html changes if you point me to the web page > sources, so you just need to push the change. > > Cheers, > Mario > > From hang.vo at oracle.com Thu Feb 7 15:03:57 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 07 Feb 2013 23:03:57 +0000 Subject: hg: openjfx/8/graphics/rt: Updated project properties to point to local directories instead of in rt-closed. Oops. Message-ID: <20130207230400.0FDE2478F9@hg.openjdk.java.net> Changeset: 14da6e9bbcfe Author: rbair Date: 2013-02-07 14:57 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/14da6e9bbcfe Updated project properties to point to local directories instead of in rt-closed. Oops. ! decora-d3d/project.properties ! decora-es2/project.properties ! decora-jsw/project.properties ! decora-prism-ps/project.properties ! decora-prism-sw/project.properties ! decora-prism/project.properties ! decora-sse/project.properties From neugens.limasoftware at gmail.com Thu Feb 7 15:05:48 2013 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 8 Feb 2013 00:05:48 +0100 Subject: How to build openjfx in its current state In-Reply-To: <84F20A3B-A014-47FB-9870-6A9566632A37@oracle.com> References: <1360249250.1911.8.camel@pegasus> <5113DB3B.3070005@oracle.com> <1360257052.1911.11.camel@pegasus> <84F20A3B-A014-47FB-9870-6A9566632A37@oracle.com> Message-ID: Il giorno 07/feb/2013 23:59, "Richard Bair" ha scritto: > > Hey Mario, I just updated the project page. Not sure how long it takes to be reflected in the public pages. Now it just points to stable URLs and we let everything else (build instructions, etc) reside in the wiki. > > Richard Great, thanks a lot! Cheers, Mario From richard.bair at oracle.com Thu Feb 7 15:12:33 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 7 Feb 2013 15:12:33 -0800 Subject: How to build openjfx in its current state In-Reply-To: <1360249250.1911.8.camel@pegasus> References: <1360249250.1911.8.camel@pegasus> Message-ID: <986847F1-22C3-4FCD-8C3D-89F0E9FA0FEB@oracle.com> Hi Mario, It looks like the open build has deteriorated, probably while we've been open sourcing things we haven't been diligent about keeping the open build up to date (I know I haven't). Now that I'm looking at it, there are numerous issues: - Some of the projects are not declaring dependencies in project.properties correctly - The build order in build.xml "dist" target is wrong - Projects are missing from build.xml "dist" target The reason it has built before has been luck -- the projects are out of order, but they're building anyway because the jfxrt.jar is acting as a backstop. But if you were to modify sources in one project and wanted to depend on it from another project, you'd run into these problems. Now that a *lot* of stuff is in the open, I'm trying to build without linking to jfxrt.jar. I should get pretty far on that. Once the build is succeeding up to the point it should, then I'll test against a stripped down jfxrt.jar (that only contains the closed bits) so that I can make sure the open build is working correctly. Richard On Feb 7, 2013, at 7:00 AM, Mario Torre wrote: > Hi all! > > The build instructions for building OpenJFX seems a bit outdated (or I'm > reading them wrong), and no matter how I try I always get compilation > failures (I'm trying OpenJFX 8 :). > > Dalibor presentation at FOSDEM was about this how to build OpenJFX from > sources, but I didn't take notes :) > > Is it possible to have a quick refresher? > > And speaking about that, I remember that Richard was doing some > experiments with Gradle, did you made some progress in that regard or is > there anything we can do to help on that? > > Cheers, > Mario > > From joseph.andresen at oracle.com Thu Feb 7 15:11:02 2013 From: joseph.andresen at oracle.com (joe andresen) Date: Thu, 07 Feb 2013 15:11:02 -0800 Subject: [API Review] FX 8 3D API In-Reply-To: <5113E230.4080302@oracle.com> References: <510C1B8D.4060302@oracle.com> <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> <5112A71A.50502@oracle.com> <5112AD50.1040807@oracle.com> <268F341F-8FCE-4FB5-AB18-A54E873B3931@oracle.com> <5112C19A.7050009@oracle.com> <3ACF3F09-8EF8-4A7A-ACCD-E1D3CB6F141C@oracle.com> <5112C6C0.5020803@oracle.com> <5113692A.8020300@oracle.com> <90D2394C-E9B2-4B9C-898F-DA74A15AAE86@oracle.com> <5113E230.4080302@oracle.com> Message-ID: <51143486.7040400@oracle.com> Just a thought, I would think that Color, ImagePattern, and the Gradients could be instances of Materials. A Material is a texture that is applied to a surface. In todays graphics pipeline, the texture on the surface is calculated with shaders, float3 color variables, and any other types of variables the shaders might use. If you were to to extend this methodology to prism, setting the fill of a Shape with a material would give a more detailed interface for what will be processed on those pixels. For Example, if Color was a Material it would look something like: //pseudo code Material color_Material; //any other initialize code color.setPixelShader(color_Shader); color.setFloat3(red_Color); Rectangle rect = new Rectangle(); rect.setFill(color_Material); Now this totally breaks down with prism's shape rendering implementation, but from an API standpoint, this makes sense to me. (the problem being that in prism, what 2d shape you are rendering is determined by a pixel shader.) Here are a couple of other somewhat random libraries' abstraction of a Material. http://clb.demon.fi/gfxapi/docs/Material_summary.php http://docs.unity3d.com/Documentation/ScriptReference/Material.html Interesting how Unity has specific variables that are meant for a Main Color. I think this has to do with their public and not standard shader architecture. (Surface Shaders) Flash 3d has no such thing, where instead you have to set shader variables from a context, which in my opinion is nasty. http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display3D/Context3D.html -Joe The current way does not limit us from doing this in the future so that is why it is just a thought :) . From kevin.rushforth at oracle.com Thu Feb 7 15:54:00 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 07 Feb 2013 15:54:00 -0800 Subject: [API Review] FX 8 3D API In-Reply-To: <51143486.7040400@oracle.com> References: <510C1B8D.4060302@oracle.com> <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> <5112A71A.50502@oracle.com> <5112AD50.1040807@oracle.com> <268F341F-8FCE-4FB5-AB18-A54E873B3931@oracle.com> <5112C19A.7050009@oracle.com> <3ACF3F09-8EF8-4A7A-ACCD-E1D3CB6F141C@oracle.com> <5112C6C0.5020803@oracle.com> <5113692A.8020300@oracle.com> <90D2394C-E9B2-4B9C-898F-DA74A15AAE86@oracle.com> <5113E230.4080302@oracle.com> <51143486.7040400@oracle.com> Message-ID: <51143E98.3040006@oracle.com> Even if we wanted to do this, it could not be accomplished by making Paint a subclass of Material without an incompatible API change. All that you would gain by making Paint a subclass of Material is the ability to render a 3D shape with a gradient or a solid color, which seems not all that useful. What you are talking about below would only be possible if you made Material a subclass of Paint, but there isn't enough value in doing that to justify changing all of the 2D shaders to allow this (not to mention just defining what the semantics of this would be). > The current way does not limit us from doing this in the future so > that is why it is just a thought :) . Right. For FX 8 they will be separate classes with no common superclass. We could extend this later if desired (not convinced, though). -- Kevin joe andresen wrote: > > Just a thought, > > I would think that Color, ImagePattern, and the Gradients could be > instances of Materials. > > A Material is a texture that is applied to a surface. In todays > graphics pipeline, the texture on the surface is calculated with > shaders, float3 color variables, and any other types of variables the > shaders might use. > > If you were to to extend this methodology to prism, setting the fill > of a Shape with a material would give a more detailed interface for > what will be processed on those pixels. > > For Example, if Color was a Material it would look something like: > > //pseudo code > > Material color_Material; > //any other initialize code > color.setPixelShader(color_Shader); > color.setFloat3(red_Color); > > Rectangle rect = new Rectangle(); > rect.setFill(color_Material); > > Now this totally breaks down with prism's shape rendering > implementation, but from an API standpoint, this makes sense to me. > (the problem being that in prism, what 2d shape you are rendering is > determined by a pixel shader.) > > Here are a couple of other somewhat random libraries' abstraction of a > Material. > > http://clb.demon.fi/gfxapi/docs/Material_summary.php > > http://docs.unity3d.com/Documentation/ScriptReference/Material.html > > Interesting how Unity has specific variables that are meant for a Main > Color. I think this has to do with their public and not standard > shader architecture. (Surface Shaders) > > Flash 3d has no such thing, where instead you have to set shader > variables from a context, which in my opinion is nasty. > > http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display3D/Context3D.html > > > -Joe > > The current way does not limit us from doing this in the future so > that is why it is just a thought :) . > From hang.vo at oracle.com Thu Feb 7 16:03:04 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Feb 2013 00:03:04 +0000 Subject: hg: openjfx/8/graphics/rt: Additional path errors. What I did wrong was not update the build-closed.xml files of projects referring to decora. I also need to adjust the decora projects so they have a build-closed.xml file. I will update the project to make sure it builds for open source devs separately. Message-ID: <20130208000306.8494E478FC@hg.openjdk.java.net> Changeset: f5dae05e32d8 Author: rbair Date: 2013-02-07 15:52 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f5dae05e32d8 Additional path errors. What I did wrong was not update the build-closed.xml files of projects referring to decora. I also need to adjust the decora projects so they have a build-closed.xml file. I will update the project to make sure it builds for open source devs separately. ! javafx-sg-common/build-closed.xml ! javafx-sg-prism/build-closed.xml ! javafx-ui-charts/project.properties ! javafx-ui-common/build-closed.xml ! test-stub-toolkit/build-closed.xml ! test-stub-toolkit/project.properties From hang.vo at oracle.com Thu Feb 7 16:18:01 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Feb 2013 00:18:01 +0000 Subject: hg: openjfx/8/graphics/rt: [ECLIPSE ONLY] fixing classpath for decora Message-ID: <20130208001803.9987C478FD@hg.openjdk.java.net> Changeset: 610dbac8d6fc Author: Felipe Heidrich Date: 2013-02-07 16:13 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/610dbac8d6fc [ECLIPSE ONLY] fixing classpath for decora ! .classpath From hang.vo at oracle.com Thu Feb 7 16:47:52 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Feb 2013 00:47:52 +0000 Subject: hg: openjfx/8/controls/rt: RT-23847 axis tickLabelRotation does not work Message-ID: <20130208004756.8BF0E478FE@hg.openjdk.java.net> Changeset: 723b68315cb2 Author: Paru Somashekar Date: 2013-02-07 16:53 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/723b68315cb2 RT-23847 axis tickLabelRotation does not work RT-24256 Adding RadioMenuItem to ToggleGroup causes IAE ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java ! javafx-ui-controls/src/javafx/scene/control/RadioMenuItem.java From hang.vo at oracle.com Thu Feb 7 16:47:57 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Feb 2013 00:47:57 +0000 Subject: hg: openjfx/8/graphics/rt: 4 new changesets Message-ID: <20130208004805.7CB71478FF@hg.openjdk.java.net> Changeset: d39f91a06d08 Author: hudson Date: 2013-02-07 14:40 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d39f91a06d08 Added tag 8.0-b76 for changeset 27a5dff62edc ! .hgtags Changeset: a2a4de77db5f Author: David Grieve Date: 2013-02-07 15:34 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a2a4de77db5f [TEST ONLY] RT-28273: disable Node_effectiveOrientation_Css_Test ! javafx-ui-common/test/unit/javafx/scene/Node_effectiveOrientation_Css_Test.java Changeset: 591738b789c3 Author: David Grieve Date: 2013-02-07 19:00 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/591738b789c3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 4446f7960af3 Author: kcr Date: 2013-02-07 16:35 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4446f7960af3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGMediaView.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/PrismMediaFrameHandler.java - javafx-ui-common/test/unit/javafx/animation/AnimationMock.java From joseph.andresen at oracle.com Thu Feb 7 17:21:13 2013 From: joseph.andresen at oracle.com (Joe Andresen) Date: Thu, 7 Feb 2013 17:21:13 -0800 (PST) Subject: [API Review] FX 8 3D API Message-ID: <83d21cb8-fd54-4ba0-91d5-c04e8da62be2@default> see response inline. ----- Original Message ----- From: kevin.rushforth at oracle.com To: joseph.andresen at oracle.com Cc: openjfx-dev at openjdk.java.net Sent: Thursday, February 7, 2013 3:53:59 PM GMT -08:00 US/Canada Pacific Subject: Re: [API Review] FX 8 3D API Even if we wanted to do this, it could not be accomplished by making Paint a subclass of Material without an incompatible API change. I didn't say to make paint a subclass of material.... All that you would gain by making Paint a subclass of Material is the ability to render a 3D shape with a gradient or a solid color, which seems not all that useful. That is what a texture map is for, i think it could be useful. What you are talking about below would only be possible if you made Material a subclass of Paint, but there isn't enough value in doing that to justify changing all of the 2D shaders to allow this (not to mention just defining what the semantics of this would be). actually... this isnt so incompatible with prism now... we would simply replace our paint pixel shaders with material ones. multiplying the color generated by the material shader with the mask would give desired results... i think.... > The current way does not limit us from doing this in the future so > that is why it is just a thought :) . Right. For FX 8 they will be separate classes with no common superclass. We could extend this later if desired (not convinced, though). indeed. -- Kevin joe andresen wrote: > > Just a thought, > > I would think that Color, ImagePattern, and the Gradients could be > instances of Materials. > > A Material is a texture that is applied to a surface. In todays > graphics pipeline, the texture on the surface is calculated with > shaders, float3 color variables, and any other types of variables the > shaders might use. > > If you were to to extend this methodology to prism, setting the fill > of a Shape with a material would give a more detailed interface for > what will be processed on those pixels. > > For Example, if Color was a Material it would look something like: > > //pseudo code > > Material color_Material; > //any other initialize code > color.setPixelShader(color_Shader); > color.setFloat3(red_Color); > > Rectangle rect = new Rectangle(); > rect.setFill(color_Material); > > Now this totally breaks down with prism's shape rendering > implementation, but from an API standpoint, this makes sense to me. > (the problem being that in prism, what 2d shape you are rendering is > determined by a pixel shader.) > > Here are a couple of other somewhat random libraries' abstraction of a > Material. > > http://clb.demon.fi/gfxapi/docs/Material_summary.php > > http://docs.unity3d.com/Documentation/ScriptReference/Material.html > > Interesting how Unity has specific variables that are meant for a Main > Color. I think this has to do with their public and not standard > shader architecture. (Surface Shaders) > > Flash 3d has no such thing, where instead you have to set shader > variables from a context, which in my opinion is nasty. > > http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display3D/Context3D.html > > > -Joe > > The current way does not limit us from doing this in the future so > that is why it is just a thought :) . > From hang.vo at oracle.com Thu Feb 7 17:32:47 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Feb 2013 01:32:47 +0000 Subject: hg: openjfx/8/graphics/rt: RT-17401: 3D geometry support -- initial commit, only d3d is implemented Message-ID: <20130208013251.8671C47902@hg.openjdk.java.net> Changeset: 0f328860af65 Author: kcr Date: 2013-02-07 17:13 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0f328860af65 RT-17401: 3D geometry support -- initial commit, only d3d is implemented Contributed-by: jada - javafx-geom/src/com/sun/javafx/geom/CameraImpl.java - javafx-geom/src/com/sun/javafx/geom/ParallelCameraImpl.java - javafx-geom/src/com/sun/javafx/geom/PerspectiveCameraImpl.java ! javafx-geom/src/com/sun/javafx/geom/PickRay.java ! javafx-geom/src/com/sun/javafx/geom/transform/GeneralTransform3D.java + javafx-sg-common/src/com/sun/javafx/sg/PGAmbientLight.java + javafx-sg-common/src/com/sun/javafx/sg/PGBox.java + javafx-sg-common/src/com/sun/javafx/sg/PGCamera.java + javafx-sg-common/src/com/sun/javafx/sg/PGCylinder.java + javafx-sg-common/src/com/sun/javafx/sg/PGLightBase.java + javafx-sg-common/src/com/sun/javafx/sg/PGMeshView.java + javafx-sg-common/src/com/sun/javafx/sg/PGParallelCamera.java + javafx-sg-common/src/com/sun/javafx/sg/PGPerspectiveCamera.java + javafx-sg-common/src/com/sun/javafx/sg/PGPhongMaterial.java + javafx-sg-common/src/com/sun/javafx/sg/PGPointLight.java + javafx-sg-common/src/com/sun/javafx/sg/PGShape3D.java + javafx-sg-common/src/com/sun/javafx/sg/PGSphere.java + javafx-sg-common/src/com/sun/javafx/sg/PGTriangleMesh.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGAmbientLight.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGBox.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGCamera.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGCylinder.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGGroup.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGLightBase.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGMeshView.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGNode.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGParallelCamera.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGPerspectiveCamera.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGPhongMaterial.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGPointLight.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGRegion.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGShape3D.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGSphere.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGTriangleMesh.java ! javafx-sg-prism/test/com/sun/javafx/sg/prism/TestGraphics.java ! javafx-ui-common/src/com/sun/javafx/scene/DirtyBits.java ! javafx-ui-common/src/com/sun/javafx/scene/EnteredExitedHandler.java ! javafx-ui-common/src/com/sun/javafx/scene/input/InputEventUtils.java + javafx-ui-common/src/com/sun/javafx/scene/input/PickResultChooser.java ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/TKScene.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java + javafx-ui-common/src/javafx/scene/AmbientLight.java ! javafx-ui-common/src/javafx/scene/Camera.java + javafx-ui-common/src/javafx/scene/LightBase.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/ParallelCamera.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/PerspectiveCamera.java + javafx-ui-common/src/javafx/scene/PointLight.java ! javafx-ui-common/src/javafx/scene/Scene.java + javafx-ui-common/src/javafx/scene/SubScene.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java ! javafx-ui-common/src/javafx/scene/input/DragEvent.java ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/KeyEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseDragEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java + javafx-ui-common/src/javafx/scene/input/PickResult.java ! javafx-ui-common/src/javafx/scene/input/RotateEvent.java ! javafx-ui-common/src/javafx/scene/input/ScrollEvent.java ! javafx-ui-common/src/javafx/scene/input/SwipeEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchPoint.java ! javafx-ui-common/src/javafx/scene/input/ZoomEvent.java ! javafx-ui-common/src/javafx/scene/layout/Region.java + javafx-ui-common/src/javafx/scene/paint/Material.java + javafx-ui-common/src/javafx/scene/paint/PhongMaterial.java + javafx-ui-common/src/javafx/scene/shape/Box.java + javafx-ui-common/src/javafx/scene/shape/CullFace.java + javafx-ui-common/src/javafx/scene/shape/Cylinder.java + javafx-ui-common/src/javafx/scene/shape/DrawMode.java + javafx-ui-common/src/javafx/scene/shape/Mesh.java + javafx-ui-common/src/javafx/scene/shape/MeshView.java + javafx-ui-common/src/javafx/scene/shape/PredefinedMeshManager.java + javafx-ui-common/src/javafx/scene/shape/Shape3D.java + javafx-ui-common/src/javafx/scene/shape/Sphere.java + javafx-ui-common/src/javafx/scene/shape/TriangleMesh.java ! javafx-ui-common/test/unit/javafx/scene/MouseTest.java + javafx-ui-common/test/unit/javafx/scene/MouseTest3D.java ! javafx-ui-common/test/unit/javafx/scene/NodeTest.java ! javafx-ui-common/test/unit/javafx/scene/Scenegraph_eventHandlers_Test.java ! javafx-ui-common/test/unit/javafx/scene/input/ContextMenuEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/DragAndDropTest.java ! javafx-ui-common/test/unit/javafx/scene/input/MouseDragEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/RotateEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/ScrollEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/SwipeEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/TestNode.java ! javafx-ui-common/test/unit/javafx/scene/input/TouchEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/ZoomEventTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ScrollPaneSkinTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/VirtualFlowTest.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubBox.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubCylinder.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubMeshView.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubScene.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubShape3D.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubSphere.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubTriangleMesh.java From hang.vo at oracle.com Thu Feb 7 18:28:10 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Feb 2013 02:28:10 +0000 Subject: hg: openjfx/8/master/rt: 87 new changesets Message-ID: <20130208023026.C6BC14790A@hg.openjdk.java.net> Changeset: 3e556868fc53 Author: kcr Date: 2012-11-05 08:27 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3e556868fc53 RT-25322: Improve utility methods (bugdb 14672404) Reviewed-by: Steve Northover, Phil Race, Artem Ananiev, Marc Schoenefeld ! javafx-ui-common/src/com/sun/javafx/Utils.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 11a05268d086 Author: kcr Date: 2012-11-10 06:47 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/11a05268d086 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-controls/src/javafx/scene/control/Control.java Changeset: 2da5fd244217 Author: kcr Date: 2012-11-20 07:24 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2da5fd244217 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/com/sun/javafx/Utils.java Changeset: 001ec302d141 Author: kcr Date: 2012-11-30 14:04 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/001ec302d141 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 8c4be8679422 Author: kcr Date: 2012-12-07 09:29 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8c4be8679422 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: fc3d9c1c40be Author: kcr Date: 2012-12-13 18:49 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fc3d9c1c40be Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/com/sun/javafx/Utils.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: bf7b298cab88 Author: kcr Date: 2012-11-16 12:35 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bf7b298cab88 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/com/sun/javafx/Utils.java Changeset: 99bb0131ebc9 Author: Milan Kubec Date: 2012-11-26 16:22 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/99bb0131ebc9 fix of classpath related to move of the project from rt-closed repo to rt repo ! javafx-fxml/nbproject/project.xml Changeset: 5fbc473c6c5d Author: Artem Ananiev Date: 2012-11-29 19:57 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5fbc473c6c5d RT-26578: Improve Glass thread handling Reviewed-by: Andrew Gross, Kevin Rushforth, Marc Schoenefeld ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/com/sun/javafx/tk/TKScene.java ! javafx-ui-common/src/com/sun/javafx/tk/TKStage.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-common/src/javafx/stage/Window.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubScene.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubStage.java Changeset: 61c721a2f027 Author: kcr Date: 2012-11-30 15:40 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/61c721a2f027 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8-cpu-225/dev/jfx/rt ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 6046b51aa28f Author: kcr Date: 2012-12-07 10:16 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6046b51aa28f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8-cpu-225/dev/jfx/rt Changeset: d3c9ba231203 Author: kcr Date: 2012-12-13 19:04 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d3c9ba231203 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8-cpu-225/dev/jfx/rt ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: e2e77aed2a96 Author: kcr Date: 2012-12-20 18:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e2e77aed2a96 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 79e549a30585 Author: kcr Date: 2013-01-03 16:11 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/79e549a30585 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: ee1f55c99b71 Author: kcr Date: 2013-01-12 11:17 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ee1f55c99b71 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 9d69c7de9bfe Author: Milan Kubec Date: 2013-01-21 10:47 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9d69c7de9bfe RT-26596: fwd-port to FX8 of Reuse standard utility classes for method calls ! javafx-fxml/project.properties ! javafx-fxml/src/com/sun/javafx/fxml/BeanAdapter.java ! javafx-fxml/src/javafx/fxml/FXMLLoader.java ! javafx-fxml/src/javafx/fxml/JavaFXBuilderFactory.java Changeset: 00328d63df9e Author: kcr Date: 2013-01-21 07:33 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/00328d63df9e Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-fxml/src/javafx/fxml/FXMLLoader.java ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 1585db3ed50d Author: kcr Date: 2013-01-26 08:41 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1585db3ed50d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-fxml/src/com/sun/javafx/fxml/BeanAdapter.java ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java Changeset: 56dee48d8e94 Author: kcr Date: 2013-02-01 07:08 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/56dee48d8e94 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt ! javafx-fxml/project.properties ! javafx-fxml/src/javafx/fxml/FXMLLoader.java ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/com/sun/javafx/tk/TKStage.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/stage/Stage.java ! javafx-ui-common/src/javafx/stage/Window.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubStage.java Changeset: 3565e21dd806 Author: Felipe Heidrich Date: 2013-01-29 14:41 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3565e21dd806 RT-26719: TextFlow doesn't provide a sensible minHeight(double) value ! javafx-ui-common/src/javafx/scene/text/TextFlow.java Changeset: 8e2421b550ae Author: Pavel Safrata Date: 2013-01-30 09:10 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8e2421b550ae RT-27087: added multiply(double) to points. ! javafx-ui-common/src/javafx/geometry/Point2D.java ! javafx-ui-common/src/javafx/geometry/Point3D.java ! javafx-ui-common/test/unit/javafx/geometry/Point2DTest.java ! javafx-ui-common/test/unit/javafx/geometry/Point3DTest.java Changeset: 1fa552fa870f Author: Richard Bair Date: 2013-01-30 09:32 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1fa552fa870f RT-18702: Add a ScheduledService which allows to auto-restart a service Summary: Added the ScheduledService -- we had previously discussed the API on openjfx-dev. Also added a pile of unit tests (nothing here for SQE to do as the concurrent classes are all tested via unit tests). + javafx-concurrent/src/javafx/concurrent/ScheduledService.java ! javafx-concurrent/src/javafx/concurrent/Service.java - javafx-concurrent/test/javafx/concurrent/AbstractService.java + javafx-concurrent/test/javafx/concurrent/ScheduledServiceTest.java ! javafx-concurrent/test/javafx/concurrent/ServiceExceptionTest.java ! javafx-concurrent/test/javafx/concurrent/ServiceLifecycleTest.java ! javafx-concurrent/test/javafx/concurrent/ServiceTest.java ! javafx-concurrent/test/javafx/concurrent/ServiceTestBase.java + javafx-concurrent/test/javafx/concurrent/TestServiceFactory.java Changeset: ec7e18a92765 Author: Richard Bair Date: 2013-01-30 09:34 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ec7e18a92765 RT-18820: Task needs to support incremental updates to the value Summary: Simply added a method updateValue and added documentation. Tests forthcoming. Tested manually using HelloTask (not checked in) which computed fib and constantly updated the window and it was great. ! javafx-concurrent/src/javafx/concurrent/Task.java ! javafx-concurrent/test/javafx/concurrent/TaskSwampEventQueueTest.java Changeset: ce7477ff2246 Author: prr Date: 2013-01-30 11:40 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ce7477ff2246 Fixed RT-28018: PageLayout constructor arg checking ! javafx-ui-common/src/javafx/print/PageLayout.java Changeset: e4577fd9c0f1 Author: Daniel Blaukopf Date: 2013-01-30 22:00 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e4577fd9c0f1 Fix for RT-28035 (Can't find embedded platform properties) and RT-27194 (Must set javafx.platform) ! javafx-common/src/com/sun/javafx/PlatformUtil.java Changeset: d36aa4dd0524 Author: Martin Sladecek Date: 2013-01-31 13:34 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d36aa4dd0524 RT-28066 Fix Tangent interpolator units + Javadoc update of Interpolator.TANGENT ! javafx-anim/src/com/sun/scenario/animation/NumberTangentInterpolator.java ! javafx-anim/src/com/sun/scenario/animation/shared/InterpolationInterval.java ! javafx-anim/src/javafx/animation/Interpolator.java + javafx-anim/src/javafx/animation/doc-files/tangent_interpolator.png ! javafx-anim/test/unit/com/sun/scenario/animation/NumberTangentInterpolatorTest.java ! javafx-anim/test/unit/javafx/animation/InterpolatorTest.java Changeset: 5a6d64b971ec Author: Martin Sladecek Date: 2013-01-31 13:35 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5a6d64b971ec merge Changeset: 9187bb46dd5f Author: Martin Sladecek Date: 2013-01-31 13:37 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9187bb46dd5f [JAVADOC] update of Interpolator javadoc ! javafx-anim/src/javafx/animation/Interpolator.java Changeset: a30a4db16376 Author: Martin Sladecek Date: 2013-01-31 13:37 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a30a4db16376 merge - apps/experiments/Modena/src/modena/Modena.css - javafx-concurrent/test/javafx/concurrent/AbstractService.java - javafx-ui-common/src/com/sun/javafx/css/parser/Css2Java.java - javafx-ui-common/test/unit/com/sun/javafx/test/OrientationHelper.java - javafx-ui-controls/src/com/preview/javafx/scene/control/DialogResources.java - javafx-ui-controls/src/com/preview/javafx/scene/control/DialogTemplate.java - javafx-ui-controls/src/com/preview/javafx/scene/control/Dialogs.java - javafx-ui-controls/src/com/preview/javafx/scene/control/ExceptionDialog.java - javafx-ui-controls/src/com/preview/javafx/scene/control/FXDialog.java - javafx-ui-controls/src/com/preview/javafx/scene/control/UITextArea.java - javafx-ui-controls/src/com/preview/javafx/scene/control/dialogs.css - javafx-ui-controls/src/com/sun/javafx/scene/control/FocusableTextField.java - javafx-ui-controls/src/javafx/scene/control/CellSpan.java - javafx-ui-controls/src/javafx/scene/control/SpanModel.java Changeset: 99aa53873cc0 Author: Felipe Heidrich Date: 2013-01-31 15:04 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/99aa53873cc0 RT-28099: Remove old/unused draw string code - part 1 - javafx-sg-common/src/com/sun/javafx/sg/PGText.java - javafx-sg-common/src/com/sun/javafx/sg/PGTextHelper.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGText.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGTextHelper.java ! javafx-sg-prism/test/com/sun/javafx/sg/prism/TestGraphics.java ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubText.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextHelper.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: e50a7a45723b Author: Felipe Heidrich Date: 2013-01-31 16:03 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e50a7a45723b RT-28099: Remove old/unused draw string code - part 2 - javafx-sg-common/src/com/sun/javafx/sg/PGSpan.java + javafx-sg-common/src/com/sun/javafx/sg/PGText.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGCanvas.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGSpan.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGText.java ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-common/src/javafx/scene/text/Text.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubSpan.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubText.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: 12bef5a3a874 Author: Martin Sladecek Date: 2013-02-01 15:34 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/12bef5a3a874 Fix for "coverage" target running on JDK7 ! build-defs.xml Changeset: f77dec4adb2a Author: Richard Bair Date: 2013-02-01 08:57 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f77dec4adb2a Partial RT-28089 Summary: Moved build.gradle & settings.gradle to rt. renamed generator.gradle to build.gradle. + build.gradle + settings.gradle Changeset: 871e03bb7fb9 Author: Richard Bair Date: 2013-02-01 09:19 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/871e03bb7fb9 Partial RT-28089 Summary: Added open portion of generator script. Will generate a new "javafx" directory that is a sibling of "rt" + generator.gradle Changeset: 4499eedd0789 Author: Richard Bair Date: 2013-02-01 10:26 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4499eedd0789 Partial RT-28089 Summary: Fixed so that it generates correctly whether run from rt or run from the closed build file that includes all the closed sources. ! generator.gradle Changeset: 7721377d1f70 Author: jgodinez Date: 2013-02-01 11:25 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7721377d1f70 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-concurrent/test/javafx/concurrent/AbstractService.java - javafx-sg-common/src/com/sun/javafx/sg/PGSpan.java ! javafx-sg-common/src/com/sun/javafx/sg/PGText.java - javafx-sg-common/src/com/sun/javafx/sg/PGTextHelper.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGSpan.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGText.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGTextHelper.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/src/javafx/scene/text/TextFlow.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubSpan.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubText.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextHelper.java Changeset: dd34f7bd08cd Author: Richard Bair Date: 2013-02-01 16:14 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/dd34f7bd08cd Partial RT-28089 Summary: Added the graphics tests. They don't execute unfortunately, silly old StubToolkit. ! build.gradle ! generator.gradle Changeset: fa747ba3156b Author: Artem Ananiev Date: 2013-02-04 15:12 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fa747ba3156b Fix for RT-28165: Move javafx-embed-swing and javafx-embed-swt to open Reviewed-by: Kevin Rushforth ! .classpath ! .idea/modules.xml ! build.xml + javafx-embed-swing/build-closed.xml + javafx-embed-swing/build-common.xml + javafx-embed-swing/build.xml + javafx-embed-swing/javafx-embed-swing.iml + javafx-embed-swing/nbproject/project.xml + javafx-embed-swing/project.properties + javafx-embed-swing/src/javafx/embed/swing/DataFlavorUtils.java + javafx-embed-swing/src/javafx/embed/swing/JFXPanel.java + javafx-embed-swing/src/javafx/embed/swing/SwingCursors.java + javafx-embed-swing/src/javafx/embed/swing/SwingDnD.java + javafx-embed-swing/src/javafx/embed/swing/SwingDragSource.java + javafx-embed-swing/src/javafx/embed/swing/SwingEvents.java + javafx-embed-swing/src/javafx/embed/swing/SwingFXUtils.java + javafx-embed-swing/src/javafx/embed/swing/package.html + javafx-embed-swt/build-closed.xml + javafx-embed-swt/build-common.xml + javafx-embed-swt/build.xml + javafx-embed-swt/javafx-embed-swt.iml + javafx-embed-swt/nbproject/project.xml + javafx-embed-swt/project.properties + javafx-embed-swt/src/javafx/embed/swt/CustomTransfer.java + javafx-embed-swt/src/javafx/embed/swt/FXCanvas.java + javafx-embed-swt/src/javafx/embed/swt/SWTCursors.java + javafx-embed-swt/src/javafx/embed/swt/SWTEvents.java + javafx-embed-swt/src/javafx/embed/swt/SWTFXUtils.java + javafx-embed-swt/src/javafx/embed/swt/package.html Changeset: c2fb1c411133 Author: Martin Sladecek Date: 2013-02-04 14:18 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c2fb1c411133 RT-28166 Animation methods accept illegal Duration values that are not expected in the Animation code. ! javafx-anim/src/javafx/animation/Animation.java ! javafx-anim/src/javafx/animation/Timeline.java ! javafx-ui-common/src/javafx/animation/FadeTransition.java ! javafx-ui-common/src/javafx/animation/FillTransition.java ! javafx-ui-common/src/javafx/animation/PathTransition.java ! javafx-ui-common/src/javafx/animation/PauseTransition.java ! javafx-ui-common/src/javafx/animation/RotateTransition.java ! javafx-ui-common/src/javafx/animation/ScaleTransition.java ! javafx-ui-common/src/javafx/animation/StrokeTransition.java ! javafx-ui-common/src/javafx/animation/TranslateTransition.java Changeset: 7425eab5722d Author: Martin Sladecek Date: 2013-02-04 14:25 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7425eab5722d merge Changeset: 2a0b0d0d4dd1 Author: Eva Krejcirova Date: 2013-02-04 16:29 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2a0b0d0d4dd1 RT-14730: Drag and drop needs support for drag view. Reviewed by Pavel Safrata ! javafx-ui-common/src/com/sun/javafx/tk/TKClipboard.java ! javafx-ui-common/src/javafx/scene/input/DataFormat.java ! javafx-ui-common/src/javafx/scene/input/Dragboard.java ! javafx-ui-common/test/unit/javafx/scene/input/DragAndDropTest.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: d715d9ce4dff Author: Martin Sladecek Date: 2013-02-04 17:09 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d715d9ce4dff Fixed failing tests ! javafx-anim/src/javafx/animation/Animation.java Changeset: d5735f8fd0a7 Author: Martin Sladecek Date: 2013-02-04 17:09 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d5735f8fd0a7 merge Changeset: 012c2fd4a6f9 Author: jgodinez Date: 2013-02-04 10:47 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/012c2fd4a6f9 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt - javafx-concurrent/test/javafx/concurrent/AbstractService.java - javafx-sg-common/src/com/sun/javafx/sg/PGSpan.java - javafx-sg-common/src/com/sun/javafx/sg/PGTextHelper.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGSpan.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGTextHelper.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubSpan.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextHelper.java Changeset: 41487f55d1d2 Author: "Joseph Andresen" Date: 2013-02-04 14:34 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/41487f55d1d2 RT-25354 ImagePattern does not track changes ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGRegion.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGShape.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-common/src/javafx/scene/ImageCursor.java ! javafx-ui-common/src/javafx/scene/canvas/GraphicsContext.java ! javafx-ui-common/src/javafx/scene/effect/ColorInput.java ! javafx-ui-common/src/javafx/scene/image/Image.java ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/src/javafx/scene/image/WritableImage.java ! javafx-ui-common/src/javafx/scene/paint/Color.java ! javafx-ui-common/src/javafx/scene/paint/ImagePattern.java ! javafx-ui-common/src/javafx/scene/paint/LinearGradient.java ! javafx-ui-common/src/javafx/scene/paint/Paint.java ! javafx-ui-common/src/javafx/scene/paint/RadialGradient.java ! javafx-ui-common/src/javafx/scene/shape/Shape.java ! javafx-ui-common/src/javafx/scene/text/Text.java Changeset: 254f69a9f5d5 Author: flar Date: 2013-02-04 17:59 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/254f69a9f5d5 Fix tests broken by fix for RT-25354 ! javafx-ui-common/test/unit/javafx/scene/effect/ColorInputTest.java ! javafx-ui-common/test/unit/javafx/scene/image/ImageTest.java ! javafx-ui-common/test/unit/javafx/scene/paint/ImagePatternTest.java ! javafx-ui-common/test/unit/javafx/scene/paint/LinearGradientTest.java ! javafx-ui-common/test/unit/javafx/scene/paint/RadialGradientTest.java Changeset: 9daaff7ef6d5 Author: Martin Sladecek Date: 2013-02-05 09:47 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9daaff7ef6d5 Open-source of javafx-beans ! build.xml ! common.properties ! javafx-anim/build-closed.xml ! javafx-annotation-processor/build-closed.xml ! javafx-annotation-processor/nbproject/project.xml ! javafx-beans-dt/build-closed.xml ! javafx-beans-dt/project.properties + javafx-beans/build-closed.xml + javafx-beans/build-common.xml + javafx-beans/build.xml + javafx-beans/jar.jardesc + javafx-beans/javafx-beans.iml + javafx-beans/nbproject/project.xml + javafx-beans/project.properties + javafx-beans/src/com/sun/javafx/beans/IDProperty.java + javafx-beans/src/com/sun/javafx/beans/annotations/Default.java + javafx-beans/src/com/sun/javafx/beans/annotations/Delegate.java + javafx-beans/src/com/sun/javafx/beans/annotations/DuplicateInBuilderProperties.java + javafx-beans/src/com/sun/javafx/beans/annotations/NoBuilder.java + javafx-beans/src/com/sun/javafx/beans/annotations/NoInit.java + javafx-beans/src/com/sun/javafx/beans/annotations/NonNull.java + javafx-beans/src/com/sun/javafx/binding/BidirectionalBinding.java + javafx-beans/src/com/sun/javafx/binding/BidirectionalContentBinding.java + javafx-beans/src/com/sun/javafx/binding/BindingHelperObserver.java + javafx-beans/src/com/sun/javafx/binding/ContentBinding.java + javafx-beans/src/com/sun/javafx/binding/DoubleConstant.java + javafx-beans/src/com/sun/javafx/binding/ExpressionHelper.java + javafx-beans/src/com/sun/javafx/binding/ExpressionHelperBase.java + javafx-beans/src/com/sun/javafx/binding/FloatConstant.java + javafx-beans/src/com/sun/javafx/binding/IntegerConstant.java + javafx-beans/src/com/sun/javafx/binding/ListExpressionHelper.java + javafx-beans/src/com/sun/javafx/binding/Logging.java + javafx-beans/src/com/sun/javafx/binding/LongConstant.java + javafx-beans/src/com/sun/javafx/binding/MapExpressionHelper.java + javafx-beans/src/com/sun/javafx/binding/ObjectConstant.java + javafx-beans/src/com/sun/javafx/binding/SelectBinding.java + javafx-beans/src/com/sun/javafx/binding/SetExpressionHelper.java + javafx-beans/src/com/sun/javafx/binding/StringConstant.java + javafx-beans/src/com/sun/javafx/binding/StringFormatter.java + javafx-beans/src/com/sun/javafx/collections/BaseModifiableObservableList.java + javafx-beans/src/com/sun/javafx/collections/BaseObservableList.java + javafx-beans/src/com/sun/javafx/collections/ChangeHelper.java + javafx-beans/src/com/sun/javafx/collections/ElementObservableListDecorator.java + javafx-beans/src/com/sun/javafx/collections/ElementObserver.java + javafx-beans/src/com/sun/javafx/collections/ImmutableObservableList.java + javafx-beans/src/com/sun/javafx/collections/ListChangeBuilder.java + javafx-beans/src/com/sun/javafx/collections/ListListenerHelper.java + javafx-beans/src/com/sun/javafx/collections/MapAdapterChange.java + javafx-beans/src/com/sun/javafx/collections/MapListenerHelper.java + javafx-beans/src/com/sun/javafx/collections/MappingChange.java + javafx-beans/src/com/sun/javafx/collections/NonIterableChange.java + javafx-beans/src/com/sun/javafx/collections/ObservableListWrapper.java + javafx-beans/src/com/sun/javafx/collections/ObservableMapWrapper.java + javafx-beans/src/com/sun/javafx/collections/ObservableSetWrapper.java + javafx-beans/src/com/sun/javafx/collections/SetAdapterChange.java + javafx-beans/src/com/sun/javafx/collections/SetListenerHelper.java + javafx-beans/src/com/sun/javafx/collections/SortHelper.java + javafx-beans/src/com/sun/javafx/collections/SortableList.java + javafx-beans/src/com/sun/javafx/collections/SourceAdapterChange.java + javafx-beans/src/com/sun/javafx/collections/TrackableObservableList.java + javafx-beans/src/com/sun/javafx/collections/UnmodifiableListSet.java + javafx-beans/src/com/sun/javafx/collections/UnmodifiableObservableMap.java + javafx-beans/src/com/sun/javafx/collections/VetoableListDecorator.java + javafx-beans/src/com/sun/javafx/collections/annotations/ReturnsUnmodifiableCollection.java + javafx-beans/src/com/sun/javafx/collections/transformation/FilterableList.java + javafx-beans/src/com/sun/javafx/collections/transformation/FilteredList.java + javafx-beans/src/com/sun/javafx/collections/transformation/Matcher.java + javafx-beans/src/com/sun/javafx/collections/transformation/SortableList.java + javafx-beans/src/com/sun/javafx/collections/transformation/SortedList.java + javafx-beans/src/com/sun/javafx/collections/transformation/TransformationList.java + javafx-beans/src/com/sun/javafx/property/PropertyReference.java + javafx-beans/src/com/sun/javafx/property/adapter/JavaBeanPropertyBuilderHelper.java + javafx-beans/src/com/sun/javafx/property/adapter/PropertyDescriptor.java + javafx-beans/src/com/sun/javafx/property/adapter/ReadOnlyJavaBeanPropertyBuilderHelper.java + javafx-beans/src/com/sun/javafx/property/adapter/ReadOnlyPropertyDescriptor.java + javafx-beans/src/javafx/beans/DefaultProperty.java + javafx-beans/src/javafx/beans/InvalidationListener.java + javafx-beans/src/javafx/beans/Observable.java + javafx-beans/src/javafx/beans/WeakInvalidationListener.java + javafx-beans/src/javafx/beans/WeakListener.java + javafx-beans/src/javafx/beans/binding/Binding.java + javafx-beans/src/javafx/beans/binding/Bindings.java + javafx-beans/src/javafx/beans/binding/BooleanBinding.java + javafx-beans/src/javafx/beans/binding/BooleanExpression.java + javafx-beans/src/javafx/beans/binding/DoubleBinding.java + javafx-beans/src/javafx/beans/binding/DoubleExpression.java + javafx-beans/src/javafx/beans/binding/FloatBinding.java + javafx-beans/src/javafx/beans/binding/FloatExpression.java + javafx-beans/src/javafx/beans/binding/IntegerBinding.java + javafx-beans/src/javafx/beans/binding/IntegerExpression.java + javafx-beans/src/javafx/beans/binding/ListBinding.java + javafx-beans/src/javafx/beans/binding/ListExpression.java + javafx-beans/src/javafx/beans/binding/LongBinding.java + javafx-beans/src/javafx/beans/binding/LongExpression.java + javafx-beans/src/javafx/beans/binding/MapBinding.java + javafx-beans/src/javafx/beans/binding/MapExpression.java + javafx-beans/src/javafx/beans/binding/NumberBinding.java + javafx-beans/src/javafx/beans/binding/NumberExpression.java + javafx-beans/src/javafx/beans/binding/NumberExpressionBase.java + javafx-beans/src/javafx/beans/binding/ObjectBinding.java + javafx-beans/src/javafx/beans/binding/ObjectExpression.java + javafx-beans/src/javafx/beans/binding/SetBinding.java + javafx-beans/src/javafx/beans/binding/SetExpression.java + javafx-beans/src/javafx/beans/binding/StringBinding.java + javafx-beans/src/javafx/beans/binding/StringExpression.java + javafx-beans/src/javafx/beans/binding/When.java + javafx-beans/src/javafx/beans/binding/package.html + javafx-beans/src/javafx/beans/package.html + javafx-beans/src/javafx/beans/property/BooleanProperty.java + javafx-beans/src/javafx/beans/property/BooleanPropertyBase.java + javafx-beans/src/javafx/beans/property/DoubleProperty.java + javafx-beans/src/javafx/beans/property/DoublePropertyBase.java + javafx-beans/src/javafx/beans/property/FloatProperty.java + javafx-beans/src/javafx/beans/property/FloatPropertyBase.java + javafx-beans/src/javafx/beans/property/IntegerProperty.java + javafx-beans/src/javafx/beans/property/IntegerPropertyBase.java + javafx-beans/src/javafx/beans/property/ListProperty.java + javafx-beans/src/javafx/beans/property/ListPropertyBase.java + javafx-beans/src/javafx/beans/property/LongProperty.java + javafx-beans/src/javafx/beans/property/LongPropertyBase.java + javafx-beans/src/javafx/beans/property/MapProperty.java + javafx-beans/src/javafx/beans/property/MapPropertyBase.java + javafx-beans/src/javafx/beans/property/ObjectProperty.java + javafx-beans/src/javafx/beans/property/ObjectPropertyBase.java + javafx-beans/src/javafx/beans/property/Property.java + javafx-beans/src/javafx/beans/property/ReadOnlyBooleanProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyBooleanPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyBooleanWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyDoubleProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyDoublePropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyDoubleWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyFloatProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyFloatPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyFloatWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyIntegerProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyIntegerPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyIntegerWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyListProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyListPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyListWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyLongProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyLongPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyLongWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyMapProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyMapPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyMapWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyObjectProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyObjectPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyObjectWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlySetProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlySetPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlySetWrapper.java + javafx-beans/src/javafx/beans/property/ReadOnlyStringProperty.java + javafx-beans/src/javafx/beans/property/ReadOnlyStringPropertyBase.java + javafx-beans/src/javafx/beans/property/ReadOnlyStringWrapper.java + javafx-beans/src/javafx/beans/property/SetProperty.java + javafx-beans/src/javafx/beans/property/SetPropertyBase.java + javafx-beans/src/javafx/beans/property/SimpleBooleanProperty.java + javafx-beans/src/javafx/beans/property/SimpleDoubleProperty.java + javafx-beans/src/javafx/beans/property/SimpleFloatProperty.java + javafx-beans/src/javafx/beans/property/SimpleIntegerProperty.java + javafx-beans/src/javafx/beans/property/SimpleListProperty.java + javafx-beans/src/javafx/beans/property/SimpleLongProperty.java + javafx-beans/src/javafx/beans/property/SimpleMapProperty.java + javafx-beans/src/javafx/beans/property/SimpleObjectProperty.java + javafx-beans/src/javafx/beans/property/SimpleSetProperty.java + javafx-beans/src/javafx/beans/property/SimpleStringProperty.java + javafx-beans/src/javafx/beans/property/StringProperty.java + javafx-beans/src/javafx/beans/property/StringPropertyBase.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanBooleanProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanBooleanPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanDoubleProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanDoublePropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanFloatProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanFloatPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanIntegerProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanIntegerPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanLongProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanLongPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanObjectProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanObjectPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanStringProperty.java + javafx-beans/src/javafx/beans/property/adapter/JavaBeanStringPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanBooleanProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanBooleanPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanDoubleProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanDoublePropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanFloatProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanFloatPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanIntegerProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanIntegerPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanLongProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanLongPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanObjectProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanObjectPropertyBuilder.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanStringProperty.java + javafx-beans/src/javafx/beans/property/adapter/ReadOnlyJavaBeanStringPropertyBuilder.java + javafx-beans/src/javafx/beans/property/package.html + javafx-beans/src/javafx/beans/value/ChangeListener.java + javafx-beans/src/javafx/beans/value/ObservableBooleanValue.java + javafx-beans/src/javafx/beans/value/ObservableDoubleValue.java + javafx-beans/src/javafx/beans/value/ObservableFloatValue.java + javafx-beans/src/javafx/beans/value/ObservableIntegerValue.java + javafx-beans/src/javafx/beans/value/ObservableListValue.java + javafx-beans/src/javafx/beans/value/ObservableLongValue.java + javafx-beans/src/javafx/beans/value/ObservableMapValue.java + javafx-beans/src/javafx/beans/value/ObservableNumberValue.java + javafx-beans/src/javafx/beans/value/ObservableObjectValue.java + javafx-beans/src/javafx/beans/value/ObservableSetValue.java + javafx-beans/src/javafx/beans/value/ObservableStringValue.java + javafx-beans/src/javafx/beans/value/ObservableValue.java + javafx-beans/src/javafx/beans/value/ObservableValueBase.java + javafx-beans/src/javafx/beans/value/WeakChangeListener.java + javafx-beans/src/javafx/beans/value/WritableBooleanValue.java + javafx-beans/src/javafx/beans/value/WritableDoubleValue.java + javafx-beans/src/javafx/beans/value/WritableFloatValue.java + javafx-beans/src/javafx/beans/value/WritableIntegerValue.java + javafx-beans/src/javafx/beans/value/WritableListValue.java + javafx-beans/src/javafx/beans/value/WritableLongValue.java + javafx-beans/src/javafx/beans/value/WritableMapValue.java + javafx-beans/src/javafx/beans/value/WritableNumberValue.java + javafx-beans/src/javafx/beans/value/WritableObjectValue.java + javafx-beans/src/javafx/beans/value/WritableSetValue.java + javafx-beans/src/javafx/beans/value/WritableStringValue.java + javafx-beans/src/javafx/beans/value/WritableValue.java + javafx-beans/src/javafx/beans/value/package.html + javafx-beans/src/javafx/collections/FXCollections.java + javafx-beans/src/javafx/collections/ListChangeListener.java + javafx-beans/src/javafx/collections/MapChangeListener.java + javafx-beans/src/javafx/collections/ObservableList.java + javafx-beans/src/javafx/collections/ObservableMap.java + javafx-beans/src/javafx/collections/ObservableSet.java + javafx-beans/src/javafx/collections/SetChangeListener.java + javafx-beans/src/javafx/collections/WeakListChangeListener.java + javafx-beans/src/javafx/collections/WeakMapChangeListener.java + javafx-beans/src/javafx/collections/WeakSetChangeListener.java + javafx-beans/src/javafx/collections/package.html + javafx-beans/test/com/sun/javafx/binding/BidirectionalBindingTest.java + javafx-beans/test/com/sun/javafx/binding/BidirectionalBindingWithConversionTest.java + javafx-beans/test/com/sun/javafx/binding/BidirectionalContentBindingListTest.java + javafx-beans/test/com/sun/javafx/binding/BidirectionalContentBindingMapTest.java + javafx-beans/test/com/sun/javafx/binding/BidirectionalContentBindingSetTest.java + javafx-beans/test/com/sun/javafx/binding/ContentBindingListTest.java + javafx-beans/test/com/sun/javafx/binding/ContentBindingMapTest.java + javafx-beans/test/com/sun/javafx/binding/ContentBindingSetTest.java + javafx-beans/test/com/sun/javafx/binding/ErrorLoggingUtiltity.java + javafx-beans/test/com/sun/javafx/binding/ExpressionHelperBaseTest.java + javafx-beans/test/com/sun/javafx/binding/ExpressionHelperTest.java + javafx-beans/test/com/sun/javafx/binding/ExpressionHelperUtility.java + javafx-beans/test/com/sun/javafx/binding/ExpressionHelperUtilityTest.java + javafx-beans/test/com/sun/javafx/binding/ListExpressionHelperTest.java + javafx-beans/test/com/sun/javafx/binding/SelectBindingTest.java + javafx-beans/test/com/sun/javafx/binding/StringFormatterTest.java + javafx-beans/test/com/sun/javafx/collections/ListChangeBuilderTest.java + javafx-beans/test/com/sun/javafx/collections/ListListenerHelperTest.java + javafx-beans/test/com/sun/javafx/collections/MapListenerHelperTest.java + javafx-beans/test/com/sun/javafx/collections/SetListenerHelperTest.java + javafx-beans/test/com/sun/javafx/property/adapter/JavaBeanPropertyBuilderHelperTest.java + javafx-beans/test/com/sun/javafx/property/adapter/PropertyDescriptorTest.java + javafx-beans/test/com/sun/javafx/property/adapter/ReadOnlyPropertyDescriptorTest.java + javafx-beans/test/javafx/beans/Foo.java + javafx-beans/test/javafx/beans/InvalidationListenerMock.java + javafx-beans/test/javafx/beans/Person.java + javafx-beans/test/javafx/beans/WeakInvalidationListenerMock.java + javafx-beans/test/javafx/beans/WeakInvalidationListenerTest.java + javafx-beans/test/javafx/beans/property/BooleanPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/BooleanPropertyTest.java + javafx-beans/test/javafx/beans/property/DoublePropertyBaseTest.java + javafx-beans/test/javafx/beans/property/DoublePropertyTest.java + javafx-beans/test/javafx/beans/property/FloatPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/FloatPropertyTest.java + javafx-beans/test/javafx/beans/property/IntegerPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/IntegerPropertyTest.java + javafx-beans/test/javafx/beans/property/ListPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ListPropertyTest.java + javafx-beans/test/javafx/beans/property/LongPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/LongPropertyTest.java + javafx-beans/test/javafx/beans/property/MapPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/MapPropertyTest.java + javafx-beans/test/javafx/beans/property/ObjectPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ObjectPropertyTest.java + javafx-beans/test/javafx/beans/property/PropertiesTest.java + javafx-beans/test/javafx/beans/property/PropertyReferenceTest.java + javafx-beans/test/javafx/beans/property/PropertyReferenceWithInterfacesTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyBooleanPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyBooleanPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyBooleanWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyDoublePropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyDoublePropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyDoubleWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyFloatPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyFloatPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyFloatWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyIntegerPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyIntegerPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyIntegerWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyListPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyListPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyListWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyLongPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyLongPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyLongWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyMapPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyMapPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyMapWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyObjectPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyObjectPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyObjectWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlySetPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlySetPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlySetWrapperTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyStringPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyStringPropertyTest.java + javafx-beans/test/javafx/beans/property/ReadOnlyStringWrapperTest.java + javafx-beans/test/javafx/beans/property/SetPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/SetPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleBooleanPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleDoublePropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleFloatPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleIntegerPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleListPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleLongPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleObjectPropertyTest.java + javafx-beans/test/javafx/beans/property/SimpleStringPropertyTest.java + javafx-beans/test/javafx/beans/property/StringPropertyBaseTest.java + javafx-beans/test/javafx/beans/property/StringPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanBooleanPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanBooleanProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanDoublePropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanDoubleProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanFloatPropertyBuilderaTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanFloatProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanIntegerPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanIntegerProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanLongPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanLongProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanObjectPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanPropertyTestBase.java + javafx-beans/test/javafx/beans/property/adapter/JavaBeanStringPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanBooleanPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanBooleanProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanDoublePropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanDoubleProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanFloatPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanFloatProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanIntegerPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanIntegerProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanLongPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanLongProperty_prim_Test.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanObjectPropertyTest.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanPropertyBuilder_General_Test.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanPropertyTestBase.java + javafx-beans/test/javafx/beans/property/adapter/ReadOnlyJavaBeanStringPropertyTest.java + javafx-beans/test/javafx/beans/value/ChangeListenerMock.java + javafx-beans/test/javafx/beans/value/ObservableBooleanValueStub.java + javafx-beans/test/javafx/beans/value/ObservableDoubleValueStub.java + javafx-beans/test/javafx/beans/value/ObservableFloatValueStub.java + javafx-beans/test/javafx/beans/value/ObservableIntegerValueStub.java + javafx-beans/test/javafx/beans/value/ObservableLongValueStub.java + javafx-beans/test/javafx/beans/value/ObservableObjectValueStub.java + javafx-beans/test/javafx/beans/value/ObservableStringValueStub.java + javafx-beans/test/javafx/beans/value/ObservableValueBaseTest.java + javafx-beans/test/javafx/beans/value/ObservableValueStub.java + javafx-beans/test/javafx/beans/value/WeakChangeListenerMock.java + javafx-beans/test/javafx/beans/value/WeakChangeListenerTest.java + javafx-beans/test/javafx/binding/BindingToStringTest.java + javafx-beans/test/javafx/binding/BindingsBooleanTest.java + javafx-beans/test/javafx/binding/BindingsCreateBindingTest.java + javafx-beans/test/javafx/binding/BindingsEqualsTest.java + javafx-beans/test/javafx/binding/BindingsIsNullTest.java + javafx-beans/test/javafx/binding/BindingsListTest.java + javafx-beans/test/javafx/binding/BindingsMapTest.java + javafx-beans/test/javafx/binding/BindingsNumberCalculationsTest.java + javafx-beans/test/javafx/binding/BindingsNumberCastTest.java + javafx-beans/test/javafx/binding/BindingsSetTest.java + javafx-beans/test/javafx/binding/DependencyUtils.java + javafx-beans/test/javafx/binding/GenericBindingTest.java + javafx-beans/test/javafx/binding/ListBindingTest.java + javafx-beans/test/javafx/binding/MapBindingTest.java + javafx-beans/test/javafx/binding/SetBindingTest.java + javafx-beans/test/javafx/binding/Variable.java + javafx-beans/test/javafx/binding/WhenTestBase.java + javafx-beans/test/javafx/binding/When_Boolean_Test.java + javafx-beans/test/javafx/binding/When_Double_Test.java + javafx-beans/test/javafx/binding/When_Float_Test.java + javafx-beans/test/javafx/binding/When_Integer_Test.java + javafx-beans/test/javafx/binding/When_Long_Test.java + javafx-beans/test/javafx/binding/When_Object_Test.java + javafx-beans/test/javafx/binding/When_String_Test.java + javafx-beans/test/javafx/binding/expression/AbstractNumberExpressionTest.java + javafx-beans/test/javafx/binding/expression/BooleanExpressionTest.java + javafx-beans/test/javafx/binding/expression/DoubleExpressionTest.java + javafx-beans/test/javafx/binding/expression/FloatExpressionTest.java + javafx-beans/test/javafx/binding/expression/IntegerExpressionTest.java + javafx-beans/test/javafx/binding/expression/ListExpressionTest.java + javafx-beans/test/javafx/binding/expression/LongExpressionTest.java + javafx-beans/test/javafx/binding/expression/MapExpressionTest.java + javafx-beans/test/javafx/binding/expression/ObjectExpressionTest.java + javafx-beans/test/javafx/binding/expression/SetExpressionTest.java + javafx-beans/test/javafx/binding/expression/StringExpressionTest.java + javafx-beans/test/javafx/collections/Callable.java + javafx-beans/test/javafx/collections/FXCollectionsTest.java + javafx-beans/test/javafx/collections/FilteredListTest.java + javafx-beans/test/javafx/collections/MockListObserver.java + javafx-beans/test/javafx/collections/MockMapObserver.java + javafx-beans/test/javafx/collections/MockSetObserver.java + javafx-beans/test/javafx/collections/ObservableListIteratorTestBase.java + javafx-beans/test/javafx/collections/ObservableListIterator_P1_Test.java + javafx-beans/test/javafx/collections/ObservableListIterator_P2_Test.java + javafx-beans/test/javafx/collections/ObservableListIterator_P3_Test.java + javafx-beans/test/javafx/collections/ObservableListTestBase.java + javafx-beans/test/javafx/collections/ObservableListTestBase_Empty.java + javafx-beans/test/javafx/collections/ObservableListWithExtractor.java + javafx-beans/test/javafx/collections/ObservableList_Empty_P1_Test.java + javafx-beans/test/javafx/collections/ObservableList_Empty_P2_Test.java + javafx-beans/test/javafx/collections/ObservableList_Empty_P3_Test.java + javafx-beans/test/javafx/collections/ObservableList_P1_Test.java + javafx-beans/test/javafx/collections/ObservableList_P2_Test.java + javafx-beans/test/javafx/collections/ObservableList_P3_Test.java + javafx-beans/test/javafx/collections/ObservableMapTestBase.java + javafx-beans/test/javafx/collections/ObservableMap_P1_Test.java + javafx-beans/test/javafx/collections/ObservableMap_P2_Test.java + javafx-beans/test/javafx/collections/ObservableMap_P3_Test.java + javafx-beans/test/javafx/collections/ObservableMap_P4_Test.java + javafx-beans/test/javafx/collections/ObservableSetTestBase.java + javafx-beans/test/javafx/collections/ObservableSet_P1_Test.java + javafx-beans/test/javafx/collections/ObservableSet_P2_Test.java + javafx-beans/test/javafx/collections/ObservableSet_P3_Test.java + javafx-beans/test/javafx/collections/ObservableSubListIteratorTestBase.java + javafx-beans/test/javafx/collections/ObservableSubListIterator_P1_Test.java + javafx-beans/test/javafx/collections/ObservableSubListIterator_P2_Test.java + javafx-beans/test/javafx/collections/ObservableSubListIterator_P3_Test.java + javafx-beans/test/javafx/collections/ObservableSubListTestBase.java + javafx-beans/test/javafx/collections/ObservableSubList_P1_Test.java + javafx-beans/test/javafx/collections/ObservableSubList_P2_Test.java + javafx-beans/test/javafx/collections/ObservableSubList_P3_Test.java + javafx-beans/test/javafx/collections/Person.java + javafx-beans/test/javafx/collections/SortedListTest.java + javafx-beans/test/javafx/collections/TestedObservableLists.java + javafx-beans/test/javafx/collections/TransformationListTest.java + javafx-beans/test/javafx/collections/UnmodifiableObservableMapTestBase.java + javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P1_Test.java + javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P2_Test.java + javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P3_Test.java + javafx-beans/test/javafx/collections/UnmodifiableObservableMap_P4_Test.java + javafx-beans/test/javafx/collections/VetoableObservableListTest.java + javafx-beans/test/javafx/collections/WeakListChangeListenerMock.java + javafx-beans/test/javafx/collections/WeakListChangeListenerTest.java + javafx-beans/test/javafx/collections/WeakMapChangeListenerTest.java + javafx-beans/test/javafx/collections/WeakSetChangeListenerTest.java ! javafx-concurrent/build-closed.xml ! javafx-concurrent/project.properties ! javafx-designtime/build-closed.xml ! javafx-fxml/build-closed.xml ! javafx-fxml/nbproject/project.xml ! javafx-sg-common/project.properties ! javafx-ui-charts/build-closed.xml ! javafx-ui-common/build-closed.xml ! javafx-ui-common/nbproject/project.xml ! javafx-ui-controls/build-closed.xml ! javafx-ui-controls/build-common.xml ! javafx-util-converter/build-closed.xml Changeset: e573fa389ba7 Author: Radko Najman Date: 2013-02-05 13:45 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e573fa389ba7 RT-16008: Dirty region of nodes under group with effect should adjust itself so that it covers every affected pixels ! javafx-geom/src/com/sun/javafx/geom/BaseBounds.java ! javafx-geom/src/com/sun/javafx/geom/BoxBounds.java + javafx-geom/src/com/sun/javafx/geom/DirtyRegionContainer.java + javafx-geom/src/com/sun/javafx/geom/DirtyRegionPool.java ! javafx-geom/src/com/sun/javafx/geom/RectBounds.java + javafx-geom/test/com/sun/javafx/geom/DirtyRegionContainerTest.java ! javafx-sg-common/src/com/sun/javafx/sg/BaseNode.java - javafx-sg-common/src/com/sun/javafx/sg/DirtyRegionContainer.java - javafx-sg-common/src/com/sun/javafx/sg/DirtyRegionPool.java ! javafx-sg-common/test/com/sun/javafx/sg/CullingTest.java - javafx-sg-common/test/com/sun/javafx/sg/DirtyRegionContainerTest.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGCanvas.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGGroup.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGNode.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NodeEffectInput.java ! javafx-sg-prism/test/com/sun/javafx/sg/prism/DirtyRegionTestBase.java ! javafx-sg-prism/test/com/sun/javafx/sg/prism/NodeTestUtils.java Changeset: db6fc38a2116 Author: flar Date: 2013-02-05 09:28 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/db6fc38a2116 Fix RT-27964 - Load HiDPI images when available on HiDPI displays ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGCanvas.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGImageView.java ! javafx-ui-common/src/com/sun/javafx/tk/PlatformImage.java ! javafx-ui-common/src/javafx/scene/image/Image.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubFilterable.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubPlatformImage.java Changeset: ddcec14f0d81 Author: Jonathan Giles Date: 2013-02-01 09:58 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ddcec14f0d81 RT-28100: Make internal KeyBinding class consistent with key events and simplify cross-platform controls behaviour code. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/KeyBinding.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/OrientedKeyBinding.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextBinding.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/test/javafx/scene/control/KeyEventFirer.java ! javafx-ui-controls/test/javafx/scene/control/KeyModifier.java ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java Changeset: 46d18078dffd Author: Jonathan Giles Date: 2013-02-01 10:02 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/46d18078dffd Merge Changeset: 78544be55907 Author: jgiles Date: 2013-01-31 09:08 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/78544be55907 RT-24484: [TreeView, TreeTableView] Should support clickCounts greater than 2 (by expanding / collapsing branches when clickCount % 2 == 0) ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java Changeset: 9b7793501d71 Author: jgiles Date: 2013-01-31 09:11 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9b7793501d71 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 1877fab88c54 Author: jgiles Date: 2013-02-01 10:04 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1877fab88c54 RT-28098: [TreeView, TreeTableView] Disclosure nodes should animate when branches are expanded / collapsed Whilst a trivial tweak, I mainly did this to drill down into functional issues and performance of TreeView and TreeTableView. I believe performance is significantly improved now, but I am pushing to the repo to get performance numbers across the board from our perf tests. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/caspian.css ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css ! javafx-ui-controls/src/javafx/scene/control/TreeTableRow.java Changeset: fb32a5e26397 Author: jgiles Date: 2013-02-01 10:08 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fb32a5e26397 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: cc7fed4a834c Author: mickf Date: 2013-02-01 15:27 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/cc7fed4a834c RT-28130 : Resolve Findbugs issues in com.sun.javafx.scene.control.ScrollBar ! javafx-ui-controls/src/javafx/scene/control/ScrollBar.java Changeset: 74802b5965e1 Author: David Grieve Date: 2013-02-01 11:16 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/74802b5965e1 RT-25288: add support for functional pseudo-class :dir() ! javafx-ui-common/src/com/sun/javafx/css/Match.java ! javafx-ui-common/src/com/sun/javafx/css/SimpleSelector.java ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java ! javafx-ui-common/src/javafx/scene/Scene.java + javafx-ui-common/test/unit/javafx/scene/Node_effectiveOrientation_Css_Test.java Changeset: f440bb18e36e Author: David Grieve Date: 2013-02-01 12:41 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f440bb18e36e RT-25288: previous changeset for this bug introduced an index out of bounds exception coming from PseudoClassSet ! javafx-ui-common/src/com/sun/javafx/css/PseudoClassSet.java Changeset: 3b32a4d8521d Author: David Grieve Date: 2013-02-01 12:56 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3b32a4d8521d RT-27472: check if term returns null. if so, skip expr ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java Changeset: ec3108783ed1 Author: Paru Somashekar Date: 2013-02-01 16:31 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ec3108783ed1 fix RT-27901 LineChart series colors are not unique & RT-28090 PieChart throws IAE when elements are sorted ! javafx-ui-charts/src/javafx/scene/chart/AreaChart.java ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java ! javafx-ui-charts/src/javafx/scene/chart/LineChart.java ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java Changeset: 33ec77bbf951 Author: jgiles Date: 2013-02-01 14:29 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/33ec77bbf951 [TEST ONLY] Added two unit tests for RT-28113: [TreeView, TreeTableView] Focus jumps to TreeItem sibling when child TreeItem is removed. Both tests are @Ignore'd at the moment, pending a chance to resolve the bug. ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: 66a0f97af26d Author: jgiles Date: 2013-02-01 17:17 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/66a0f97af26d Remove accidental println. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java Changeset: c954f63ec612 Author: jgiles Date: 2013-02-02 09:43 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c954f63ec612 RT-25142: ComboBox accepts setItems(null) but later throws NPE when layout() is called. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java Changeset: 84b84a9d3d5d Author: jgiles Date: 2013-02-04 14:49 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/84b84a9d3d5d Further work on RT-28100: Make internal KeyBinding class consistent with key events and simplify cross-platform controls behaviour code. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/KeyBinding.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/OrientedKeyBinding.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java ! javafx-ui-controls/test/javafx/scene/control/KeyEventFirer.java ! javafx-ui-controls/test/javafx/scene/control/KeyModifier.java Changeset: 8727876146cb Author: jgiles Date: 2013-02-04 14:49 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8727876146cb [TEST ONLY] Added unit tests for RT-28065 (although the tests are disabled until a fix is in place). ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewKeyInputTest.java Changeset: b7bfb47e2654 Author: jgiles Date: 2013-02-04 15:13 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b7bfb47e2654 RT-27829: Clean up controls compilation warnings (part two) Contributed-By: Tom Schindl Reviewed-By: jgiles ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java ! javafx-ui-controls/src/javafx/scene/control/MultipleSelectionModelBase.java ! javafx-ui-controls/src/javafx/scene/control/ScrollToEvent.java ! javafx-ui-controls/src/javafx/scene/control/Separator.java ! javafx-ui-controls/src/javafx/scene/control/Tab.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TablePosition.java ! javafx-ui-controls/src/javafx/scene/control/TitledPane.java ! javafx-ui-controls/src/javafx/scene/control/ToggleButton.java ! javafx-ui-controls/src/javafx/scene/control/ToolBar.java ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java ! javafx-ui-controls/src/javafx/scene/control/TreeCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeItem.java ! javafx-ui-controls/src/javafx/scene/control/TreeTablePosition.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableRow.java Changeset: 0e085e2dce76 Author: jgiles Date: 2013-02-04 15:17 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0e085e2dce76 RT-28128: TableColumnBase.DEFAULT_COMPARATOR can lead to CCE Contributed-By: Tom Schindl Reviewed-By: jgiles ! javafx-ui-controls/src/javafx/scene/control/TableColumnBase.java Changeset: 29207ea36ee0 Author: jgiles Date: 2013-02-04 17:03 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/29207ea36ee0 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 8252bde86002 Author: Jonathan Giles Date: 2013-02-04 19:00 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/8252bde86002 Significantly improved keyboard navigation support for ListView, TreeView, TableView and TreeTableView on Mac OS (as part of RT-27658). Additionally, I have fixed up all the *KeyInputTest unit tests to run and pass on Mac OS, although due to memory limitations of the build servers they continue to be @Ignore'd. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeViewBehavior.java ! javafx-ui-controls/test/javafx/scene/control/ListViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewKeyInputTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewKeyInputTest.java Changeset: 3408eed98c2c Author: mickf Date: 2013-02-04 14:58 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3408eed98c2c RT-22977 : Keyboard focus Traversal : Non-mouse Traversal Input ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ChoiceBoxBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ComboBoxBaseBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ListViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/SliderBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/Utils.java Changeset: 1310b65cbceb Author: mickf Date: 2013-02-04 15:54 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1310b65cbceb RT-28042 : Resolve Findbugs issues in com.sun.javafx.scene.control.skin.Utils ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/Utils.java Changeset: f6b77bf59fff Author: David Grieve Date: 2013-02-04 16:29 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f6b77bf59fff branch merge ! javafx-ui-common/src/javafx/scene/Scene.java Changeset: 38b3163d69ac Author: Paru Somashekar Date: 2013-02-04 16:52 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/38b3163d69ac RT-23123 autoranging lead to charts incorrect appearance ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java Changeset: 16b8b81ecfcd Author: jgiles Date: 2013-02-05 11:52 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/16b8b81ecfcd [TEST ONLY] Added unit test for RT-24412 ! javafx-ui-controls/test/javafx/scene/control/ComboBoxTest.java Changeset: 3f20a5e249d9 Author: jgiles Date: 2013-02-05 16:06 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3f20a5e249d9 RT-27852: [TreeView, TreeTableView] expanding/collapsing doesn't work when resetting the root of the TreeView. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeViewSkin.java Changeset: c46edc2e930f Author: jgiles Date: 2013-02-05 16:13 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c46edc2e930f Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt Changeset: 3587d30fc228 Author: David Grieve Date: 2013-02-05 10:44 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3587d30fc228 RT-23691: stylemanager leaks like a sieve. ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java ! javafx-ui-common/src/javafx/application/Application.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/stage/Window.java ! javafx-ui-common/test/unit/com/sun/javafx/css/CssMetaDataTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/HonorDeveloperSettingsTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/Node_cssStyleMap_Test.java ! javafx-ui-common/test/unit/com/sun/javafx/css/StyleManagerTest.java ! javafx-ui-common/test/unit/javafx/scene/Node_effectiveOrientation_Css_Test.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/test/javafx/scene/control/PopupControlTest.java Changeset: 94130cc6c0a2 Author: Paru Somashekar Date: 2013-02-05 08:53 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/94130cc6c0a2 RT-24342 ColorPicker missing javadoc. ! javafx-ui-controls/src/javafx/scene/control/ColorPicker.java Changeset: 98da68b53ff0 Author: David Grieve Date: 2013-02-05 11:50 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/98da68b53ff0 RT-27155: if setting value raises exception, reset value the value to initial and thereafter skip setting the property ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java Changeset: 6dea9882cca3 Author: David Grieve Date: 2013-02-05 11:51 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6dea9882cca3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/rt Changeset: 7c234c222c85 Author: Paru Somashekar Date: 2013-02-05 15:18 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7c234c222c85 RT-23091 PieChart data changed issue, RT-24847 Grab testing NPE & RT-15291: Resetting data in LineChart issue ! javafx-ui-charts/src/javafx/scene/chart/LineChart.java ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/MenuBarSkin.java Changeset: ffa3ff5846b9 Author: "Jasper Potts" Date: 2013-02-05 17:02 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ffa3ff5846b9 Modena test app, added new page and upated tests. ! apps/experiments/Modena/src/modena/Modena.java ! apps/experiments/Modena/src/modena/SamplePage.java ! apps/experiments/Modena/src/modena/SamplePageHelpers.java ! apps/experiments/Modena/src/modena/SimpleWindowPage.java ! apps/experiments/Modena/src/modena/TestApp.css ! apps/experiments/Modena/src/modena/simple-window.fxml ! apps/experiments/Modena/src/modena/simple-window.fxml.bak + apps/experiments/Modena/src/modena/ubuntu-window-frame.png ! apps/experiments/Modena/src/modena/ui-mosaic.fxml + apps/experiments/Modena/src/modena/ui-mosaic.fxml.bak + apps/experiments/Modena/src/modena/windows7-window-frame.png ! apps/experiments/Modena/src/modena/windows8-window-frame.png Changeset: 5fdb62478264 Author: "Jasper Potts" Date: 2013-02-05 17:02 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5fdb62478264 Modena theme, changed to less rounded corners and blue focus color. Lots of other little tweeks as a result ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 27a5dff62edc Author: David Grieve Date: 2013-02-06 10:28 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/27a5dff62edc branch merge - javafx-concurrent/test/javafx/concurrent/AbstractService.java - javafx-sg-common/src/com/sun/javafx/sg/DirtyRegionContainer.java - javafx-sg-common/src/com/sun/javafx/sg/DirtyRegionPool.java - javafx-sg-common/src/com/sun/javafx/sg/PGSpan.java - javafx-sg-common/src/com/sun/javafx/sg/PGTextHelper.java - javafx-sg-common/test/com/sun/javafx/sg/DirtyRegionContainerTest.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGSpan.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGTextHelper.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubSpan.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubTextHelper.java Changeset: d39f91a06d08 Author: hudson Date: 2013-02-07 14:40 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d39f91a06d08 Added tag 8.0-b76 for changeset 27a5dff62edc ! .hgtags Changeset: a2a4de77db5f Author: David Grieve Date: 2013-02-07 15:34 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a2a4de77db5f [TEST ONLY] RT-28273: disable Node_effectiveOrientation_Css_Test ! javafx-ui-common/test/unit/javafx/scene/Node_effectiveOrientation_Css_Test.java Changeset: 591738b789c3 Author: David Grieve Date: 2013-02-07 19:00 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/591738b789c3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt From hang.vo at oracle.com Thu Feb 7 19:03:08 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Feb 2013 03:03:08 +0000 Subject: hg: openjfx/8/controls/rt: javadoc for installing tooltips on XYChart symbols. Message-ID: <20130208030312.59C0C4790C@hg.openjdk.java.net> Changeset: 1b745a96e73b Author: Paru Somashekar Date: 2013-02-07 18:57 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/1b745a96e73b javadoc for installing tooltips on XYChart symbols. ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java From alexandre.iline at oracle.com Fri Feb 8 04:38:23 2013 From: alexandre.iline at oracle.com (alexandre.iline at oracle.com) Date: Fri, 08 Feb 2013 12:38:23 +0000 Subject: hg: openjfx/8/master/tests: 2 new changesets Message-ID: <20130208123824.EFA5747939@hg.openjdk.java.net> Changeset: 94a803dbcc0d Author: Shura Date: 2013-02-08 04:20 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/94a803dbcc0d re-mapping mouse buttons in glass robot similar to AWT robot a test fix ! tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/DefaultGlassInputMap.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/tableview/TableViewSample.java Changeset: 3ab4b68a796d Author: Shura Date: 2013-02-08 04:23 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/3ab4b68a796d update project info for GlassRobot and GlassImage ! tools/Jemmy/GlassImage/build.xml ! tools/Jemmy/GlassRobot/build.xml From tobi at ultramixer.com Fri Feb 8 05:21:33 2013 From: tobi at ultramixer.com (Tobias Bley) Date: Fri, 8 Feb 2013 14:21:33 +0100 Subject: Using shaders in JavaFX? Message-ID: <2A3ACB80-1F85-46B2-9F52-9A433329DEEB@ultramixer.com> Hi JavaFX freaks, JavaFX is a very wonderful language and we made several tests in porting our Swing based consumer apps to JavaFX - successfully! I love porting to JavaFX :) What I would like to know is: Is it possible to use (OpenGL) shaders in JavaFX? Best regards, Tobi -- Tobias Bley Chief Executive Officer -------------------------------------------------------- UltraMixer Digital Audio Solutions Schillerstra?e 29 D-01326 Dresden Germany -------------------------------------------------------- bley at ultramixer.com http://www.ultramixer.com From alexandre.iline at oracle.com Fri Feb 8 05:28:13 2013 From: alexandre.iline at oracle.com (alexandre.iline at oracle.com) Date: Fri, 08 Feb 2013 13:28:13 +0000 Subject: hg: openjfx/8/master/tests: Test stability fix Message-ID: <20130208132813.D3EF84793C@hg.openjdk.java.net> Changeset: da642cc2e917 Author: Alexandre (Shura) Iline Date: 2013-02-08 17:26 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/da642cc2e917 Test stability fix ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/input/InputSampleBase.java From neugens at redhat.com Fri Feb 8 05:46:23 2013 From: neugens at redhat.com (Mario Torre) Date: Fri, 08 Feb 2013 14:46:23 +0100 Subject: How to build openjfx in its current state In-Reply-To: <986847F1-22C3-4FCD-8C3D-89F0E9FA0FEB@oracle.com> References: <1360249250.1911.8.camel@pegasus> <986847F1-22C3-4FCD-8C3D-89F0E9FA0FEB@oracle.com> Message-ID: <1360331183.1911.113.camel@pegasus> Il giorno gio, 07/02/2013 alle 15.12 -0800, Richard Bair ha scritto: > Hi Mario, > > It looks like the open build has deteriorated, probably while we've > been open sourcing things we haven't been diligent about keeping the > open build up to date (I know I haven't). Now that I'm looking at it, > there are numerous issues: > > - Some of the projects are not declaring dependencies in > project.properties correctly > - The build order in build.xml "dist" target is wrong > - Projects are missing from build.xml "dist" target > > The reason it has built before has been luck -- the projects are out > of order, but they're building anyway because the jfxrt.jar is acting > as a backstop. But if you were to modify sources in one project and > wanted to depend on it from another project, you'd run into these > problems. > > Now that a *lot* of stuff is in the open, I'm trying to build without > linking to jfxrt.jar. I should get pretty far on that. Once the build > is succeeding up to the point it should, then I'll test against a > stripped down jfxrt.jar (that only contains the closed bits) so that I > can make sure the open build is working correctly. I tried to put the openjfxrt.jar into my OpenJDK (and using it instead of the closed jfxrt.jar). I don't get very far, because of some missing classes in the .beans package that are needed right away. I will wait for the new gradle scripts to get in master before attempting again so that we have a more reliable build system to play with. Do you have a list of the things that still need to be open sourced (even as an estimate if you can't disclose the list yet)? Cheers, Mario From richard.bair at oracle.com Fri Feb 8 07:29:21 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 8 Feb 2013 07:29:21 -0800 Subject: How to build openjfx in its current state In-Reply-To: <1360331183.1911.113.camel@pegasus> References: <1360249250.1911.8.camel@pegasus> <986847F1-22C3-4FCD-8C3D-89F0E9FA0FEB@oracle.com> <1360331183.1911.113.camel@pegasus> Message-ID: <827085D1-AB8B-4A4E-AEDD-26E724106EF3@oracle.com> Hi Mario, >> Now that a *lot* of stuff is in the open, I'm trying to build without >> linking to jfxrt.jar. I should get pretty far on that. Once the build >> is succeeding up to the point it should, then I'll test against a >> stripped down jfxrt.jar (that only contains the closed bits) so that I >> can make sure the open build is working correctly. > > I tried to put the openjfxrt.jar into my OpenJDK (and using it instead > of the closed jfxrt.jar). > > I don't get very far, because of some missing classes in the .beans > package that are needed right away. Even though I'm replacing the ant scripts with the gradle scripts, I'm first getting the open ant scripts to work right in part to help me get 100% up to speed on our build process and also so you guys don't have to wait a few weeks while I'm trying to get the new gradle scripts working. I should have it sorted today (famous last words). > Do you have a list of the things that still need to be open sourced > (even as an estimate if you can't disclose the list yet)? These are now open source (yay!): javafx-embed-swing javafx-embed-swt decora-d3d decora-jsw decora-prism decora-prism-ps decora-prism-sw decora-runtime decora-sse javafx-beans These should be out in less than two weeks: glass javafx-iio prism-j2d prism-ps prism-util prism-common prism-sw These we're chasing down the final bits. I would say within a month if all goes well, a couple months if it doesn't. javafx-ui-quantum javafx-ui-webnode webkit webnode-prism javafx-ui-desktop media prism-d3d prism-es2 prism-es2-eglf prism-es2-eglx11 prism-es2-mac prism-es2-win prism-es2-x11 At this point we are ALMOST fully open source. The only remaining nugget (AFAIK!) is javafx-font. This presently relies on T2K. I don't want to plug in FreeType the way we did on the JDK side. Rather, I'd like the open implementation to be a simple thin-wrapper on top of the native APIs, so that we use Pango / Direct2D / Cocoa or whatnot in order to both give us the glyphs to draw and also to do line measurement / complex text layout / etc (right now we rely on a combination of T2K and ICU). The reason we think this will work for us is that with Java 8 we no longer officially support Windows XP, so we can finally leave GDI as our least-common-denominator out. (GDI just couldn't do what we needed, so we had to have our own implementation anyway, so it made sense to just use it across the board). Richard From hang.vo at oracle.com Fri Feb 8 07:47:44 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Feb 2013 15:47:44 +0000 Subject: hg: openjfx/8/controls/rt: RT-25892 : ListView(touch): When scrolling a list, scroll bars are not visible Message-ID: <20130208154747.F039347940@hg.openjdk.java.net> Changeset: 40e12d6e802c Author: mickf Date: 2013-02-08 15:35 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/40e12d6e802c RT-25892 : ListView(touch): When scrolling a list, scroll bars are not visible ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/embedded.css From kevin.rushforth at oracle.com Fri Feb 8 07:57:44 2013 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 08 Feb 2013 07:57:44 -0800 Subject: Using shaders in JavaFX? In-Reply-To: <2A3ACB80-1F85-46B2-9F52-9A433329DEEB@ultramixer.com> References: <2A3ACB80-1F85-46B2-9F52-9A433329DEEB@ultramixer.com> Message-ID: <51152078.1020303@oracle.com> > > What I would like to know is: Is it possible to use (OpenGL) shaders in JavaFX? No, this is not possible. We use shaders internally for rendering, but supporting user-defined shaders is not planned. -- Kevin Tobias Bley wrote: > Hi JavaFX freaks, > > JavaFX is a very wonderful language and we made several tests in porting our Swing based consumer apps to JavaFX - successfully! I love porting to JavaFX :) > > What I would like to know is: Is it possible to use (OpenGL) shaders in JavaFX? > > Best regards, > Tobi > > > > From richard.bair at oracle.com Fri Feb 8 08:31:17 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 8 Feb 2013 08:31:17 -0800 Subject: Using shaders in JavaFX? In-Reply-To: <51152078.1020303@oracle.com> References: <2A3ACB80-1F85-46B2-9F52-9A433329DEEB@ultramixer.com> <51152078.1020303@oracle.com> Message-ID: >> What I would like to know is: Is it possible to use (OpenGL) shaders in JavaFX? > > No, this is not possible. We use shaders internally for rendering, but supporting user-defined shaders is not planned. Well, we've talked about it a lot but it isn't on a roadmap anywhere. Is there a JIRA issue for it? One thing we've talked about was having Shader extend Paint (or Effect). I think maybe if a shader extended Effect it would fit into our system fairly naturally? Of course we're only talking about fragment shaders here. But once we make something like that available I suspect people will also want geometry shaders soon after. Richard From jeff at reportmill.com Fri Feb 8 08:38:15 2013 From: jeff at reportmill.com (Jeff Martin) Date: Fri, 8 Feb 2013 10:38:15 -0600 Subject: 3D or Mobile? In-Reply-To: <51143486.7040400@oracle.com> References: <510C1B8D.4060302@oracle.com> <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> <5112A71A.50502@oracle.com> <5112AD50.1040807@oracle.com> <268F341F-8FCE-4FB5-AB18-A54E873B3931@oracle.com> <5112C19A.7050009@oracle.com> <3ACF3F09-8EF8-4A7A-ACCD-E1D3CB6F141C@oracle.com> <5112C6C0.5020803@oracle.com> <5113692A.8020300@oracle.com> <90D2394C-E9B2-4B9C-898F-DA74A15AAE86@oracle.com> <5113E230.4080302@oracle.com> <51143486.7040400@oracle.com> Message-ID: <2BCEE267-27F2-472C-8D73-B369AE19A52E@reportmill.com> Not to stir things up, and I'm super excited about 3D, but I'm wondering what that meeting was like where the product plan managers said, "Let's not commit to mobile, there's no business case. Now on to 3D!". I'm actually easy to please on the mobile front, I wish Oracle would just say what is probably true: "Worst case for mobile JFX is 2-3 years. We want to get our ducks in a row on the desktop first." My son's middle school is one of these that is rolling out iPads to every student and my wife and I just started a Java/JavaFX computer club for them. Guess what the kids want to know? ;-) jeff From hang.vo at oracle.com Fri Feb 8 08:48:05 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Feb 2013 16:48:05 +0000 Subject: hg: openjfx/8/controls/rt: Modena tweak - added -fx-shadow-highlight-color to SplitMenuButton Message-ID: <20130208164808.B6F1F47944@hg.openjdk.java.net> Changeset: 656c76d07b42 Author: mo.chicharro Date: 2013-02-08 16:45 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/656c76d07b42 Modena tweak - added -fx-shadow-highlight-color to SplitMenuButton ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From richard.bair at oracle.com Fri Feb 8 08:51:38 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 8 Feb 2013 08:51:38 -0800 Subject: 3D or Mobile? In-Reply-To: <2BCEE267-27F2-472C-8D73-B369AE19A52E@reportmill.com> References: <510C1B8D.4060302@oracle.com> <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> <5112A71A.50502@oracle.com> <5112AD50.1040807@oracle.com> <268F341F-8FCE-4FB5-AB18-A54E873B3931@oracle.com> <5112C19A.7050009@oracle.com> <3ACF3F09-8EF8-4A7A-ACCD-E1D3CB6F141C@oracle.com> <5112C6C0.5020803@oracle.com> <5113692A.8020300@oracle.com> <90D2394C-E9B2-4B9C-898F-DA74A15AAE86@oracle.com> <5113E230.4080302@oracle.com> <51143486.7040400@oracle.com> <2BCEE267-27F2-472C-8D73-B369AE19A52E@reportmill.com> Message-ID: > Not to stir things up, and I'm super excited about 3D, but I'm wondering what that meeting was like where the product plan managers said, "Let's not commit to mobile, there's no business case. Now on to 3D!". > > I'm actually easy to please on the mobile front, I wish Oracle would just say what is probably true: "Worst case for mobile JFX is 2-3 years. We want to get our ducks in a row on the desktop first." Probably that is a worst case, but the best case is much, much, better ;-). Richard From jeff at reportmill.com Fri Feb 8 08:57:45 2013 From: jeff at reportmill.com (Jeff Martin) Date: Fri, 8 Feb 2013 10:57:45 -0600 Subject: 3D or Mobile? In-Reply-To: References: <510C1B8D.4060302@oracle.com> <5903E31E-68FA-4BC6-884A-536F27677191@oracle.com> <5112A71A.50502@oracle.com> <5112AD50.1040807@oracle.com> <268F341F-8FCE-4FB5-AB18-A54E873B3931@oracle.com> <5112C19A.7050009@oracle.com> <3ACF3F09-8EF8-4A7A-ACCD-E1D3CB6F141C@oracle.com> <5112C6C0.5020803@oracle.com> <5113692A.8020300@oracle.com> <90D2394C-E9B2-4B9C-898F-DA74A15AAE86@oracle.com> <5113E230.4080302@oracle.com> <51143486.7040400@oracle.com> <2BCEE267-27F2-472C-8D73-B369AE19A52E@reportmill.com> Message-ID: Thank you for that - that's what I tell them (teachers and administrators, too). I don't have to feel guilty saying it anymore, though. :-) jeff On Feb 8, 2013, at 10:51 AM, Richard Bair wrote: >> Not to stir things up, and I'm super excited about 3D, but I'm wondering what that meeting was like where the product plan managers said, "Let's not commit to mobile, there's no business case. Now on to 3D!". >> >> I'm actually easy to please on the mobile front, I wish Oracle would just say what is probably true: "Worst case for mobile JFX is 2-3 years. We want to get our ducks in a row on the desktop first." > > Probably that is a worst case, but the best case is much, much, better ;-). > > Richard From neugens at redhat.com Fri Feb 8 08:59:31 2013 From: neugens at redhat.com (Mario Torre) Date: Fri, 08 Feb 2013 17:59:31 +0100 Subject: Using shaders in JavaFX? In-Reply-To: References: <2A3ACB80-1F85-46B2-9F52-9A433329DEEB@ultramixer.com> <51152078.1020303@oracle.com> Message-ID: <1360342771.1911.118.camel@pegasus> Il giorno ven, 08/02/2013 alle 08.31 -0800, Richard Bair ha scritto: > One thing we've talked about was having Shader extend Paint (or > Effect). I think maybe if a shader extended Effect it would fit into > our system fairly naturally? This seems pretty intuitive too. > Of course we're only talking about fragment shaders here. But once we > make something like that available I suspect people will also want > geometry shaders soon after. Maybe be give an handle to the OpenGL (or DirectX) context for custom rendering? I can see this as a useful feature for embedding OpenGL scenes in JavaFX, but I can also see how many troubles would result from this, so not sure if it's actually a good idea. Cheers, Mario From tom.schindl at bestsolution.at Fri Feb 8 09:02:06 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 08 Feb 2013 18:02:06 +0100 Subject: Using shaders in JavaFX? In-Reply-To: <1360342771.1911.118.camel@pegasus> References: <2A3ACB80-1F85-46B2-9F52-9A433329DEEB@ultramixer.com> <51152078.1020303@oracle.com> <1360342771.1911.118.camel@pegasus> Message-ID: <51152F8E.4010606@bestsolution.at> [...] > Maybe be give an handle to the OpenGL (or DirectX) context for custom > rendering? > > I can see this as a useful feature for embedding OpenGL scenes in > JavaFX, but I can also see how many troubles would result from this, so > not sure if it's actually a good idea. > There was a recent other thread here discussing exactly this kind of thing. Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From neugens at redhat.com Fri Feb 8 09:48:10 2013 From: neugens at redhat.com (Mario Torre) Date: Fri, 08 Feb 2013 18:48:10 +0100 Subject: How to build openjfx in its current state In-Reply-To: <827085D1-AB8B-4A4E-AEDD-26E724106EF3@oracle.com> References: <1360249250.1911.8.camel@pegasus> <986847F1-22C3-4FCD-8C3D-89F0E9FA0FEB@oracle.com> <1360331183.1911.113.camel@pegasus> <827085D1-AB8B-4A4E-AEDD-26E724106EF3@oracle.com> Message-ID: <1360345690.1911.138.camel@pegasus> Il giorno ven, 08/02/2013 alle 07.29 -0800, Richard Bair ha scritto: > At this point we are ALMOST fully open source. The only remaining > nugget (AFAIK!) is javafx-font. This presently relies on T2K. I don't > want to plug in FreeType the way we did on the JDK side. Rather, I'd > like the open implementation to be a simple thin-wrapper on top of the > native APIs, so that we use Pango / Direct2D / Cocoa or whatnot in > order to both give us the glyphs to draw and also to do line > measurement / complex text layout / etc (right now we rely on a > combination of T2K and ICU). The reason we think this will work for us > is that with Java 8 we no longer officially support Windows XP, so we > can finally leave GDI as our least-common-denominator out. (GDI just > couldn't do what we needed, so we had to have our own implementation > anyway, so it made sense to just use it across the board). Great stuff! I think that having a small layer between real backend and JFX makes entirely sense. Maybe we could start looking at it already, even if I suspect you have most of this abstraction in place already (or at least in mind :) so there is probably "little" else to do but implement the actual code with target specific toolkits. Cheers, Mario From hang.vo at oracle.com Fri Feb 8 09:47:57 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Feb 2013 17:47:57 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28298: Remove PGWebView Message-ID: <20130208174800.DFDB34794B@hg.openjdk.java.net> Changeset: bdecfce65a2f Author: Richard Bair Date: 2013-02-08 09:40 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bdecfce65a2f RT-28298: Remove PGWebView - javafx-sg-common/src/com/sun/javafx/sg/PGWebView.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubWebView.java From tom.schindl at bestsolution.at Fri Feb 8 10:56:52 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 08 Feb 2013 19:56:52 +0100 Subject: JemmyFX License Problem Message-ID: <51154A74.8060904@bestsolution.at> Hi, Jemmy itself is released under CDDL but in contrast to that the FX-Extension are only released under GPL this causes problems to me because I can't ship it with e(fx)clipse once it is moved to Eclipse.org, hence people will have a hard time writing Jemmy Unit-Tests. How is Netbeans going to address this problem, are they allowed to ship GPL licensed software with their product? Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From hang.vo at oracle.com Fri Feb 8 11:07:15 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Feb 2013 19:07:15 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130208190721.AD10447955@hg.openjdk.java.net> Changeset: b86a515c40c6 Author: mo.chicharro Date: 2013-02-08 18:58 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b86a515c40c6 Modena tweaks - added new alignment visual showing spacing of arrows from right edge of controls ! apps/experiments/Modena/src/modena/SameHeightTest.fxml Changeset: eeafbb33986a Author: mo.chicharro Date: 2013-02-08 19:00 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/eeafbb33986a Modena tweaks - fix for RT-28299: Spacing of arrows from right edge of controls ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From richard.bair at oracle.com Fri Feb 8 11:07:26 2013 From: richard.bair at oracle.com (Richard Bair) Date: Fri, 8 Feb 2013 11:07:26 -0800 Subject: JemmyFX License Problem In-Reply-To: <51154A74.8060904@bestsolution.at> References: <51154A74.8060904@bestsolution.at> Message-ID: <84B8CA0A-48CB-4143-98AD-12D70FBB7E3A@oracle.com> Good question, I will see what the story is. Richard On Feb 8, 2013, at 10:56 AM, Tom Schindl wrote: > Hi, > > Jemmy itself is released under CDDL but in contrast to that the > FX-Extension are only released under GPL this causes problems to me > because I can't ship it with e(fx)clipse once it is moved to > Eclipse.org, hence people will have a hard time writing Jemmy Unit-Tests. > > How is Netbeans going to address this problem, are they allowed to ship > GPL licensed software with their product? > > Tom > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From hang.vo at oracle.com Fri Feb 8 11:32:49 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Feb 2013 19:32:49 +0000 Subject: hg: openjfx/8/graphics/rt: RT-25524 LOD Helper Message-ID: <20130208193253.9E9D747958@hg.openjdk.java.net> Changeset: 7677be81f484 Author: Yao Wang Date: 2013-02-08 11:17 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7677be81f484 RT-25524 LOD Helper ! javafx-sg-common/src/com/sun/javafx/sg/PGCamera.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGCamera.java ! javafx-ui-common/src/javafx/scene/Camera.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/shape/Cylinder.java ! javafx-ui-common/src/javafx/scene/shape/Sphere.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java From don at donandann.com Fri Feb 8 13:42:58 2013 From: don at donandann.com (Don Corley) Date: Fri, 8 Feb 2013 13:42:58 -0800 Subject: JavaFX support added to Auto-webstart tool Message-ID: JavaFX application support has been added to the open source auto-webstart tool. Auto Web Start is a zero-configuration client for java applications. The javaFX specific instructions are here: http://www.jbundle.org/jbundle/auto-webstart/javafx.html It works with an OSGi server to assemble dependencies and deliver them to a web browser. You don't have to do any preparation, just package your classes in jar files, install them in an OSGi server and supply the main javaFX application class: http://www.jbundle.org/webstart/docs/javafx.html?appletClass=org.jbundle.javafx.example.helloworld.HelloWorldJavaFXApp The auto web start tool deploys using javaFX javascript, creates the web start jnlp file, does a pack200/gzip on your jars and delivers them to the client. If you use OBR, it will automatically download and install all your dependencies. Take a look and tell me what you think. Thanks, Don From hang.vo at oracle.com Fri Feb 8 14:48:12 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 08 Feb 2013 22:48:12 +0000 Subject: hg: openjfx/8/controls/rt: RT-21094: move Styleable to javafx.css package Message-ID: <20130208224814.3444547961@hg.openjdk.java.net> Changeset: 372e8ef0a10d Author: David Grieve Date: 2013-02-08 17:37 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/372e8ef0a10d RT-21094: move Styleable to javafx.css package ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java ! javafx-ui-charts/src/javafx/scene/chart/Chart.java ! javafx-ui-charts/src/javafx/scene/chart/LineChart.java ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java ! javafx-ui-charts/src/javafx/scene/chart/StackedAreaChart.java ! javafx-ui-charts/src/javafx/scene/chart/StackedBarChart.java ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java ! javafx-ui-common/src/com/sun/javafx/css/CssError.java ! javafx-ui-common/src/com/sun/javafx/css/StyleConverterImpl.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java - javafx-ui-common/src/com/sun/javafx/css/Styleable.java ! javafx-ui-common/src/com/sun/javafx/css/converters/FontConverter.java ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java ! javafx-ui-common/src/javafx/css/CssMetaData.java ! javafx-ui-common/src/javafx/css/FontCssMetaData.java ! javafx-ui-common/src/javafx/css/SimpleStyleableBooleanProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableDoubleProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableFloatProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableIntegerProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableLongProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableObjectProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableStringProperty.java + javafx-ui-common/src/javafx/css/Styleable.java ! javafx-ui-common/src/javafx/css/StyleableProperty.java ! javafx-ui-common/src/javafx/css/package.html ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/src/javafx/scene/layout/Background.java ! javafx-ui-common/src/javafx/scene/layout/BackgroundConverter.java ! javafx-ui-common/src/javafx/scene/layout/Border.java ! javafx-ui-common/src/javafx/scene/layout/BorderConverter.java ! javafx-ui-common/src/javafx/scene/layout/FlowPane.java ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/src/javafx/scene/layout/HBox.java ! javafx-ui-common/src/javafx/scene/layout/Region.java ! javafx-ui-common/src/javafx/scene/layout/StackPane.java ! javafx-ui-common/src/javafx/scene/layout/TilePane.java ! javafx-ui-common/src/javafx/scene/layout/VBox.java ! javafx-ui-common/src/javafx/scene/shape/Rectangle.java ! javafx-ui-common/src/javafx/scene/shape/Shape.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/src/javafx/scene/text/TextFlow.java ! javafx-ui-common/test/unit/com/sun/javafx/css/CssMetaDataTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/TestNode.java ! javafx-ui-common/test/unit/com/sun/javafx/css/TestNodeBase.java ! javafx-ui-common/test/unit/com/sun/javafx/test/CssMethodsTestBase.java ! javafx-ui-common/test/unit/javafx/scene/CSSNode.java ! javafx-ui-common/test/unit/javafx/scene/Node_effectiveOrientation_Css_Test.java ! javafx-ui-common/test/unit/javafx/scene/Node_onInvalidate_Test.java ! javafx-ui-common/test/unit/javafx/scene/shape/ShapeTest.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CellSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledImpl.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/javafx/scene/chart/Axis.java ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java ! javafx-ui-controls/src/javafx/scene/chart/NumberAxis.java ! javafx-ui-controls/src/javafx/scene/chart/ValueAxis.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/MenuBar.java ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/ScrollBar.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java ! javafx-ui-controls/src/javafx/scene/control/Separator.java ! javafx-ui-controls/src/javafx/scene/control/SkinBase.java ! javafx-ui-controls/src/javafx/scene/control/Slider.java ! javafx-ui-controls/src/javafx/scene/control/SplitPane.java ! javafx-ui-controls/src/javafx/scene/control/Tab.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TableColumnBase.java ! javafx-ui-controls/src/javafx/scene/control/TextArea.java ! javafx-ui-controls/src/javafx/scene/control/TextField.java ! javafx-ui-controls/src/javafx/scene/control/TextInputControl.java ! javafx-ui-controls/src/javafx/scene/control/TitledPane.java ! javafx-ui-controls/src/javafx/scene/control/ToolBar.java ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabeledImplTest.java ! javafx-ui-controls/test/javafx/scene/control/ControlTest.java From hang.vo at oracle.com Fri Feb 8 16:48:05 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 09 Feb 2013 00:48:05 +0000 Subject: hg: openjfx/8/graphics/rt: RT-23818: com.sun.javafx.geom Area and Rectangle classes define equals() method but not hashCode() Message-ID: <20130209004809.DA7A147966@hg.openjdk.java.net> Changeset: afe9c4479408 Author: Felipe Heidrich Date: 2013-02-08 16:44 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/afe9c4479408 RT-23818: com.sun.javafx.geom Area and Rectangle classes define equals() method but not hashCode() ! javafx-geom/cagsrc.double/com/sun/javafx/geom/Area.java ! javafx-geom/src/com/sun/javafx/geom/Rectangle.java From hang.vo at oracle.com Fri Feb 8 17:48:08 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 09 Feb 2013 01:48:08 +0000 Subject: hg: openjfx/8/graphics/rt: Fix of build scripts for the open source builds. People should now be able to build successfully using ant on OpenJFX (see updated wiki for latest). Message-ID: <20130209014810.921A747969@hg.openjdk.java.net> Changeset: d448980b1a24 Author: rbair Date: 2013-02-08 17:37 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d448980b1a24 Fix of build scripts for the open source builds. People should now be able to build successfully using ant on OpenJFX (see updated wiki for latest). ! build-decora.xml ! build-defs.xml ! build.xml ! common.properties + decora-compiler/build-closed.xml + decora-compiler/build-common.xml ! decora-compiler/build.xml ! decora-compiler/project.properties + decora-d3d/build-closed.xml + decora-d3d/build-common.xml ! decora-d3d/build.xml + decora-es2/build-closed.xml + decora-es2/build-common.xml ! decora-es2/build.xml + decora-jsw/build-closed.xml + decora-jsw/build-common.xml ! decora-jsw/build.xml + decora-prism-ps/build-closed.xml + decora-prism-ps/build-common.xml ! decora-prism-ps/build.xml ! decora-prism-ps/project.properties + decora-prism-sw/build-closed.xml + decora-prism-sw/build-common.xml ! decora-prism-sw/build.xml ! decora-prism-sw/project.properties + decora-prism/build-closed.xml + decora-prism/build-common.xml ! decora-prism/build.xml ! decora-prism/project.properties + decora-runtime/build-closed.xml + decora-runtime/build-common.xml ! decora-runtime/build.xml ! decora-runtime/project.properties + decora-sse/build-closed.xml + decora-sse/build-common.xml ! decora-sse/build.xml ! decora-sse/project.properties ! javafx-anim/project.properties ! javafx-annotation-processor/build-common.xml ! javafx-annotation-processor/project.properties ! javafx-beans-dt/build-common.xml ! javafx-beans-dt/build.xml ! javafx-beans-dt/project.properties ! javafx-beans/project.properties ! javafx-concurrent/build-closed.xml ! javafx-concurrent/build-common.xml ! javafx-concurrent/build.xml ! javafx-concurrent/project.properties ! javafx-designtime/project.properties ! javafx-embed-swing/project.properties ! javafx-fxml/project.properties ! javafx-geom/build-closed.xml ! javafx-sg-common/build-closed.xml ! javafx-sg-common/project.properties ! javafx-sg-prism/build-closed.xml ! javafx-sg-prism/build-common.xml ! javafx-sg-prism/build.xml ! javafx-sg-prism/project.properties ! javafx-ui-charts/project.properties ! javafx-ui-common/build.xml ! javafx-ui-common/project.properties ! javafx-ui-controls/project.properties ! javafx-util-converter/project.properties ! pisces/build-closed.xml ! pisces/build-common.xml ! pisces/build.xml ! pisces/project.properties ! test-stub-toolkit/project.properties From hang.vo at oracle.com Sat Feb 9 23:33:23 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sun, 10 Feb 2013 07:33:23 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28308: decora-d3d classes not included in jfxrt.jar Message-ID: <20130210073331.258F147985@hg.openjdk.java.net> Changeset: 03cc45b0c481 Author: rbair Date: 2013-02-09 23:14 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/03cc45b0c481 RT-28308: decora-d3d classes not included in jfxrt.jar Summary: updated the build-closed file to determine correctly whether on windows and therefore whether to compile the d3d classes. Verified the fix by inspecting the jar after compilation to ensure the files are there. ! decora-d3d/build-closed.xml From hang.vo at oracle.com Sun Feb 10 07:33:50 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sun, 10 Feb 2013 15:33:50 +0000 Subject: hg: openjfx/8/graphics/rt: Fix RT-27951 - Enable Virtual keyboard only for touch devices (depending on ConditionalFeature.VIRTUAL_KEYBOARD) Message-ID: <20130210153356.BE27E47988@hg.openjdk.java.net> Changeset: a69414a64ca8 Author: Seeon Birger Date: 2013-02-10 17:40 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a69414a64ca8 Fix RT-27951 - Enable Virtual keyboard only for touch devices (depending on ConditionalFeature.VIRTUAL_KEYBOARD) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java From sven.reimers at gmail.com Sun Feb 10 09:58:26 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Sun, 10 Feb 2013 18:58:26 +0100 Subject: Node and prefWidthProperty Message-ID: Hi all, any special reason why there is not a prefWidthProperty on Node, although it has a prefWidth? 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 From hang.vo at oracle.com Mon Feb 11 00:25:56 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Feb 2013 08:25:56 +0000 Subject: hg: openjfx/8/graphics/rt: RT-9383: Event constructors finalized. Message-ID: <20130211082558.AE67F4799B@hg.openjdk.java.net> Changeset: c8109f961d4d Author: Pavel Safrata Date: 2013-02-11 08:16 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c8109f961d4d RT-9383: Event constructors finalized. ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/DragEvent.java ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/KeyEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseDragEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java ! javafx-ui-common/src/javafx/scene/input/RotateEvent.java ! javafx-ui-common/src/javafx/scene/input/ScrollEvent.java ! javafx-ui-common/src/javafx/scene/input/SwipeEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchPoint.java ! javafx-ui-common/src/javafx/scene/input/ZoomEvent.java ! javafx-ui-common/test/unit/com/sun/javafx/test/MouseEventGenerator.java ! javafx-ui-common/test/unit/javafx/scene/input/DragAndDropTest.java ! javafx-ui-common/test/unit/javafx/scene/input/MouseDragEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/MouseEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/TouchEventTest.java From lehmann at media-interactive.de Mon Feb 11 01:27:57 2013 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 11 Feb 2013 10:27:57 +0100 Subject: SceneBuilder src, or how to drag/size controls In-Reply-To: <5110143F.6060405@oracle.com> References: <51100F7E.2010603@media-interactive.de> <5110143F.6060405@oracle.com> Message-ID: <5118B99D.2080809@media-interactive.de> Hi, I have been experimenting with a few approaches on this, looks like I need a custom layout container which allows users to select, move, and resize child controls at runtime. So far, the best approach seems to be to extend Region, filter on mouse events, and keep track of a "selected" child control. This control would get a special styleclass to show the selection border, e.g. .selectedborder { -fx-border-width: 6; -fx-border-color: lightgray; -fx-border-insets: -6; } Two problems with this: 1. Removing the selectedborder styleclass does not remove the border. I actually have to switch to another styleclass to achieve this. Is this how it is supposed to be? I am afraid of removing any borders unrelated to the "selection": .unselectedborder { -fx-border-width: 0; -fx-border-color: lightgray; -fx-border-insets: -0; } 2. The approach won't work with anything not in the Region hierarchy which introduces the border styling. So for any Shape I am not getting a selection border. I guess this would change with FX8 then? Alternatively, the selection border could be implemented by wrapping each child into a "layout private" AnchorPane - but that would expose a modified parent/child hierarchy to the outside which I'd like to avoid because node selection is an implementation detail. Rgds Werner On 04.02.2013 21:04, Jonathan Giles wrote: > I can't speak to the first part of your email, but regarding resizing > standard controls: as of JavaFX 8.0 Control extends from Region, so > whilst I haven't tested Andrew's code, this should theoretically work. > It would be worth testing, anyway :-) > > -- Jonathan From hang.vo at oracle.com Mon Feb 11 02:18:09 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Feb 2013 10:18:09 +0000 Subject: hg: openjfx/8/graphics/rt: Fix for RT-26745: Clean up initialization of QuantumClipboard Message-ID: <20130211101814.4DA0D4799F@hg.openjdk.java.net> Changeset: 6d112cd51f1b Author: Artem Ananiev Date: 2013-02-11 14:02 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6d112cd51f1b Fix for RT-26745: Clean up initialization of QuantumClipboard Reviewed-by: Alexey Utkin, Pavel Safrata ! javafx-ui-common/src/com/sun/javafx/tk/TKClipboard.java ! javafx-ui-common/src/com/sun/javafx/tk/TKDragGestureListener.java ! javafx-ui-common/src/com/sun/javafx/tk/TKDragSourceListener.java ! javafx-ui-common/src/com/sun/javafx/tk/TKDropTargetListener.java ! javafx-ui-common/src/com/sun/javafx/tk/TKScene.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/Clipboard.java ! javafx-ui-common/src/javafx/scene/input/Dragboard.java ! javafx-ui-common/test/unit/javafx/scene/input/DragAndDropTest.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubScene.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java From richard.bair at oracle.com Mon Feb 11 07:42:48 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 11 Feb 2013 07:42:48 -0800 Subject: Node and prefWidthProperty In-Reply-To: References: Message-ID: <2BE87E75-1E02-4323-B957-0F135199D054@oracle.com> Yes! In fact there is no prefWidth property on Node (no getPrefWidth, setPrefWidth, or prefWidthProperty). Rather the prefWidth() method is a computational method vs. an accessor. If you look at Region, you will find prefWidthProperty(), getPrefWidth(), and setPrefWidth (along with min width, max width, min height, max height, etc). The prefWidth() method will inspect the prefWidth property, minWidth property, maxWidth property etc and compute what the pref width for this node is at this time. Now, perhaps the question could be, why don't we have a computedPrefWidth property on node? I suspect it has to do with two things. First, the bindings associated with such a thing on a layout container would be pretty intense. That's not necessarily saying it couldn't be done ("its all software" as Hans Muller used to say -- we can do anything -- for a price). However I expect it would be difficult. The second reason is because we want to make it easy for subclasses to override the computation of the prefWidth (as each layout container for example have their own algorithm for figuring this out). As such, having method to override is much simpler than binding that has to be broken and reestablished (although again, not impossible). I'm guessing what you're wanting is a way to know when the pref size has changed? Richard On Feb 10, 2013, at 9:58 AM, Sven Reimers wrote: > Hi all, > > any special reason why there is not a prefWidthProperty on Node, although > it has a prefWidth? > > 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 From richard.bair at oracle.com Mon Feb 11 08:03:29 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 11 Feb 2013 08:03:29 -0800 Subject: SceneBuilder src, or how to drag/size controls In-Reply-To: <5118B99D.2080809@media-interactive.de> References: <51100F7E.2010603@media-interactive.de> <5110143F.6060405@oracle.com> <5118B99D.2080809@media-interactive.de> Message-ID: <4AE90B62-703D-4F52-8CB0-1538C091922F@oracle.com> > 1. Removing the selectedborder styleclass does not remove the border. I actually have to switch to another styleclass to achieve this. Is this how it is supposed to be? I am afraid of removing any borders unrelated to the "selection": That sounds like a bug to me. If David has power (he's under snow on the east coast) then I'd like to get his input (likely already a known issue and perhaps fixed in the latest). > 2. The approach won't work with anything not in the Region hierarchy which introduces the border styling. So for any Shape I am not getting a selection border. I guess this would change with FX8 then? > > Alternatively, the selection border could be implemented by wrapping each child into a "layout private" AnchorPane - but that would expose a modified parent/child hierarchy to the outside which I'd like to avoid because node selection is an implementation detail. The other issue is that if you have a Circle for instance you will get a rectangular selection instead of a circular selection. I don't know that this would work for you, but also there might be the option of applying an outer glow effect to the selected node. If you can't change the effect property on the node itself, then wrapping it in a group is probably the best option. Richard From david.grieve at oracle.com Mon Feb 11 08:32:59 2013 From: david.grieve at oracle.com (David Grieve) Date: Mon, 11 Feb 2013 11:32:59 -0500 Subject: SceneBuilder src, or how to drag/size controls In-Reply-To: <4AE90B62-703D-4F52-8CB0-1538C091922F@oracle.com> References: <51100F7E.2010603@media-interactive.de> <5110143F.6060405@oracle.com> <5118B99D.2080809@media-interactive.de> <4AE90B62-703D-4F52-8CB0-1538C091922F@oracle.com> Message-ID: On Feb 11, 2013, at 11:03 AM, Richard Bair wrote: >> 1. Removing the selectedborder styleclass does not remove the border. I actually have to switch to another styleclass to achieve this. Is this how it is supposed to be? I am afraid of removing any borders unrelated to the "selection": > > That sounds like a bug to me. If David has power (he's under snow on the east coast) then I'd like to get his input (likely already a known issue and perhaps fixed in the latest). > This is a bug. There is a similar bug http://javafx-jira.kenai.com/browse/RT-19264. From sven.reimers at gmail.com Mon Feb 11 09:09:25 2013 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 11 Feb 2013 18:09:25 +0100 Subject: Node and prefWidthProperty In-Reply-To: <2BE87E75-1E02-4323-B957-0F135199D054@oracle.com> References: <2BE87E75-1E02-4323-B957-0F135199D054@oracle.com> Message-ID: Yes, I probably want to know about all the changes of width / height (bind to them). I can do a check if my Node is a Region and use the properties there, but I thought it would be more consistent if those were available straight from Node. Thanks Sven On Mon, Feb 11, 2013 at 4:42 PM, Richard Bair wrote: > Yes! In fact there is no prefWidth property on Node (no getPrefWidth, > setPrefWidth, or prefWidthProperty). Rather the prefWidth() method is a > computational method vs. an accessor. > > If you look at Region, you will find prefWidthProperty(), getPrefWidth(), > and setPrefWidth (along with min width, max width, min height, max height, > etc). > > The prefWidth() method will inspect the prefWidth property, minWidth > property, maxWidth property etc and compute what the pref width for this > node is at this time. > > Now, perhaps the question could be, why don't we have a computedPrefWidth > property on node? I suspect it has to do with two things. First, the > bindings associated with such a thing on a layout container would be pretty > intense. That's not necessarily saying it couldn't be done ("its all > software" as Hans Muller used to say -- we can do anything -- for a price). > However I expect it would be difficult. The second reason is because we > want to make it easy for subclasses to override the computation of the > prefWidth (as each layout container for example have their own algorithm > for figuring this out). As such, having method to override is much simpler > than binding that has to be broken and reestablished (although again, not > impossible). > > I'm guessing what you're wanting is a way to know when the pref size has > changed? > > Richard > > On Feb 10, 2013, at 9:58 AM, Sven Reimers wrote: > > > Hi all, > > > > any special reason why there is not a prefWidthProperty on Node, although > > it has a prefWidth? > > > > 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 > > -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * NetBeans Governance Board Member: http://netbeans.org/about/os/governance.html * 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 From lehmann at media-interactive.de Mon Feb 11 09:57:15 2013 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 11 Feb 2013 18:57:15 +0100 Subject: SceneBuilder src, or how to drag/size controls In-Reply-To: References: <51100F7E.2010603@media-interactive.de> <5110143F.6060405@oracle.com> <5118B99D.2080809@media-interactive.de> <4AE90B62-703D-4F52-8CB0-1538C091922F@oracle.com> Message-ID: <511930FB.8040204@media-interactive.de> Here's another similar bug: http://javafx-jira.kenai.com/browse/RT-19089 How do those borders add up when they are defined in different styleclasses? On one styleclass I could define X borders - are those completely separated from another styleclass with Y borders? Apparently not so since I could remove the "selected" border with an "unselected" styleclass. But then I could damage any other border. Maybe borders from inherited styles are unaffected here... Werner On 11.02.2013 17:32, David Grieve wrote: > > On Feb 11, 2013, at 11:03 AM, Richard Bair > wrote: > >>> 1. Removing the selectedborder styleclass does not remove the >>> border. I actually have to switch to another styleclass to >>> achieve this. Is this how it is supposed to be? I am afraid of >>> removing any borders unrelated to the "selection": >> >> That sounds like a bug to me. If David has power (he's under snow >> on the east coast) then I'd like to get his input (likely already a >> known issue and perhaps fixed in the latest). >> > > This is a bug. There is a similar bug > http://javafx-jira.kenai.com/browse/RT-19264. From lehmann at media-interactive.de Mon Feb 11 10:07:06 2013 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 11 Feb 2013 19:07:06 +0100 Subject: SceneBuilder src, or how to drag/size controls In-Reply-To: <4AE90B62-703D-4F52-8CB0-1538C091922F@oracle.com> References: <51100F7E.2010603@media-interactive.de> <5110143F.6060405@oracle.com> <5118B99D.2080809@media-interactive.de> <4AE90B62-703D-4F52-8CB0-1538C091922F@oracle.com> Message-ID: <5119334A.6070501@media-interactive.de> True. I guess I'd be fine with rectangular selection borders only, for now. Using an effect is a nice idea, in order to get around the "borders only on Region" restriction. I am sure it could be parameterized to look like a selection. Unfortunately I also need drag markers for resizing (4x in the corners and 4x in between) and that might be a bit difficult to do with an effect. Another alternative: show selection border and drag markers in a transparent "floating" click-through Region (not unlike a glasspane), always positioned on top of the "selected" node. Bindings could be used to keep the position of the selection in sync with the position of the "selected" node underneath. Theoretically this is the best option since I am not changing the parent/child hierarchy on contained nodes in the layout, and I don't depend on CSS available only on Regions. Still have to see how it works out. Werner On 11.02.2013 17:03, Richard Bair wrote: > The other issue is that if you have a Circle for instance you will > get a rectangular selection instead of a circular selection. > > I don't know that this would work for you, but also there might be > the option of applying an outer glow effect to the selected node. If > you can't change the effect property on the node itself, then > wrapping it in a group is probably the best option. > > Richard From david.grieve at oracle.com Mon Feb 11 10:10:29 2013 From: david.grieve at oracle.com (David Grieve) Date: Mon, 11 Feb 2013 13:10:29 -0500 Subject: SceneBuilder src, or how to drag/size controls In-Reply-To: <511930FB.8040204@media-interactive.de> References: <51100F7E.2010603@media-interactive.de> <5110143F.6060405@oracle.com> <5118B99D.2080809@media-interactive.de> <4AE90B62-703D-4F52-8CB0-1538C091922F@oracle.com> <511930FB.8040204@media-interactive.de> Message-ID: The styles would only affect those nodes that have those style classes. You cannot do damage to any other border. If you remove the "selected" style-class and then add the "unselected", you should be fine. On Feb 11, 2013, at 12:57 PM, Werner Lehmann wrote: > Here's another similar bug: http://javafx-jira.kenai.com/browse/RT-19089 > > How do those borders add up when they are defined in different styleclasses? On one styleclass I could define X borders - are those completely separated from another styleclass with Y borders? Apparently not so since I could remove the "selected" border with an "unselected" styleclass. But then I could damage any other border. Maybe borders from inherited styles are unaffected here... > > Werner > > On 11.02.2013 17:32, David Grieve wrote: >> >> On Feb 11, 2013, at 11:03 AM, Richard Bair >> wrote: >> >>>> 1. Removing the selectedborder styleclass does not remove the >>>> border. I actually have to switch to another styleclass to >>>> achieve this. Is this how it is supposed to be? I am afraid of >>>> removing any borders unrelated to the "selection": >>> >>> That sounds like a bug to me. If David has power (he's under snow >>> on the east coast) then I'd like to get his input (likely already a >>> known issue and perhaps fixed in the latest). >>> >> >> This is a bug. There is a similar bug >> http://javafx-jira.kenai.com/browse/RT-19264. > From hang.vo at oracle.com Mon Feb 11 11:03:44 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Feb 2013 19:03:44 +0000 Subject: hg: openjfx/8/graphics/rt: Renamed printing unit test directory. Message-ID: <20130211190346.E325B479AF@hg.openjdk.java.net> Changeset: b10019f7ff27 Author: jgodinez Date: 2013-02-11 10:58 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b10019f7ff27 Renamed printing unit test directory. ! javafx-ui-common/project.properties + javafx-ui-common/test/unit/test/javafx/print/JobSettingsTest.java + javafx-ui-common/test/unit/test/javafx/print/PrinterJobTest.java - javafx-ui-common/test/unit/test/javax/print/JobSettingsTest.java - javafx-ui-common/test/unit/test/javax/print/PrinterJobTest.java From hang.vo at oracle.com Mon Feb 11 15:48:02 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 11 Feb 2013 23:48:02 +0000 Subject: hg: openjfx/8/graphics/rt: Fix to RT-28303: Use TempState rather than instance variables for projtx and viewport needed by LOD helper method. Message-ID: <20130211234806.87492479B9@hg.openjdk.java.net> Changeset: cc3702cbc8a0 Author: Chien Yang Date: 2013-02-11 15:31 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/cc3702cbc8a0 Fix to RT-28303: Use TempState rather than instance variables for projtx and viewport needed by LOD helper method. Approved by Kevin ! javafx-ui-common/src/com/sun/javafx/TempState.java ! javafx-ui-common/src/javafx/scene/Node.java From hang.vo at oracle.com Mon Feb 11 17:03:27 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Feb 2013 01:03:27 +0000 Subject: hg: openjfx/8/controls/rt: RT-25533 : Menu javadoc & RT-26576 ColorPicker RGB components get incorrect value. Message-ID: <20130212010337.3203A479BD@hg.openjdk.java.net> Changeset: f437c9bdc79f Author: Paru Somashekar Date: 2013-02-11 16:58 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f437c9bdc79f RT-25533 : Menu javadoc & RT-26576 ColorPicker RGB components get incorrect value. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java ! javafx-ui-controls/src/javafx/scene/control/Menu.java From hang.vo at oracle.com Mon Feb 11 18:03:16 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Feb 2013 02:03:16 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130212020324.0EBB9479C0@hg.openjdk.java.net> Changeset: dafee5d5fe66 Author: Chien Yang Date: 2013-02-11 17:46 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dafee5d5fe66 Fixed to RT-27113: Netbeans project dependency information got lost .... Approved by Richard. ! javafx-geom/project.properties ! javafx-sg-common/project.properties ! javafx-sg-prism/project.properties ! javafx-ui-common/project.properties Changeset: 91891157486b Author: rbair Date: 2013-02-11 17:50 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/91891157486b RT-28344: NonNull annotation is unused and should be removed ! build.gradle - javafx-beans/src/com/sun/javafx/beans/annotations/NonNull.java From hang.vo at oracle.com Mon Feb 11 18:03:53 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Feb 2013 02:03:53 +0000 Subject: hg: openjfx/8/controls/rt: 10 new changesets Message-ID: <20130212020413.D46D5479C1@hg.openjdk.java.net> Changeset: e4464b4f804c Author: jgiles Date: 2013-02-07 10:39 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e4464b4f804c RT-28016: JAVAFX TABLEVIEW .SORTING ARROW SHIFTS TO THE WRONG COLUMN ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java Changeset: 4f89dec868cb Author: jgiles Date: 2013-02-07 13:56 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4f89dec868cb RT-28250: [TreeView, TreeTableView] expand/collapse arrows have a mind of their own ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java Changeset: 9b02ded253ac Author: jgiles Date: 2013-02-07 16:22 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9b02ded253ac Minor tweaks to combat RT-28213: 8.0-controls-scrum-287: memory leak in ComboBox. Unfortunately the perf regression is to undo a functional regression, so there isn't much more that can be done here. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxBaseSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java Changeset: 5b785c886979 Author: jgiles Date: 2013-02-08 09:39 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5b785c886979 RT-24916: TableView.scrollTo(TableColumn) Review-by: jgiles Contributed-by: Tom Schindl ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualContainerBase.java ! javafx-ui-controls/src/javafx/scene/control/ControlUtils.java ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java ! javafx-ui-controls/src/javafx/scene/control/ScrollToEvent.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java Changeset: e6475877a2cc Author: jgiles Date: 2013-02-08 10:55 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e6475877a2cc RT-27585: [TreeTableView] Changes in editable cell are not commited. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java Changeset: ba8319f15c9b Author: jgiles Date: 2013-02-08 13:38 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ba8319f15c9b RT-22716: Scene graph elements are not garbage collected (Memory Leak) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java Changeset: f6a082cf07a3 Author: jgiles Date: 2013-02-11 13:21 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f6a082cf07a3 RT-27966: TabPane setTabMaxWidth hides close button ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java Changeset: d46f39fd37eb Author: jgiles Date: 2013-02-11 13:53 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d46f39fd37eb RT-27606: [TreeTableView] Double click on editable collapses the row. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java Changeset: cee06e42e4f3 Author: jgiles Date: 2013-02-11 14:58 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/cee06e42e4f3 RT-27820: ListView selectionModel selectedItems list returns incorrect size ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: 722cc3746842 Author: jgiles Date: 2013-02-12 14:33 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/722cc3746842 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java From hang.vo at oracle.com Mon Feb 11 20:33:42 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Feb 2013 04:33:42 +0000 Subject: hg: openjfx/8/controls/rt: 3 new changesets Message-ID: <20130212043348.D544B479C7@hg.openjdk.java.net> Changeset: ea4b9aedce67 Author: "Jasper Potts" Date: 2013-02-11 20:21 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ea4b9aedce67 Modena: tweek to body gradient ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 5d7d7686a2c3 Author: "Jasper Potts" Date: 2013-02-11 20:21 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5d7d7686a2c3 Modena: test app netbeans project updates ! apps/experiments/Modena/nbproject/build-impl.xml ! apps/experiments/Modena/nbproject/configs/Run_as_WebStart.properties ! apps/experiments/Modena/nbproject/configs/Run_in_Browser.properties ! apps/experiments/Modena/nbproject/genfiles.properties ! apps/experiments/Modena/nbproject/jfx-impl.xml + apps/experiments/Modena/nbproject/jfx-impl_backup_1.xml ! apps/experiments/Modena/nbproject/project.properties ! apps/experiments/Modena/src/modena/TestApp.css Changeset: 13ee6aa1865f Author: "Jasper Potts" Date: 2013-02-11 20:30 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/13ee6aa1865f MADE MODENA DEFAULT THEME. If there are issues with this change, it can easily be backed out by changing line 474 of com.sun.javafx.application.PlatformImpl back to Caspian. ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java From hang.vo at oracle.com Tue Feb 12 12:33:38 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 12 Feb 2013 20:33:38 +0000 Subject: hg: openjfx/8/controls/rt: [TEST-ONLY] syntax error in modena.css caused some failures. Added @Ignore to tests that still failed and created bugs for removing the @Ignore. Also changed build script to convert modena.css to modena.bss Message-ID: <20130212203342.A8076479F0@hg.openjdk.java.net> Changeset: 2275a38d56ca Author: David Grieve Date: 2013-02-12 15:28 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2275a38d56ca [TEST-ONLY] syntax error in modena.css caused some failures. Added @Ignore to tests that still failed and created bugs for removing the @Ignore. Also changed build script to convert modena.css to modena.bss ! javafx-ui-controls/build-common.xml ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css ! javafx-ui-controls/test/javafx/scene/control/AccordionTest.java ! javafx-ui-controls/test/javafx/scene/control/ColorPickerTest.java From martin.lang at zeiss.com Tue Feb 12 13:04:29 2013 From: martin.lang at zeiss.com (Martin Lang) Date: Tue, 12 Feb 2013 22:04:29 +0100 Subject: =?ISO-8859-1?Q?AUTO=3A_Martin_Lang_is_out_of_the_office_=28R=FCckkehr_am?= =?ISO-8859-1?B?DQogIDEzLjAyLjIwMTMp?= Message-ID: Ich bin bis 13.02.2013 abwesend. Dear Sender, I am out of office on Feb 12th with no access to email. Thanks, Dr. Martin Lang _________________ Carl Zeiss Meditec AG Standort/Location M?nchen Product Manager Retina Imaging Dr.-Ing. M a r t i n L a n g phone: +49 (0)89 909000-105 fax: +49 (0)89 909000-222 mobile: +49 (0)151 62 85 46 97 mailto: martin.lang at meditec.zeiss.com http://www.meditec.zeiss.com Carl Zeiss Meditec AG, Standort/Location M?nchen, Kistlerhofstr. 75, 81379 M?nchen Vorsitzender des Aufsichtsrates: Dr. Michael Kaschke Vorstand: Dr. Ludwin Monz (Vorsitzender), Dr. Christian M?ller, Thomas Simmerer Sitz der Gesellschaft: 07745 Jena, Deutschland Amtsgericht Jena HRB 205623, USt-IdNr: DE 811 922 737 Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht "openjfx-dev Digest, Vol 15, Issue 40" gesendet am 12.02.2013 21:00:00. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, w?hrend diese Person abwesend ist. ---------------------------------------- This message is intended for a particular addressee only and may contain business or company secrets. If you have received this email in error, please contact the sender and delete the message immediately. Any use of this email, including saving, publishing, copying, replication or forwarding of the message or the contents is not permitted. From tom.schindl at bestsolution.at Tue Feb 12 14:56:43 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 12 Feb 2013 23:56:43 +0100 Subject: LayoutPass on each keypress, mouseclick, ... Message-ID: <511AC8AB.3090606@bestsolution.at> Hi, While debugging a FX-JIRA I've instrumented TextAreaSkin and saw that every keystroke, leads to relayout. > java.lang.Exception: Stack trace > at java.lang.Thread.dumpStack(Thread.java:1345) > at com.sun.javafx.scene.control.skin.TextAreaSkin.computeMinWidth(TextAreaSkin.java:774) > at javafx.scene.control.Control.computeMinWidth(Control.java:442) > at javafx.scene.Parent.minWidth(Parent.java:887) > at javafx.scene.layout.Region.minWidth(Region.java:1135) > at javafx.scene.layout.Region.layoutInArea(Region.java:1818) > at javafx.scene.layout.Region.layoutInArea(Region.java:1785) > at javafx.scene.layout.Region.layoutInArea(Region.java:1726) > at javafx.scene.layout.StackPane.layoutChildren(StackPane.java:337) > at javafx.scene.Parent.layout(Parent.java:1014) > at javafx.scene.Scene.layoutDirtyRoots(Scene.java:537) > at javafx.scene.Scene.doLayoutPass(Scene.java:508) > at javafx.scene.Scene.access$25(Scene.java:505) > at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2193) > at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:347) > at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:524) > at com.sun.javafx.tk.quantum.QuantumToolkit$12.run(QuantumToolkit.java:377) > at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(Unknown Source) Is this really needed? Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From hang.vo at oracle.com Tue Feb 12 21:48:41 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Feb 2013 05:48:41 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130213054847.55EE247A10@hg.openjdk.java.net> Changeset: 7dc3847a8025 Author: David Grieve Date: 2013-02-12 23:29 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7dc3847a8025 RT-21094: need to mark some impl_ methods as deprecated ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java Changeset: 103768088c59 Author: David Grieve Date: 2013-02-13 00:35 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/103768088c59 [TEST-ONLY] Add @Ignore to StackedAreaChartTest and StackedBarChartTest pending RT-28373 ! javafx-ui-charts/test/javafx/scene/chart/StackedAreaChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/StackedBarChartTest.java From hang.vo at oracle.com Wed Feb 13 01:33:01 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Feb 2013 09:33:01 +0000 Subject: hg: openjfx/8/graphics/rt: RT-26789: toString overriden for shapes. Message-ID: <20130213093307.C4AC447A13@hg.openjdk.java.net> Changeset: 0db334c76977 Author: Pavel Safrata Date: 2013-02-13 09:22 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0db334c76977 RT-26789: toString overriden for shapes. ! javafx-ui-common/src/javafx/scene/shape/Arc.java ! javafx-ui-common/src/javafx/scene/shape/ArcTo.java ! javafx-ui-common/src/javafx/scene/shape/Circle.java ! javafx-ui-common/src/javafx/scene/shape/ClosePath.java ! javafx-ui-common/src/javafx/scene/shape/CubicCurve.java ! javafx-ui-common/src/javafx/scene/shape/CubicCurveTo.java ! javafx-ui-common/src/javafx/scene/shape/Ellipse.java ! javafx-ui-common/src/javafx/scene/shape/HLineTo.java ! javafx-ui-common/src/javafx/scene/shape/Line.java ! javafx-ui-common/src/javafx/scene/shape/LineTo.java ! javafx-ui-common/src/javafx/scene/shape/MoveTo.java ! javafx-ui-common/src/javafx/scene/shape/Path.java ! javafx-ui-common/src/javafx/scene/shape/Polygon.java ! javafx-ui-common/src/javafx/scene/shape/Polyline.java ! javafx-ui-common/src/javafx/scene/shape/QuadCurve.java ! javafx-ui-common/src/javafx/scene/shape/QuadCurveTo.java ! javafx-ui-common/src/javafx/scene/shape/Rectangle.java ! javafx-ui-common/src/javafx/scene/shape/SVGPath.java ! javafx-ui-common/src/javafx/scene/shape/VLineTo.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/test/unit/javafx/scene/shape/ArcTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/ArcToTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/CircleTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/ClosePathTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/CubicCurveTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/CubicCurveToTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/EllipseTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/HLineToTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/LineTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/LineToTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/MoveToTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/PathTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/PolygonTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/PolylineTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/QuadCurveTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/QuadCurveToTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/RectangleTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/SVGPathTest.java ! javafx-ui-common/test/unit/javafx/scene/shape/VLineToTest.java ! javafx-ui-common/test/unit/javafx/scene/text/TextTest.java From hang.vo at oracle.com Wed Feb 13 02:18:45 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Feb 2013 10:18:45 +0000 Subject: hg: openjfx/8/graphics/rt: Picking optimizations (RT-5475): single PickRay instance reused, no temporary parent-to-local transforms, deltaTransform instead of add-transform-subtract, fast path for pick rays perpendicular to the XY plane Message-ID: <20130213101850.E66A647A16@hg.openjdk.java.net> Changeset: 897ef4f2b18e Author: Pavel Safrata Date: 2013-02-13 10:05 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/897ef4f2b18e Picking optimizations (RT-5475): single PickRay instance reused, no temporary parent-to-local transforms, deltaTransform instead of add-transform-subtract, fast path for pick rays perpendicular to the XY plane ! javafx-geom/src/com/sun/javafx/geom/PickRay.java ! javafx-geom/src/com/sun/javafx/geom/transform/Affine3D.java ! javafx-geom/src/com/sun/javafx/geom/transform/AffineBase.java ! javafx-geom/src/com/sun/javafx/geom/transform/BaseTransform.java ! javafx-geom/src/com/sun/javafx/geom/transform/Identity.java ! javafx-geom/src/com/sun/javafx/geom/transform/Translate2D.java ! javafx-ui-common/src/javafx/scene/Node.java From krueger at lesspain.de Wed Feb 13 02:40:05 2013 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Wed, 13 Feb 2013 11:40:05 +0100 Subject: Big thank you!!! Message-ID: for this: http://fxexperience.com/2013/02/february-open-source-update/ I am quite convinced that this can be the game changer for Java/JFX as a client platform because it makes it so much more attractive from a commercial and organizational point of view to decide to develop using this technology despite possible maturity problems on the way and having more people throw more use cases at JFX will make it mature faster. Just great! Thanks to everyone at oracle lobbying for that decision! Robert From johan at lodgon.com Wed Feb 13 02:56:15 2013 From: johan at lodgon.com (Johan Vos) Date: Wed, 13 Feb 2013 11:56:15 +0100 Subject: Big thank you!!! In-Reply-To: References: Message-ID: +1 2013/2/13 Robert Kr?ger > for this: http://fxexperience.com/2013/02/february-open-source-update/ > > I am quite convinced that this can be the game changer for Java/JFX as > a client platform because it makes it so much more attractive from a > commercial and organizational point of view to decide to develop using > this technology despite possible maturity problems on the way and > having more people throw more use cases at JFX will make it mature > faster. > > Just great! Thanks to everyone at oracle lobbying for that decision! > > Robert > From hendrik.ebbers at me.com Wed Feb 13 04:31:47 2013 From: hendrik.ebbers at me.com (Hendrik Ebbers) Date: Wed, 13 Feb 2013 12:31:47 +0000 (GMT) Subject: Big thank you!!! In-Reply-To: Message-ID: +1 Am 13. Februar 2013 um 11:56 schrieb Johan Vos : +1 2013/2/13 Robert Kr?ger > for this: http://fxexperience.com/2013/02/february-open-source-update/ > > I am quite convinced that this can be the game changer for Java/JFX as > a client platform because it makes it so much more attractive from a > commercial and organizational point of view to decide to develop using > this technology despite possible maturity problems on the way and > having more people throw more use cases at JFX will make it mature > faster. > > Just great! Thanks to everyone at oracle lobbying for that decision! > > Robert > From hang.vo at oracle.com Wed Feb 13 04:47:54 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Feb 2013 12:47:54 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130213124801.7578D47A1A@hg.openjdk.java.net> Changeset: 6dabd87c27d6 Author: mo.chicharro Date: 2013-02-13 12:36 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6dabd87c27d6 Modena tweaks - Added TitledPane to SameHeightTest.fxml for height comparison ! apps/experiments/Modena/src/modena/SameHeightTest.fxml Changeset: 14dda2ac593b Author: mo.chicharro Date: 2013-02-13 12:37 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/14dda2ac593b Modena Tweaks - Adjusted height of TitledPane ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From tbee at tbee.org Wed Feb 13 05:01:50 2013 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 13 Feb 2013 14:01:50 +0100 Subject: Big thank you!!! In-Reply-To: References: Message-ID: <511B8EBE.2020906@tbee.org> ++1 On 2013-02-13 13:31, Hendrik Ebbers wrote: > +1 > > Am 13. Februar 2013 um 11:56 schrieb Johan Vos : > > +1 > > 2013/2/13 Robert Kr?ger > >> for this: http://fxexperience.com/2013/02/february-open-source-update/ >> >> I am quite convinced that this can be the game changer for Java/JFX as >> a client platform because it makes it so much more attractive from a >> commercial and organizational point of view to decide to develop using >> this technology despite possible maturity problems on the way and >> having more people throw more use cases at JFX will make it mature >> faster. >> >> Just great! Thanks to everyone at oracle lobbying for that decision! >> >> Robert >> From jeff at reportmill.com Wed Feb 13 05:05:54 2013 From: jeff at reportmill.com (Jeff Martin) Date: Wed, 13 Feb 2013 07:05:54 -0600 Subject: Big thank you!!! In-Reply-To: References: Message-ID: I agree! It's getting some coverage, too! http://www.theregister.co.uk/2013/02/12/open_source_javafx_for_mobile/ http://www.javaworld.com/community/?q=node/10354 Great work, highly appreciated! jeff On Feb 13, 2013, at 4:40 AM, Robert Kr?ger wrote: > for this: http://fxexperience.com/2013/02/february-open-source-update/ > > I am quite convinced that this can be the game changer for Java/JFX as > a client platform because it makes it so much more attractive from a > commercial and organizational point of view to decide to develop using > this technology despite possible maturity problems on the way and > having more people throw more use cases at JFX will make it mature > faster. > > Just great! Thanks to everyone at oracle lobbying for that decision! > > Robert From hang.vo at oracle.com Wed Feb 13 15:17:44 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Wed, 13 Feb 2013 23:17:44 +0000 Subject: hg: openjfx/8/graphics/rt: [ECLIPSE ONLY] fix classpath webnode and media are optional Message-ID: <20130213231748.A17D947A5E@hg.openjdk.java.net> Changeset: b9eda00f7c4a Author: Felipe Heidrich Date: 2013-02-13 15:04 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b9eda00f7c4a [ECLIPSE ONLY] fix classpath webnode and media are optional ! .classpath From hang.vo at oracle.com Wed Feb 13 17:04:16 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Feb 2013 01:04:16 +0000 Subject: hg: openjfx/8/controls/rt: 38 new changesets Message-ID: <20130214010536.4C1E547A61@hg.openjdk.java.net> Changeset: c97dc773b5a4 Author: David Grieve Date: 2013-02-13 16:37 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c97dc773b5a4 RT-28391: set default platform to caspian. backed out @Ignore on unit test that failed due to modena. ! javafx-ui-charts/test/javafx/scene/chart/StackedAreaChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/StackedBarChartTest.java ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-controls/test/javafx/scene/control/AccordionTest.java ! javafx-ui-controls/test/javafx/scene/control/ColorPickerTest.java Changeset: d39f91a06d08 Author: hudson Date: 2013-02-07 14:40 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d39f91a06d08 Added tag 8.0-b76 for changeset 27a5dff62edc ! .hgtags Changeset: a2a4de77db5f Author: David Grieve Date: 2013-02-07 15:34 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a2a4de77db5f [TEST ONLY] RT-28273: disable Node_effectiveOrientation_Css_Test ! javafx-ui-common/test/unit/javafx/scene/Node_effectiveOrientation_Css_Test.java Changeset: 591738b789c3 Author: David Grieve Date: 2013-02-07 19:00 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/591738b789c3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt Changeset: 110d447262ce Author: Felipe Heidrich Date: 2013-02-05 13:33 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/110d447262ce [ECLIPSE_ONLY] javafx-beans & embedded swt open sourcing ! .classpath Changeset: 7132b587bdfb Author: David Hill Date: 2013-02-05 17:21 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7132b587bdfb RT-27891 Multithreading issues in Quantum between user thread and rendering thread. ! javafx-sg-prism/test/com/sun/javafx/sg/prism/TestGraphics.java Changeset: 7500b8ef6c34 Author: flar Date: 2013-02-05 16:30 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7500b8ef6c34 Ignore all webrev related files in .hgignore ! .hgignore Changeset: ac6952f8fee4 Author: rbair Date: 2013-02-05 17:45 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ac6952f8fee4 RT-28230: Media and Web need to be factored out of Prism - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGMediaView.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGNode.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/PrismMediaFrameHandler.java ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: a0b4e4f589b5 Author: rbair Date: 2013-02-05 18:40 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a0b4e4f589b5 Partial RT-28089: Write Script to auto-generate the new repository layout Summary: Moved javafx-beans and javafx-embed-swing and javafx-embed-swt to the public gradle generator ! build.gradle ! generator.gradle Changeset: 6af9a14ae71a Author: Martin Sladecek Date: 2013-02-06 13:22 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6af9a14ae71a RT-26799 Implementation of the hasProperties() method of the Node class ! javafx-ui-common/src/javafx/scene/Node.java Changeset: 811c479d634b Author: Artem Ananiev Date: 2013-02-06 20:00 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/811c479d634b Fix for RT-27209: Build failure in rt/deploy on Windows with VS2010 Express ! deploy/packager/winlauncher/javafxpackager.rc Changeset: f94ae4f94775 Author: Felipe Heidrich Date: 2013-02-06 11:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f94ae4f94775 [fix css warnings] fix missing semicolon in css files ! apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/SchedulerStyleSheet.css ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/VirtualFlowTest.css Changeset: beb638445101 Author: rbair Date: 2013-02-06 16:15 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/beb638445101 [TEST ONLY] Updated Service tests -- made thread daemon, closed off running threads when done, and ignored the security manager test which appears to be bogus. ! javafx-concurrent/test/javafx/concurrent/ServiceLifecycleTest.java ! javafx-concurrent/test/javafx/concurrent/ServiceTestBase.java ! javafx-concurrent/test/javafx/concurrent/ServiceWithSecurityManagerTest.java Changeset: c6fb5c694336 Author: Richard Bair Date: 2013-02-06 17:42 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c6fb5c694336 Updated copyright headers on decora-compiler .g and .stg files ! decora-compiler/src/com/sun/scenario/effect/compiler/JSL.g ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/jogl/JOGLGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/rsl/RSLGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/prism/PrismGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MEJavaGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MENativeGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSEJavaGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSENativeGlue.stg Changeset: 74bb20d3b013 Author: Richard Bair Date: 2013-02-06 18:19 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/74bb20d3b013 Fixed Pagination* copyright headers ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/PaginationBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java Changeset: e1971713872e Author: Martin Sladecek Date: 2013-02-07 08:54 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e1971713872e Renamed AnimationMock in javafx-ui-common to avoid name clash with AnimationMock in javafx-anim + javafx-ui-common/test/unit/javafx/animation/AnimationDummy.java - javafx-ui-common/test/unit/javafx/animation/AnimationMock.java ! javafx-ui-common/test/unit/javafx/animation/ParallelTransitionTest.java ! javafx-ui-common/test/unit/javafx/animation/SequentialTransitionTest.java Changeset: 07a0f071ae9b Author: Martin Sladecek Date: 2013-02-07 09:47 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/07a0f071ae9b merge - javafx-ui-common/test/unit/javafx/animation/AnimationMock.java Changeset: 3919f556c448 Author: Pavel Safrata Date: 2013-02-07 13:19 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3919f556c448 RT-28028: Affine internal state was broken after unsuccessful invert. ! javafx-ui-common/src/javafx/scene/transform/Affine.java ! javafx-ui-common/test/unit/javafx/scene/transform/AffineOperationsTest.java Changeset: ee1e4c0502d4 Author: jgodinez Date: 2013-02-07 08:37 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ee1e4c0502d4 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGMediaView.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/PrismMediaFrameHandler.java ! javafx-ui-common/src/javafx/scene/Node.java - javafx-ui-common/test/unit/javafx/animation/AnimationMock.java Changeset: 7507d0eacf70 Author: rbair Date: 2013-02-07 13:14 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7507d0eacf70 RT-28274: Open Source Decora Projects Summary: Moved Decora to open source + build-decora.xml ! build.gradle + decora-d3d/build.xml + decora-d3d/decora-d3d.iml + decora-d3d/nbproject/project.xml + decora-d3d/project.properties + decora-d3d/src/com/sun/scenario/effect/impl/hw/d3d/D3DShaderSource.java + decora-es2/build.xml + decora-es2/decora-es2.iml + decora-es2/nbproject/project.xml + decora-es2/project.properties + decora-es2/src/com/sun/scenario/effect/impl/es2/ES2ShaderSource.java + decora-jsw/build.xml + decora-jsw/decora-jsw.iml + decora-jsw/nbproject/project.xml + decora-jsw/project.properties + decora-jsw/src/com/sun/scenario/effect/impl/sw/java/JSWBoxBlurPeer.java + decora-jsw/src/com/sun/scenario/effect/impl/sw/java/JSWBoxShadowPeer.java + decora-jsw/src/com/sun/scenario/effect/impl/sw/java/JSWEffectPeer.java + decora-jsw/src/com/sun/scenario/effect/impl/sw/java/JSWLinearConvolvePeer.java + decora-jsw/src/com/sun/scenario/effect/impl/sw/java/JSWLinearConvolveShadowPeer.java + decora-jsw/src/com/sun/scenario/effect/impl/sw/java/JSWRendererDelegate.java + decora-prism-ps/build.xml + decora-prism-ps/decora-prism-ps.iml + decora-prism-ps/nbproject/project.xml + decora-prism-ps/project.properties + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPSDrawable.java + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPSEffectPeer.java + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPSOneSamplerPeer.java + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPSRenderer.java + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPSTwoSamplerPeer.java + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPSZeroSamplerPeer.java + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPStoPSWDisplacementMapPeer.java + decora-prism-sw/build.xml + decora-prism-sw/decora-prism-sw.iml + decora-prism-sw/nbproject/project.xml + decora-prism-sw/project.properties + decora-prism-sw/src/com/sun/scenario/effect/impl/prism/sw/PSWDrawable.java + decora-prism-sw/src/com/sun/scenario/effect/impl/prism/sw/PSWRenderer.java + decora-prism/build.xml + decora-prism/decora-prism.iml + decora-prism/nbproject/project.xml + decora-prism/project.properties + decora-prism/src/com/sun/scenario/effect/impl/prism/PrCropPeer.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrDrawable.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrEffectHelper.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrFilterContext.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrFloodPeer.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrImage.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrMergePeer.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrReflectionPeer.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrRenderInfo.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrRenderer.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrTexture.java + decora-runtime/build.xml + decora-runtime/decora-runtime.iml + decora-runtime/generator/CompileBlend.java + decora-runtime/generator/CompileBoxBlur.java + decora-runtime/generator/CompileExternal.java + decora-runtime/generator/CompileGaussian.java + decora-runtime/generator/CompileJSL.java + decora-runtime/generator/CompileLinearConvolve.java + decora-runtime/generator/CompilePhong.java + decora-runtime/generator/CompileZoomRadialBlur.java + decora-runtime/jsl/Blend.jsl + decora-runtime/jsl/Blend_ADD.jsl + decora-runtime/jsl/Blend_BLUE.jsl + decora-runtime/jsl/Blend_COLOR_BURN.jsl + decora-runtime/jsl/Blend_COLOR_DODGE.jsl + decora-runtime/jsl/Blend_DARKEN.jsl + decora-runtime/jsl/Blend_DIFFERENCE.jsl + decora-runtime/jsl/Blend_EXCLUSION.jsl + decora-runtime/jsl/Blend_GREEN.jsl + decora-runtime/jsl/Blend_HARD_LIGHT.jsl + decora-runtime/jsl/Blend_LIGHTEN.jsl + decora-runtime/jsl/Blend_MULTIPLY.jsl + decora-runtime/jsl/Blend_OVERLAY.jsl + decora-runtime/jsl/Blend_RED.jsl + decora-runtime/jsl/Blend_SCREEN.jsl + decora-runtime/jsl/Blend_SOFT_LIGHT.jsl + decora-runtime/jsl/Blend_SRC_ATOP.jsl + decora-runtime/jsl/Blend_SRC_IN.jsl + decora-runtime/jsl/Blend_SRC_OUT.jsl + decora-runtime/jsl/Blend_SRC_OVER.jsl + decora-runtime/jsl/BoxBlur.jsl + decora-runtime/jsl/Brightpass.jsl + decora-runtime/jsl/ColorAdjust.jsl + decora-runtime/jsl/DisplacementMap.jsl + decora-runtime/jsl/GaussianBlur.jsl + decora-runtime/jsl/InvertMask.jsl + decora-runtime/jsl/LinearConvolve.jsl + decora-runtime/jsl/LinearConvolveShadow.jsl + decora-runtime/jsl/PerspectiveTransform.jsl + decora-runtime/jsl/PhongLighting.jsl + decora-runtime/jsl/SepiaTone.jsl + decora-runtime/jsl/ZoomRadialBlur.jsl + decora-runtime/nbproject/project.xml + decora-runtime/project.properties + decora-runtime/src/com/sun/scenario/effect/AbstractShadow.java + decora-runtime/src/com/sun/scenario/effect/Blend.java + decora-runtime/src/com/sun/scenario/effect/Bloom.java + decora-runtime/src/com/sun/scenario/effect/BoxBlur.java + decora-runtime/src/com/sun/scenario/effect/BoxShadow.java + decora-runtime/src/com/sun/scenario/effect/Brightpass.java + decora-runtime/src/com/sun/scenario/effect/Color4f.java + decora-runtime/src/com/sun/scenario/effect/ColorAdjust.java + decora-runtime/src/com/sun/scenario/effect/CoreEffect.java + decora-runtime/src/com/sun/scenario/effect/Crop.java + decora-runtime/src/com/sun/scenario/effect/DelegateEffect.java + decora-runtime/src/com/sun/scenario/effect/DisplacementMap.java + decora-runtime/src/com/sun/scenario/effect/DropShadow.java + decora-runtime/src/com/sun/scenario/effect/Effect.java + decora-runtime/src/com/sun/scenario/effect/FilterContext.java + decora-runtime/src/com/sun/scenario/effect/FilterEffect.java + decora-runtime/src/com/sun/scenario/effect/Filterable.java + decora-runtime/src/com/sun/scenario/effect/FloatMap.java + decora-runtime/src/com/sun/scenario/effect/Flood.java + decora-runtime/src/com/sun/scenario/effect/GaussianBlur.java + decora-runtime/src/com/sun/scenario/effect/GaussianShadow.java + decora-runtime/src/com/sun/scenario/effect/GeneralShadow.java + decora-runtime/src/com/sun/scenario/effect/Glow.java + decora-runtime/src/com/sun/scenario/effect/Identity.java + decora-runtime/src/com/sun/scenario/effect/ImageData.java + decora-runtime/src/com/sun/scenario/effect/ImageDataRenderer.java + decora-runtime/src/com/sun/scenario/effect/InnerShadow.java + decora-runtime/src/com/sun/scenario/effect/InvertMask.java + decora-runtime/src/com/sun/scenario/effect/Merge.java + decora-runtime/src/com/sun/scenario/effect/MotionBlur.java + decora-runtime/src/com/sun/scenario/effect/Offset.java + decora-runtime/src/com/sun/scenario/effect/PerspectiveTransform.java + decora-runtime/src/com/sun/scenario/effect/PhongLighting.java + decora-runtime/src/com/sun/scenario/effect/Reflection.java + decora-runtime/src/com/sun/scenario/effect/SepiaTone.java + decora-runtime/src/com/sun/scenario/effect/ZoomRadialBlur.java + decora-runtime/src/com/sun/scenario/effect/impl/BufferUtil.java + decora-runtime/src/com/sun/scenario/effect/impl/EffectPeer.java + decora-runtime/src/com/sun/scenario/effect/impl/HeapImage.java + decora-runtime/src/com/sun/scenario/effect/impl/ImagePool.java + decora-runtime/src/com/sun/scenario/effect/impl/Renderer.java + decora-runtime/src/com/sun/scenario/effect/impl/RendererFactory.java + decora-runtime/src/com/sun/scenario/effect/impl/hw/Drawable.java + decora-runtime/src/com/sun/scenario/effect/impl/hw/RendererDelegate.java + decora-runtime/src/com/sun/scenario/effect/impl/hw/Shader.java + decora-runtime/src/com/sun/scenario/effect/impl/hw/ShaderSource.java + decora-runtime/src/com/sun/scenario/effect/impl/hw/Texture.java + decora-runtime/src/com/sun/scenario/effect/impl/state/AccessHelper.java + decora-runtime/src/com/sun/scenario/effect/impl/state/BoxBlurState.java + decora-runtime/src/com/sun/scenario/effect/impl/state/BoxShadowState.java + decora-runtime/src/com/sun/scenario/effect/impl/state/GaussianBlurState.java + decora-runtime/src/com/sun/scenario/effect/impl/state/GaussianShadowState.java + decora-runtime/src/com/sun/scenario/effect/impl/state/HVSeparableKernel.java + decora-runtime/src/com/sun/scenario/effect/impl/state/LinearConvolveKernel.java + decora-runtime/src/com/sun/scenario/effect/impl/state/LinearConvolvePeer.java + decora-runtime/src/com/sun/scenario/effect/impl/state/LinearConvolveShadowPeer.java + decora-runtime/src/com/sun/scenario/effect/impl/state/MotionBlurState.java + decora-runtime/src/com/sun/scenario/effect/impl/state/PerspectiveTransformState.java + decora-runtime/src/com/sun/scenario/effect/impl/state/ZoomRadialBlurState.java + decora-runtime/src/com/sun/scenario/effect/impl/sw/RendererDelegate.java + decora-runtime/src/com/sun/scenario/effect/light/DistantLight.java + decora-runtime/src/com/sun/scenario/effect/light/Light.java + decora-runtime/src/com/sun/scenario/effect/light/PointLight.java + decora-runtime/src/com/sun/scenario/effect/light/SpotLight.java + decora-runtime/test/com/sun/scenario/effect/Test1.java + decora-runtime/test/com/sun/scenario/effect/Test2.java + decora-runtime/test/com/sun/scenario/effect/rt_5239/RT_5239Test.java + decora-runtime/testjsl/Test1.jsl + decora-runtime/testjsl/Test2.jsl + decora-sse-native/Makefile + decora-sse-native/SSEBoxBlurPeer.cc + decora-sse-native/SSEBoxShadowPeer.cc + decora-sse-native/SSELinearConvolvePeer.cc + decora-sse-native/SSELinearConvolveShadowPeer.cc + decora-sse-native/SSEUtils.cc + decora-sse-native/SSEUtils.h + decora-sse-native/nbproject/Makefile-Debug.mk + decora-sse-native/nbproject/Makefile-Release.mk + decora-sse-native/nbproject/Makefile-impl.mk + decora-sse-native/nbproject/configurations.xml + decora-sse-native/nbproject/project.xml + decora-sse/build-macosx.xml + decora-sse/build-windows.xml + decora-sse/build.xml + decora-sse/decora-sse.iml + decora-sse/nbproject/project.xml + decora-sse/project.properties + decora-sse/src/com/sun/scenario/effect/impl/sw/sse/SSEBoxBlurPeer.java + decora-sse/src/com/sun/scenario/effect/impl/sw/sse/SSEBoxShadowPeer.java + decora-sse/src/com/sun/scenario/effect/impl/sw/sse/SSEEffectPeer.java + decora-sse/src/com/sun/scenario/effect/impl/sw/sse/SSELinearConvolvePeer.java + decora-sse/src/com/sun/scenario/effect/impl/sw/sse/SSELinearConvolveShadowPeer.java + decora-sse/src/com/sun/scenario/effect/impl/sw/sse/SSERendererDelegate.java ! generator.gradle ! javafx-ui-controls/src/javafx/scene/control/Pagination.java Changeset: 14da6e9bbcfe Author: rbair Date: 2013-02-07 14:57 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/14da6e9bbcfe Updated project properties to point to local directories instead of in rt-closed. Oops. ! decora-d3d/project.properties ! decora-es2/project.properties ! decora-jsw/project.properties ! decora-prism-ps/project.properties ! decora-prism-sw/project.properties ! decora-prism/project.properties ! decora-sse/project.properties Changeset: f5dae05e32d8 Author: rbair Date: 2013-02-07 15:52 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f5dae05e32d8 Additional path errors. What I did wrong was not update the build-closed.xml files of projects referring to decora. I also need to adjust the decora projects so they have a build-closed.xml file. I will update the project to make sure it builds for open source devs separately. ! javafx-sg-common/build-closed.xml ! javafx-sg-prism/build-closed.xml ! javafx-ui-charts/project.properties ! javafx-ui-common/build-closed.xml ! test-stub-toolkit/build-closed.xml ! test-stub-toolkit/project.properties Changeset: 610dbac8d6fc Author: Felipe Heidrich Date: 2013-02-07 16:13 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/610dbac8d6fc [ECLIPSE ONLY] fixing classpath for decora ! .classpath Changeset: 4446f7960af3 Author: kcr Date: 2013-02-07 16:35 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/4446f7960af3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGMediaView.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/PrismMediaFrameHandler.java - javafx-ui-common/test/unit/javafx/animation/AnimationMock.java Changeset: 0f328860af65 Author: kcr Date: 2013-02-07 17:13 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/0f328860af65 RT-17401: 3D geometry support -- initial commit, only d3d is implemented Contributed-by: jada - javafx-geom/src/com/sun/javafx/geom/CameraImpl.java - javafx-geom/src/com/sun/javafx/geom/ParallelCameraImpl.java - javafx-geom/src/com/sun/javafx/geom/PerspectiveCameraImpl.java ! javafx-geom/src/com/sun/javafx/geom/PickRay.java ! javafx-geom/src/com/sun/javafx/geom/transform/GeneralTransform3D.java + javafx-sg-common/src/com/sun/javafx/sg/PGAmbientLight.java + javafx-sg-common/src/com/sun/javafx/sg/PGBox.java + javafx-sg-common/src/com/sun/javafx/sg/PGCamera.java + javafx-sg-common/src/com/sun/javafx/sg/PGCylinder.java + javafx-sg-common/src/com/sun/javafx/sg/PGLightBase.java + javafx-sg-common/src/com/sun/javafx/sg/PGMeshView.java + javafx-sg-common/src/com/sun/javafx/sg/PGParallelCamera.java + javafx-sg-common/src/com/sun/javafx/sg/PGPerspectiveCamera.java + javafx-sg-common/src/com/sun/javafx/sg/PGPhongMaterial.java + javafx-sg-common/src/com/sun/javafx/sg/PGPointLight.java + javafx-sg-common/src/com/sun/javafx/sg/PGShape3D.java + javafx-sg-common/src/com/sun/javafx/sg/PGSphere.java + javafx-sg-common/src/com/sun/javafx/sg/PGTriangleMesh.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGAmbientLight.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGBox.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGCamera.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGCylinder.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGGroup.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGLightBase.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGMeshView.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGNode.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGParallelCamera.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGPerspectiveCamera.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGPhongMaterial.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGPointLight.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGRegion.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGShape3D.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGSphere.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGTriangleMesh.java ! javafx-sg-prism/test/com/sun/javafx/sg/prism/TestGraphics.java ! javafx-ui-common/src/com/sun/javafx/scene/DirtyBits.java ! javafx-ui-common/src/com/sun/javafx/scene/EnteredExitedHandler.java ! javafx-ui-common/src/com/sun/javafx/scene/input/InputEventUtils.java + javafx-ui-common/src/com/sun/javafx/scene/input/PickResultChooser.java ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/TKScene.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java + javafx-ui-common/src/javafx/scene/AmbientLight.java ! javafx-ui-common/src/javafx/scene/Camera.java + javafx-ui-common/src/javafx/scene/LightBase.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/ParallelCamera.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/PerspectiveCamera.java + javafx-ui-common/src/javafx/scene/PointLight.java ! javafx-ui-common/src/javafx/scene/Scene.java + javafx-ui-common/src/javafx/scene/SubScene.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java ! javafx-ui-common/src/javafx/scene/input/DragEvent.java ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/KeyEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseDragEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java + javafx-ui-common/src/javafx/scene/input/PickResult.java ! javafx-ui-common/src/javafx/scene/input/RotateEvent.java ! javafx-ui-common/src/javafx/scene/input/ScrollEvent.java ! javafx-ui-common/src/javafx/scene/input/SwipeEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchPoint.java ! javafx-ui-common/src/javafx/scene/input/ZoomEvent.java ! javafx-ui-common/src/javafx/scene/layout/Region.java + javafx-ui-common/src/javafx/scene/paint/Material.java + javafx-ui-common/src/javafx/scene/paint/PhongMaterial.java + javafx-ui-common/src/javafx/scene/shape/Box.java + javafx-ui-common/src/javafx/scene/shape/CullFace.java + javafx-ui-common/src/javafx/scene/shape/Cylinder.java + javafx-ui-common/src/javafx/scene/shape/DrawMode.java + javafx-ui-common/src/javafx/scene/shape/Mesh.java + javafx-ui-common/src/javafx/scene/shape/MeshView.java + javafx-ui-common/src/javafx/scene/shape/PredefinedMeshManager.java + javafx-ui-common/src/javafx/scene/shape/Shape3D.java + javafx-ui-common/src/javafx/scene/shape/Sphere.java + javafx-ui-common/src/javafx/scene/shape/TriangleMesh.java ! javafx-ui-common/test/unit/javafx/scene/MouseTest.java + javafx-ui-common/test/unit/javafx/scene/MouseTest3D.java ! javafx-ui-common/test/unit/javafx/scene/NodeTest.java ! javafx-ui-common/test/unit/javafx/scene/Scenegraph_eventHandlers_Test.java ! javafx-ui-common/test/unit/javafx/scene/input/ContextMenuEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/DragAndDropTest.java ! javafx-ui-common/test/unit/javafx/scene/input/MouseDragEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/RotateEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/ScrollEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/SwipeEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/TestNode.java ! javafx-ui-common/test/unit/javafx/scene/input/TouchEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/ZoomEventTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ScrollPaneSkinTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/VirtualFlowTest.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubBox.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubCylinder.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubMeshView.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubScene.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubShape3D.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubSphere.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubTriangleMesh.java Changeset: bdecfce65a2f Author: Richard Bair Date: 2013-02-08 09:40 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/bdecfce65a2f RT-28298: Remove PGWebView - javafx-sg-common/src/com/sun/javafx/sg/PGWebView.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubWebView.java Changeset: 7677be81f484 Author: Yao Wang Date: 2013-02-08 11:17 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/7677be81f484 RT-25524 LOD Helper ! javafx-sg-common/src/com/sun/javafx/sg/PGCamera.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGCamera.java ! javafx-ui-common/src/javafx/scene/Camera.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/shape/Cylinder.java ! javafx-ui-common/src/javafx/scene/shape/Sphere.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: afe9c4479408 Author: Felipe Heidrich Date: 2013-02-08 16:44 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/afe9c4479408 RT-23818: com.sun.javafx.geom Area and Rectangle classes define equals() method but not hashCode() ! javafx-geom/cagsrc.double/com/sun/javafx/geom/Area.java ! javafx-geom/src/com/sun/javafx/geom/Rectangle.java Changeset: d448980b1a24 Author: rbair Date: 2013-02-08 17:37 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d448980b1a24 Fix of build scripts for the open source builds. People should now be able to build successfully using ant on OpenJFX (see updated wiki for latest). ! build-decora.xml ! build-defs.xml ! build.xml ! common.properties + decora-compiler/build-closed.xml + decora-compiler/build-common.xml ! decora-compiler/build.xml ! decora-compiler/project.properties + decora-d3d/build-closed.xml + decora-d3d/build-common.xml ! decora-d3d/build.xml + decora-es2/build-closed.xml + decora-es2/build-common.xml ! decora-es2/build.xml + decora-jsw/build-closed.xml + decora-jsw/build-common.xml ! decora-jsw/build.xml + decora-prism-ps/build-closed.xml + decora-prism-ps/build-common.xml ! decora-prism-ps/build.xml ! decora-prism-ps/project.properties + decora-prism-sw/build-closed.xml + decora-prism-sw/build-common.xml ! decora-prism-sw/build.xml ! decora-prism-sw/project.properties + decora-prism/build-closed.xml + decora-prism/build-common.xml ! decora-prism/build.xml ! decora-prism/project.properties + decora-runtime/build-closed.xml + decora-runtime/build-common.xml ! decora-runtime/build.xml ! decora-runtime/project.properties + decora-sse/build-closed.xml + decora-sse/build-common.xml ! decora-sse/build.xml ! decora-sse/project.properties ! javafx-anim/project.properties ! javafx-annotation-processor/build-common.xml ! javafx-annotation-processor/project.properties ! javafx-beans-dt/build-common.xml ! javafx-beans-dt/build.xml ! javafx-beans-dt/project.properties ! javafx-beans/project.properties ! javafx-concurrent/build-closed.xml ! javafx-concurrent/build-common.xml ! javafx-concurrent/build.xml ! javafx-concurrent/project.properties ! javafx-designtime/project.properties ! javafx-embed-swing/project.properties ! javafx-fxml/project.properties ! javafx-geom/build-closed.xml ! javafx-sg-common/build-closed.xml ! javafx-sg-common/project.properties ! javafx-sg-prism/build-closed.xml ! javafx-sg-prism/build-common.xml ! javafx-sg-prism/build.xml ! javafx-sg-prism/project.properties ! javafx-ui-charts/project.properties ! javafx-ui-common/build.xml ! javafx-ui-common/project.properties ! javafx-ui-controls/project.properties ! javafx-util-converter/project.properties ! pisces/build-closed.xml ! pisces/build-common.xml ! pisces/build.xml ! pisces/project.properties ! test-stub-toolkit/project.properties Changeset: 03cc45b0c481 Author: rbair Date: 2013-02-09 23:14 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/03cc45b0c481 RT-28308: decora-d3d classes not included in jfxrt.jar Summary: updated the build-closed file to determine correctly whether on windows and therefore whether to compile the d3d classes. Verified the fix by inspecting the jar after compilation to ensure the files are there. ! decora-d3d/build-closed.xml Changeset: a69414a64ca8 Author: Seeon Birger Date: 2013-02-10 17:40 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a69414a64ca8 Fix RT-27951 - Enable Virtual keyboard only for touch devices (depending on ConditionalFeature.VIRTUAL_KEYBOARD) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java Changeset: c8109f961d4d Author: Pavel Safrata Date: 2013-02-11 08:16 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c8109f961d4d RT-9383: Event constructors finalized. ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/DragEvent.java ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/KeyEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseDragEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java ! javafx-ui-common/src/javafx/scene/input/RotateEvent.java ! javafx-ui-common/src/javafx/scene/input/ScrollEvent.java ! javafx-ui-common/src/javafx/scene/input/SwipeEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchPoint.java ! javafx-ui-common/src/javafx/scene/input/ZoomEvent.java ! javafx-ui-common/test/unit/com/sun/javafx/test/MouseEventGenerator.java ! javafx-ui-common/test/unit/javafx/scene/input/DragAndDropTest.java ! javafx-ui-common/test/unit/javafx/scene/input/MouseDragEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/MouseEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/TouchEventTest.java Changeset: 6d112cd51f1b Author: Artem Ananiev Date: 2013-02-11 14:02 +0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6d112cd51f1b Fix for RT-26745: Clean up initialization of QuantumClipboard Reviewed-by: Alexey Utkin, Pavel Safrata ! javafx-ui-common/src/com/sun/javafx/tk/TKClipboard.java ! javafx-ui-common/src/com/sun/javafx/tk/TKDragGestureListener.java ! javafx-ui-common/src/com/sun/javafx/tk/TKDragSourceListener.java ! javafx-ui-common/src/com/sun/javafx/tk/TKDropTargetListener.java ! javafx-ui-common/src/com/sun/javafx/tk/TKScene.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/Clipboard.java ! javafx-ui-common/src/javafx/scene/input/Dragboard.java ! javafx-ui-common/test/unit/javafx/scene/input/DragAndDropTest.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubScene.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: b10019f7ff27 Author: jgodinez Date: 2013-02-11 10:58 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b10019f7ff27 Renamed printing unit test directory. ! javafx-ui-common/project.properties + javafx-ui-common/test/unit/test/javafx/print/JobSettingsTest.java + javafx-ui-common/test/unit/test/javafx/print/PrinterJobTest.java - javafx-ui-common/test/unit/test/javax/print/JobSettingsTest.java - javafx-ui-common/test/unit/test/javax/print/PrinterJobTest.java Changeset: cc3702cbc8a0 Author: Chien Yang Date: 2013-02-11 15:31 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/cc3702cbc8a0 Fix to RT-28303: Use TempState rather than instance variables for projtx and viewport needed by LOD helper method. Approved by Kevin ! javafx-ui-common/src/com/sun/javafx/TempState.java ! javafx-ui-common/src/javafx/scene/Node.java Changeset: dafee5d5fe66 Author: Chien Yang Date: 2013-02-11 17:46 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/dafee5d5fe66 Fixed to RT-27113: Netbeans project dependency information got lost .... Approved by Richard. ! javafx-geom/project.properties ! javafx-sg-common/project.properties ! javafx-sg-prism/project.properties ! javafx-ui-common/project.properties Changeset: 91891157486b Author: rbair Date: 2013-02-11 17:50 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/91891157486b RT-28344: NonNull annotation is unused and should be removed ! build.gradle - javafx-beans/src/com/sun/javafx/beans/annotations/NonNull.java Changeset: b2dfc3891302 Author: David Grieve Date: 2013-02-13 18:35 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b2dfc3891302 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-ui-common/src/com/sun/javafx/css/Styleable.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/layout/Region.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java From phdoerfler at gmail.com Thu Feb 14 01:48:08 2013 From: phdoerfler at gmail.com (=?iso-8859-1?Q?Philipp_D=F6rfler?=) Date: Thu, 14 Feb 2013 10:48:08 +0100 Subject: Decora <> Open Shading Language? Message-ID: <92B8F9D0-8E17-43D6-B5BE-8DB4E2153435@gmail.com> Greetings, I stumbled upon the Open Shading Language [1] which seems to be an already established standard and uses LLVM to optimize shaders. I wonder why this is not used instead of / as a backend for Decora. Might you please shed some light on that? Cheers and thanks in advance ~ Philipp From phdoerfler at gmail.com Thu Feb 14 01:49:19 2013 From: phdoerfler at gmail.com (=?iso-8859-1?Q?Philipp_D=F6rfler?=) Date: Thu, 14 Feb 2013 10:49:19 +0100 Subject: Decora <> Open Shading Language? In-Reply-To: <92B8F9D0-8E17-43D6-B5BE-8DB4E2153435@gmail.com> References: <92B8F9D0-8E17-43D6-B5BE-8DB4E2153435@gmail.com> Message-ID: <78F405D3-FFED-4314-BFE5-622495543B99@gmail.com> Here is the link: [1] http://opensource.imageworks.com/?p=osl Am 14.02.2013 um 10:48 schrieb Philipp D?rfler : > Greetings, > > I stumbled upon the Open Shading Language [1] which seems to be an already established standard and uses LLVM to optimize shaders. I wonder why this is not used instead of / as a backend for Decora. Might you please shed some light on that? > > Cheers and thanks in advance > ~ Philipp From tom.schindl at bestsolution.at Thu Feb 14 02:06:52 2013 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 14 Feb 2013 11:06:52 +0100 Subject: Decora <> Open Shading Language? In-Reply-To: <78F405D3-FFED-4314-BFE5-622495543B99@gmail.com> References: <92B8F9D0-8E17-43D6-B5BE-8DB4E2153435@gmail.com> <78F405D3-FFED-4314-BFE5-622495543B99@gmail.com> Message-ID: <511CB73C.10503@bestsolution.at> If I read this right they are running the shader stuff on the CPU and not on the GPU. In the roadmap I read: --------8<-------- ... We would like to implement alternate "back ends" that would allow translation of OSL shaders (and shader networks) into code that can run on GPUs or other exotic hardware (at least for the biggest subset of OSL that can be expressed on such hardware). This would, for example, allow you to view close approximations to your OSL shaders in realtime preview windows in a modeling system or lighting tool. ... --------8<-------- Tom Am 14.02.13 10:49, schrieb Philipp D?rfler: > Here is the link: > [1] http://opensource.imageworks.com/?p=osl > > Am 14.02.2013 um 10:48 schrieb Philipp D?rfler : > >> Greetings, >> >> I stumbled upon the Open Shading Language [1] which seems to be an already established standard and uses LLVM to optimize shaders. I wonder why this is not used instead of / as a backend for Decora. Might you please shed some light on that? >> >> Cheers and thanks in advance >> ~ Philipp > -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl gesch?ftsf?hrer/CEO ------------------------------------------------------------------------ eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834 From phdoerfler at gmail.com Thu Feb 14 02:31:55 2013 From: phdoerfler at gmail.com (=?iso-8859-1?Q?Philipp_D=F6rfler?=) Date: Thu, 14 Feb 2013 11:31:55 +0100 Subject: Decora <> Open Shading Language? In-Reply-To: <511CB73C.10503@bestsolution.at> References: <92B8F9D0-8E17-43D6-B5BE-8DB4E2153435@gmail.com> <78F405D3-FFED-4314-BFE5-622495543B99@gmail.com> <511CB73C.10503@bestsolution.at> Message-ID: <229CE4F6-2FCD-4BFA-ADD5-6101C779C7D4@gmail.com> Given that they are mentioning the GPU in the roadmap at least indicates that it would possible to write such a backend. Thus my suggestion to take advantage of the intermediate bytecode emitted by OSL and to convert this bytecode to D3D and OpenGL shaders using Decora. I'm neither a Decora nor an OSL expert and I especially do not know how complex OSL (or that subset of OSL) is or if it is suitable for the purposes Decora is aimed at. For example: Decora allows to call getEffect() [1]. I just assume there is a comparable way of doing that in OSL. Having said that, I imagine it would be pretty awesome to have "NEW: Support for Open Shading Language in Decora" in the feature list for JavaFX 42 given that JavaFX 2 seems to be all about re-using existing knowledge and not having to learn new languages. [1] http://hg.openjdk.java.net/openjfx/8/controls/rt/file/7507d0eacf70/decora-runtime/jsl/BoxBlur.jsl Just my six cent, ~ Philipp Am 14.02.2013 um 11:06 schrieb Tom Schindl : > If I read this right they are running the shader stuff on the CPU and > not on the GPU. > > In the roadmap I read: > --------8<-------- > ... > We would like to implement alternate "back ends" that would allow > translation of OSL shaders (and shader networks) into code that can run > on GPUs or other exotic hardware (at least for the biggest subset of OSL > that can be expressed on such hardware). This would, for example, allow > you to view close approximations to your OSL shaders in realtime preview > windows in a modeling system or lighting tool. > ... > --------8<-------- > > Tom > > Am 14.02.13 10:49, schrieb Philipp D?rfler: >> Here is the link: >> [1] http://opensource.imageworks.com/?p=osl >> >> Am 14.02.2013 um 10:48 schrieb Philipp D?rfler : >> >>> Greetings, >>> >>> I stumbled upon the Open Shading Language [1] which seems to be an already established standard and uses LLVM to optimize shaders. I wonder why this is not used instead of / as a backend for Decora. Might you please shed some light on that? >>> >>> Cheers and thanks in advance >>> ~ Philipp >> > > > -- > B e s t S o l u t i o n . a t EDV Systemhaus GmbH > ------------------------------------------------------------------------ > tom schindl gesch?ftsf?hrer/CEO > ------------------------------------------------------------------------ > eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 > http://www.BestSolution.at phone ++43 512 935834 From hang.vo at oracle.com Thu Feb 14 03:33:28 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Feb 2013 11:33:28 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28217 - Regression: Dirtyopts repaint issue in Ensemble and Stopwatch Message-ID: <20130214113336.D7C1D47A72@hg.openjdk.java.net> Changeset: 673501d476ce Author: Radko Najman Date: 2013-02-14 12:22 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/673501d476ce RT-28217 - Regression: Dirtyopts repaint issue in Ensemble and Stopwatch ! javafx-sg-common/src/com/sun/javafx/sg/BaseNode.java From hang.vo at oracle.com Thu Feb 14 05:32:59 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Feb 2013 13:32:59 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130214133305.E4A4947A7B@hg.openjdk.java.net> Changeset: 7519c42e504f Author: kcr Date: 2013-02-14 05:20 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7519c42e504f [TEST-ONLY] Remove unneeded override of test target in javafx-ui-common so smoke.test.excludes will work ! javafx-ui-common/build-common.xml Changeset: a898fab91b4f Author: kcr Date: 2013-02-14 05:26 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a898fab91b4f Backed out changeset 7519c42e504f This caused a test failure elsewhere, so looking for another solution ! javafx-ui-common/build-common.xml From hang.vo at oracle.com Thu Feb 14 05:33:27 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Feb 2013 13:33:27 +0000 Subject: hg: openjfx/8/controls/rt: Modena Tweaks - improved look for focused tab (also fixes RT-27857) Message-ID: <20130214133331.A9D9347A7C@hg.openjdk.java.net> Changeset: 71f97b47e94d Author: mo.chicharro Date: 2013-02-14 13:23 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/71f97b47e94d Modena Tweaks - improved look for focused tab (also fixes RT-27857) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From hang.vo at oracle.com Thu Feb 14 07:03:26 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Feb 2013 15:03:26 +0000 Subject: hg: openjfx/8/graphics/rt: [TEST-ONLY] Remove unneeded override of test target in javafx-ui-common so smoke.test.excludes will work Message-ID: <20130214150330.A17EF47A85@hg.openjdk.java.net> Changeset: 769e835be3cd Author: kcr Date: 2013-02-14 06:50 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/769e835be3cd [TEST-ONLY] Remove unneeded override of test target in javafx-ui-common so smoke.test.excludes will work ! javafx-ui-common/build-closed.xml ! javafx-ui-common/build-common.xml From hang.vo at oracle.com Thu Feb 14 08:18:13 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Feb 2013 16:18:13 +0000 Subject: hg: openjfx/8/graphics/rt: Renamed MouseTest3D to Mouse3DTest because our buildsystem ignores tests in files not suffixed with "Test". Message-ID: <20130214161817.0B22B47A8E@hg.openjdk.java.net> Changeset: 938770d25b8f Author: Pavel Safrata Date: 2013-02-14 16:15 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/938770d25b8f Renamed MouseTest3D to Mouse3DTest because our buildsystem ignores tests in files not suffixed with "Test". + javafx-ui-common/test/unit/javafx/scene/Mouse3DTest.java - javafx-ui-common/test/unit/javafx/scene/MouseTest3D.java From scgm11 at gmail.com Thu Feb 14 10:10:07 2013 From: scgm11 at gmail.com (Sebastian Gutierrez) Date: Thu, 14 Feb 2013 16:10:07 -0200 Subject: Async REST web services calls Message-ID: <1D520562-DDF6-482D-B9C2-6D66BCCFF670@gmail.com> Hello list, I'm migrating a silverlight app to javafx, but I'm running into this issue: I used a lot async calls to REST Webservices on siverlight like this: WebClient test = new WebClient(); test.UploadStringCompleted += new UploadStringCompletedEventHandler(test_UploadStringCompleted); test.UploadStringAsync(URL, POST DATA); and the callback method: void test_UploadStringCompleted(object sender, UploadStringCompletedEventArgs e) { String result = e.Response(); //here I have the response of the web service } now Im using this on JAVAFX: public static String ExecPOSTRESTWebService(String resource, String data) { try { String rest = //URL for the rest WS; URL url = new URL(rest); URLConnection conn = url.openConnection(); conn.setDoOutput(true); BufferedReader rd; String buffer; try (OutputStreamWriter wr = new OutputStreamWriter(conn.getOutputStream())) { wr.write(data); wr.flush(); rd = new BufferedReader(new InputStreamReader(conn.getInputStream())); String line; buffer = ""; while ((line = rd.readLine()) != null) { buffer = buffer + line; } } rd.close(); return buffer; } catch (Exception ex) { Logger.getLogger(Utils.class.getName()).log(Level.SEVERE, ex.toString()); return ""; } } the problem is that this is sync and not async so I block the UI, I know I can do some threading and Platform.runlater? and those? but for many calls the code will get hard to read and difficult is there any component around that does the async calls with a callback method?? any library? Thanks! From hendrik.ebbers at me.com Thu Feb 14 10:21:03 2013 From: hendrik.ebbers at me.com (Hendrik Ebbers) Date: Thu, 14 Feb 2013 19:21:03 +0100 Subject: Async REST web services calls In-Reply-To: <1D520562-DDF6-482D-B9C2-6D66BCCFF670@gmail.com> References: <1D520562-DDF6-482D-B9C2-6D66BCCFF670@gmail.com> Message-ID: <7AC9E60F-7C6E-4952-83BC-99F568FE6619@me.com> Hi, maybe DataFX (http://www.javafxdata.org/) can help. Am 14.02.2013 um 19:10 schrieb Sebastian Gutierrez : > Hello list, > > I'm migrating a silverlight app to javafx, but I'm running into this issue: > > I used a lot async calls to REST Webservices on siverlight like this: > > WebClient test = new WebClient(); > test.UploadStringCompleted += new UploadStringCompletedEventHandler(test_UploadStringCompleted); > test.UploadStringAsync(URL, POST DATA); > > and the callback method: > > > void test_UploadStringCompleted(object sender, UploadStringCompletedEventArgs e) > { > String result = e.Response(); > > //here I have the response of the web service > > } > > > > > > now Im using this on JAVAFX: > > > public static String ExecPOSTRESTWebService(String resource, String data) > { > try { > > > > > String rest = //URL for the rest WS; > > URL url = new URL(rest); > URLConnection conn = url.openConnection(); > conn.setDoOutput(true); > BufferedReader rd; > String buffer; > try (OutputStreamWriter wr = new OutputStreamWriter(conn.getOutputStream())) { > wr.write(data); > wr.flush(); > rd = new BufferedReader(new InputStreamReader(conn.getInputStream())); > String line; > buffer = ""; > while ((line = rd.readLine()) != null) { > buffer = buffer + line; > } > } > rd.close(); > > return buffer; > > } catch (Exception ex) { > Logger.getLogger(Utils.class.getName()).log(Level.SEVERE, ex.toString()); > return ""; > } > > } > > > the problem is that this is sync and not async so I block the UI, I know I can do some threading and Platform.runlater? and those? but for many calls the code will get hard to read and difficult > is there any component around that does the async calls with a callback method?? any library? > > > Thanks! > > > From hang.vo at oracle.com Thu Feb 14 11:47:50 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Thu, 14 Feb 2013 19:47:50 +0000 Subject: hg: openjfx/8/graphics/rt: RT-26893 Remove dead classes in decora-compiler Message-ID: <20130214194755.0943B47A9A@hg.openjdk.java.net> Changeset: cfa2e868a1fc Author: "Joseph Andresen" Date: 2013-02-14 11:13 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/cfa2e868a1fc RT-26893 Remove dead classes in decora-compiler - decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/jogl/JOGLBackend.java - decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/jogl/JOGLGlue.stg - decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/rsl/RSLBackend.java - decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/rsl/RSLGlue.stg From richard.bair at oracle.com Thu Feb 14 13:52:29 2013 From: richard.bair at oracle.com (Richard Bair) Date: Thu, 14 Feb 2013 13:52:29 -0800 Subject: Decora <> Open Shading Language? In-Reply-To: <78F405D3-FFED-4314-BFE5-622495543B99@gmail.com> References: <92B8F9D0-8E17-43D6-B5BE-8DB4E2153435@gmail.com> <78F405D3-FFED-4314-BFE5-622495543B99@gmail.com> Message-ID: <05613065-350C-42BF-A94A-3401F2F0E32F@oracle.com> Hi Philip, Very interesting link. I didn't clone the repo and check, I'm not sure how long it has been around. We've had Decora for 5 years I think, so we may predate it substantially. Adobe also has a shader technology called Pixel Bender (http://www.adobe.com/devnet/pixelbender.html). The nice thing about their language is that their designer tools support Pixel Bender (and I guess AGAL and Pixel Bender 3D https://www.adobe.com/devnet/flashplayer/articles/what-is-agal.html). Although we use Decora for our shaders, we haven't done much more than keep it running. Jim Graham has had a number of ideas about things he wanted to do to move Decora forward (maybe he can chime in with those). There are Pros / Cons to each: OSL: Pros: - It looks like Sony Pictures is continuing to work on OSL, it wasn't a dump & forget. - Any time multiple companies can contribute to the same thing, the better chance of broader adoption (& tools etc) - Being able to leverage other's work instead of doing all the work ourselves could free us from some maintenance costs Cons: - Different design center -- doesn't yet support GPUs for instance - Lack of tooling Pixel Bender: Pros: - Great tooling support - Same design center -- shaders for 2D / 3D applications - Robust - Leverage Adobe's investment Cons: - License is proprietary according to wikipedia, not sure myself - Not sure of the runtime size - Needs to be vetted for security risks Decora: Pros: - Does exactly what we need -- no more - Small size (no features we don't need) Cons: - No time to invest in serious upgrades - No tooling support I think that's a fair portrayal of the situation. From a pragmatic perspective it seems like supporting Pixel Bender would be a great way forward, but I don't know what the license situation is (i.e.: would we have to provide our own compiler, or could we reuse their compiler? Can we even do that much?). Given we haven't had time to spend improving decora, replacing it would be even more work. However, I wouldn't be opposed to using OSL or Pixel Bender or any other system if the benefits outweigh the costs. Richard On Feb 14, 2013, at 1:49 AM, Philipp D?rfler wrote: > Here is the link: > [1] http://opensource.imageworks.com/?p=osl > > Am 14.02.2013 um 10:48 schrieb Philipp D?rfler : > >> Greetings, >> >> I stumbled upon the Open Shading Language [1] which seems to be an already established standard and uses LLVM to optimize shaders. I wonder why this is not used instead of / as a backend for Decora. Might you please shed some light on that? >> >> Cheers and thanks in advance >> ~ Philipp > From james.graham at oracle.com Thu Feb 14 14:43:17 2013 From: james.graham at oracle.com (Jim Graham) Date: Thu, 14 Feb 2013 14:43:17 -0800 Subject: Decora <> Open Shading Language? In-Reply-To: <05613065-350C-42BF-A94A-3401F2F0E32F@oracle.com> References: <92B8F9D0-8E17-43D6-B5BE-8DB4E2153435@gmail.com> <78F405D3-FFED-4314-BFE5-622495543B99@gmail.com> <05613065-350C-42BF-A94A-3401F2F0E32F@oracle.com> Message-ID: <511D6885.6010800@oracle.com> Rich's analysis is spot on from my perspective. I don't have much time to work on Decora these days and most of my plans for what I would do are more tweaking and fixing issues that cause us headaches for our current usage. For example, it was originally written to be a standalone package that could be integrated into Swing apps or any other infrastructure out there, but we've since broken just about any generalized mechanism in it through disuse and lack of maintenance. Since we don't really believe that it would ever be a standalone module any more, it would integrate a whole lot more directly and simply if we redid the interface to it to be Prism-specific. The only "marketing bullet point" advantages to switching from Decora would likely be possibly enabling user-supplied shaders, and also using it for the greater needs of 3D apps that go beyond basic pixel-shaders. We'd love to be able to leverage Decora at runtime for user-supplied shaders, but that is a daunting amount of work since much of its actions rely on being able to use javac and/or a native C, GSL, or HLSL compiler to finish the work after the "decora compiler" does the translations - i.e. it translates form HSL into various other forms of source code and then runs other compilers on those. What we would probably have to do is to provide a way for a developer to run the decora compiler alongside his FX app and then include the various compiled alternative results, but that would require building on multiple platforms to produce all of the necessary files that are needed on an arbitrary target computer (minimally, building on Windows could net a GLS, an HLSL, and a Java version of the shader so that may be enough, but Mac developers would be out of luck for producing Win-specific output). We'd also have to do a security analysis of accepting compiled GSL and HLSL shaders in a non-privileged deployment (the least common denominator work around would be to only allow the Java-compiled versions of the shaders in the absence of a signed app, but the performance on those would likely be lower than something that the developer wrote themselves in hand-tuned Java). So, there are a lot of issues to consider and work on there before we could use Decora to provide user-supplied shaders. It may be less work to provide the GPU plugins for OSL than to figure out a workaround for the need for a compiler in Decora. We'd also leverage a larger development community for the more common parts of it. But, we'd also have to do a large security review of it every single time we brought over a new source drop from it and the complexity of that security review would involve analyzing the byte-code they produce and all elements of their runtime to make sure that a hostile OSL byte-code file couldn't break us. Using this "off the shelf" technology sounds attractive, but integrating a 3rd party solution often has its own headaches that you don't see when you are in the honeymoon phase after having read all of the marketing bullet points. :( I think a first task should be to get to the point where "Jim" isn't the only engineer with more than a passing understanding of what goes on with Decora under the hood - particularly since I don't have much time to do a more indepth analysis of competing technologies like this. Any volunteers that are fascinated by the world of shaders? ...jim On 2/14/13 1:52 PM, Richard Bair wrote: > Hi Philip, > > Very interesting link. I didn't clone the repo and check, I'm not sure how long it has been around. We've had Decora for 5 years I think, so we may predate it substantially. > > Adobe also has a shader technology called Pixel Bender (http://www.adobe.com/devnet/pixelbender.html). The nice thing about their language is that their designer tools support Pixel Bender (and I guess AGAL and Pixel Bender 3D https://www.adobe.com/devnet/flashplayer/articles/what-is-agal.html). > > Although we use Decora for our shaders, we haven't done much more than keep it running. Jim Graham has had a number of ideas about things he wanted to do to move Decora forward (maybe he can chime in with those). > > There are Pros / Cons to each: > > OSL: > Pros: > - It looks like Sony Pictures is continuing to work on OSL, it wasn't a dump & forget. > - Any time multiple companies can contribute to the same thing, the better chance of broader adoption (& tools etc) > - Being able to leverage other's work instead of doing all the work ourselves could free us from some maintenance costs > Cons: > - Different design center -- doesn't yet support GPUs for instance > - Lack of tooling > > Pixel Bender: > Pros: > - Great tooling support > - Same design center -- shaders for 2D / 3D applications > - Robust > - Leverage Adobe's investment > Cons: > - License is proprietary according to wikipedia, not sure myself > - Not sure of the runtime size > - Needs to be vetted for security risks > > Decora: > Pros: > - Does exactly what we need -- no more > - Small size (no features we don't need) > Cons: > - No time to invest in serious upgrades > - No tooling support > > I think that's a fair portrayal of the situation. From a pragmatic perspective it seems like supporting Pixel Bender would be a great way forward, but I don't know what the license situation is (i.e.: would we have to provide our own compiler, or could we reuse their compiler? Can we even do that much?). Given we haven't had time to spend improving decora, replacing it would be even more work. > > However, I wouldn't be opposed to using OSL or Pixel Bender or any other system if the benefits outweigh the costs. > > Richard > > > On Feb 14, 2013, at 1:49 AM, Philipp D?rfler wrote: > >> Here is the link: >> [1] http://opensource.imageworks.com/?p=osl >> >> Am 14.02.2013 um 10:48 schrieb Philipp D?rfler : >> >>> Greetings, >>> >>> I stumbled upon the Open Shading Language [1] which seems to be an already established standard and uses LLVM to optimize shaders. I wonder why this is not used instead of / as a backend for Decora. Might you please shed some light on that? >>> >>> Cheers and thanks in advance >>> ~ Philipp >> > From joseph.andresen at oracle.com Thu Feb 14 15:05:56 2013 From: joseph.andresen at oracle.com (joe andresen) Date: Thu, 14 Feb 2013 15:05:56 -0800 Subject: Decora <> Open Shading Language? In-Reply-To: <511D6885.6010800@oracle.com> References: <92B8F9D0-8E17-43D6-B5BE-8DB4E2153435@gmail.com> <78F405D3-FFED-4314-BFE5-622495543B99@gmail.com> <05613065-350C-42BF-A94A-3401F2F0E32F@oracle.com> <511D6885.6010800@oracle.com> Message-ID: <511D6DD4.8070604@oracle.com> On 2/14/2013 2:43 PM, Jim Graham wrote: > I think a first task should be to get to the point where "Jim" isn't > the only engineer with more than a passing understanding of what goes > on with Decora under the hood - particularly since I don't have much > time to do a more indepth analysis of competing technologies like > this. Any volunteers that are fascinated by the world of shaders? My understanding has been purely from a Prism rendering perspective, I have looked into a number of possibilities into extending JSL, like adding vertex shader support and whatnot. But again, my focus has always been "what can JSL and the decora-compiler do for ES2 and D3D projects moving forward", which i admit is a bit limited in scope. I agree with what you said about the problems. There is also the issue that decora "doing only what we need" is starting to become incorrect (as in we need more). Our current 3D implementation makes no use of the decora-compiler translator, which means that the 3d shaders are hand written which means they are different, and theoretically could introduce a bit of shader code that isn't as well tested (In practice it isn't that big of a deal). Prism's use of JSL itself is also in need of work since writing a shader is only half the battle. We need to be able to provide flexible vertex data objects/interfaces and manage these in a way that is simple and flexible if we are to provide shaders to developers. As for the languages themselves, different engineers here have differing opinions. Some think we should stop using JSL and concentrate on GLSL and HLSL specifically, maybe providing a bridge so we only expose one language in the API. Some think JSL with a little love could be upgraded to fill that need. OSL is an interesting thought. -Joe From jasper.potts at oracle.com Thu Feb 14 15:30:41 2013 From: jasper.potts at oracle.com (Jasper Potts) Date: Thu, 14 Feb 2013 15:30:41 -0800 Subject: Decora <> Open Shading Language? In-Reply-To: <511D6DD4.8070604@oracle.com> References: <92B8F9D0-8E17-43D6-B5BE-8DB4E2153435@gmail.com> <78F405D3-FFED-4314-BFE5-622495543B99@gmail.com> <05613065-350C-42BF-A94A-3401F2F0E32F@oracle.com> <511D6885.6010800@oracle.com> <511D6DD4.8070604@oracle.com> Message-ID: <6F6D8AFD-D91F-4319-A7D5-230C8C0C8A5C@oracle.com> Another one to consider is proposed CSS spec for shaders. https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html http://www.adobe.com/devnet/html5/articles/css-shaders.html Jasper Sent from my iPhone On Feb 14, 2013, at 3:05 PM, joe andresen wrote: > On 2/14/2013 2:43 PM, Jim Graham wrote: >> I think a first task should be to get to the point where "Jim" isn't the only engineer with more than a passing understanding of what goes on with Decora under the hood - particularly since I don't have much time to do a more indepth analysis of competing technologies like this. Any volunteers that are fascinated by the world of shaders? > My understanding has been purely from a Prism rendering perspective, I have looked into a number of possibilities into extending JSL, like adding vertex shader support and whatnot. But again, my focus has always been "what can JSL and the decora-compiler do for ES2 and D3D projects moving forward", which i admit is a bit limited in scope. > > I agree with what you said about the problems. There is also the issue that decora "doing only what we need" is starting to become incorrect (as in we need more). Our current 3D implementation makes no use of the decora-compiler translator, which means that the 3d shaders are hand written which means they are different, and theoretically could introduce a bit of shader code that isn't as well tested (In practice it isn't that big of a deal). Prism's use of JSL itself is also in need of work since writing a shader is only half the battle. We need to be able to provide flexible vertex data objects/interfaces and manage these in a way that is simple and flexible if we are to provide shaders to developers. > > As for the languages themselves, different engineers here have differing opinions. > > Some think we should stop using JSL and concentrate on GLSL and HLSL specifically, maybe providing a bridge so we only expose one language in the API. > > Some think JSL with a little love could be upgraded to fill that need. > > OSL is an interesting thought. > > -Joe > From phdoerfler at gmail.com Thu Feb 14 15:39:31 2013 From: phdoerfler at gmail.com (=?iso-8859-1?Q?Philipp_D=F6rfler?=) Date: Fri, 15 Feb 2013 00:39:31 +0100 Subject: Decora <> Open Shading Language? In-Reply-To: <511D6885.6010800@oracle.com> References: <92B8F9D0-8E17-43D6-B5BE-8DB4E2153435@gmail.com> <78F405D3-FFED-4314-BFE5-622495543B99@gmail.com> <05613065-350C-42BF-A94A-3401F2F0E32F@oracle.com> <511D6885.6010800@oracle.com> Message-ID: Thanks for your elaborate replies and for providing insight into Decora. It's a shame it took this course given how high the original hopes had been. The reasons for this development are all quite understandable and I share your pain, for that matter. Still: Decora would certainly be an awesome stand alone tool and given that you guys are busy open sourcing JavaFX I might feel tempted to write a tiny shader editor on top of it (once I'll have time for that, aka never). Regarding OSL and Pixel Bender: According to GitHub, the first commit [1] was on 2008-09-03, 4 years ago. So indeed, Decora predates OSL. From what I've heard the Blender community is currently adapting their shader code to OSL. Hopefully it will gain more momentum and interest so it might become a viable alternative or supplement for Decora. I was unaware of Pixel Bender and have to say it looks rather promising though the disadvantages mentioned are deterrent. Again thanks for your detailed replies. It's nice to see how much you care about Decora :) [1] https://github.com/imageworks/OpenShadingLanguage/commit/ed210bbb0c5c74ad0b82c4a8a949ab97d1aa0ad6 Am 14.02.2013 um 23:43 schrieb Jim Graham : > Rich's analysis is spot on from my perspective. I don't have much time to work on Decora these days and most of my plans for what I would do are more tweaking and fixing issues that cause us headaches for our current usage. For example, it was originally written to be a standalone package that could be integrated into Swing apps or any other infrastructure out there, but we've since broken just about any generalized mechanism in it through disuse and lack of maintenance. Since we don't really believe that it would ever be a standalone module any more, it would integrate a whole lot more directly and simply if we redid the interface to it to be Prism-specific. > > The only "marketing bullet point" advantages to switching from Decora would likely be possibly enabling user-supplied shaders, and also using it for the greater needs of 3D apps that go beyond basic pixel-shaders. > > We'd love to be able to leverage Decora at runtime for user-supplied shaders, but that is a daunting amount of work since much of its actions rely on being able to use javac and/or a native C, GSL, or HLSL compiler to finish the work after the "decora compiler" does the translations - i.e. it translates form HSL into various other forms of source code and then runs other compilers on those. What we would probably have to do is to provide a way for a developer to run the decora compiler alongside his FX app and then include the various compiled alternative results, but that would require building on multiple platforms to produce all of the necessary files that are needed on an arbitrary target computer (minimally, building on Windows could net a GLS, an HLSL, and a Java version of the shader so that may be enough, but Mac developers would be out of luck for producing Win-specific output). We'd also have to do a security analysis of accepting compiled GSL and HLSL shaders in a non-privileged deployment (the least common denominator work around would be to only allow the Java-compiled versions of the shaders in the absence of a signed app, but the performance on those would likely be lower than something that the developer wrote themselves in hand-tuned Java). So, there are a lot of issues to consider and work on there before we could use Decora to provide user-supplied shaders. > > It may be less work to provide the GPU plugins for OSL than to figure out a workaround for the need for a compiler in Decora. We'd also leverage a larger development community for the more common parts of it. But, we'd also have to do a large security review of it every single time we brought over a new source drop from it and the complexity of that security review would involve analyzing the byte-code they produce and all elements of their runtime to make sure that a hostile OSL byte-code file couldn't break us. Using this "off the shelf" technology sounds attractive, but integrating a 3rd party solution often has its own headaches that you don't see when you are in the honeymoon phase after having read all of the marketing bullet points. :( > > I think a first task should be to get to the point where "Jim" isn't the only engineer with more than a passing understanding of what goes on with Decora under the hood - particularly since I don't have much time to do a more indepth analysis of competing technologies like this. Any volunteers that are fascinated by the world of shaders? > > ...jim > > On 2/14/13 1:52 PM, Richard Bair wrote: >> Hi Philip, >> >> Very interesting link. I didn't clone the repo and check, I'm not sure how long it has been around. We've had Decora for 5 years I think, so we may predate it substantially. >> >> Adobe also has a shader technology called Pixel Bender (http://www.adobe.com/devnet/pixelbender.html). The nice thing about their language is that their designer tools support Pixel Bender (and I guess AGAL and Pixel Bender 3D https://www.adobe.com/devnet/flashplayer/articles/what-is-agal.html). >> >> Although we use Decora for our shaders, we haven't done much more than keep it running. Jim Graham has had a number of ideas about things he wanted to do to move Decora forward (maybe he can chime in with those). >> >> There are Pros / Cons to each: >> >> OSL: >> Pros: >> - It looks like Sony Pictures is continuing to work on OSL, it wasn't a dump & forget. >> - Any time multiple companies can contribute to the same thing, the better chance of broader adoption (& tools etc) >> - Being able to leverage other's work instead of doing all the work ourselves could free us from some maintenance costs >> Cons: >> - Different design center -- doesn't yet support GPUs for instance >> - Lack of tooling >> >> Pixel Bender: >> Pros: >> - Great tooling support >> - Same design center -- shaders for 2D / 3D applications >> - Robust >> - Leverage Adobe's investment >> Cons: >> - License is proprietary according to wikipedia, not sure myself >> - Not sure of the runtime size >> - Needs to be vetted for security risks >> >> Decora: >> Pros: >> - Does exactly what we need -- no more >> - Small size (no features we don't need) >> Cons: >> - No time to invest in serious upgrades >> - No tooling support >> >> I think that's a fair portrayal of the situation. From a pragmatic perspective it seems like supporting Pixel Bender would be a great way forward, but I don't know what the license situation is (i.e.: would we have to provide our own compiler, or could we reuse their compiler? Can we even do that much?). Given we haven't had time to spend improving decora, replacing it would be even more work. >> >> However, I wouldn't be opposed to using OSL or Pixel Bender or any other system if the benefits outweigh the costs. >> >> Richard >> >> >> On Feb 14, 2013, at 1:49 AM, Philipp D?rfler wrote: >> >>> Here is the link: >>> [1] http://opensource.imageworks.com/?p=osl >>> >>> Am 14.02.2013 um 10:48 schrieb Philipp D?rfler : >>> >>>> Greetings, >>>> >>>> I stumbled upon the Open Shading Language [1] which seems to be an already established standard and uses LLVM to optimize shaders. I wonder why this is not used instead of / as a backend for Decora. Might you please shed some light on that? >>>> >>>> Cheers and thanks in advance >>>> ~ Philipp >>> >> From joseph.andresen at oracle.com Thu Feb 14 15:41:43 2013 From: joseph.andresen at oracle.com (joe andresen) Date: Thu, 14 Feb 2013 15:41:43 -0800 Subject: Decora <> Open Shading Language? In-Reply-To: References: <92B8F9D0-8E17-43D6-B5BE-8DB4E2153435@gmail.com> <78F405D3-FFED-4314-BFE5-622495543B99@gmail.com> <05613065-350C-42BF-A94A-3401F2F0E32F@oracle.com> <511D6885.6010800@oracle.com> Message-ID: <511D7637.50404@oracle.com> Hey Philipp, About 6 months ago I wrote a netbeans extension to support jsl, and it worked quite nicely, but I ran in to trouble bundling it and alas ran out of free time to work out the issues (there was a netbeans bug that was holding me back). I would love for it to get cleaned up and bundled for all of us to use. -Joe On 2/14/2013 3:39 PM, Philipp D?rfler wrote: > Thanks for your elaborate replies and for providing insight into Decora. It's a shame it took this course given how high the original hopes had been. The reasons for this development are all quite understandable and I share your pain, for that matter. Still: Decora would certainly be an awesome stand alone tool and given that you guys are busy open sourcing JavaFX I might feel tempted to write a tiny shader editor on top of it (once I'll have time for that, aka never). > > Regarding OSL and Pixel Bender: > According to GitHub, the first commit [1] was on 2008-09-03, 4 years ago. So indeed, Decora predates OSL. From what I've heard the Blender community is currently adapting their shader code to OSL. Hopefully it will gain more momentum and interest so it might become a viable alternative or supplement for Decora. > I was unaware of Pixel Bender and have to say it looks rather promising though the disadvantages mentioned are deterrent. > > Again thanks for your detailed replies. It's nice to see how much you care about Decora :) > > [1] https://github.com/imageworks/OpenShadingLanguage/commit/ed210bbb0c5c74ad0b82c4a8a949ab97d1aa0ad6 > > Am 14.02.2013 um 23:43 schrieb Jim Graham : > >> Rich's analysis is spot on from my perspective. I don't have much time to work on Decora these days and most of my plans for what I would do are more tweaking and fixing issues that cause us headaches for our current usage. For example, it was originally written to be a standalone package that could be integrated into Swing apps or any other infrastructure out there, but we've since broken just about any generalized mechanism in it through disuse and lack of maintenance. Since we don't really believe that it would ever be a standalone module any more, it would integrate a whole lot more directly and simply if we redid the interface to it to be Prism-specific. >> >> The only "marketing bullet point" advantages to switching from Decora would likely be possibly enabling user-supplied shaders, and also using it for the greater needs of 3D apps that go beyond basic pixel-shaders. >> >> We'd love to be able to leverage Decora at runtime for user-supplied shaders, but that is a daunting amount of work since much of its actions rely on being able to use javac and/or a native C, GSL, or HLSL compiler to finish the work after the "decora compiler" does the translations - i.e. it translates form HSL into various other forms of source code and then runs other compilers on those. What we would probably have to do is to provide a way for a developer to run the decora compiler alongside his FX app and then include the various compiled alternative results, but that would require building on multiple platforms to produce all of the necessary files that are needed on an arbitrary target computer (minimally, building on Windows could net a GLS, an HLSL, and a Java version of the shader so that may be enough, but Mac developers would be out of luck for producing Win-specific output). We'd also have to do a security analysis of accepting compiled GSL and HLSL shaders in a non-privileged deployment (the least common denominator work around would be to only allow the Java-compiled versions of the shaders in the absence of a signed app, but the performance on those would likely be lower than something that the developer wrote themselves in hand-tuned Java). So, there are a lot of issues to consider and work on there before we could use Decora to provide user-supplied shaders. >> >> It may be less work to provide the GPU plugins for OSL than to figure out a workaround for the need for a compiler in Decora. We'd also leverage a larger development community for the more common parts of it. But, we'd also have to do a large security review of it every single time we brought over a new source drop from it and the complexity of that security review would involve analyzing the byte-code they produce and all elements of their runtime to make sure that a hostile OSL byte-code file couldn't break us. Using this "off the shelf" technology sounds attractive, but integrating a 3rd party solution often has its own headaches that you don't see when you are in the honeymoon phase after having read all of the marketing bullet points. :( >> >> I think a first task should be to get to the point where "Jim" isn't the only engineer with more than a passing understanding of what goes on with Decora under the hood - particularly since I don't have much time to do a more indepth analysis of competing technologies like this. Any volunteers that are fascinated by the world of shaders? >> >> ...jim >> >> On 2/14/13 1:52 PM, Richard Bair wrote: >>> Hi Philip, >>> >>> Very interesting link. I didn't clone the repo and check, I'm not sure how long it has been around. We've had Decora for 5 years I think, so we may predate it substantially. >>> >>> Adobe also has a shader technology called Pixel Bender (http://www.adobe.com/devnet/pixelbender.html). The nice thing about their language is that their designer tools support Pixel Bender (and I guess AGAL and Pixel Bender 3D https://www.adobe.com/devnet/flashplayer/articles/what-is-agal.html). >>> >>> Although we use Decora for our shaders, we haven't done much more than keep it running. Jim Graham has had a number of ideas about things he wanted to do to move Decora forward (maybe he can chime in with those). >>> >>> There are Pros / Cons to each: >>> >>> OSL: >>> Pros: >>> - It looks like Sony Pictures is continuing to work on OSL, it wasn't a dump & forget. >>> - Any time multiple companies can contribute to the same thing, the better chance of broader adoption (& tools etc) >>> - Being able to leverage other's work instead of doing all the work ourselves could free us from some maintenance costs >>> Cons: >>> - Different design center -- doesn't yet support GPUs for instance >>> - Lack of tooling >>> >>> Pixel Bender: >>> Pros: >>> - Great tooling support >>> - Same design center -- shaders for 2D / 3D applications >>> - Robust >>> - Leverage Adobe's investment >>> Cons: >>> - License is proprietary according to wikipedia, not sure myself >>> - Not sure of the runtime size >>> - Needs to be vetted for security risks >>> >>> Decora: >>> Pros: >>> - Does exactly what we need -- no more >>> - Small size (no features we don't need) >>> Cons: >>> - No time to invest in serious upgrades >>> - No tooling support >>> >>> I think that's a fair portrayal of the situation. From a pragmatic perspective it seems like supporting Pixel Bender would be a great way forward, but I don't know what the license situation is (i.e.: would we have to provide our own compiler, or could we reuse their compiler? Can we even do that much?). Given we haven't had time to spend improving decora, replacing it would be even more work. >>> >>> However, I wouldn't be opposed to using OSL or Pixel Bender or any other system if the benefits outweigh the costs. >>> >>> Richard >>> >>> >>> On Feb 14, 2013, at 1:49 AM, Philipp D?rfler wrote: >>> >>>> Here is the link: >>>> [1] http://opensource.imageworks.com/?p=osl >>>> >>>> Am 14.02.2013 um 10:48 schrieb Philipp D?rfler : >>>> >>>>> Greetings, >>>>> >>>>> I stumbled upon the Open Shading Language [1] which seems to be an already established standard and uses LLVM to optimize shaders. I wonder why this is not used instead of / as a backend for Decora. Might you please shed some light on that? >>>>> >>>>> Cheers and thanks in advance >>>>> ~ Philipp From phdoerfler at gmail.com Thu Feb 14 15:56:28 2013 From: phdoerfler at gmail.com (=?iso-8859-1?Q?Philipp_D=F6rfler?=) Date: Fri, 15 Feb 2013 00:56:28 +0100 Subject: Decora <> Open Shading Language? In-Reply-To: <511D7637.50404@oracle.com> References: <92B8F9D0-8E17-43D6-B5BE-8DB4E2153435@gmail.com> <78F405D3-FFED-4314-BFE5-622495543B99@gmail.com> <05613065-350C-42BF-A94A-3401F2F0E32F@oracle.com> <511D6885.6010800@oracle.com> <511D7637.50404@oracle.com> Message-ID: <09E10F53-9745-4D44-BAE2-9B918918F9C9@gmail.com> Hey Joe, well what are you waiting for? ;) Just kidding, that sounds like a welcome addition. I hope you'll find the time to clean it up some day. ~ Philipp Am 15.02.2013 um 00:41 schrieb joe andresen : > Hey Philipp, > > About 6 months ago I wrote a netbeans extension to support jsl, and it worked quite nicely, but I ran in to trouble bundling it and alas ran out of free time to work out the issues (there was a netbeans bug that was holding me back). > > I would love for it to get cleaned up and bundled for all of us to use. > > -Joe > > > On 2/14/2013 3:39 PM, Philipp D?rfler wrote: >> Thanks for your elaborate replies and for providing insight into Decora. It's a shame it took this course given how high the original hopes had been. The reasons for this development are all quite understandable and I share your pain, for that matter. Still: Decora would certainly be an awesome stand alone tool and given that you guys are busy open sourcing JavaFX I might feel tempted to write a tiny shader editor on top of it (once I'll have time for that, aka never). >> >> Regarding OSL and Pixel Bender: >> According to GitHub, the first commit [1] was on 2008-09-03, 4 years ago. So indeed, Decora predates OSL. From what I've heard the Blender community is currently adapting their shader code to OSL. Hopefully it will gain more momentum and interest so it might become a viable alternative or supplement for Decora. >> I was unaware of Pixel Bender and have to say it looks rather promising though the disadvantages mentioned are deterrent. >> >> Again thanks for your detailed replies. It's nice to see how much you care about Decora :) >> >> [1] https://github.com/imageworks/OpenShadingLanguage/commit/ed210bbb0c5c74ad0b82c4a8a949ab97d1aa0ad6 >> >> Am 14.02.2013 um 23:43 schrieb Jim Graham : >> >>> Rich's analysis is spot on from my perspective. I don't have much time to work on Decora these days and most of my plans for what I would do are more tweaking and fixing issues that cause us headaches for our current usage. For example, it was originally written to be a standalone package that could be integrated into Swing apps or any other infrastructure out there, but we've since broken just about any generalized mechanism in it through disuse and lack of maintenance. Since we don't really believe that it would ever be a standalone module any more, it would integrate a whole lot more directly and simply if we redid the interface to it to be Prism-specific. >>> >>> The only "marketing bullet point" advantages to switching from Decora would likely be possibly enabling user-supplied shaders, and also using it for the greater needs of 3D apps that go beyond basic pixel-shaders. >>> >>> We'd love to be able to leverage Decora at runtime for user-supplied shaders, but that is a daunting amount of work since much of its actions rely on being able to use javac and/or a native C, GSL, or HLSL compiler to finish the work after the "decora compiler" does the translations - i.e. it translates form HSL into various other forms of source code and then runs other compilers on those. What we would probably have to do is to provide a way for a developer to run the decora compiler alongside his FX app and then include the various compiled alternative results, but that would require building on multiple platforms to produce all of the necessary files that are needed on an arbitrary target computer (minimally, building on Windows could net a GLS, an HLSL, and a Java version of the shader so that may be enough, but Mac developers would be out of luck for producing Win-specific output). We'd also have to do a security analysis of accepting compiled GSL and HLSL shaders in a non-privileged deployment (the least common denominator work around would be to only allow the Java-compiled versions of the shaders in the absence of a signed app, but the performance on those would likely be lower than something that the developer wrote themselves in hand-tuned Java). So, there are a lot of issues to consider and work on there before we could use Decora to provide user-supplied shaders. >>> >>> It may be less work to provide the GPU plugins for OSL than to figure out a workaround for the need for a compiler in Decora. We'd also leverage a larger development community for the more common parts of it. But, we'd also have to do a large security review of it every single time we brought over a new source drop from it and the complexity of that security review would involve analyzing the byte-code they produce and all elements of their runtime to make sure that a hostile OSL byte-code file couldn't break us. Using this "off the shelf" technology sounds attractive, but integrating a 3rd party solution often has its own headaches that you don't see when you are in the honeymoon phase after having read all of the marketing bullet points. :( >>> >>> I think a first task should be to get to the point where "Jim" isn't the only engineer with more than a passing understanding of what goes on with Decora under the hood - particularly since I don't have much time to do a more indepth analysis of competing technologies like this. Any volunteers that are fascinated by the world of shaders? >>> >>> ...jim >>> >>> On 2/14/13 1:52 PM, Richard Bair wrote: >>>> Hi Philip, >>>> >>>> Very interesting link. I didn't clone the repo and check, I'm not sure how long it has been around. We've had Decora for 5 years I think, so we may predate it substantially. >>>> >>>> Adobe also has a shader technology called Pixel Bender (http://www.adobe.com/devnet/pixelbender.html). The nice thing about their language is that their designer tools support Pixel Bender (and I guess AGAL and Pixel Bender 3D https://www.adobe.com/devnet/flashplayer/articles/what-is-agal.html). >>>> >>>> Although we use Decora for our shaders, we haven't done much more than keep it running. Jim Graham has had a number of ideas about things he wanted to do to move Decora forward (maybe he can chime in with those). >>>> >>>> There are Pros / Cons to each: >>>> >>>> OSL: >>>> Pros: >>>> - It looks like Sony Pictures is continuing to work on OSL, it wasn't a dump & forget. >>>> - Any time multiple companies can contribute to the same thing, the better chance of broader adoption (& tools etc) >>>> - Being able to leverage other's work instead of doing all the work ourselves could free us from some maintenance costs >>>> Cons: >>>> - Different design center -- doesn't yet support GPUs for instance >>>> - Lack of tooling >>>> >>>> Pixel Bender: >>>> Pros: >>>> - Great tooling support >>>> - Same design center -- shaders for 2D / 3D applications >>>> - Robust >>>> - Leverage Adobe's investment >>>> Cons: >>>> - License is proprietary according to wikipedia, not sure myself >>>> - Not sure of the runtime size >>>> - Needs to be vetted for security risks >>>> >>>> Decora: >>>> Pros: >>>> - Does exactly what we need -- no more >>>> - Small size (no features we don't need) >>>> Cons: >>>> - No time to invest in serious upgrades >>>> - No tooling support >>>> >>>> I think that's a fair portrayal of the situation. From a pragmatic perspective it seems like supporting Pixel Bender would be a great way forward, but I don't know what the license situation is (i.e.: would we have to provide our own compiler, or could we reuse their compiler? Can we even do that much?). Given we haven't had time to spend improving decora, replacing it would be even more work. >>>> >>>> However, I wouldn't be opposed to using OSL or Pixel Bender or any other system if the benefits outweigh the costs. >>>> >>>> Richard >>>> >>>> >>>> On Feb 14, 2013, at 1:49 AM, Philipp D?rfler wrote: >>>> >>>>> Here is the link: >>>>> [1] http://opensource.imageworks.com/?p=osl >>>>> >>>>> Am 14.02.2013 um 10:48 schrieb Philipp D?rfler : >>>>> >>>>>> Greetings, >>>>>> >>>>>> I stumbled upon the Open Shading Language [1] which seems to be an already established standard and uses LLVM to optimize shaders. I wonder why this is not used instead of / as a backend for Decora. Might you please shed some light on that? >>>>>> >>>>>> Cheers and thanks in advance >>>>>> ~ Philipp > > From hang.vo at oracle.com Thu Feb 14 16:48:16 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 15 Feb 2013 00:48:16 +0000 Subject: hg: openjfx/8/controls/rt: RT-14059 & RT-23120 : BarChart issue with non zero lower bound. Message-ID: <20130215004823.D252047AA8@hg.openjdk.java.net> Changeset: 6e7c79dda497 Author: Paru Somashekar Date: 2013-02-14 16:42 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6e7c79dda497 RT-14059 & RT-23120 : BarChart issue with non zero lower bound. ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java From hang.vo at oracle.com Thu Feb 14 22:08:52 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 15 Feb 2013 06:08:52 +0000 Subject: hg: openjfx/8/master/rt: 66 new changesets Message-ID: <20130215061103.C99DB47ABC@hg.openjdk.java.net> Changeset: 110d447262ce Author: Felipe Heidrich Date: 2013-02-05 13:33 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/110d447262ce [ECLIPSE_ONLY] javafx-beans & embedded swt open sourcing ! .classpath Changeset: 7132b587bdfb Author: David Hill Date: 2013-02-05 17:21 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7132b587bdfb RT-27891 Multithreading issues in Quantum between user thread and rendering thread. ! javafx-sg-prism/test/com/sun/javafx/sg/prism/TestGraphics.java Changeset: 7500b8ef6c34 Author: flar Date: 2013-02-05 16:30 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7500b8ef6c34 Ignore all webrev related files in .hgignore ! .hgignore Changeset: ac6952f8fee4 Author: rbair Date: 2013-02-05 17:45 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ac6952f8fee4 RT-28230: Media and Web need to be factored out of Prism - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGMediaView.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGNode.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/PrismMediaFrameHandler.java ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: a0b4e4f589b5 Author: rbair Date: 2013-02-05 18:40 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a0b4e4f589b5 Partial RT-28089: Write Script to auto-generate the new repository layout Summary: Moved javafx-beans and javafx-embed-swing and javafx-embed-swt to the public gradle generator ! build.gradle ! generator.gradle Changeset: 6af9a14ae71a Author: Martin Sladecek Date: 2013-02-06 13:22 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6af9a14ae71a RT-26799 Implementation of the hasProperties() method of the Node class ! javafx-ui-common/src/javafx/scene/Node.java Changeset: 811c479d634b Author: Artem Ananiev Date: 2013-02-06 20:00 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/811c479d634b Fix for RT-27209: Build failure in rt/deploy on Windows with VS2010 Express ! deploy/packager/winlauncher/javafxpackager.rc Changeset: f94ae4f94775 Author: Felipe Heidrich Date: 2013-02-06 11:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f94ae4f94775 [fix css warnings] fix missing semicolon in css files ! apps/experiments/ConferenceScheduleApp/src/com/javafx/experiments/scheduleapp/SchedulerStyleSheet.css ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/VirtualFlowTest.css Changeset: beb638445101 Author: rbair Date: 2013-02-06 16:15 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/beb638445101 [TEST ONLY] Updated Service tests -- made thread daemon, closed off running threads when done, and ignored the security manager test which appears to be bogus. ! javafx-concurrent/test/javafx/concurrent/ServiceLifecycleTest.java ! javafx-concurrent/test/javafx/concurrent/ServiceTestBase.java ! javafx-concurrent/test/javafx/concurrent/ServiceWithSecurityManagerTest.java Changeset: c6fb5c694336 Author: Richard Bair Date: 2013-02-06 17:42 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c6fb5c694336 Updated copyright headers on decora-compiler .g and .stg files ! decora-compiler/src/com/sun/scenario/effect/compiler/JSL.g ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/jogl/JOGLGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/rsl/RSLGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/prism/PrismGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MEJavaGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MENativeGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSEJavaGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSENativeGlue.stg Changeset: 74bb20d3b013 Author: Richard Bair Date: 2013-02-06 18:19 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/74bb20d3b013 Fixed Pagination* copyright headers ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/PaginationBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java Changeset: e1971713872e Author: Martin Sladecek Date: 2013-02-07 08:54 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e1971713872e Renamed AnimationMock in javafx-ui-common to avoid name clash with AnimationMock in javafx-anim + javafx-ui-common/test/unit/javafx/animation/AnimationDummy.java - javafx-ui-common/test/unit/javafx/animation/AnimationMock.java ! javafx-ui-common/test/unit/javafx/animation/ParallelTransitionTest.java ! javafx-ui-common/test/unit/javafx/animation/SequentialTransitionTest.java Changeset: 07a0f071ae9b Author: Martin Sladecek Date: 2013-02-07 09:47 +0100 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/07a0f071ae9b merge - javafx-ui-common/test/unit/javafx/animation/AnimationMock.java Changeset: 3919f556c448 Author: Pavel Safrata Date: 2013-02-07 13:19 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/3919f556c448 RT-28028: Affine internal state was broken after unsuccessful invert. ! javafx-ui-common/src/javafx/scene/transform/Affine.java ! javafx-ui-common/test/unit/javafx/scene/transform/AffineOperationsTest.java Changeset: ee1e4c0502d4 Author: jgodinez Date: 2013-02-07 08:37 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ee1e4c0502d4 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx//rt - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGMediaView.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/PrismMediaFrameHandler.java ! javafx-ui-common/src/javafx/scene/Node.java - javafx-ui-common/test/unit/javafx/animation/AnimationMock.java Changeset: 7507d0eacf70 Author: rbair Date: 2013-02-07 13:14 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7507d0eacf70 RT-28274: Open Source Decora Projects Summary: Moved Decora to open source + build-decora.xml ! build.gradle + decora-d3d/build.xml + decora-d3d/decora-d3d.iml + decora-d3d/nbproject/project.xml + decora-d3d/project.properties + decora-d3d/src/com/sun/scenario/effect/impl/hw/d3d/D3DShaderSource.java + decora-es2/build.xml + decora-es2/decora-es2.iml + decora-es2/nbproject/project.xml + decora-es2/project.properties + decora-es2/src/com/sun/scenario/effect/impl/es2/ES2ShaderSource.java + decora-jsw/build.xml + decora-jsw/decora-jsw.iml + decora-jsw/nbproject/project.xml + decora-jsw/project.properties + decora-jsw/src/com/sun/scenario/effect/impl/sw/java/JSWBoxBlurPeer.java + decora-jsw/src/com/sun/scenario/effect/impl/sw/java/JSWBoxShadowPeer.java + decora-jsw/src/com/sun/scenario/effect/impl/sw/java/JSWEffectPeer.java + decora-jsw/src/com/sun/scenario/effect/impl/sw/java/JSWLinearConvolvePeer.java + decora-jsw/src/com/sun/scenario/effect/impl/sw/java/JSWLinearConvolveShadowPeer.java + decora-jsw/src/com/sun/scenario/effect/impl/sw/java/JSWRendererDelegate.java + decora-prism-ps/build.xml + decora-prism-ps/decora-prism-ps.iml + decora-prism-ps/nbproject/project.xml + decora-prism-ps/project.properties + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPSDrawable.java + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPSEffectPeer.java + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPSOneSamplerPeer.java + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPSRenderer.java + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPSTwoSamplerPeer.java + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPSZeroSamplerPeer.java + decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPStoPSWDisplacementMapPeer.java + decora-prism-sw/build.xml + decora-prism-sw/decora-prism-sw.iml + decora-prism-sw/nbproject/project.xml + decora-prism-sw/project.properties + decora-prism-sw/src/com/sun/scenario/effect/impl/prism/sw/PSWDrawable.java + decora-prism-sw/src/com/sun/scenario/effect/impl/prism/sw/PSWRenderer.java + decora-prism/build.xml + decora-prism/decora-prism.iml + decora-prism/nbproject/project.xml + decora-prism/project.properties + decora-prism/src/com/sun/scenario/effect/impl/prism/PrCropPeer.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrDrawable.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrEffectHelper.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrFilterContext.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrFloodPeer.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrImage.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrMergePeer.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrReflectionPeer.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrRenderInfo.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrRenderer.java + decora-prism/src/com/sun/scenario/effect/impl/prism/PrTexture.java + decora-runtime/build.xml + decora-runtime/decora-runtime.iml + decora-runtime/generator/CompileBlend.java + decora-runtime/generator/CompileBoxBlur.java + decora-runtime/generator/CompileExternal.java + decora-runtime/generator/CompileGaussian.java + decora-runtime/generator/CompileJSL.java + decora-runtime/generator/CompileLinearConvolve.java + decora-runtime/generator/CompilePhong.java + decora-runtime/generator/CompileZoomRadialBlur.java + decora-runtime/jsl/Blend.jsl + decora-runtime/jsl/Blend_ADD.jsl + decora-runtime/jsl/Blend_BLUE.jsl + decora-runtime/jsl/Blend_COLOR_BURN.jsl + decora-runtime/jsl/Blend_COLOR_DODGE.jsl + decora-runtime/jsl/Blend_DARKEN.jsl + decora-runtime/jsl/Blend_DIFFERENCE.jsl + decora-runtime/jsl/Blend_EXCLUSION.jsl + decora-runtime/jsl/Blend_GREEN.jsl + decora-runtime/jsl/Blend_HARD_LIGHT.jsl + decora-runtime/jsl/Blend_LIGHTEN.jsl + decora-runtime/jsl/Blend_MULTIPLY.jsl + decora-runtime/jsl/Blend_OVERLAY.jsl + decora-runtime/jsl/Blend_RED.jsl + decora-runtime/jsl/Blend_SCREEN.jsl + decora-runtime/jsl/Blend_SOFT_LIGHT.jsl + decora-runtime/jsl/Blend_SRC_ATOP.jsl + decora-runtime/jsl/Blend_SRC_IN.jsl + decora-runtime/jsl/Blend_SRC_OUT.jsl + decora-runtime/jsl/Blend_SRC_OVER.jsl + decora-runtime/jsl/BoxBlur.jsl + decora-runtime/jsl/Brightpass.jsl + decora-runtime/jsl/ColorAdjust.jsl + decora-runtime/jsl/DisplacementMap.jsl + decora-runtime/jsl/GaussianBlur.jsl + decora-runtime/jsl/InvertMask.jsl + decora-runtime/jsl/LinearConvolve.jsl + decora-runtime/jsl/LinearConvolveShadow.jsl + decora-runtime/jsl/PerspectiveTransform.jsl + decora-runtime/jsl/PhongLighting.jsl + decora-runtime/jsl/SepiaTone.jsl + decora-runtime/jsl/ZoomRadialBlur.jsl + decora-runtime/nbproject/project.xml + decora-runtime/project.properties + decora-runtime/src/com/sun/scenario/effect/AbstractShadow.java + decora-runtime/src/com/sun/scenario/effect/Blend.java + decora-runtime/src/com/sun/scenario/effect/Bloom.java + decora-runtime/src/com/sun/scenario/effect/BoxBlur.java + decora-runtime/src/com/sun/scenario/effect/BoxShadow.java + decora-runtime/src/com/sun/scenario/effect/Brightpass.java + decora-runtime/src/com/sun/scenario/effect/Color4f.java + decora-runtime/src/com/sun/scenario/effect/ColorAdjust.java + decora-runtime/src/com/sun/scenario/effect/CoreEffect.java + decora-runtime/src/com/sun/scenario/effect/Crop.java + decora-runtime/src/com/sun/scenario/effect/DelegateEffect.java + decora-runtime/src/com/sun/scenario/effect/DisplacementMap.java + decora-runtime/src/com/sun/scenario/effect/DropShadow.java + decora-runtime/src/com/sun/scenario/effect/Effect.java + decora-runtime/src/com/sun/scenario/effect/FilterContext.java + decora-runtime/src/com/sun/scenario/effect/FilterEffect.java + decora-runtime/src/com/sun/scenario/effect/Filterable.java + decora-runtime/src/com/sun/scenario/effect/FloatMap.java + decora-runtime/src/com/sun/scenario/effect/Flood.java + decora-runtime/src/com/sun/scenario/effect/GaussianBlur.java + decora-runtime/src/com/sun/scenario/effect/GaussianShadow.java + decora-runtime/src/com/sun/scenario/effect/GeneralShadow.java + decora-runtime/src/com/sun/scenario/effect/Glow.java + decora-runtime/src/com/sun/scenario/effect/Identity.java + decora-runtime/src/com/sun/scenario/effect/ImageData.java + decora-runtime/src/com/sun/scenario/effect/ImageDataRenderer.java + decora-runtime/src/com/sun/scenario/effect/InnerShadow.java + decora-runtime/src/com/sun/scenario/effect/InvertMask.java + decora-runtime/src/com/sun/scenario/effect/Merge.java + decora-runtime/src/com/sun/scenario/effect/MotionBlur.java + decora-runtime/src/com/sun/scenario/effect/Offset.java + decora-runtime/src/com/sun/scenario/effect/PerspectiveTransform.java + decora-runtime/src/com/sun/scenario/effect/PhongLighting.java + decora-runtime/src/com/sun/scenario/effect/Reflection.java + decora-runtime/src/com/sun/scenario/effect/SepiaTone.java + decora-runtime/src/com/sun/scenario/effect/ZoomRadialBlur.java + decora-runtime/src/com/sun/scenario/effect/impl/BufferUtil.java + decora-runtime/src/com/sun/scenario/effect/impl/EffectPeer.java + decora-runtime/src/com/sun/scenario/effect/impl/HeapImage.java + decora-runtime/src/com/sun/scenario/effect/impl/ImagePool.java + decora-runtime/src/com/sun/scenario/effect/impl/Renderer.java + decora-runtime/src/com/sun/scenario/effect/impl/RendererFactory.java + decora-runtime/src/com/sun/scenario/effect/impl/hw/Drawable.java + decora-runtime/src/com/sun/scenario/effect/impl/hw/RendererDelegate.java + decora-runtime/src/com/sun/scenario/effect/impl/hw/Shader.java + decora-runtime/src/com/sun/scenario/effect/impl/hw/ShaderSource.java + decora-runtime/src/com/sun/scenario/effect/impl/hw/Texture.java + decora-runtime/src/com/sun/scenario/effect/impl/state/AccessHelper.java + decora-runtime/src/com/sun/scenario/effect/impl/state/BoxBlurState.java + decora-runtime/src/com/sun/scenario/effect/impl/state/BoxShadowState.java + decora-runtime/src/com/sun/scenario/effect/impl/state/GaussianBlurState.java + decora-runtime/src/com/sun/scenario/effect/impl/state/GaussianShadowState.java + decora-runtime/src/com/sun/scenario/effect/impl/state/HVSeparableKernel.java + decora-runtime/src/com/sun/scenario/effect/impl/state/LinearConvolveKernel.java + decora-runtime/src/com/sun/scenario/effect/impl/state/LinearConvolvePeer.java + decora-runtime/src/com/sun/scenario/effect/impl/state/LinearConvolveShadowPeer.java + decora-runtime/src/com/sun/scenario/effect/impl/state/MotionBlurState.java + decora-runtime/src/com/sun/scenario/effect/impl/state/PerspectiveTransformState.java + decora-runtime/src/com/sun/scenario/effect/impl/state/ZoomRadialBlurState.java + decora-runtime/src/com/sun/scenario/effect/impl/sw/RendererDelegate.java + decora-runtime/src/com/sun/scenario/effect/light/DistantLight.java + decora-runtime/src/com/sun/scenario/effect/light/Light.java + decora-runtime/src/com/sun/scenario/effect/light/PointLight.java + decora-runtime/src/com/sun/scenario/effect/light/SpotLight.java + decora-runtime/test/com/sun/scenario/effect/Test1.java + decora-runtime/test/com/sun/scenario/effect/Test2.java + decora-runtime/test/com/sun/scenario/effect/rt_5239/RT_5239Test.java + decora-runtime/testjsl/Test1.jsl + decora-runtime/testjsl/Test2.jsl + decora-sse-native/Makefile + decora-sse-native/SSEBoxBlurPeer.cc + decora-sse-native/SSEBoxShadowPeer.cc + decora-sse-native/SSELinearConvolvePeer.cc + decora-sse-native/SSELinearConvolveShadowPeer.cc + decora-sse-native/SSEUtils.cc + decora-sse-native/SSEUtils.h + decora-sse-native/nbproject/Makefile-Debug.mk + decora-sse-native/nbproject/Makefile-Release.mk + decora-sse-native/nbproject/Makefile-impl.mk + decora-sse-native/nbproject/configurations.xml + decora-sse-native/nbproject/project.xml + decora-sse/build-macosx.xml + decora-sse/build-windows.xml + decora-sse/build.xml + decora-sse/decora-sse.iml + decora-sse/nbproject/project.xml + decora-sse/project.properties + decora-sse/src/com/sun/scenario/effect/impl/sw/sse/SSEBoxBlurPeer.java + decora-sse/src/com/sun/scenario/effect/impl/sw/sse/SSEBoxShadowPeer.java + decora-sse/src/com/sun/scenario/effect/impl/sw/sse/SSEEffectPeer.java + decora-sse/src/com/sun/scenario/effect/impl/sw/sse/SSELinearConvolvePeer.java + decora-sse/src/com/sun/scenario/effect/impl/sw/sse/SSELinearConvolveShadowPeer.java + decora-sse/src/com/sun/scenario/effect/impl/sw/sse/SSERendererDelegate.java ! generator.gradle ! javafx-ui-controls/src/javafx/scene/control/Pagination.java Changeset: 14da6e9bbcfe Author: rbair Date: 2013-02-07 14:57 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/14da6e9bbcfe Updated project properties to point to local directories instead of in rt-closed. Oops. ! decora-d3d/project.properties ! decora-es2/project.properties ! decora-jsw/project.properties ! decora-prism-ps/project.properties ! decora-prism-sw/project.properties ! decora-prism/project.properties ! decora-sse/project.properties Changeset: f5dae05e32d8 Author: rbair Date: 2013-02-07 15:52 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f5dae05e32d8 Additional path errors. What I did wrong was not update the build-closed.xml files of projects referring to decora. I also need to adjust the decora projects so they have a build-closed.xml file. I will update the project to make sure it builds for open source devs separately. ! javafx-sg-common/build-closed.xml ! javafx-sg-prism/build-closed.xml ! javafx-ui-charts/project.properties ! javafx-ui-common/build-closed.xml ! test-stub-toolkit/build-closed.xml ! test-stub-toolkit/project.properties Changeset: 610dbac8d6fc Author: Felipe Heidrich Date: 2013-02-07 16:13 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/610dbac8d6fc [ECLIPSE ONLY] fixing classpath for decora ! .classpath Changeset: 4446f7960af3 Author: kcr Date: 2013-02-07 16:35 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4446f7960af3 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-sg-prism/src/com/sun/javafx/sg/prism/NGMediaView.java - javafx-sg-prism/src/com/sun/javafx/sg/prism/PrismMediaFrameHandler.java - javafx-ui-common/test/unit/javafx/animation/AnimationMock.java Changeset: 0f328860af65 Author: kcr Date: 2013-02-07 17:13 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/0f328860af65 RT-17401: 3D geometry support -- initial commit, only d3d is implemented Contributed-by: jada - javafx-geom/src/com/sun/javafx/geom/CameraImpl.java - javafx-geom/src/com/sun/javafx/geom/ParallelCameraImpl.java - javafx-geom/src/com/sun/javafx/geom/PerspectiveCameraImpl.java ! javafx-geom/src/com/sun/javafx/geom/PickRay.java ! javafx-geom/src/com/sun/javafx/geom/transform/GeneralTransform3D.java + javafx-sg-common/src/com/sun/javafx/sg/PGAmbientLight.java + javafx-sg-common/src/com/sun/javafx/sg/PGBox.java + javafx-sg-common/src/com/sun/javafx/sg/PGCamera.java + javafx-sg-common/src/com/sun/javafx/sg/PGCylinder.java + javafx-sg-common/src/com/sun/javafx/sg/PGLightBase.java + javafx-sg-common/src/com/sun/javafx/sg/PGMeshView.java + javafx-sg-common/src/com/sun/javafx/sg/PGParallelCamera.java + javafx-sg-common/src/com/sun/javafx/sg/PGPerspectiveCamera.java + javafx-sg-common/src/com/sun/javafx/sg/PGPhongMaterial.java + javafx-sg-common/src/com/sun/javafx/sg/PGPointLight.java + javafx-sg-common/src/com/sun/javafx/sg/PGShape3D.java + javafx-sg-common/src/com/sun/javafx/sg/PGSphere.java + javafx-sg-common/src/com/sun/javafx/sg/PGTriangleMesh.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGAmbientLight.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGBox.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGCamera.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGCylinder.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGGroup.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGLightBase.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGMeshView.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGNode.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGParallelCamera.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGPerspectiveCamera.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGPhongMaterial.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGPointLight.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGRegion.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGShape3D.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGSphere.java + javafx-sg-prism/src/com/sun/javafx/sg/prism/NGTriangleMesh.java ! javafx-sg-prism/test/com/sun/javafx/sg/prism/TestGraphics.java ! javafx-ui-common/src/com/sun/javafx/scene/DirtyBits.java ! javafx-ui-common/src/com/sun/javafx/scene/EnteredExitedHandler.java ! javafx-ui-common/src/com/sun/javafx/scene/input/InputEventUtils.java + javafx-ui-common/src/com/sun/javafx/scene/input/PickResultChooser.java ! javafx-ui-common/src/com/sun/javafx/tk/DummyToolkit.java ! javafx-ui-common/src/com/sun/javafx/tk/TKScene.java ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java + javafx-ui-common/src/javafx/scene/AmbientLight.java ! javafx-ui-common/src/javafx/scene/Camera.java + javafx-ui-common/src/javafx/scene/LightBase.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/ParallelCamera.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/PerspectiveCamera.java + javafx-ui-common/src/javafx/scene/PointLight.java ! javafx-ui-common/src/javafx/scene/Scene.java + javafx-ui-common/src/javafx/scene/SubScene.java ! javafx-ui-common/src/javafx/scene/input/ContextMenuEvent.java ! javafx-ui-common/src/javafx/scene/input/DragEvent.java ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/KeyEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseDragEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java + javafx-ui-common/src/javafx/scene/input/PickResult.java ! javafx-ui-common/src/javafx/scene/input/RotateEvent.java ! javafx-ui-common/src/javafx/scene/input/ScrollEvent.java ! javafx-ui-common/src/javafx/scene/input/SwipeEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchPoint.java ! javafx-ui-common/src/javafx/scene/input/ZoomEvent.java ! javafx-ui-common/src/javafx/scene/layout/Region.java + javafx-ui-common/src/javafx/scene/paint/Material.java + javafx-ui-common/src/javafx/scene/paint/PhongMaterial.java + javafx-ui-common/src/javafx/scene/shape/Box.java + javafx-ui-common/src/javafx/scene/shape/CullFace.java + javafx-ui-common/src/javafx/scene/shape/Cylinder.java + javafx-ui-common/src/javafx/scene/shape/DrawMode.java + javafx-ui-common/src/javafx/scene/shape/Mesh.java + javafx-ui-common/src/javafx/scene/shape/MeshView.java + javafx-ui-common/src/javafx/scene/shape/PredefinedMeshManager.java + javafx-ui-common/src/javafx/scene/shape/Shape3D.java + javafx-ui-common/src/javafx/scene/shape/Sphere.java + javafx-ui-common/src/javafx/scene/shape/TriangleMesh.java ! javafx-ui-common/test/unit/javafx/scene/MouseTest.java + javafx-ui-common/test/unit/javafx/scene/MouseTest3D.java ! javafx-ui-common/test/unit/javafx/scene/NodeTest.java ! javafx-ui-common/test/unit/javafx/scene/Scenegraph_eventHandlers_Test.java ! javafx-ui-common/test/unit/javafx/scene/input/ContextMenuEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/DragAndDropTest.java ! javafx-ui-common/test/unit/javafx/scene/input/MouseDragEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/RotateEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/ScrollEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/SwipeEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/TestNode.java ! javafx-ui-common/test/unit/javafx/scene/input/TouchEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/ZoomEventTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/ScrollPaneSkinTest.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/VirtualFlowTest.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubBox.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubCylinder.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubMeshView.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubScene.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubShape3D.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubSphere.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java + test-stub-toolkit/src/com/sun/javafx/pgstub/StubTriangleMesh.java Changeset: bdecfce65a2f Author: Richard Bair Date: 2013-02-08 09:40 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/bdecfce65a2f RT-28298: Remove PGWebView - javafx-sg-common/src/com/sun/javafx/sg/PGWebView.java - test-stub-toolkit/src/com/sun/javafx/pgstub/StubWebView.java Changeset: 7677be81f484 Author: Yao Wang Date: 2013-02-08 11:17 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7677be81f484 RT-25524 LOD Helper ! javafx-sg-common/src/com/sun/javafx/sg/PGCamera.java ! javafx-sg-prism/src/com/sun/javafx/sg/prism/NGCamera.java ! javafx-ui-common/src/javafx/scene/Camera.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/shape/Cylinder.java ! javafx-ui-common/src/javafx/scene/shape/Sphere.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: afe9c4479408 Author: Felipe Heidrich Date: 2013-02-08 16:44 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/afe9c4479408 RT-23818: com.sun.javafx.geom Area and Rectangle classes define equals() method but not hashCode() ! javafx-geom/cagsrc.double/com/sun/javafx/geom/Area.java ! javafx-geom/src/com/sun/javafx/geom/Rectangle.java Changeset: d448980b1a24 Author: rbair Date: 2013-02-08 17:37 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d448980b1a24 Fix of build scripts for the open source builds. People should now be able to build successfully using ant on OpenJFX (see updated wiki for latest). ! build-decora.xml ! build-defs.xml ! build.xml ! common.properties + decora-compiler/build-closed.xml + decora-compiler/build-common.xml ! decora-compiler/build.xml ! decora-compiler/project.properties + decora-d3d/build-closed.xml + decora-d3d/build-common.xml ! decora-d3d/build.xml + decora-es2/build-closed.xml + decora-es2/build-common.xml ! decora-es2/build.xml + decora-jsw/build-closed.xml + decora-jsw/build-common.xml ! decora-jsw/build.xml + decora-prism-ps/build-closed.xml + decora-prism-ps/build-common.xml ! decora-prism-ps/build.xml ! decora-prism-ps/project.properties + decora-prism-sw/build-closed.xml + decora-prism-sw/build-common.xml ! decora-prism-sw/build.xml ! decora-prism-sw/project.properties + decora-prism/build-closed.xml + decora-prism/build-common.xml ! decora-prism/build.xml ! decora-prism/project.properties + decora-runtime/build-closed.xml + decora-runtime/build-common.xml ! decora-runtime/build.xml ! decora-runtime/project.properties + decora-sse/build-closed.xml + decora-sse/build-common.xml ! decora-sse/build.xml ! decora-sse/project.properties ! javafx-anim/project.properties ! javafx-annotation-processor/build-common.xml ! javafx-annotation-processor/project.properties ! javafx-beans-dt/build-common.xml ! javafx-beans-dt/build.xml ! javafx-beans-dt/project.properties ! javafx-beans/project.properties ! javafx-concurrent/build-closed.xml ! javafx-concurrent/build-common.xml ! javafx-concurrent/build.xml ! javafx-concurrent/project.properties ! javafx-designtime/project.properties ! javafx-embed-swing/project.properties ! javafx-fxml/project.properties ! javafx-geom/build-closed.xml ! javafx-sg-common/build-closed.xml ! javafx-sg-common/project.properties ! javafx-sg-prism/build-closed.xml ! javafx-sg-prism/build-common.xml ! javafx-sg-prism/build.xml ! javafx-sg-prism/project.properties ! javafx-ui-charts/project.properties ! javafx-ui-common/build.xml ! javafx-ui-common/project.properties ! javafx-ui-controls/project.properties ! javafx-util-converter/project.properties ! pisces/build-closed.xml ! pisces/build-common.xml ! pisces/build.xml ! pisces/project.properties ! test-stub-toolkit/project.properties Changeset: 03cc45b0c481 Author: rbair Date: 2013-02-09 23:14 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/03cc45b0c481 RT-28308: decora-d3d classes not included in jfxrt.jar Summary: updated the build-closed file to determine correctly whether on windows and therefore whether to compile the d3d classes. Verified the fix by inspecting the jar after compilation to ensure the files are there. ! decora-d3d/build-closed.xml Changeset: a69414a64ca8 Author: Seeon Birger Date: 2013-02-10 17:40 +0200 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/a69414a64ca8 Fix RT-27951 - Enable Virtual keyboard only for touch devices (depending on ConditionalFeature.VIRTUAL_KEYBOARD) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java Changeset: c8109f961d4d Author: Pavel Safrata Date: 2013-02-11 08:16 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c8109f961d4d RT-9383: Event constructors finalized. ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/DragEvent.java ! javafx-ui-common/src/javafx/scene/input/GestureEvent.java ! javafx-ui-common/src/javafx/scene/input/KeyEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseDragEvent.java ! javafx-ui-common/src/javafx/scene/input/MouseEvent.java ! javafx-ui-common/src/javafx/scene/input/RotateEvent.java ! javafx-ui-common/src/javafx/scene/input/ScrollEvent.java ! javafx-ui-common/src/javafx/scene/input/SwipeEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchEvent.java ! javafx-ui-common/src/javafx/scene/input/TouchPoint.java ! javafx-ui-common/src/javafx/scene/input/ZoomEvent.java ! javafx-ui-common/test/unit/com/sun/javafx/test/MouseEventGenerator.java ! javafx-ui-common/test/unit/javafx/scene/input/DragAndDropTest.java ! javafx-ui-common/test/unit/javafx/scene/input/MouseDragEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/MouseEventTest.java ! javafx-ui-common/test/unit/javafx/scene/input/TouchEventTest.java Changeset: 6d112cd51f1b Author: Artem Ananiev Date: 2013-02-11 14:02 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6d112cd51f1b Fix for RT-26745: Clean up initialization of QuantumClipboard Reviewed-by: Alexey Utkin, Pavel Safrata ! javafx-ui-common/src/com/sun/javafx/tk/TKClipboard.java ! javafx-ui-common/src/com/sun/javafx/tk/TKDragGestureListener.java ! javafx-ui-common/src/com/sun/javafx/tk/TKDragSourceListener.java ! javafx-ui-common/src/com/sun/javafx/tk/TKDropTargetListener.java ! javafx-ui-common/src/com/sun/javafx/tk/TKScene.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/input/Clipboard.java ! javafx-ui-common/src/javafx/scene/input/Dragboard.java ! javafx-ui-common/test/unit/javafx/scene/input/DragAndDropTest.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubScene.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubToolkit.java Changeset: b10019f7ff27 Author: jgodinez Date: 2013-02-11 10:58 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b10019f7ff27 Renamed printing unit test directory. ! javafx-ui-common/project.properties + javafx-ui-common/test/unit/test/javafx/print/JobSettingsTest.java + javafx-ui-common/test/unit/test/javafx/print/PrinterJobTest.java - javafx-ui-common/test/unit/test/javax/print/JobSettingsTest.java - javafx-ui-common/test/unit/test/javax/print/PrinterJobTest.java Changeset: cc3702cbc8a0 Author: Chien Yang Date: 2013-02-11 15:31 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/cc3702cbc8a0 Fix to RT-28303: Use TempState rather than instance variables for projtx and viewport needed by LOD helper method. Approved by Kevin ! javafx-ui-common/src/com/sun/javafx/TempState.java ! javafx-ui-common/src/javafx/scene/Node.java Changeset: dafee5d5fe66 Author: Chien Yang Date: 2013-02-11 17:46 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/dafee5d5fe66 Fixed to RT-27113: Netbeans project dependency information got lost .... Approved by Richard. ! javafx-geom/project.properties ! javafx-sg-common/project.properties ! javafx-sg-prism/project.properties ! javafx-ui-common/project.properties Changeset: 91891157486b Author: rbair Date: 2013-02-11 17:50 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/91891157486b RT-28344: NonNull annotation is unused and should be removed ! build.gradle - javafx-beans/src/com/sun/javafx/beans/annotations/NonNull.java Changeset: d28efedf73e3 Author: "Jasper Potts" Date: 2013-02-06 11:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d28efedf73e3 RT-28252: ScrollBar Thumb doesn't snap to pixel ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java Changeset: fb2dc010dd91 Author: "Jasper Potts" Date: 2013-02-06 13:12 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/fb2dc010dd91 Fixed RT-28163: [SplitMenuButton] Arrow button rendering has changed. ! apps/experiments/Modena/src/modena/SamplePage.java ! javafx-ui-controls/src/javafx/scene/control/MenuButton.java Changeset: 30fb7b4a2195 Author: "Jasper Potts" Date: 2013-02-06 19:18 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/30fb7b4a2195 Fixed RT-28255: Remove PSEUDO_CLASS_OVERRIDE from Node ! apps/experiments/Modena/src/modena/SamplePage.java ! javafx-ui-common/src/javafx/scene/Node.java Changeset: 4bd39477ff95 Author: "Jasper Potts" Date: 2013-02-07 14:33 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4bd39477ff95 Modena: Added extra border to scroll bar, adjusted height of some controls to match new Button height. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 723b68315cb2 Author: Paru Somashekar Date: 2013-02-07 16:53 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/723b68315cb2 RT-23847 axis tickLabelRotation does not work RT-24256 Adding RadioMenuItem to ToggleGroup causes IAE ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java ! javafx-ui-controls/src/javafx/scene/control/RadioMenuItem.java Changeset: 1b745a96e73b Author: Paru Somashekar Date: 2013-02-07 18:57 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/1b745a96e73b javadoc for installing tooltips on XYChart symbols. ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java Changeset: 40e12d6e802c Author: mickf Date: 2013-02-08 15:35 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/40e12d6e802c RT-25892 : ListView(touch): When scrolling a list, scroll bars are not visible ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/embedded.css Changeset: 656c76d07b42 Author: mo.chicharro Date: 2013-02-08 16:45 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/656c76d07b42 Modena tweak - added -fx-shadow-highlight-color to SplitMenuButton ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: b86a515c40c6 Author: mo.chicharro Date: 2013-02-08 18:58 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b86a515c40c6 Modena tweaks - added new alignment visual showing spacing of arrows from right edge of controls ! apps/experiments/Modena/src/modena/SameHeightTest.fxml Changeset: eeafbb33986a Author: mo.chicharro Date: 2013-02-08 19:00 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/eeafbb33986a Modena tweaks - fix for RT-28299: Spacing of arrows from right edge of controls ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 372e8ef0a10d Author: David Grieve Date: 2013-02-08 17:37 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/372e8ef0a10d RT-21094: move Styleable to javafx.css package ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java ! javafx-ui-charts/src/javafx/scene/chart/Chart.java ! javafx-ui-charts/src/javafx/scene/chart/LineChart.java ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java ! javafx-ui-charts/src/javafx/scene/chart/StackedAreaChart.java ! javafx-ui-charts/src/javafx/scene/chart/StackedBarChart.java ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java ! javafx-ui-common/src/com/sun/javafx/css/CssError.java ! javafx-ui-common/src/com/sun/javafx/css/StyleConverterImpl.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java - javafx-ui-common/src/com/sun/javafx/css/Styleable.java ! javafx-ui-common/src/com/sun/javafx/css/converters/FontConverter.java ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java ! javafx-ui-common/src/javafx/css/CssMetaData.java ! javafx-ui-common/src/javafx/css/FontCssMetaData.java ! javafx-ui-common/src/javafx/css/SimpleStyleableBooleanProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableDoubleProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableFloatProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableIntegerProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableLongProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableObjectProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableStringProperty.java + javafx-ui-common/src/javafx/css/Styleable.java ! javafx-ui-common/src/javafx/css/StyleableProperty.java ! javafx-ui-common/src/javafx/css/package.html ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/src/javafx/scene/layout/Background.java ! javafx-ui-common/src/javafx/scene/layout/BackgroundConverter.java ! javafx-ui-common/src/javafx/scene/layout/Border.java ! javafx-ui-common/src/javafx/scene/layout/BorderConverter.java ! javafx-ui-common/src/javafx/scene/layout/FlowPane.java ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/src/javafx/scene/layout/HBox.java ! javafx-ui-common/src/javafx/scene/layout/Region.java ! javafx-ui-common/src/javafx/scene/layout/StackPane.java ! javafx-ui-common/src/javafx/scene/layout/TilePane.java ! javafx-ui-common/src/javafx/scene/layout/VBox.java ! javafx-ui-common/src/javafx/scene/shape/Rectangle.java ! javafx-ui-common/src/javafx/scene/shape/Shape.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/src/javafx/scene/text/TextFlow.java ! javafx-ui-common/test/unit/com/sun/javafx/css/CssMetaDataTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/TestNode.java ! javafx-ui-common/test/unit/com/sun/javafx/css/TestNodeBase.java ! javafx-ui-common/test/unit/com/sun/javafx/test/CssMethodsTestBase.java ! javafx-ui-common/test/unit/javafx/scene/CSSNode.java ! javafx-ui-common/test/unit/javafx/scene/Node_effectiveOrientation_Css_Test.java ! javafx-ui-common/test/unit/javafx/scene/Node_onInvalidate_Test.java ! javafx-ui-common/test/unit/javafx/scene/shape/ShapeTest.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CellSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledImpl.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/javafx/scene/chart/Axis.java ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java ! javafx-ui-controls/src/javafx/scene/chart/NumberAxis.java ! javafx-ui-controls/src/javafx/scene/chart/ValueAxis.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/MenuBar.java ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/ScrollBar.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java ! javafx-ui-controls/src/javafx/scene/control/Separator.java ! javafx-ui-controls/src/javafx/scene/control/SkinBase.java ! javafx-ui-controls/src/javafx/scene/control/Slider.java ! javafx-ui-controls/src/javafx/scene/control/SplitPane.java ! javafx-ui-controls/src/javafx/scene/control/Tab.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TableColumnBase.java ! javafx-ui-controls/src/javafx/scene/control/TextArea.java ! javafx-ui-controls/src/javafx/scene/control/TextField.java ! javafx-ui-controls/src/javafx/scene/control/TextInputControl.java ! javafx-ui-controls/src/javafx/scene/control/TitledPane.java ! javafx-ui-controls/src/javafx/scene/control/ToolBar.java ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabeledImplTest.java ! javafx-ui-controls/test/javafx/scene/control/ControlTest.java Changeset: f437c9bdc79f Author: Paru Somashekar Date: 2013-02-11 16:58 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f437c9bdc79f RT-25533 : Menu javadoc & RT-26576 ColorPicker RGB components get incorrect value. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java ! javafx-ui-controls/src/javafx/scene/control/Menu.java Changeset: e4464b4f804c Author: jgiles Date: 2013-02-07 10:39 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e4464b4f804c RT-28016: JAVAFX TABLEVIEW .SORTING ARROW SHIFTS TO THE WRONG COLUMN ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java Changeset: 4f89dec868cb Author: jgiles Date: 2013-02-07 13:56 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/4f89dec868cb RT-28250: [TreeView, TreeTableView] expand/collapse arrows have a mind of their own ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java Changeset: 9b02ded253ac Author: jgiles Date: 2013-02-07 16:22 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/9b02ded253ac Minor tweaks to combat RT-28213: 8.0-controls-scrum-287: memory leak in ComboBox. Unfortunately the perf regression is to undo a functional regression, so there isn't much more that can be done here. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxBaseSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java Changeset: 5b785c886979 Author: jgiles Date: 2013-02-08 09:39 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5b785c886979 RT-24916: TableView.scrollTo(TableColumn) Review-by: jgiles Contributed-by: Tom Schindl ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualContainerBase.java ! javafx-ui-controls/src/javafx/scene/control/ControlUtils.java ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java ! javafx-ui-controls/src/javafx/scene/control/ScrollToEvent.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java Changeset: e6475877a2cc Author: jgiles Date: 2013-02-08 10:55 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/e6475877a2cc RT-27585: [TreeTableView] Changes in editable cell are not commited. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java Changeset: ba8319f15c9b Author: jgiles Date: 2013-02-08 13:38 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ba8319f15c9b RT-22716: Scene graph elements are not garbage collected (Memory Leak) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java Changeset: f6a082cf07a3 Author: jgiles Date: 2013-02-11 13:21 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/f6a082cf07a3 RT-27966: TabPane setTabMaxWidth hides close button ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java Changeset: d46f39fd37eb Author: jgiles Date: 2013-02-11 13:53 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/d46f39fd37eb RT-27606: [TreeTableView] Double click on editable collapses the row. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java Changeset: cee06e42e4f3 Author: jgiles Date: 2013-02-11 14:58 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/cee06e42e4f3 RT-27820: ListView selectionModel selectedItems list returns incorrect size ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: 722cc3746842 Author: jgiles Date: 2013-02-12 14:33 +1300 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/722cc3746842 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java Changeset: ea4b9aedce67 Author: "Jasper Potts" Date: 2013-02-11 20:21 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/ea4b9aedce67 Modena: tweek to body gradient ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 5d7d7686a2c3 Author: "Jasper Potts" Date: 2013-02-11 20:21 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/5d7d7686a2c3 Modena: test app netbeans project updates ! apps/experiments/Modena/nbproject/build-impl.xml ! apps/experiments/Modena/nbproject/configs/Run_as_WebStart.properties ! apps/experiments/Modena/nbproject/configs/Run_in_Browser.properties ! apps/experiments/Modena/nbproject/genfiles.properties ! apps/experiments/Modena/nbproject/jfx-impl.xml + apps/experiments/Modena/nbproject/jfx-impl_backup_1.xml ! apps/experiments/Modena/nbproject/project.properties ! apps/experiments/Modena/src/modena/TestApp.css Changeset: 13ee6aa1865f Author: "Jasper Potts" Date: 2013-02-11 20:30 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/13ee6aa1865f MADE MODENA DEFAULT THEME. If there are issues with this change, it can easily be backed out by changing line 474 of com.sun.javafx.application.PlatformImpl back to Caspian. ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java Changeset: 2275a38d56ca Author: David Grieve Date: 2013-02-12 15:28 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/2275a38d56ca [TEST-ONLY] syntax error in modena.css caused some failures. Added @Ignore to tests that still failed and created bugs for removing the @Ignore. Also changed build script to convert modena.css to modena.bss ! javafx-ui-controls/build-common.xml ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css ! javafx-ui-controls/test/javafx/scene/control/AccordionTest.java ! javafx-ui-controls/test/javafx/scene/control/ColorPickerTest.java Changeset: 7dc3847a8025 Author: David Grieve Date: 2013-02-12 23:29 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/7dc3847a8025 RT-21094: need to mark some impl_ methods as deprecated ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java Changeset: 103768088c59 Author: David Grieve Date: 2013-02-13 00:35 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/103768088c59 [TEST-ONLY] Add @Ignore to StackedAreaChartTest and StackedBarChartTest pending RT-28373 ! javafx-ui-charts/test/javafx/scene/chart/StackedAreaChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/StackedBarChartTest.java Changeset: 6dabd87c27d6 Author: mo.chicharro Date: 2013-02-13 12:36 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/6dabd87c27d6 Modena tweaks - Added TitledPane to SameHeightTest.fxml for height comparison ! apps/experiments/Modena/src/modena/SameHeightTest.fxml Changeset: 14dda2ac593b Author: mo.chicharro Date: 2013-02-13 12:37 +0000 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/14dda2ac593b Modena Tweaks - Adjusted height of TitledPane ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: c97dc773b5a4 Author: David Grieve Date: 2013-02-13 16:37 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/c97dc773b5a4 RT-28391: set default platform to caspian. backed out @Ignore on unit test that failed due to modena. ! javafx-ui-charts/test/javafx/scene/chart/StackedAreaChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/StackedBarChartTest.java ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-controls/test/javafx/scene/control/AccordionTest.java ! javafx-ui-controls/test/javafx/scene/control/ColorPickerTest.java Changeset: b2dfc3891302 Author: David Grieve Date: 2013-02-13 18:35 -0500 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/b2dfc3891302 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-ui-common/src/com/sun/javafx/css/Styleable.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/layout/Region.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java Changeset: 82735d8f445e Author: hudson Date: 2013-02-14 20:12 -0800 URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/82735d8f445e Added tag 8.0-b77 for changeset b2dfc3891302 ! .hgtags From hang.vo at oracle.com Fri Feb 15 08:03:45 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 15 Feb 2013 16:03:45 +0000 Subject: hg: openjfx/8/controls/rt: Modena Tweaks - adjusted appearance of focus Message-ID: <20130215160349.2123D47AEA@hg.openjdk.java.net> Changeset: b98188e0f5eb Author: mo.chicharro Date: 2013-02-15 15:47 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b98188e0f5eb Modena Tweaks - adjusted appearance of focus ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From hang.vo at oracle.com Fri Feb 15 08:33:11 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 15 Feb 2013 16:33:11 +0000 Subject: hg: openjfx/8/controls/rt: Modena Tweaks - adjusted tab order for ui-mosaic.fxml inside Modena app Message-ID: <20130215163316.0511647AED@hg.openjdk.java.net> Changeset: b270d1aab6c6 Author: mo.chicharro Date: 2013-02-15 16:19 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b270d1aab6c6 Modena Tweaks - adjusted tab order for ui-mosaic.fxml inside Modena app ! apps/experiments/Modena/src/modena/ui-mosaic.fxml From hang.vo at oracle.com Fri Feb 15 08:48:45 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 15 Feb 2013 16:48:45 +0000 Subject: hg: openjfx/8/controls/rt: RT-25892 - ListView(touch): When scrolling a list, scroll bars are not visible Message-ID: <20130215164850.0E4BB47AF5@hg.openjdk.java.net> Changeset: 360ae0cedf47 Author: mickf Date: 2013-02-15 16:44 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/360ae0cedf47 RT-25892 - ListView(touch): When scrolling a list, scroll bars are not visible ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualFlow.java From hang.vo at oracle.com Fri Feb 15 09:33:18 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 15 Feb 2013 17:33:18 +0000 Subject: hg: openjfx/8/controls/rt: RT-25883 - Default button works on Mac runtime, not on Windows, when same button is assigned default & cancel. Message-ID: <20130215173322.3280247AFC@hg.openjdk.java.net> Changeset: e34f07f82ec2 Author: mickf Date: 2013-02-15 17:17 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/e34f07f82ec2 RT-25883 - Default button works on Mac runtime, not on Windows, when same button is assigned default & cancel. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/ButtonBehavior.java From hang.vo at oracle.com Fri Feb 15 10:48:02 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 15 Feb 2013 18:48:02 +0000 Subject: hg: openjfx/8/graphics/rt: RT-26853: getNativeDestHandle and getNativeSourceHandle() should be evaluated. Message-ID: <20130215184806.CAE5247B00@hg.openjdk.java.net> Changeset: 3e37a45fcc69 Author: Felipe Heidrich Date: 2013-02-15 10:31 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3e37a45fcc69 RT-26853: getNativeDestHandle and getNativeSourceHandle() should be evaluated. ! decora-prism-ps/src/com/sun/scenario/effect/impl/prism/ps/PPSDrawable.java ! decora-prism-sw/src/com/sun/scenario/effect/impl/prism/sw/PSWDrawable.java ! decora-prism/src/com/sun/scenario/effect/impl/prism/PrTexture.java - decora-runtime/src/com/sun/scenario/effect/impl/hw/Drawable.java - decora-runtime/src/com/sun/scenario/effect/impl/hw/RendererDelegate.java - decora-runtime/src/com/sun/scenario/effect/impl/hw/Shader.java - decora-runtime/src/com/sun/scenario/effect/impl/hw/Texture.java ! javafx-sg-prism/test/com/sun/javafx/sg/prism/TestGraphics.java From hang.vo at oracle.com Fri Feb 15 12:18:28 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 15 Feb 2013 20:18:28 +0000 Subject: hg: openjfx/8/graphics/rt: 34 new changesets Message-ID: <20130215201937.E2E9D47B0C@hg.openjdk.java.net> Changeset: d28efedf73e3 Author: "Jasper Potts" Date: 2013-02-06 11:01 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d28efedf73e3 RT-28252: ScrollBar Thumb doesn't snap to pixel ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java Changeset: fb2dc010dd91 Author: "Jasper Potts" Date: 2013-02-06 13:12 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fb2dc010dd91 Fixed RT-28163: [SplitMenuButton] Arrow button rendering has changed. ! apps/experiments/Modena/src/modena/SamplePage.java ! javafx-ui-controls/src/javafx/scene/control/MenuButton.java Changeset: 30fb7b4a2195 Author: "Jasper Potts" Date: 2013-02-06 19:18 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/30fb7b4a2195 Fixed RT-28255: Remove PSEUDO_CLASS_OVERRIDE from Node ! apps/experiments/Modena/src/modena/SamplePage.java ! javafx-ui-common/src/javafx/scene/Node.java Changeset: 4bd39477ff95 Author: "Jasper Potts" Date: 2013-02-07 14:33 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4bd39477ff95 Modena: Added extra border to scroll bar, adjusted height of some controls to match new Button height. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 723b68315cb2 Author: Paru Somashekar Date: 2013-02-07 16:53 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/723b68315cb2 RT-23847 axis tickLabelRotation does not work RT-24256 Adding RadioMenuItem to ToggleGroup causes IAE ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java ! javafx-ui-controls/src/javafx/scene/control/RadioMenuItem.java Changeset: 1b745a96e73b Author: Paru Somashekar Date: 2013-02-07 18:57 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1b745a96e73b javadoc for installing tooltips on XYChart symbols. ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java Changeset: 40e12d6e802c Author: mickf Date: 2013-02-08 15:35 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/40e12d6e802c RT-25892 : ListView(touch): When scrolling a list, scroll bars are not visible ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/caspian/embedded.css Changeset: 656c76d07b42 Author: mo.chicharro Date: 2013-02-08 16:45 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/656c76d07b42 Modena tweak - added -fx-shadow-highlight-color to SplitMenuButton ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: b86a515c40c6 Author: mo.chicharro Date: 2013-02-08 18:58 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b86a515c40c6 Modena tweaks - added new alignment visual showing spacing of arrows from right edge of controls ! apps/experiments/Modena/src/modena/SameHeightTest.fxml Changeset: eeafbb33986a Author: mo.chicharro Date: 2013-02-08 19:00 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/eeafbb33986a Modena tweaks - fix for RT-28299: Spacing of arrows from right edge of controls ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 372e8ef0a10d Author: David Grieve Date: 2013-02-08 17:37 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/372e8ef0a10d RT-21094: move Styleable to javafx.css package ! javafx-ui-charts/src/javafx/scene/chart/BarChart.java ! javafx-ui-charts/src/javafx/scene/chart/Chart.java ! javafx-ui-charts/src/javafx/scene/chart/LineChart.java ! javafx-ui-charts/src/javafx/scene/chart/PieChart.java ! javafx-ui-charts/src/javafx/scene/chart/StackedAreaChart.java ! javafx-ui-charts/src/javafx/scene/chart/StackedBarChart.java ! javafx-ui-charts/src/javafx/scene/chart/XYChart.java ! javafx-ui-common/src/com/sun/javafx/css/CssError.java ! javafx-ui-common/src/com/sun/javafx/css/StyleConverterImpl.java ! javafx-ui-common/src/com/sun/javafx/css/StyleHelper.java ! javafx-ui-common/src/com/sun/javafx/css/StyleManager.java - javafx-ui-common/src/com/sun/javafx/css/Styleable.java ! javafx-ui-common/src/com/sun/javafx/css/converters/FontConverter.java ! javafx-ui-common/src/com/sun/javafx/css/parser/CSSParser.java ! javafx-ui-common/src/javafx/css/CssMetaData.java ! javafx-ui-common/src/javafx/css/FontCssMetaData.java ! javafx-ui-common/src/javafx/css/SimpleStyleableBooleanProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableDoubleProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableFloatProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableIntegerProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableLongProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableObjectProperty.java ! javafx-ui-common/src/javafx/css/SimpleStyleableStringProperty.java + javafx-ui-common/src/javafx/css/Styleable.java ! javafx-ui-common/src/javafx/css/StyleableProperty.java ! javafx-ui-common/src/javafx/css/package.html ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/image/ImageView.java ! javafx-ui-common/src/javafx/scene/layout/Background.java ! javafx-ui-common/src/javafx/scene/layout/BackgroundConverter.java ! javafx-ui-common/src/javafx/scene/layout/Border.java ! javafx-ui-common/src/javafx/scene/layout/BorderConverter.java ! javafx-ui-common/src/javafx/scene/layout/FlowPane.java ! javafx-ui-common/src/javafx/scene/layout/GridPane.java ! javafx-ui-common/src/javafx/scene/layout/HBox.java ! javafx-ui-common/src/javafx/scene/layout/Region.java ! javafx-ui-common/src/javafx/scene/layout/StackPane.java ! javafx-ui-common/src/javafx/scene/layout/TilePane.java ! javafx-ui-common/src/javafx/scene/layout/VBox.java ! javafx-ui-common/src/javafx/scene/shape/Rectangle.java ! javafx-ui-common/src/javafx/scene/shape/Shape.java ! javafx-ui-common/src/javafx/scene/text/Text.java ! javafx-ui-common/src/javafx/scene/text/TextFlow.java ! javafx-ui-common/test/unit/com/sun/javafx/css/CssMetaDataTest.java ! javafx-ui-common/test/unit/com/sun/javafx/css/TestNode.java ! javafx-ui-common/test/unit/com/sun/javafx/css/TestNodeBase.java ! javafx-ui-common/test/unit/com/sun/javafx/test/CssMethodsTestBase.java ! javafx-ui-common/test/unit/javafx/scene/CSSNode.java ! javafx-ui-common/test/unit/javafx/scene/Node_effectiveOrientation_Css_Test.java ! javafx-ui-common/test/unit/javafx/scene/Node_onInvalidate_Test.java ! javafx-ui-common/test/unit/javafx/scene/shape/ShapeTest.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CellSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ContextMenuContent.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledImpl.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/LabeledText.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ToolBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/javafx/scene/chart/Axis.java ! javafx-ui-controls/src/javafx/scene/chart/CategoryAxis.java ! javafx-ui-controls/src/javafx/scene/chart/NumberAxis.java ! javafx-ui-controls/src/javafx/scene/chart/ValueAxis.java ! javafx-ui-controls/src/javafx/scene/control/Control.java ! javafx-ui-controls/src/javafx/scene/control/Labeled.java ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/MenuBar.java ! javafx-ui-controls/src/javafx/scene/control/MenuItem.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/ScrollBar.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java ! javafx-ui-controls/src/javafx/scene/control/Separator.java ! javafx-ui-controls/src/javafx/scene/control/SkinBase.java ! javafx-ui-controls/src/javafx/scene/control/Slider.java ! javafx-ui-controls/src/javafx/scene/control/SplitPane.java ! javafx-ui-controls/src/javafx/scene/control/Tab.java ! javafx-ui-controls/src/javafx/scene/control/TabPane.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TableColumnBase.java ! javafx-ui-controls/src/javafx/scene/control/TextArea.java ! javafx-ui-controls/src/javafx/scene/control/TextField.java ! javafx-ui-controls/src/javafx/scene/control/TextInputControl.java ! javafx-ui-controls/src/javafx/scene/control/TitledPane.java ! javafx-ui-controls/src/javafx/scene/control/ToolBar.java ! javafx-ui-controls/src/javafx/scene/control/Tooltip.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/skin/LabeledImplTest.java ! javafx-ui-controls/test/javafx/scene/control/ControlTest.java Changeset: f437c9bdc79f Author: Paru Somashekar Date: 2013-02-11 16:58 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f437c9bdc79f RT-25533 : Menu javadoc & RT-26576 ColorPicker RGB components get incorrect value. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/CustomColorDialog.java ! javafx-ui-controls/src/javafx/scene/control/Menu.java Changeset: e4464b4f804c Author: jgiles Date: 2013-02-07 10:39 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e4464b4f804c RT-28016: JAVAFX TABLEVIEW .SORTING ARROW SHIFTS TO THE WRONG COLUMN ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java Changeset: 4f89dec868cb Author: jgiles Date: 2013-02-07 13:56 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4f89dec868cb RT-28250: [TreeView, TreeTableView] expand/collapse arrows have a mind of their own ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java Changeset: 9b02ded253ac Author: jgiles Date: 2013-02-07 16:22 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9b02ded253ac Minor tweaks to combat RT-28213: 8.0-controls-scrum-287: memory leak in ComboBox. Unfortunately the perf regression is to undo a functional regression, so there isn't much more that can be done here. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxBaseSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java Changeset: 5b785c886979 Author: jgiles Date: 2013-02-08 09:39 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5b785c886979 RT-24916: TableView.scrollTo(TableColumn) Review-by: jgiles Contributed-by: Tom Schindl ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/VirtualContainerBase.java ! javafx-ui-controls/src/javafx/scene/control/ControlUtils.java ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java ! javafx-ui-controls/src/javafx/scene/control/ScrollToEvent.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java Changeset: e6475877a2cc Author: jgiles Date: 2013-02-08 10:55 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e6475877a2cc RT-27585: [TreeTableView] Changes in editable cell are not commited. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableViewSkin.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java Changeset: ba8319f15c9b Author: jgiles Date: 2013-02-08 13:38 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ba8319f15c9b RT-22716: Scene graph elements are not garbage collected (Memory Leak) ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java Changeset: f6a082cf07a3 Author: jgiles Date: 2013-02-11 13:21 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f6a082cf07a3 RT-27966: TabPane setTabMaxWidth hides close button ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java Changeset: d46f39fd37eb Author: jgiles Date: 2013-02-11 13:53 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d46f39fd37eb RT-27606: [TreeTableView] Double click on editable collapses the row. ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableCellBehaviorBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableCellBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TreeTableRowBehavior.java Changeset: cee06e42e4f3 Author: jgiles Date: 2013-02-11 14:58 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/cee06e42e4f3 RT-27820: ListView selectionModel selectedItems list returns incorrect size ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeView.java ! javafx-ui-controls/test/javafx/scene/control/ListViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: 722cc3746842 Author: jgiles Date: 2013-02-12 14:33 +1300 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/722cc3746842 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ScrollBarSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableColumnHeader.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java ! javafx-ui-controls/src/javafx/scene/control/ListView.java ! javafx-ui-controls/src/javafx/scene/control/ScrollPane.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java Changeset: ea4b9aedce67 Author: "Jasper Potts" Date: 2013-02-11 20:21 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ea4b9aedce67 Modena: tweek to body gradient ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 5d7d7686a2c3 Author: "Jasper Potts" Date: 2013-02-11 20:21 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5d7d7686a2c3 Modena: test app netbeans project updates ! apps/experiments/Modena/nbproject/build-impl.xml ! apps/experiments/Modena/nbproject/configs/Run_as_WebStart.properties ! apps/experiments/Modena/nbproject/configs/Run_in_Browser.properties ! apps/experiments/Modena/nbproject/genfiles.properties ! apps/experiments/Modena/nbproject/jfx-impl.xml + apps/experiments/Modena/nbproject/jfx-impl_backup_1.xml ! apps/experiments/Modena/nbproject/project.properties ! apps/experiments/Modena/src/modena/TestApp.css Changeset: 13ee6aa1865f Author: "Jasper Potts" Date: 2013-02-11 20:30 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/13ee6aa1865f MADE MODENA DEFAULT THEME. If there are issues with this change, it can easily be backed out by changing line 474 of com.sun.javafx.application.PlatformImpl back to Caspian. ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java Changeset: 2275a38d56ca Author: David Grieve Date: 2013-02-12 15:28 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2275a38d56ca [TEST-ONLY] syntax error in modena.css caused some failures. Added @Ignore to tests that still failed and created bugs for removing the @Ignore. Also changed build script to convert modena.css to modena.bss ! javafx-ui-controls/build-common.xml ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css ! javafx-ui-controls/test/javafx/scene/control/AccordionTest.java ! javafx-ui-controls/test/javafx/scene/control/ColorPickerTest.java Changeset: 7dc3847a8025 Author: David Grieve Date: 2013-02-12 23:29 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7dc3847a8025 RT-21094: need to mark some impl_ methods as deprecated ! javafx-ui-controls/src/javafx/scene/control/PopupControl.java ! javafx-ui-controls/src/javafx/scene/control/TableColumn.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableColumn.java Changeset: 103768088c59 Author: David Grieve Date: 2013-02-13 00:35 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/103768088c59 [TEST-ONLY] Add @Ignore to StackedAreaChartTest and StackedBarChartTest pending RT-28373 ! javafx-ui-charts/test/javafx/scene/chart/StackedAreaChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/StackedBarChartTest.java Changeset: 6dabd87c27d6 Author: mo.chicharro Date: 2013-02-13 12:36 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6dabd87c27d6 Modena tweaks - Added TitledPane to SameHeightTest.fxml for height comparison ! apps/experiments/Modena/src/modena/SameHeightTest.fxml Changeset: 14dda2ac593b Author: mo.chicharro Date: 2013-02-13 12:37 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/14dda2ac593b Modena Tweaks - Adjusted height of TitledPane ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: c97dc773b5a4 Author: David Grieve Date: 2013-02-13 16:37 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c97dc773b5a4 RT-28391: set default platform to caspian. backed out @Ignore on unit test that failed due to modena. ! javafx-ui-charts/test/javafx/scene/chart/StackedAreaChartTest.java ! javafx-ui-charts/test/javafx/scene/chart/StackedBarChartTest.java ! javafx-ui-common/src/com/sun/javafx/application/PlatformImpl.java ! javafx-ui-controls/test/javafx/scene/control/AccordionTest.java ! javafx-ui-controls/test/javafx/scene/control/ColorPickerTest.java Changeset: b2dfc3891302 Author: David Grieve Date: 2013-02-13 18:35 -0500 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b2dfc3891302 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - javafx-ui-common/src/com/sun/javafx/css/Styleable.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/layout/Region.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/PaginationSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! javafx-ui-controls/src/javafx/scene/control/Pagination.java Changeset: 82735d8f445e Author: hudson Date: 2013-02-14 20:12 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/82735d8f445e Added tag 8.0-b77 for changeset b2dfc3891302 ! .hgtags Changeset: d4ce43227fca Author: kcr Date: 2013-02-15 11:58 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d4ce43227fca Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/MASTER/jfx/rt - decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/jogl/JOGLBackend.java - decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/jogl/JOGLGlue.stg - decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/rsl/RSLBackend.java - decora-compiler/src/com/sun/scenario/effect/compiler/backend/j2d/rsl/RSLGlue.stg - decora-runtime/src/com/sun/scenario/effect/impl/hw/Drawable.java - decora-runtime/src/com/sun/scenario/effect/impl/hw/RendererDelegate.java - decora-runtime/src/com/sun/scenario/effect/impl/hw/Shader.java - decora-runtime/src/com/sun/scenario/effect/impl/hw/Texture.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/shape/Rectangle.java ! javafx-ui-common/src/javafx/scene/text/Text.java - javafx-ui-common/test/unit/javafx/scene/MouseTest3D.java From hang.vo at oracle.com Fri Feb 15 12:18:03 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 15 Feb 2013 20:18:03 +0000 Subject: hg: openjfx/8/controls/rt: Modena Tweaks - new focus visual for text-area and pill-buttons Message-ID: <20130215201807.D3FCF47B0A@hg.openjdk.java.net> Changeset: 772801ad2574 Author: mo.chicharro Date: 2013-02-15 20:07 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/772801ad2574 Modena Tweaks - new focus visual for text-area and pill-buttons ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From hang.vo at oracle.com Fri Feb 15 14:47:54 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 15 Feb 2013 22:47:54 +0000 Subject: hg: openjfx/8/graphics/rt: Re-enabled printing unit test. Message-ID: <20130215224758.BD39947B17@hg.openjdk.java.net> Changeset: be8486aec5ba Author: jgodinez Date: 2013-02-15 14:33 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/be8486aec5ba Re-enabled printing unit test. ! javafx-ui-common/test/unit/test/javafx/print/JobSettingsTest.java ! javafx-ui-common/test/unit/test/javafx/print/PrinterJobTest.java From hang.vo at oracle.com Fri Feb 15 15:33:05 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Fri, 15 Feb 2013 23:33:05 +0000 Subject: hg: openjfx/8/controls/rt: RT-26049: [TitledPane] Right-click on the drop-down arrow opens/collapses control and opens context menu simultaneously. Message-ID: <20130215233309.E613A47B18@hg.openjdk.java.net> Changeset: 2c6d6e386e14 Author: raginip Date: 2013-02-15 15:26 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2c6d6e386e14 RT-26049: [TitledPane] Right-click on the drop-down arrow opens/collapses control and opens context menu simultaneously. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TitledPaneSkin.java From kirhog at gmail.com Fri Feb 15 17:15:28 2013 From: kirhog at gmail.com (=?KOI8-R?B?59XM2MvPIOHMxcvTwc7E0g==?=) Date: Sat, 16 Feb 2013 04:15:28 +0300 Subject: Async REST web services calls In-Reply-To: <7AC9E60F-7C6E-4952-83BC-99F568FE6619@me.com> References: <1D520562-DDF6-482D-B9C2-6D66BCCFF670@gmail.com> <7AC9E60F-7C6E-4952-83BC-99F568FE6619@me.com> Message-ID: Sebastian, Try Apache HttpComponents library for HTTP requests: http://hc.apache.org/. Your code will be much more simpler. Furthermore it has async client ( http://hc.apache.org/httpcomponents-asyncclient-dev/index.html) and the example ( http://hc.apache.org/httpcomponents-asyncclient-dev/httpasyncclient/examples/org/apache/http/examples/nio/client/AsyncClientHttpExchangeFutureCallback.java) special for your case. Regards, Alexander 2013/2/14 Hendrik Ebbers > Hi, > maybe DataFX (http://www.javafxdata.org/) can help. > > > > Am 14.02.2013 um 19:10 schrieb Sebastian Gutierrez : > > > Hello list, > > > > I'm migrating a silverlight app to javafx, but I'm running into this > issue: > > > > I used a lot async calls to REST Webservices on siverlight like this: > > > > WebClient test = new WebClient(); > > test.UploadStringCompleted += new > UploadStringCompletedEventHandler(test_UploadStringCompleted); > > test.UploadStringAsync(URL, POST DATA); > > > > and the callback method: > > > > > > void test_UploadStringCompleted(object sender, > UploadStringCompletedEventArgs e) > > { > > String result = e.Response(); > > > > //here I have the response of the web service > > > > } > > > > > > > > > > > > now Im using this on JAVAFX: > > > > > > public static String ExecPOSTRESTWebService(String resource, String data) > > { > > try { > > > > > > > > > > String rest = //URL for the rest WS; > > > > URL url = new URL(rest); > > URLConnection conn = url.openConnection(); > > conn.setDoOutput(true); > > BufferedReader rd; > > String buffer; > > try (OutputStreamWriter wr = new > OutputStreamWriter(conn.getOutputStream())) { > > wr.write(data); > > wr.flush(); > > rd = new BufferedReader(new > InputStreamReader(conn.getInputStream())); > > String line; > > buffer = ""; > > while ((line = rd.readLine()) != null) { > > buffer = buffer + line; > > } > > } > > rd.close(); > > > > return buffer; > > > > } catch (Exception ex) { > > Logger.getLogger(Utils.class.getName()).log(Level.SEVERE, > ex.toString()); > > return ""; > > } > > > > } > > > > > > the problem is that this is sync and not async so I block the UI, I know > I can do some threading and Platform.runlater? and those? but for many > calls the code will get hard to read and difficult > > is there any component around that does the async calls with a callback > method?? any library? > > > > > > Thanks! > > > > > > > From hang.vo at oracle.com Fri Feb 15 17:33:11 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 16 Feb 2013 01:33:11 +0000 Subject: hg: openjfx/8/controls/rt: 3 new changesets Message-ID: <20130216013328.4203B47B1B@hg.openjdk.java.net> Changeset: caf9d1a65fc0 Author: "Jasper Potts" Date: 2013-02-15 16:40 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/caf9d1a65fc0 Modena test app, fixed editable combo focused state ! apps/experiments/Modena/src/modena/SamplePage.java Changeset: b874b0ab1ed8 Author: "Jasper Potts" Date: 2013-02-15 17:24 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b874b0ab1ed8 Modena: tweeked main gradients again. Improved focus drawing ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 3312cb7d2def Author: "Jasper Potts" Date: 2013-02-15 17:24 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/3312cb7d2def Modena test app, added pill button focused state ! apps/experiments/Modena/src/modena/SamplePage.java From zonski at gmail.com Fri Feb 15 17:46:18 2013 From: zonski at gmail.com (Daniel Zwolenski) Date: Sat, 16 Feb 2013 12:46:18 +1100 Subject: Async REST web services calls In-Reply-To: References: <1D520562-DDF6-482D-B9C2-6D66BCCFF670@gmail.com> <7AC9E60F-7C6E-4952-83BC-99F568FE6619@me.com> Message-ID: And another alternative: http://www.zenjava.com/2012/12/04/javafx-with-a-springmvc-rest-server-in-5-minutes/ This is both client and server but the client bit should work with any rest server. Threading model from here would apply too: http://www.zenjava.com/2012/02/25/going-remote-javafx-and-spring-remoting/ (not a rest example but same deal) Add security with something like this: http://www.zenjava.com/2012/03/27/javafx-and-spring-security/ If you have a pure java client and a pure java server I'd highly recommend spring remoting (with httpinvoker) over Rest. You only really need/want rest if you are targeting cross-language clients and the programming model is then messier as a result. On 16/02/2013, at 12:15 PM, ?????? ????????? wrote: > Sebastian, > > Try Apache HttpComponents library for HTTP requests: > http://hc.apache.org/. Your code will be much more simpler. > > Furthermore it has async client ( > http://hc.apache.org/httpcomponents-asyncclient-dev/index.html) and the > example ( > http://hc.apache.org/httpcomponents-asyncclient-dev/httpasyncclient/examples/org/apache/http/examples/nio/client/AsyncClientHttpExchangeFutureCallback.java) > special for your case. > > Regards, > Alexander > > 2013/2/14 Hendrik Ebbers > >> Hi, >> maybe DataFX (http://www.javafxdata.org/) can help. >> >> >> >> Am 14.02.2013 um 19:10 schrieb Sebastian Gutierrez : >> >>> Hello list, >>> >>> I'm migrating a silverlight app to javafx, but I'm running into this >> issue: >>> >>> I used a lot async calls to REST Webservices on siverlight like this: >>> >>> WebClient test = new WebClient(); >>> test.UploadStringCompleted += new >> UploadStringCompletedEventHandler(test_UploadStringCompleted); >>> test.UploadStringAsync(URL, POST DATA); >>> >>> and the callback method: >>> >>> >>> void test_UploadStringCompleted(object sender, >> UploadStringCompletedEventArgs e) >>> { >>> String result = e.Response(); >>> >>> //here I have the response of the web service >>> >>> } >>> >>> >>> >>> >>> >>> now Im using this on JAVAFX: >>> >>> >>> public static String ExecPOSTRESTWebService(String resource, String data) >>> { >>> try { >>> >>> >>> >>> >>> String rest = //URL for the rest WS; >>> >>> URL url = new URL(rest); >>> URLConnection conn = url.openConnection(); >>> conn.setDoOutput(true); >>> BufferedReader rd; >>> String buffer; >>> try (OutputStreamWriter wr = new >> OutputStreamWriter(conn.getOutputStream())) { >>> wr.write(data); >>> wr.flush(); >>> rd = new BufferedReader(new >> InputStreamReader(conn.getInputStream())); >>> String line; >>> buffer = ""; >>> while ((line = rd.readLine()) != null) { >>> buffer = buffer + line; >>> } >>> } >>> rd.close(); >>> >>> return buffer; >>> >>> } catch (Exception ex) { >>> Logger.getLogger(Utils.class.getName()).log(Level.SEVERE, >> ex.toString()); >>> return ""; >>> } >>> >>> } >>> >>> >>> the problem is that this is sync and not async so I block the UI, I know >> I can do some threading and Platform.runlater? and those? but for many >> calls the code will get hard to read and difficult >>> is there any component around that does the async calls with a callback >> method?? any library? >>> >>> >>> Thanks! >>> >>> >>> >> From hang.vo at oracle.com Fri Feb 15 19:33:29 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Sat, 16 Feb 2013 03:33:29 +0000 Subject: hg: openjfx/8/controls/rt: Modena, added menu shadow. Added menus to test app, Table view test selection fixed. Added Horiz List test. Message-ID: <20130216033333.BD04A47B23@hg.openjdk.java.net> Changeset: fc3124f2b74f Author: "Jasper Potts" Date: 2013-02-15 19:18 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fc3124f2b74f Modena, added menu shadow. Added menus to test app, Table view test selection fixed. Added Horiz List test. ! apps/experiments/Modena/src/modena/SamplePage.java ! apps/experiments/Modena/src/modena/SamplePageHelpers.java ! apps/experiments/Modena/src/modena/SamplePageTableHelper.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From jonathan.giles at oracle.com Sun Feb 17 13:36:41 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 18 Feb 2013 10:36:41 +1300 Subject: [REVIEW REQUEST] Improvements to TableView sorting Message-ID: <51214D69.3020301@oracle.com> Hi all, I am wanting to summarise my plans on how to improve TableView sorting in JavaFX 8.0, given the conclusions reached regarding the introduction of SortedList in JavaFX 8.0 [1]. Apologies for the length of this email. If I had more time I would have made it shorter. OVERVIEW ==================== For a while I've maintained an umbrella issue for improved sorting functionality in TableView (RT-19479 [2]). My expectation is what I outline below should work towards resolving as many of the issues outlined in this Jira issue, most importantly the following features are ones I would love to support: 1) Support returning to an unsorted state. 2) Support forcing a 'continuous' sort (so that whenever the items list is changed the TableView remains sorted). 3) Support custom sort policies (to allow for people to override the current in-memory sort policy and instead, say, go direct to a database to do the sort). 4) Be notified of when a sort event is about to occur and prevent it from happening. 5) Make it possible to force a sort when something elsewhere in the universe (unrelated to the tableview) has changed (e.g. when you know the tableview is no longer consistent and should re-run its sort policy). I'm not aware of other features that should be supported. If you have some and they are within the scope of TableView sorting, then please read the rest of this email and then reply to it so we can discuss. IMPLEMENTATION ==================== I have attached an early draft patch for the following functionality inside RT-19479. It is 'early and draft' in the sense that I'm fairly comfortable with the API, but there is still a lot of implementation and javadoc work that needs to be done. Hopefully it should give you all an idea of what is planned, so that you may offer any thoughts before I get too far into implementation and javadoc. To summarise the patch, what I've done is add a new SortEvent class, and then for both TableView and TreeTableView I have done the following: * I've introduced a public static Callback DEFAULT_SORT_POLICY that encapsulates the current sorting code. Users are free to overwrite this sort policy should they wish to instead go to the database, for example. They do this by calling tableView.setSortPolicy(...). * I have made the TableView and TreeTableView sort() methods public, but they simply defer to the sort policy (assuming it is non-null, which is the case by default as the DEFAULT_SORT_POLICY is set by default). * I have made the code that calls sort() more full-featured. This happens in a few places, most notably when the 'sortOrder' list is changed (where sortOrder is a list of TableColumns which the user / developer has specified are to be used to sort the data in the table). In particular, I now do the following when the sortOrder changes (or any of the other sort criteria relevant to the sort): o I update the Comparator that I am about to use. This Comparator is now publicly readable (but not writable), so that people can do sortedList.comparatorProperty().bind(tableView.comparatorProperty()). + The reason why I don't want the comparator to be writable is that it would then allow for the comparator to be inconsistent with the sortOrder list, whereas I view the comparator as a reflection of the sortOrder. If people don't want to use this comparator they are free to set their own sort policy and use whatever they want in there. o I fire the SortEvent. If this event is consumed I do not run the sort(). o I call sort() o sort() is now very simple: it calls getSortPolicy() and runs it, passing in the TableView / TreeTableView and expecting a boolean response to indicate success or failure. The above outline essentially allows for features 2), 3), 4) and 5) from the list above. The only feature missing therefore is 1), which is support for returning to an unsorted state. The solution to this is to have a special-case support inside TableView / SortedList such that the developer may do what I mentioned above (namely, sortedList.comparatorProperty().bind(tableView.comparatorProperty())), and when the tableView.sortOrder list is empty the TableView / SortedList will take that to mean there is no sort desired and to return to the original, unsorted state. The other important note to make is that if you as the developer provide the TableView with a SortedList this is telling the TableView not to sort the collection or modify the Comparator if the user / developer changes the sortOrder (e.g. by clicking on the column headers). In other words, a TableView with a SortedList can not have its sort order changed by default. Of course, if you DO want the Comparator to be changed in your SortedList (and to support unsorted state as above), you can simply bind the comparator of the list to the tableview comparator. I hope that is clear. It's a lot of detail to get out, but hopefully it meets the expectations of everyone and I can go forth and implement it (and pray for no gnarly edge cases). I think the most probable area for issues is around maintaining consistent visuals for the sorted table column(s) given the ability for sorting to fail and / or be ignored by the developer implementation of the comparator / sort policy. As always, your thoughts and comments are appreciated, but lets keep this discussion focused solely on sorting in TableView (and to a lesser degree TreeTableView). [1] See the last comment by Richard Bair here: http://javafx-jira.kenai.com/browse/RT-17053 [2] http://javafx-jira.kenai.com/browse/RT-19479 Thanks, -- Jonathan From hang.vo at oracle.com Sun Feb 17 16:18:17 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Feb 2013 00:18:17 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130218001825.89DA747B42@hg.openjdk.java.net> Changeset: c45213895edf Author: David Grieve Date: 2013-02-15 18:12 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/c45213895edf RT-28394: from impl_processCSS(boolean), process css from the top-most css-dirty node on down. ! javafx-ui-common/src/javafx/scene/Node.java Changeset: 63cd571ad9b9 Author: David Grieve Date: 2013-02-17 19:14 -0500 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/63cd571ad9b9 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt From hang.vo at oracle.com Sun Feb 17 20:04:17 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Feb 2013 04:04:17 +0000 Subject: hg: openjfx/8/controls/rt: 8 new changesets Message-ID: <20130218040435.7819447B45@hg.openjdk.java.net> Changeset: fcc775200892 Author: jgiles Date: 2013-02-12 15:05 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/fcc775200892 RT-26168: BorderPane ignores the managed property of it's children Reviewed-by: jgiles Contributed-by: Tom Schindl ! javafx-ui-common/src/javafx/scene/layout/BorderPane.java Changeset: 5959523b02a0 Author: jgiles Date: 2013-02-12 17:06 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5959523b02a0 RT-28117: [TreeTableView] Disclosure nodes do not appear / disappear when children are added / removed from a TreeItem ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkinBase.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeTableRowSkin.java Changeset: 8ea32651d1a8 Author: jgiles Date: 2013-02-12 17:12 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8ea32651d1a8 RT-26048: [SplitMenuButton] Right-click on the drop-down arrow opens popup and context menu simultaneously. Reviewed-by: jgiles Contributed-by: Tom Schindl ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/MenuButtonBehaviorBase.java Changeset: 6996f0da8544 Author: jgiles Date: 2013-02-12 18:50 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6996f0da8544 RT-28302: 8.0-b73: Creating and removing TreeView with static TreeItems leaks memory ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/src/javafx/scene/control/TableView.java ! javafx-ui-controls/src/javafx/scene/control/TreeCell.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableRow.java ! javafx-ui-controls/src/javafx/scene/control/TreeTableView.java Changeset: 2890df2ceca7 Author: jgiles Date: 2013-02-18 11:18 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2890df2ceca7 Rename variable name in ProgressIndicatorSkin due to obvious copy/paste typo. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java Changeset: b0ac1381c884 Author: jgiles Date: 2013-02-18 13:53 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b0ac1381c884 RT-28390: NPE in TreeCellSkin when TreeCell disclosureNode is set to null ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TreeCellSkin.java ! javafx-ui-controls/test/javafx/scene/control/TreeTableViewTest.java ! javafx-ui-controls/test/javafx/scene/control/TreeViewTest.java Changeset: 8aa51f2ae458 Author: jgiles Date: 2013-02-18 14:49 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8aa51f2ae458 RT-28397: ListView is not updated when we change item in items list. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ListViewSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableViewSkinBase.java Changeset: f0277741af73 Author: jgiles Date: 2013-02-18 16:32 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f0277741af73 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt From hang.vo at oracle.com Mon Feb 18 00:21:21 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Feb 2013 08:21:21 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28446: parallel picking uses PickRay. Message-ID: <20130218082131.7C45C47B4E@hg.openjdk.java.net> Changeset: b1e1caf6c52d Author: Pavel Safrata Date: 2013-02-18 08:12 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/b1e1caf6c52d RT-28446: parallel picking uses PickRay. ! javafx-geom/src/com/sun/javafx/geom/PickRay.java ! javafx-ui-common/src/com/sun/javafx/scene/input/PickResultChooser.java ! javafx-ui-common/src/javafx/scene/Node.java ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-common/src/javafx/scene/layout/Region.java ! javafx-ui-common/src/javafx/scene/shape/Box.java ! javafx-ui-common/src/javafx/scene/shape/Cylinder.java ! javafx-ui-common/src/javafx/scene/shape/Sphere.java ! javafx-ui-common/src/javafx/scene/shape/TriangleMesh.java ! javafx-ui-common/test/unit/javafx/scene/NodeTest.java From hang.vo at oracle.com Mon Feb 18 00:33:45 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Feb 2013 08:33:45 +0000 Subject: hg: openjfx/8/graphics/rt: 3 new changesets Message-ID: <20130218083351.C7EB447B52@hg.openjdk.java.net> Changeset: 8081a4a05576 Author: Pavel Safrata Date: 2013-02-18 08:22 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8081a4a05576 More 3D picking tests. ! javafx-ui-common/test/unit/javafx/scene/Mouse3DTest.java ! javafx-ui-common/test/unit/javafx/scene/PickAndContainsTest.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubScene.java Changeset: 5226a9e8bd8c Author: Martin Sladecek Date: 2013-02-18 09:23 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5226a9e8bd8c RT-28326 Line Refresh Bug ! javafx-geom/src/com/sun/javafx/geom/DirtyRegionContainer.java Changeset: e79db2a615be Author: Martin Sladecek Date: 2013-02-18 09:26 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e79db2a615be merge From hang.vo at oracle.com Mon Feb 18 00:48:45 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Feb 2013 08:48:45 +0000 Subject: hg: openjfx/8/graphics/rt: Fixed build failure. Message-ID: <20130218084847.5B5D547B53@hg.openjdk.java.net> Changeset: c98c8d62c30b Author: Pavel Safrata Date: 2013-02-18 08:39 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c98c8d62c30b Fixed build failure. ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubScene.java From hang.vo at oracle.com Mon Feb 18 01:04:19 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Feb 2013 09:04:19 +0000 Subject: hg: openjfx/8/graphics/rt: Minor temporary fix (temporary) and some more tests. Message-ID: <20130218090421.EA8E347B54@hg.openjdk.java.net> Changeset: 4ef7fa436803 Author: Pavel Safrata Date: 2013-02-18 08:54 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4ef7fa436803 Minor temporary fix (temporary) and some more tests. ! javafx-geom/src/com/sun/javafx/geom/PickRay.java ! javafx-ui-common/test/unit/javafx/scene/Mouse3DTest.java ! javafx-ui-common/test/unit/javafx/scene/PickAndContainsTest.java From sebastian.rheinnecker at yworks.com Mon Feb 18 01:17:23 2013 From: sebastian.rheinnecker at yworks.com (Sebastian Rheinnecker) Date: Mon, 18 Feb 2013 10:17:23 +0100 Subject: FXML Development Message-ID: <5121F1A3.9090408@yworks.com> Hey, there has been no real update to the FXML part of javafx for a 3-4 weeks now, even though major issues exist (referring to jira). Is there any special reason for this? Kind regards, Sebastian -- Sebastian Rheinnecker phone: +49 7071 9709050 fax: +49 7071 9709051 yWorks GmbH Vor dem Kreuzberg 28 72070 Tuebingen Germany http://www.yworks.com Managing Directors: Sebastian M?ller, Michael Pfahler Commercial Registry: Stuttgart, Germany, HRB 382340 From hang.vo at oracle.com Mon Feb 18 01:18:37 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Feb 2013 09:18:37 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130218091841.32C2F47B56@hg.openjdk.java.net> Changeset: 284f1b82605d Author: Pavel Safrata Date: 2013-02-18 09:03 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/284f1b82605d One more picking test. ! javafx-ui-common/test/unit/javafx/scene/Mouse3DTest.java Changeset: 961437ff0a15 Author: Pavel Safrata Date: 2013-02-18 09:09 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/961437ff0a15 Tests for RT-13740 (picking with depth-buffer) ! javafx-ui-common/test/unit/javafx/scene/MouseTest.java From ozemale at ozemail.com.au Mon Feb 18 02:09:30 2013 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Mon, 18 Feb 2013 21:09:30 +1100 Subject: Sub-pixel text rendering in Canvas revisited Message-ID: <000c01ce0dc0$0b4a6570$21df3050$@com.au> Some time ago I posted about my wish for Canvas to support sub-pixel antialiased text rendering (also known as LCD text rendering). At the time, some resistance to the idea was expressed (from the JavaFX development team) on the basis that adding a method to set the text "smoothing" type in Canvas would result in API bloat. In addition, some comments were made in relation to the difficulty of rendering LCD text with transitions and animations. I would like to restate that I strongly believe that Canvas needs to support LCD text. I simply cannot see that adding *one* method to an API is equivalent to "bloat". Also, while I profess that I am no advanced graphics expert, I am not sure why LCD text would cause unsolvable problems for transitions/animations given that other graphics toolkits (i.e. Flash, Silverlight and even HTML5 Canvas) are all capable of rendering LCD text and having such text participate in animations. What makes JavaFX so different? So, is it possible the decision not to support LCD text in JavaFX Canvas be reconsidered? As I said in my original post, the main driver for me is that I would like to develop advanced controls based on Canvas but am concerned that the text in said controls looks distinctly different (i.e. much poorer/fizzier) than text rendered in "standard" controls (i.e. those not based on Canvas). The result is a non-uniform and substandard UI. Thanks, -jct From milan.kubec at oracle.com Mon Feb 18 02:41:30 2013 From: milan.kubec at oracle.com (Milan Kubec) Date: Mon, 18 Feb 2013 11:41:30 +0100 Subject: FXML Development In-Reply-To: <5121F1A3.9090408@yworks.com> References: <5121F1A3.9090408@yworks.com> Message-ID: <5122055A.2020804@oracle.com> Hello, there were no major features planned for FXML for upcomming release. What major issues are you refering to in particular? Thanks Milan Kubec Dne 18.2.2013 10:17, Sebastian Rheinnecker napsal(a): > Hey, > > there has been no real update to the FXML part of javafx for a 3-4 > weeks now, even though major issues exist (referring to jira). Is > there any special reason for this? > > Kind regards, > Sebastian > From james.graham at oracle.com Mon Feb 18 02:41:25 2013 From: james.graham at oracle.com (Jim Graham) Date: Mon, 18 Feb 2013 02:41:25 -0800 Subject: Sub-pixel text rendering in Canvas revisited In-Reply-To: <000c01ce0dc0$0b4a6570$21df3050$@com.au> References: <000c01ce0dc0$0b4a6570$21df3050$@com.au> Message-ID: <51220555.7020601@oracle.com> Phil's comment about the API was not about bloat, it was about designing an API before we understood the issues and how developers were facing them. We fully understood the issues that would affect LCD rendering of a Text Node and so that has API to control it, but we do not yet understand all of the issues that would affect LCD text for Canvas (and some of what I said before that we think we might understand turns out is not necessarily completely accurate in the face of Windows 8 HiDPI scaling so perhaps it is a good thing that we waited). I explained the technical issues on another message on this mailing list. I'll include that description here: > One issue with canvas is that LCD text needs to be rendered when the > device space transform is known. With Canvas we know what the pixel > space is of the backing raster, but the transform that is applied > when we render the backing raster to the screen (which is probably > identity in many common cases) can wreak havoc with the sub-pixel > work we did on the text. If we provided a control for it on > GraphicsContext then you'd have to commit to not involving the > canvas in any transforms except for integer translations. > > Also, I'd have to think about how this would be affected by HiDPI > as well. The typical Apple retina screen would be a simple 2x > scale so the same integer translate restriction would still work > fine, but I haven't delved too deep into what scaling options > Windows 8 offers... > > ...jim Note that comparing our LCD text capabilities to Flash and Silverlight would better use our Text node as a comparison. If I understand correctly, Flash and Silverlight rerender the text for every frame of an animation and so they can adjust it for the specific final transform and pixel layout of the screen they are animating on. Canvas is an image you can render into and then move/scale/stretch/rotate that image afterwards so to do LCD text on that would be better compared to whether Photoshop can implement LCD text in an image you save. Also, I was under the impression that HTML5 Canvas did not do LCD text (yet). At least I see no API related to it in the latest cuts of the API that I've looked at and when I search for it I see people asking why their HTML5 Canvas text is grayscale when their browser text is LCD (usually for the same reason - HTML5 is implemented as a pixel store, not a list of graphics commands to be reiterated during animations). Also, we now have an idea of what is involved with HiDPI on Mac Retina and Windows 8 and it doesn't look promising. If we rasterize at 2x for a Mac Retina display and the window is dragged to a non-Retina display than our attempts to do LCD at 2x will look worse than if we had done grayscale - though LCD text on a Retina display is already overkill. Windows 8 documents indicate that applications should prepare to render with 1.4 and 1.8 pixel scaling so they do not have an even multiple so my caveats above about how Mac Retina's 2x pixel scaling would not affect LCD restrictions on Canvas are unfortunately not applicable to HiDPI Windows 8 screens. :( This requires more testing and analysis before we can offer an LCD text API on GraphicsContext that doesn't create more problems than it solves... ...jim On 2/18/13 2:09 AM, John C. Turnbull wrote: > Some time ago I posted about my wish for Canvas to support sub-pixel > antialiased text rendering (also known as LCD text rendering). > > > > At the time, some resistance to the idea was expressed (from the JavaFX > development team) on the basis that adding a method to set the text > "smoothing" type in Canvas would result in API bloat. In addition, some > comments were made in relation to the difficulty of rendering LCD text with > transitions and animations. > > > > I would like to restate that I strongly believe that Canvas needs to support > LCD text. I simply cannot see that adding *one* method to an API is > equivalent to "bloat". Also, while I profess that I am no advanced graphics > expert, I am not sure why LCD text would cause unsolvable problems for > transitions/animations given that other graphics toolkits (i.e. Flash, > Silverlight and even HTML5 Canvas) are all capable of rendering LCD text and > having such text participate in animations. What makes JavaFX so different? > > > > So, is it possible the decision not to support LCD text in JavaFX Canvas be > reconsidered? As I said in my original post, the main driver for me is that > I would like to develop advanced controls based on Canvas but am concerned > that the text in said controls looks distinctly different (i.e. much > poorer/fizzier) than text rendered in "standard" controls (i.e. those not > based on Canvas). The result is a non-uniform and substandard UI. > > > > Thanks, > > > > -jct > From martin.sladecek at oracle.com Mon Feb 18 04:38:08 2013 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Mon, 18 Feb 2013 13:38:08 +0100 Subject: [API Review] Property and expression conversion methods Message-ID: <512220B0.5030709@oracle.com> Hello, there are 2 JIRA issues requesting some conversion between primitive expression/properties/observablevalues and theirs object counterparts, as primitive types actually use Number as generics parameter. To avoid backwards incompatibility by changing the generics parameters to more specific types, we decided to introduce conversion methods to these types, so that you can use them as objects of the same (generics) type. Here are the JIRA issues: http://javafx-jira.kenai.com/browse/RT-25996 http://javafx-jira.kenai.com/browse/RT-19020 And here are the proposed methods. Using Double here, but the same API will be also for Float, Integer, Long and Boolean. DoubleExpression: public ObjectExpression asObject(); ReadOnlyDoubleProperty: @Override public ReadOnlyObjectProperty asObject(); DoubleProperty: @Override ObjectProperty asObject(); The conversion from object to primitive will be provided through static methods (for Double, Float, Integer and Long): DoubleExpression: public static DoubleExpression doubleExpression(ObservableValue) ReadOnlyDoubleProperty: public static ReadOnlyDoubleProperty readOnlyDoubleProperty(ReadOnlyProperty); DoubleProperty: public static DoubleProperty doubleProperty(Property); ... and for Boolean: BooleanExpression: public static BooleanExpression booleanExpression(ObservableValue) ReadOnlyBooleanProperty: public static ReadOnlyBooleanProperty readOnlyBooleanPropety(ReadOnlyProperty); BooleanProperty: public static BooleanProperty booleanProperty(Property); Regards, -Martin From hang.vo at oracle.com Mon Feb 18 04:48:42 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Feb 2013 12:48:42 +0000 Subject: hg: openjfx/8/graphics/rt: 2 new changesets Message-ID: <20130218124848.A939047B5C@hg.openjdk.java.net> Changeset: af9f7005c06f Author: Martin Sladecek Date: 2013-02-18 13:45 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/af9f7005c06f RT-23600 ObservableListBase - javafx-beans/src/com/sun/javafx/collections/BaseModifiableObservableList.java - javafx-beans/src/com/sun/javafx/collections/BaseObservableList.java ! javafx-beans/src/com/sun/javafx/collections/ChangeHelper.java ! javafx-beans/src/com/sun/javafx/collections/ElementObservableListDecorator.java ! javafx-beans/src/com/sun/javafx/collections/ElementObserver.java - javafx-beans/src/com/sun/javafx/collections/ListChangeBuilder.java ! javafx-beans/src/com/sun/javafx/collections/ObservableListWrapper.java ! javafx-beans/src/com/sun/javafx/collections/transformation/FilteredList.java ! javafx-beans/src/com/sun/javafx/collections/transformation/SortedList.java ! javafx-beans/src/com/sun/javafx/collections/transformation/TransformationList.java ! javafx-beans/src/javafx/collections/FXCollections.java + javafx-beans/src/javafx/collections/ListChangeBuilder.java + javafx-beans/src/javafx/collections/ModifiableObservableListBase.java + javafx-beans/src/javafx/collections/ObservableListBase.java - javafx-beans/test/com/sun/javafx/collections/ListChangeBuilderTest.java + javafx-beans/test/javafx/collections/ListChangeBuilderTest.java ! javafx-beans/test/javafx/collections/SortedListTest.java Changeset: c5937c934c18 Author: Martin Sladecek Date: 2013-02-18 13:46 +0100 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c5937c934c18 merge - javafx-beans/src/com/sun/javafx/collections/BaseModifiableObservableList.java - javafx-beans/src/com/sun/javafx/collections/BaseObservableList.java - javafx-beans/src/com/sun/javafx/collections/ListChangeBuilder.java - javafx-beans/test/com/sun/javafx/collections/ListChangeBuilderTest.java From hang.vo at oracle.com Mon Feb 18 08:18:44 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Feb 2013 16:18:44 +0000 Subject: hg: openjfx/8/graphics/rt: RT-28359: Region respects pickOnBounds. Message-ID: <20130218161850.A0CB547B64@hg.openjdk.java.net> Changeset: c3101dee71a3 Author: Pavel Safrata Date: 2013-02-18 16:08 +0000 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c3101dee71a3 RT-28359: Region respects pickOnBounds. ! javafx-ui-common/src/javafx/scene/layout/Region.java From hang.vo at oracle.com Mon Feb 18 08:48:34 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Feb 2013 16:48:34 +0000 Subject: hg: openjfx/8/controls/rt: Modena Tweaks - Fix focus for pill button, toggle selected, and SplitMenuButton Message-ID: <20130218164839.B88E147B68@hg.openjdk.java.net> Changeset: f52035ccf89c Author: mo.chicharro Date: 2013-02-18 16:39 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f52035ccf89c Modena Tweaks - Fix focus for pill button, toggle selected, and SplitMenuButton ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css From alexandre.iline at oracle.com Mon Feb 18 09:02:19 2013 From: alexandre.iline at oracle.com (alexandre.iline at oracle.com) Date: Mon, 18 Feb 2013 17:02:19 +0000 Subject: hg: openjfx/8/master/tests: 15 new changesets Message-ID: <20130218170225.800DC47B69@hg.openjdk.java.net> Changeset: 84b268549aa4 Author: Alexandre (Shura) Iline Date: 2013-02-11 14:04 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/84b268549aa4 concurentmodificationexception ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/input/InputApp.java ! tools/Jemmy/JemmyFX/samples/org/jemmy/samples/input/InputSampleBase.java Changeset: ccd16c8cd9dd Author: Alexandre (Shura) Iline Date: 2013-02-12 15:23 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/ccd16c8cd9dd Maven artifact generation. Fixed a few dependencies along the way. ! .hgignore ! tools/Jemmy/GlassImage/build.xml ! tools/Jemmy/GlassImage/nbproject/project.properties + tools/Jemmy/GlassImage/pom-tmpl.xml + tools/Jemmy/GlassImage/src/org/jemmy/image/jemmy.properties ! tools/Jemmy/GlassRobot/build.xml + tools/Jemmy/GlassRobot/manifest.mf + tools/Jemmy/GlassRobot/pom-tmpl.xml + tools/Jemmy/GlassRobot/src/org/jemmy/input/glass/jemmy.properties ! tools/Jemmy/JemmyFX/build.xml ! tools/Jemmy/JemmyFX/nbproject/build-impl.xml ! tools/Jemmy/JemmyFX/nbproject/genfiles.properties ! tools/Jemmy/JemmyFX/nbproject/project.properties ! tools/Jemmy/JemmyFX/nbproject/project.xml + tools/Jemmy/JemmyFX/pom-tmpl.xml ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/jemmy.properties ! tools/Jemmy/JemmyFXBrowser/build.xml ! tools/Jemmy/JemmyFXBrowser/nbproject/build-impl.xml ! tools/Jemmy/JemmyFXBrowser/nbproject/genfiles.properties ! tools/Jemmy/JemmyFXBrowser/nbproject/project.properties ! tools/Jemmy/JemmyFXBrowser/nbproject/project.xml + tools/Jemmy/JemmyFXBrowser/pom-tmpl.xml + tools/Jemmy/JemmyFXBrowser/src/org/jemmy/fx/jemmy.properties Changeset: 872e64ac3a79 Author: Alexandre (Shura) Iline Date: 2013-02-13 12:01 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/872e64ac3a79 JSObject is not public com.sun.webkit.dom removing all the webview functionality until fixed - tools/Jemmy/JemmyFX/samples/org/jemmy/samples/webview/WebViewApp.java - tools/Jemmy/JemmyFX/samples/org/jemmy/samples/webview/WebViewSample.java - tools/Jemmy/JemmyFX/samples/org/jemmy/samples/webview/button.html ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrapper.java - tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebNodeParent.java - tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebNodeWrap.java - tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebViewWrap.java - tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/WebViewApp.java - tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/WebViewTest.java Changeset: e33cffde6dae Author: Alexandre (Shura) Iline Date: 2013-02-13 17:51 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/e33cffde6dae JemmyCore v 0.9.6 ! tools/Jemmy/GlassImage/pom-tmpl.xml ! tools/Jemmy/GlassRobot/pom-tmpl.xml ! tools/Jemmy/JemmyFX/pom-tmpl.xml ! tools/Jemmy/JemmyFXBrowser/pom-tmpl.xml Changeset: 6157872621ce Author: Aleksandr Sakharuk Date: 2013-02-13 17:26 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/6157872621ce Add latest changes. ! functional/SceneGraphTests/src/test/scenegraph/app/AffineApp.java ! functional/SceneGraphTests/src/test/scenegraph/app/ImageLoadingApp.java ! functional/SceneGraphTests/src/test/scenegraph/app/ImagesApp.java ! functional/SceneGraphTests/src/test/scenegraph/app/StageSceneApp.java ! functional/SceneGraphTests/src/test/scenegraph/binding/BindingApp.java ! functional/SceneGraphTests/src/test/scenegraph/lcd/animation/AnimationLCDTextTestApp.java ! functional/SceneGraphTests/src/test/scenegraph/richtext/RichTextPropertiesApp.java ! functional/SceneGraphTests/test/security/D3DRendererNativePointerTest.java ! functional/SceneGraphTests/test/test/scenegraph/binding/BindingTestBase.java ! functional/SceneGraphTests/test/test/scenegraph/functional/SceneEventHandlersTest.java ! functional/SceneGraphTests/test/test/scenegraph/functional/imageLoading/ImageLoadingTest.java ! functional/SceneGraphTests/test/test/scenegraph/richtext/RichTextLabeledsTest.java ! functional/SceneGraphTests/test/test/scenegraph/richtext/RichTextMixedTest.java ! functional/SceneGraphTests/test/test/scenegraph/richtext/RichTextPropertiesFunctional.java ! functional/SceneGraphTests/test/test/scenegraph/richtext/RichTextRectangleTest.java ! functional/SceneGraphTests/test/test/scenegraph/richtext/RichTextTestBase.java ! functional/SceneGraphTests/test/test/scenegraph/richtext/RichTextTextTest.java Changeset: fc496f242d6f Author: Alexandre (Shura) Iline Date: 2013-02-13 17:51 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/fc496f242d6f merge Changeset: 82aa83e2ed68 Author: Alexandre (Shura) Iline Date: 2013-02-13 18:54 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/82aa83e2ed68 ant properties are immutable ! tools/Jemmy/JemmyFX/build.xml ! tools/Jemmy/JemmyFXBrowser/build.xml Changeset: 451f41322dc3 Author: Alexandre (Shura) Iline Date: 2013-02-13 19:09 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/451f41322dc3 proper property file ! tools/Jemmy/JemmyFX/build.xml ! tools/Jemmy/JemmyFXBrowser/build.xml Changeset: 4c9639b81da8 Author: Alexandre (Shura) Iline Date: 2013-02-14 18:14 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/4c9639b81da8 /ext ! functional/SceneGraphTests/nbproject/project.properties Changeset: 87df8b459341 Author: Aleksandr Sakharuk Date: 2013-02-14 13:09 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/87df8b459341 Remove StageSceneApp.java. - functional/SceneGraphTests/src/test/scenegraph/app/StageSceneApp.java Changeset: f0e1d31aeaf7 Author: Aleksandr Sakharuk Date: 2013-02-14 13:46 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/f0e1d31aeaf7 Move multitouch apps and several other classes to close part. ! functional/SceneGraphTests/test/test/scenegraph/functional/SceneEventHandlersTest.java Changeset: 99d110bf4d75 Author: Aleksandr Sakharuk Date: 2013-02-14 13:55 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/99d110bf4d75 Remove apps for manual tests. - functional/SceneGraphTests/src/test/multitouch/app/MouseEventApp.java - functional/SceneGraphTests/src/test/multitouch/app/MultiTouchApp.java - functional/SceneGraphTests/src/test/multitouch/app/TouchPointGrabApp.java - functional/SceneGraphTests/src/test/multitouch/app/TouchPointsMarksScene.java - functional/SceneGraphTests/src/test/multitouch/app/TouchableShapeFactory.java - functional/SceneGraphTests/src/test/scenegraph/app/ImageLoadingApp.java - functional/SceneGraphTests/src/test/scenegraph/app/ImageLoadingManual.java - functional/SceneGraphTests/test/test/scenegraph/functional/imageLoading/ImageLoadingTest.java Changeset: 2b9e760d8371 Author: Alexandre (Shura) Iline Date: 2013-02-14 18:14 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/2b9e760d8371 merge - functional/SceneGraphTests/src/test/multitouch/app/MouseEventApp.java - functional/SceneGraphTests/src/test/multitouch/app/MultiTouchApp.java - functional/SceneGraphTests/src/test/multitouch/app/TouchPointGrabApp.java - functional/SceneGraphTests/src/test/multitouch/app/TouchPointsMarksScene.java - functional/SceneGraphTests/src/test/multitouch/app/TouchableShapeFactory.java - functional/SceneGraphTests/src/test/scenegraph/app/ImageLoadingApp.java - functional/SceneGraphTests/src/test/scenegraph/app/ImageLoadingManual.java - functional/SceneGraphTests/src/test/scenegraph/app/StageSceneApp.java - functional/SceneGraphTests/test/test/scenegraph/functional/imageLoading/ImageLoadingTest.java Changeset: 360dc01da08e Author: Alexandre (Shura) Iline Date: 2013-02-14 18:22 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/360dc01da08e another /ext ! tools/SharedTestUtils/nbproject/project.properties Changeset: e4d78e490620 Author: Irina Latysheva Date: 2013-02-14 19:08 +0400 URL: http://hg.openjdk.java.net/openjfx/8/master/tests/rev/e4d78e490620 Fix for 8.0 b75 API change in WebNode (com.sun.webkit.JSObject -> netscape.javascript.JSObject). + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/webview/WebViewApp.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/webview/WebViewSample.java + tools/Jemmy/JemmyFX/samples/org/jemmy/samples/webview/button.html ! tools/Jemmy/JemmyFX/src/org/jemmy/fx/NodeWrapper.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebNodeParent.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebNodeWrap.java + tools/Jemmy/JemmyFX/src/org/jemmy/fx/control/WebViewWrap.java + tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/WebViewApp.java + tools/Jemmy/JemmyFX/test/org/jemmy/fx/control/WebViewTest.java From hang.vo at oracle.com Mon Feb 18 10:18:47 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Feb 2013 18:18:47 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130218181854.A1D3747B6D@hg.openjdk.java.net> Changeset: a92db10ee128 Author: mo.chicharro Date: 2013-02-18 18:09 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a92db10ee128 Modena Tweaks - Fixed width of button on split ColorPicker ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: 2607f93a7a18 Author: mo.chicharro Date: 2013-02-18 18:11 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2607f93a7a18 Modena App - added Split ColorPicker to SameHeightTest.fxml ! apps/experiments/Modena/src/modena/SameHeightTest.fxml From hang.vo at oracle.com Mon Feb 18 12:04:04 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Feb 2013 20:04:04 +0000 Subject: hg: openjfx/8/graphics/rt: White-space-only change to remove DOS line endings Message-ID: <20130218200408.BA59B47B6F@hg.openjdk.java.net> Changeset: 8194b8a697ba Author: kcr Date: 2013-02-18 11:47 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8194b8a697ba White-space-only change to remove DOS line endings ! apps/experiments/ModenaTest/test/modenatest/ModenaTest.java ! deploy/packager/src/com/sun/javafx/tools/packager/bundlers/WinExeBundler.java ! deploy/packager/src/com/sun/javafx/tools/resource/windows/WinResources.java ! deploy/packager/test/com/sun/javafx/tools/packager/bundlers/WinMsiBundlerTest.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/DisplayItem.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/author/BeanCreateInfo.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/author/BeanCreateInfoSet.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/author/CheckedDisplayAction.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/author/Customizer.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/author/CustomizerResult.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/author/DesignInfo.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/author/DisplayAction.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/author/DisplayActionSet.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/author/PropertyEditor.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/author/Result.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/author/ResultMessage.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/author/ResultMessageType.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/tool/ContextField.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/tool/ContextMember.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/tool/ContextMethod.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/tool/DesignBean.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/tool/DesignBeanListener.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/tool/DesignContext.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/tool/DesignContextListener.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/tool/DesignEvent.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/tool/DesignProject.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/tool/DesignProperty.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/tool/LinearPosition.java ! javafx-beans-dt/src/com/sun/javafx/beans/design/tool/Position.java ! javafx-embed-swing/src/javafx/embed/swing/SwingDragSource.java ! javafx-embed-swt/src/javafx/embed/swt/CustomTransfer.java ! javafx-ui-common/src/com/sun/javafx/scene/SceneHelper.java ! javafx-ui-common/test/unit/com/sun/javafx/test/NodeOrientationTestBase.java ! javafx-ui-common/test/unit/javafx/scene/Node_effectiveOrientation_Test.java ! javafx-ui-common/test/unit/javafx/scene/Node_hasMirroring_Test.java ! javafx-ui-common/test/unit/javafx/scene/canvas/CanvasTest.java ! javafx-ui-common/test/unit/javafx/stage/CommonDialogsTest.java ! javafx-ui-common/test/unit/javafx/stage/ScreenTest.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/MultiplePropertyChangeListenerHandler.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/behavior/TableViewBehavior.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/BehaviorSkinBase.java ! javafx-ui-controls/src/javafx/scene/control/ControlUtils.java ! javafx-ui-controls/src/javafx/scene/control/ResizeFeaturesBase.java ! javafx-ui-controls/src/javafx/scene/control/ScrollToEvent.java ! javafx-ui-controls/src/javafx/scene/control/SkinBase.java ! javafx-ui-controls/src/javafx/scene/control/TableFocusModel.java ! javafx-ui-controls/src/javafx/scene/control/TableSelectionModel.java ! javafx-ui-controls/src/javafx/scene/control/TableUtil.java ! javafx-ui-controls/src/javafx/scene/control/TreeSortMode.java ! javafx-ui-controls/src/javafx/scene/control/TreeUtil.java ! javafx-ui-controls/src/javafx/scene/control/cell/CellUtils.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/CheckBoxTreeTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ChoiceBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ChoiceBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ChoiceBoxTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ChoiceBoxTreeTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ComboBoxTreeTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/MapValueFactory.java ! javafx-ui-controls/src/javafx/scene/control/cell/ProgressBarTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/ProgressBarTreeTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldListCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTableCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeCell.java ! javafx-ui-controls/src/javafx/scene/control/cell/TextFieldTreeTableCell.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/behavior/ListViewAnchorRetriever.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/behavior/TableViewAnchorRetriever.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/behavior/TreeTableViewAnchorRetriever.java ! javafx-ui-controls/test/com/sun/javafx/scene/control/behavior/TreeViewAnchorRetriever.java ! javafx-ui-controls/test/javafx/scene/control/KeyEventFirer.java ! javafx-ui-controls/test/javafx/scene/control/KeyModifier.java ! javafx-ui-controls/test/javafx/scene/control/SkinBaseAccessor.java ! javafx-util-converter/src/javafx/util/converter/BigDecimalStringConverter.java ! javafx-util-converter/src/javafx/util/converter/BigIntegerStringConverter.java ! javafx-util-converter/src/javafx/util/converter/BooleanStringConverter.java ! javafx-util-converter/src/javafx/util/converter/ByteStringConverter.java ! javafx-util-converter/src/javafx/util/converter/CharacterStringConverter.java ! javafx-util-converter/src/javafx/util/converter/CurrencyStringConverter.java ! javafx-util-converter/src/javafx/util/converter/DateStringConverter.java ! javafx-util-converter/src/javafx/util/converter/DateTimeStringConverter.java ! javafx-util-converter/src/javafx/util/converter/DefaultStringConverter.java ! javafx-util-converter/src/javafx/util/converter/DoubleStringConverter.java ! javafx-util-converter/src/javafx/util/converter/FloatStringConverter.java ! javafx-util-converter/src/javafx/util/converter/FormatStringConverter.java ! javafx-util-converter/src/javafx/util/converter/IntegerStringConverter.java ! javafx-util-converter/src/javafx/util/converter/LongStringConverter.java ! javafx-util-converter/src/javafx/util/converter/NumberStringConverter.java ! javafx-util-converter/src/javafx/util/converter/PercentageStringConverter.java ! javafx-util-converter/src/javafx/util/converter/ShortStringConverter.java ! javafx-util-converter/src/javafx/util/converter/TimeStringConverter.java ! test-stub-toolkit/src/com/sun/javafx/pgstub/StubCanvas.java From parvathi.somashekar at oracle.com Mon Feb 18 12:53:08 2013 From: parvathi.somashekar at oracle.com (Paru Somashekar) Date: Mon, 18 Feb 2013 12:53:08 -0800 Subject: API REVIEW Axis label property Message-ID: <512294B4.6000101@oracle.com> JIRA : http://javafx-jira.kenai.com/browse/RT-28151 As the JIRA indicates, it is a simple change to use StringProperty for the axis label instead of ObjectProperty. This is a breaking API change - however the likelihood is minimal, as both ObjectProperty and StringProperty implement a lot of the same interfaces. As the JIRA notes, this is not consistent with the rest of the Charts API, where StringProperty is used instead of ObjectProperty, hence the need to fix it. thanks, Paru. From knut.arne.vedaa at broadpark.no Mon Feb 18 13:29:51 2013 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Mon, 18 Feb 2013 22:29:51 +0100 Subject: [REVIEW REQUEST] Improvements to TableView sorting In-Reply-To: <51214D69.3020301@oracle.com> References: <51214D69.3020301@oracle.com> Message-ID: <51229D4F.2080003@broadpark.no> > The above outline essentially allows for features 2), 3), 4) and 5) from > the list above. The only feature missing therefore is 1), which is > support for returning to an unsorted state. The solution to this is to > have a special-case support inside TableView / SortedList such that the > developer may do what I mentioned above (namely, > sortedList.comparatorProperty().bind(tableView.comparatorProperty())), > and when the tableView.sortOrder list is empty the TableView / > SortedList will take that to mean there is no sort desired and to return > to the original, unsorted state. > > The other important note to make is that if you as the developer provide > the TableView with a SortedList this is telling the TableView not to > sort the collection or modify the Comparator if the user / developer > changes the sortOrder (e.g. by clicking on the column headers). In other > words, a TableView with a SortedList can not have its sort order changed > by default. Of course, if you DO want the Comparator to be changed in > your SortedList (and to support unsorted state as above), you can simply > bind the comparator of the list to the tableview comparator. This is not very clear to me. It seems that you indicate there are two scenarios: A) The list you provide to TableView is a SortedList. B) The list you provide to TableView is not a SortedList. So in A), TableView will not do any sorting of its own, and it will not modify its comparator (or are you talking about SortedList's comparator?), but you can still bind the comparator to your SortedList? And in B), will sorting happens as it currently does, i.e. by mutating the user's list, or will TableView have an internal SortedList (as discussed previously)? Knut Arne Vedaa From jonathan.giles at oracle.com Mon Feb 18 13:37:24 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 19 Feb 2013 10:37:24 +1300 Subject: [REVIEW REQUEST] Improvements to TableView sorting In-Reply-To: <51229D4F.2080003@broadpark.no> References: <51214D69.3020301@oracle.com> <51229D4F.2080003@broadpark.no> Message-ID: <51229F14.4090509@oracle.com> >> The above outline essentially allows for features 2), 3), 4) and 5) from >> the list above. The only feature missing therefore is 1), which is >> support for returning to an unsorted state. The solution to this is to >> have a special-case support inside TableView / SortedList such that the >> developer may do what I mentioned above (namely, >> sortedList.comparatorProperty().bind(tableView.comparatorProperty())), >> and when the tableView.sortOrder list is empty the TableView / >> SortedList will take that to mean there is no sort desired and to return >> to the original, unsorted state. >> >> The other important note to make is that if you as the developer provide >> the TableView with a SortedList this is telling the TableView not to >> sort the collection or modify the Comparator if the user / developer >> changes the sortOrder (e.g. by clicking on the column headers). In other >> words, a TableView with a SortedList can not have its sort order changed >> by default. Of course, if you DO want the Comparator to be changed in >> your SortedList (and to support unsorted state as above), you can simply >> bind the comparator of the list to the tableview comparator. > > This is not very clear to me. It seems that you indicate there are two > scenarios: > > A) The list you provide to TableView is a SortedList. > > B) The list you provide to TableView is not a SortedList. > > So in A), TableView will not do any sorting of its own, and it will > not modify its comparator (or are you talking about SortedList's > comparator?), but you can still bind the comparator to your SortedList? Right. To clarify: when a SortedList is set in the TableView items list the TableView _will not_ sort it (either by actually performing a sort or by modifying the Comparator on the SortedList). The TableView _will_ modify the TableView.comparator property to represent what the user has requested, but this is not necessarily the guaranteed visual state. And yes, you can bind the SortedList comparator to the TableView comparator to get the expected sorting support. > > And in B), will sorting happens as it currently does, i.e. by mutating > the user's list, or will TableView have an internal SortedList (as > discussed previously)? Mutation will happen on the users list as currently occurs - there will be no internal SortedList. -- Jonathan From knut.arne.vedaa at broadpark.no Mon Feb 18 13:39:22 2013 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Mon, 18 Feb 2013 22:39:22 +0100 Subject: [API Review] Property and expression conversion methods In-Reply-To: <512220B0.5030709@oracle.com> References: <512220B0.5030709@oracle.com> Message-ID: <51229F8A.2010602@broadpark.no> Martin Sladecek wrote: > Hello, > > there are 2 JIRA issues requesting some conversion between primitive > expression/properties/observablevalues and theirs object counterparts, > as primitive types actually use Number as generics parameter. To avoid > backwards incompatibility by changing the generics parameters to more > specific types, we decided to introduce conversion methods to these > types, so that you can use them as objects of the same (generics) type. > > Here are the JIRA issues: > http://javafx-jira.kenai.com/browse/RT-25996 > http://javafx-jira.kenai.com/browse/RT-19020 It seems to me that the root problem here is this: interface ObservableNumberValue extends ObservableValue interface ObservableIntegerValue extends ObservableNumberValue Wouldn't it be solved by changing it to: interface ObservableNumberValue extends ObservableValue interface ObservableIntegerValue extends ObservableNumberValue (And similar for other Number descendants.) Knut Arne Vedaa From richard.bair at oracle.com Mon Feb 18 13:34:43 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 18 Feb 2013 13:34:43 -0800 Subject: API REVIEW Axis label property In-Reply-To: <512294B4.6000101@oracle.com> References: <512294B4.6000101@oracle.com> Message-ID: <2389A223-FD14-4F63-9A32-3DD47DBB662D@oracle.com> I've added the api-review label. This is very likely to not be approved, as we are not allowing binary incompatible changes unless they are of the most serious nature, and this one doesn't appear to fit that criteria. Richard On Feb 18, 2013, at 12:53 PM, Paru Somashekar wrote: > JIRA : http://javafx-jira.kenai.com/browse/RT-28151 > > As the JIRA indicates, it is a simple change to use StringProperty for the axis label instead of ObjectProperty. This is a breaking API change - however the likelihood is minimal, as both ObjectProperty and StringProperty implement a lot of the same interfaces. > As the JIRA notes, this is not consistent with the rest of the Charts API, where StringProperty is used instead of ObjectProperty, hence the need to fix it. > > thanks, > Paru. From knut.arne.vedaa at broadpark.no Mon Feb 18 13:50:25 2013 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Mon, 18 Feb 2013 22:50:25 +0100 Subject: [REVIEW REQUEST] Improvements to TableView sorting In-Reply-To: <51229F14.4090509@oracle.com> References: <51214D69.3020301@oracle.com> <51229D4F.2080003@broadpark.no> <51229F14.4090509@oracle.com> Message-ID: <5122A221.6060203@broadpark.no> > Right. To clarify: when a SortedList is set in the TableView items list > the TableView _will not_ sort it (either by actually performing a sort > or by modifying the Comparator on the SortedList). The TableView _will_ > modify the TableView.comparator property to represent what the user has > requested, but this is not necessarily the guaranteed visual state. > > And yes, you can bind the SortedList comparator to the TableView > comparator to get the expected sorting support. Ok, that was what I thought you meant it just wasn't quite clear from your description. :) >> And in B), will sorting happens as it currently does, i.e. by mutating >> the user's list, or will TableView have an internal SortedList (as >> discussed previously)? > > Mutation will happen on the users list as currently occurs - there will > be no internal SortedList. How will it then be returned to an unsorted state? And, as I'm not sure if a conclusion was reached in the previous thread about FilteredList/SortedList, what happens here if the provided list is a FilteredList or some other TransformedList (but not a SortedList) - was the decision to make TransformedList mutable after all? Knut Arne From jonathan.giles at oracle.com Mon Feb 18 13:54:14 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 19 Feb 2013 10:54:14 +1300 Subject: [REVIEW REQUEST] Improvements to TableView sorting In-Reply-To: <5122A221.6060203@broadpark.no> References: <51214D69.3020301@oracle.com> <51229D4F.2080003@broadpark.no> <51229F14.4090509@oracle.com> <5122A221.6060203@broadpark.no> Message-ID: <5122A306.80400@oracle.com> >>> And in B), will sorting happens as it currently does, i.e. by mutating >>> the user's list, or will TableView have an internal SortedList (as >>> discussed previously)? >> >> Mutation will happen on the users list as currently occurs - there will >> be no internal SortedList. > > How will it then be returned to an unsorted state? It won't - when an ObservableList is used we will maintain the current behavior of not retaining the original, unsorted state. For people who want to support returning to an unsorted state but otherwise have functionality like that of a normal ObservableList, they will do something like this: SortedList sortedList = new SortedList(SortedList.UNSORTED); // where SortedList.UNSORTED is a special Comparator sortedList.setAll(....); TableView tableview = new TableView(sortedList); sortedList.comparatorProperty().bind(tableview.comparatorProperty()); > > And, as I'm not sure if a conclusion was reached in the previous > thread about FilteredList/SortedList, what happens here if the > provided list is a FilteredList or some other TransformedList (but not > a SortedList) - was the decision to make TransformedList mutable after > all? I've not been closely involved in these discussions, so I'll leave that to Richard and / or Martin to answer. -- Jonathan From richard.bair at oracle.com Mon Feb 18 13:54:42 2013 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 18 Feb 2013 13:54:42 -0800 Subject: [REVIEW REQUEST] Improvements to TableView sorting In-Reply-To: <51229F14.4090509@oracle.com> References: <51214D69.3020301@oracle.com> <51229D4F.2080003@broadpark.no> <51229F14.4090509@oracle.com> Message-ID: <27457768-29C9-4E40-A3B0-FC5F67F0A224@oracle.com> >> This is not very clear to me. It seems that you indicate there are two scenarios: >> >> A) The list you provide to TableView is a SortedList. >> >> B) The list you provide to TableView is not a SortedList. >> >> So in A), TableView will not do any sorting of its own, and it will not modify its comparator (or are you talking about SortedList's comparator?), but you can still bind the comparator to your SortedList? > > Right. To clarify: when a SortedList is set in the TableView items list the TableView _will not_ sort it (either by actually performing a sort or by modifying the Comparator on the SortedList). The TableView _will_ modify the TableView.comparator property to represent what the user has requested, but this is not necessarily the guaranteed visual state. > > And yes, you can bind the SortedList comparator to the TableView comparator to get the expected sorting support. And the reason for this is that the SortedList is unmodifiable (but mutable). So the add / remove methods etc throw unsupported operation exception, so from the table's perspective, it cannot be sorted. So if you use such a list, then you have to take one more step to wire up the comparator of the sorted list to the comparator on the table view, so that whenever the comparator changes the sorted list is notified of it and can do its own sorting internally. Richard From knut.arne.vedaa at broadpark.no Mon Feb 18 14:12:58 2013 From: knut.arne.vedaa at broadpark.no (Knut Arne Vedaa) Date: Mon, 18 Feb 2013 23:12:58 +0100 Subject: [REVIEW REQUEST] Improvements to TableView sorting In-Reply-To: <5122A306.80400@oracle.com> References: <51214D69.3020301@oracle.com> <51229D4F.2080003@broadpark.no> <51229F14.4090509@oracle.com> <5122A221.6060203@broadpark.no> <5122A306.80400@oracle.com> Message-ID: <5122A76A.2070404@broadpark.no> > It won't - when an ObservableList is used we will maintain the current > behavior of not retaining the original, unsorted state. For people who > want to support returning to an unsorted state but otherwise have > functionality like that of a normal ObservableList, they will do > something like this: > > SortedList sortedList = new SortedList(SortedList.UNSORTED); // where > SortedList.UNSORTED is a special Comparator > sortedList.setAll(....); > TableView tableview = new TableView(sortedList); > sortedList.comparatorProperty().bind(tableview.comparatorProperty()); I see. So "return to unsorted" is thus not a feature of TableView - but of SortedList, and the user has to set it up correctly in order to get that feature. And providing a SortedList to TableView is a signal saying "hey, don't sort me - I'm taking care of it on my own (and you couldn't, even if you tried, so just don't try)". This is not a bad solution in my opinion, although I don't think it's 100% clean to create such coupling between TableView and a specific other class that is not appearing as a type in it's (TableView's) API. Knut Arne From hang.vo at oracle.com Mon Feb 18 14:48:34 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Mon, 18 Feb 2013 22:48:34 +0000 Subject: hg: openjfx/8/controls/rt: 2 new changesets Message-ID: <20130218224840.6778447B77@hg.openjdk.java.net> Changeset: a6419b0a5ca1 Author: mo.chicharro Date: 2013-02-18 22:34 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a6419b0a5ca1 Modena Tweaks - fix for RT-28384: No focus highlight on ScrollBar. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/modena/modena.css Changeset: f63eaef76ee9 Author: mo.chicharro Date: 2013-02-18 22:35 +0000 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/f63eaef76ee9 Modena App - added focused Scrollbars to sample page. ! apps/experiments/Modena/src/modena/SamplePage.java From jonathan.giles at oracle.com Mon Feb 18 16:39:56 2013 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 19 Feb 2013 13:39:56 +1300 Subject: [REVIEW REQUEST] Add support for an emptyText property in ComboBox Message-ID: <5122C9DC.4000502@oracle.com> Hi all, http://javafx-jira.kenai.com/browse/RT-22972 I'm keen to add an 'emptyText' property to ComboBox. This property would be analogous to the 'promptText' property already supported, except that it would appear in the popup list area when the items list is empty (rather than in the text field when that is empty). I'm happy to accept alternate naming suggestions, as this is just the first name that occurred to me. -- -- Jonathan From hang.vo at oracle.com Mon Feb 18 17:04:09 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Feb 2013 01:04:09 +0000 Subject: hg: openjfx/8/controls/rt: changed to private access for a few private enums ( as specified by code scanner output). Message-ID: <20130219010413.856CC47B7B@hg.openjdk.java.net> Changeset: 05ce9cba6cac Author: Paru Somashekar Date: 2013-02-18 17:02 -0800 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/05ce9cba6cac changed to private access for a few private enums ( as specified by code scanner output). ! javafx-ui-charts/src/javafx/scene/chart/StackedAreaChart.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ComboBoxMode.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TableRowSkinBase.java From hang.vo at oracle.com Mon Feb 18 17:18:43 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Feb 2013 01:18:43 +0000 Subject: hg: openjfx/8/controls/rt: 5 new changesets Message-ID: <20130219011855.D7C0447B7C@hg.openjdk.java.net> Changeset: 5124ab1a7a00 Author: jgiles Date: 2013-02-19 10:42 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5124ab1a7a00 RT-28337: Regression : many controls cannot be resized ! javafx-ui-controls/src/javafx/scene/control/SkinBase.java Changeset: 8aec9ff72401 Author: jgiles Date: 2013-02-19 10:43 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8aec9ff72401 RT-28366: ColorPickerSkin : create on demand color names map as opposed to a static list that reflects off of Color class. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java Changeset: 799c98ad1c38 Author: jgiles Date: 2013-02-19 11:17 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/799c98ad1c38 Updated the color name map based on tweaks provided by Jindra. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/ColorPickerSkin.java Changeset: 53d2d6db973a Author: jgiles Date: 2013-02-19 12:44 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/53d2d6db973a RT-26542: [TabPane] Disabled / Disable states are inconsistent Reviewed-by: jgiles Contributed-by: Tom Schindl ! javafx-ui-controls/src/javafx/scene/control/Tab.java ! javafx-ui-controls/test/javafx/scene/control/TabTest.java Changeset: 5c929574001d Author: jgiles Date: 2013-02-19 14:05 +1300 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/5c929574001d Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt From hang.vo at oracle.com Mon Feb 18 18:10:47 2013 From: hang.vo at oracle.com (hang.vo at oracle.com) Date: Tue, 19 Feb 2013 02:10:47 +0000 Subject: hg: openjfx/8/graphics/rt: RT-25869: Update copyright date to 2013; fix missing or malformed copyrights Message-ID: <20130219021050.AA14547B80@hg.openjdk.java.net> Changeset: eb8fe386f751 Author: kcr Date: 2013-02-18 14:17 -0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/eb8fe386f751 RT-25869: Update copyright date to 2013; fix missing or malformed copyrights ! decora-compiler/src/com/sun/scenario/effect/compiler/JSLC.java ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/hw/ES2Backend.java ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/hw/GLSLBackend.java ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/hw/HLSLBackend.java ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/hw/SLBackend.java ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/prism/PrismBackend.java ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/prism/PrismGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWBackend.java ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWCallScanner.java ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWFuncImpls.java ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/java/JSWTreeScanner.java ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MEBackend.java ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MECallScanner.java ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MEFuncImpls.java ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MEJavaGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/MENativeGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/me/METreeScanner.java ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSEBackend.java ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSECallScanner.java ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSEFuncImpls.java ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSEJavaGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSENativeGlue.stg ! decora-compiler/src/com/sun/scenario/effect/compiler/backend/sw/sse/SSETreeScanner.java ! decora-compiler/src/com/sun/scenario/effect/compiler/model/BaseType.java ! decora-compiler/src/com/sun/scenario/effect/compiler/model/BinaryOpType.java ! decora-compiler/src/com/sun/scenario/effect/compiler/model/CoreSymbols.java ! decora-compiler/src/com/sun/scenario/effect/compiler/model/FuncImpl.java ! decora-compiler/src/com/sun/scenario/effect/compiler/model/Function.java ! decora-compiler/src/com/sun/scenario/effect/compiler/model/Param.java ! decora-compiler/src/com/sun/scenario/effect/compiler/model/Precision.java ! decora-compiler/src/com/sun/scenario/effect/compiler/model/Qualifier.java ! decora-compiler/src/com/sun/scenario/effect/compiler/model/SymbolTable.java ! decora-compiler/src/com/sun/scenario/effect/compiler/model/Type.java ! decora-compiler/src/com/sun/scenario/effect/compiler/model/UnaryOpType.java ! decora-compiler/src/com/sun/scenario/effect/compiler/model/Variable.java ! decora-compiler/src/com/sun/scenario/effect/compiler/tree/ArrayAccessExpr.java ! decora-compiler/src/com/sun/scenario/effect/compiler/tree/BinaryExpr.java ! decora-compiler/src/com/sun/scenario/effect/compiler/tree/BreakStmt.java ! decora-compiler/src/com/sun/scenario/effect/compiler/tree/CallExpr.java ! decora-compiler/src/com/sun/scenario/effect/compiler/tree/CompoundStmt.java ! decora-compiler