From james.graham at oracle.com Sat Nov 1 01:43:30 2014 From: james.graham at oracle.com (Jim Graham) Date: Fri, 31 Oct 2014 18:43:30 -0700 Subject: 8u40 review request: RT-34467 huge memory consumption resizing transparent window Message-ID: <54543AC2.1040403@oracle.com> webrev: http://cr.openjdk.java.net/~flar/RT-34467/webrev.00/ Jira: https://javafx-jira.kenai.com/browse/RT-34467 This builds on the recent fixes for RT-38923 by adding a mechanism to reuse old buffers when they are large enough. Both test cases in RT-34467 now seem to be fairly well behaved (with both default and 1000m heap parameters)... ...jim From james.graham at oracle.com Sat Nov 1 03:20:37 2014 From: james.graham at oracle.com (Jim Graham) Date: Fri, 31 Oct 2014 20:20:37 -0700 Subject: 8u40 post-commit review: RT-39209 deleted dead code associated with obsolete FullCubic shaders Message-ID: <54545185.6050507@oracle.com> webrev: http://cr.openjdk.java.net/~flar/RT-39209/webrev.00/ Jira: https://javafx-jira.kenai.com/browse/RT-39209 The artifacts directory on Windows was approximately 44k smaller (out of 30m) after the code/shaders were removed... ...jim From peatmoss84 at gmail.com Sat Nov 1 12:03:06 2014 From: peatmoss84 at gmail.com (Pete Moss) Date: Sat, 1 Nov 2014 08:03:06 -0400 Subject: Initial positioning of Dialog Message-ID: Just getting started using the new openjfx-dialogs. One thing that annoys me is the default initial positioning of a popup dialog. The default seems to pop up in the center of the primary display screen. This is particularly annoying when the app is running in my secondary display. Where's the popup? Is there an option to have it centered on the stage, or a way to manually control the initial position? I tried to handle onShowing() but at this point X, Y, width and height are NaN. Thanks. From swpalmer at gmail.com Sat Nov 1 13:25:26 2014 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 1 Nov 2014 09:25:26 -0400 Subject: Initial positioning of Dialog In-Reply-To: References: Message-ID: <94DB8377-F398-4D7A-BB93-E0355E0799F0@gmail.com> I was just addressing a bug in my application related to this. The behaviour you describe happens only in Java FX 2.x. In JavaFX 8 the dialog still appears in the centre of the display, but it chooses the correct display based on where the parent window is. I ended up adding a bit of code to reposition the dialog manually, but it was a little tricky to avoid having the dialog flash at the original position first. I had to set the opacity to 0, reposition it, and then wait a bit before setting the opacity to 1. Even that was done in a couple stages with runLater. Scott > On Nov 1, 2014, at 8:03 AM, Pete Moss wrote: > > Just getting started using the new openjfx-dialogs. One thing that annoys > me is the default initial positioning of a popup dialog. The default seems > to pop up in the center of the primary display screen. This is particularly > annoying when the app is running in my secondary display. Where's the popup? > > Is there an option to have it centered on the stage, or a way to manually > control the initial position? I tried to handle onShowing() but at this > point X, Y, width and height are NaN. > > Thanks. From peatmoss84 at gmail.com Sat Nov 1 13:39:32 2014 From: peatmoss84 at gmail.com (Pete Moss) Date: Sat, 1 Nov 2014 09:39:32 -0400 Subject: Initial positioning of Dialog In-Reply-To: <94DB8377-F398-4D7A-BB93-E0355E0799F0@gmail.com> References: <94DB8377-F398-4D7A-BB93-E0355E0799F0@gmail.com> Message-ID: I get different behavior. I am using JavaFX 8 (1.8u25) with openjfx-dialogs-1.0.2 which is part of controlsfx-8.20.8. Here is my show code: OptionsDlg dlg = new OptionsDlg(); // where OptionsDlg extends Dialog dlg.initOwner(mainWnd.getScene().getWindow()); dlg.showAndWait(); When I set the initOwner() as shown, if the main app is in my primary display, the dlg seems to be centered on the stage, which I am happy with. However, if I move my main app into my secondary display, the dlg pops up in the center of the main display. This seems like a bug. If I comment out the line that sets initOwner(), the dlg always seems to pop up in the center of the main display, regardless of where the main app is. On Sat, Nov 1, 2014 at 9:25 AM, Scott Palmer wrote: > I was just addressing a bug in my application related to this. The > behaviour you describe happens only in Java FX 2.x. In JavaFX 8 the dialog > still appears in the centre of the display, but it chooses the correct > display based on where the parent window is. > > I ended up adding a bit of code to reposition the dialog manually, but it > was a little tricky to avoid having the dialog flash at the original > position first. I had to set the opacity to 0, reposition it, and then > wait a bit before setting the opacity to 1. Even that was done in a couple > stages with runLater. > > Scott > > > On Nov 1, 2014, at 8:03 AM, Pete Moss wrote: > > > > Just getting started using the new openjfx-dialogs. One thing that annoys > > me is the default initial positioning of a popup dialog. The default > seems > > to pop up in the center of the primary display screen. This is > particularly > > annoying when the app is running in my secondary display. Where's the > popup? > > > > Is there an option to have it centered on the stage, or a way to manually > > control the initial position? I tried to handle onShowing() but at this > > point X, Y, width and height are NaN. > > > > Thanks. > > From swpalmer at gmail.com Sat Nov 1 14:59:47 2014 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 1 Nov 2014 10:59:47 -0400 Subject: Initial positioning of Dialog In-Reply-To: References: <94DB8377-F398-4D7A-BB93-E0355E0799F0@gmail.com> Message-ID: <52850D0E-1057-439D-B73C-8CC5122B65E3@gmail.com> Ah, I the controlsFX code must be doing something to position the dialog. Perhaps you can step into the code and see what it is doing. The behaviour without a owner appears to be the standard behaviour - centre on the screen. Scott > On Nov 1, 2014, at 9:39 AM, Pete Moss wrote: > > I get different behavior. I am using JavaFX 8 (1.8u25) with openjfx-dialogs-1.0.2 which is part of controlsfx-8.20.8. Here is my show code: > > OptionsDlg dlg = new OptionsDlg(); // where OptionsDlg extends Dialog > dlg.initOwner(mainWnd.getScene().getWindow()); > dlg.showAndWait(); > > When I set the initOwner() as shown, if the main app is in my primary display, the dlg seems to be centered on the stage, which I am happy with. However, if I move my main app into my secondary display, the dlg pops up in the center of the main display. This seems like a bug. > > If I comment out the line that sets initOwner(), the dlg always seems to pop up in the center of the main display, regardless of where the main app is. > > > > > >> On Sat, Nov 1, 2014 at 9:25 AM, Scott Palmer wrote: >> I was just addressing a bug in my application related to this. The behaviour you describe happens only in Java FX 2.x. In JavaFX 8 the dialog still appears in the centre of the display, but it chooses the correct display based on where the parent window is. >> >> I ended up adding a bit of code to reposition the dialog manually, but it was a little tricky to avoid having the dialog flash at the original position first. I had to set the opacity to 0, reposition it, and then wait a bit before setting the opacity to 1. Even that was done in a couple stages with runLater. >> >> Scott >> >> > On Nov 1, 2014, at 8:03 AM, Pete Moss wrote: >> > >> > Just getting started using the new openjfx-dialogs. One thing that annoys >> > me is the default initial positioning of a popup dialog. The default seems >> > to pop up in the center of the primary display screen. This is particularly >> > annoying when the app is running in my secondary display. Where's the popup? >> > >> > Is there an option to have it centered on the stage, or a way to manually >> > control the initial position? I tried to handle onShowing() but at this >> > point X, Y, width and height are NaN. >> > >> > Thanks. >> > From peatmoss84 at gmail.com Sat Nov 1 15:08:59 2014 From: peatmoss84 at gmail.com (Pete Moss) Date: Sat, 1 Nov 2014 11:08:59 -0400 Subject: How to get a popup Dialog to inherit styles from main app? Message-ID: I am just getting started using the Dialog class and I noticed that my dialog content is not picking up styles that I've added to a global style sheet in my app. I suspect because Dialog's HeavyweightDialog is creating a new Stage. In my Main class I have: Scene scene = new Scene(root, 600, 500, Color.YELLOW); String s = Main.class.getResource("ui/styles.css").toExternalForm(); scene.getStylesheets().add(s); How can I get that stylesheet applied to the scene graph in my popup dialog? At what point in the lifecycle of my dialog can I do this? Thanks. From mike at plan99.net Sat Nov 1 17:32:05 2014 From: mike at plan99.net (Mike Hearn) Date: Sat, 1 Nov 2014 17:32:05 +0000 Subject: Embedding Mac native widgets into a Scene In-Reply-To: <5453A24A.1020202@oracle.com> References: <5453A24A.1020202@oracle.com> Message-ID: Alternatively, I wonder how hard it is to access the underlying features directly rather than try to use the real edit widget. Like, perhaps it's possible to access autocorrect via JNA or equivalent. On Fri, Oct 31, 2014 at 2:52 PM, Stephen F Northover < steve.x.northover at oracle.com> wrote: > Hi Mike, > > Embedding native controls in FX runs afoul of the whole > lightweight/heavyweight issue. I had a hack of this once using SWT native > controls and I was able to have them appear on Windows because HWND > clipping was honored but on Mac, FX drew on top of the native control. Mac > was changed to use CALayers way back for JDK7 and this also made things > more complicated. > > Having said all that (from memory), for iOS, there was some work that > overlayed an iOS text control in order to use the native keyboard control. > The control was created when editing started and then disposed when editing > ended. This would obviously have the same lightweight/heavyweight issues > while editing was happening and a host of other smaller problems (wrong > font, jumping, scrolling etc). > > One possible way for this to really work would be to get the native > control to render to a texture and get JavaFX to draw the texture. That is > just the painting side of the equation. Events would need to be delivered > to this non-painting control as well. There are operating system calls on > Mac that you can use to paint a control to an image so it is in theory > doable but a ton of work. > > Steve > > > On 2014-10-31, 9:48 AM, Mike Hearn wrote: > >> JavaFX provides a great set of widgets that are pretty complete, but a few >> lag behind behind their native counterparts on some platforms. This is >> especially noticeable with the Mac text field widget, which has things >> like >> integrated spelling/grammar checking, auto correct, services, speech >> recognition and so on. >> >> WebKit manages to expose all this functionality despite that HTML is not >> the native Mac UI framework. So I am wondering how hard it is for JFX to >> do >> the same. However, I know very little about how WebKit does this or how >> easy it'd be to replicate in the Java world. Are there any experts on the >> list who could comment? >> > > From peter.penzov at gmail.com Sat Nov 1 18:05:10 2014 From: peter.penzov at gmail.com (Peter Penzov) Date: Sat, 1 Nov 2014 20:05:10 +0200 Subject: Dialogs in JavaFX 8u40 Message-ID: Hi, I tested Java 8u40 b12 dialogs. Are there any plans to improve the design of the dialogs? Are there any plans for additional design development? BR, Peter From jonathan.giles at oracle.com Sat Nov 1 18:08:27 2014 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Sun, 02 Nov 2014 07:08:27 +1300 Subject: Dialogs in JavaFX 8u40 In-Reply-To: References: Message-ID: Other than bug fixes, there is no additional work planned. If there are things you would like to see supported, please file requests in Jira. If there are design bugs, please report them! -- Jonathan Sent from a touch device. Please excuse my brevity. On 2 November 2014 07:05:10 GMT+13:00, Peter Penzov wrote: >Hi, > I tested Java 8u40 b12 dialogs. Are there any plans to improve the >design of the dialogs? Are there any plans for additional design >development? > >BR, >Peter From kevin.rushforth at oracle.com Sat Nov 1 18:19:35 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 01 Nov 2014 11:19:35 -0700 Subject: Dialogs in JavaFX 8u40 In-Reply-To: References: Message-ID: <54552437.8000500@oracle.com> There are no more design improvements planned for 8u40, and b12 has all of the latest changes. If there is something specific that you had in mind you could either discuss on this thread or file a JIRA, but it will be post-8u40. As for fixing bugs, we have about one more month -- M4 is on Dec 1, by which time all planned bug fixing work for 8u40 needs to be done (only critical bugs will be considered after that). -- Kevin Peter Penzov wrote: > Hi, > I tested Java 8u40 b12 dialogs. Are there any plans to improve the > design of the dialogs? Are there any plans for additional design > development? > > BR, > Peter > From johan at lodgon.com Sat Nov 1 21:04:52 2014 From: johan at lodgon.com (Johan Vos) Date: Sat, 1 Nov 2014 22:04:52 +0100 Subject: prism and monocle? Message-ID: This is probably a dumb question, but now that I have the monocle glass implementation instead of lens running on Android/Dalvik, I am a bit confused with prism/es2/monocle, since it contains duplicate files of prism/es2/eglfb? The OpenJFX wiki is very clear in explaining Monocle as a glass implementation, but I don't understand yet why it also appears in prism? - Johan From anton.tarasov at oracle.com Sat Nov 1 20:10:57 2014 From: anton.tarasov at oracle.com (Anton Tarasov) Date: Sat, 01 Nov 2014 23:10:57 +0300 Subject: 8u40 review request: RT-38861 Rendering is disturbed by mouseover or focus move checkbox and radio of WebView Message-ID: <54553E51.6070700@oracle.com> Hi Kevin, Leonid, Please, review a simple fix: http://cr.openjdk.java.net/~ant/RT-38861/webrev.0 https://javafx-jira.kenai.com/browse/RT-38861 (This is a post-push review request). Thanks, Anton. From daniel.blaukopf at oracle.com Sat Nov 1 23:03:08 2014 From: daniel.blaukopf at oracle.com (Daniel Blaukopf) Date: Sun, 2 Nov 2014 01:03:08 +0200 Subject: prism and monocle? In-Reply-To: References: Message-ID: <957C7AF3-86F9-4F45-8075-E28FBF1F30D4@oracle.com> Hi Johan, You should use prism/es2/monocle. The MonocleGLContext in this implementation uses the AcceleratedScreen class from Monocle to get access to an accelerated drawing surface. The eglfb implementation of Prism has some platform-specific code in it. prism/es2/monocle doesn?t; it relies on the Monocle Glass implementation to provide a platform abstraction. Thanks, Daniel > On Nov 1, 2014, at 11:04 PM, Johan Vos wrote: > > This is probably a dumb question, but now that I have the monocle glass > implementation instead of lens running on Android/Dalvik, I am a bit > confused with prism/es2/monocle, since it contains duplicate files of > prism/es2/eglfb? > The OpenJFX wiki is very clear in explaining Monocle as a glass > implementation, but I don't understand yet why it also appears in prism? > > - Johan From ngalarneau at ABINITIO.COM Mon Nov 3 13:44:52 2014 From: ngalarneau at ABINITIO.COM (ngalarneau at ABINITIO.COM) Date: Mon, 3 Nov 2014 08:44:52 -0500 Subject: Initial positioning of Dialog In-Reply-To: <52850D0E-1057-439D-B73C-8CC5122B65E3@gmail.com> References: <94DB8377-F398-4D7A-BB93-E0355E0799F0@gmail.com> <52850D0E-1057-439D-B73C-8CC5122B65E3@gmail.com> Message-ID: Scott, When you say it works for you, which java are you running? - Java 8 (1.8u25) with openjfx-dialogs-1.0.2 like Pete - Java 8 update 40 pre-release - something else? Using the released 8u25 with openjfx-dialogs-1.0.2 I, too, have seen the dialog pop on the wrong display. Neil From: Scott Palmer To: Pete Moss , Cc: "openjfx-dev at openjdk.java.net" Date: 11/01/2014 11:00 AM Subject: Re: Initial positioning of Dialog Sent by: "openjfx-dev" Ah, I the controlsFX code must be doing something to position the dialog. Perhaps you can step into the code and see what it is doing. The behaviour without a owner appears to be the standard behaviour - centre on the screen. Scott > On Nov 1, 2014, at 9:39 AM, Pete Moss wrote: > > I get different behavior. I am using JavaFX 8 (1.8u25) with openjfx-dialogs-1.0.2 which is part of controlsfx-8.20.8. Here is my show code: > > OptionsDlg dlg = new OptionsDlg(); // where OptionsDlg extends Dialog > dlg.initOwner(mainWnd.getScene().getWindow()); > dlg.showAndWait(); > > When I set the initOwner() as shown, if the main app is in my primary display, the dlg seems to be centered on the stage, which I am happy with. However, if I move my main app into my secondary display, the dlg pops up in the center of the main display. This seems like a bug. > > If I comment out the line that sets initOwner(), the dlg always seems to pop up in the center of the main display, regardless of where the main app is. > > > > > >> On Sat, Nov 1, 2014 at 9:25 AM, Scott Palmer wrote: >> I was just addressing a bug in my application related to this. The behaviour you describe happens only in Java FX 2.x. In JavaFX 8 the dialog still appears in the centre of the display, but it chooses the correct display based on where the parent window is. >> >> I ended up adding a bit of code to reposition the dialog manually, but it was a little tricky to avoid having the dialog flash at the original position first. I had to set the opacity to 0, reposition it, and then wait a bit before setting the opacity to 1. Even that was done in a couple stages with runLater. >> >> Scott >> >> > On Nov 1, 2014, at 8:03 AM, Pete Moss wrote: >> > >> > Just getting started using the new openjfx-dialogs. One thing that annoys >> > me is the default initial positioning of a popup dialog. The default seems >> > to pop up in the center of the primary display screen. This is particularly >> > annoying when the app is running in my secondary display. Where's the popup? >> > >> > Is there an option to have it centered on the stage, or a way to manually >> > control the initial position? I tried to handle onShowing() but at this >> > point X, Y, width and height are NaN. >> > >> > Thanks. >> > NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution. From ngalarneau at ABINITIO.COM Mon Nov 3 13:49:23 2014 From: ngalarneau at ABINITIO.COM (ngalarneau at ABINITIO.COM) Date: Mon, 3 Nov 2014 08:49:23 -0500 Subject: Questions about Platform.runLater() and Application.start() Message-ID: Hello, Is there documentation that describes somewhere how Platform.runLater() & Application.start() interact? My impression is that (roughly speaking): - there is an EventQueue (to use the Swing terminology). - the EventQueue holds both UI events (like mouse click) as well as the Runnables enqueued by runLater(). - the first (?) event put in the EventQueue is a Runnable representing Application.start(). My impression is, therefore, that any Runnables enqueued during Application.start() won't be run until after start() completes. This behavior is the same as one runLater() not interrupting another runLater(). Is this sort of stuff documented somewhere? Is this the right way to think about this part of the system? (even if the implementation is different) Are there other special things to be aware of about Application.start()? Thanks, Neil P.S. I am using javafx.concurrent.Service & Task and am hitting some issues. NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution. From steve.x.northover at oracle.com Mon Nov 3 14:58:47 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Mon, 03 Nov 2014 09:58:47 -0500 Subject: Questions about Platform.runLater() and Application.start() In-Reply-To: References: Message-ID: <54579827.4080109@oracle.com> Hi there, If you en-queue a runnable in start() it will not run until start() completes unless you open a dialog in start() that waits for a result before proceeding. In that case, your runnable will run. You are correct about runnables and input events being part of the input queue for the application thread. Threads are not interrupted to run code. Steve On 2014-11-03, 8:49 AM, ngalarneau at ABINITIO.COM wrote: > Hello, > > Is there documentation that describes somewhere how Platform.runLater() & > Application.start() interact? > > My impression is that (roughly speaking): > - there is an EventQueue (to use the Swing terminology). > - the EventQueue holds both UI events (like mouse click) as well as the > Runnables enqueued by runLater(). > - the first (?) event put in the EventQueue is a Runnable representing > Application.start(). > > > My impression is, therefore, that any Runnables enqueued during > Application.start() won't be run until after start() completes. > This behavior is the same as one runLater() not interrupting another > runLater(). > > > Is this sort of stuff documented somewhere? > > Is this the right way to think about this part of the system? (even if the > implementation is different) > > Are there other special things to be aware of about Application.start()? > > > Thanks, > > Neil > > P.S. I am using javafx.concurrent.Service & Task and am hitting some > issues. > > > > NOTICE from Ab Initio: This email (including any attachments) may contain > information that is subject to confidentiality obligations or is legally > privileged, and sender does not waive confidentiality or privilege. If > received in error, please notify the sender, delete this email, and make > no further use, disclosure, or distribution. From steve.x.northover at oracle.com Mon Nov 3 15:22:21 2014 From: steve.x.northover at oracle.com (Stephen F Northover) Date: Mon, 03 Nov 2014 10:22:21 -0500 Subject: Initial positioning of Dialog In-Reply-To: References: Message-ID: <54579DAD.9050802@oracle.com> Hi Pete, If this is a bug in JFX dialogs that are part of 8u40, please enter a bug report with a small but complete code example and a set of steps. Thanks, Steve On 2014-11-01, 8:03 AM, Pete Moss wrote: > Just getting started using the new openjfx-dialogs. One thing that annoys > me is the default initial positioning of a popup dialog. The default seems > to pop up in the center of the primary display screen. This is particularly > annoying when the app is running in my secondary display. Where's the popup? > > Is there an option to have it centered on the stage, or a way to manually > control the initial position? I tried to handle onShowing() but at this > point X, Y, width and height are NaN. > > Thanks. From swpalmer at gmail.com Mon Nov 3 17:07:18 2014 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 3 Nov 2014 12:07:18 -0500 Subject: Initial positioning of Dialog In-Reply-To: References: <94DB8377-F398-4D7A-BB93-E0355E0799F0@gmail.com> <52850D0E-1057-439D-B73C-8CC5122B65E3@gmail.com> Message-ID: <5216C884-8729-4762-A0A1-74928A81B541@gmail.com> > On Nov 3, 2014, at 8:44 AM, ngalarneau at ABINITIO.COM wrote: > > Scott, > > When you say it works for you, which java are you running? > - Java 8 (1.8u25) with openjfx-dialogs-1.0.2 like Pete > - Java 8 update 40 pre-release > - something else? > > Using the released 8u25 with openjfx-dialogs-1.0.2 I, too, have seen the > dialog pop on the wrong display. > > > Neil I meant that a stage that has an Owner pops up on the same monitor as the parent stage. I?m not using openjfx-dialogs. I had my own dialog class from long ago where I had to work around the issue on JavaFX 2.x, because the same code on FX 2.x always opened the stage on the default monitor, regardless of where its parent was. Scott From kevin.rushforth at oracle.com Mon Nov 3 21:07:15 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 03 Nov 2014 13:07:15 -0800 Subject: 8u-dev unlocked following this week's sanity testing Message-ID: <5457EE83.2050202@oracle.com> From cnewland at chrisnewland.com Mon Nov 3 23:42:53 2014 From: cnewland at chrisnewland.com (Chris Newland) Date: Mon, 3 Nov 2014 23:42:53 -0000 Subject: Quick look at JavaFX methods above the HotSpot inlining threshold Message-ID: <6f7061cddbb0f488f5fc13ff9cb8c006.squirrel@excalibur.xssl.net> Hi all, As part of the JITWatch[1] project I've written a tool called JarScan which counts the bytecode size of methods in a jar and logs those methods which are above HotSpot's 325 byte size threshold for inlining methods it determines are "hot". In jfxrt.jar from Oracle's JDK 1.8.0_25 on Linux x86_64 there are 774 methods above the threshold which I've listed in this gist: https://gist.github.com/chriswhocodes/c474e49f0d111757dbf2 A lot of these won't be found in hot code but perhaps the methods under com.sun.javafx.geom and javafx.scene.transform could be candidates for examination with JIT compilation in mind? Has anybody on the list done any experiments in this area? If not I'll try and find some time to see if there are any gains to be made by trimming methods (in the OpenJFX source) to fit inside the inlining threshold. Cheers, Chris @chriswhocodes [1] https://github.com/AdoptOpenJDK/jitwatch From richard.bair at oracle.com Tue Nov 4 00:27:21 2014 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 3 Nov 2014 16:27:21 -0800 Subject: Quick look at JavaFX methods above the HotSpot inlining threshold In-Reply-To: <6f7061cddbb0f488f5fc13ff9cb8c006.squirrel@excalibur.xssl.net> References: <6f7061cddbb0f488f5fc13ff9cb8c006.squirrel@excalibur.xssl.net> Message-ID: Hi Chris, I?ve not seen any experiments or investigation along these lines, looking forward to what you find! Richard > On Nov 3, 2014, at 3:42 PM, Chris Newland wrote: > > Hi all, > > As part of the JITWatch[1] project I've written a tool called JarScan > which counts the bytecode size of methods in a jar and logs those methods > which are above HotSpot's 325 byte size threshold for inlining methods it > determines are "hot". > > In jfxrt.jar from Oracle's JDK 1.8.0_25 on Linux x86_64 there are 774 > methods above the threshold which I've listed in this gist: > https://gist.github.com/chriswhocodes/c474e49f0d111757dbf2 > > A lot of these won't be found in hot code but perhaps the methods under > com.sun.javafx.geom and javafx.scene.transform could be candidates for > examination with JIT compilation in mind? > > Has anybody on the list done any experiments in this area? If not I'll try > and find some time to see if there are any gains to be made by trimming > methods (in the OpenJFX source) to fit inside the inlining threshold. > > Cheers, > > Chris > @chriswhocodes > > [1] https://github.com/AdoptOpenJDK/jitwatch > From swpalmer at gmail.com Tue Nov 4 02:05:15 2014 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 3 Nov 2014 21:05:15 -0500 Subject: Quick look at JavaFX methods above the HotSpot inlining threshold In-Reply-To: <6f7061cddbb0f488f5fc13ff9cb8c006.squirrel@excalibur.xssl.net> References: <6f7061cddbb0f488f5fc13ff9cb8c006.squirrel@excalibur.xssl.net> Message-ID: JITWatch looks like an interesting project. Where did you get the information about the 325 byte limit? The data I found indicated that the default limit was *much* smaller. From this page: http://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html#BABDDFII -XX:MaxInlineSize=size Sets the maximum bytecode size (in bytes) of a method to be inlined. Append the letter k or K to indicate kilobytes, m or M to indicate megabytes, g or G to indicate gigabytes. By default, the maximum bytecode size is set to 35 bytes: -XX:MaxInlineSize=35 It would be interesting to see how adjusting some of those parameters affects performance. Does JITWatch have tools for measuring that sort of thing? Cheers, Scott > On Nov 3, 2014, at 6:42 PM, Chris Newland wrote: > > Hi all, > > As part of the JITWatch[1] project I've written a tool called JarScan > which counts the bytecode size of methods in a jar and logs those methods > which are above HotSpot's 325 byte size threshold for inlining methods it > determines are "hot". > > In jfxrt.jar from Oracle's JDK 1.8.0_25 on Linux x86_64 there are 774 > methods above the threshold which I've listed in this gist: > https://gist.github.com/chriswhocodes/c474e49f0d111757dbf2 > > A lot of these won't be found in hot code but perhaps the methods under > com.sun.javafx.geom and javafx.scene.transform could be candidates for > examination with JIT compilation in mind? > > Has anybody on the list done any experiments in this area? If not I'll try > and find some time to see if there are any gains to be made by trimming > methods (in the OpenJFX source) to fit inside the inlining threshold. > > Cheers, > > Chris > @chriswhocodes > > [1] https://github.com/AdoptOpenJDK/jitwatch > From cnewland at chrisnewland.com Tue Nov 4 06:06:57 2014 From: cnewland at chrisnewland.com (Chris Newland) Date: Tue, 4 Nov 2014 06:06:57 -0000 Subject: Quick look at JavaFX methods above the HotSpot inlining threshold In-Reply-To: References: <6f7061cddbb0f488f5fc13ff9cb8c006.squirrel@excalibur.xssl.net> Message-ID: <19237159e7ff908a03a7337992ee9c2b.squirrel@excalibur.xssl.net> Hi Scott, MaxInlineSize (default 35) is the size under which methods will be inlined regardless of whether they meet the "hot" criteria (number of invocations observed; 10,000 for server VM). FreqInlineSize (default 325 on Linux x86_64) is the size up to which HotSpot will inline methods if they meet the "hot" criteria. Documentation on these is bit sparse but they are defined in hotspot/src/cpu/x86/vm/c1_globals_x86.hpp in the OpenJDK source code. >From my experiments, tuning (increasing) these parameters can often worsen overall application behaviour, probably because they were arrived at empirically after profiling the core libs. In some of the core libs, method bytecode is pushed above the inling threshold by assert code that under most conditions (no -ea VM switch) will never be executed. I've seen assertions account for up to 25% of a method's bytecode. JITWatch has a "Sandbox" mode where you can rapidly profile the effects of tuning these parameters and can also highlight badly predicted branches and polymorphic dispatches (which can't be type-sharpened). I think it will be interesting to run JITWatch over some JavaFX applications as graphics code can have some really hot loops where small gains can make a difference. I can't promise any performance silver bullets and this is observation is only about inlining (saving the method invocation overhead). Hot code will still be JIT-compiled to native even if it's above the FreqInlineSize threshold (in fact I've seen some UI blit methods generate >32KBytes of native code thanks to some aggressive loop unrolling!). Will let you know what I find. Cheers, Chris @chriswhocodes p.s. the JITWatch UI is written in JavaFX and I've found it a really nice technology to work with :) On Tue, November 4, 2014 02:05, Scott Palmer wrote: > JITWatch looks like an interesting project. > > > Where did you get the information about the 325 byte limit? The data I > found indicated that the default limit was *much* smaller. > > From this page: > http://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html#BA > BDDFII > > > -XX:MaxInlineSize=size > Sets the maximum bytecode size (in bytes) of a method to be inlined. > Append the letter k or K to indicate kilobytes, m or M to indicate > megabytes, g or G to indicate gigabytes. By default, the maximum bytecode > size is set to 35 bytes: > > -XX:MaxInlineSize=35 > > > > It would be interesting to see how adjusting some of those parameters > affects performance. Does JITWatch have tools for measuring that sort of > thing? > > Cheers, > > > Scott > > > >> On Nov 3, 2014, at 6:42 PM, Chris Newland >> wrote: >> >> >> Hi all, >> >> >> As part of the JITWatch[1] project I've written a tool called JarScan >> which counts the bytecode size of methods in a jar and logs those >> methods which are above HotSpot's 325 byte size threshold for inlining >> methods it determines are "hot". >> >> In jfxrt.jar from Oracle's JDK 1.8.0_25 on Linux x86_64 there are 774 >> methods above the threshold which I've listed in this gist: >> https://gist.github.com/chriswhocodes/c474e49f0d111757dbf2 >> >> >> A lot of these won't be found in hot code but perhaps the methods under >> com.sun.javafx.geom and javafx.scene.transform could be candidates for >> examination with JIT compilation in mind? >> >> Has anybody on the list done any experiments in this area? If not I'll >> try and find some time to see if there are any gains to be made by >> trimming methods (in the OpenJFX source) to fit inside the inlining >> threshold. >> >> Cheers, >> >> >> Chris >> @chriswhocodes >> >> >> [1] https://github.com/AdoptOpenJDK/jitwatch >> >> > > From hastebrot at gmail.com Tue Nov 4 17:14:43 2014 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Tue, 4 Nov 2014 18:14:43 +0100 Subject: Monocle in 8u25 Message-ID: Hi! I noticed `com.sun.glass.ui.monocle.MonoclePlatformFactory` is missing from `jfxrt.jar` at least in the Windows and Linux builds of Java 8u25, although it is included in 8u20. Is there any specific reason why Monocle is not included? Is there a way to use Monocle in 8u25? Regards Benjamin (Crosspost from: https://community.oracle.com/message/12680634#12680634) From kevin.rushforth at oracle.com Tue Nov 4 17:43:09 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 04 Nov 2014 09:43:09 -0800 Subject: Monocle in 8u25 In-Reply-To: References: Message-ID: <5459102D.9010004@oracle.com> Monocle is not included in any 8u release on desktop platforms (Windows, Linux, Mac). -- Kevin Benjamin Gudehus wrote: > Hi! > > I noticed `com.sun.glass.ui.monocle.MonoclePlatformFactory` is missing from > `jfxrt.jar` at > least in the Windows and Linux builds of Java 8u25, although it is included > in 8u20. > > Is there any specific reason why Monocle is not included? Is there a way to > use Monocle > in 8u25? > > Regards > Benjamin > > (Crosspost from: https://community.oracle.com/message/12680634#12680634) > From hastebrot at gmail.com Tue Nov 4 17:51:54 2014 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Tue, 4 Nov 2014 18:51:54 +0100 Subject: Monocle in 8u25 In-Reply-To: <5459102D.9010004@oracle.com> References: <5459102D.9010004@oracle.com> Message-ID: I see. Didn't know that. Thanks for the quick response. Users from the TestFX project are interested in headless testing (e.g. on Windows with Jenkins). There was a blog post [1] a while back, which explained how to use TestFX and Java 8 to run headless tests. I've never tried this myself, but recently added adapters for GlassRobot and the JavaFX event robot to TestFX in order to allow headless testing. [1] http://ustesis.wordpress.com/2014/04/23/headless-ui-testing-with-testfx-and-javafx-8/ On Tue, Nov 4, 2014 at 6:43 PM, Kevin Rushforth wrote: > Monocle is not included in any 8u release on desktop platforms (Windows, > Linux, Mac). > > -- Kevin > > > > Benjamin Gudehus wrote: > >> Hi! >> >> I noticed `com.sun.glass.ui.monocle.MonoclePlatformFactory` is missing >> from >> `jfxrt.jar` at >> least in the Windows and Linux builds of Java 8u25, although it is >> included >> in 8u20. >> >> Is there any specific reason why Monocle is not included? Is there a way >> to >> use Monocle >> in 8u25? >> >> Regards >> Benjamin >> >> (Crosspost from: https://community.oracle.com/message/12680634#12680634) >> >> > From hastebrot at gmail.com Tue Nov 4 18:23:13 2014 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Tue, 4 Nov 2014 19:23:13 +0100 Subject: Monocle in 8u25 In-Reply-To: References: <5459102D.9010004@oracle.com> Message-ID: I ran a simple click test with "-Dglass.platform=Monocle -Dmonocle.platform=Headless -Dprism.order=sw" and the GlassRobot on Windows 7 with Java 8u20 and can confirm that the tests ran headless and clicked on an invisible table row. I also could browse the Monocle source code within IntelliJ IDEA. However on Java 8u25 the same test will fail with java.lang.ClassNotFoundException: com.sun.glass.ui.monocle.MonoclePlatformFactory Failed to load Glass factory class ---- C:\Program Files\Java\jdk1.8.0_20\bin>java -version java version "1.8.0_20-ea" Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b05) Java HotSpot(TM) 64-Bit Server VM (build 25.20-b05, mixed mode) Regards, Benjamin On Tue, Nov 4, 2014 at 6:51 PM, Benjamin Gudehus wrote: > I see. Didn't know that. Thanks for the quick response. > > Users from the TestFX project are interested in headless testing (e.g. on > Windows with Jenkins). There was a blog post [1] a while back, which > explained how to use TestFX and Java 8 to run headless tests. I've never > tried this myself, but recently added adapters for GlassRobot and the > JavaFX event robot to TestFX in order to allow headless testing. > > [1] > http://ustesis.wordpress.com/2014/04/23/headless-ui-testing-with-testfx-and-javafx-8/ > > On Tue, Nov 4, 2014 at 6:43 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Monocle is not included in any 8u release on desktop platforms (Windows, >> Linux, Mac). >> >> -- Kevin >> >> >> >> Benjamin Gudehus wrote: >> >>> Hi! >>> >>> I noticed `com.sun.glass.ui.monocle.MonoclePlatformFactory` is missing >>> from >>> `jfxrt.jar` at >>> least in the Windows and Linux builds of Java 8u25, although it is >>> included >>> in 8u20. >>> >>> Is there any specific reason why Monocle is not included? Is there a way >>> to >>> use Monocle >>> in 8u25? >>> >>> Regards >>> Benjamin >>> >>> (Crosspost from: https://community.oracle.com/message/12680634#12680634) >>> >>> >> > From kevin.rushforth at oracle.com Tue Nov 4 18:25:53 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 04 Nov 2014 10:25:53 -0800 Subject: Monocle in 8u25 In-Reply-To: References: <5459102D.9010004@oracle.com> Message-ID: <54591A31.1070709@oracle.com> > Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b05) This is an early access build and is not the final build of 8u20. Monocle was mistakenly included in some of our early access builds, but was removed prior to the fcs build. -- Kevin Benjamin Gudehus wrote: > I ran a simple click test with > > "-Dglass.platform=Monocle -Dmonocle.platform=Headless -Dprism.order=sw" > > and the GlassRobot on Windows 7 with Java 8u20 and can confirm that > the tests ran headless and clicked on an invisible table row. I also > could browse the Monocle source code within IntelliJ IDEA. > > However on Java 8u25 the same test will fail with > > java.lang.ClassNotFoundException: > com.sun.glass.ui.monocle.MonoclePlatformFactory > Failed to load Glass factory class > > ---- > > C:\Program Files\Java\jdk1.8.0_20\bin>java -version > java version "1.8.0_20-ea" > Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b05) > Java HotSpot(TM) 64-Bit Server VM (build 25.20-b05, mixed mode) > > Regards, > Benjamin > > On Tue, Nov 4, 2014 at 6:51 PM, Benjamin Gudehus > wrote: > > I see. Didn't know that. Thanks for the quick response. > > Users from the TestFX project are interested in headless testing > (e.g. on Windows with Jenkins). There was a blog post [1] a while > back, which explained how to use TestFX and Java 8 to run headless > tests. I've never tried this myself, but recently added adapters > for GlassRobot and the JavaFX event robot to TestFX in order to > allow headless testing. > > [1] > http://ustesis.wordpress.com/2014/04/23/headless-ui-testing-with-testfx-and-javafx-8/ > > On Tue, Nov 4, 2014 at 6:43 PM, Kevin Rushforth > > > wrote: > > Monocle is not included in any 8u release on desktop platforms > (Windows, Linux, Mac). > > -- Kevin > > > > Benjamin Gudehus wrote: > > Hi! > > I noticed > `com.sun.glass.ui.monocle.MonoclePlatformFactory` is > missing from > `jfxrt.jar` at > least in the Windows and Linux builds of Java 8u25, > although it is included > in 8u20. > > Is there any specific reason why Monocle is not included? > Is there a way to > use Monocle > in 8u25? > > Regards > Benjamin > > (Crosspost from: > https://community.oracle.com/message/12680634#12680634) > > > > From hastebrot at gmail.com Tue Nov 4 18:36:09 2014 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Tue, 4 Nov 2014 19:36:09 +0100 Subject: Monocle in 8u25 In-Reply-To: <54591A31.1070709@oracle.com> References: <5459102D.9010004@oracle.com> <54591A31.1070709@oracle.com> Message-ID: Thank you. That makes it clearer. :) Is it possible to supply the headless part of Monocle in an external Jar for desktop platforms? As far as I know the only possibility to run TestFX tests with Hudson/Jenkins is in headless mode. TestFX's tests itself can only run with the X virtual framebuffer on Linux test clients for the Travis CI so far. So far the only advice I could give TestFX users who like to run headless tests is to use 1.8.0_20-ea-b05. On Tue, Nov 4, 2014 at 7:25 PM, Kevin Rushforth wrote: > > > Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b05) > > This is an early access build and is not the final build of 8u20. Monocle > was mistakenly included in some of our early access builds, but was removed > prior to the fcs build. > > > -- Kevin > > > Benjamin Gudehus wrote: > > I ran a simple click test with > > "-Dglass.platform=Monocle -Dmonocle.platform=Headless -Dprism.order=sw" > > and the GlassRobot on Windows 7 with Java 8u20 and can confirm that the > tests ran headless and clicked on an invisible table row. I also could > browse the Monocle source code within IntelliJ IDEA. > > However on Java 8u25 the same test will fail with > > java.lang.ClassNotFoundException: > com.sun.glass.ui.monocle.MonoclePlatformFactory > Failed to load Glass factory class > > ---- > > C:\Program Files\Java\jdk1.8.0_20\bin>java -version > java version "1.8.0_20-ea" > Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b05) > Java HotSpot(TM) 64-Bit Server VM (build 25.20-b05, mixed mode) > > Regards, > Benjamin > > On Tue, Nov 4, 2014 at 6:51 PM, Benjamin Gudehus > wrote: > >> I see. Didn't know that. Thanks for the quick response. >> >> Users from the TestFX project are interested in headless testing (e.g. >> on Windows with Jenkins). There was a blog post [1] a while back, which >> explained how to use TestFX and Java 8 to run headless tests. I've never >> tried this myself, but recently added adapters for GlassRobot and the >> JavaFX event robot to TestFX in order to allow headless testing. >> >> [1] >> http://ustesis.wordpress.com/2014/04/23/headless-ui-testing-with-testfx-and-javafx-8/ >> >> On Tue, Nov 4, 2014 at 6:43 PM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> Monocle is not included in any 8u release on desktop platforms (Windows, >>> Linux, Mac). >>> >>> -- Kevin >>> >>> >>> >>> Benjamin Gudehus wrote: >>> >>>> Hi! >>>> >>>> I noticed `com.sun.glass.ui.monocle.MonoclePlatformFactory` is missing >>>> from >>>> `jfxrt.jar` at >>>> least in the Windows and Linux builds of Java 8u25, although it is >>>> included >>>> in 8u20. >>>> >>>> Is there any specific reason why Monocle is not included? Is there a >>>> way to >>>> use Monocle >>>> in 8u25? >>>> >>>> Regards >>>> Benjamin >>>> >>>> (Crosspost from: https://community.oracle.com/message/12680634#12680634 >>>> ) >>>> >>>> >>> >> > From hastebrot at gmail.com Tue Nov 4 19:42:45 2014 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Tue, 4 Nov 2014 20:42:45 +0100 Subject: Monocle in 8u25 In-Reply-To: References: <5459102D.9010004@oracle.com> <54591A31.1070709@oracle.com> Message-ID: Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory won't retrieve externally defined PlatformFactorys. So I will try to set the PlatformFactory.instance field manually, before the Application/Tookit/FX-Thread is launched. On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus wrote: > Thank you. That makes it clearer. :) > > Is it possible to supply the headless part of Monocle in an external Jar > for desktop platforms? > > As far as I know the only possibility to run TestFX tests with > Hudson/Jenkins is in headless mode. > TestFX's tests itself can only run with the X virtual framebuffer on Linux > test clients for the Travis CI so far. > > So far the only advice I could give TestFX users who like to run headless > tests is to use 1.8.0_20-ea-b05. > From kevin.rushforth at oracle.com Tue Nov 4 22:59:08 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 04 Nov 2014 14:59:08 -0800 Subject: [8u40] review request: RT-34388: [Mac] Update build system to properly support Xcode 5 and later Message-ID: <54595A3C.10503@oracle.com> Dave D and Dave H, Please review the following: https://javafx-jira.kenai.com/browse/RT-34388 http://cr.openjdk.java.net/~kcr/RT-34388/webrev.00/ Thanks. -- Kevin From kevin.rushforth at oracle.com Tue Nov 4 23:01:11 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 04 Nov 2014 15:01:11 -0800 Subject: [8u40] review request: RT-39262: Remove "/arch:sse" from 64-bit Windows build Message-ID: <54595AB7.4010508@oracle.com> Hi Vadim and Dave, Please review the following simple change: https://javafx-jira.kenai.com/browse/RT-39262 http://cr.openjdk.java.net/~kcr/RT-39262/webrev.00/ Thanks. -- Kevin From hastebrot at gmail.com Tue Nov 4 23:17:15 2014 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Wed, 5 Nov 2014 00:17:15 +0100 Subject: Monocle in 8u25 In-Reply-To: References: <5459102D.9010004@oracle.com> <54591A31.1070709@oracle.com> Message-ID: I managed to run Monocle/Headless on Windows with 8u25. This will allow users to run headless tests. All what is needed is to copy all files from "com/sun/glass/ui/monocle" of "javafx-src.zip" and add the cursor resource files from "modules/graphics/src/main/resources/com/sun/glass/ui/monocle" of the related hg tag in the OpenJFX repository [1]. Before Application#launch() is called we need to manually set the Glass and Monocle platforms: accessStaticField(com.sun.glass.ui.PlatformFactory.class, "instance", new com.sun.glass.ui.monocle.MonoclePlatformFactory()); accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class, "platform", new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); The directory structure in 8u40 is a bit different, but there could be added version checks. Checking for the JVM vars "glass.platform" and "monocle.platform" might be also added to this code. [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus wrote: > Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory won't > retrieve externally defined PlatformFactorys. So I will try to set the > PlatformFactory.instance field manually, before the > Application/Tookit/FX-Thread is launched. > > On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus > wrote: > >> Thank you. That makes it clearer. :) >> >> Is it possible to supply the headless part of Monocle in an external Jar >> for desktop platforms? >> >> As far as I know the only possibility to run TestFX tests with >> Hudson/Jenkins is in headless mode. >> TestFX's tests itself can only run with the X virtual framebuffer on >> Linux test clients for the Travis CI so far. >> >> So far the only advice I could give TestFX users who like to run headless >> tests is to use 1.8.0_20-ea-b05. >> > From kevin.rushforth at oracle.com Tue Nov 4 23:26:47 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 04 Nov 2014 15:26:47 -0800 Subject: [8u40] review request: RT-38991: [CSS] Absolute URL in stylesheet does not work Message-ID: <545960B7.3030709@oracle.com> David (and Jonathan and Steve), Please review the following: https://javafx-jira.kenai.com/browse/RT-38991 http://cr.openjdk.java.net/~kcr/RT-38991/webrev.00/ Based on my testing it should implement what is wanted, but your expert eyes would be good here. More testing is needed. -- Kevin From jonathan.giles at oracle.com Wed Nov 5 00:32:16 2014 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 05 Nov 2014 13:32:16 +1300 Subject: How to get a popup Dialog to inherit styles from main app? In-Reply-To: References: Message-ID: <54597010.4060409@oracle.com> Please file a jira issue and we can work on this in there. Most probably the solution will be that we have the underlying stage (in the HeavyweightDialog class, as you mention) copy in the stylesheets of its owner window automatically. -- Jonathan On 2/11/2014 4:08 a.m., Pete Moss wrote: > I am just getting started using the Dialog class and I noticed that my > dialog content is not picking up styles that I've added to a global style > sheet in my app. I suspect because Dialog's HeavyweightDialog is creating a > new Stage. > > In my Main class I have: > > Scene scene = new Scene(root, 600, 500, Color.YELLOW); > String s = Main.class.getResource("ui/styles.css").toExternalForm(); > scene.getStylesheets().add(s); > > How can I get that stylesheet applied to the scene graph in my popup > dialog? At what point in the lifecycle of my dialog can I do this? > > Thanks. From felix.bembrick at gmail.com Wed Nov 5 10:46:54 2014 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Wed, 5 Nov 2014 21:46:54 +1100 Subject: RT-36146: request to reopen Message-ID: As can be seen in the issue notes, I do not believe this issue is "Not an issue" and really needs to be fixed. https://javafx-jira.kenai.com/browse/RT-36146 I hope everyone concerned about the quality of font rendering on Windows with JavaFX looks at this issue and adds their comments. Felix From sean.true at gmail.com Wed Nov 5 15:36:46 2014 From: sean.true at gmail.com (Sean True) Date: Wed, 5 Nov 2014 10:36:46 -0500 Subject: Monocle in 8u25 In-Reply-To: References: <5459102D.9010004@oracle.com> <54591A31.1070709@oracle.com> Message-ID: Did you build the glass/ui/monocle sources into a separate jar, or did you do a complete OpenJFX build? If you did a separate build, a recipe would be extremely helpful. -- Sean On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus wrote: > I managed to run Monocle/Headless on Windows with 8u25. This will allow > users to run headless tests. > > All what is needed is to copy all files from "com/sun/glass/ui/monocle" of > "javafx-src.zip" and add the > cursor resource files from > "modules/graphics/src/main/resources/com/sun/glass/ui/monocle" of the > related hg tag in the OpenJFX repository [1]. > > Before Application#launch() is called we need to manually set the Glass and > Monocle platforms: > > accessStaticField(com.sun.glass.ui.PlatformFactory.class, "instance", > new com.sun.glass.ui.monocle.MonoclePlatformFactory()); > accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class, > "platform", > new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); > > The directory structure in 8u40 is a bit different, but there could be > added version checks. Checking > for the JVM vars "glass.platform" and "monocle.platform" might be also > added to this code. > > [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags > > > On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus > wrote: > > > Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory won't > > retrieve externally defined PlatformFactorys. So I will try to set the > > PlatformFactory.instance field manually, before the > > Application/Tookit/FX-Thread is launched. > > > > On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus > > wrote: > > > >> Thank you. That makes it clearer. :) > >> > >> Is it possible to supply the headless part of Monocle in an external Jar > >> for desktop platforms? > >> > >> As far as I know the only possibility to run TestFX tests with > >> Hudson/Jenkins is in headless mode. > >> TestFX's tests itself can only run with the X virtual framebuffer on > >> Linux test clients for the Travis CI so far. > >> > >> So far the only advice I could give TestFX users who like to run > headless > >> tests is to use 1.8.0_20-ea-b05. > >> > > > From hastebrot at gmail.com Wed Nov 5 15:57:39 2014 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Wed, 5 Nov 2014 16:57:39 +0100 Subject: Monocle in 8u25 In-Reply-To: References: <5459102D.9010004@oracle.com> <54591A31.1070709@oracle.com> Message-ID: Hi Sean, I've put the Monocle sources directly in my code directories for testing purposes. Putting it into a separate Jar is possible and I thought that pre-compiled jars could be provided via Maven. I didn't do a complete OpenJFX build, because I was only interested in the Headless component of Monocle, i.e. I didn't needed the platform-dependent dynamic libraries. Rough instructions were given in a previous mail. There were some request to provide the pre-compoile jars so I will additionally set up a public repository with detailed instructions when I'm back home. --Benjamin On 11/5/14, Sean True wrote: > Did you build the glass/ui/monocle sources into a separate jar, or did you > do a complete OpenJFX build? > > If you did a separate build, a recipe would be extremely helpful. > > -- Sean > > On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus > wrote: > >> I managed to run Monocle/Headless on Windows with 8u25. This will allow >> users to run headless tests. >> >> All what is needed is to copy all files from "com/sun/glass/ui/monocle" >> of >> "javafx-src.zip" and add the >> cursor resource files from >> "modules/graphics/src/main/resources/com/sun/glass/ui/monocle" of the >> related hg tag in the OpenJFX repository [1]. >> >> Before Application#launch() is called we need to manually set the Glass >> and >> Monocle platforms: >> >> accessStaticField(com.sun.glass.ui.PlatformFactory.class, "instance", >> new com.sun.glass.ui.monocle.MonoclePlatformFactory()); >> accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class, >> "platform", >> new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); >> >> The directory structure in 8u40 is a bit different, but there could be >> added version checks. Checking >> for the JVM vars "glass.platform" and "monocle.platform" might be also >> added to this code. >> >> [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags >> >> >> On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus >> wrote: >> >> > Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory >> > won't >> > retrieve externally defined PlatformFactorys. So I will try to set the >> > PlatformFactory.instance field manually, before the >> > Application/Tookit/FX-Thread is launched. >> > >> > On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus >> > wrote: >> > >> >> Thank you. That makes it clearer. :) >> >> >> >> Is it possible to supply the headless part of Monocle in an external >> >> Jar >> >> for desktop platforms? >> >> >> >> As far as I know the only possibility to run TestFX tests with >> >> Hudson/Jenkins is in headless mode. >> >> TestFX's tests itself can only run with the X virtual framebuffer on >> >> Linux test clients for the Travis CI so far. >> >> >> >> So far the only advice I could give TestFX users who like to run >> headless >> >> tests is to use 1.8.0_20-ea-b05. >> >> >> > >> > From ngalarneau at ABINITIO.COM Wed Nov 5 16:18:37 2014 From: ngalarneau at ABINITIO.COM (ngalarneau at ABINITIO.COM) Date: Wed, 5 Nov 2014 11:18:37 -0500 Subject: Questions about Platform.runLater() and Application.start() In-Reply-To: <54579827.4080109@oracle.com> References: <54579827.4080109@oracle.com> Message-ID: Steve, Thank you for that important addition. Is it true that this, also, is not a special case? In other words, is this how it works? - the input queue contains both Events and Runnables (from runLater() and the first one containing a call to Application.start()) - one item is processed from the input queue at a time - if the processing of that item does a Dialog.showAndWait(), then: - - the processing of that item is suspended (the thread blocks?) until showAndWait() returns and - - a new item processor picks the next item off of the input queue & starts processing it It looks like the "JavaFX Application Thread" is the item processor. Neil From: Stephen F Northover To: ngalarneau at ABINITIO.COM, openjfx-dev at openjdk.java.net, Date: 11/03/2014 09:58 AM Subject: Re: Questions about Platform.runLater() and Application.start() Hi there, If you en-queue a runnable in start() it will not run until start() completes unless you open a dialog in start() that waits for a result before proceeding. In that case, your runnable will run. You are correct about runnables and input events being part of the input queue for the application thread. Threads are not interrupted to run code. Steve On 2014-11-03, 8:49 AM, ngalarneau at ABINITIO.COM wrote: > Hello, > > Is there documentation that describes somewhere how Platform.runLater() & > Application.start() interact? > > My impression is that (roughly speaking): > - there is an EventQueue (to use the Swing terminology). > - the EventQueue holds both UI events (like mouse click) as well as the > Runnables enqueued by runLater(). > - the first (?) event put in the EventQueue is a Runnable representing > Application.start(). > > > My impression is, therefore, that any Runnables enqueued during > Application.start() won't be run until after start() completes. > This behavior is the same as one runLater() not interrupting another > runLater(). > > > Is this sort of stuff documented somewhere? > > Is this the right way to think about this part of the system? (even if the > implementation is different) > > Are there other special things to be aware of about Application.start()? > > > Thanks, > > Neil > > P.S. I am using javafx.concurrent.Service & Task and am hitting some > issues. > NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution. From kevin.rushforth at oracle.com Wed Nov 5 16:25:49 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 05 Nov 2014 08:25:49 -0800 Subject: Questions about Platform.runLater() and Application.start() In-Reply-To: References: <54579827.4080109@oracle.com> Message-ID: <545A4F8D.2070803@oracle.com> Hi Neal, You are correct. The JavaFX Application Thread is the event thread for JavaFX. It processes input events, pulses, animations, and Runnables that are submitted via runLater. Other than the special case when a nested event loop is spun up (e.g., showAndWait()) a new runnable or event will not be processed until the current one has returned to the event loop. -- Kevin ngalarneau at ABINITIO.COM wrote: > Steve, > > Thank you for that important addition. > > Is it true that this, also, is not a special case? > > In other words, is this how it works? > - the input queue contains both Events and Runnables (from runLater() and > the first one containing a call to Application.start()) > - one item is processed from the input queue at a time > - if the processing of that item does a Dialog.showAndWait(), then: > - - the processing of that item is suspended (the thread blocks?) until > showAndWait() returns and > - - a new item processor picks the next item off of the input queue & > starts processing it > > It looks like the "JavaFX Application Thread" is the item processor. > > > Neil > > > > > From: Stephen F Northover > To: ngalarneau at ABINITIO.COM, openjfx-dev at openjdk.java.net, > Date: 11/03/2014 09:58 AM > Subject: Re: Questions about Platform.runLater() and > Application.start() > > > > Hi there, > > If you en-queue a runnable in start() it will not run until start() > completes unless you open a dialog in start() that waits for a result > before proceeding. In that case, your runnable will run. You are > correct about runnables and input events being part of the input queue > for the application thread. Threads are not interrupted to run code. > > Steve > > On 2014-11-03, 8:49 AM, ngalarneau at ABINITIO.COM wrote: > >> Hello, >> >> Is there documentation that describes somewhere how Platform.runLater() >> > & > >> Application.start() interact? >> >> My impression is that (roughly speaking): >> - there is an EventQueue (to use the Swing terminology). >> - the EventQueue holds both UI events (like mouse click) as well as >> > the > >> Runnables enqueued by runLater(). >> - the first (?) event put in the EventQueue is a Runnable representing >> Application.start(). >> >> >> My impression is, therefore, that any Runnables enqueued during >> Application.start() won't be run until after start() completes. >> This behavior is the same as one runLater() not interrupting another >> runLater(). >> >> >> Is this sort of stuff documented somewhere? >> >> Is this the right way to think about this part of the system? (even if >> > the > >> implementation is different) >> >> Are there other special things to be aware of about Application.start()? >> >> >> Thanks, >> >> Neil >> >> P.S. I am using javafx.concurrent.Service & Task and am hitting some >> issues. >> >> > > > > NOTICE from Ab Initio: This email (including any attachments) may contain > information that is subject to confidentiality obligations or is legally > privileged, and sender does not waive confidentiality or privilege. If > received in error, please notify the sender, delete this email, and make > no further use, disclosure, or distribution. > From sean.true at gmail.com Wed Nov 5 16:28:45 2014 From: sean.true at gmail.com (Sean True) Date: Wed, 5 Nov 2014 11:28:45 -0500 Subject: Monocle in 8u25 In-Reply-To: References: <5459102D.9010004@oracle.com> <54591A31.1070709@oracle.com> Message-ID: Setting this up in a repo with instructions for the slow and the lazy :-) would be really helpful. Thank you. -- Sean On Wed, Nov 5, 2014 at 10:57 AM, Benjamin Gudehus wrote: > Hi Sean, > > I've put the Monocle sources directly in my code directories for > testing purposes. Putting it into a separate Jar is possible and I > thought that pre-compiled jars could be provided via Maven. > > I didn't do a complete OpenJFX build, because I was only interested in > the Headless component of Monocle, i.e. I didn't needed the > platform-dependent dynamic libraries. > > Rough instructions were given in a previous mail. There were some > request to provide the pre-compoile jars so I will additionally set up > a public repository with detailed instructions when I'm back home. > > --Benjamin > > On 11/5/14, Sean True wrote: > > Did you build the glass/ui/monocle sources into a separate jar, or did > you > > do a complete OpenJFX build? > > > > If you did a separate build, a recipe would be extremely helpful. > > > > -- Sean > > > > On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus > > wrote: > > > >> I managed to run Monocle/Headless on Windows with 8u25. This will allow > >> users to run headless tests. > >> > >> All what is needed is to copy all files from "com/sun/glass/ui/monocle" > >> of > >> "javafx-src.zip" and add the > >> cursor resource files from > >> "modules/graphics/src/main/resources/com/sun/glass/ui/monocle" of the > >> related hg tag in the OpenJFX repository [1]. > >> > >> Before Application#launch() is called we need to manually set the Glass > >> and > >> Monocle platforms: > >> > >> accessStaticField(com.sun.glass.ui.PlatformFactory.class, "instance", > >> new com.sun.glass.ui.monocle.MonoclePlatformFactory()); > >> accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class, > >> "platform", > >> new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); > >> > >> The directory structure in 8u40 is a bit different, but there could be > >> added version checks. Checking > >> for the JVM vars "glass.platform" and "monocle.platform" might be also > >> added to this code. > >> > >> [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags > >> > >> > >> On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus > >> wrote: > >> > >> > Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory > >> > won't > >> > retrieve externally defined PlatformFactorys. So I will try to set the > >> > PlatformFactory.instance field manually, before the > >> > Application/Tookit/FX-Thread is launched. > >> > > >> > On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus > > >> > wrote: > >> > > >> >> Thank you. That makes it clearer. :) > >> >> > >> >> Is it possible to supply the headless part of Monocle in an external > >> >> Jar > >> >> for desktop platforms? > >> >> > >> >> As far as I know the only possibility to run TestFX tests with > >> >> Hudson/Jenkins is in headless mode. > >> >> TestFX's tests itself can only run with the X virtual framebuffer on > >> >> Linux test clients for the Travis CI so far. > >> >> > >> >> So far the only advice I could give TestFX users who like to run > >> headless > >> >> tests is to use 1.8.0_20-ea-b05. > >> >> > >> > > >> > > > From tbee at tbee.org Wed Nov 5 19:20:45 2014 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 05 Nov 2014 20:20:45 +0100 Subject: Monocle in 8u25 In-Reply-To: References: <5459102D.9010004@oracle.com> <54591A31.1070709@oracle.com> Message-ID: <545A788D.9030509@tbee.org> This is extremely good news. I have no problem to "drag" that library along in the JFXtras project (project name seems to be a good match for this usage ;-) and release it to maven - if that is allowed by the JavaFX license. Tom On 5-11-2014 16:57, Benjamin Gudehus wrote: > Hi Sean, > > I've put the Monocle sources directly in my code directories for > testing purposes. Putting it into a separate Jar is possible and I > thought that pre-compiled jars could be provided via Maven. > > I didn't do a complete OpenJFX build, because I was only interested in > the Headless component of Monocle, i.e. I didn't needed the > platform-dependent dynamic libraries. > > Rough instructions were given in a previous mail. There were some > request to provide the pre-compoile jars so I will additionally set up > a public repository with detailed instructions when I'm back home. > > --Benjamin > > On 11/5/14, Sean True wrote: >> Did you build the glass/ui/monocle sources into a separate jar, or did you >> do a complete OpenJFX build? >> >> If you did a separate build, a recipe would be extremely helpful. >> >> -- Sean >> >> On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus >> wrote: >> >>> I managed to run Monocle/Headless on Windows with 8u25. This will allow >>> users to run headless tests. >>> >>> All what is needed is to copy all files from "com/sun/glass/ui/monocle" >>> of >>> "javafx-src.zip" and add the >>> cursor resource files from >>> "modules/graphics/src/main/resources/com/sun/glass/ui/monocle" of the >>> related hg tag in the OpenJFX repository [1]. >>> >>> Before Application#launch() is called we need to manually set the Glass >>> and >>> Monocle platforms: >>> >>> accessStaticField(com.sun.glass.ui.PlatformFactory.class, "instance", >>> new com.sun.glass.ui.monocle.MonoclePlatformFactory()); >>> accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class, >>> "platform", >>> new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); >>> >>> The directory structure in 8u40 is a bit different, but there could be >>> added version checks. Checking >>> for the JVM vars "glass.platform" and "monocle.platform" might be also >>> added to this code. >>> >>> [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags >>> >>> >>> On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus >>> wrote: >>> >>>> Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory >>>> won't >>>> retrieve externally defined PlatformFactorys. So I will try to set the >>>> PlatformFactory.instance field manually, before the >>>> Application/Tookit/FX-Thread is launched. >>>> >>>> On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus >>>> wrote: >>>> >>>>> Thank you. That makes it clearer. :) >>>>> >>>>> Is it possible to supply the headless part of Monocle in an external >>>>> Jar >>>>> for desktop platforms? >>>>> >>>>> As far as I know the only possibility to run TestFX tests with >>>>> Hudson/Jenkins is in headless mode. >>>>> TestFX's tests itself can only run with the X virtual framebuffer on >>>>> Linux test clients for the Travis CI so far. >>>>> >>>>> So far the only advice I could give TestFX users who like to run >>> headless >>>>> tests is to use 1.8.0_20-ea-b05. >>>>> From morris.meyer at oracle.com Thu Nov 6 16:29:15 2014 From: morris.meyer at oracle.com (Morris Meyer) Date: Thu, 06 Nov 2014 11:29:15 -0500 Subject: [8u40] Review request: RT-38641- Unknown error 0x80DE0001 when trying to drag TreeView node Message-ID: <545BA1DB.6000805@oracle.com> David and Kevin, Could you please review the following change to remove the extraneous Windows COM debug output from Glass drag-and-drop? Thanks much, --morris JIRA - https://javafx-jira.kenai.com/browse/RT-38641 WEBREV - http://cr.openjdk.java.net/~morris/RT-38641.01/ From kevin.rushforth at oracle.com Thu Nov 6 18:11:46 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 06 Nov 2014 10:11:46 -0800 Subject: FX JIRA release Lombard --> 8 Message-ID: <545BB9E2.7030100@oracle.com> In case anyone wonders where the "Lombard" release went in FX JIRA, it has been renamed to "8" to match the JDK and to match the rest of the releases. If you have any JIRA queries then you will need to update them. -- Kevin From ngalarneau at ABINITIO.COM Fri Nov 7 14:00:43 2014 From: ngalarneau at ABINITIO.COM (ngalarneau at ABINITIO.COM) Date: Fri, 7 Nov 2014 09:00:43 -0500 Subject: Can a Button refuse focus? Message-ID: Can a control in JavaFX refuse focus? Often you don't want buttons in a toolbar to receive focus. Although the ToolBar javadoc states that focusTraversable is set to false, in Ensemble8, the buttons in the toolbar both are in the focus traversal cycle & receive focus when clicked on. In this post ( http://bekwam.blogspot.co.nz/2014/11/javafx-cut-copy-and-paste-from-toolbar.html ) linked to from FX Experience, the fellow does a fragile & incomplete workaround for this problem. Making the button not be focus traversable isn't good enough (if I understand it correctly), because the user could still click on the button & then it would take focus. Node.isCanReceiveFocus() is, of course, not overridable, so that avenue is blocked. Thanks, Neil NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution. From ngalarneau at ABINITIO.COM Fri Nov 7 14:11:12 2014 From: ngalarneau at ABINITIO.COM (ngalarneau at ABINITIO.COM) Date: Fri, 7 Nov 2014 09:11:12 -0500 Subject: Can a Button refuse focus? In-Reply-To: References: Message-ID: To be clear, the blog writer did the best he could & acknowledged that the approach he was forced to take was fragile & incomplete. Neil From: ngalarneau at ABINITIO.COM To: openjfx-dev at openjdk.java.net, Date: 11/07/2014 09:01 AM Subject: Can a Button refuse focus? Sent by: "openjfx-dev" Can a control in JavaFX refuse focus? Often you don't want buttons in a toolbar to receive focus. Although the ToolBar javadoc states that focusTraversable is set to false, in Ensemble8, the buttons in the toolbar both are in the focus traversal cycle & receive focus when clicked on. In this post ( http://bekwam.blogspot.co.nz/2014/11/javafx-cut-copy-and-paste-from-toolbar.html ) linked to from FX Experience, the fellow does a fragile & incomplete workaround for this problem. Making the button not be focus traversable isn't good enough (if I understand it correctly), because the user could still click on the button & then it would take focus. Node.isCanReceiveFocus() is, of course, not overridable, so that avenue is blocked. Thanks, Neil NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution. From vadim.pakhnushev at oracle.com Fri Nov 7 17:45:53 2014 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 07 Nov 2014 20:45:53 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <545D0551.8080709@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PDT until 1pm PDT. Happy testing! Thanks, Vadim From navdeepsingh.sidhu95 at gmail.com Fri Nov 7 20:10:50 2014 From: navdeepsingh.sidhu95 at gmail.com (Navdeep Singh Sidhu) Date: Sat, 8 Nov 2014 01:40:50 +0530 Subject: How to add comboboxcell in tableView (JavaFx)? Message-ID: Hello, Is there any good examples to add ComboboxCell in TableView? I am trying to add this but i couldn't find any good example on internet. :( Thanks & Regards From kishori.sharan at gmail.com Fri Nov 7 20:50:49 2014 From: kishori.sharan at gmail.com (Kishori Sharan) Date: Fri, 7 Nov 2014 14:50:49 -0600 Subject: How to add comboboxcell in tableView (JavaFx)? In-Reply-To: References: Message-ID: Sorry. I forgot to add a disclaimer in my previous email that the attached chapter is the first draft and you may find errors. On Fri, Nov 7, 2014 at 2:10 PM, Navdeep Singh Sidhu < navdeepsingh.sidhu95 at gmail.com> wrote: > Hello, > > Is there any good examples to add ComboboxCell in TableView? I am trying to > add this but i couldn't find any good example on internet. :( > > Thanks & Regards > From felix.bembrick at gmail.com Fri Nov 7 20:51:32 2014 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Sat, 8 Nov 2014 07:51:32 +1100 Subject: Fwd: RT-36146: request to reopen In-Reply-To: References: Message-ID: How do I get an issue re-opened? ---------- Forwarded message ---------- From: Felix Bembrick Date: 5 November 2014 21:46 Subject: RT-36146: request to reopen To: "openjfx-dev at openjdk.java.net List" As can be seen in the issue notes, I do not believe this issue is "Not an issue" and really needs to be fixed. https://javafx-jira.kenai.com/browse/RT-36146 I hope everyone concerned about the quality of font rendering on Windows with JavaFX looks at this issue and adds their comments. Felix From kevin.rushforth at oracle.com Fri Nov 7 20:55:12 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 07 Nov 2014 12:55:12 -0800 Subject: Fwd: RT-36146: request to reopen In-Reply-To: References: Message-ID: <545D31B0.7040305@oracle.com> Hi Felix, Sorry for the delay in responding. You need to first convince us that there is a bug here. Can you send me a zip file with the images for comparison. I'll get Phil or Felipe to look at them and comment. -- Kevin Felix Bembrick wrote: > How do I get an issue re-opened? > > > ---------- Forwarded message ---------- > From: Felix Bembrick > Date: 5 November 2014 21:46 > Subject: RT-36146: request to reopen > To: "openjfx-dev at openjdk.java.net List" > > > As can be seen in the issue notes, I do not believe this issue is "Not an > issue" and really needs to be fixed. > > https://javafx-jira.kenai.com/browse/RT-36146 > > I hope everyone concerned about the quality of font rendering on Windows > with JavaFX looks at this issue and adds their comments. > > Felix > From tbee at tbee.org Fri Nov 7 21:49:01 2014 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 07 Nov 2014 22:49:01 +0100 Subject: off topic: LocalDate Message-ID: <545D3E4D.1050500@tbee.org> I'm trying to do some refactoring on the Agenda control; its skin class is quite large. I figured I also switch to use the new Java 8 date time API, because it is much easier than Calendar. At least... That is what I expect after using JodaTime a lot in my projects. But, ah, does anyone know how we got from JodaTime's "localDate.toDate()" to Java 8's "Date.from(localDate.atZone(ZoneId.systemDefault()).toInstant())"??? From omathe at free.fr Sun Nov 9 07:29:25 2014 From: omathe at free.fr (omathe at free.fr) Date: Sun, 9 Nov 2014 08:29:25 +0100 (CET) Subject: off topic: LocalDate In-Reply-To: <545D3E4D.1050500@tbee.org> Message-ID: <715923014.297483941.1415518165439.JavaMail.root@zimbra63-e11.priv.proxad.net> Date date = Date.from(Instant.now()); ----- Mail original ----- De: "Tom Eugelink" ?: openjfx-dev at openjdk.java.net Envoy?: Vendredi 7 Novembre 2014 22:49:01 Objet: off topic: LocalDate I'm trying to do some refactoring on the Agenda control; its skin class is quite large. I figured I also switch to use the new Java 8 date time API, because it is much easier than Calendar. At least... That is what I expect after using JodaTime a lot in my projects. But, ah, does anyone know how we got from JodaTime's "localDate.toDate()" to Java 8's "Date.from(localDate.atZone(ZoneId.systemDefault()).toInstant())"??? From tbee at tbee.org Sun Nov 9 08:08:39 2014 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 09 Nov 2014 09:08:39 +0100 Subject: off topic: LocalDate In-Reply-To: <715923014.297483941.1415518165439.JavaMail.root@zimbra63-e11.priv.proxad.net> References: <715923014.297483941.1415518165439.JavaMail.root@zimbra63-e11.priv.proxad.net> Message-ID: <545F2107.8000307@tbee.org> Starting point is a LocalDate. On 9-11-2014 08:29, omathe at free.fr wrote: > Date date = Date.from(Instant.now()); > > ----- Mail original ----- > De: "Tom Eugelink" > ?: openjfx-dev at openjdk.java.net > Envoy?: Vendredi 7 Novembre 2014 22:49:01 > Objet: off topic: LocalDate > > I'm trying to do some refactoring on the Agenda control; its skin class is quite large. I figured I also switch to use the new Java 8 date time API, because it is much easier than Calendar. At least... That is what I expect after using JodaTime a lot in my projects. > > But, ah, does anyone know how we got from JodaTime's "localDate.toDate()" to Java 8's "Date.from(localDate.atZone(ZoneId.systemDefault()).toInstant())"??? From anton.tarasov at oracle.com Mon Nov 10 07:48:30 2014 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Mon, 10 Nov 2014 11:48:30 +0400 Subject: [8u40] Review request: RT-39332 A typo in ViewPainter.getPixelScaleFactor Message-ID: <54606DCE.5080705@oracle.com> Hello, A typo is fixed: https://javafx-jira.kenai.com/browse/RT-39332 Thanks, Anton. From vadim.pakhnushev at oracle.com Mon Nov 10 16:30:59 2014 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Mon, 10 Nov 2014 19:30:59 +0300 Subject: [8u40] Review request for RT-39304: Some tests doesn't test actual controls classes Message-ID: <5460E843.3070406@oracle.com> Hi Kevin, Please review this fix: https://javafx-jira.kenai.com/browse/RT-39304 http://cr.openjdk.java.net/~vadim/RT-39304/webrev.00/ Thanks, Vadim From guenther.jeffrey at gmail.com Mon Nov 10 20:04:03 2014 From: guenther.jeffrey at gmail.com (Jeffrey Guenther) Date: Mon, 10 Nov 2014 12:04:03 -0800 Subject: Building Creative Graphics Applications in JavaFX Message-ID: <6BDD9DB1-8C56-406F-9244-6E0FC96EB341@gmail.com> Hello, I have been using JavaFX for the last couple years to build a prototype for my PhD research. I?ve really enjoyed myself as I?ve used it. For the most part, I can implement a UI as fast as I can understand what it needs to do. The scene graph is wonderful. JavaFX is great if you want to build a more traditional application that uses buttons, list views, tables views, etc. What I?m still trying to understand is how well JavaFX can help me build more complex interactive graphics applications. The majority of my work is in data visualization and image creation. I?ve been working some something like NodeBox or Grasshopper for Rhino. I?ll finish the prototype with JavaFX. What I?m pondering is if I can/should keep using JavaFX should I take the project commercial or will it be coding myself into a corner. My question to you is: has any one tried to build, even as a sample project, a small image editor or vector drawing application with JavaFX? What worked well? What kinds of problems did you run into? What has been the experience of the SceneBuilder team? SceneBuilder is probably the most advanced creative tool I?ve seen built with JavaFX so far. I read a post about there being a OpenGL view added to JavaFX one day. What?s the latest on this? I?m very convinced by the work done by Netflix with RxJava and their other projects that Java/JVM applications work great in the enterprise on the server. What I?m wondering is if Java and JavaFX can compete with tools like Apple?s Cocoa or Qt for building creative applications like say the next generations of Photoshop and Illustrator, or some other new innovative way of creating content. Thank you for your time! Jeff From kevin.rushforth at oracle.com Mon Nov 10 21:04:00 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 10 Nov 2014 13:04:00 -0800 Subject: 8u-dev unlocked following this week's sanity testing Message-ID: <54612840.9050000@oracle.com> From morris.meyer at oracle.com Mon Nov 10 22:06:31 2014 From: morris.meyer at oracle.com (Morris Meyer) Date: Mon, 10 Nov 2014 17:06:31 -0500 Subject: [8u40] Review request: RT-34668 Mac: Assertion failures when exiting VideoCube test Message-ID: <546136E7.5090705@oracle.com> David, Kevin and Chien, Please review my fix for RT-34668 to remove the spurious extra runnable that sometimes pops up after applications are quit on the Mac. Thanks, --morris BUG - https://javafx-jira.kenai.com/browse/RT-34668 WEBREV - http://cr.openjdk.java.net/~morris/RT-34668.01 From clong9993 at gmail.com Tue Nov 11 01:16:40 2014 From: clong9993 at gmail.com (Cheryl Long) Date: Tue, 11 Nov 2014 11:16:40 +1000 Subject: JavaFX 8 - Printing 3d scene Message-ID: I posted the following question on Stack Overflow and it was suggested that I ask it here. I am trying to use the JavaFX 8 printing API and I am running into problems when I try to print any scene/node that contains any sort of 3D content. I have been searching both here and other sites for an answer and haven't been able to find anything to help. If the node contains only 2D content, the scene will print on my selected printer without issue. But if I add a single 3D object to the scene, the whole thing fails to print - without any error but without any content. If I am printing to a printer, a blank page is "printed" and if I am printing to a document printer, I get an empty document. I have tried using the AWT printing mechanism to convert the node to a WritableImage and then to a BufferedImage for printing. This works in that it prints but we aren't happy with the quality that we get from it. My print caller is fairly standard at this stage - private void doPrintFX() { Printer printer = Printer.getDefaultPrinter(); PageLayout pageLayout = printer.createPageLayout( Paper.A3, PageOrientation.LANDSCAPE, Printer.MarginType.DEFAULT); final double scaleFactor = computeScaleFactor(pageLayout.getPrintableWidth(), pageLayout.getPrintableHeight(), sceneNode.getBoundsInParent().getWidth(), sceneNode.getBoundsInParent().getHeight()); if (scaleFactor != 0) { sceneNode.getTransforms().add(new Scale(scaleFactor, scaleFactor)); } PrinterJob job = PrinterJob.createPrinterJob(printer); if (job != null) { System.out.println("Printing to " + job.getPrinter().getName()); boolean success = job.printPage(pageLayout, sceneNode); if (success) { job.endJob(); } }} I have scaled back the node to be a very simple scene containing a couple of rectangles and a cylinder. The code I am currently using is: Cylinder cylinder = new Cylinder(50, 150); cylinder.setLayoutX(250); cylinder.setLayoutY(100); canvas.getDrawingPane().getChildren().add(cylinder); Rectangle item = new Rectangle(50, 50, 100, 50); item.setStroke(Color.BLACK); item.setFill(null); canvas.getDrawingPane().getChildren().add(item); item = new Rectangle(75, 75, 100, 50); item.setStroke(Color.BLACK); item.setFill(null); canvas.getDrawingPane().getChildren().add(item); The canvas.getDrawingPane is a Pane and is what is being sent to the print function. Can anyone advise what might be wrong with what I am doing? Does the JavaFX print API support printing of 3D nodes? Thank you. From swpalmer at gmail.com Tue Nov 11 01:45:10 2014 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 10 Nov 2014 20:45:10 -0500 Subject: JavaFX 8 - Printing 3d scene In-Reply-To: References: Message-ID: I suggest you file a bug with a reproducible test case at https://javafx-jira.kenai.com/ If the 3D node will render to an image, then it should also be printable directly. Scott On Mon, Nov 10, 2014 at 8:16 PM, Cheryl Long wrote: > I posted the following question on Stack Overflow and it was suggested that > I ask it here. > > I am trying to use the JavaFX 8 printing API and I am running into problems > when I try to print any scene/node that contains any sort of 3D content. I > have been searching both here and other sites for an answer and haven't > been able to find anything to help. > > If the node contains only 2D content, the scene will print on my selected > printer without issue. But if I add a single 3D object to the scene, the > whole thing fails to print - without any error but without any content. If > I am printing to a printer, a blank page is "printed" and if I am printing > to a document printer, I get an empty document. > > I have tried using the AWT printing mechanism to convert the node to a > WritableImage and then to a BufferedImage for printing. This works in that > it prints but we aren't happy with the quality that we get from it. > > My print caller is fairly standard at this stage - > > private void doPrintFX() { > Printer printer = Printer.getDefaultPrinter(); > PageLayout pageLayout = printer.createPageLayout( > Paper.A3, PageOrientation.LANDSCAPE, > Printer.MarginType.DEFAULT); > > final double scaleFactor = > computeScaleFactor(pageLayout.getPrintableWidth(), > pageLayout.getPrintableHeight(), > sceneNode.getBoundsInParent().getWidth(), > sceneNode.getBoundsInParent().getHeight()); > if (scaleFactor != 0) { > sceneNode.getTransforms().add(new Scale(scaleFactor, scaleFactor)); > } > > PrinterJob job = PrinterJob.createPrinterJob(printer); > if (job != null) { > System.out.println("Printing to " + job.getPrinter().getName()); > boolean success = job.printPage(pageLayout, sceneNode); > if (success) { > job.endJob(); > } > }} > > I have scaled back the node to be a very simple scene containing a couple > of rectangles and a cylinder. The code I am currently using is: > > Cylinder cylinder = new Cylinder(50, 150); > cylinder.setLayoutX(250); > cylinder.setLayoutY(100); > canvas.getDrawingPane().getChildren().add(cylinder); > > Rectangle item = new Rectangle(50, 50, 100, 50); > item.setStroke(Color.BLACK); > item.setFill(null); > canvas.getDrawingPane().getChildren().add(item); > > item = new Rectangle(75, 75, 100, 50); > item.setStroke(Color.BLACK); > item.setFill(null); > canvas.getDrawingPane().getChildren().add(item); > > The canvas.getDrawingPane is a Pane and is what is being sent to the print > function. > > Can anyone advise what might be wrong with what I am doing? Does the JavaFX > print API support printing of 3D nodes? > > Thank you. > From swpalmer at gmail.com Tue Nov 11 03:51:33 2014 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 10 Nov 2014 22:51:33 -0500 Subject: Building Creative Graphics Applications in JavaFX In-Reply-To: <6BDD9DB1-8C56-406F-9244-6E0FC96EB341@gmail.com> References: <6BDD9DB1-8C56-406F-9244-6E0FC96EB341@gmail.com> Message-ID: JavaFX is up to the task. I've done an application much like you describe (visualizing a bunch of connected nodes). It's a commercial app ( http://www.digitalrapids.com/en/Products/Kayak/Page2.aspx) Though image operations on a raster for such things as a Photoshop-like app could benefit a lot from going native. (There is JAI for that, but it deals with AWT images.) Scott On Mon, Nov 10, 2014 at 3:04 PM, Jeffrey Guenther < guenther.jeffrey at gmail.com> wrote: > Hello, > > I have been using JavaFX for the last couple years to build a prototype > for my PhD research. I?ve really enjoyed myself as I?ve used it. For the > most part, I can implement a UI as fast as I can understand what it needs > to do. The scene graph is wonderful. > > JavaFX is great if you want to build a more traditional application that > uses buttons, list views, tables views, etc. What I?m still trying to > understand is how well JavaFX can help me build more complex interactive > graphics applications. The majority of my work is in data visualization and > image creation. I?ve been working some something like NodeBox or > Grasshopper for Rhino. I?ll finish the prototype with JavaFX. What I?m > pondering is if I can/should keep using JavaFX should I take the project > commercial or will it be coding myself into a corner. > > My question to you is: has any one tried to build, even as a sample > project, a small image editor or vector drawing application with JavaFX? > What worked well? What kinds of problems did you run into? > > What has been the experience of the SceneBuilder team? SceneBuilder is > probably the most advanced creative tool I?ve seen built with JavaFX so far. > > I read a post about there being a OpenGL view added to JavaFX one day. > What?s the latest on this? > > I?m very convinced by the work done by Netflix with RxJava and their other > projects that Java/JVM applications work great in the enterprise on the > server. What I?m wondering is if Java and JavaFX can compete with tools > like Apple?s Cocoa or Qt for building creative applications like say the > next generations of Photoshop and Illustrator, or some other new innovative > way of creating content. > > Thank you for your time! > > Jeff > > > From kevin.rushforth at oracle.com Tue Nov 11 15:29:06 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 11 Nov 2014 07:29:06 -0800 Subject: JavaFX 8 - Printing 3d scene In-Reply-To: References: Message-ID: <54622B42.9040104@oracle.com> 3D is not supported for printing. I don't know whether this is documented (it should be if it isn't), but it is a known limitation of the current implementation which uses Java2D to render. -- Kevin Scott Palmer wrote: > I suggest you file a bug with a reproducible test case at > https://javafx-jira.kenai.com/ > If the 3D node will render to an image, then it should also be printable > directly. > > Scott > > On Mon, Nov 10, 2014 at 8:16 PM, Cheryl Long wrote: > > >> I posted the following question on Stack Overflow and it was suggested that >> I ask it here. >> >> I am trying to use the JavaFX 8 printing API and I am running into problems >> when I try to print any scene/node that contains any sort of 3D content. I >> have been searching both here and other sites for an answer and haven't >> been able to find anything to help. >> >> If the node contains only 2D content, the scene will print on my selected >> printer without issue. But if I add a single 3D object to the scene, the >> whole thing fails to print - without any error but without any content. If >> I am printing to a printer, a blank page is "printed" and if I am printing >> to a document printer, I get an empty document. >> >> I have tried using the AWT printing mechanism to convert the node to a >> WritableImage and then to a BufferedImage for printing. This works in that >> it prints but we aren't happy with the quality that we get from it. >> >> My print caller is fairly standard at this stage - >> >> private void doPrintFX() { >> Printer printer = Printer.getDefaultPrinter(); >> PageLayout pageLayout = printer.createPageLayout( >> Paper.A3, PageOrientation.LANDSCAPE, >> Printer.MarginType.DEFAULT); >> >> final double scaleFactor = >> computeScaleFactor(pageLayout.getPrintableWidth(), >> pageLayout.getPrintableHeight(), >> sceneNode.getBoundsInParent().getWidth(), >> sceneNode.getBoundsInParent().getHeight()); >> if (scaleFactor != 0) { >> sceneNode.getTransforms().add(new Scale(scaleFactor, scaleFactor)); >> } >> >> PrinterJob job = PrinterJob.createPrinterJob(printer); >> if (job != null) { >> System.out.println("Printing to " + job.getPrinter().getName()); >> boolean success = job.printPage(pageLayout, sceneNode); >> if (success) { >> job.endJob(); >> } >> }} >> >> I have scaled back the node to be a very simple scene containing a couple >> of rectangles and a cylinder. The code I am currently using is: >> >> Cylinder cylinder = new Cylinder(50, 150); >> cylinder.setLayoutX(250); >> cylinder.setLayoutY(100); >> canvas.getDrawingPane().getChildren().add(cylinder); >> >> Rectangle item = new Rectangle(50, 50, 100, 50); >> item.setStroke(Color.BLACK); >> item.setFill(null); >> canvas.getDrawingPane().getChildren().add(item); >> >> item = new Rectangle(75, 75, 100, 50); >> item.setStroke(Color.BLACK); >> item.setFill(null); >> canvas.getDrawingPane().getChildren().add(item); >> >> The canvas.getDrawingPane is a Pane and is what is being sent to the print >> function. >> >> Can anyone advise what might be wrong with what I am doing? Does the JavaFX >> print API support printing of 3D nodes? >> >> Thank you. >> >> From philip.race at oracle.com Tue Nov 11 18:13:18 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 11 Nov 2014 10:13:18 -0800 Subject: JavaFX 8 - Printing 3d scene In-Reply-To: <54622B42.9040104@oracle.com> References: <54622B42.9040104@oracle.com> Message-ID: <546251BE.8000205@oracle.com> This is analagous to the software pipeline where 3D rendering - even to screen - is not supported. I can't see that we documented it, but we were aware that printing 3D was out-of-scope for FX 8. FWIW I think these features were overlapping in development and printing was largely done before 3D was complete. If you are running an accelerated (D3D or OpenGL) pipeline and the Node.snapshot(..) function can grab the 3d node perhaps we could implement printing the scene in terms of that. So what you get would be whatever snapshot would do for you. In the interim you could do that yourself. -phil. On 11/11/2014 7:29 AM, Kevin Rushforth wrote: > 3D is not supported for printing. I don't know whether this is > documented (it should be if it isn't), but it is a known limitation of > the current implementation which uses Java2D to render. > > -- Kevin > > > Scott Palmer wrote: >> I suggest you file a bug with a reproducible test case at >> https://javafx-jira.kenai.com/ >> If the 3D node will render to an image, then it should also be printable >> directly. >> >> Scott >> >> On Mon, Nov 10, 2014 at 8:16 PM, Cheryl Long >> wrote: >> >>> I posted the following question on Stack Overflow and it was >>> suggested that >>> I ask it here. >>> >>> I am trying to use the JavaFX 8 printing API and I am running into >>> problems >>> when I try to print any scene/node that contains any sort of 3D >>> content. I >>> have been searching both here and other sites for an answer and haven't >>> been able to find anything to help. >>> >>> If the node contains only 2D content, the scene will print on my >>> selected >>> printer without issue. But if I add a single 3D object to the scene, >>> the >>> whole thing fails to print - without any error but without any >>> content. If >>> I am printing to a printer, a blank page is "printed" and if I am >>> printing >>> to a document printer, I get an empty document. >>> >>> I have tried using the AWT printing mechanism to convert the node to a >>> WritableImage and then to a BufferedImage for printing. This works >>> in that >>> it prints but we aren't happy with the quality that we get from it. >>> >>> My print caller is fairly standard at this stage - >>> >>> private void doPrintFX() { >>> Printer printer = Printer.getDefaultPrinter(); >>> PageLayout pageLayout = printer.createPageLayout( >>> Paper.A3, PageOrientation.LANDSCAPE, >>> Printer.MarginType.DEFAULT); >>> >>> final double scaleFactor = >>> computeScaleFactor(pageLayout.getPrintableWidth(), >>> pageLayout.getPrintableHeight(), >>> sceneNode.getBoundsInParent().getWidth(), >>> sceneNode.getBoundsInParent().getHeight()); >>> if (scaleFactor != 0) { >>> sceneNode.getTransforms().add(new Scale(scaleFactor, >>> scaleFactor)); >>> } >>> >>> PrinterJob job = PrinterJob.createPrinterJob(printer); >>> if (job != null) { >>> System.out.println("Printing to " + >>> job.getPrinter().getName()); >>> boolean success = job.printPage(pageLayout, sceneNode); >>> if (success) { >>> job.endJob(); >>> } >>> }} >>> >>> I have scaled back the node to be a very simple scene containing a >>> couple >>> of rectangles and a cylinder. The code I am currently using is: >>> >>> Cylinder cylinder = new Cylinder(50, 150); >>> cylinder.setLayoutX(250); >>> cylinder.setLayoutY(100); >>> canvas.getDrawingPane().getChildren().add(cylinder); >>> >>> Rectangle item = new Rectangle(50, 50, 100, 50); >>> item.setStroke(Color.BLACK); >>> item.setFill(null); >>> canvas.getDrawingPane().getChildren().add(item); >>> >>> item = new Rectangle(75, 75, 100, 50); >>> item.setStroke(Color.BLACK); >>> item.setFill(null); >>> canvas.getDrawingPane().getChildren().add(item); >>> >>> The canvas.getDrawingPane is a Pane and is what is being sent to the >>> print >>> function. >>> >>> Can anyone advise what might be wrong with what I am doing? Does the >>> JavaFX >>> print API support printing of 3D nodes? >>> >>> Thank you. >>> From swpalmer at gmail.com Tue Nov 11 19:12:37 2014 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 11 Nov 2014 14:12:37 -0500 Subject: JavaFX 8 - Printing 3d scene In-Reply-To: <546251BE.8000205@oracle.com> References: <54622B42.9040104@oracle.com> <546251BE.8000205@oracle.com> Message-ID: I'm curious. If printing in JavaFX is implemented via Java2D then why isn't it matching what "worked" for the OP? "I have tried using the AWT printing mechanism to convert the node to a WritableImage and then to a BufferedImage for printing. This works in that it prints but we aren't happy with the quality that we get from it." Presumably with the appropriate transform in the SnapshotParameters the image resolution can be made to match the printer. If memory is a concern, it could be done in strips by manipulating the SnapshotParameters viewport. Perhaps I am missing some threading issue that makes this impossible? Scott On Tue, Nov 11, 2014 at 1:13 PM, Phil Race wrote: > This is analagous to the software pipeline where 3D rendering - even to > screen - is not supported. > > I can't see that we documented it, but we were aware that printing 3D was > out-of-scope for FX 8. > FWIW I think these features were overlapping in development and printing > was largely done > before 3D was complete. > > If you are running an accelerated (D3D or OpenGL) pipeline and the > Node.snapshot(..) function can grab > the 3d node perhaps we could implement printing the scene in terms of > that. > So what you get would be whatever snapshot would do for you. In the > interim you could do that yourself. > > -phil. > > > > On 11/11/2014 7:29 AM, Kevin Rushforth wrote: > >> 3D is not supported for printing. I don't know whether this is documented >> (it should be if it isn't), but it is a known limitation of the current >> implementation which uses Java2D to render. >> >> -- Kevin >> >> >> Scott Palmer wrote: >> >>> I suggest you file a bug with a reproducible test case at >>> https://javafx-jira.kenai.com/ >>> If the 3D node will render to an image, then it should also be printable >>> directly. >>> >>> Scott >>> >>> On Mon, Nov 10, 2014 at 8:16 PM, Cheryl Long >>> wrote: >>> >>> I posted the following question on Stack Overflow and it was suggested >>>> that >>>> I ask it here. >>>> >>>> I am trying to use the JavaFX 8 printing API and I am running into >>>> problems >>>> when I try to print any scene/node that contains any sort of 3D >>>> content. I >>>> have been searching both here and other sites for an answer and haven't >>>> been able to find anything to help. >>>> >>>> If the node contains only 2D content, the scene will print on my >>>> selected >>>> printer without issue. But if I add a single 3D object to the scene, the >>>> whole thing fails to print - without any error but without any content. >>>> If >>>> I am printing to a printer, a blank page is "printed" and if I am >>>> printing >>>> to a document printer, I get an empty document. >>>> >>>> I have tried using the AWT printing mechanism to convert the node to a >>>> WritableImage and then to a BufferedImage for printing. This works in >>>> that >>>> it prints but we aren't happy with the quality that we get from it. >>>> >>>> My print caller is fairly standard at this stage - >>>> >>>> private void doPrintFX() { >>>> Printer printer = Printer.getDefaultPrinter(); >>>> PageLayout pageLayout = printer.createPageLayout( >>>> Paper.A3, PageOrientation.LANDSCAPE, >>>> Printer.MarginType.DEFAULT); >>>> >>>> final double scaleFactor = >>>> computeScaleFactor(pageLayout.getPrintableWidth(), >>>> pageLayout.getPrintableHeight(), >>>> sceneNode.getBoundsInParent().getWidth(), >>>> sceneNode.getBoundsInParent().getHeight()); >>>> if (scaleFactor != 0) { >>>> sceneNode.getTransforms().add(new Scale(scaleFactor, >>>> scaleFactor)); >>>> } >>>> >>>> PrinterJob job = PrinterJob.createPrinterJob(printer); >>>> if (job != null) { >>>> System.out.println("Printing to " + job.getPrinter().getName()); >>>> boolean success = job.printPage(pageLayout, sceneNode); >>>> if (success) { >>>> job.endJob(); >>>> } >>>> }} >>>> >>>> I have scaled back the node to be a very simple scene containing a >>>> couple >>>> of rectangles and a cylinder. The code I am currently using is: >>>> >>>> Cylinder cylinder = new Cylinder(50, 150); >>>> cylinder.setLayoutX(250); >>>> cylinder.setLayoutY(100); >>>> canvas.getDrawingPane().getChildren().add(cylinder); >>>> >>>> Rectangle item = new Rectangle(50, 50, 100, 50); >>>> item.setStroke(Color.BLACK); >>>> item.setFill(null); >>>> canvas.getDrawingPane().getChildren().add(item); >>>> >>>> item = new Rectangle(75, 75, 100, 50); >>>> item.setStroke(Color.BLACK); >>>> item.setFill(null); >>>> canvas.getDrawingPane().getChildren().add(item); >>>> >>>> The canvas.getDrawingPane is a Pane and is what is being sent to the >>>> print >>>> function. >>>> >>>> Can anyone advise what might be wrong with what I am doing? Does the >>>> JavaFX >>>> print API support printing of 3D nodes? >>>> >>>> Thank you. >>>> >>>> > From philip.race at oracle.com Tue Nov 11 20:07:05 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 11 Nov 2014 12:07:05 -0800 Subject: JavaFX 8 - Printing 3d scene In-Reply-To: References: <54622B42.9040104@oracle.com> <546251BE.8000205@oracle.com> Message-ID: <54626C69.1090207@oracle.com> 2D printing will print images at hi-res, and FX printing will too .. I remember testing with some ultra hi-res images I found somewhere. To get a hi-res image printed out you would need to be able to capture all of the device pixels - if they aren't there to start with there's nothing printing can do. If you do that I believe it 'just works'. I used an image at full resolution and placed it into an ImageView which had the size I wanted. If it was scaled down to 144x144 screen /user pixels, it'll get scaled down to 2"x2" on the printer. If the image was really 1,440x1,440 all those pixels will be sent to the printer and the results should look good. The snippet below probably isn't working with a hi-res image, instead just scaling the up the image to fit the page. It may be scaling by < 2 for all I can tell. The PrintResolution attribute needs to be involved somewhere if you want to know how much to scale the backbuffer from which you get the pixels but 300dpi should look ok except to a discerning user. I am however not sure how "the AWT printing mechanism" can be coerced into converting a node to a WriteableImage. I just don't follow that sentence. -phil. On 11/11/2014 11:12 AM, Scott Palmer wrote: > I'm curious. If printing in JavaFX is implemented via Java2D then why > isn't it matching what "worked" for the OP? > > "I have tried using the AWT printing mechanism to convert the node > to a > WritableImage and then to a BufferedImage for printing. This works in that > it prints but we aren't happy with the quality that we get from it." > > Presumably with the appropriate transform in the SnapshotParameters > the image resolution can be made to match the printer. If memory is a > concern, it could be done in strips by manipulating the > SnapshotParameters viewport. > Perhaps I am missing some threading issue that makes this impossible? > > > Scott > > On Tue, Nov 11, 2014 at 1:13 PM, Phil Race > wrote: > > This is analagous to the software pipeline where 3D rendering - > even to screen - is not supported. > > I can't see that we documented it, but we were aware that printing > 3D was out-of-scope for FX 8. > FWIW I think these features were overlapping in development and > printing was largely done > before 3D was complete. > > If you are running an accelerated (D3D or OpenGL) pipeline and the > Node.snapshot(..) function can grab > the 3d node perhaps we could implement printing the scene in > terms of that. > So what you get would be whatever snapshot would do for you. In > the interim you could do that yourself. > > -phil. > > > > On 11/11/2014 7:29 AM, Kevin Rushforth wrote: > > 3D is not supported for printing. I don't know whether this is > documented (it should be if it isn't), but it is a known > limitation of the current implementation which uses Java2D to > render. > > -- Kevin > > > Scott Palmer wrote: > > I suggest you file a bug with a reproducible test case at > https://javafx-jira.kenai.com/ > If the 3D node will render to an image, then it should > also be printable > directly. > > Scott > > On Mon, Nov 10, 2014 at 8:16 PM, Cheryl Long > > wrote: > > I posted the following question on Stack Overflow and > it was suggested that > I ask it here. > > I am trying to use the JavaFX 8 printing API and I am > running into problems > when I try to print any scene/node that contains any > sort of 3D content. I > have been searching both here and other sites for an > answer and haven't > been able to find anything to help. > > If the node contains only 2D content, the scene will > print on my selected > printer without issue. But if I add a single 3D object > to the scene, the > whole thing fails to print - without any error but > without any content. If > I am printing to a printer, a blank page is "printed" > and if I am printing > to a document printer, I get an empty document. > > I have tried using the AWT printing mechanism to > convert the node to a > WritableImage and then to a BufferedImage for > printing. This works in that > it prints but we aren't happy with the quality that we > get from it. > > My print caller is fairly standard at this stage - > > private void doPrintFX() { > Printer printer = Printer.getDefaultPrinter(); > PageLayout pageLayout = printer.createPageLayout( > Paper.A3, PageOrientation.LANDSCAPE, > Printer.MarginType.DEFAULT); > > final double scaleFactor = > computeScaleFactor(pageLayout.getPrintableWidth(), > pageLayout.getPrintableHeight(), > sceneNode.getBoundsInParent().getWidth(), > sceneNode.getBoundsInParent().getHeight()); > if (scaleFactor != 0) { > sceneNode.getTransforms().add(new > Scale(scaleFactor, scaleFactor)); > } > > PrinterJob job = PrinterJob.createPrinterJob(printer); > if (job != null) { > System.out.println("Printing to " + > job.getPrinter().getName()); > boolean success = job.printPage(pageLayout, > sceneNode); > if (success) { > job.endJob(); > } > }} > > I have scaled back the node to be a very simple scene > containing a couple > of rectangles and a cylinder. The code I am currently > using is: > > Cylinder cylinder = new Cylinder(50, 150); > cylinder.setLayoutX(250); > cylinder.setLayoutY(100); > canvas.getDrawingPane().getChildren().add(cylinder); > > Rectangle item = new Rectangle(50, 50, 100, 50); > item.setStroke(Color.BLACK); > item.setFill(null); > canvas.getDrawingPane().getChildren().add(item); > > item = new Rectangle(75, 75, 100, 50); > item.setStroke(Color.BLACK); > item.setFill(null); > canvas.getDrawingPane().getChildren().add(item); > > The canvas.getDrawingPane is a Pane and is what is > being sent to the print > function. > > Can anyone advise what might be wrong with what I am > doing? Does the JavaFX > print API support printing of 3D nodes? > > Thank you. > > > From chien.yang at oracle.com Wed Nov 12 02:02:51 2014 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 11 Nov 2014 18:02:51 -0800 Subject: [8u40] Post commit notification: RT-39364: Code cleanup: Better naming for scene antialiasing in toolkit and prism Message-ID: <5462BFCB.1060300@oracle.com> This is a prep work for RT-38063 and it is reviewed by kcr. - Chien From james.graham at oracle.com Wed Nov 12 02:14:12 2014 From: james.graham at oracle.com (Jim Graham) Date: Tue, 11 Nov 2014 18:14:12 -0800 Subject: 8u40 review request: RT-39275 bad bounds leading to repaint issues in Ensemble8/TextFlow Message-ID: <5462C274.10604@oracle.com> webrev: http://cr.openjdk.java.net/~flar/RT-39275/webrev.00/ Jira: https://javafx-jira.kenai.com/browse/RT-39275 Long explanations about the rework of the original fix for RT-36130 are in the Jira comments... ...jim From swpalmer at gmail.com Wed Nov 12 05:01:08 2014 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 12 Nov 2014 00:01:08 -0500 Subject: JavaFX 8 - Printing 3d scene In-Reply-To: <54626C69.1090207@oracle.com> References: <54622B42.9040104@oracle.com> <546251BE.8000205@oracle.com> <54626C69.1090207@oracle.com> Message-ID: "I am however not sure how "the AWT printing mechanism" can be coerced into converting a node to a WriteableImage. I just don't follow that sentence." The JavaFX printing API takes a Node as input. Node.snapshot produces an image and can do so with a transform applied via the SnapshotParameters to produce a high-resolution output image (matching the printer DPI). That JavaFX image can be converted to a Java2D image with javafx.embed.swing.SwingFXUtils, that Java2D image can be printed directly to the Graphics context of Java2D printing APIs. When I saw that JavaFX printing was implemented via Java2D printing, I actually just assumed that was how it worked, but since printing 3D directly doesn't work, but taking a snapshot of 3D node does work, obviously it's different under the hood. I'm not sure why it has to be, but my guess would be that there are threading issues that come up between the AWT/Swing thread and the FX thread. Probably something that can be worked around in an application, but was too scary to hide behind the scenes in the FX printing API as it could lead to deadlocks. I'm just speculating though. Scott On Tue, Nov 11, 2014 at 3:07 PM, Phil Race wrote: > 2D printing will print images at hi-res, and FX printing will too .. I > remember testing > with some ultra hi-res images I found somewhere. > > To get a hi-res image printed out you would need to be able to capture all > of the > device pixels - if they aren't there to start with there's nothing > printing can do. > If you do that I believe it 'just works'. I used an image at full > resolution and > placed it into an ImageView which had the size I wanted. > > If it was scaled down to 144x144 screen /user pixels, it'll get scaled > down to 2"x2" on the printer. > If the image was really 1,440x1,440 all those pixels will be sent to the > printer and the results > should look good. > > The snippet below probably isn't working with a hi-res image, instead just > scaling the > up the image to fit the page. It may be scaling by < 2 for all I can tell. > The PrintResolution attribute needs to be involved somewhere if you want > to know > how much to scale the backbuffer from which you get the pixels but 300dpi > should > look ok except to a discerning user. > > I am however not sure how "the AWT printing mechanism" can be coerced into > converting a node to a WriteableImage. I just don't follow that sentence. > > -phil. > > On 11/11/2014 11:12 AM, Scott Palmer wrote: > >> I'm curious. If printing in JavaFX is implemented via Java2D then why >> isn't it matching what "worked" for the OP? >> >> "I have tried using the AWT printing mechanism to convert the node to >> a >> WritableImage and then to a BufferedImage for printing. This works in that >> it prints but we aren't happy with the quality that we get from it." >> >> Presumably with the appropriate transform in the SnapshotParameters the >> image resolution can be made to match the printer. If memory is a concern, >> it could be done in strips by manipulating the SnapshotParameters viewport. >> Perhaps I am missing some threading issue that makes this impossible? >> >> >> Scott >> >> On Tue, Nov 11, 2014 at 1:13 PM, Phil Race > > wrote: >> >> This is analagous to the software pipeline where 3D rendering - >> even to screen - is not supported. >> >> I can't see that we documented it, but we were aware that printing >> 3D was out-of-scope for FX 8. >> FWIW I think these features were overlapping in development and >> printing was largely done >> before 3D was complete. >> >> If you are running an accelerated (D3D or OpenGL) pipeline and the >> Node.snapshot(..) function can grab >> the 3d node perhaps we could implement printing the scene in >> terms of that. >> So what you get would be whatever snapshot would do for you. In >> the interim you could do that yourself. >> >> -phil. >> >> >> >> On 11/11/2014 7:29 AM, Kevin Rushforth wrote: >> >> 3D is not supported for printing. I don't know whether this is >> documented (it should be if it isn't), but it is a known >> limitation of the current implementation which uses Java2D to >> render. >> >> -- Kevin >> >> >> Scott Palmer wrote: >> >> I suggest you file a bug with a reproducible test case at >> https://javafx-jira.kenai.com/ >> If the 3D node will render to an image, then it should >> also be printable >> directly. >> >> Scott >> >> On Mon, Nov 10, 2014 at 8:16 PM, Cheryl Long >> > wrote: >> >> I posted the following question on Stack Overflow and >> it was suggested that >> I ask it here. >> >> I am trying to use the JavaFX 8 printing API and I am >> running into problems >> when I try to print any scene/node that contains any >> sort of 3D content. I >> have been searching both here and other sites for an >> answer and haven't >> been able to find anything to help. >> >> If the node contains only 2D content, the scene will >> print on my selected >> printer without issue. But if I add a single 3D object >> to the scene, the >> whole thing fails to print - without any error but >> without any content. If >> I am printing to a printer, a blank page is "printed" >> and if I am printing >> to a document printer, I get an empty document. >> >> I have tried using the AWT printing mechanism to >> convert the node to a >> WritableImage and then to a BufferedImage for >> printing. This works in that >> it prints but we aren't happy with the quality that we >> get from it. >> >> My print caller is fairly standard at this stage - >> >> private void doPrintFX() { >> Printer printer = Printer.getDefaultPrinter(); >> PageLayout pageLayout = printer.createPageLayout( >> Paper.A3, PageOrientation.LANDSCAPE, >> Printer.MarginType.DEFAULT); >> >> final double scaleFactor = >> computeScaleFactor(pageLayout.getPrintableWidth(), >> pageLayout.getPrintableHeight(), >> sceneNode.getBoundsInParent().getWidth(), >> sceneNode.getBoundsInParent().getHeight()); >> if (scaleFactor != 0) { >> sceneNode.getTransforms().add(new >> Scale(scaleFactor, scaleFactor)); >> } >> >> PrinterJob job = PrinterJob.createPrinterJob( >> printer); >> if (job != null) { >> System.out.println("Printing to " + >> job.getPrinter().getName()); >> boolean success = job.printPage(pageLayout, >> sceneNode); >> if (success) { >> job.endJob(); >> } >> }} >> >> I have scaled back the node to be a very simple scene >> containing a couple >> of rectangles and a cylinder. The code I am currently >> using is: >> >> Cylinder cylinder = new Cylinder(50, 150); >> cylinder.setLayoutX(250); >> cylinder.setLayoutY(100); >> canvas.getDrawingPane().getChildren().add(cylinder); >> >> Rectangle item = new Rectangle(50, 50, 100, 50); >> item.setStroke(Color.BLACK); >> item.setFill(null); >> canvas.getDrawingPane().getChildren().add(item); >> >> item = new Rectangle(75, 75, 100, 50); >> item.setStroke(Color.BLACK); >> item.setFill(null); >> canvas.getDrawingPane().getChildren().add(item); >> >> The canvas.getDrawingPane is a Pane and is what is >> being sent to the print >> function. >> >> Can anyone advise what might be wrong with what I am >> doing? Does the JavaFX >> print API support printing of 3D nodes? >> >> Thank you. >> >> >> >> > From hastebrot at gmail.com Wed Nov 12 07:30:45 2014 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Wed, 12 Nov 2014 08:30:45 +0100 Subject: Monocle in 8u25 In-Reply-To: <545A788D.9030509@tbee.org> References: <5459102D.9010004@oracle.com> <54591A31.1070709@oracle.com> <545A788D.9030509@tbee.org> Message-ID: Hi all! Files and instructions are available at https://github.com/TestFX/Monocle. Releases with jars: https://github.com/TestFX/Monocle/releases License (taken from OpenJFX respository): https://github.com/TestFX/Monocle/blob/master/LICENSE Would be nice to have this available from Maven. --Benjamin On Wed, Nov 5, 2014 at 8:20 PM, Tom Eugelink wrote: > This is extremely good news. I have no problem to "drag" that library > along in the JFXtras project (project name seems to be a good match for > this usage ;-) and release it to maven - if that is allowed by the JavaFX > license. > > Tom > > > > On 5-11-2014 16:57, Benjamin Gudehus wrote: > >> Hi Sean, >> >> I've put the Monocle sources directly in my code directories for >> testing purposes. Putting it into a separate Jar is possible and I >> thought that pre-compiled jars could be provided via Maven. >> >> I didn't do a complete OpenJFX build, because I was only interested in >> the Headless component of Monocle, i.e. I didn't needed the >> platform-dependent dynamic libraries. >> >> Rough instructions were given in a previous mail. There were some >> request to provide the pre-compoile jars so I will additionally set up >> a public repository with detailed instructions when I'm back home. >> >> --Benjamin >> >> On 11/5/14, Sean True wrote: >> >>> Did you build the glass/ui/monocle sources into a separate jar, or did >>> you >>> do a complete OpenJFX build? >>> >>> If you did a separate build, a recipe would be extremely helpful. >>> >>> -- Sean >>> >>> On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus >>> wrote: >>> >>> I managed to run Monocle/Headless on Windows with 8u25. This will allow >>>> users to run headless tests. >>>> >>>> All what is needed is to copy all files from "com/sun/glass/ui/monocle" >>>> of >>>> "javafx-src.zip" and add the >>>> cursor resource files from >>>> "modules/graphics/src/main/resources/com/sun/glass/ui/monocle" of the >>>> related hg tag in the OpenJFX repository [1]. >>>> >>>> Before Application#launch() is called we need to manually set the Glass >>>> and >>>> Monocle platforms: >>>> >>>> accessStaticField(com.sun.glass.ui.PlatformFactory.class, "instance", >>>> new com.sun.glass.ui.monocle.MonoclePlatformFactory()); >>>> accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class, >>>> "platform", >>>> new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); >>>> >>>> The directory structure in 8u40 is a bit different, but there could be >>>> added version checks. Checking >>>> for the JVM vars "glass.platform" and "monocle.platform" might be also >>>> added to this code. >>>> >>>> [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags >>>> >>>> >>>> On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus >>>> wrote: >>>> >>>> Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory >>>>> won't >>>>> retrieve externally defined PlatformFactorys. So I will try to set the >>>>> PlatformFactory.instance field manually, before the >>>>> Application/Tookit/FX-Thread is launched. >>>>> >>>>> On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus >>>>> wrote: >>>>> >>>>> Thank you. That makes it clearer. :) >>>>>> >>>>>> Is it possible to supply the headless part of Monocle in an external >>>>>> Jar >>>>>> for desktop platforms? >>>>>> >>>>>> As far as I know the only possibility to run TestFX tests with >>>>>> Hudson/Jenkins is in headless mode. >>>>>> TestFX's tests itself can only run with the X virtual framebuffer on >>>>>> Linux test clients for the Travis CI so far. >>>>>> >>>>>> So far the only advice I could give TestFX users who like to run >>>>>> >>>>> headless >>>> >>>>> tests is to use 1.8.0_20-ea-b05. >>>>>> >>>>>> > From tbee at tbee.org Wed Nov 12 07:48:49 2014 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 12 Nov 2014 08:48:49 +0100 Subject: Monocle in 8u25 In-Reply-To: References: <5459102D.9010004@oracle.com> <54591A31.1070709@oracle.com> <545A788D.9030509@tbee.org> Message-ID: <546310E1.8000702@tbee.org> I can roll it out under the same name (openjfx-monocle-1.8.0_20) within the org.jfxtras group. Just say so. Tom On 12-11-2014 08:30, Benjamin Gudehus wrote: > Hi all! > > Files and instructions are available at https://github.com/TestFX/Monocle. > > Releases with jars: https://github.com/TestFX/Monocle/releases > > License (taken from OpenJFX respository): https://github.com/TestFX/Monocle/blob/master/LICENSE > > Would be nice to have this available from Maven. > > --Benjamin > > On Wed, Nov 5, 2014 at 8:20 PM, Tom Eugelink > wrote: > > This is extremely good news. I have no problem to "drag" that library along in the JFXtras project (project name seems to be a good match for this usage ;-) and release it to maven - if that is allowed by the JavaFX license. > > Tom > > > > On 5-11-2014 16:57, Benjamin Gudehus wrote: > > Hi Sean, > > I've put the Monocle sources directly in my code directories for > testing purposes. Putting it into a separate Jar is possible and I > thought that pre-compiled jars could be provided via Maven. > > I didn't do a complete OpenJFX build, because I was only interested in > the Headless component of Monocle, i.e. I didn't needed the > platform-dependent dynamic libraries. > > Rough instructions were given in a previous mail. There were some > request to provide the pre-compoile jars so I will additionally set up > a public repository with detailed instructions when I'm back home. > > --Benjamin > > On 11/5/14, Sean True > wrote: > > Did you build the glass/ui/monocle sources into a separate jar, or did you > do a complete OpenJFX build? > > If you did a separate build, a recipe would be extremely helpful. > > -- Sean > > On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus > > wrote: > > I managed to run Monocle/Headless on Windows with 8u25. This will allow > users to run headless tests. > > All what is needed is to copy all files from "com/sun/glass/ui/monocle" > of > "javafx-src.zip" and add the > cursor resource files from > "modules/graphics/src/main/resources/com/sun/glass/ui/monocle" of the > related hg tag in the OpenJFX repository [1]. > > Before Application#launch() is called we need to manually set the Glass > and > Monocle platforms: > > accessStaticField(com.sun.glass.ui.PlatformFactory.class, "instance", > new com.sun.glass.ui.monocle.MonoclePlatformFactory()); > accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class, > "platform", > new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); > > The directory structure in 8u40 is a bit different, but there could be > added version checks. Checking > for the JVM vars "glass.platform" and "monocle.platform" might be also > added to this code. > > [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags > > > On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus > > wrote: > > Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory > won't > retrieve externally defined PlatformFactorys. So I will try to set the > PlatformFactory.instance field manually, before the > Application/Tookit/FX-Thread is launched. > > On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus > > wrote: > > Thank you. That makes it clearer. :) > > Is it possible to supply the headless part of Monocle in an external > Jar > for desktop platforms? > > As far as I know the only possibility to run TestFX tests with > Hudson/Jenkins is in headless mode. > TestFX's tests itself can only run with the X virtual framebuffer on > Linux test clients for the Travis CI so far. > > So far the only advice I could give TestFX users who like to run > > headless > > tests is to use 1.8.0_20-ea-b05. > > > From hastebrot at gmail.com Wed Nov 12 08:09:20 2014 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Wed, 12 Nov 2014 09:09:20 +0100 Subject: Monocle in 8u25 In-Reply-To: <546310E1.8000702@tbee.org> References: <5459102D.9010004@oracle.com> <54591A31.1070709@oracle.com> <545A788D.9030509@tbee.org> <546310E1.8000702@tbee.org> Message-ID: That would be nice, Tom. Example usage: Since com.sun.glass.ui.PlatformFactory can't find Monocle classes from the external jars, we need to change public static void main(String[] appArgs) { Application.launch(appClass, appArgs); } to public static void main(String[] appArgs) { new ToolkitApplicationLauncher().launch(appClass, appArgs); } and start the Application with -Djavafx.monocle.headless=true. ToolkitApplicationLauncher.jar: https://gist.github.com/hastebrot/cbca1128dd791966e3a6 On Wed, Nov 12, 2014 at 8:48 AM, Tom Eugelink wrote: > I can roll it out under the same name (openjfx-monocle-1.8.0_20) within > the org.jfxtras group. Just say so. > > Tom > > > > > > On 12-11-2014 08:30, Benjamin Gudehus wrote: > > Hi all! > > Files and instructions are available at https://github.com/TestFX/Monocle > . > > Releases with jars: https://github.com/TestFX/Monocle/releases > > License (taken from OpenJFX respository): > https://github.com/TestFX/Monocle/blob/master/LICENSE > > Would be nice to have this available from Maven. > > --Benjamin > > On Wed, Nov 5, 2014 at 8:20 PM, Tom Eugelink wrote: > >> This is extremely good news. I have no problem to "drag" that library >> along in the JFXtras project (project name seems to be a good match for >> this usage ;-) and release it to maven - if that is allowed by the JavaFX >> license. >> >> Tom >> >> >> >> On 5-11-2014 16:57, Benjamin Gudehus wrote: >> >>> Hi Sean, >>> >>> I've put the Monocle sources directly in my code directories for >>> testing purposes. Putting it into a separate Jar is possible and I >>> thought that pre-compiled jars could be provided via Maven. >>> >>> I didn't do a complete OpenJFX build, because I was only interested in >>> the Headless component of Monocle, i.e. I didn't needed the >>> platform-dependent dynamic libraries. >>> >>> Rough instructions were given in a previous mail. There were some >>> request to provide the pre-compoile jars so I will additionally set up >>> a public repository with detailed instructions when I'm back home. >>> >>> --Benjamin >>> >>> On 11/5/14, Sean True wrote: >>> >>>> Did you build the glass/ui/monocle sources into a separate jar, or did >>>> you >>>> do a complete OpenJFX build? >>>> >>>> If you did a separate build, a recipe would be extremely helpful. >>>> >>>> -- Sean >>>> >>>> On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus >>>> wrote: >>>> >>>> I managed to run Monocle/Headless on Windows with 8u25. This will allow >>>>> users to run headless tests. >>>>> >>>>> All what is needed is to copy all files from "com/sun/glass/ui/monocle" >>>>> of >>>>> "javafx-src.zip" and add the >>>>> cursor resource files from >>>>> "modules/graphics/src/main/resources/com/sun/glass/ui/monocle" of the >>>>> related hg tag in the OpenJFX repository [1]. >>>>> >>>>> Before Application#launch() is called we need to manually set the Glass >>>>> and >>>>> Monocle platforms: >>>>> >>>>> accessStaticField(com.sun.glass.ui.PlatformFactory.class, "instance", >>>>> new com.sun.glass.ui.monocle.MonoclePlatformFactory()); >>>>> accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class, >>>>> "platform", >>>>> new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); >>>>> >>>>> The directory structure in 8u40 is a bit different, but there could be >>>>> added version checks. Checking >>>>> for the JVM vars "glass.platform" and "monocle.platform" might be also >>>>> added to this code. >>>>> >>>>> [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags >>>>> >>>>> >>>>> On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus >>>>> wrote: >>>>> >>>>> Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory >>>>>> won't >>>>>> retrieve externally defined PlatformFactorys. So I will try to set the >>>>>> PlatformFactory.instance field manually, before the >>>>>> Application/Tookit/FX-Thread is launched. >>>>>> >>>>>> On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus >>>>> > >>>>>> wrote: >>>>>> >>>>>> Thank you. That makes it clearer. :) >>>>>>> >>>>>>> Is it possible to supply the headless part of Monocle in an external >>>>>>> Jar >>>>>>> for desktop platforms? >>>>>>> >>>>>>> As far as I know the only possibility to run TestFX tests with >>>>>>> Hudson/Jenkins is in headless mode. >>>>>>> TestFX's tests itself can only run with the X virtual framebuffer on >>>>>>> Linux test clients for the Travis CI so far. >>>>>>> >>>>>>> So far the only advice I could give TestFX users who like to run >>>>>>> >>>>>> headless >>>>> >>>>>> tests is to use 1.8.0_20-ea-b05. >>>>>>> >>>>>>> >> > > From guenther.jeffrey at gmail.com Wed Nov 12 17:17:49 2014 From: guenther.jeffrey at gmail.com (Jeffrey Guenther) Date: Wed, 12 Nov 2014 09:17:49 -0800 Subject: Building Creative Graphics Applications in JavaFX In-Reply-To: References: <6BDD9DB1-8C56-406F-9244-6E0FC96EB341@gmail.com> Message-ID: Hi Scott, Thank you for the heads up. The application looks great! Is dataflow UI custom or are you using an open source library? Is the video encoding stuff written in Java too? Jeff > On Nov 10, 2014, at 7:51 PM, Scott Palmer wrote: > > JavaFX is up to the task. I've done an application much like you describe (visualizing a bunch of connected nodes). It's a commercial app (http://www.digitalrapids.com/en/Products/Kayak/Page2.aspx ) > > Though image operations on a raster for such things as a Photoshop-like app could benefit a lot from going native. (There is JAI for that, but it deals with AWT images.) > > Scott > > On Mon, Nov 10, 2014 at 3:04 PM, Jeffrey Guenther > wrote: > Hello, > > I have been using JavaFX for the last couple years to build a prototype for my PhD research. I?ve really enjoyed myself as I?ve used it. For the most part, I can implement a UI as fast as I can understand what it needs to do. The scene graph is wonderful. > > JavaFX is great if you want to build a more traditional application that uses buttons, list views, tables views, etc. What I?m still trying to understand is how well JavaFX can help me build more complex interactive graphics applications. The majority of my work is in data visualization and image creation. I?ve been working some something like NodeBox or Grasshopper for Rhino. I?ll finish the prototype with JavaFX. What I?m pondering is if I can/should keep using JavaFX should I take the project commercial or will it be coding myself into a corner. > > My question to you is: has any one tried to build, even as a sample project, a small image editor or vector drawing application with JavaFX? > What worked well? What kinds of problems did you run into? > > What has been the experience of the SceneBuilder team? SceneBuilder is probably the most advanced creative tool I?ve seen built with JavaFX so far. > > I read a post about there being a OpenGL view added to JavaFX one day. What?s the latest on this? > > I?m very convinced by the work done by Netflix with RxJava and their other projects that Java/JVM applications work great in the enterprise on the server. What I?m wondering is if Java and JavaFX can compete with tools like Apple?s Cocoa or Qt for building creative applications like say the next generations of Photoshop and Illustrator, or some other new innovative way of creating content. > > Thank you for your time! > > Jeff > > > From tbee at tbee.org Wed Nov 12 17:50:07 2014 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 12 Nov 2014 18:50:07 +0100 Subject: Monocle in 8u25 In-Reply-To: References: <5459102D.9010004@oracle.com> <54591A31.1070709@oracle.com> <545A788D.9030509@tbee.org> <546310E1.8000702@tbee.org> Message-ID: <54639DCF.9020707@tbee.org> I've build the jars from the sources in github (this makes creating new releases easier) and the artifacts are on their way to Maven Central... If everything seems to be ok, I'll create a pull request with some changes to gradle.build for the releasing process. Tom On 12-11-2014 09:09, Benjamin Gudehus wrote: > That would be nice, Tom. > > Example usage: > > Since com.sun.glass.ui.PlatformFactory can't find Monocle classes from the external jars, we need to change > > public static void main(String[] appArgs) { > Application.launch(appClass, appArgs); > } > > to > > public static void main(String[] appArgs) { > new ToolkitApplicationLauncher().launch(appClass, appArgs); > } > > and start the Application with -Djavafx.monocle.headless=true. > > ToolkitApplicationLauncher.jar: https://gist.github.com/hastebrot/cbca1128dd791966e3a6 > > > On Wed, Nov 12, 2014 at 8:48 AM, Tom Eugelink > wrote: > > I can roll it out under the same name (openjfx-monocle-1.8.0_20) within the org.jfxtras group. Just say so. > > Tom > > > > > > On 12-11-2014 08:30, Benjamin Gudehus wrote: >> Hi all! >> >> Files and instructions are available at https://github.com/TestFX/Monocle. >> >> Releases with jars: https://github.com/TestFX/Monocle/releases >> >> License (taken from OpenJFX respository): https://github.com/TestFX/Monocle/blob/master/LICENSE >> >> Would be nice to have this available from Maven. >> >> --Benjamin >> >> On Wed, Nov 5, 2014 at 8:20 PM, Tom Eugelink > wrote: >> >> This is extremely good news. I have no problem to "drag" that library along in the JFXtras project (project name seems to be a good match for this usage ;-) and release it to maven - if that is allowed by the JavaFX license. >> >> Tom >> >> >> >> On 5-11-2014 16:57, Benjamin Gudehus wrote: >> >> Hi Sean, >> >> I've put the Monocle sources directly in my code directories for >> testing purposes. Putting it into a separate Jar is possible and I >> thought that pre-compiled jars could be provided via Maven. >> >> I didn't do a complete OpenJFX build, because I was only interested in >> the Headless component of Monocle, i.e. I didn't needed the >> platform-dependent dynamic libraries. >> >> Rough instructions were given in a previous mail. There were some >> request to provide the pre-compoile jars so I will additionally set up >> a public repository with detailed instructions when I'm back home. >> >> --Benjamin >> >> On 11/5/14, Sean True > wrote: >> >> Did you build the glass/ui/monocle sources into a separate jar, or did you >> do a complete OpenJFX build? >> >> If you did a separate build, a recipe would be extremely helpful. >> >> -- Sean >> >> On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus > >> wrote: >> >> I managed to run Monocle/Headless on Windows with 8u25. This will allow >> users to run headless tests. >> >> All what is needed is to copy all files from "com/sun/glass/ui/monocle" >> of >> "javafx-src.zip" and add the >> cursor resource files from >> "modules/graphics/src/main/resources/com/sun/glass/ui/monocle" of the >> related hg tag in the OpenJFX repository [1]. >> >> Before Application#launch() is called we need to manually set the Glass >> and >> Monocle platforms: >> >> accessStaticField(com.sun.glass.ui.PlatformFactory.class, "instance", >> new com.sun.glass.ui.monocle.MonoclePlatformFactory()); >> accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class, >> "platform", >> new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); >> >> The directory structure in 8u40 is a bit different, but there could be >> added version checks. Checking >> for the JVM vars "glass.platform" and "monocle.platform" might be also >> added to this code. >> >> [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags >> >> >> On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus > >> wrote: >> >> Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory >> won't >> retrieve externally defined PlatformFactorys. So I will try to set the >> PlatformFactory.instance field manually, before the >> Application/Tookit/FX-Thread is launched. >> >> On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus > >> wrote: >> >> Thank you. That makes it clearer. :) >> >> Is it possible to supply the headless part of Monocle in an external >> Jar >> for desktop platforms? >> >> As far as I know the only possibility to run TestFX tests with >> Hudson/Jenkins is in headless mode. >> TestFX's tests itself can only run with the X virtual framebuffer on >> Linux test clients for the Travis CI so far. >> >> So far the only advice I could give TestFX users who like to run >> >> headless >> >> tests is to use 1.8.0_20-ea-b05. >> >> >> > > From tbee at tbee.org Wed Nov 12 21:17:26 2014 From: tbee at tbee.org (Tom Eugelink) Date: Wed, 12 Nov 2014 22:17:26 +0100 Subject: Monocle in 8u25 In-Reply-To: References: <5459102D.9010004@oracle.com> <54591A31.1070709@oracle.com> <545A788D.9030509@tbee.org> <546310E1.8000702@tbee.org> Message-ID: <5463CE66.6090806@tbee.org> org.jftras:openjfx-monicle:1.8.0_20 is available in Maven central. Tom On 12-11-2014 09:09, Benjamin Gudehus wrote: > That would be nice, Tom. > > Example usage: > > Since com.sun.glass.ui.PlatformFactory can't find Monocle classes from the external jars, we need to change > > public static void main(String[] appArgs) { > Application.launch(appClass, appArgs); > } > > to > > public static void main(String[] appArgs) { > new ToolkitApplicationLauncher().launch(appClass, appArgs); > } > > and start the Application with -Djavafx.monocle.headless=true. > > ToolkitApplicationLauncher.jar: https://gist.github.com/hastebrot/cbca1128dd791966e3a6 > > > On Wed, Nov 12, 2014 at 8:48 AM, Tom Eugelink > wrote: > > I can roll it out under the same name (openjfx-monocle-1.8.0_20) within the org.jfxtras group. Just say so. > > Tom > > > > > > On 12-11-2014 08:30, Benjamin Gudehus wrote: >> Hi all! >> >> Files and instructions are available at https://github.com/TestFX/Monocle. >> >> Releases with jars: https://github.com/TestFX/Monocle/releases >> >> License (taken from OpenJFX respository): https://github.com/TestFX/Monocle/blob/master/LICENSE >> >> Would be nice to have this available from Maven. >> >> --Benjamin >> >> On Wed, Nov 5, 2014 at 8:20 PM, Tom Eugelink > wrote: >> >> This is extremely good news. I have no problem to "drag" that library along in the JFXtras project (project name seems to be a good match for this usage ;-) and release it to maven - if that is allowed by the JavaFX license. >> >> Tom >> >> >> >> On 5-11-2014 16:57, Benjamin Gudehus wrote: >> >> Hi Sean, >> >> I've put the Monocle sources directly in my code directories for >> testing purposes. Putting it into a separate Jar is possible and I >> thought that pre-compiled jars could be provided via Maven. >> >> I didn't do a complete OpenJFX build, because I was only interested in >> the Headless component of Monocle, i.e. I didn't needed the >> platform-dependent dynamic libraries. >> >> Rough instructions were given in a previous mail. There were some >> request to provide the pre-compoile jars so I will additionally set up >> a public repository with detailed instructions when I'm back home. >> >> --Benjamin >> >> On 11/5/14, Sean True > wrote: >> >> Did you build the glass/ui/monocle sources into a separate jar, or did you >> do a complete OpenJFX build? >> >> If you did a separate build, a recipe would be extremely helpful. >> >> -- Sean >> >> On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus > >> wrote: >> >> I managed to run Monocle/Headless on Windows with 8u25. This will allow >> users to run headless tests. >> >> All what is needed is to copy all files from "com/sun/glass/ui/monocle" >> of >> "javafx-src.zip" and add the >> cursor resource files from >> "modules/graphics/src/main/resources/com/sun/glass/ui/monocle" of the >> related hg tag in the OpenJFX repository [1]. >> >> Before Application#launch() is called we need to manually set the Glass >> and >> Monocle platforms: >> >> accessStaticField(com.sun.glass.ui.PlatformFactory.class, "instance", >> new com.sun.glass.ui.monocle.MonoclePlatformFactory()); >> accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class, >> "platform", >> new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); >> >> The directory structure in 8u40 is a bit different, but there could be >> added version checks. Checking >> for the JVM vars "glass.platform" and "monocle.platform" might be also >> added to this code. >> >> [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags >> >> >> On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus > >> wrote: >> >> Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory >> won't >> retrieve externally defined PlatformFactorys. So I will try to set the >> PlatformFactory.instance field manually, before the >> Application/Tookit/FX-Thread is launched. >> >> On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus > >> wrote: >> >> Thank you. That makes it clearer. :) >> >> Is it possible to supply the headless part of Monocle in an external >> Jar >> for desktop platforms? >> >> As far as I know the only possibility to run TestFX tests with >> Hudson/Jenkins is in headless mode. >> TestFX's tests itself can only run with the X virtual framebuffer on >> Linux test clients for the Travis CI so far. >> >> So far the only advice I could give TestFX users who like to run >> >> headless >> >> tests is to use 1.8.0_20-ea-b05. >> >> >> > > From swpalmer at gmail.com Wed Nov 12 21:36:03 2014 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 12 Nov 2014 16:36:03 -0500 Subject: Building Creative Graphics Applications in JavaFX In-Reply-To: References: <6BDD9DB1-8C56-406F-9244-6E0FC96EB341@gmail.com> Message-ID: The data flow UI is all custom. A very early version tried to use the NetBeans Visual Library, but we it didn't quite have do everything we needed and we saw that Swing was on the way out so we went with FX. At first we embedded a JFXPanel in the Swing app. Now it is all ported to JavaFX though it can still run in a Swing mode with the JFXPanel. The video processing is done with native code, but the data flow and metadata that enables dynamic workflows is all on the Java side. We had to go native to get a decent video preview too, that's the most awkward part of the UI. There is no supported mechanism to even get the native window handle of the stage so the preview window is a horrible hack. I'm hoping to get some support in FX to fix that - either access to a OpenGL or DirectDraw context, or access to the MediaPlayer pipeline (my request for that dates back to JavaFX 1.0). Cheers, Scott On Wed, Nov 12, 2014 at 12:17 PM, Jeffrey Guenther < guenther.jeffrey at gmail.com> wrote: > Hi Scott, > > Thank you for the heads up. The application looks great! > > Is dataflow UI custom or are you using an open source library? > Is the video encoding stuff written in Java too? > > Jeff > > On Nov 10, 2014, at 7:51 PM, Scott Palmer wrote: > > JavaFX is up to the task. I've done an application much like you describe > (visualizing a bunch of connected nodes). It's a commercial app ( > http://www.digitalrapids.com/en/Products/Kayak/Page2.aspx) > > Though image operations on a raster for such things as a Photoshop-like > app could benefit a lot from going native. (There is JAI for that, but it > deals with AWT images.) > > Scott > > On Mon, Nov 10, 2014 at 3:04 PM, Jeffrey Guenther < > guenther.jeffrey at gmail.com> wrote: > >> Hello, >> >> I have been using JavaFX for the last couple years to build a prototype >> for my PhD research. I?ve really enjoyed myself as I?ve used it. For the >> most part, I can implement a UI as fast as I can understand what it needs >> to do. The scene graph is wonderful. >> >> JavaFX is great if you want to build a more traditional application that >> uses buttons, list views, tables views, etc. What I?m still trying to >> understand is how well JavaFX can help me build more complex interactive >> graphics applications. The majority of my work is in data visualization and >> image creation. I?ve been working some something like NodeBox or >> Grasshopper for Rhino. I?ll finish the prototype with JavaFX. What I?m >> pondering is if I can/should keep using JavaFX should I take the project >> commercial or will it be coding myself into a corner. >> >> My question to you is: has any one tried to build, even as a sample >> project, a small image editor or vector drawing application with JavaFX? >> What worked well? What kinds of problems did you run into? >> >> What has been the experience of the SceneBuilder team? SceneBuilder is >> probably the most advanced creative tool I?ve seen built with JavaFX so far. >> >> I read a post about there being a OpenGL view added to JavaFX one day. >> What?s the latest on this? >> >> I?m very convinced by the work done by Netflix with RxJava and their >> other projects that Java/JVM applications work great in the enterprise on >> the server. What I?m wondering is if Java and JavaFX can compete with tools >> like Apple?s Cocoa or Qt for building creative applications like say the >> next generations of Photoshop and Illustrator, or some other new innovative >> way of creating content. >> >> Thank you for your time! >> >> Jeff >> >> >> > > From chris.bensen at oracle.com Wed Nov 12 23:58:57 2014 From: chris.bensen at oracle.com (Chris Bensen) Date: Wed, 12 Nov 2014 15:58:57 -0800 Subject: Review for RT-39137 Message-ID: <068CBD40-BC3D-4B16-885E-06E15900B06B@oracle.com> Danno, Please review this patch. More info in the JIRA Webrev: http://cr.openjdk.java.net/~cbensen/RT-39137/webrev.00/ JIRA: https://javafx-jira.kenai.com/browse/RT-39137 From alexander.zvegintsev at oracle.com Thu Nov 13 17:47:25 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 13 Nov 2014 20:47:25 +0300 Subject: [8u40] Review request for RT-38940: [Gtk, Mac] Japanese IME, unable to distinguish focused composing text Message-ID: <5464EEAD.5030905@oracle.com> Hello, please review the fix http://cr.openjdk.java.net/~azvegint/fx/8u40/38940/ for https://javafx-jira.kenai.com/browse/RT-38940 -- -- Thanks, Alexander. From ngalarneau at ABINITIO.COM Thu Nov 13 20:38:39 2014 From: ngalarneau at ABINITIO.COM (ngalarneau at ABINITIO.COM) Date: Thu, 13 Nov 2014 15:38:39 -0500 Subject: Monocle in 8u25 In-Reply-To: References: <54591A31.1070709@oracle.com> <545A788D.9030509@tbee.org> <546310E1.8000702@tbee.org> Message-ID: Hi Benjamin, We are using Spock for testing, and have modified the setupStage() method to support optional headless testing with Monocle, which is working well on Windows (the code is in groovy): void setupStage(Closure rootNodeFactory) { if (fx == null && isHeadless) { // Cribbed from: https://gist.github.com/hastebrot/cbca1128dd791966e3a6 PlatformFactory.instance = new MonoclePlatformFactory() NativePlatformFactory.platform = new HeadlessPlatform() } fx = new GuiTest() fx.rootNodeFactory = rootNodeFactory fx.setupGuiTest() } It works nicely until fx.clickOn is called. The TestFX library is still moving the Windows mouse! Any thoughts? Thanks, Neil From: Benjamin Gudehus To: Tom Eugelink , Cc: "openjfx-dev at openjdk.java.net" Date: 11/12/2014 03:10 AM Subject: Re: Monocle in 8u25 Sent by: "openjfx-dev" That would be nice, Tom. Example usage: Since com.sun.glass.ui.PlatformFactory can't find Monocle classes from the external jars, we need to change public static void main(String[] appArgs) { Application.launch(appClass, appArgs); } to public static void main(String[] appArgs) { new ToolkitApplicationLauncher().launch(appClass, appArgs); } and start the Application with -Djavafx.monocle.headless=true. ToolkitApplicationLauncher.jar: https://gist.github.com/hastebrot/cbca1128dd791966e3a6 On Wed, Nov 12, 2014 at 8:48 AM, Tom Eugelink wrote: > I can roll it out under the same name (openjfx-monocle-1.8.0_20) within > the org.jfxtras group. Just say so. > > Tom > > > On 12-11-2014 08:30, Benjamin Gudehus wrote: > > Hi all! > > Files and instructions are available at https://github.com/TestFX/Monocle > . > > Releases with jars: https://github.com/TestFX/Monocle/releases > > License (taken from OpenJFX respository): > https://github.com/TestFX/Monocle/blob/master/LICENSE > > Would be nice to have this available from Maven. > > --Benjamin > > On Wed, Nov 5, 2014 at 8:20 PM, Tom Eugelink wrote: > >> This is extremely good news. I have no problem to "drag" that library >> along in the JFXtras project (project name seems to be a good match for >> this usage ;-) and release it to maven - if that is allowed by the JavaFX >> license. >> >> Tom >> >> >> >> On 5-11-2014 16:57, Benjamin Gudehus wrote: >> >>> Hi Sean, >>> >>> I've put the Monocle sources directly in my code directories for >>> testing purposes. Putting it into a separate Jar is possible and I >>> thought that pre-compiled jars could be provided via Maven. >>> >>> I didn't do a complete OpenJFX build, because I was only interested in >>> the Headless component of Monocle, i.e. I didn't needed the >>> platform-dependent dynamic libraries. >>> >>> Rough instructions were given in a previous mail. There were some >>> request to provide the pre-compoile jars so I will additionally set up >>> a public repository with detailed instructions when I'm back home. >>> >>> --Benjamin >>> >>> On 11/5/14, Sean True wrote: >>> >>>> Did you build the glass/ui/monocle sources into a separate jar, or did >>>> you >>>> do a complete OpenJFX build? >>>> >>>> If you did a separate build, a recipe would be extremely helpful. >>>> >>>> -- Sean >>>> >>>> On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus >>>> wrote: >>>> >>>> I managed to run Monocle/Headless on Windows with 8u25. This will allow >>>>> users to run headless tests. >>>>> >>>>> All what is needed is to copy all files from "com/sun/glass/ui/monocle" >>>>> of >>>>> "javafx-src.zip" and add the >>>>> cursor resource files from >>>>> "modules/graphics/src/main/resources/com/sun/glass/ui/monocle" of the >>>>> related hg tag in the OpenJFX repository [1]. >>>>> >>>>> Before Application#launch() is called we need to manually set the Glass >>>>> and >>>>> Monocle platforms: >>>>> >>>>> accessStaticField(com.sun.glass.ui.PlatformFactory.class, "instance", >>>>> new com.sun.glass.ui.monocle.MonoclePlatformFactory()); >>>>> accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class, >>>>> "platform", >>>>> new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); >>>>> >>>>> The directory structure in 8u40 is a bit different, but there could be >>>>> added version checks. Checking >>>>> for the JVM vars "glass.platform" and "monocle.platform" might be also >>>>> added to this code. >>>>> >>>>> [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags >>>>> >>>>> >>>>> On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus >>>>> wrote: >>>>> >>>>> Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory >>>>>> won't >>>>>> retrieve externally defined PlatformFactorys. So I will try to set the >>>>>> PlatformFactory.instance field manually, before the >>>>>> Application/Tookit/FX-Thread is launched. >>>>>> >>>>>> On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus >>>>> > >>>>>> wrote: >>>>>> >>>>>> Thank you. That makes it clearer. :) >>>>>>> >>>>>>> Is it possible to supply the headless part of Monocle in an external >>>>>>> Jar >>>>>>> for desktop platforms? >>>>>>> >>>>>>> As far as I know the only possibility to run TestFX tests with >>>>>>> Hudson/Jenkins is in headless mode. >>>>>>> TestFX's tests itself can only run with the X virtual framebuffer on >>>>>>> Linux test clients for the Travis CI so far. >>>>>>> >>>>>>> So far the only advice I could give TestFX users who like to run >>>>>>> >>>>>> headless >>>>> >>>>>> tests is to use 1.8.0_20-ea-b05. >>>>>>> NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution. From hastebrot at gmail.com Thu Nov 13 21:01:17 2014 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Thu, 13 Nov 2014 22:01:17 +0100 Subject: Monocle in 8u25 In-Reply-To: References: <54591A31.1070709@oracle.com> <545A788D.9030509@tbee.org> <546310E1.8000702@tbee.org> Message-ID: Hi Neil! >The TestFX library is still moving the Windows mouse! TestFX is using Awt's robot. This robot ignores Glass/Monocle and controls the OS's cursor. We need to replace it with Glass' robot. I already tested it and it works fine. PR will be ready soon. This PR will also replace the Awt screenshot mechanism with the one from the Glass robot. I hoped that this will also take screenshots wenn running in headless mode. But unfortunately the screenshots were empty. I saw in Monocle's source code, that it writes color values into an internal byte stream, so it actually should work. Also very nice to see, that people are using bleeding edge version of TestFX. :) TestFX will also have better Spock/Groovy support in the future. --Benjamin On Thu, Nov 13, 2014 at 9:38 PM, wrote: > Hi Benjamin, > > We are using Spock for testing, and have modified the setupStage() method > to support optional headless testing with Monocle, > which is working well on Windows (the code is in groovy): > > void setupStage(Closure rootNodeFactory) > { > if (fx == null && isHeadless) > { > // Cribbed from: > https://gist.github.com/hastebrot/cbca1128dd791966e3a6 > PlatformFactory.instance = new MonoclePlatformFactory() > NativePlatformFactory.platform = new HeadlessPlatform() > } > fx = new GuiTest() > fx.rootNodeFactory = rootNodeFactory > fx.setupGuiTest() > } > > It works nicely until fx.clickOn is called. The TestFX library is still > moving the Windows mouse! > > Any thoughts? > > > Thanks, > > Neil > > > > > From: Benjamin Gudehus > To: Tom Eugelink , > Cc: "openjfx-dev at openjdk.java.net" > Date: 11/12/2014 03:10 AM > Subject: Re: Monocle in 8u25 > Sent by: "openjfx-dev" > ------------------------------ > > > > That would be nice, Tom. > > Example usage: > > Since com.sun.glass.ui.PlatformFactory can't find Monocle classes from the > external jars, we need to change > > public static void main(String[] appArgs) { > Application.launch(appClass, appArgs); > } > > to > > public static void main(String[] appArgs) { > new ToolkitApplicationLauncher().launch(appClass, appArgs); > } > > and start the Application with -Djavafx.monocle.headless=true. > > ToolkitApplicationLauncher.jar: > https://gist.github.com/hastebrot/cbca1128dd791966e3a6 > > > On Wed, Nov 12, 2014 at 8:48 AM, Tom Eugelink wrote: > > > I can roll it out under the same name (openjfx-monocle-1.8.0_20) within > > the org.jfxtras group. Just say so. > > > > Tom > > > > > > On 12-11-2014 08:30, Benjamin Gudehus wrote: > > > > Hi all! > > > > Files and instructions are available at > https://github.com/TestFX/Monocle > > . > > > > Releases with jars: https://github.com/TestFX/Monocle/releases > > > > License (taken from OpenJFX respository): > > https://github.com/TestFX/Monocle/blob/master/LICENSE > > > > Would be nice to have this available from Maven. > > > > --Benjamin > > > > On Wed, Nov 5, 2014 at 8:20 PM, Tom Eugelink wrote: > > > >> This is extremely good news. I have no problem to "drag" that library > >> along in the JFXtras project (project name seems to be a good match for > >> this usage ;-) and release it to maven - if that is allowed by the > JavaFX > >> license. > >> > >> Tom > >> > >> > >> > >> On 5-11-2014 16:57, Benjamin Gudehus wrote: > >> > >>> Hi Sean, > >>> > >>> I've put the Monocle sources directly in my code directories for > >>> testing purposes. Putting it into a separate Jar is possible and I > >>> thought that pre-compiled jars could be provided via Maven. > >>> > >>> I didn't do a complete OpenJFX build, because I was only interested in > >>> the Headless component of Monocle, i.e. I didn't needed the > >>> platform-dependent dynamic libraries. > >>> > >>> Rough instructions were given in a previous mail. There were some > >>> request to provide the pre-compoile jars so I will additionally set up > >>> a public repository with detailed instructions when I'm back home. > >>> > >>> --Benjamin > >>> > >>> On 11/5/14, Sean True wrote: > >>> > >>>> Did you build the glass/ui/monocle sources into a separate jar, or did > >>>> you > >>>> do a complete OpenJFX build? > >>>> > >>>> If you did a separate build, a recipe would be extremely helpful. > >>>> > >>>> -- Sean > >>>> > >>>> On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus > > >>>> wrote: > >>>> > >>>> I managed to run Monocle/Headless on Windows with 8u25. This will > allow > >>>>> users to run headless tests. > >>>>> > >>>>> All what is needed is to copy all files from > "com/sun/glass/ui/monocle" > >>>>> of > >>>>> "javafx-src.zip" and add the > >>>>> cursor resource files from > >>>>> "modules/graphics/src/main/resources/com/sun/glass/ui/monocle" of the > >>>>> related hg tag in the OpenJFX repository [1]. > >>>>> > >>>>> Before Application#launch() is called we need to manually set the > Glass > >>>>> and > >>>>> Monocle platforms: > >>>>> > >>>>> accessStaticField(com.sun.glass.ui.PlatformFactory.class, "instance", > >>>>> new com.sun.glass.ui.monocle.MonoclePlatformFactory()); > >>>>> > accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class, > >>>>> "platform", > >>>>> new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); > >>>>> > >>>>> The directory structure in 8u40 is a bit different, but there could > be > >>>>> added version checks. Checking > >>>>> for the JVM vars "glass.platform" and "monocle.platform" might be > also > >>>>> added to this code. > >>>>> > >>>>> [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags > >>>>> > >>>>> > >>>>> On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus < > hastebrot at gmail.com> > >>>>> wrote: > >>>>> > >>>>> Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory > >>>>>> won't > >>>>>> retrieve externally defined PlatformFactorys. So I will try to set > the > >>>>>> PlatformFactory.instance field manually, before the > >>>>>> Application/Tookit/FX-Thread is launched. > >>>>>> > >>>>>> On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus < > hastebrot at gmail.com > >>>>>> > > >>>>>> wrote: > >>>>>> > >>>>>> Thank you. That makes it clearer. :) > >>>>>>> > >>>>>>> Is it possible to supply the headless part of Monocle in an > external > >>>>>>> Jar > >>>>>>> for desktop platforms? > >>>>>>> > >>>>>>> As far as I know the only possibility to run TestFX tests with > >>>>>>> Hudson/Jenkins is in headless mode. > >>>>>>> TestFX's tests itself can only run with the X virtual framebuffer > on > >>>>>>> Linux test clients for the Travis CI so far. > >>>>>>> > >>>>>>> So far the only advice I could give TestFX users who like to run > >>>>>>> > >>>>>> headless > >>>>> > >>>>>> tests is to use 1.8.0_20-ea-b05. > >>>>>>> > > > > > NOTICE *from Ab Initio: This email (including any attachments) may > contain information that is subject to confidentiality obligations or is > legally privileged, and sender does not waive confidentiality or privilege. > If received in error, please notify the sender, delete this email, and make > no further use, disclosure, or distribution. * From hastebrot at gmail.com Thu Nov 13 21:06:29 2014 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Thu, 13 Nov 2014 22:06:29 +0100 Subject: Monocle in 8u25 In-Reply-To: References: <54591A31.1070709@oracle.com> <545A788D.9030509@tbee.org> <546310E1.8000702@tbee.org> Message-ID: @Tom Thanks for the patch. Will apply it soon. Is there something like a package maintainer field for Maven? I think developer is a bit too pompous; I didn't touch the code. On Thu, Nov 13, 2014 at 10:01 PM, Benjamin Gudehus wrote: > Hi Neil! > > >The TestFX library is still moving the Windows mouse! > TestFX is using Awt's robot. This robot ignores Glass/Monocle and controls > the OS's cursor. > We need to replace it with Glass' robot. I already tested it and it works > fine. > PR will be ready soon. This PR will also replace the Awt screenshot > mechanism with the one > from the Glass robot. I hoped that this will also take screenshots wenn > running in headless mode. > But unfortunately the screenshots were empty. I saw in Monocle's source > code, that it writes > color values into an internal byte stream, so it actually should work. > > Also very nice to see, that people are using bleeding edge version of > TestFX. :) > TestFX will also have better Spock/Groovy support in the future. > > --Benjamin > > > On Thu, Nov 13, 2014 at 9:38 PM, wrote: > >> Hi Benjamin, >> >> We are using Spock for testing, and have modified the setupStage() method >> to support optional headless testing with Monocle, >> which is working well on Windows (the code is in groovy): >> >> void setupStage(Closure rootNodeFactory) >> { >> if (fx == null && isHeadless) >> { >> // Cribbed from: >> https://gist.github.com/hastebrot/cbca1128dd791966e3a6 >> PlatformFactory.instance = new MonoclePlatformFactory() >> NativePlatformFactory.platform = new HeadlessPlatform() >> } >> fx = new GuiTest() >> fx.rootNodeFactory = rootNodeFactory >> fx.setupGuiTest() >> } >> >> It works nicely until fx.clickOn is called. The TestFX library is still >> moving the Windows mouse! >> >> Any thoughts? >> >> >> Thanks, >> >> Neil >> >> >> >> >> From: Benjamin Gudehus >> To: Tom Eugelink , >> Cc: "openjfx-dev at openjdk.java.net" >> Date: 11/12/2014 03:10 AM >> Subject: Re: Monocle in 8u25 >> Sent by: "openjfx-dev" >> ------------------------------ >> >> >> >> That would be nice, Tom. >> >> Example usage: >> >> Since com.sun.glass.ui.PlatformFactory can't find Monocle classes from the >> external jars, we need to change >> >> public static void main(String[] appArgs) { >> Application.launch(appClass, appArgs); >> } >> >> to >> >> public static void main(String[] appArgs) { >> new ToolkitApplicationLauncher().launch(appClass, appArgs); >> } >> >> and start the Application with -Djavafx.monocle.headless=true. >> >> ToolkitApplicationLauncher.jar: >> https://gist.github.com/hastebrot/cbca1128dd791966e3a6 >> >> >> On Wed, Nov 12, 2014 at 8:48 AM, Tom Eugelink wrote: >> >> > I can roll it out under the same name (openjfx-monocle-1.8.0_20) within >> > the org.jfxtras group. Just say so. >> > >> > Tom >> > >> > >> > On 12-11-2014 08:30, Benjamin Gudehus wrote: >> > >> > Hi all! >> > >> > Files and instructions are available at >> https://github.com/TestFX/Monocle >> > . >> > >> > Releases with jars: https://github.com/TestFX/Monocle/releases >> > >> > License (taken from OpenJFX respository): >> > https://github.com/TestFX/Monocle/blob/master/LICENSE >> > >> > Would be nice to have this available from Maven. >> > >> > --Benjamin >> > >> > On Wed, Nov 5, 2014 at 8:20 PM, Tom Eugelink wrote: >> > >> >> This is extremely good news. I have no problem to "drag" that library >> >> along in the JFXtras project (project name seems to be a good match for >> >> this usage ;-) and release it to maven - if that is allowed by the >> JavaFX >> >> license. >> >> >> >> Tom >> >> >> >> >> >> >> >> On 5-11-2014 16:57, Benjamin Gudehus wrote: >> >> >> >>> Hi Sean, >> >>> >> >>> I've put the Monocle sources directly in my code directories for >> >>> testing purposes. Putting it into a separate Jar is possible and I >> >>> thought that pre-compiled jars could be provided via Maven. >> >>> >> >>> I didn't do a complete OpenJFX build, because I was only interested in >> >>> the Headless component of Monocle, i.e. I didn't needed the >> >>> platform-dependent dynamic libraries. >> >>> >> >>> Rough instructions were given in a previous mail. There were some >> >>> request to provide the pre-compoile jars so I will additionally set up >> >>> a public repository with detailed instructions when I'm back home. >> >>> >> >>> --Benjamin >> >>> >> >>> On 11/5/14, Sean True wrote: >> >>> >> >>>> Did you build the glass/ui/monocle sources into a separate jar, or >> did >> >>>> you >> >>>> do a complete OpenJFX build? >> >>>> >> >>>> If you did a separate build, a recipe would be extremely helpful. >> >>>> >> >>>> -- Sean >> >>>> >> >>>> On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus < >> hastebrot at gmail.com> >> >>>> wrote: >> >>>> >> >>>> I managed to run Monocle/Headless on Windows with 8u25. This will >> allow >> >>>>> users to run headless tests. >> >>>>> >> >>>>> All what is needed is to copy all files from >> "com/sun/glass/ui/monocle" >> >>>>> of >> >>>>> "javafx-src.zip" and add the >> >>>>> cursor resource files from >> >>>>> "modules/graphics/src/main/resources/com/sun/glass/ui/monocle" of >> the >> >>>>> related hg tag in the OpenJFX repository [1]. >> >>>>> >> >>>>> Before Application#launch() is called we need to manually set the >> Glass >> >>>>> and >> >>>>> Monocle platforms: >> >>>>> >> >>>>> accessStaticField(com.sun.glass.ui.PlatformFactory.class, >> "instance", >> >>>>> new com.sun.glass.ui.monocle.MonoclePlatformFactory()); >> >>>>> >> accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class, >> >>>>> "platform", >> >>>>> new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); >> >>>>> >> >>>>> The directory structure in 8u40 is a bit different, but there could >> be >> >>>>> added version checks. Checking >> >>>>> for the JVM vars "glass.platform" and "monocle.platform" might be >> also >> >>>>> added to this code. >> >>>>> >> >>>>> [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags >> >>>>> >> >>>>> >> >>>>> On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus < >> hastebrot at gmail.com> >> >>>>> wrote: >> >>>>> >> >>>>> Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory >> >>>>>> won't >> >>>>>> retrieve externally defined PlatformFactorys. So I will try to set >> the >> >>>>>> PlatformFactory.instance field manually, before the >> >>>>>> Application/Tookit/FX-Thread is launched. >> >>>>>> >> >>>>>> On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus < >> hastebrot at gmail.com >> >>>>>> > >> >>>>>> wrote: >> >>>>>> >> >>>>>> Thank you. That makes it clearer. :) >> >>>>>>> >> >>>>>>> Is it possible to supply the headless part of Monocle in an >> external >> >>>>>>> Jar >> >>>>>>> for desktop platforms? >> >>>>>>> >> >>>>>>> As far as I know the only possibility to run TestFX tests with >> >>>>>>> Hudson/Jenkins is in headless mode. >> >>>>>>> TestFX's tests itself can only run with the X virtual framebuffer >> on >> >>>>>>> Linux test clients for the Travis CI so far. >> >>>>>>> >> >>>>>>> So far the only advice I could give TestFX users who like to run >> >>>>>>> >> >>>>>> headless >> >>>>> >> >>>>>> tests is to use 1.8.0_20-ea-b05. >> >>>>>>> >> >> >> >> >> NOTICE *from Ab Initio: This email (including any attachments) may >> contain information that is subject to confidentiality obligations or is >> legally privileged, and sender does not waive confidentiality or privilege. >> If received in error, please notify the sender, delete this email, and make >> no further use, disclosure, or distribution. * > > > From tbee at tbee.org Thu Nov 13 21:33:45 2014 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 13 Nov 2014 22:33:45 +0100 Subject: Monocle in 8u25 In-Reply-To: References: <54591A31.1070709@oracle.com> <545A788D.9030509@tbee.org> <546310E1.8000702@tbee.org> Message-ID: <546523B9.5040207@tbee.org> A developer is mandatory, your name is as good as any? Tom On 13-11-2014 22:06, Benjamin Gudehus wrote: > @Tom Thanks for the patch. Will apply it soon. > Is there something like a package maintainer field for Maven? I think > developer is a bit too pompous; I didn't touch the code. > > On Thu, Nov 13, 2014 at 10:01 PM, Benjamin Gudehus > wrote: > >> Hi Neil! >> >>> The TestFX library is still moving the Windows mouse! >> TestFX is using Awt's robot. This robot ignores Glass/Monocle and controls >> the OS's cursor. >> We need to replace it with Glass' robot. I already tested it and it works >> fine. >> PR will be ready soon. This PR will also replace the Awt screenshot >> mechanism with the one >> from the Glass robot. I hoped that this will also take screenshots wenn >> running in headless mode. >> But unfortunately the screenshots were empty. I saw in Monocle's source >> code, that it writes >> color values into an internal byte stream, so it actually should work. >> >> Also very nice to see, that people are using bleeding edge version of >> TestFX. :) >> TestFX will also have better Spock/Groovy support in the future. >> >> --Benjamin >> >> >> On Thu, Nov 13, 2014 at 9:38 PM, wrote: >> >>> Hi Benjamin, >>> >>> We are using Spock for testing, and have modified the setupStage() method >>> to support optional headless testing with Monocle, >>> which is working well on Windows (the code is in groovy): >>> >>> void setupStage(Closure rootNodeFactory) >>> { >>> if (fx == null && isHeadless) >>> { >>> // Cribbed from: >>> https://gist.github.com/hastebrot/cbca1128dd791966e3a6 >>> PlatformFactory.instance = new MonoclePlatformFactory() >>> NativePlatformFactory.platform = new HeadlessPlatform() >>> } >>> fx = new GuiTest() >>> fx.rootNodeFactory = rootNodeFactory >>> fx.setupGuiTest() >>> } >>> >>> It works nicely until fx.clickOn is called. The TestFX library is still >>> moving the Windows mouse! >>> >>> Any thoughts? >>> >>> >>> Thanks, >>> >>> Neil >>> >>> >>> >>> >>> From: Benjamin Gudehus >>> To: Tom Eugelink , >>> Cc: "openjfx-dev at openjdk.java.net" >>> Date: 11/12/2014 03:10 AM >>> Subject: Re: Monocle in 8u25 >>> Sent by: "openjfx-dev" >>> ------------------------------ >>> >>> >>> >>> That would be nice, Tom. >>> >>> Example usage: >>> >>> Since com.sun.glass.ui.PlatformFactory can't find Monocle classes from the >>> external jars, we need to change >>> >>> public static void main(String[] appArgs) { >>> Application.launch(appClass, appArgs); >>> } >>> >>> to >>> >>> public static void main(String[] appArgs) { >>> new ToolkitApplicationLauncher().launch(appClass, appArgs); >>> } >>> >>> and start the Application with -Djavafx.monocle.headless=true. >>> >>> ToolkitApplicationLauncher.jar: >>> https://gist.github.com/hastebrot/cbca1128dd791966e3a6 >>> >>> >>> On Wed, Nov 12, 2014 at 8:48 AM, Tom Eugelink wrote: >>> >>>> I can roll it out under the same name (openjfx-monocle-1.8.0_20) within >>>> the org.jfxtras group. Just say so. >>>> >>>> Tom >>>> >>>> >>>> On 12-11-2014 08:30, Benjamin Gudehus wrote: >>>> >>>> Hi all! >>>> >>>> Files and instructions are available at >>> https://github.com/TestFX/Monocle >>>> . >>>> >>>> Releases with jars: https://github.com/TestFX/Monocle/releases >>>> >>>> License (taken from OpenJFX respository): >>>> https://github.com/TestFX/Monocle/blob/master/LICENSE >>>> >>>> Would be nice to have this available from Maven. >>>> >>>> --Benjamin >>>> >>>> On Wed, Nov 5, 2014 at 8:20 PM, Tom Eugelink wrote: >>>> >>>>> This is extremely good news. I have no problem to "drag" that library >>>>> along in the JFXtras project (project name seems to be a good match for >>>>> this usage ;-) and release it to maven - if that is allowed by the >>> JavaFX >>>>> license. >>>>> >>>>> Tom >>>>> >>>>> >>>>> >>>>> On 5-11-2014 16:57, Benjamin Gudehus wrote: >>>>> >>>>>> Hi Sean, >>>>>> >>>>>> I've put the Monocle sources directly in my code directories for >>>>>> testing purposes. Putting it into a separate Jar is possible and I >>>>>> thought that pre-compiled jars could be provided via Maven. >>>>>> >>>>>> I didn't do a complete OpenJFX build, because I was only interested in >>>>>> the Headless component of Monocle, i.e. I didn't needed the >>>>>> platform-dependent dynamic libraries. >>>>>> >>>>>> Rough instructions were given in a previous mail. There were some >>>>>> request to provide the pre-compoile jars so I will additionally set up >>>>>> a public repository with detailed instructions when I'm back home. >>>>>> >>>>>> --Benjamin >>>>>> >>>>>> On 11/5/14, Sean True wrote: >>>>>> >>>>>>> Did you build the glass/ui/monocle sources into a separate jar, or >>> did >>>>>>> you >>>>>>> do a complete OpenJFX build? >>>>>>> >>>>>>> If you did a separate build, a recipe would be extremely helpful. >>>>>>> >>>>>>> -- Sean >>>>>>> >>>>>>> On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus < >>> hastebrot at gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> I managed to run Monocle/Headless on Windows with 8u25. This will >>> allow >>>>>>>> users to run headless tests. >>>>>>>> >>>>>>>> All what is needed is to copy all files from >>> "com/sun/glass/ui/monocle" >>>>>>>> of >>>>>>>> "javafx-src.zip" and add the >>>>>>>> cursor resource files from >>>>>>>> "modules/graphics/src/main/resources/com/sun/glass/ui/monocle" of >>> the >>>>>>>> related hg tag in the OpenJFX repository [1]. >>>>>>>> >>>>>>>> Before Application#launch() is called we need to manually set the >>> Glass >>>>>>>> and >>>>>>>> Monocle platforms: >>>>>>>> >>>>>>>> accessStaticField(com.sun.glass.ui.PlatformFactory.class, >>> "instance", >>>>>>>> new com.sun.glass.ui.monocle.MonoclePlatformFactory()); >>>>>>>> >>> accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class, >>>>>>>> "platform", >>>>>>>> new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); >>>>>>>> >>>>>>>> The directory structure in 8u40 is a bit different, but there could >>> be >>>>>>>> added version checks. Checking >>>>>>>> for the JVM vars "glass.platform" and "monocle.platform" might be >>> also >>>>>>>> added to this code. >>>>>>>> >>>>>>>> [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus < >>> hastebrot at gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory >>>>>>>>> won't >>>>>>>>> retrieve externally defined PlatformFactorys. So I will try to set >>> the >>>>>>>>> PlatformFactory.instance field manually, before the >>>>>>>>> Application/Tookit/FX-Thread is launched. >>>>>>>>> >>>>>>>>> On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus < >>> hastebrot at gmail.com >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Thank you. That makes it clearer. :) >>>>>>>>>> Is it possible to supply the headless part of Monocle in an >>> external >>>>>>>>>> Jar >>>>>>>>>> for desktop platforms? >>>>>>>>>> >>>>>>>>>> As far as I know the only possibility to run TestFX tests with >>>>>>>>>> Hudson/Jenkins is in headless mode. >>>>>>>>>> TestFX's tests itself can only run with the X virtual framebuffer >>> on >>>>>>>>>> Linux test clients for the Travis CI so far. >>>>>>>>>> >>>>>>>>>> So far the only advice I could give TestFX users who like to run >>>>>>>>>> >>>>>>>>> headless >>>>>>>>> tests is to use 1.8.0_20-ea-b05. >>> >>> >>> >>> NOTICE *from Ab Initio: This email (including any attachments) may >>> contain information that is subject to confidentiality obligations or is >>> legally privileged, and sender does not waive confidentiality or privilege. >>> If received in error, please notify the sender, delete this email, and make >>> no further use, disclosure, or distribution. * >> >> From herve.girod at gmail.com Thu Nov 13 22:30:25 2014 From: herve.girod at gmail.com (Herve Girod) Date: Thu, 13 Nov 2014 23:30:25 +0100 Subject: Dumping the rendering process in JavaFX Message-ID: Hello, I think that more than one year ago, I asked if it was possible to dump the JavaFX rendering process. More than one year later, I (or we, for I am speaking on behalf of my project) are almost there. We use this in a library for a "JavaFX to any format you want" converter. For example we are currently able to convert a live JavaFX image to a PowerPoint slider (using POI), or we also could do the same with a WMF / EMF / SVG image, keeping the vector content of course. What we did is hacking the J2DPrismGraphics class to render it in a custom Graphics2D context which in turn can be a PPT / SVG / WMF / or EMF serializer. Our use case is the use of JavaFX in an Editor (no it's not a JavaFX Editor, we edit graphic specifications for an avionics standard called ARINC 661), and the ability to produce another Vector format with exactly the same UI. It works very well, except that of course we had to hack a few JavaFX core classes to do that (obviously J2DPrismGraphics was not designed to allow this). We did not recompile the core library, it's just separate classes which uses com.sun classes when possible, or we used PrivilegedActions when a method we needed was package protected. But we have still a big problem (I think that it might be the only one, except for the fact that our solution is an ugly hack, as you can see): There is still one case where our solution does not work: Textures. In fact we would have been able to convert JavaFX textures to BufferedImages if we could use the Java2D-based Texture class, but of course as we did nothing special, we encounter a D3D Texture (for example on Windows) which we don't know how to deal with. Which leads me to my two questions: - Is there a programmatic way (even a contorted one) to force JavaFX to use our own specific Pipeline (the idea is to be able to do this temporarily when serializing the JavaFX content, so without having to use command line argument) - I think that it could be very useful to have a neutral and JavaFX - supported way for developers to use their own Pipeline, even if it was limited and with a lower than average performance. Being able to convert from / to the JavaFX format is something that can be very useful. Herv? From kevin.rushforth at oracle.com Thu Nov 13 22:49:53 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 13 Nov 2014 14:49:53 -0800 Subject: Dumping the rendering process in JavaFX In-Reply-To: References: Message-ID: <54653591.8000803@oracle.com> You could take a look at what JavaFX internally does for printing, which is similar to what you are trying to do. It also forces the J2D pipeline and had to deal with this issue. You likely won't be able to do it without modifying FX internals, though, which is what printing does in a few places. -- Kevin Herve Girod wrote: > Hello, > > I think that more than one year ago, I asked if it was possible to dump the > JavaFX rendering process. More than one year later, I (or we, for I am > speaking on behalf of my project) are almost there. We use this in a > library for a "JavaFX to any format you want" converter. For example we are > currently able to convert a live JavaFX image to a PowerPoint slider (using > POI), or we also could do the same with a WMF / EMF / SVG image, keeping > the vector content of course. > > What we did is hacking the J2DPrismGraphics class to render it in a custom > Graphics2D context which in turn can be a PPT / SVG / WMF / or EMF > serializer. > > Our use case is the use of JavaFX in an Editor (no it's not a JavaFX > Editor, we edit graphic specifications for an avionics standard called > ARINC 661), and the ability to produce another Vector format with exactly > the same UI. > > It works very well, except that of course we had to hack a few JavaFX core > classes to do that (obviously J2DPrismGraphics was not designed to allow > this). We did not recompile the core library, it's just separate classes > which uses com.sun classes when possible, or we used PrivilegedActions when > a method we needed was package protected. > > But we have still a big problem (I think that it might be the only one, > except for the fact that our solution is an ugly hack, as you can see): > > There is still one case where our solution does not work: Textures. In fact > we would have been able to convert JavaFX textures to BufferedImages if we > could use the Java2D-based Texture class, but of course as we did nothing > special, we encounter a D3D Texture (for example on Windows) which we don't > know how to deal with. > > Which leads me to my two questions: > > - Is there a programmatic way (even a contorted one) to force JavaFX to use > our own specific Pipeline (the idea is to be able to do this temporarily > when serializing the JavaFX content, so without having to use command line > argument) > > - I think that it could be very useful to have a neutral and JavaFX - > supported way for developers to use their own Pipeline, even if it was > limited and with a lower than average performance. Being able to convert > from / to the JavaFX format is something that can be very useful. > > Herv? > From herve.girod at gmail.com Thu Nov 13 22:53:54 2014 From: herve.girod at gmail.com (Herve Girod) Date: Thu, 13 Nov 2014 23:53:54 +0100 Subject: Dumping the rendering process in JavaFX In-Reply-To: <54653591.8000803@oracle.com> References: <54653591.8000803@oracle.com> Message-ID: Thanks a lot, I did not think about that. 2014-11-13 23:49 GMT+01:00 Kevin Rushforth : > You could take a look at what JavaFX internally does for printing, which > is similar to what you are trying to do. It also forces the J2D pipeline > and had to deal with this issue. You likely won't be able to do it without > modifying FX internals, though, which is what printing does in a few places. > > -- Kevin > > > > Herve Girod wrote: > >> Hello, >> >> I think that more than one year ago, I asked if it was possible to dump >> the >> JavaFX rendering process. More than one year later, I (or we, for I am >> speaking on behalf of my project) are almost there. We use this in a >> library for a "JavaFX to any format you want" converter. For example we >> are >> currently able to convert a live JavaFX image to a PowerPoint slider >> (using >> POI), or we also could do the same with a WMF / EMF / SVG image, keeping >> the vector content of course. >> >> What we did is hacking the J2DPrismGraphics class to render it in a custom >> Graphics2D context which in turn can be a PPT / SVG / WMF / or EMF >> serializer. >> >> Our use case is the use of JavaFX in an Editor (no it's not a JavaFX >> Editor, we edit graphic specifications for an avionics standard called >> ARINC 661), and the ability to produce another Vector format with exactly >> the same UI. >> >> It works very well, except that of course we had to hack a few JavaFX core >> classes to do that (obviously J2DPrismGraphics was not designed to allow >> this). We did not recompile the core library, it's just separate classes >> which uses com.sun classes when possible, or we used PrivilegedActions >> when >> a method we needed was package protected. >> >> But we have still a big problem (I think that it might be the only one, >> except for the fact that our solution is an ugly hack, as you can see): >> >> There is still one case where our solution does not work: Textures. In >> fact >> we would have been able to convert JavaFX textures to BufferedImages if we >> could use the Java2D-based Texture class, but of course as we did nothing >> special, we encounter a D3D Texture (for example on Windows) which we >> don't >> know how to deal with. >> >> Which leads me to my two questions: >> >> - Is there a programmatic way (even a contorted one) to force JavaFX to >> use >> our own specific Pipeline (the idea is to be able to do this temporarily >> when serializing the JavaFX content, so without having to use command line >> argument) >> >> - I think that it could be very useful to have a neutral and JavaFX - >> supported way for developers to use their own Pipeline, even if it was >> limited and with a lower than average performance. Being able to convert >> from / to the JavaFX format is something that can be very useful. >> >> Herv? >> >> > From hastebrot at gmail.com Thu Nov 13 23:00:49 2014 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Fri, 14 Nov 2014 00:00:49 +0100 Subject: Monocle in 8u25 In-Reply-To: <546523B9.5040207@tbee.org> References: <54591A31.1070709@oracle.com> <545A788D.9030509@tbee.org> <546310E1.8000702@tbee.org> <546523B9.5040207@tbee.org> Message-ID: Maybe we could use "The TestFX contributors" as "developers"? On Thu, Nov 13, 2014 at 10:33 PM, Tom Eugelink wrote: > A developer is mandatory, your name is as good as any? > > Tom > > > > On 13-11-2014 22:06, Benjamin Gudehus wrote: > >> @Tom Thanks for the patch. Will apply it soon. >> Is there something like a package maintainer field for Maven? I think >> developer is a bit too pompous; I didn't touch the code. >> >> On Thu, Nov 13, 2014 at 10:01 PM, Benjamin Gudehus >> wrote: >> >> Hi Neil! >>> >>> The TestFX library is still moving the Windows mouse! >>>> >>> TestFX is using Awt's robot. This robot ignores Glass/Monocle and >>> controls >>> the OS's cursor. >>> We need to replace it with Glass' robot. I already tested it and it works >>> fine. >>> PR will be ready soon. This PR will also replace the Awt screenshot >>> mechanism with the one >>> from the Glass robot. I hoped that this will also take screenshots wenn >>> running in headless mode. >>> But unfortunately the screenshots were empty. I saw in Monocle's source >>> code, that it writes >>> color values into an internal byte stream, so it actually should work. >>> >>> Also very nice to see, that people are using bleeding edge version of >>> TestFX. :) >>> TestFX will also have better Spock/Groovy support in the future. >>> >>> --Benjamin >>> >>> >>> On Thu, Nov 13, 2014 at 9:38 PM, wrote: >>> >>> Hi Benjamin, >>>> >>>> We are using Spock for testing, and have modified the setupStage() >>>> method >>>> to support optional headless testing with Monocle, >>>> which is working well on Windows (the code is in groovy): >>>> >>>> void setupStage(Closure rootNodeFactory) >>>> { >>>> if (fx == null && isHeadless) >>>> { >>>> // Cribbed from: >>>> https://gist.github.com/hastebrot/cbca1128dd791966e3a6 >>>> PlatformFactory.instance = new MonoclePlatformFactory() >>>> NativePlatformFactory.platform = new HeadlessPlatform() >>>> } >>>> fx = new GuiTest() >>>> fx.rootNodeFactory = rootNodeFactory >>>> fx.setupGuiTest() >>>> } >>>> >>>> It works nicely until fx.clickOn is called. The TestFX library is still >>>> moving the Windows mouse! >>>> >>>> Any thoughts? >>>> >>>> >>>> Thanks, >>>> >>>> Neil >>>> >>>> >>>> >>>> >>>> From: Benjamin Gudehus >>>> To: Tom Eugelink , >>>> Cc: "openjfx-dev at openjdk.java.net" >>> > >>>> Date: 11/12/2014 03:10 AM >>>> Subject: Re: Monocle in 8u25 >>>> Sent by: "openjfx-dev" >>>> ------------------------------ >>>> >>>> >>>> >>>> >>>> That would be nice, Tom. >>>> >>>> Example usage: >>>> >>>> Since com.sun.glass.ui.PlatformFactory can't find Monocle classes from >>>> the >>>> external jars, we need to change >>>> >>>> public static void main(String[] appArgs) { >>>> Application.launch(appClass, appArgs); >>>> } >>>> >>>> to >>>> >>>> public static void main(String[] appArgs) { >>>> new ToolkitApplicationLauncher().launch(appClass, appArgs); >>>> } >>>> >>>> and start the Application with -Djavafx.monocle.headless=true. >>>> >>>> ToolkitApplicationLauncher.jar: >>>> https://gist.github.com/hastebrot/cbca1128dd791966e3a6 >>>> >>>> >>>> On Wed, Nov 12, 2014 at 8:48 AM, Tom Eugelink wrote: >>>> >>>> I can roll it out under the same name (openjfx-monocle-1.8.0_20) >>>>> within >>>>> the org.jfxtras group. Just say so. >>>>> >>>>> Tom >>>>> >>>>> >>>>> On 12-11-2014 08:30, Benjamin Gudehus wrote: >>>>> >>>>> Hi all! >>>>> >>>>> Files and instructions are available at >>>>> >>>> https://github.com/TestFX/Monocle >>>> >>>>> . >>>>> >>>>> Releases with jars: https://github.com/TestFX/Monocle/releases >>>>> >>>>> License (taken from OpenJFX respository): >>>>> https://github.com/TestFX/Monocle/blob/master/LICENSE >>>>> >>>>> Would be nice to have this available from Maven. >>>>> >>>>> --Benjamin >>>>> >>>>> On Wed, Nov 5, 2014 at 8:20 PM, Tom Eugelink wrote: >>>>> >>>>> This is extremely good news. I have no problem to "drag" that library >>>>>> along in the JFXtras project (project name seems to be a good match >>>>>> for >>>>>> this usage ;-) and release it to maven - if that is allowed by the >>>>>> >>>>> JavaFX >>>> >>>>> license. >>>>>> >>>>>> Tom >>>>>> >>>>>> >>>>>> >>>>>> On 5-11-2014 16:57, Benjamin Gudehus wrote: >>>>>> >>>>>> Hi Sean, >>>>>>> >>>>>>> I've put the Monocle sources directly in my code directories for >>>>>>> testing purposes. Putting it into a separate Jar is possible and I >>>>>>> thought that pre-compiled jars could be provided via Maven. >>>>>>> >>>>>>> I didn't do a complete OpenJFX build, because I was only interested >>>>>>> in >>>>>>> the Headless component of Monocle, i.e. I didn't needed the >>>>>>> platform-dependent dynamic libraries. >>>>>>> >>>>>>> Rough instructions were given in a previous mail. There were some >>>>>>> request to provide the pre-compoile jars so I will additionally set >>>>>>> up >>>>>>> a public repository with detailed instructions when I'm back home. >>>>>>> >>>>>>> --Benjamin >>>>>>> >>>>>>> On 11/5/14, Sean True wrote: >>>>>>> >>>>>>> Did you build the glass/ui/monocle sources into a separate jar, or >>>>>>>> >>>>>>> did >>>> >>>>> you >>>>>>>> do a complete OpenJFX build? >>>>>>>> >>>>>>>> If you did a separate build, a recipe would be extremely helpful. >>>>>>>> >>>>>>>> -- Sean >>>>>>>> >>>>>>>> On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus < >>>>>>>> >>>>>>> hastebrot at gmail.com> >>>> >>>>> wrote: >>>>>>>> >>>>>>>> I managed to run Monocle/Headless on Windows with 8u25. This will >>>>>>>> >>>>>>> allow >>>> >>>>> users to run headless tests. >>>>>>>>> >>>>>>>>> All what is needed is to copy all files from >>>>>>>>> >>>>>>>> "com/sun/glass/ui/monocle" >>>> >>>>> of >>>>>>>>> "javafx-src.zip" and add the >>>>>>>>> cursor resource files from >>>>>>>>> "modules/graphics/src/main/resources/com/sun/glass/ui/monocle" of >>>>>>>>> >>>>>>>> the >>>> >>>>> related hg tag in the OpenJFX repository [1]. >>>>>>>>> >>>>>>>>> Before Application#launch() is called we need to manually set the >>>>>>>>> >>>>>>>> Glass >>>> >>>>> and >>>>>>>>> Monocle platforms: >>>>>>>>> >>>>>>>>> accessStaticField(com.sun.glass.ui.PlatformFactory.class, >>>>>>>>> >>>>>>>> "instance", >>>> >>>>> new com.sun.glass.ui.monocle.MonoclePlatformFactory()); >>>>>>>>> >>>>>>>>> accessStaticField(com.sun.glass.ui.monocle. >>>> NativePlatformFactory.class, >>>> >>>>> "platform", >>>>>>>>> new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); >>>>>>>>> >>>>>>>>> The directory structure in 8u40 is a bit different, but there could >>>>>>>>> >>>>>>>> be >>>> >>>>> added version checks. Checking >>>>>>>>> for the JVM vars "glass.platform" and "monocle.platform" might be >>>>>>>>> >>>>>>>> also >>>> >>>>> added to this code. >>>>>>>>> >>>>>>>>> [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus < >>>>>>>>> >>>>>>>> hastebrot at gmail.com> >>>> >>>>> wrote: >>>>>>>>> >>>>>>>>> Hmm. Seems that Class.forName() in com.sun.glass.ui. >>>>>>>>> PlatformFactory >>>>>>>>> >>>>>>>>>> won't >>>>>>>>>> retrieve externally defined PlatformFactorys. So I will try to set >>>>>>>>>> >>>>>>>>> the >>>> >>>>> PlatformFactory.instance field manually, before the >>>>>>>>>> Application/Tookit/FX-Thread is launched. >>>>>>>>>> >>>>>>>>>> On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus < >>>>>>>>>> >>>>>>>>> hastebrot at gmail.com >>>> >>>>> wrote: >>>>>>>>>> >>>>>>>>>> Thank you. That makes it clearer. :) >>>>>>>>>> >>>>>>>>>>> Is it possible to supply the headless part of Monocle in an >>>>>>>>>>> >>>>>>>>>> external >>>> >>>>> Jar >>>>>>>>>>> for desktop platforms? >>>>>>>>>>> >>>>>>>>>>> As far as I know the only possibility to run TestFX tests with >>>>>>>>>>> Hudson/Jenkins is in headless mode. >>>>>>>>>>> TestFX's tests itself can only run with the X virtual framebuffer >>>>>>>>>>> >>>>>>>>>> on >>>> >>>>> Linux test clients for the Travis CI so far. >>>>>>>>>>> >>>>>>>>>>> So far the only advice I could give TestFX users who like to run >>>>>>>>>>> >>>>>>>>>>> headless >>>>>>>>>> tests is to use 1.8.0_20-ea-b05. >>>>>>>>>> >>>>>>>>> >>>> >>>> >>>> NOTICE *from Ab Initio: This email (including any attachments) may >>>> contain information that is subject to confidentiality obligations or is >>>> legally privileged, and sender does not waive confidentiality or >>>> privilege. >>>> If received in error, please notify the sender, delete this email, and >>>> make >>>> no further use, disclosure, or distribution. * >>>> >>> >>> >>> > From philip.race at oracle.com Thu Nov 13 23:15:14 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 13 Nov 2014 15:15:14 -0800 Subject: Dumping the rendering process in JavaFX In-Reply-To: <54653591.8000803@oracle.com> References: <54653591.8000803@oracle.com> Message-ID: <54653B82.4060503@oracle.com> Basically for printing we had to detect that we were printing and use a non-cached texture. If you look for references to "PrinterGraphics" you might find some of them. Canvas is one place we had to deal with this. There are at least one or two others. Doing anything like only this via public API is probably an insurmountable challenge. -phil. On 11/13/14 2:49 PM, Kevin Rushforth wrote: > You could take a look at what JavaFX internally does for printing, > which is similar to what you are trying to do. It also forces the J2D > pipeline and had to deal with this issue. You likely won't be able to > do it without modifying FX internals, though, which is what printing > does in a few places. > > -- Kevin > > > Herve Girod wrote: >> Hello, >> >> I think that more than one year ago, I asked if it was possible to >> dump the >> JavaFX rendering process. More than one year later, I (or we, for I am >> speaking on behalf of my project) are almost there. We use this in a >> library for a "JavaFX to any format you want" converter. For example >> we are >> currently able to convert a live JavaFX image to a PowerPoint slider >> (using >> POI), or we also could do the same with a WMF / EMF / SVG image, keeping >> the vector content of course. >> >> What we did is hacking the J2DPrismGraphics class to render it in a >> custom >> Graphics2D context which in turn can be a PPT / SVG / WMF / or EMF >> serializer. >> >> Our use case is the use of JavaFX in an Editor (no it's not a JavaFX >> Editor, we edit graphic specifications for an avionics standard called >> ARINC 661), and the ability to produce another Vector format with >> exactly >> the same UI. >> >> It works very well, except that of course we had to hack a few JavaFX >> core >> classes to do that (obviously J2DPrismGraphics was not designed to allow >> this). We did not recompile the core library, it's just separate classes >> which uses com.sun classes when possible, or we used >> PrivilegedActions when >> a method we needed was package protected. >> >> But we have still a big problem (I think that it might be the only one, >> except for the fact that our solution is an ugly hack, as you can see): >> >> There is still one case where our solution does not work: Textures. >> In fact >> we would have been able to convert JavaFX textures to BufferedImages >> if we >> could use the Java2D-based Texture class, but of course as we did >> nothing >> special, we encounter a D3D Texture (for example on Windows) which we >> don't >> know how to deal with. >> >> Which leads me to my two questions: >> >> - Is there a programmatic way (even a contorted one) to force JavaFX >> to use >> our own specific Pipeline (the idea is to be able to do this temporarily >> when serializing the JavaFX content, so without having to use command >> line >> argument) >> >> - I think that it could be very useful to have a neutral and JavaFX - >> supported way for developers to use their own Pipeline, even if it was >> limited and with a lower than average performance. Being able to convert >> from / to the JavaFX format is something that can be very useful. >> >> Herv? From herve.girod at gmail.com Thu Nov 13 23:31:15 2014 From: herve.girod at gmail.com (Herve Girod) Date: Fri, 14 Nov 2014 00:31:15 +0100 Subject: Dumping the rendering process in JavaFX In-Reply-To: <54653B82.4060503@oracle.com> References: <54653591.8000803@oracle.com> <54653B82.4060503@oracle.com> Message-ID: Thanks for you two, I will try this tomorrow - I'm in France so it's late now ;) Our project is Open Source, but this functionality is not central to it, I will extract this on another Open Source project then after it's done, this could be useful to other devs think. Herv? 2014-11-14 0:15 GMT+01:00 Phil Race : > Basically for printing we had to detect that we were printing and use a > non-cached texture. > If you look for references to "PrinterGraphics" you might find some of > them. > Canvas is one place we had to deal with this. There are at least one or > two others. > Doing anything like only this via public API is probably an insurmountable > challenge. > > -phil. > > > On 11/13/14 2:49 PM, Kevin Rushforth wrote: > >> You could take a look at what JavaFX internally does for printing, which >> is similar to what you are trying to do. It also forces the J2D pipeline >> and had to deal with this issue. You likely won't be able to do it without >> modifying FX internals, though, which is what printing does in a few places. >> >> -- Kevin >> >> >> Herve Girod wrote: >> >>> Hello, >>> >>> I think that more than one year ago, I asked if it was possible to dump >>> the >>> JavaFX rendering process. More than one year later, I (or we, for I am >>> speaking on behalf of my project) are almost there. We use this in a >>> library for a "JavaFX to any format you want" converter. For example we >>> are >>> currently able to convert a live JavaFX image to a PowerPoint slider >>> (using >>> POI), or we also could do the same with a WMF / EMF / SVG image, keeping >>> the vector content of course. >>> >>> What we did is hacking the J2DPrismGraphics class to render it in a >>> custom >>> Graphics2D context which in turn can be a PPT / SVG / WMF / or EMF >>> serializer. >>> >>> Our use case is the use of JavaFX in an Editor (no it's not a JavaFX >>> Editor, we edit graphic specifications for an avionics standard called >>> ARINC 661), and the ability to produce another Vector format with exactly >>> the same UI. >>> >>> It works very well, except that of course we had to hack a few JavaFX >>> core >>> classes to do that (obviously J2DPrismGraphics was not designed to allow >>> this). We did not recompile the core library, it's just separate classes >>> which uses com.sun classes when possible, or we used PrivilegedActions >>> when >>> a method we needed was package protected. >>> >>> But we have still a big problem (I think that it might be the only one, >>> except for the fact that our solution is an ugly hack, as you can see): >>> >>> There is still one case where our solution does not work: Textures. In >>> fact >>> we would have been able to convert JavaFX textures to BufferedImages if >>> we >>> could use the Java2D-based Texture class, but of course as we did nothing >>> special, we encounter a D3D Texture (for example on Windows) which we >>> don't >>> know how to deal with. >>> >>> Which leads me to my two questions: >>> >>> - Is there a programmatic way (even a contorted one) to force JavaFX to >>> use >>> our own specific Pipeline (the idea is to be able to do this temporarily >>> when serializing the JavaFX content, so without having to use command >>> line >>> argument) >>> >>> - I think that it could be very useful to have a neutral and JavaFX - >>> supported way for developers to use their own Pipeline, even if it was >>> limited and with a lower than average performance. Being able to convert >>> from / to the JavaFX format is something that can be very useful. >>> >>> Herv? >>> >> > From james.graham at oracle.com Fri Nov 14 01:29:57 2014 From: james.graham at oracle.com (Jim Graham) Date: Thu, 13 Nov 2014 17:29:57 -0800 Subject: Dumping the rendering process in JavaFX In-Reply-To: <54653B82.4060503@oracle.com> References: <54653591.8000803@oracle.com> <54653B82.4060503@oracle.com> Message-ID: <54655B15.70403@oracle.com> Some pie in the sky observations about the background here... Note that there was a fine line there that had to be evaluated. Many of the printing detection changes were basically just "Oh, look, I have a new ResourceFactory now, that probably means new Textures", but it was tempered with "One might think to permanently shift over to the resources from this new factory, but if we're just printing, we are probably going to switch right back to a screen factory so any permanent changes of internal state are likely unwarranted". On the other hand, sometimes when you print a scene, it was specially created just for the printing process so the initial ResourceFactory it sees is likely the only one it will ever see (and then the tree will be tossed). It would be nice if we could generalize this or switch the way we manage resource states in the NGNode tree so that this was both flexible for switching seamlessly to a new resource factory/pool and flexibly dealt with the temporary/permanent nature of why those differences might come up (in other words, dynamically use and cache new resources without alienating or losing track of old ones unless that old pipeline/RF is going away). Right now there aren't any on-screen related changes that might require us to permanently switch pipelines/resource factories (not entirely sure about management of D3D resources when we lose access to the screen, though) and printing is really the only use case where we ever even see a new ResourceFactory. But, who knows what the future may bring and making assumptions about the RF being a constant throughout the app life cycle are not necessarily the best implementation practice in the long run... Have fun! ;) ...jim On 11/13/14 3:15 PM, Phil Race wrote: > Basically for printing we had to detect that we were printing and use a > non-cached texture. > If you look for references to "PrinterGraphics" you might find some of > them. > Canvas is one place we had to deal with this. There are at least one or > two others. > Doing anything like only this via public API is probably an > insurmountable challenge. > > -phil. > > On 11/13/14 2:49 PM, Kevin Rushforth wrote: >> You could take a look at what JavaFX internally does for printing, >> which is similar to what you are trying to do. It also forces the J2D >> pipeline and had to deal with this issue. You likely won't be able to >> do it without modifying FX internals, though, which is what printing >> does in a few places. >> >> -- Kevin >> >> >> Herve Girod wrote: >>> Hello, >>> >>> I think that more than one year ago, I asked if it was possible to >>> dump the >>> JavaFX rendering process. More than one year later, I (or we, for I am >>> speaking on behalf of my project) are almost there. We use this in a >>> library for a "JavaFX to any format you want" converter. For example >>> we are >>> currently able to convert a live JavaFX image to a PowerPoint slider >>> (using >>> POI), or we also could do the same with a WMF / EMF / SVG image, keeping >>> the vector content of course. >>> >>> What we did is hacking the J2DPrismGraphics class to render it in a >>> custom >>> Graphics2D context which in turn can be a PPT / SVG / WMF / or EMF >>> serializer. >>> >>> Our use case is the use of JavaFX in an Editor (no it's not a JavaFX >>> Editor, we edit graphic specifications for an avionics standard called >>> ARINC 661), and the ability to produce another Vector format with >>> exactly >>> the same UI. >>> >>> It works very well, except that of course we had to hack a few JavaFX >>> core >>> classes to do that (obviously J2DPrismGraphics was not designed to allow >>> this). We did not recompile the core library, it's just separate classes >>> which uses com.sun classes when possible, or we used >>> PrivilegedActions when >>> a method we needed was package protected. >>> >>> But we have still a big problem (I think that it might be the only one, >>> except for the fact that our solution is an ugly hack, as you can see): >>> >>> There is still one case where our solution does not work: Textures. >>> In fact >>> we would have been able to convert JavaFX textures to BufferedImages >>> if we >>> could use the Java2D-based Texture class, but of course as we did >>> nothing >>> special, we encounter a D3D Texture (for example on Windows) which we >>> don't >>> know how to deal with. >>> >>> Which leads me to my two questions: >>> >>> - Is there a programmatic way (even a contorted one) to force JavaFX >>> to use >>> our own specific Pipeline (the idea is to be able to do this temporarily >>> when serializing the JavaFX content, so without having to use command >>> line >>> argument) >>> >>> - I think that it could be very useful to have a neutral and JavaFX - >>> supported way for developers to use their own Pipeline, even if it was >>> limited and with a lower than average performance. Being able to convert >>> from / to the JavaFX format is something that can be very useful. >>> >>> Herv? > From felix.bembrick at gmail.com Fri Nov 14 03:34:33 2014 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Fri, 14 Nov 2014 14:34:33 +1100 Subject: What Scene Builder needs YESTERDAY! Message-ID: Java applets were the first "programs" to run inside a web browser and for a (little) while they were flavour of the month. But then along came Flash which had several advantages such as faster load times, consistent loads and antialiased fonts/graphics and soon completely surpassed applets. But the MAIN reason why Flash was initially so successful and went on for years and years of domination is that the Flash tools had an Animation/Timeline Editor pretty much from the beginning. This enabled even a novice to drag images around and draw the path they wanted them to move along, add all sorts of bouncing effects and sounds and the result was the birth of the online greeting card company. But Flash soon went on to be so much more. As the Adobe tools improved, so did the SWFs and soon entire websites were written in Flash. Meanwhile, applet programmers had absolutely nothing remotely similar and had to try (and I stress try) to tediously hand code any animations and transitions and effects and I don't think it ever worked. Fast forward 15-20 years and now we have JavaFX which doesn't need to run in the browser, has even more features than Flash, uses hardware acceleration for superior performance, has a wide range of built-in animations, transitions and effects but STILL we have to hand code any animation/transitions. This is INCREDIBLY inefficient and unless Scene Builder incorporates a powerful, sophisticated animation/transition and effect editor VERY, VERY SOON I fear that the advanced graphics features are never going to be used to their full potential (much to the detriment of JavaFX itself). Does anyone know if one is in the pipeline? I see this as one of the most vital features for the JavaFX ecosystem to achieve more penetration and, eventually, survive. Felix From tbee at tbee.org Fri Nov 14 06:20:44 2014 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 14 Nov 2014 07:20:44 +0100 Subject: Monocle in 8u25 In-Reply-To: References: <54591A31.1070709@oracle.com> <545A788D.9030509@tbee.org> <546310E1.8000702@tbee.org> <546523B9.5040207@tbee.org> Message-ID: <54659F3C.8090601@tbee.org> I'll change it for the next release to something less personal. :-) Tom On 14-11-2014 00:00, Benjamin Gudehus wrote: > Maybe we could use "The TestFX contributors" as "developers"? > > On Thu, Nov 13, 2014 at 10:33 PM, Tom Eugelink > wrote: > > A developer is mandatory, your name is as good as any? > > Tom > > > > On 13-11-2014 22:06, Benjamin Gudehus wrote: > > @Tom Thanks for the patch. Will apply it soon. > Is there something like a package maintainer field for Maven? I think > developer is a bit too pompous; I didn't touch the code. > > On Thu, Nov 13, 2014 at 10:01 PM, Benjamin Gudehus > > wrote: > > Hi Neil! > > The TestFX library is still moving the Windows mouse! > > TestFX is using Awt's robot. This robot ignores Glass/Monocle and controls > the OS's cursor. > We need to replace it with Glass' robot. I already tested it and it works > fine. > PR will be ready soon. This PR will also replace the Awt screenshot > mechanism with the one > from the Glass robot. I hoped that this will also take screenshots wenn > running in headless mode. > But unfortunately the screenshots were empty. I saw in Monocle's source > code, that it writes > color values into an internal byte stream, so it actually should work. > > Also very nice to see, that people are using bleeding edge version of > TestFX. :) > TestFX will also have better Spock/Groovy support in the future. > > --Benjamin > > > On Thu, Nov 13, 2014 at 9:38 PM, > wrote: > > Hi Benjamin, > > We are using Spock for testing, and have modified the setupStage() method > to support optional headless testing with Monocle, > which is working well on Windows (the code is in groovy): > > void setupStage(Closure rootNodeFactory) > { > if (fx == null && isHeadless) > { > // Cribbed from: > https://gist.github.com/hastebrot/cbca1128dd791966e3a6 > PlatformFactory.instance = new MonoclePlatformFactory() > NativePlatformFactory.platform = new HeadlessPlatform() > } > fx = new GuiTest() > fx.rootNodeFactory = rootNodeFactory > fx.setupGuiTest() > } > > It works nicely until fx.clickOn is called. The TestFX library is still > moving the Windows mouse! > > Any thoughts? > > > Thanks, > > Neil > > > > > From: Benjamin Gudehus > > To: Tom Eugelink >, > Cc: "openjfx-dev at openjdk.java.net " > > Date: 11/12/2014 03:10 AM > Subject: Re: Monocle in 8u25 > Sent by: "openjfx-dev" > > ------------------------------ > > > > > That would be nice, Tom. > > Example usage: > > Since com.sun.glass.ui.PlatformFactory can't find Monocle classes from the > external jars, we need to change > > public static void main(String[] appArgs) { > Application.launch(appClass, appArgs); > } > > to > > public static void main(String[] appArgs) { > new ToolkitApplicationLauncher().launch(appClass, appArgs); > } > > and start the Application with -Djavafx.monocle.headless=true. > > ToolkitApplicationLauncher.jar: > https://gist.github.com/hastebrot/cbca1128dd791966e3a6 > > > On Wed, Nov 12, 2014 at 8:48 AM, Tom Eugelink > wrote: > > I can roll it out under the same name (openjfx-monocle-1.8.0_20) within > the org.jfxtras group. Just say so. > > Tom > > > On 12-11-2014 08:30, Benjamin Gudehus wrote: > > Hi all! > > Files and instructions are available at > > https://github.com/TestFX/Monocle > > . > > Releases with jars: https://github.com/TestFX/Monocle/releases > > License (taken from OpenJFX respository): > https://github.com/TestFX/Monocle/blob/master/LICENSE > > Would be nice to have this available from Maven. > > --Benjamin > > On Wed, Nov 5, 2014 at 8:20 PM, Tom Eugelink > wrote: > > This is extremely good news. I have no problem to "drag" that library > along in the JFXtras project (project name seems to be a good match for > this usage ;-) and release it to maven - if that is allowed by the > > JavaFX > > license. > > Tom > > > > On 5-11-2014 16:57, Benjamin Gudehus wrote: > > Hi Sean, > > I've put the Monocle sources directly in my code directories for > testing purposes. Putting it into a separate Jar is possible and I > thought that pre-compiled jars could be provided via Maven. > > I didn't do a complete OpenJFX build, because I was only interested in > the Headless component of Monocle, i.e. I didn't needed the > platform-dependent dynamic libraries. > > Rough instructions were given in a previous mail. There were some > request to provide the pre-compoile jars so I will additionally set up > a public repository with detailed instructions when I'm back home. > > --Benjamin > > On 11/5/14, Sean True > wrote: > > Did you build the glass/ui/monocle sources into a separate jar, or > > did > > you > do a complete OpenJFX build? > > If you did a separate build, a recipe would be extremely helpful. > > -- Sean > > On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus < > > hastebrot at gmail.com > > > wrote: > > I managed to run Monocle/Headless on Windows with 8u25. This will > > allow > > users to run headless tests. > > All what is needed is to copy all files from > > "com/sun/glass/ui/monocle" > > of > "javafx-src.zip" and add the > cursor resource files from > "modules/graphics/src/main/resources/com/sun/glass/ui/monocle" of > > the > > related hg tag in the OpenJFX repository [1]. > > Before Application#launch() is called we need to manually set the > > Glass > > and > Monocle platforms: > > accessStaticField(com.sun.glass.ui.PlatformFactory.class, > > "instance", > > new com.sun.glass.ui.monocle.MonoclePlatformFactory()); > > accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class, > > "platform", > new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); > > The directory structure in 8u40 is a bit different, but there could > > be > > added version checks. Checking > for the JVM vars "glass.platform" and "monocle.platform" might be > > also > > added to this code. > > [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags > > > On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus < > > hastebrot at gmail.com > > > wrote: > > Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory > > won't > retrieve externally defined PlatformFactorys. So I will try to set > > the > > PlatformFactory.instance field manually, before the > Application/Tookit/FX-Thread is launched. > > On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus < > > hastebrot at gmail.com > > wrote: > > Thank you. That makes it clearer. :) > > Is it possible to supply the headless part of Monocle in an > > external > > Jar > for desktop platforms? > > As far as I know the only possibility to run TestFX tests with > Hudson/Jenkins is in headless mode. > TestFX's tests itself can only run with the X virtual framebuffer > > on > > Linux test clients for the Travis CI so far. > > So far the only advice I could give TestFX users who like to run > > headless > tests is to use 1.8.0_20-ea-b05. > > > > > NOTICE *from Ab Initio: This email (including any attachments) may > contain information that is subject to confidentiality obligations or is > legally privileged, and sender does not waive confidentiality or privilege. > If received in error, please notify the sender, delete this email, and make > no further use, disclosure, or distribution. * > > > > > From tbee at tbee.org Fri Nov 14 06:21:38 2014 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 14 Nov 2014 07:21:38 +0100 Subject: Monocle in 8u25 In-Reply-To: References: <54591A31.1070709@oracle.com> <545A788D.9030509@tbee.org> <546310E1.8000702@tbee.org> <546523B9.5040207@tbee.org> Message-ID: <54659F72.7020603@tbee.org> Should we roll out a openjfx-monocle-1.8.0_40-SNAPSHOT? Tom On 14-11-2014 00:00, Benjamin Gudehus wrote: > Maybe we could use "The TestFX contributors" as "developers"? > > On Thu, Nov 13, 2014 at 10:33 PM, Tom Eugelink > wrote: > > A developer is mandatory, your name is as good as any? > > Tom > > > > On 13-11-2014 22:06, Benjamin Gudehus wrote: > > @Tom Thanks for the patch. Will apply it soon. > Is there something like a package maintainer field for Maven? I think > developer is a bit too pompous; I didn't touch the code. > > On Thu, Nov 13, 2014 at 10:01 PM, Benjamin Gudehus > > wrote: > > Hi Neil! > > The TestFX library is still moving the Windows mouse! > > TestFX is using Awt's robot. This robot ignores Glass/Monocle and controls > the OS's cursor. > We need to replace it with Glass' robot. I already tested it and it works > fine. > PR will be ready soon. This PR will also replace the Awt screenshot > mechanism with the one > from the Glass robot. I hoped that this will also take screenshots wenn > running in headless mode. > But unfortunately the screenshots were empty. I saw in Monocle's source > code, that it writes > color values into an internal byte stream, so it actually should work. > > Also very nice to see, that people are using bleeding edge version of > TestFX. :) > TestFX will also have better Spock/Groovy support in the future. > > --Benjamin > > > On Thu, Nov 13, 2014 at 9:38 PM, > wrote: > > Hi Benjamin, > > We are using Spock for testing, and have modified the setupStage() method > to support optional headless testing with Monocle, > which is working well on Windows (the code is in groovy): > > void setupStage(Closure rootNodeFactory) > { > if (fx == null && isHeadless) > { > // Cribbed from: > https://gist.github.com/hastebrot/cbca1128dd791966e3a6 > PlatformFactory.instance = new MonoclePlatformFactory() > NativePlatformFactory.platform = new HeadlessPlatform() > } > fx = new GuiTest() > fx.rootNodeFactory = rootNodeFactory > fx.setupGuiTest() > } > > It works nicely until fx.clickOn is called. The TestFX library is still > moving the Windows mouse! > > Any thoughts? > > > Thanks, > > Neil > > > > > From: Benjamin Gudehus > > To: Tom Eugelink >, > Cc: "openjfx-dev at openjdk.java.net " > > Date: 11/12/2014 03:10 AM > Subject: Re: Monocle in 8u25 > Sent by: "openjfx-dev" > > ------------------------------ > > > > > That would be nice, Tom. > > Example usage: > > Since com.sun.glass.ui.PlatformFactory can't find Monocle classes from the > external jars, we need to change > > public static void main(String[] appArgs) { > Application.launch(appClass, appArgs); > } > > to > > public static void main(String[] appArgs) { > new ToolkitApplicationLauncher().launch(appClass, appArgs); > } > > and start the Application with -Djavafx.monocle.headless=true. > > ToolkitApplicationLauncher.jar: > https://gist.github.com/hastebrot/cbca1128dd791966e3a6 > > > On Wed, Nov 12, 2014 at 8:48 AM, Tom Eugelink > wrote: > > I can roll it out under the same name (openjfx-monocle-1.8.0_20) within > the org.jfxtras group. Just say so. > > Tom > > > On 12-11-2014 08:30, Benjamin Gudehus wrote: > > Hi all! > > Files and instructions are available at > > https://github.com/TestFX/Monocle > > . > > Releases with jars: https://github.com/TestFX/Monocle/releases > > License (taken from OpenJFX respository): > https://github.com/TestFX/Monocle/blob/master/LICENSE > > Would be nice to have this available from Maven. > > --Benjamin > > On Wed, Nov 5, 2014 at 8:20 PM, Tom Eugelink > wrote: > > This is extremely good news. I have no problem to "drag" that library > along in the JFXtras project (project name seems to be a good match for > this usage ;-) and release it to maven - if that is allowed by the > > JavaFX > > license. > > Tom > > > > On 5-11-2014 16:57, Benjamin Gudehus wrote: > > Hi Sean, > > I've put the Monocle sources directly in my code directories for > testing purposes. Putting it into a separate Jar is possible and I > thought that pre-compiled jars could be provided via Maven. > > I didn't do a complete OpenJFX build, because I was only interested in > the Headless component of Monocle, i.e. I didn't needed the > platform-dependent dynamic libraries. > > Rough instructions were given in a previous mail. There were some > request to provide the pre-compoile jars so I will additionally set up > a public repository with detailed instructions when I'm back home. > > --Benjamin > > On 11/5/14, Sean True > wrote: > > Did you build the glass/ui/monocle sources into a separate jar, or > > did > > you > do a complete OpenJFX build? > > If you did a separate build, a recipe would be extremely helpful. > > -- Sean > > On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus < > > hastebrot at gmail.com > > > wrote: > > I managed to run Monocle/Headless on Windows with 8u25. This will > > allow > > users to run headless tests. > > All what is needed is to copy all files from > > "com/sun/glass/ui/monocle" > > of > "javafx-src.zip" and add the > cursor resource files from > "modules/graphics/src/main/resources/com/sun/glass/ui/monocle" of > > the > > related hg tag in the OpenJFX repository [1]. > > Before Application#launch() is called we need to manually set the > > Glass > > and > Monocle platforms: > > accessStaticField(com.sun.glass.ui.PlatformFactory.class, > > "instance", > > new com.sun.glass.ui.monocle.MonoclePlatformFactory()); > > accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class, > > "platform", > new com.sun.glass.ui.monocle.headless.HeadlessPlatform()); > > The directory structure in 8u40 is a bit different, but there could > > be > > added version checks. Checking > for the JVM vars "glass.platform" and "monocle.platform" might be > > also > > added to this code. > > [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags > > > On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus < > > hastebrot at gmail.com > > > wrote: > > Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory > > won't > retrieve externally defined PlatformFactorys. So I will try to set > > the > > PlatformFactory.instance field manually, before the > Application/Tookit/FX-Thread is launched. > > On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus < > > hastebrot at gmail.com > > wrote: > > Thank you. That makes it clearer. :) > > Is it possible to supply the headless part of Monocle in an > > external > > Jar > for desktop platforms? > > As far as I know the only possibility to run TestFX tests with > Hudson/Jenkins is in headless mode. > TestFX's tests itself can only run with the X virtual framebuffer > > on > > Linux test clients for the Travis CI so far. > > So far the only advice I could give TestFX users who like to run > > headless > tests is to use 1.8.0_20-ea-b05. > > > > > NOTICE *from Ab Initio: This email (including any attachments) may > contain information that is subject to confidentiality obligations or is > legally privileged, and sender does not waive confidentiality or privilege. > If received in error, please notify the sender, delete this email, and make > no further use, disclosure, or distribution. * > > > > > From anton.tarasov at oracle.com Fri Nov 14 12:41:04 2014 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 14 Nov 2014 16:41:04 +0400 Subject: [8u40] Review request: RT-39392 [WebView] DEBUG build fails with unresolved symbols Message-ID: <5465F860.9030308@oracle.com> Leonid, Please, review the fix: https://javafx-jira.kenai.com/browse/RT-39392 http://cr.openjdk.java.net/~ant/RT-39392/webrev.0 It fixes the WebView DEBUG build failure on Windows. Thanks, Anton. From ngalarneau at ABINITIO.COM Fri Nov 14 14:10:37 2014 From: ngalarneau at ABINITIO.COM (ngalarneau at ABINITIO.COM) Date: Fri, 14 Nov 2014 09:10:37 -0500 Subject: Monocle in 8u25 In-Reply-To: <54659F72.7020603@tbee.org> References: <545A788D.9030509@tbee.org> <546310E1.8000702@tbee.org> Message-ID: That would be great. Neil From: Tom Eugelink To: Benjamin Gudehus , Cc: "openjfx-dev at openjdk.java.net" Date: 11/14/2014 01:22 AM Subject: Re: Monocle in 8u25 Sent by: "openjfx-dev" Should we roll out a openjfx-monocle-1.8.0_40-SNAPSHOT? Tom On 14-11-2014 00:00, Benjamin Gudehus wrote: > Maybe we could use "The TestFX contributors" as "developers"? > > On Thu, Nov 13, 2014 at 10:33 PM, Tom Eugelink > wrote: > > A developer is mandatory, your name is as good as any? > > Tom > > > > On 13-11-2014 22:06, Benjamin Gudehus wrote: > > @Tom Thanks for the patch. Will apply it soon. > Is there something like a package maintainer field for Maven? I think > developer is a bit too pompous; I didn't touch the code. > > On Thu, Nov 13, 2014 at 10:01 PM, Benjamin Gudehus > > wrote: > > Hi Neil! > > The TestFX library is still moving the Windows mouse! > > TestFX is using Awt's robot. This robot ignores Glass/Monocle and controls > the OS's cursor. > We need to replace it with Glass' robot. I already tested it and it works > fine. > PR will be ready soon. This PR will also replace the Awt screenshot > mechanism with the one > from the Glass robot. I hoped that this will also take screenshots wenn > running in headless mode. > But unfortunately the screenshots were empty. I saw in Monocle's source > code, that it writes > color values into an internal byte stream, so it actually should work. > > Also very nice to see, that people are using bleeding edge version of > TestFX. :) > TestFX will also have better Spock/Groovy support in the future. > > --Benjamin > > > On Thu, Nov 13, 2014 at 9:38 PM, > wrote: > > Hi Benjamin, > > We are using Spock for testing, and have modified the setupStage() method > to support optional headless testing with Monocle, > which is working well on Windows (the code is in groovy): > > void setupStage(Closure rootNodeFactory) > { > if (fx == null && isHeadless) > { > // Cribbed from: > https://gist.github.com/hastebrot/cbca1128dd791966e3a6 > PlatformFactory.instance = new MonoclePlatformFactory() > NativePlatformFactory.platform = new HeadlessPlatform() > } > fx = new GuiTest() > fx.rootNodeFactory = rootNodeFactory > fx.setupGuiTest() > } > > It works nicely until fx.clickOn is called. The TestFX library is still > moving the Windows mouse! > > Any thoughts? > > > Thanks, > > Neil > > > > > From: Benjamin Gudehus > > To: Tom Eugelink >, > Cc: "openjfx-dev at openjdk.java.net < mailto:openjfx-dev at openjdk.java.net>" > > Date: 11/12/2014 03:10 AM > Subject: Re: Monocle in 8u25 > Sent by: "openjfx-dev" > > ------------------------------ > > > > > That would be nice, Tom. > > Example usage: > > Since com.sun.glass.ui.PlatformFactory can't find Monocle classes from the > external jars, we need to change > > public static void main(String[] appArgs) { > Application.launch(appClass, appArgs); > } > > to > > public static void main(String[] appArgs) { > new ToolkitApplicationLauncher().launch(appClass, appArgs); > } > > and start the Application with -Djavafx.monocle.headless=true. > > ToolkitApplicationLauncher.jar: > https://gist.github.com/hastebrot/cbca1128dd791966e3a6 > > > On Wed, Nov 12, 2014 at 8:48 AM, Tom Eugelink > wrote: > > I can roll it out under the same name (openjfx-monocle-1.8.0_20) within > the org.jfxtras group. Just say so. > > Tom > > > On 12-11-2014 08:30, Benjamin Gudehus wrote: > > Hi all! > > Files and instructions are available at > > https://github.com/TestFX/Monocle > > . > > Releases with jars: https://github.com/TestFX/Monocle/releases > > License (taken from OpenJFX respository): > https://github.com/TestFX/Monocle/blob/master/LICENSE > > Would be nice to have this available from Maven. > > --Benjamin > > On Wed, Nov 5, 2014 at 8:20 PM, Tom Eugelink > wrote: > > This is extremely good news. I have no problem to "drag" that library > along in the JFXtras project (project name seems to be a good match for > this usage ;-) and release it to maven - if that is allowed by the > > JavaFX > > license. > > Tom > > > > On 5-11-2014 16:57, Benjamin Gudehus wrote: > > Hi Sean, > > I've put the Monocle sources directly in my code directories for > testing purposes. Putting it into a separate Jar is possible and I > thought that pre-compiled jars could be provided via Maven. > > I didn't do a complete OpenJFX build, because I was only interested in > the Headless component of Monocle, i.e. I didn't needed the > platform-dependent dynamic libraries. > > Rough instructions were given in a previous mail. There were some > request to provide the pre-compoile jars so I will additionally set up > a public repository with detailed instructions when I'm back home. > > --Benjamin > NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution. From jeff at reportmill.com Fri Nov 14 14:24:41 2014 From: jeff at reportmill.com (Jeff Martin) Date: Fri, 14 Nov 2014 08:24:41 -0600 Subject: What Scene Builder needs YESTERDAY! In-Reply-To: References: Message-ID: <258792E3-8160-427B-B066-FFD710B7DED6@reportmill.com> I think this was true back when Java was a contender for browser graphics. It?s clear now that Java in the browser, and even Flash, are going away. Now I think the best opportunity for JavaFX is for rich, cross-platform, non-browser apps - which really means desktop enterprise apps. Very limiting - until JavaFX has a mobile story. For this I think JavaFX needs an application like Microsoft Access or Oracle ADF as opposed to a FlashDesigner app (though that wouldn?t hurt). Having a top-teir mobile story is really the only hope to have JavaFX go mainstream. It would be nice if Oracle would buy RoboVM. :-) jeff On Nov 13, 2014, at 9:34 PM, Felix Bembrick wrote: > Java applets were the first "programs" to run inside a web browser and for > a (little) while they were flavour of the month. > > But then along came Flash which had several advantages such as faster load > times, consistent loads and antialiased fonts/graphics and soon completely > surpassed applets. > > But the MAIN reason why Flash was initially so successful and went on for > years and years of domination is that the Flash tools had an > Animation/Timeline Editor pretty much from the beginning. This enabled > even a novice to drag images around and draw the path they wanted them to > move along, add all sorts of bouncing effects and sounds and the result was > the birth of the online greeting card company. > > But Flash soon went on to be so much more. As the Adobe tools improved, so > did the SWFs and soon entire websites were written in Flash. > > Meanwhile, applet programmers had absolutely nothing remotely similar and > had to try (and I stress try) to tediously hand code any animations and > transitions and effects and I don't think it ever worked. > > Fast forward 15-20 years and now we have JavaFX which doesn't need to run > in the browser, has even more features than Flash, uses hardware > acceleration for superior performance, has a wide range of built-in > animations, transitions and effects but STILL we have to hand code any > animation/transitions. > > This is INCREDIBLY inefficient and unless Scene Builder incorporates a > powerful, sophisticated animation/transition and effect editor VERY, VERY > SOON I fear that the advanced graphics features are never going to be used > to their full potential (much to the detriment of JavaFX itself). > > Does anyone know if one is in the pipeline? I see this as one of the most > vital features for the JavaFX ecosystem to achieve more penetration and, > eventually, survive. > > Felix From alexander.zvegintsev at oracle.com Fri Nov 14 16:33:58 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 14 Nov 2014 19:33:58 +0300 Subject: [8u40] Review request RT-39233: Glass/GTK should support removing Window.MINIMIZABLE, Window.MAXIMIZABLE Message-ID: <54662EF6.3040806@oracle.com> Hello David, please review the fix http://cr.openjdk.java.net/~azvegint/fx/8u40/39233/00/ for the issue https://javafx-jira.kenai.com/browse/RT-39233 -- Thanks, Alexander. From alexander.zvegintsev at oracle.com Fri Nov 14 16:34:20 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 14 Nov 2014 19:34:20 +0300 Subject: [8u40] Review request for RT-35310: [Stage, Linux] In HelloSanity, the 'Back from minimize' button does not restore the stage Message-ID: <54662F0C.3000104@oracle.com> Hello David, please review the fix http://cr.openjdk.java.net/~azvegint/fx/8u40/35310/00/ for the issue https://javafx-jira.kenai.com/browse/RT-35310 -- Thanks, Alexander. From david.dehaven at oracle.com Fri Nov 14 17:03:21 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 14 Nov 2014 09:03:21 -0800 Subject: RFR: [8u40] RT-37125: setjmp/longjmp changes the process signal mask on OS X Message-ID: <11DD431B-BB28-4643-9F67-7B819D228DDD@oracle.com> Kevin and Jim, please review a fairly trivial change for 8u40. Diff is in the JIRA comments, no webrev: https://javafx-jira.kenai.com/browse/RT-37125 -DrD- From ngalarneau at ABINITIO.COM Fri Nov 14 18:48:13 2014 From: ngalarneau at ABINITIO.COM (ngalarneau at ABINITIO.COM) Date: Fri, 14 Nov 2014 13:48:13 -0500 Subject: What Scene Builder needs YESTERDAY! In-Reply-To: <258792E3-8160-427B-B066-FFD710B7DED6@reportmill.com> References: <258792E3-8160-427B-B066-FFD710B7DED6@reportmill.com> Message-ID: I think there is an opportunity for JavaFX to replace enterprise Flex apps. How big that opportunity is, I couldn't say. It would be great if, when the 64-bit ARM port[1] is finished, Oracle offered a "64-bit ARM with JavaFX on iOS & Android" offering. Neil 1 - https://blogs.oracle.com/henrik/entry/oracle_jdk_on_64_bit From: Jeff Martin To: Felix Bembrick , Cc: "openjfx-dev at openjdk.java.net List" Date: 11/14/2014 09:25 AM Subject: Re: What Scene Builder needs YESTERDAY! Sent by: "openjfx-dev" I think this was true back when Java was a contender for browser graphics. It?s clear now that Java in the browser, and even Flash, are going away. Now I think the best opportunity for JavaFX is for rich, cross-platform, non-browser apps - which really means desktop enterprise apps. Very limiting - until JavaFX has a mobile story. For this I think JavaFX needs an application like Microsoft Access or Oracle ADF as opposed to a FlashDesigner app (though that wouldn?t hurt). Having a top-teir mobile story is really the only hope to have JavaFX go mainstream. It would be nice if Oracle would buy RoboVM. :-) jeff On Nov 13, 2014, at 9:34 PM, Felix Bembrick wrote: > Java applets were the first "programs" to run inside a web browser and for > a (little) while they were flavour of the month. > > But then along came Flash which had several advantages such as faster load > times, consistent loads and antialiased fonts/graphics and soon completely > surpassed applets. > > But the MAIN reason why Flash was initially so successful and went on for > years and years of domination is that the Flash tools had an > Animation/Timeline Editor pretty much from the beginning. This enabled > even a novice to drag images around and draw the path they wanted them to > move along, add all sorts of bouncing effects and sounds and the result was > the birth of the online greeting card company. > > But Flash soon went on to be so much more. As the Adobe tools improved, so > did the SWFs and soon entire websites were written in Flash. > > Meanwhile, applet programmers had absolutely nothing remotely similar and > had to try (and I stress try) to tediously hand code any animations and > transitions and effects and I don't think it ever worked. > > Fast forward 15-20 years and now we have JavaFX which doesn't need to run > in the browser, has even more features than Flash, uses hardware > acceleration for superior performance, has a wide range of built-in > animations, transitions and effects but STILL we have to hand code any > animation/transitions. > > This is INCREDIBLY inefficient and unless Scene Builder incorporates a > powerful, sophisticated animation/transition and effect editor VERY, VERY > SOON I fear that the advanced graphics features are never going to be used > to their full potential (much to the detriment of JavaFX itself). > > Does anyone know if one is in the pipeline? I see this as one of the most > vital features for the JavaFX ecosystem to achieve more penetration and, > eventually, survive. > > Felix NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution. From hastebrot at gmail.com Fri Nov 14 19:04:57 2014 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Fri, 14 Nov 2014 20:04:57 +0100 Subject: Monocle in 8u25 In-Reply-To: References: <545A788D.9030509@tbee.org> <546310E1.8000702@tbee.org> <54659F72.7020603@tbee.org> Message-ID: >Should we roll out a openjfx-monocle-1.8.0_40-SNAPSHOT? I'll prepare a branch for this. Applied your patch and made some changes (introduced gradle.properties and removed redundant if-condition): https://github.com/TestFX/Monocle/pull/2/files --Benjamin From kevin.rushforth at oracle.com Fri Nov 14 19:43:02 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 Nov 2014 11:43:02 -0800 Subject: 8u40 rampdown schedule Message-ID: <54665B46.8000205@oracle.com> This is an update on the OpenJFX 8u40 [1] rampdown schedule. These dates derive from equivalent JDK 8u40 dates. As a reminder, the deadline for getting changes into 8u-dev and having them show up in that week's build is 1am Pacific on Monday [2]. Here are the key dates: 8u40 ZBB (Zero Bug Bounce) : Monday, Dec 1 8u40 M4 milestone build : Monday, Dec 8 8u40 RDP2 (rampdown phase 2) : Monday, Dec 15 8u-dev open up for post-8u40 changes: Tuesday, Dec 16. 8u40 repo fork: Wednesday, Dec 17 (based off the build from Monday) All product bugs currently targeted to 8u40 are expected to be addressed, either by fixing or deferring them, on or before our ZBB date of Dec 1. Between Dec 1 and Dec 15 we will be in "rampdown mode" for 8u40, during which time all bugs except doc / test bugs will need additional approval to go in. The focus will be on critical regressions. After Dec 15, only release-team approved bugs will be pulled into 8u40. Generally this is only show-stoppers or other release critical bugs. Related to this, I will be opening up a 9-dev repo for FX 9 work sometime in the next week or so. -- Kevin [1] https://wiki.openjdk.java.net/display/OpenJFX/8u40 [2] https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing From David.Hill at Oracle.com Fri Nov 14 19:55:51 2014 From: David.Hill at Oracle.com (David Hill) Date: Fri, 14 Nov 2014 14:55:51 -0500 Subject: Please review Message-ID: <54665E47.5060105@Oracle.com> Kevin, Morris, Please Review: jira: https://javafx-jira.kenai.com/browse/RT-38797 webrev: http://cr.openjdk.java.net/~ddhill/RT-38797/ I did try to fix this with native code, but could not find a documented way of checking the keyboard on MacOSX. And on other platforms, the presence of the key tends to be done with a table that may not map to a real attached keyboard. So used a lookup table for the most likely common use cases for this call. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From hastebrot at gmail.com Sat Nov 15 00:48:42 2014 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Sat, 15 Nov 2014 01:48:42 +0100 Subject: Monocle in 8u25 In-Reply-To: References: <545A788D.9030509@tbee.org> <546310E1.8000702@tbee.org> <54659F72.7020603@tbee.org> Message-ID: You can find the PR for headless support in TestFX here: https://github.com/TestFX/TestFX/pull/159 There are some issues with the Glass robot. We need this robot in order to simulate user interactions in headless mode. One problem is, that the Glass robot *(1) requires an JavaFX application* to be set up. TestFX initializes the robots first and then launches the Application. I worked-around this problem, by initializing the Glass robot just before the first user interaction is made. Another problem is, that the Glass robot *(2) requires interactions to be run within the JavaFX thread*. From the integration tests I've wrote it looks that we need to wait for the events in the JavaFX thread to complete for certain interactions, e.g. we need to wait after mouseMove() in order to do mouseClick(). With the AWT robot we only needed to wait for the events triggered by interactions to complete (let's call them post-interaction events). Now it seems that we also need to wait for the interactions itself to complete, which then will also trigger the post-interaction events. I'll need to visualize different interaction events, post-interaction events and the event waiting, and decide when we need to use the semaphore solution we currently use to wait for post-interaction events. Also I thought that events with Platform.runLater() will be processed first-in-first-out, but it seems that this is not the case. Yet, another problem is, that I did not manage to *(3) retrieve screenshot images in headless mode* with the Glass robot. Although it works in normal mode. Maybe the JavaFX event robot can retrieve the screenshots. Interestingly the HeadlessScreen updates it's framebuffer ( https://github.com/TestFX/Monocle/blob/0ab3986f4c/src/main/java/com/sun/glass/ui/monocle/headless/HeadlessScreen.java#L117 ). Regards, Benjamin On Fri, Nov 14, 2014 at 8:04 PM, Benjamin Gudehus wrote: > >Should we roll out a openjfx-monocle-1.8.0_40-SNAPSHOT? > > I'll prepare a branch for this. > > Applied your patch and made some changes (introduced gradle.properties and > removed redundant if-condition): > > https://github.com/TestFX/Monocle/pull/2/files > > --Benjamin > From hastebrot at gmail.com Sat Nov 15 15:49:49 2014 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Sat, 15 Nov 2014 16:49:49 +0100 Subject: Monocle in 8u25 In-Reply-To: References: <545A788D.9030509@tbee.org> <546310E1.8000702@tbee.org> <54659F72.7020603@tbee.org> Message-ID: Small update: Regarding (2) "requires interactions to be run withing the JavaFX thread": Nearly all integration tests for TestFX pass now. However the interactions freeze when using Glass robot, Node.startDragAndDrop() and ClipboardContent.putString() together. I guess the timing with Platform.runLater() needs some work. Regarding (3) "retrieve screenshot images in headless mode": I forgot to use "-Dprism.order=sw". Screenshots work in headless mode. --Benjamin On Sat, Nov 15, 2014 at 1:48 AM, Benjamin Gudehus wrote: > You can find the PR for headless support in TestFX here: > https://github.com/TestFX/TestFX/pull/159 > > There are some issues with the Glass robot. We need this robot in order to > simulate user interactions in headless mode. > > One problem is, that the Glass robot *(1) requires an JavaFX application* > to be set up. TestFX initializes the robots first and then launches the > Application. I worked-around this problem, by initializing the Glass robot > just before the first user interaction is made. > > Another problem is, that the Glass robot *(2) requires interactions to be > run within the JavaFX thread*. From the integration tests I've wrote it > looks that we need to wait for the events in the JavaFX thread to complete > for certain interactions, e.g. we need to wait after mouseMove() in order > to do mouseClick(). With the AWT robot we only needed to wait for the > events triggered by interactions to complete (let's call them > post-interaction events). Now it seems that we also need to wait for the > interactions itself to complete, which then will also trigger the > post-interaction events. I'll need to visualize different interaction > events, post-interaction events and the event waiting, and decide when we > need to use the semaphore solution we currently use to wait for > post-interaction events. Also I thought that events with > Platform.runLater() will be processed first-in-first-out, but it seems that > this is not the case. > > Yet, another problem is, that I did not manage to *(3) retrieve > screenshot images in headless mode* with the Glass robot. Although it > works in normal mode. Maybe the JavaFX event robot can retrieve the > screenshots. Interestingly the HeadlessScreen updates it's framebuffer ( > https://github.com/TestFX/Monocle/blob/0ab3986f4c/src/main/java/com/sun/glass/ui/monocle/headless/HeadlessScreen.java#L117 > ). > > Regards, > Benjamin > > > On Fri, Nov 14, 2014 at 8:04 PM, Benjamin Gudehus > wrote: > >> >Should we roll out a openjfx-monocle-1.8.0_40-SNAPSHOT? >> >> I'll prepare a branch for this. >> >> Applied your patch and made some changes (introduced gradle.properties >> and removed redundant if-condition): >> >> https://github.com/TestFX/Monocle/pull/2/files >> >> --Benjamin >> > > From sean.true at gmail.com Sat Nov 15 16:25:28 2014 From: sean.true at gmail.com (Sean True) Date: Sat, 15 Nov 2014 11:25:28 -0500 Subject: Monocle in 8u25 In-Reply-To: References: <545A788D.9030509@tbee.org> <546310E1.8000702@tbee.org> <54659F72.7020603@tbee.org> Message-ID: Benjamin -- This is terrific news. Thank you for the hard work behind all of this. -- Sean On Sat, Nov 15, 2014 at 10:49 AM, Benjamin Gudehus wrote: > Small update: > > Regarding (2) "requires interactions to be run withing the JavaFX thread": > Nearly all integration tests for TestFX pass now. However the interactions > freeze when using Glass robot, Node.startDragAndDrop() and > ClipboardContent.putString() together. I guess the timing with > Platform.runLater() needs some work. > > Regarding (3) "retrieve screenshot images in headless mode": I forgot to > use "-Dprism.order=sw". Screenshots work in headless mode. > > --Benjamin > > On Sat, Nov 15, 2014 at 1:48 AM, Benjamin Gudehus > wrote: > > > You can find the PR for headless support in TestFX here: > > https://github.com/TestFX/TestFX/pull/159 > > > > There are some issues with the Glass robot. We need this robot in order > to > > simulate user interactions in headless mode. > > > > One problem is, that the Glass robot *(1) requires an JavaFX application* > > to be set up. TestFX initializes the robots first and then launches the > > Application. I worked-around this problem, by initializing the Glass > robot > > just before the first user interaction is made. > > > > Another problem is, that the Glass robot *(2) requires interactions to be > > run within the JavaFX thread*. From the integration tests I've wrote it > > looks that we need to wait for the events in the JavaFX thread to > complete > > for certain interactions, e.g. we need to wait after mouseMove() in order > > to do mouseClick(). With the AWT robot we only needed to wait for the > > events triggered by interactions to complete (let's call them > > post-interaction events). Now it seems that we also need to wait for the > > interactions itself to complete, which then will also trigger the > > post-interaction events. I'll need to visualize different interaction > > events, post-interaction events and the event waiting, and decide when we > > need to use the semaphore solution we currently use to wait for > > post-interaction events. Also I thought that events with > > Platform.runLater() will be processed first-in-first-out, but it seems > that > > this is not the case. > > > > Yet, another problem is, that I did not manage to *(3) retrieve > > screenshot images in headless mode* with the Glass robot. Although it > > works in normal mode. Maybe the JavaFX event robot can retrieve the > > screenshots. Interestingly the HeadlessScreen updates it's framebuffer ( > > > https://github.com/TestFX/Monocle/blob/0ab3986f4c/src/main/java/com/sun/glass/ui/monocle/headless/HeadlessScreen.java#L117 > > ). > > > > Regards, > > Benjamin > > > > > > On Fri, Nov 14, 2014 at 8:04 PM, Benjamin Gudehus > > wrote: > > > >> >Should we roll out a openjfx-monocle-1.8.0_40-SNAPSHOT? > >> > >> I'll prepare a branch for this. > >> > >> Applied your patch and made some changes (introduced gradle.properties > >> and removed redundant if-condition): > >> > >> https://github.com/TestFX/Monocle/pull/2/files > >> > >> --Benjamin > >> > > > > > From herve.girod at gmail.com Sun Nov 16 17:59:05 2014 From: herve.girod at gmail.com (Herve Girod) Date: Sun, 16 Nov 2014 18:59:05 +0100 Subject: Dumping the rendering process in JavaFX In-Reply-To: <54655B15.70403@oracle.com> References: <54653591.8000803@oracle.com> <54653B82.4060503@oracle.com> <54655B15.70403@oracle.com> Message-ID: Hello, I did as it was proposed, and it work. I still have some cases where textures are a little off compared to the position where they should be, but it might be due to the post-processing I perform after creating the awt BufferedImage. Compared to what I thought, there were not a lot of classes I had to "hack" (by accessing protected or package protected methods or constructors). Mainly: I had to create a custom Screen (just to avoid NGRegion to fetch textures from their cache), a custom ResourceProvider (to return my Textures rather than the Platform ones), and I had to peform some code like in NGCanvas to get an awt image for textures. I will post an openSource project with more generic code than mine after I have performed some tests. Herv? 2014-11-14 2:29 GMT+01:00 Jim Graham : > Some pie in the sky observations about the background here... > > Note that there was a fine line there that had to be evaluated. Many of > the printing detection changes were basically just "Oh, look, I have a new > ResourceFactory now, that probably means new Textures", but it was tempered > with "One might think to permanently shift over to the resources from this > new factory, but if we're just printing, we are probably going to switch > right back to a screen factory so any permanent changes of internal state > are likely unwarranted". On the other hand, sometimes when you print a > scene, it was specially created just for the printing process so the > initial ResourceFactory it sees is likely the only one it will ever see > (and then the tree will be tossed). > > It would be nice if we could generalize this or switch the way we manage > resource states in the NGNode tree so that this was both flexible for > switching seamlessly to a new resource factory/pool and flexibly dealt with > the temporary/permanent nature of why those differences might come up (in > other words, dynamically use and cache new resources without alienating or > losing track of old ones unless that old pipeline/RF is going away). > > Right now there aren't any on-screen related changes that might require us > to permanently switch pipelines/resource factories (not entirely sure about > management of D3D resources when we lose access to the screen, though) and > printing is really the only use case where we ever even see a new > ResourceFactory. But, who knows what the future may bring and making > assumptions about the RF being a constant throughout the app life cycle are > not necessarily the best implementation practice in the long run... > > Have fun! ;) > > ...jim > > > On 11/13/14 3:15 PM, Phil Race wrote: > >> Basically for printing we had to detect that we were printing and use a >> non-cached texture. >> If you look for references to "PrinterGraphics" you might find some of >> them. >> Canvas is one place we had to deal with this. There are at least one or >> two others. >> Doing anything like only this via public API is probably an >> insurmountable challenge. >> >> -phil. >> >> On 11/13/14 2:49 PM, Kevin Rushforth wrote: >> >>> You could take a look at what JavaFX internally does for printing, >>> which is similar to what you are trying to do. It also forces the J2D >>> pipeline and had to deal with this issue. You likely won't be able to >>> do it without modifying FX internals, though, which is what printing >>> does in a few places. >>> >>> -- Kevin >>> >>> >>> Herve Girod wrote: >>> >>>> Hello, >>>> >>>> I think that more than one year ago, I asked if it was possible to >>>> dump the >>>> JavaFX rendering process. More than one year later, I (or we, for I am >>>> speaking on behalf of my project) are almost there. We use this in a >>>> library for a "JavaFX to any format you want" converter. For example >>>> we are >>>> currently able to convert a live JavaFX image to a PowerPoint slider >>>> (using >>>> POI), or we also could do the same with a WMF / EMF / SVG image, keeping >>>> the vector content of course. >>>> >>>> What we did is hacking the J2DPrismGraphics class to render it in a >>>> custom >>>> Graphics2D context which in turn can be a PPT / SVG / WMF / or EMF >>>> serializer. >>>> >>>> Our use case is the use of JavaFX in an Editor (no it's not a JavaFX >>>> Editor, we edit graphic specifications for an avionics standard called >>>> ARINC 661), and the ability to produce another Vector format with >>>> exactly >>>> the same UI. >>>> >>>> It works very well, except that of course we had to hack a few JavaFX >>>> core >>>> classes to do that (obviously J2DPrismGraphics was not designed to allow >>>> this). We did not recompile the core library, it's just separate classes >>>> which uses com.sun classes when possible, or we used >>>> PrivilegedActions when >>>> a method we needed was package protected. >>>> >>>> But we have still a big problem (I think that it might be the only one, >>>> except for the fact that our solution is an ugly hack, as you can see): >>>> >>>> There is still one case where our solution does not work: Textures. >>>> In fact >>>> we would have been able to convert JavaFX textures to BufferedImages >>>> if we >>>> could use the Java2D-based Texture class, but of course as we did >>>> nothing >>>> special, we encounter a D3D Texture (for example on Windows) which we >>>> don't >>>> know how to deal with. >>>> >>>> Which leads me to my two questions: >>>> >>>> - Is there a programmatic way (even a contorted one) to force JavaFX >>>> to use >>>> our own specific Pipeline (the idea is to be able to do this temporarily >>>> when serializing the JavaFX content, so without having to use command >>>> line >>>> argument) >>>> >>>> - I think that it could be very useful to have a neutral and JavaFX - >>>> supported way for developers to use their own Pipeline, even if it was >>>> limited and with a lower than average performance. Being able to convert >>>> from / to the JavaFX format is something that can be very useful. >>>> >>>> Herv? >>>> >>> >> From r.lichtenberger at gmail.com Mon Nov 17 10:14:33 2014 From: r.lichtenberger at gmail.com (Robert Lichtenberger) Date: Mon, 17 Nov 2014 11:14:33 +0100 Subject: Text cut off in new Dialogs API Message-ID: <5469CA89.3050206@gmail.com> I hope this is the right place to post bugs to. If not, please accept my apologies and advise where to post bugs. I've just tried the upcoming (u40) new Dialogs API (good job, BTW, looks/feels great) and noticed that long content texts will be cut off (elipsis). Here's an example: import javafx.application.Application; import javafx.event.ActionEvent; import javafx.event.EventHandler; import javafx.scene.Scene; import javafx.scene.control.Alert; import javafx.scene.control.Alert.AlertType; import javafx.scene.control.Menu; import javafx.scene.control.MenuBar; import javafx.scene.control.MenuItem; import javafx.scene.input.KeyCombination; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class DialogCutOffBug extends Application { public DialogCutOffBug() { } @Override public void start(Stage stage) throws Exception { stage.setTitle("Menu Sample"); Scene scene = new Scene(new VBox(), 400, 350); MenuBar menuBar = new MenuBar(); // --- Menu File Menu menuFile = new Menu("File"); menuBar.getMenus().addAll(menuFile); MenuItem test = new MenuItem("Open Dialog"); test.setAccelerator(KeyCombination.keyCombination("Ctrl+O")); test.setOnAction(new EventHandler() { public void handle(ActionEvent t) { Alert alert = new Alert(AlertType.INFORMATION); alert.setTitle("Information Dialog"); alert.setHeaderText("Short"); alert.setContentText("Whenever I start to use dialogs, there is certain verboseness involved, which will make the dialog basically useless, however JavaFX should not produce ellipses here, because the Dialog text should always be displayed in Full"); alert.showAndWait(); } }); menuFile.getItems().add(test); ((VBox) scene.getRoot()).getChildren().addAll(menuBar); stage.setScene(scene); stage.show(); } public static void main(String[] args) { launch(args); } } It looks like this (red line added by me, of course): Best regards, Robert Lichtenberger From ngalarneau at ABINITIO.COM Mon Nov 17 15:24:24 2014 From: ngalarneau at ABINITIO.COM (ngalarneau at ABINITIO.COM) Date: Mon, 17 Nov 2014 10:24:24 -0500 Subject: Monocle in 8u25 In-Reply-To: References: <545A788D.9030509@tbee.org> <546310E1.8000702@tbee.org> <54659F72.7020603@tbee.org> Message-ID: Hi Benjamin, Your progress sounds very good! In your email below, you said: "Also I thought that events with Platform.runLater() will be processed first-in-first-out, but it seems that this is not the case." Kevin, on an email on Nov. 5th to this list, said that the only exception to Platform.runLater() Runnables being processed in order was in the case of a showAndWait() being done. That blocks the current thread, which stops the current Runnable from completing while a new thread takes the next event/Runnable from the queue. In that case later Runnables would be processed before the earlier one completes. Does that explain what you have seen? Neil From: Benjamin Gudehus To: ngalarneau at abinitio.com, Cc: Tom Eugelink , "openjfx-dev at openjdk.java.net" Date: 11/15/2014 10:50 AM Subject: Re: Monocle in 8u25 Small update: Regarding (2) "requires interactions to be run withing the JavaFX thread": Nearly all integration tests for TestFX pass now. However the interactions freeze when using Glass robot, Node.startDragAndDrop() and ClipboardContent.putString() together. I guess the timing with Platform.runLater() needs some work. Regarding (3) "retrieve screenshot images in headless mode": I forgot to use "-Dprism.order=sw". Screenshots work in headless mode. --Benjamin On Sat, Nov 15, 2014 at 1:48 AM, Benjamin Gudehus wrote: You can find the PR for headless support in TestFX here: https://github.com/TestFX/TestFX/pull/159 There are some issues with the Glass robot. We need this robot in order to simulate user interactions in headless mode. One problem is, that the Glass robot (1) requires an JavaFX application to be set up. TestFX initializes the robots first and then launches the Application. I worked-around this problem, by initializing the Glass robot just before the first user interaction is made. Another problem is, that the Glass robot (2) requires interactions to be run within the JavaFX thread. From the integration tests I've wrote it looks that we need to wait for the events in the JavaFX thread to complete for certain interactions, e.g. we need to wait after mouseMove() in order to do mouseClick(). With the AWT robot we only needed to wait for the events triggered by interactions to complete (let's call them post-interaction events). Now it seems that we also need to wait for the interactions itself to complete, which then will also trigger the post-interaction events. I'll need to visualize different interaction events, post-interaction events and the event waiting, and decide when we need to use the semaphore solution we currently use to wait for post-interaction events. Also I thought that events with Platform.runLater() will be processed first-in-first-out, but it seems that this is not the case. Yet, another problem is, that I did not manage to (3) retrieve screenshot images in headless mode with the Glass robot. Although it works in normal mode. Maybe the JavaFX event robot can retrieve the screenshots. Interestingly the HeadlessScreen updates it's framebuffer ( https://github.com/TestFX/Monocle/blob/0ab3986f4c/src/main/java/com/sun/glass/ui/monocle/headless/HeadlessScreen.java#L117 ). Regards, Benjamin NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution. From richard.bair at oracle.com Mon Nov 17 15:48:52 2014 From: richard.bair at oracle.com (Richard Bair) Date: Mon, 17 Nov 2014 07:48:52 -0800 Subject: What Scene Builder needs YESTERDAY! In-Reply-To: References: Message-ID: I?m afraid at this time there are no plans for adding an animation/transition effect editor to Scene Builder, certainly not in the short-term. Thanks Richard > On Nov 13, 2014, at 7:34 PM, Felix Bembrick wrote: > > Java applets were the first "programs" to run inside a web browser and for > a (little) while they were flavour of the month. > > But then along came Flash which had several advantages such as faster load > times, consistent loads and antialiased fonts/graphics and soon completely > surpassed applets. > > But the MAIN reason why Flash was initially so successful and went on for > years and years of domination is that the Flash tools had an > Animation/Timeline Editor pretty much from the beginning. This enabled > even a novice to drag images around and draw the path they wanted them to > move along, add all sorts of bouncing effects and sounds and the result was > the birth of the online greeting card company. > > But Flash soon went on to be so much more. As the Adobe tools improved, so > did the SWFs and soon entire websites were written in Flash. > > Meanwhile, applet programmers had absolutely nothing remotely similar and > had to try (and I stress try) to tediously hand code any animations and > transitions and effects and I don't think it ever worked. > > Fast forward 15-20 years and now we have JavaFX which doesn't need to run > in the browser, has even more features than Flash, uses hardware > acceleration for superior performance, has a wide range of built-in > animations, transitions and effects but STILL we have to hand code any > animation/transitions. > > This is INCREDIBLY inefficient and unless Scene Builder incorporates a > powerful, sophisticated animation/transition and effect editor VERY, VERY > SOON I fear that the advanced graphics features are never going to be used > to their full potential (much to the detriment of JavaFX itself). > > Does anyone know if one is in the pipeline? I see this as one of the most > vital features for the JavaFX ecosystem to achieve more penetration and, > eventually, survive. > > Felix From kevin.rushforth at oracle.com Mon Nov 17 16:00:44 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 17 Nov 2014 08:00:44 -0800 Subject: Text cut off in new Dialogs API In-Reply-To: <5469CA89.3050206@gmail.com> References: <5469CA89.3050206@gmail.com> Message-ID: <546A1BAC.9060102@oracle.com> Please file a JIRA. -- Kevin Robert Lichtenberger wrote: > I hope this is the right place to post bugs to. If not, please accept > my apologies and advise where to post bugs. > > I've just tried the upcoming (u40) new Dialogs API (good job, BTW, > looks/feels great) and noticed that long content texts will be cut off > (elipsis). > > Here's an example: > > import javafx.application.Application; > import javafx.event.ActionEvent; > import javafx.event.EventHandler; > import javafx.scene.Scene; > import javafx.scene.control.Alert; > import javafx.scene.control.Alert.AlertType; > import javafx.scene.control.Menu; > import javafx.scene.control.MenuBar; > import javafx.scene.control.MenuItem; > import javafx.scene.input.KeyCombination; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class DialogCutOffBug extends Application { > > public DialogCutOffBug() { > } > > @Override > public void start(Stage stage) throws Exception { > stage.setTitle("Menu Sample"); > Scene scene = new Scene(new VBox(), 400, 350); > > MenuBar menuBar = new MenuBar(); > > // --- Menu File > Menu menuFile = new Menu("File"); > menuBar.getMenus().addAll(menuFile); > > MenuItem test = new MenuItem("Open Dialog"); > test.setAccelerator(KeyCombination.keyCombination("Ctrl+O")); > test.setOnAction(new EventHandler() { > public void handle(ActionEvent t) { > Alert alert = new Alert(AlertType.INFORMATION); > alert.setTitle("Information Dialog"); > alert.setHeaderText("Short"); > alert.setContentText("Whenever I start to use dialogs, > there is certain verboseness involved, which will make the dialog > basically useless, however JavaFX should not produce ellipses here, > because the Dialog text should always be displayed in Full"); > alert.showAndWait(); > } > }); > > menuFile.getItems().add(test); > > ((VBox) scene.getRoot()).getChildren().addAll(menuBar); > > stage.setScene(scene); > stage.show(); > } > > public static void main(String[] args) { > launch(args); > } > } > > It looks like this (red line added by me, of course): > > > Best regards, > Robert Lichtenberger > From vadim.pakhnushev at oracle.com Mon Nov 17 18:52:43 2014 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Mon, 17 Nov 2014 21:52:43 +0300 Subject: [8u40] Review request for RT-39035: [TableView] TableView vertical mouse wheel scrolling does not go to the bottom (screen at a time or fast wheel setting) Message-ID: <546A43FB.7040502@oracle.com> Hi Jonathan, Kevin, Please review the fix: https://javafx-jira.kenai.com/browse/RT-39035 http://cr.openjdk.java.net/~vadim/RT-39035/webrev.00/ Thanks, Vadim From anton.tarasov at oracle.com Mon Nov 17 20:31:32 2014 From: anton.tarasov at oracle.com (Anton Tarasov) Date: Mon, 17 Nov 2014 23:31:32 +0300 Subject: [8u40] Post commit notification: RT-39336 [JFXPanel] Two popup windows in WebEngine on OS X 10.10 Message-ID: <546A5B24.2040008@oracle.com> Hi Vadim, Kevin, A post commit notification for the following: https://javafx-jira.kenai.com/browse/RT-39336 http://cr.openjdk.java.net/~ant/RT-39336/webrev.0 Thanks, Anton. From kevin.rushforth at oracle.com Mon Nov 17 21:06:11 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 17 Nov 2014 13:06:11 -0800 Subject: 8u-dev unlocked following this week's sanity testing Message-ID: <546A6343.2020901@oracle.com> From jonathan.giles at oracle.com Mon Nov 17 22:42:05 2014 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 18 Nov 2014 11:42:05 +1300 Subject: Text cut off in new Dialogs API In-Reply-To: <546A1BAC.9060102@oracle.com> References: <5469CA89.3050206@gmail.com> <546A1BAC.9060102@oracle.com> Message-ID: <546A79BD.3010601@oracle.com> I've filed https://javafx-jira.kenai.com/browse/RT-39422 -- Jonathan On 18/11/2014 5:00 a.m., Kevin Rushforth wrote: > Please file a JIRA. > > -- Kevin > > > Robert Lichtenberger wrote: >> I hope this is the right place to post bugs to. If not, please accept >> my apologies and advise where to post bugs. >> >> I've just tried the upcoming (u40) new Dialogs API (good job, BTW, >> looks/feels great) and noticed that long content texts will be cut >> off (elipsis). >> >> Here's an example: >> >> import javafx.application.Application; >> import javafx.event.ActionEvent; >> import javafx.event.EventHandler; >> import javafx.scene.Scene; >> import javafx.scene.control.Alert; >> import javafx.scene.control.Alert.AlertType; >> import javafx.scene.control.Menu; >> import javafx.scene.control.MenuBar; >> import javafx.scene.control.MenuItem; >> import javafx.scene.input.KeyCombination; >> import javafx.scene.layout.VBox; >> import javafx.stage.Stage; >> >> public class DialogCutOffBug extends Application { >> >> public DialogCutOffBug() { >> } >> >> @Override >> public void start(Stage stage) throws Exception { >> stage.setTitle("Menu Sample"); >> Scene scene = new Scene(new VBox(), 400, 350); >> >> MenuBar menuBar = new MenuBar(); >> >> // --- Menu File >> Menu menuFile = new Menu("File"); >> menuBar.getMenus().addAll(menuFile); >> >> MenuItem test = new MenuItem("Open Dialog"); >> test.setAccelerator(KeyCombination.keyCombination("Ctrl+O")); >> test.setOnAction(new EventHandler() { >> public void handle(ActionEvent t) { >> Alert alert = new Alert(AlertType.INFORMATION); >> alert.setTitle("Information Dialog"); >> alert.setHeaderText("Short"); >> alert.setContentText("Whenever I start to use >> dialogs, there is certain verboseness involved, which will make the >> dialog basically useless, however JavaFX should not produce ellipses >> here, because the Dialog text should always be displayed in Full"); >> alert.showAndWait(); >> } >> }); >> >> menuFile.getItems().add(test); >> >> ((VBox) scene.getRoot()).getChildren().addAll(menuBar); >> >> stage.setScene(scene); >> stage.show(); >> } >> >> public static void main(String[] args) { >> launch(args); >> } >> } >> >> It looks like this (red line added by me, of course): >> >> >> Best regards, >> Robert Lichtenberger >> From kevin.rushforth at oracle.com Tue Nov 18 12:25:44 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 Nov 2014 04:25:44 -0800 Subject: HEADS-UP: 9-dev repo will open up this week Message-ID: <546B3AC8.7060601@oracle.com> As I mentioned in last week's e-mail about the OpenJFX 8u40 rampdown plan, we are preparing to create an OpenJFX 9-dev repo and intend to open it up later this week. Until we fork the 8u40 stabilization repo we will continue to automatically forward-sync changes from 8u to 9, so any bug that is fixed in 8u-dev prior to that time need not be separately fixed in 9. I will send a notice to the alias just before we stop doing this forward sync. I will send a follow-up message when the new repo is open, and what the rules will be for pushing changes. Initially, we will just target bug fixes that are considered too risky for 8u, along with any changes needed to support JDK9 features or build time changes; no new features or enhancements yet. -- Kevin From elina.kleyman at oracle.com Tue Nov 18 16:44:55 2014 From: elina.kleyman at oracle.com (Elina Kleyman) Date: Tue, 18 Nov 2014 08:44:55 -0800 (PST) Subject: [8u40] Review request: RT-39380 - Ensemble8: Charts category - empty tabs are shown when opening "View Source" Message-ID: <4d8d684b-8ac7-489e-b4cb-bc84bf8aa9a1@default> Hi Morris and Kevin, Please review my small fix to Ensemble (Charts): JIRA: https://javafx-jira.kenai.com/browse/RT-39380 WEBREV: http://cr.openjdk.java.net/~ekleyman/RT-39380/webrev/ Thanks, Elina From chien.yang at oracle.com Wed Nov 19 00:27:56 2014 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 18 Nov 2014 16:27:56 -0800 Subject: [8u40] Code Review Request For RT-38063: Bleeding Edges - Background Bleeding on Shared Edges for 3D Multi-Polygon Configurations Message-ID: <546BE40C.5020907@oracle.com> Hi Jim and Kevin, Please review the proposed fix: https://javafx-jira.kenai.com/browse/RT-38063 http://cr.openjdk.java.net/~ckyang/RT-38063/webrev.00/ Thanks, - Chien From james.graham at oracle.com Wed Nov 19 00:36:11 2014 From: james.graham at oracle.com (Jim Graham) Date: Tue, 18 Nov 2014 16:36:11 -0800 Subject: 8u40 review request: RT-38060 effect clipping code does not work on retina MBP Message-ID: <546BE5FB.30502@oracle.com> Jira: https://javafx-jira.kenai.com/browse/RT-38060 webrev: http://cr.openjdk.java.net/~flar/RT-38060/webrev.00/ ...jim From chien.yang at oracle.com Thu Nov 20 18:18:59 2014 From: chien.yang at oracle.com (Chien Yang) Date: Thu, 20 Nov 2014 10:18:59 -0800 Subject: [8u40] Code Review Request For RT-39468: Overlapping 3D transformed 2D shapes have dirty edges in Scene with depth buffer Message-ID: <546E3093.6010306@oracle.com> Hi Jim and Kevin, Please review the proposed fix posted in this JIRA: https://javafx-jira.kenai.com/browse/RT-39468 Thanks, - Chien From kevin.rushforth at oracle.com Fri Nov 21 00:44:45 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 20 Nov 2014 16:44:45 -0800 Subject: [8u40] review request: RT-39421: Security exception in Service.cancel and URLLoaderThreadFactory when running sandboxed applet Message-ID: <546E8AFD.1080801@oracle.com> Vadim, Jonathan, Anton, Please review: https://javafx-jira.kenai.com/browse/RT-39421 http://cr.openjdk.java.net/~kcr/RT-39421/webrev.00/ Details in JIRA. Thanks. -- Kevin From neugens at redhat.com Fri Nov 21 15:26:48 2014 From: neugens at redhat.com (Mario Torre) Date: Fri, 21 Nov 2014 16:26:48 +0100 Subject: Possible new project: OpenJDK LaF In-Reply-To: <1409220286.25913.8.camel@nirvana.localdomain> References: <1409155016.25913.6.camel@nirvana.localdomain> <1409220286.25913.8.camel@nirvana.localdomain> Message-ID: <1416583608.22846.43.camel@nirvana.localdomain> On Thu, 2014-08-28 at 12:04 +0200, Mario Torre wrote: > On Wed, 2014-08-27 at 17:03 +0100, Martijn Verburg wrote: > > I think a move to GTK 3 would eliminate a class of java/Linux desktop > > issues we run across today. My concern would be the long term maintenance > > of this piece... Given no further comments on this thread, I went ahead and created a draft JEP proposal: https://bugs.openjdk.java.net/browse/JDK-8065658 I would appreciate if you could comment on this and help me out moving forward. Please, ensure that all the replies happen to be on the swing-dev mailing list. Thanks! Mario From vadim.pakhnushev at oracle.com Fri Nov 21 16:57:09 2014 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 21 Nov 2014 19:57:09 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <546F6EE5.5050605@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim From chien.yang at oracle.com Fri Nov 21 21:33:21 2014 From: chien.yang at oracle.com (Chien Yang) Date: Fri, 21 Nov 2014 13:33:21 -0800 Subject: [8u40] Code Review Request For RT-39455: Remove unused ShapeUtil.rasterizeGlyphOutline method and relevant prism settings Message-ID: <546FAFA1.2050201@oracle.com> Hi Jim, Phil or Kevin, Please review the proposed fix posted in this JIRA: JIRA: https://javafx-jira.kenai.com/browse/RT-39455 Webrev: http://cr.openjdk.java.net/~ckyang/RT-39455/webrev.00/ Thanks, - Chien From kevin.rushforth at oracle.com Fri Nov 21 23:13:26 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Nov 2014 15:13:26 -0800 Subject: PLEASE READ: FX 9-dev repo is now open Message-ID: <546FC716.6080604@oracle.com> OpenJFX Developers: I am pleased to announce that the OpenJFX 9-dev repo [1] is now open. As with FX 8, there is a corresponding master repo, but developers should pull from 9-dev just as is currently done for 8u-dev. Here are the rules of engagement. They are also posted on the OpenJFK Wiki [2]. 1) For at least the next three weeks, we will still automatically forward-sync changes from 8u to 9 each week. This means that: A) you must avoid any significant refactoring, white space changes, etc., in 9-dev that might cause difficult-to-resolve merge conflicts; and B) any change that is intended for 8u40 should be pushed to 8u-dev only and not also to 9-dev (it will get synced into 9-dev at the next integration). I will send an announcement when this changes, likely in mid-December. 2) Until we determine the scope of the FX work for 9, the changesets should be limited to bug fixing and minor improvements; no API changes or new functionality should be added yet. The code review requirements are the same as for non-milestone weeks for 8u-dev [3]. 3) Our testing is still focused on 8u40, so there is no weekly lockout period yet for 9. I plan to take a snapshot for integration at the same time as we start sanity testing 8u-dev (1am on Monday). Stay tuned for changes on this front once 8u40 repo is forked and we go into rampdown for that release. Let me know if you have any questions. -- Kevin [1] http://hg.openjdk.java.net/openjfx/9-dev/rt [2] https://wiki.openjdk.java.net/display/OpenJFX/9 [3] https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews From kevin.rushforth at oracle.com Fri Nov 21 23:37:44 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Nov 2014 15:37:44 -0800 Subject: [8u40] review request: RT-39000: Exceptions in sandboxed app when dragging text within WebView Message-ID: <546FCCC8.2080300@oracle.com> Anton (or Leonid), Please review the following simple fix: https://javafx-jira.kenai.com/browse/RT-39000 http://cr.openjdk.java.net/~kcr/RT-39000/webrev.00/ Thanks. -- Kevin From james.graham at oracle.com Sat Nov 22 03:22:41 2014 From: james.graham at oracle.com (Jim Graham) Date: Fri, 21 Nov 2014 19:22:41 -0800 Subject: [8u40] review request: RT-39424 center of pixel sampling for non-AA rendering Message-ID: <54700181.30109@oracle.com> webrev: http://cr.openjdk.java.net/~flar/RT-39424/webrev.00/ Jira: https://javafx-jira.kenai.com/browse/RT-39424 Note that curves still show a lot of errors due to RT-39439. Those will be fixed by work on the "BND" constants in a separate fix... ...jim From ooo_saturn7 at mail.ru Sat Nov 22 14:42:19 2014 From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=) Date: Sat, 22 Nov 2014 17:42:19 +0300 Subject: =?UTF-8?B?TGludXggKGNlbnRvcyksIG9wZW5qZGsgOCwgb3BlbmpmeCBhbmQgbmV0YmVh?= =?UTF-8?B?bnMgOA==?= Message-ID: <1416667339.70989799@f322.i.mail.ru> Hello everybody. I installed at centos 6.4 openjdk 8, netbeans 8 and build openjfx (via gradle). The only thing I can't uderstand is how to make netbeans work with built openjfx sdk. As openjdx sdk is in folder /temp while jdk is in /usr/lib/jvm/java-8... I can't undertand how to add openjfx to netbeans as everywhere people say that jfx is already in jdk. So, what now should I do to make all these work together? -- PashaTurok From kevin.rushforth at oracle.com Sun Nov 23 01:29:21 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 22 Nov 2014 17:29:21 -0800 Subject: [8u40] review request: RT-39182: Enable building 32-bit Linux on 64-bit systems Message-ID: <54713871.2090502@oracle.com> Dave, Kirill, Anton, Chris, Please review the following build changes to enable building 32-bit graphics, media, webkit, and packager binaries on a 64-bit Linux system. https://javafx-jira.kenai.com/browse/RT-39182 http://cr.openjdk.java.net/~kcr/RT-39182/webrev.01/ Details are in JIRA. -- Kevin From tom.schindl at bestsolution.at Sun Nov 23 19:04:33 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sun, 23 Nov 2014 20:04:33 +0100 Subject: Text.getImpl_caretShape returns strange results under certain conditions Message-ID: <54722FC1.9040904@bestsolution.at> Hi, I was debugging a problem in my StyledText-Source editor today and found one of my layout problems is that ListCells (the inner representation of the editor lines is simply ListView) sometime get really strange heights assigned. To display a caret in the UI I'm creating a caret-Shape using Text.getImpl_caretShape but this is causeing my layout problems because under certain conditions the returned cursor is completely wrong. Look for example at the following example. The first line is the bounds of the Text-Element with the content (privata) and the 2nd is the Path created by Text.getImpl_caretShape > BoundingBox [minX:0.0, minY:0.0, minZ:0.0, width:81.01318359375, height:15.0, depth:0.0, maxX:81.01318359375, maxY:15.0, maxZ:0.0] > privata ===> [MoveTo[x=9.00146484375, y=120.0], LineTo[x=9.00146484375, y=135.0]] the correct path is [MoveTo[x=9.00146484375, y=0.0], LineTo[x=9.00146484375, y=15.0]] I've been able to work around this problem for the time being. Anyone an idea what is causing this completely invalid caretShape? Tom -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From felipe.heidrich at oracle.com Mon Nov 24 01:49:44 2014 From: felipe.heidrich at oracle.com (Felipe Heidrich) Date: Sun, 23 Nov 2014 17:49:44 -0800 Subject: Text.getImpl_caretShape returns strange results under certain conditions In-Reply-To: <54722FC1.9040904@bestsolution.at> References: <54722FC1.9040904@bestsolution.at> Message-ID: <7D7CFDE4-1268-4340-8620-81DA97630BB6@oracle.com> Hi Tom, Without a reproducible testcase it is hard to see what is happening. Are you using Text or TextFlow ? For some reason the Text.getImpl_caretShape() seems to think the caret is in the 8th line, which seems to indicate there is some line wrapping width set when it should not (Jim just fixed a bug in that code last week). Regards, Felipe > On Nov 23, 2014, at 11:04 AM, Tom Schindl wrote: > > Hi, > > I was debugging a problem in my StyledText-Source editor today and found > one of my layout problems is that ListCells (the inner representation of > the editor lines is simply ListView) sometime get really strange heights > assigned. > > To display a caret in the UI I'm creating a caret-Shape using > Text.getImpl_caretShape but this is causeing my layout problems because > under certain conditions the returned cursor is completely wrong. > > Look for example at the following example. The first line is the bounds > of the Text-Element with the content (privata) and the 2nd is the Path > created by Text.getImpl_caretShape > >> BoundingBox [minX:0.0, minY:0.0, minZ:0.0, width:81.01318359375, height:15.0, depth:0.0, maxX:81.01318359375, maxY:15.0, maxZ:0.0] >> privata ===> [MoveTo[x=9.00146484375, y=120.0], LineTo[x=9.00146484375, y=135.0]] > > the correct path is [MoveTo[x=9.00146484375, y=0.0], > LineTo[x=9.00146484375, y=15.0]] > > > I've been able to work around this problem for the time being. Anyone an > idea what is causing this completely invalid caretShape? > > Tom > > -- > Thomas Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck > http://www.bestsolution.at/ > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From kirill.kirichenko at oracle.com Mon Nov 24 06:01:44 2014 From: kirill.kirichenko at oracle.com (Kirill Kirichenko) Date: Mon, 24 Nov 2014 09:01:44 +0300 Subject: [8u40] review request: RT-39182: Enable building 32-bit Linux on 64-bit systems In-Reply-To: <54713871.2090502@oracle.com> References: <54713871.2090502@oracle.com> Message-ID: <5472C9C8.6080103@oracle.com> Can we build 64 bit libraries on 32 bit systems ? If so then modify this patch accordingly. K On 23.11.2014 4:29, Kevin Rushforth wrote: > Dave, Kirill, Anton, Chris, > > Please review the following build changes to enable building 32-bit > graphics, media, webkit, and packager binaries on a 64-bit Linux system. > > https://javafx-jira.kenai.com/browse/RT-39182 > http://cr.openjdk.java.net/~kcr/RT-39182/webrev.01/ > > Details are in JIRA. > > -- Kevin > From anton.tarasov at oracle.com Mon Nov 24 07:48:35 2014 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Mon, 24 Nov 2014 10:48:35 +0300 Subject: Linux (centos), openjdk 8, openjfx and netbeans 8 In-Reply-To: <1416667339.70989799@f322.i.mail.ru> References: <1416667339.70989799@f322.i.mail.ru> Message-ID: <5472E2D3.2040809@oracle.com> Hello Alexander, On 22.11.2014 17:42, ????????? ???????? wrote: > Hello everybody. > I installed at centos 6.4 openjdk 8, netbeans 8 and build openjfx (via gradle). The only thing I can't uderstand is how to make netbeans work with built openjfx sdk. As openjdx sdk is in folder /temp while jdk is in /usr/lib/jvm/java-8... I can't undertand how to add openjfx to netbeans as everywhere people say that jfx is already in jdk. > So, what now should I do to make all these work together? openjdk8 sdk contains the openjfx sdk binaries. So, you don't need to change the classpath in order to compile or run your jfx application. Simply add your jdk as a Java Platform. In case you want to try your own openjfx build with openjdk in netbeans, you can do the following. In the "Project Properties"dialog of your project, select "Libraries" and add jfxrt.jar to the Compile-time and Run-time libraries. Please, find jfxrt.jar in the "artifacts" of your openjfx workspace: /artifacts/sdk/rt/lib/ext/jfxrt.jar Also, you can find the netbeans projects of the openjfx source tree under the following dir: /rt/netbeans Regards, Anton. From tom.schindl at bestsolution.at Mon Nov 24 08:08:17 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 24 Nov 2014 09:08:17 +0100 Subject: Text.getImpl_caretShape returns strange results under certain conditions In-Reply-To: <7D7CFDE4-1268-4340-8620-81DA97630BB6@oracle.com> References: <54722FC1.9040904@bestsolution.at> <7D7CFDE4-1268-4340-8620-81DA97630BB6@oracle.com> Message-ID: <5472E771.8000502@bestsolution.at> The thing I can confirm is that the Text is inside a TextFlow but I'm fairly unable to provide a test-case because it happens at random times - I'll try to update to the latest u40 build to see if the fix from Jim helps me. For the time being I was able to work around the problem by adjusting the PathElements returned to be never larger then the text-elements height which too me sounds like a reasonable constraint because I can't think of a situation where the caret should ever be larger than the Text-Bounds. Tom On 24.11.14 02:49, Felipe Heidrich wrote: > Hi Tom, > > Without a reproducible testcase it is hard to see what is happening. Are you using Text or TextFlow ? > For some reason the Text.getImpl_caretShape() seems to think the caret is in the 8th line, which seems to indicate there is some line wrapping width set when it should not (Jim just fixed a bug in that code last week). > > Regards, > Felipe > > >> On Nov 23, 2014, at 11:04 AM, Tom Schindl wrote: >> >> Hi, >> >> I was debugging a problem in my StyledText-Source editor today and found >> one of my layout problems is that ListCells (the inner representation of >> the editor lines is simply ListView) sometime get really strange heights >> assigned. >> >> To display a caret in the UI I'm creating a caret-Shape using >> Text.getImpl_caretShape but this is causeing my layout problems because >> under certain conditions the returned cursor is completely wrong. >> >> Look for example at the following example. The first line is the bounds >> of the Text-Element with the content (privata) and the 2nd is the Path >> created by Text.getImpl_caretShape >> >>> BoundingBox [minX:0.0, minY:0.0, minZ:0.0, width:81.01318359375, height:15.0, depth:0.0, maxX:81.01318359375, maxY:15.0, maxZ:0.0] >>> privata ===> [MoveTo[x=9.00146484375, y=120.0], LineTo[x=9.00146484375, y=135.0]] >> >> the correct path is [MoveTo[x=9.00146484375, y=0.0], >> LineTo[x=9.00146484375, y=15.0]] >> >> >> I've been able to work around this problem for the time being. Anyone an >> idea what is causing this completely invalid caretShape? >> >> Tom >> >> -- >> Thomas Schindl, CTO >> BestSolution.at EDV Systemhaus GmbH >> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck >> http://www.bestsolution.at/ >> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From tom.schindl at bestsolution.at Mon Nov 24 08:31:41 2014 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 24 Nov 2014 09:31:41 +0100 Subject: Text.getImpl_caretShape returns strange results under certain conditions In-Reply-To: <5472E771.8000502@bestsolution.at> References: <54722FC1.9040904@bestsolution.at> <7D7CFDE4-1268-4340-8620-81DA97630BB6@oracle.com> <5472E771.8000502@bestsolution.at> Message-ID: <5472ECED.90203@bestsolution.at> I've just added some more debug information and for me the values I get are reasonable and the bounds are identical but once the bug is wrong and the next time it is right :-( > ========== INVALID: privat============ > Caret: [MoveTo[x=9.00146484375, y=105.0], LineTo[x=9.00146484375, y=120.0]] > Text-Bounds: BoundingBox [minX:0.0, minY:0.0, minZ:0.0, width:72.01171875, height:15.0, depth:0.0, maxX:72.01171875, maxY:15.0, maxZ:0.0] > Wrapping-Width: 0.0 > Text-Flow:BoundingBox [minX:0.0, minY:0.0, minZ:0.0, width:72.01171875, height:15.0, depth:0.0, maxX:72.01171875, maxY:15.0, maxZ:0.0] > ========== VALID: privat============ > Caret: [MoveTo[x=9.00146484375, y=0.0], LineTo[x=9.00146484375, y=15.0]] > Text-Bounds: BoundingBox [minX:0.0, minY:0.0, minZ:0.0, width:72.01171875, height:15.0, depth:0.0, maxX:72.01171875, maxY:15.0, maxZ:0.0] > Wrapping-Width: 0.0 > Text-Flow:BoundingBox [minX:0.0, minY:0.0, minZ:0.0, width:72.01171875, height:15.0, depth:0.0, maxX:72.01171875, maxY:15.0, maxZ:0.0] Jim can you point me to the bug you fixed? Tom On 24.11.14 09:08, Tom Schindl wrote: > The thing I can confirm is that the Text is inside a TextFlow but I'm > fairly unable to provide a test-case because it happens at random times > - I'll try to update to the latest u40 build to see if the fix from Jim > helps me. > > For the time being I was able to work around the problem by adjusting > the PathElements returned to be never larger then the text-elements > height which too me sounds like a reasonable constraint because I can't > think of a situation where the caret should ever be larger than the > Text-Bounds. > > Tom > > On 24.11.14 02:49, Felipe Heidrich wrote: >> Hi Tom, >> >> Without a reproducible testcase it is hard to see what is happening. Are you using Text or TextFlow ? >> For some reason the Text.getImpl_caretShape() seems to think the caret is in the 8th line, which seems to indicate there is some line wrapping width set when it should not (Jim just fixed a bug in that code last week). >> >> Regards, >> Felipe >> >> >>> On Nov 23, 2014, at 11:04 AM, Tom Schindl wrote: >>> >>> Hi, >>> >>> I was debugging a problem in my StyledText-Source editor today and found >>> one of my layout problems is that ListCells (the inner representation of >>> the editor lines is simply ListView) sometime get really strange heights >>> assigned. >>> >>> To display a caret in the UI I'm creating a caret-Shape using >>> Text.getImpl_caretShape but this is causeing my layout problems because >>> under certain conditions the returned cursor is completely wrong. >>> >>> Look for example at the following example. The first line is the bounds >>> of the Text-Element with the content (privata) and the 2nd is the Path >>> created by Text.getImpl_caretShape >>> >>>> BoundingBox [minX:0.0, minY:0.0, minZ:0.0, width:81.01318359375, height:15.0, depth:0.0, maxX:81.01318359375, maxY:15.0, maxZ:0.0] >>>> privata ===> [MoveTo[x=9.00146484375, y=120.0], LineTo[x=9.00146484375, y=135.0]] >>> >>> the correct path is [MoveTo[x=9.00146484375, y=0.0], >>> LineTo[x=9.00146484375, y=15.0]] >>> >>> >>> I've been able to work around this problem for the time being. Anyone an >>> idea what is causing this completely invalid caretShape? >>> >>> Tom >>> >>> -- >>> Thomas Schindl, CTO >>> BestSolution.at EDV Systemhaus GmbH >>> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck >>> http://www.bestsolution.at/ >>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck >> > > -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From felix.bembrick at gmail.com Mon Nov 24 09:46:19 2014 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Mon, 24 Nov 2014 20:46:19 +1100 Subject: What Scene Builder needs YESTERDAY! In-Reply-To: References: Message-ID: I am surprised more people have not expressed an opinion on this. To me, it seems absolutely *vital* to the long term (or any term) success of JavaFX. Haven't any of you ever programmed in Flash? Can you imagine trying to create any of those complex (or even the simple) animations and visualisations *without* a visual editor and by doing it code alone? It wouldn't have been practical (read possible) and similarly, and with JavaFX having even richer features, to do this "by hand". To me, this is the reason why we haven't seen any great animations/visualisations/applications using JavaFX and we probably never will until a visual animation editor is available. Specifying and controlling the motion and appearance of numerous complex objects and their transitions relying exclusively on code would not be possible for even the "gunnest" JFX coder... On 18 November 2014 at 02:48, Richard Bair wrote: > I?m afraid at this time there are no plans for adding an > animation/transition effect editor to Scene Builder, certainly not in the > short-term. > > Thanks > Richard > > > On Nov 13, 2014, at 7:34 PM, Felix Bembrick > wrote: > > > > Java applets were the first "programs" to run inside a web browser and > for > > a (little) while they were flavour of the month. > > > > But then along came Flash which had several advantages such as faster > load > > times, consistent loads and antialiased fonts/graphics and soon > completely > > surpassed applets. > > > > But the MAIN reason why Flash was initially so successful and went on for > > years and years of domination is that the Flash tools had an > > Animation/Timeline Editor pretty much from the beginning. This enabled > > even a novice to drag images around and draw the path they wanted them to > > move along, add all sorts of bouncing effects and sounds and the result > was > > the birth of the online greeting card company. > > > > But Flash soon went on to be so much more. As the Adobe tools improved, > so > > did the SWFs and soon entire websites were written in Flash. > > > > Meanwhile, applet programmers had absolutely nothing remotely similar and > > had to try (and I stress try) to tediously hand code any animations and > > transitions and effects and I don't think it ever worked. > > > > Fast forward 15-20 years and now we have JavaFX which doesn't need to run > > in the browser, has even more features than Flash, uses hardware > > acceleration for superior performance, has a wide range of built-in > > animations, transitions and effects but STILL we have to hand code any > > animation/transitions. > > > > This is INCREDIBLY inefficient and unless Scene Builder incorporates a > > powerful, sophisticated animation/transition and effect editor VERY, VERY > > SOON I fear that the advanced graphics features are never going to be > used > > to their full potential (much to the detriment of JavaFX itself). > > > > Does anyone know if one is in the pipeline? I see this as one of the > most > > vital features for the JavaFX ecosystem to achieve more penetration and, > > eventually, survive. > > > > Felix > > From tbee at tbee.org Mon Nov 24 10:02:52 2014 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 24 Nov 2014 11:02:52 +0100 Subject: What Scene Builder needs YESTERDAY! In-Reply-To: References: Message-ID: <5473024C.5080805@tbee.org> I do not think that JavaFX is aiming at replacing flash, HTML and javascript are doing a great job there, hence animations are not equally important as they were for flash. Tom On 24-11-2014 10:46, Felix Bembrick wrote: > I am surprised more people have not expressed an opinion on this. To me, > it seems absolutely *vital* to the long term (or any term) success of > JavaFX. > > Haven't any of you ever programmed in Flash? Can you imagine trying to > create any of those complex (or even the simple) animations and > visualisations *without* a visual editor and by doing it code alone? It > wouldn't have been practical (read possible) and similarly, and with JavaFX > having even richer features, to do this "by hand". > > To me, this is the reason why we haven't seen any great > animations/visualisations/applications using JavaFX and we probably never > will until a visual animation editor is available. Specifying and > controlling the motion and appearance of numerous complex objects and their > transitions relying exclusively on code would not be possible for even the > "gunnest" JFX coder... > > On 18 November 2014 at 02:48, Richard Bair wrote: > >> I?m afraid at this time there are no plans for adding an >> animation/transition effect editor to Scene Builder, certainly not in the >> short-term. >> >> Thanks >> Richard >> >>> On Nov 13, 2014, at 7:34 PM, Felix Bembrick >> wrote: >>> Java applets were the first "programs" to run inside a web browser and >> for >>> a (little) while they were flavour of the month. >>> >>> But then along came Flash which had several advantages such as faster >> load >>> times, consistent loads and antialiased fonts/graphics and soon >> completely >>> surpassed applets. >>> >>> But the MAIN reason why Flash was initially so successful and went on for >>> years and years of domination is that the Flash tools had an >>> Animation/Timeline Editor pretty much from the beginning. This enabled >>> even a novice to drag images around and draw the path they wanted them to >>> move along, add all sorts of bouncing effects and sounds and the result >> was >>> the birth of the online greeting card company. >>> >>> But Flash soon went on to be so much more. As the Adobe tools improved, >> so >>> did the SWFs and soon entire websites were written in Flash. >>> >>> Meanwhile, applet programmers had absolutely nothing remotely similar and >>> had to try (and I stress try) to tediously hand code any animations and >>> transitions and effects and I don't think it ever worked. >>> >>> Fast forward 15-20 years and now we have JavaFX which doesn't need to run >>> in the browser, has even more features than Flash, uses hardware >>> acceleration for superior performance, has a wide range of built-in >>> animations, transitions and effects but STILL we have to hand code any >>> animation/transitions. >>> >>> This is INCREDIBLY inefficient and unless Scene Builder incorporates a >>> powerful, sophisticated animation/transition and effect editor VERY, VERY >>> SOON I fear that the advanced graphics features are never going to be >> used >>> to their full potential (much to the detriment of JavaFX itself). >>> >>> Does anyone know if one is in the pipeline? I see this as one of the >> most >>> vital features for the JavaFX ecosystem to achieve more penetration and, >>> eventually, survive. >>> >>> Felix >> From felix.bembrick at gmail.com Mon Nov 24 10:20:09 2014 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Mon, 24 Nov 2014 21:20:09 +1100 Subject: What Scene Builder needs YESTERDAY! In-Reply-To: <5473024C.5080805@tbee.org> References: <5473024C.5080805@tbee.org> Message-ID: Really? My point is, why have such good built-on classes to support the building of everything from simple animations to complex visualisations if it is practically impossible to do so? On 24 November 2014 at 21:02, Tom Eugelink wrote: > I do not think that JavaFX is aiming at replacing flash, HTML and > javascript are doing a great job there, hence animations are not equally > important as they were for flash. > > Tom > > > > On 24-11-2014 10:46, Felix Bembrick wrote: > >> I am surprised more people have not expressed an opinion on this. To me, >> it seems absolutely *vital* to the long term (or any term) success of >> JavaFX. >> >> Haven't any of you ever programmed in Flash? Can you imagine trying to >> create any of those complex (or even the simple) animations and >> visualisations *without* a visual editor and by doing it code alone? It >> wouldn't have been practical (read possible) and similarly, and with >> JavaFX >> having even richer features, to do this "by hand". >> >> To me, this is the reason why we haven't seen any great >> animations/visualisations/applications using JavaFX and we probably never >> will until a visual animation editor is available. Specifying and >> controlling the motion and appearance of numerous complex objects and >> their >> transitions relying exclusively on code would not be possible for even the >> "gunnest" JFX coder... >> >> On 18 November 2014 at 02:48, Richard Bair >> wrote: >> >> I?m afraid at this time there are no plans for adding an >>> animation/transition effect editor to Scene Builder, certainly not in the >>> short-term. >>> >>> Thanks >>> Richard >>> >>> On Nov 13, 2014, at 7:34 PM, Felix Bembrick >>>> >>> wrote: >>> >>>> Java applets were the first "programs" to run inside a web browser and >>>> >>> for >>> >>>> a (little) while they were flavour of the month. >>>> >>>> But then along came Flash which had several advantages such as faster >>>> >>> load >>> >>>> times, consistent loads and antialiased fonts/graphics and soon >>>> >>> completely >>> >>>> surpassed applets. >>>> >>>> But the MAIN reason why Flash was initially so successful and went on >>>> for >>>> years and years of domination is that the Flash tools had an >>>> Animation/Timeline Editor pretty much from the beginning. This enabled >>>> even a novice to drag images around and draw the path they wanted them >>>> to >>>> move along, add all sorts of bouncing effects and sounds and the result >>>> >>> was >>> >>>> the birth of the online greeting card company. >>>> >>>> But Flash soon went on to be so much more. As the Adobe tools improved, >>>> >>> so >>> >>>> did the SWFs and soon entire websites were written in Flash. >>>> >>>> Meanwhile, applet programmers had absolutely nothing remotely similar >>>> and >>>> had to try (and I stress try) to tediously hand code any animations and >>>> transitions and effects and I don't think it ever worked. >>>> >>>> Fast forward 15-20 years and now we have JavaFX which doesn't need to >>>> run >>>> in the browser, has even more features than Flash, uses hardware >>>> acceleration for superior performance, has a wide range of built-in >>>> animations, transitions and effects but STILL we have to hand code any >>>> animation/transitions. >>>> >>>> This is INCREDIBLY inefficient and unless Scene Builder incorporates a >>>> powerful, sophisticated animation/transition and effect editor VERY, >>>> VERY >>>> SOON I fear that the advanced graphics features are never going to be >>>> >>> used >>> >>>> to their full potential (much to the detriment of JavaFX itself). >>>> >>>> Does anyone know if one is in the pipeline? I see this as one of the >>>> >>> most >>> >>>> vital features for the JavaFX ecosystem to achieve more penetration and, >>>> eventually, survive. >>>> >>>> Felix >>>> >>> >>> > From mikegps1 at gmail.com Mon Nov 24 10:39:31 2014 From: mikegps1 at gmail.com (Mike) Date: Mon, 24 Nov 2014 02:39:31 -0800 Subject: What Scene Builder needs YESTERDAY! In-Reply-To: References: <5473024C.5080805@tbee.org> Message-ID: Actually Felix Everybody is waiting for you to write such a tool. I don't think anybody has scene your Disney Animation Movie Credits but me. On Mon, Nov 24, 2014 at 2:20 AM, Felix Bembrick wrote: > Really? My point is, why have such good built-on classes to support the > building of everything from simple animations to complex visualisations if > it is practically impossible to do so? > > On 24 November 2014 at 21:02, Tom Eugelink wrote: > > > I do not think that JavaFX is aiming at replacing flash, HTML and > > javascript are doing a great job there, hence animations are not equally > > important as they were for flash. > > > > Tom > > > > > > > > On 24-11-2014 10:46, Felix Bembrick wrote: > > > >> I am surprised more people have not expressed an opinion on this. To > me, > >> it seems absolutely *vital* to the long term (or any term) success of > >> JavaFX. > >> > >> Haven't any of you ever programmed in Flash? Can you imagine trying to > >> create any of those complex (or even the simple) animations and > >> visualisations *without* a visual editor and by doing it code alone? It > >> wouldn't have been practical (read possible) and similarly, and with > >> JavaFX > >> having even richer features, to do this "by hand". > >> > >> To me, this is the reason why we haven't seen any great > >> animations/visualisations/applications using JavaFX and we probably > never > >> will until a visual animation editor is available. Specifying and > >> controlling the motion and appearance of numerous complex objects and > >> their > >> transitions relying exclusively on code would not be possible for even > the > >> "gunnest" JFX coder... > >> > >> On 18 November 2014 at 02:48, Richard Bair > >> wrote: > >> > >> I?m afraid at this time there are no plans for adding an > >>> animation/transition effect editor to Scene Builder, certainly not in > the > >>> short-term. > >>> > >>> Thanks > >>> Richard > >>> > >>> On Nov 13, 2014, at 7:34 PM, Felix Bembrick > > >>>> > >>> wrote: > >>> > >>>> Java applets were the first "programs" to run inside a web browser and > >>>> > >>> for > >>> > >>>> a (little) while they were flavour of the month. > >>>> > >>>> But then along came Flash which had several advantages such as faster > >>>> > >>> load > >>> > >>>> times, consistent loads and antialiased fonts/graphics and soon > >>>> > >>> completely > >>> > >>>> surpassed applets. > >>>> > >>>> But the MAIN reason why Flash was initially so successful and went on > >>>> for > >>>> years and years of domination is that the Flash tools had an > >>>> Animation/Timeline Editor pretty much from the beginning. This > enabled > >>>> even a novice to drag images around and draw the path they wanted them > >>>> to > >>>> move along, add all sorts of bouncing effects and sounds and the > result > >>>> > >>> was > >>> > >>>> the birth of the online greeting card company. > >>>> > >>>> But Flash soon went on to be so much more. As the Adobe tools > improved, > >>>> > >>> so > >>> > >>>> did the SWFs and soon entire websites were written in Flash. > >>>> > >>>> Meanwhile, applet programmers had absolutely nothing remotely similar > >>>> and > >>>> had to try (and I stress try) to tediously hand code any animations > and > >>>> transitions and effects and I don't think it ever worked. > >>>> > >>>> Fast forward 15-20 years and now we have JavaFX which doesn't need to > >>>> run > >>>> in the browser, has even more features than Flash, uses hardware > >>>> acceleration for superior performance, has a wide range of built-in > >>>> animations, transitions and effects but STILL we have to hand code any > >>>> animation/transitions. > >>>> > >>>> This is INCREDIBLY inefficient and unless Scene Builder incorporates a > >>>> powerful, sophisticated animation/transition and effect editor VERY, > >>>> VERY > >>>> SOON I fear that the advanced graphics features are never going to be > >>>> > >>> used > >>> > >>>> to their full potential (much to the detriment of JavaFX itself). > >>>> > >>>> Does anyone know if one is in the pipeline? I see this as one of the > >>>> > >>> most > >>> > >>>> vital features for the JavaFX ecosystem to achieve more penetration > and, > >>>> eventually, survive. > >>>> > >>>> Felix > >>>> > >>> > >>> > > > From mikegps1 at gmail.com Mon Nov 24 10:39:59 2014 From: mikegps1 at gmail.com (Mike) Date: Mon, 24 Nov 2014 02:39:59 -0800 Subject: What Scene Builder needs YESTERDAY! In-Reply-To: References: <5473024C.5080805@tbee.org> Message-ID: thats funny -Scene! boy I can't spell On Mon, Nov 24, 2014 at 2:39 AM, Mike wrote: > Actually Felix Everybody is waiting for you to write such a tool. I don't > think anybody has scene your Disney Animation Movie Credits but me. > > On Mon, Nov 24, 2014 at 2:20 AM, Felix Bembrick > wrote: > >> Really? My point is, why have such good built-on classes to support the >> building of everything from simple animations to complex visualisations if >> it is practically impossible to do so? >> >> On 24 November 2014 at 21:02, Tom Eugelink wrote: >> >> > I do not think that JavaFX is aiming at replacing flash, HTML and >> > javascript are doing a great job there, hence animations are not equally >> > important as they were for flash. >> > >> > Tom >> > >> > >> > >> > On 24-11-2014 10:46, Felix Bembrick wrote: >> > >> >> I am surprised more people have not expressed an opinion on this. To >> me, >> >> it seems absolutely *vital* to the long term (or any term) success of >> >> JavaFX. >> >> >> >> Haven't any of you ever programmed in Flash? Can you imagine trying to >> >> create any of those complex (or even the simple) animations and >> >> visualisations *without* a visual editor and by doing it code alone? >> It >> >> wouldn't have been practical (read possible) and similarly, and with >> >> JavaFX >> >> having even richer features, to do this "by hand". >> >> >> >> To me, this is the reason why we haven't seen any great >> >> animations/visualisations/applications using JavaFX and we probably >> never >> >> will until a visual animation editor is available. Specifying and >> >> controlling the motion and appearance of numerous complex objects and >> >> their >> >> transitions relying exclusively on code would not be possible for even >> the >> >> "gunnest" JFX coder... >> >> >> >> On 18 November 2014 at 02:48, Richard Bair >> >> wrote: >> >> >> >> I?m afraid at this time there are no plans for adding an >> >>> animation/transition effect editor to Scene Builder, certainly not in >> the >> >>> short-term. >> >>> >> >>> Thanks >> >>> Richard >> >>> >> >>> On Nov 13, 2014, at 7:34 PM, Felix Bembrick < >> felix.bembrick at gmail.com> >> >>>> >> >>> wrote: >> >>> >> >>>> Java applets were the first "programs" to run inside a web browser >> and >> >>>> >> >>> for >> >>> >> >>>> a (little) while they were flavour of the month. >> >>>> >> >>>> But then along came Flash which had several advantages such as faster >> >>>> >> >>> load >> >>> >> >>>> times, consistent loads and antialiased fonts/graphics and soon >> >>>> >> >>> completely >> >>> >> >>>> surpassed applets. >> >>>> >> >>>> But the MAIN reason why Flash was initially so successful and went on >> >>>> for >> >>>> years and years of domination is that the Flash tools had an >> >>>> Animation/Timeline Editor pretty much from the beginning. This >> enabled >> >>>> even a novice to drag images around and draw the path they wanted >> them >> >>>> to >> >>>> move along, add all sorts of bouncing effects and sounds and the >> result >> >>>> >> >>> was >> >>> >> >>>> the birth of the online greeting card company. >> >>>> >> >>>> But Flash soon went on to be so much more. As the Adobe tools >> improved, >> >>>> >> >>> so >> >>> >> >>>> did the SWFs and soon entire websites were written in Flash. >> >>>> >> >>>> Meanwhile, applet programmers had absolutely nothing remotely similar >> >>>> and >> >>>> had to try (and I stress try) to tediously hand code any animations >> and >> >>>> transitions and effects and I don't think it ever worked. >> >>>> >> >>>> Fast forward 15-20 years and now we have JavaFX which doesn't need to >> >>>> run >> >>>> in the browser, has even more features than Flash, uses hardware >> >>>> acceleration for superior performance, has a wide range of built-in >> >>>> animations, transitions and effects but STILL we have to hand code >> any >> >>>> animation/transitions. >> >>>> >> >>>> This is INCREDIBLY inefficient and unless Scene Builder incorporates >> a >> >>>> powerful, sophisticated animation/transition and effect editor VERY, >> >>>> VERY >> >>>> SOON I fear that the advanced graphics features are never going to be >> >>>> >> >>> used >> >>> >> >>>> to their full potential (much to the detriment of JavaFX itself). >> >>>> >> >>>> Does anyone know if one is in the pipeline? I see this as one of the >> >>>> >> >>> most >> >>> >> >>>> vital features for the JavaFX ecosystem to achieve more penetration >> and, >> >>>> eventually, survive. >> >>>> >> >>>> Felix >> >>>> >> >>> >> >>> >> > >> > > From tbee at tbee.org Mon Nov 24 11:04:01 2014 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 24 Nov 2014 12:04:01 +0100 Subject: What Scene Builder needs YESTERDAY! In-Reply-To: References: <5473024C.5080805@tbee.org> Message-ID: <547310A1.2010700@tbee.org> I have no problems using JavaFX's animations for my purposes, which are decorative effects. I do not need an editor for that, forced me to use it and it probably will even get in my way. Which BTW was the case with the Flash coding that I have done; I hated that Flash EDI, it was way too much focussed on animation. Actually that is why Adobe created Flex, which basically was flash-for-developers (instead of animators). JavaFX is more a alternative for Flex than Flash. Tom On 24-11-2014 11:20, Felix Bembrick wrote: > Really? My point is, why have such good built-on classes to support the building of everything from simple animations to complex visualisations if it is practically impossible to do so? > > On 24 November 2014 at 21:02, Tom Eugelink > wrote: > > I do not think that JavaFX is aiming at replacing flash, HTML and javascript are doing a great job there, hence animations are not equally important as they were for flash. > > Tom > > > > On 24-11-2014 10:46, Felix Bembrick wrote: > > I am surprised more people have not expressed an opinion on this. To me, > it seems absolutely *vital* to the long term (or any term) success of > JavaFX. > > Haven't any of you ever programmed in Flash? Can you imagine trying to > create any of those complex (or even the simple) animations and > visualisations *without* a visual editor and by doing it code alone? It > wouldn't have been practical (read possible) and similarly, and with JavaFX > having even richer features, to do this "by hand". > > To me, this is the reason why we haven't seen any great > animations/visualisations/applications using JavaFX and we probably never > will until a visual animation editor is available. Specifying and > controlling the motion and appearance of numerous complex objects and their > transitions relying exclusively on code would not be possible for even the > "gunnest" JFX coder... > > On 18 November 2014 at 02:48, Richard Bair > wrote: > > I?m afraid at this time there are no plans for adding an > animation/transition effect editor to Scene Builder, certainly not in the > short-term. > > Thanks > Richard > > On Nov 13, 2014, at 7:34 PM, Felix Bembrick > > > wrote: > > Java applets were the first "programs" to run inside a web browser and > > for > > a (little) while they were flavour of the month. > > But then along came Flash which had several advantages such as faster > > load > > times, consistent loads and antialiased fonts/graphics and soon > > completely > > surpassed applets. > > But the MAIN reason why Flash was initially so successful and went on for > years and years of domination is that the Flash tools had an > Animation/Timeline Editor pretty much from the beginning. This enabled > even a novice to drag images around and draw the path they wanted them to > move along, add all sorts of bouncing effects and sounds and the result > > was > > the birth of the online greeting card company. > > But Flash soon went on to be so much more. As the Adobe tools improved, > > so > > did the SWFs and soon entire websites were written in Flash. > > Meanwhile, applet programmers had absolutely nothing remotely similar and > had to try (and I stress try) to tediously hand code any animations and > transitions and effects and I don't think it ever worked. > > Fast forward 15-20 years and now we have JavaFX which doesn't need to run > in the browser, has even more features than Flash, uses hardware > acceleration for superior performance, has a wide range of built-in > animations, transitions and effects but STILL we have to hand code any > animation/transitions. > > This is INCREDIBLY inefficient and unless Scene Builder incorporates a > powerful, sophisticated animation/transition and effect editor VERY, VERY > SOON I fear that the advanced graphics features are never going to be > > used > > to their full potential (much to the detriment of JavaFX itself). > > Does anyone know if one is in the pipeline? I see this as one of the > > most > > vital features for the JavaFX ecosystem to achieve more penetration and, > eventually, survive. > > Felix > > > > From felix.bembrick at gmail.com Mon Nov 24 12:18:07 2014 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Mon, 24 Nov 2014 23:18:07 +1100 Subject: What Scene Builder needs YESTERDAY! In-Reply-To: <547310A1.2010700@tbee.org> References: <5473024C.5080805@tbee.org> <547310A1.2010700@tbee.org> Message-ID: JavaFX should not be seen as a "replacement" for anything or an "alternative". It has characteristics of both Flash and Flex along with Silverlight and especially Qt, (not to mention even HTML5/CSS/JS), but is a separate and distinct product in its own class. Just because the Flash visual editor may have "got in the way" of your desire to code directly, that doesn't mean that JavaFX should not have such an editor for all the same reasons and use cases that Flash had one. Sure, for *your* purposes of "decorative effects", I am confident that coding would suffice but for *my* purposes (and anyone who has worked in the animation industry or worked creating visualisations) I really need a visual editor of the ilk I have described. Why just make one class of user happy but seriously limit the effectiveness of another (and in doing so possibly significantly limit the market of JavaFX)? I am sure at least one of the developers on the JavaFX team has at one point at least envisaged JavaFX being used for complex animations, visualisations or even non-trivial games. What they need to do now is make such use cases feasible. On 24 November 2014 at 22:04, Tom Eugelink wrote: > I have no problems using JavaFX's animations for my purposes, which are > decorative effects. I do not need an editor for that, forced me to use it > and it probably will even get in my way. Which BTW was the case with the > Flash coding that I have done; I hated that Flash EDI, it was way too much > focussed on animation. Actually that is why Adobe created Flex, which > basically was flash-for-developers (instead of animators). JavaFX is more a > alternative for Flex than Flash. > > Tom > > > > On 24-11-2014 11:20, Felix Bembrick wrote: > > Really? My point is, why have such good built-on classes to support the > building of everything from simple animations to complex visualisations if > it is practically impossible to do so? > > On 24 November 2014 at 21:02, Tom Eugelink wrote: > >> I do not think that JavaFX is aiming at replacing flash, HTML and >> javascript are doing a great job there, hence animations are not equally >> important as they were for flash. >> >> Tom >> >> >> >> On 24-11-2014 10:46, Felix Bembrick wrote: >> >>> I am surprised more people have not expressed an opinion on this. To me, >>> it seems absolutely *vital* to the long term (or any term) success of >>> JavaFX. >>> >>> Haven't any of you ever programmed in Flash? Can you imagine trying to >>> create any of those complex (or even the simple) animations and >>> visualisations *without* a visual editor and by doing it code alone? It >>> wouldn't have been practical (read possible) and similarly, and with >>> JavaFX >>> having even richer features, to do this "by hand". >>> >>> To me, this is the reason why we haven't seen any great >>> animations/visualisations/applications using JavaFX and we probably never >>> will until a visual animation editor is available. Specifying and >>> controlling the motion and appearance of numerous complex objects and >>> their >>> transitions relying exclusively on code would not be possible for even >>> the >>> "gunnest" JFX coder... >>> >>> On 18 November 2014 at 02:48, Richard Bair >>> wrote: >>> >>> I?m afraid at this time there are no plans for adding an >>>> animation/transition effect editor to Scene Builder, certainly not in >>>> the >>>> short-term. >>>> >>>> Thanks >>>> Richard >>>> >>>> On Nov 13, 2014, at 7:34 PM, Felix Bembrick >>>>> >>>> wrote: >>>> >>>>> Java applets were the first "programs" to run inside a web browser and >>>>> >>>> for >>>> >>>>> a (little) while they were flavour of the month. >>>>> >>>>> But then along came Flash which had several advantages such as faster >>>>> >>>> load >>>> >>>>> times, consistent loads and antialiased fonts/graphics and soon >>>>> >>>> completely >>>> >>>>> surpassed applets. >>>>> >>>>> But the MAIN reason why Flash was initially so successful and went on >>>>> for >>>>> years and years of domination is that the Flash tools had an >>>>> Animation/Timeline Editor pretty much from the beginning. This enabled >>>>> even a novice to drag images around and draw the path they wanted them >>>>> to >>>>> move along, add all sorts of bouncing effects and sounds and the result >>>>> >>>> was >>>> >>>>> the birth of the online greeting card company. >>>>> >>>>> But Flash soon went on to be so much more. As the Adobe tools >>>>> improved, >>>>> >>>> so >>>> >>>>> did the SWFs and soon entire websites were written in Flash. >>>>> >>>>> Meanwhile, applet programmers had absolutely nothing remotely similar >>>>> and >>>>> had to try (and I stress try) to tediously hand code any animations and >>>>> transitions and effects and I don't think it ever worked. >>>>> >>>>> Fast forward 15-20 years and now we have JavaFX which doesn't need to >>>>> run >>>>> in the browser, has even more features than Flash, uses hardware >>>>> acceleration for superior performance, has a wide range of built-in >>>>> animations, transitions and effects but STILL we have to hand code any >>>>> animation/transitions. >>>>> >>>>> This is INCREDIBLY inefficient and unless Scene Builder incorporates a >>>>> powerful, sophisticated animation/transition and effect editor VERY, >>>>> VERY >>>>> SOON I fear that the advanced graphics features are never going to be >>>>> >>>> used >>>> >>>>> to their full potential (much to the detriment of JavaFX itself). >>>>> >>>>> Does anyone know if one is in the pipeline? I see this as one of the >>>>> >>>> most >>>> >>>>> vital features for the JavaFX ecosystem to achieve more penetration >>>>> and, >>>>> eventually, survive. >>>>> >>>>> Felix >>>>> >>>> >>>> >> > > From ryan at jaeb.ca Mon Nov 24 12:19:57 2014 From: ryan at jaeb.ca (Ryan Jaeb) Date: Mon, 24 Nov 2014 06:19:57 -0600 Subject: Non-portable config in Scene Builder 2 Message-ID: Hi, Are there any plans to improve the portability of Scene Builder's configuration? To give a specific example of what I mean, I asked a question related to previewed style sheets on the forum: https://community.oracle.com/message/12734301#12734301 For me, any features that store config info in the registry like that are unusable. As a general rule, if I can't commit something to a VCS, I don't depend on it. Of all the external tools I use, the ones I find easiest to work with have a project (config) file that I can put in my project directory and commit to VCS. All of the project config is stored in that file and all paths are relative to that file. Are there any plans to introduce the concept of a project into Scene Builder? If not, are there any plans to reintroduce the Scene Builder specific tags like the one I asked about in the above forum post? Ryan From tbee at tbee.org Mon Nov 24 12:37:16 2014 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 24 Nov 2014 13:37:16 +0100 Subject: What Scene Builder needs YESTERDAY! In-Reply-To: References: <5473024C.5080805@tbee.org> <547310A1.2010700@tbee.org> Message-ID: <5473267C.6060104@tbee.org> Oh, you are right, if the JavaFX team does not need to make choices on where to invest their precious time, then all possible usages could be implemented immediately. Unfortunately they too have to place priorities and then the most likely usage will get implemented first (since most usages already have some existing platform, "alternative" or "replacement" for an that platform comes to mind). Apparently it is not animations, personally I'm still hoping 3rd party controls support in SceneBuilder will get higher on the list, but I'm not getting my hopes up. But as Mike pointed out; it is a missing functionality, go build it! ;-) Tom On 24-11-2014 13:18, Felix Bembrick wrote: > JavaFX should not be seen as a "replacement" for anything or an "alternative". It has characteristics of both Flash and Flex along with Silverlight and especially Qt, (not to mention even HTML5/CSS/JS), but is a separate and distinct product in its own class. > > Just because the Flash visual editor may have "got in the way" of your desire to code directly, that doesn't mean that JavaFX should not have such an editor for all the same reasons and use cases that Flash had one. > > Sure, for *your* purposes of "decorative effects", I am confident that coding would suffice but for *my* purposes (and anyone who has worked in the animation industry or worked creating visualisations) I really need a visual editor of the ilk I have described. > > Why just make one class of user happy but seriously limit the effectiveness of another (and in doing so possibly significantly limit the market of JavaFX)? > > I am sure at least one of the developers on the JavaFX team has at one point at least envisaged JavaFX being used for complex animations, visualisations or even non-trivial games. What they need to do now is make such use cases feasible. > > On 24 November 2014 at 22:04, Tom Eugelink > wrote: > > I have no problems using JavaFX's animations for my purposes, which are decorative effects. I do not need an editor for that, forced me to use it and it probably will even get in my way. Which BTW was the case with the Flash coding that I have done; I hated that Flash EDI, it was way too much focussed on animation. Actually that is why Adobe created Flex, which basically was flash-for-developers (instead of animators). JavaFX is more a alternative for Flex than Flash. > > Tom > > > > On 24-11-2014 11:20, Felix Bembrick wrote: >> Really? My point is, why have such good built-on classes to support the building of everything from simple animations to complex visualisations if it is practically impossible to do so? >> >> On 24 November 2014 at 21:02, Tom Eugelink > wrote: >> >> I do not think that JavaFX is aiming at replacing flash, HTML and javascript are doing a great job there, hence animations are not equally important as they were for flash. >> >> Tom >> >> >> >> On 24-11-2014 10:46, Felix Bembrick wrote: >> >> I am surprised more people have not expressed an opinion on this. To me, >> it seems absolutely *vital* to the long term (or any term) success of >> JavaFX. >> >> Haven't any of you ever programmed in Flash? Can you imagine trying to >> create any of those complex (or even the simple) animations and >> visualisations *without* a visual editor and by doing it code alone? It >> wouldn't have been practical (read possible) and similarly, and with JavaFX >> having even richer features, to do this "by hand". >> >> To me, this is the reason why we haven't seen any great >> animations/visualisations/applications using JavaFX and we probably never >> will until a visual animation editor is available. Specifying and >> controlling the motion and appearance of numerous complex objects and their >> transitions relying exclusively on code would not be possible for even the >> "gunnest" JFX coder... >> >> On 18 November 2014 at 02:48, Richard Bair > wrote: >> >> I?m afraid at this time there are no plans for adding an >> animation/transition effect editor to Scene Builder, certainly not in the >> short-term. >> >> Thanks >> Richard >> >> On Nov 13, 2014, at 7:34 PM, Felix Bembrick > >> >> wrote: >> >> Java applets were the first "programs" to run inside a web browser and >> >> for >> >> a (little) while they were flavour of the month. >> >> But then along came Flash which had several advantages such as faster >> >> load >> >> times, consistent loads and antialiased fonts/graphics and soon >> >> completely >> >> surpassed applets. >> >> But the MAIN reason why Flash was initially so successful and went on for >> years and years of domination is that the Flash tools had an >> Animation/Timeline Editor pretty much from the beginning. This enabled >> even a novice to drag images around and draw the path they wanted them to >> move along, add all sorts of bouncing effects and sounds and the result >> >> was >> >> the birth of the online greeting card company. >> >> But Flash soon went on to be so much more. As the Adobe tools improved, >> >> so >> >> did the SWFs and soon entire websites were written in Flash. >> >> Meanwhile, applet programmers had absolutely nothing remotely similar and >> had to try (and I stress try) to tediously hand code any animations and >> transitions and effects and I don't think it ever worked. >> >> Fast forward 15-20 years and now we have JavaFX which doesn't need to run >> in the browser, has even more features than Flash, uses hardware >> acceleration for superior performance, has a wide range of built-in >> animations, transitions and effects but STILL we have to hand code any >> animation/transitions. >> >> This is INCREDIBLY inefficient and unless Scene Builder incorporates a >> powerful, sophisticated animation/transition and effect editor VERY, VERY >> SOON I fear that the advanced graphics features are never going to be >> >> used >> >> to their full potential (much to the detriment of JavaFX itself). >> >> Does anyone know if one is in the pipeline? I see this as one of the >> >> most >> >> vital features for the JavaFX ecosystem to achieve more penetration and, >> eventually, survive. >> >> Felix >> >> >> >> > > From kevin.rushforth at oracle.com Mon Nov 24 12:59:05 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 24 Nov 2014 04:59:05 -0800 Subject: [8u40] review request: RT-39182: Enable building 32-bit Linux on 64-bit systems In-Reply-To: <5472C9C8.6080103@oracle.com> References: <54713871.2090502@oracle.com> <5472C9C8.6080103@oracle.com> Message-ID: <54732B99.9060604@oracle.com> > Can we build 64 bit libraries on 32 bit systems ? If so then modify this patch accordingly. No, this will not work and is not something we would ever intend to do even if it were possible. Btw, please add review comments to JIRA. Thanks. -- Kevin Kirill Kirichenko wrote: > Can we build 64 bit libraries on 32 bit systems ? If so then modify > this patch accordingly. > K > > On 23.11.2014 4:29, Kevin Rushforth wrote: >> Dave, Kirill, Anton, Chris, >> >> Please review the following build changes to enable building 32-bit >> graphics, media, webkit, and packager binaries on a 64-bit Linux system. >> >> https://javafx-jira.kenai.com/browse/RT-39182 >> http://cr.openjdk.java.net/~kcr/RT-39182/webrev.01/ >> >> Details are in JIRA. >> >> -- Kevin >> From neugens.limasoftware at gmail.com Mon Nov 24 14:19:49 2014 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 24 Nov 2014 15:19:49 +0100 Subject: Linux (centos), openjdk 8, openjfx and netbeans 8 In-Reply-To: <5472E2D3.2040809@oracle.com> References: <1416667339.70989799@f322.i.mail.ru> <5472E2D3.2040809@oracle.com> Message-ID: Hi Anton, This is new to me, I think OpenJDK 8 does *not* contain OpenJFX (or JavaFX). You are probably referring to the Oracle closed JDK. Cheers, Mario Il 24/nov/2014 08:49 "Anton V. Tarasov" ha scritto: > Hello Alexander, > > On 22.11.2014 17:42, ????????? ???????? wrote: > >> Hello everybody. >> I installed at centos 6.4 openjdk 8, netbeans 8 and build openjfx (via >> gradle). The only thing I can't uderstand is how to make netbeans work with >> built openjfx sdk. As openjdx sdk is in folder /temp while jdk is in >> /usr/lib/jvm/java-8... I can't undertand how to add openjfx to netbeans as >> everywhere people say that jfx is already in jdk. >> So, what now should I do to make all these work together? >> > > openjdk8 sdk contains the openjfx sdk binaries. So, you don't need to > change the classpath in order to compile or run your jfx application. > Simply add your jdk as a Java Platform. > > In case you want to try your own openjfx build with openjdk in netbeans, > you can do the following. > > In the "Project Properties"dialog of your project, select "Libraries" and > add jfxrt.jar to the Compile-time and Run-time libraries. Please, find > jfxrt.jar in the "artifacts" of your openjfx workspace: > > /artifacts/sdk/rt/lib/ext/jfxrt.jar > > Also, you can find the netbeans projects of the openjfx source tree under > the following dir: > > /rt/netbeans > > Regards, > Anton. > > From jeff at reportmill.com Mon Nov 24 14:38:52 2014 From: jeff at reportmill.com (Jeff Martin) Date: Mon, 24 Nov 2014 08:38:52 -0600 Subject: What Scene Builder needs YESTERDAY! In-Reply-To: <5473267C.6060104@tbee.org> References: <5473024C.5080805@tbee.org> <547310A1.2010700@tbee.org> <5473267C.6060104@tbee.org> Message-ID: <9FDA3D29-AC8A-4ABD-9795-03FA76706B33@reportmill.com> I actually have a bit of this in SnapCode - you can draw and configure arbitrary shapes with fills and effects, bring up the animation inspector and set the time slider to a new time and reconfigure attributes for that new key-frame (such as size, location, rotation, scale, skew, color), then save and launch to see the animation. Here is a quick demo: SnapCode JavaFX Animation If you create a snap ?WebPage? subclass by the same name, this JavaFX is automatically loaded into it and you have programatic access and control over it. I also have support for animation along a path and morphing animation, but that code hasn?t had much love recently. I wish I could get this stuff polished up and out to the real world faster, but I?m a little under-resourced. :-) jeff On Nov 24, 2014, at 6:37 AM, Tom Eugelink wrote: > Oh, you are right, if the JavaFX team does not need to make choices on where to invest their precious time, then all possible usages could be implemented immediately. Unfortunately they too have to place priorities and then the most likely usage will get implemented first (since most usages already have some existing platform, "alternative" or "replacement" for an that platform comes to mind). > > Apparently it is not animations, personally I'm still hoping 3rd party controls support in SceneBuilder will get higher on the list, but I'm not getting my hopes up. But as Mike pointed out; it is a missing functionality, go build it! ;-) > > Tom > > > On 24-11-2014 13:18, Felix Bembrick wrote: >> JavaFX should not be seen as a "replacement" for anything or an "alternative". It has characteristics of both Flash and Flex along with Silverlight and especially Qt, (not to mention even HTML5/CSS/JS), but is a separate and distinct product in its own class. >> >> Just because the Flash visual editor may have "got in the way" of your desire to code directly, that doesn't mean that JavaFX should not have such an editor for all the same reasons and use cases that Flash had one. >> >> Sure, for *your* purposes of "decorative effects", I am confident that coding would suffice but for *my* purposes (and anyone who has worked in the animation industry or worked creating visualisations) I really need a visual editor of the ilk I have described. >> >> Why just make one class of user happy but seriously limit the effectiveness of another (and in doing so possibly significantly limit the market of JavaFX)? >> >> I am sure at least one of the developers on the JavaFX team has at one point at least envisaged JavaFX being used for complex animations, visualisations or even non-trivial games. What they need to do now is make such use cases feasible. >> >> On 24 November 2014 at 22:04, Tom Eugelink > wrote: >> >> I have no problems using JavaFX's animations for my purposes, which are decorative effects. I do not need an editor for that, forced me to use it and it probably will even get in my way. Which BTW was the case with the Flash coding that I have done; I hated that Flash EDI, it was way too much focussed on animation. Actually that is why Adobe created Flex, which basically was flash-for-developers (instead of animators). JavaFX is more a alternative for Flex than Flash. >> >> Tom >> >> >> >> On 24-11-2014 11:20, Felix Bembrick wrote: >>> Really? My point is, why have such good built-on classes to support the building of everything from simple animations to complex visualisations if it is practically impossible to do so? >>> >>> On 24 November 2014 at 21:02, Tom Eugelink > wrote: >>> >>> I do not think that JavaFX is aiming at replacing flash, HTML and javascript are doing a great job there, hence animations are not equally important as they were for flash. >>> >>> Tom >>> >>> >>> >>> On 24-11-2014 10:46, Felix Bembrick wrote: >>> >>> I am surprised more people have not expressed an opinion on this. To me, >>> it seems absolutely *vital* to the long term (or any term) success of >>> JavaFX. >>> >>> Haven't any of you ever programmed in Flash? Can you imagine trying to >>> create any of those complex (or even the simple) animations and >>> visualisations *without* a visual editor and by doing it code alone? It >>> wouldn't have been practical (read possible) and similarly, and with JavaFX >>> having even richer features, to do this "by hand". >>> >>> To me, this is the reason why we haven't seen any great >>> animations/visualisations/applications using JavaFX and we probably never >>> will until a visual animation editor is available. Specifying and >>> controlling the motion and appearance of numerous complex objects and their >>> transitions relying exclusively on code would not be possible for even the >>> "gunnest" JFX coder... >>> >>> On 18 November 2014 at 02:48, Richard Bair > wrote: >>> >>> I?m afraid at this time there are no plans for adding an >>> animation/transition effect editor to Scene Builder, certainly not in the >>> short-term. >>> >>> Thanks >>> Richard >>> >>> On Nov 13, 2014, at 7:34 PM, Felix Bembrick > >>> >>> wrote: >>> >>> Java applets were the first "programs" to run inside a web browser and >>> >>> for >>> >>> a (little) while they were flavour of the month. >>> >>> But then along came Flash which had several advantages such as faster >>> >>> load >>> >>> times, consistent loads and antialiased fonts/graphics and soon >>> >>> completely >>> >>> surpassed applets. >>> >>> But the MAIN reason why Flash was initially so successful and went on for >>> years and years of domination is that the Flash tools had an >>> Animation/Timeline Editor pretty much from the beginning. This enabled >>> even a novice to drag images around and draw the path they wanted them to >>> move along, add all sorts of bouncing effects and sounds and the result >>> >>> was >>> >>> the birth of the online greeting card company. >>> >>> But Flash soon went on to be so much more. As the Adobe tools improved, >>> >>> so >>> >>> did the SWFs and soon entire websites were written in Flash. >>> >>> Meanwhile, applet programmers had absolutely nothing remotely similar and >>> had to try (and I stress try) to tediously hand code any animations and >>> transitions and effects and I don't think it ever worked. >>> >>> Fast forward 15-20 years and now we have JavaFX which doesn't need to run >>> in the browser, has even more features than Flash, uses hardware >>> acceleration for superior performance, has a wide range of built-in >>> animations, transitions and effects but STILL we have to hand code any >>> animation/transitions. >>> >>> This is INCREDIBLY inefficient and unless Scene Builder incorporates a >>> powerful, sophisticated animation/transition and effect editor VERY, VERY >>> SOON I fear that the advanced graphics features are never going to be >>> >>> used >>> >>> to their full potential (much to the detriment of JavaFX itself). >>> >>> Does anyone know if one is in the pipeline? I see this as one of the >>> >>> most >>> >>> vital features for the JavaFX ecosystem to achieve more penetration and, >>> eventually, survive. >>> >>> Felix >>> >>> >>> >>> >> >> > From mk at nucleo.io Mon Nov 24 15:19:07 2014 From: mk at nucleo.io (Manfred Karrer) Date: Mon, 24 Nov 2014 16:19:07 +0100 Subject: What Scene Builder needs YESTERDAY! In-Reply-To: <5473267C.6060104@tbee.org> References: <5473024C.5080805@tbee.org> <547310A1.2010700@tbee.org> <5473267C.6060104@tbee.org> Message-ID: I have a longtime backgroud in Flash and Flex development and a bit if iOS, so I would like to add here my 5 cents. My first impression and experience with Scene Builder was kind of: Is this meant serious? It cannot be that Oracle release such a product in year 2014 when other platform had shipped well working UI - WYSIWYG editors more then 10 years ago. Sorry I don't want to be rude, but that was my first reaction. Beside that it is (at least on mac) pretty buggy and not 2 way compatible (if you continue to edit in FXML you soon get to the point where you cannot open it in Scenebuilder anymore because it does not support all what the compiler supports). That leads either to a very cautious and restrictive usage of FXML or that you use it just initially for the first UI prototype and then later don't use it anymore and have the annoying workflow to compile and run the app to see visual changes. I know that a really well working WYSIWIG editor is a challenge, and so far the only 2 which really worked well from my experience was the Flash IDE (I did not use later versions anymore so no idea how it is today) and Xcode. The Flex editor had more or less the same problems like Scene Builder (in the teams I worked it was considered as a toy). One general problem is as soon you have 2 development paths (visual and xml) it tends that one gets lost behind from proper support of the vendor. Xcode and early Flash IDE made the radical decision to have only an visual editor, the workflow does not involve xml editing when you reach the limits of the editor. That forced the visual editors that they need to make it all possible, which worked for both platforms pretty well. Of course the Flash IDE was too limited on the coding side and had another direction, but XCode combined both worlds in a pretty good way. I am not expecting to have support for animations. Thats another hard challenge and I am not sure if that should not be left out to some external tools. I just would be happy to have an visual editor that really represents correctly what i will see when its compiled and which sticks in sync when the UI gets more complex and integrated with the projects code base (here Scene Builder lacks a lot!). But beside that, another disappointment for me was (coming from Flex) that it is pretty slow (for a such a fast runtime like Java). It feels for me same slow like Flex was, but the Flash runtime used by Flex is a much, much slower then Java, so how can it be that a Java based UI framework is not min. 10 times faster? Flex used code generation so all was compiled, otherwise it would have been completely unusable (slow). JavaFX use reflection and interprets FXML at runtime which introduces 2 performance penalties: - The runtime loading (takes 50-200 ms depending on the size of the FXML) - The parsing and reflection based interpretation which takes another 50-200 ms (not so sure about that, as in that time the inclusion in the scene graph is included as well, but if the layout or rendering is so slow, then that is another question why). Every delay larger then 50 ms is very clear visible to the user, resulting in an UI which just does not feel snappy. In my current app I use caching to avoid at least the slow loading (after the initial load). I will probably convert all FXML when the UI is final to java code to get rid of the second performance penalty. But that of course is not a satisfying situation! Hopefully some code generation projects gets mature enough to be really useful in complex UIs or Oracle take JavaFX serious enough to put more effort on that. Conclusion: You can see in the UI how well the tools have supported the work process. If its a pain and a lot of work to get simple stuff done the UI looks like that. Flash was very good on that already back in 2002, you could create stunning animations, effects, designs without pain, it was fun to work on that. XCode is pretty good on that as well, Apple has a long tradition to take the visual aspect and the usability very important. And you can see that. Sorry again for the pretty critical and negative feedback. Actually I love to work with JavaFX, it just feels it could do much better, specially as we are in 2014 (Flex become mature around 2006). Kudos to all who are working hard on the platform. I am totally aware those are not easy tasks and limited resources produce restrictions... br, Manfred Karrer Am 24.11.2014 um 13:37 schrieb Tom Eugelink : > Oh, you are right, if the JavaFX team does not need to make choices on where to invest their precious time, then all possible usages could be implemented immediately. Unfortunately they too have to place priorities and then the most likely usage will get implemented first (since most usages already have some existing platform, "alternative" or "replacement" for an that platform comes to mind). > > Apparently it is not animations, personally I'm still hoping 3rd party controls support in SceneBuilder will get higher on the list, but I'm not getting my hopes up. But as Mike pointed out; it is a missing functionality, go build it! ;-) > > Tom > > > On 24-11-2014 13:18, Felix Bembrick wrote: >> JavaFX should not be seen as a "replacement" for anything or an "alternative". It has characteristics of both Flash and Flex along with Silverlight and especially Qt, (not to mention even HTML5/CSS/JS), but is a separate and distinct product in its own class. >> >> Just because the Flash visual editor may have "got in the way" of your desire to code directly, that doesn't mean that JavaFX should not have such an editor for all the same reasons and use cases that Flash had one. >> >> Sure, for *your* purposes of "decorative effects", I am confident that coding would suffice but for *my* purposes (and anyone who has worked in the animation industry or worked creating visualisations) I really need a visual editor of the ilk I have described. >> >> Why just make one class of user happy but seriously limit the effectiveness of another (and in doing so possibly significantly limit the market of JavaFX)? >> >> I am sure at least one of the developers on the JavaFX team has at one point at least envisaged JavaFX being used for complex animations, visualisations or even non-trivial games. What they need to do now is make such use cases feasible. >> >> On 24 November 2014 at 22:04, Tom Eugelink > wrote: >> >> I have no problems using JavaFX's animations for my purposes, which are decorative effects. I do not need an editor for that, forced me to use it and it probably will even get in my way. Which BTW was the case with the Flash coding that I have done; I hated that Flash EDI, it was way too much focussed on animation. Actually that is why Adobe created Flex, which basically was flash-for-developers (instead of animators). JavaFX is more a alternative for Flex than Flash. >> >> Tom >> >> >> >> On 24-11-2014 11:20, Felix Bembrick wrote: >>> Really? My point is, why have such good built-on classes to support the building of everything from simple animations to complex visualisations if it is practically impossible to do so? >>> >>> On 24 November 2014 at 21:02, Tom Eugelink > wrote: >>> >>> I do not think that JavaFX is aiming at replacing flash, HTML and javascript are doing a great job there, hence animations are not equally important as they were for flash. >>> >>> Tom >>> >>> >>> >>> On 24-11-2014 10:46, Felix Bembrick wrote: >>> >>> I am surprised more people have not expressed an opinion on this. To me, >>> it seems absolutely *vital* to the long term (or any term) success of >>> JavaFX. >>> >>> Haven't any of you ever programmed in Flash? Can you imagine trying to >>> create any of those complex (or even the simple) animations and >>> visualisations *without* a visual editor and by doing it code alone? It >>> wouldn't have been practical (read possible) and similarly, and with JavaFX >>> having even richer features, to do this "by hand". >>> >>> To me, this is the reason why we haven't seen any great >>> animations/visualisations/applications using JavaFX and we probably never >>> will until a visual animation editor is available. Specifying and >>> controlling the motion and appearance of numerous complex objects and their >>> transitions relying exclusively on code would not be possible for even the >>> "gunnest" JFX coder... >>> >>> On 18 November 2014 at 02:48, Richard Bair > wrote: >>> >>> I?m afraid at this time there are no plans for adding an >>> animation/transition effect editor to Scene Builder, certainly not in the >>> short-term. >>> >>> Thanks >>> Richard >>> >>> On Nov 13, 2014, at 7:34 PM, Felix Bembrick > >>> >>> wrote: >>> >>> Java applets were the first "programs" to run inside a web browser and >>> >>> for >>> >>> a (little) while they were flavour of the month. >>> >>> But then along came Flash which had several advantages such as faster >>> >>> load >>> >>> times, consistent loads and antialiased fonts/graphics and soon >>> >>> completely >>> >>> surpassed applets. >>> >>> But the MAIN reason why Flash was initially so successful and went on for >>> years and years of domination is that the Flash tools had an >>> Animation/Timeline Editor pretty much from the beginning. This enabled >>> even a novice to drag images around and draw the path they wanted them to >>> move along, add all sorts of bouncing effects and sounds and the result >>> >>> was >>> >>> the birth of the online greeting card company. >>> >>> But Flash soon went on to be so much more. As the Adobe tools improved, >>> >>> so >>> >>> did the SWFs and soon entire websites were written in Flash. >>> >>> Meanwhile, applet programmers had absolutely nothing remotely similar and >>> had to try (and I stress try) to tediously hand code any animations and >>> transitions and effects and I don't think it ever worked. >>> >>> Fast forward 15-20 years and now we have JavaFX which doesn't need to run >>> in the browser, has even more features than Flash, uses hardware >>> acceleration for superior performance, has a wide range of built-in >>> animations, transitions and effects but STILL we have to hand code any >>> animation/transitions. >>> >>> This is INCREDIBLY inefficient and unless Scene Builder incorporates a >>> powerful, sophisticated animation/transition and effect editor VERY, VERY >>> SOON I fear that the advanced graphics features are never going to be >>> >>> used >>> >>> to their full potential (much to the detriment of JavaFX itself). >>> >>> Does anyone know if one is in the pipeline? I see this as one of the >>> >>> most >>> >>> vital features for the JavaFX ecosystem to achieve more penetration and, >>> eventually, survive. >>> >>> Felix >>> >>> >>> >>> >> >> > From tbee at tbee.org Mon Nov 24 15:26:18 2014 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 24 Nov 2014 16:26:18 +0100 Subject: What Scene Builder needs YESTERDAY! In-Reply-To: References: <5473024C.5080805@tbee.org> <547310A1.2010700@tbee.org> <5473267C.6060104@tbee.org> Message-ID: <54734E1A.7020908@tbee.org> In light of the reflection performance hit, the approach dagger 2 has taken with DI may be pretty interesting. http://www.youtube.com/watch?v=oK_XtfXPkqw On 24-11-2014 16:19, Manfred Karrer wrote: > I have a longtime backgroud in Flash and Flex development and a bit if iOS, so I would like to add here my 5 cents. > > My first impression and experience with Scene Builder was kind of: Is this meant serious? It cannot be that Oracle release such a product in year 2014 when other platform had shipped well working UI - WYSIWYG editors more then 10 years ago. Sorry I don't want to be rude, but that was my first reaction. > > Beside that it is (at least on mac) pretty buggy and not 2 way compatible (if you continue to edit in FXML you soon get to the point where you cannot open it in Scenebuilder anymore because it does not support all what the compiler supports). That leads either to a very cautious and restrictive usage of FXML or that you use it just initially for the first UI prototype and then later don't use it anymore and have the annoying workflow to compile and run the app to see visual changes. > > I know that a really well working WYSIWIG editor is a challenge, and so far the only 2 which really worked well from my experience was the Flash IDE (I did not use later versions anymore so no idea how it is today) and Xcode. The Flex editor had more or less the same problems like Scene Builder (in the teams I worked it was considered as a toy). > > One general problem is as soon you have 2 development paths (visual and xml) it tends that one gets lost behind from proper support of the vendor. > Xcode and early Flash IDE made the radical decision to have only an visual editor, the workflow does not involve xml editing when you reach the limits of the editor. That forced the visual editors that they need to make it all possible, which worked for both platforms pretty well. Of course the Flash IDE was too limited on the coding side and had another direction, but XCode combined both worlds in a pretty good way. > > I am not expecting to have support for animations. Thats another hard challenge and I am not sure if that should not be left out to some external tools. > I just would be happy to have an visual editor that really represents correctly what i will see when its compiled and which sticks in sync when the UI gets more complex and integrated with the projects code base (here Scene Builder lacks a lot!). > > But beside that, another disappointment for me was (coming from Flex) that it is pretty slow (for a such a fast runtime like Java). It feels for me same slow like Flex was, but the Flash runtime used by Flex is a much, much slower then Java, so how can it be that a Java based UI framework is not min. 10 times faster? > > Flex used code generation so all was compiled, otherwise it would have been completely unusable (slow). > JavaFX use reflection and interprets FXML at runtime which introduces 2 performance penalties: > - The runtime loading (takes 50-200 ms depending on the size of the FXML) > - The parsing and reflection based interpretation which takes another 50-200 ms (not so sure about that, as in that time the inclusion in the scene graph is included as well, but if the layout or rendering is so slow, then that is another question why). > > Every delay larger then 50 ms is very clear visible to the user, resulting in an UI which just does not feel snappy. > In my current app I use caching to avoid at least the slow loading (after the initial load). I will probably convert all FXML when the UI is final to java code to get rid of the second performance penalty. But that of course is not a satisfying situation! > Hopefully some code generation projects gets mature enough to be really useful in complex UIs or Oracle take JavaFX serious enough to put more effort on that. > > Conclusion: > You can see in the UI how well the tools have supported the work process. > If its a pain and a lot of work to get simple stuff done the UI looks like that. > Flash was very good on that already back in 2002, you could create stunning animations, effects, designs without pain, it was fun to work on that. > XCode is pretty good on that as well, Apple has a long tradition to take the visual aspect and the usability very important. And you can see that. > > Sorry again for the pretty critical and negative feedback. Actually I love to work with JavaFX, it just feels it could do much better, specially as we are in 2014 (Flex become mature around 2006). > > Kudos to all who are working hard on the platform. I am totally aware those are not easy tasks and limited resources produce restrictions... > > br, > Manfred Karrer > > > Am 24.11.2014 um 13:37 schrieb Tom Eugelink : > >> Oh, you are right, if the JavaFX team does not need to make choices on where to invest their precious time, then all possible usages could be implemented immediately. Unfortunately they too have to place priorities and then the most likely usage will get implemented first (since most usages already have some existing platform, "alternative" or "replacement" for an that platform comes to mind). >> >> Apparently it is not animations, personally I'm still hoping 3rd party controls support in SceneBuilder will get higher on the list, but I'm not getting my hopes up. But as Mike pointed out; it is a missing functionality, go build it! ;-) >> >> Tom >> >> >> On 24-11-2014 13:18, Felix Bembrick wrote: >>> JavaFX should not be seen as a "replacement" for anything or an "alternative". It has characteristics of both Flash and Flex along with Silverlight and especially Qt, (not to mention even HTML5/CSS/JS), but is a separate and distinct product in its own class. >>> >>> Just because the Flash visual editor may have "got in the way" of your desire to code directly, that doesn't mean that JavaFX should not have such an editor for all the same reasons and use cases that Flash had one. >>> >>> Sure, for *your* purposes of "decorative effects", I am confident that coding would suffice but for *my* purposes (and anyone who has worked in the animation industry or worked creating visualisations) I really need a visual editor of the ilk I have described. >>> >>> Why just make one class of user happy but seriously limit the effectiveness of another (and in doing so possibly significantly limit the market of JavaFX)? >>> >>> I am sure at least one of the developers on the JavaFX team has at one point at least envisaged JavaFX being used for complex animations, visualisations or even non-trivial games. What they need to do now is make such use cases feasible. >>> >>> On 24 November 2014 at 22:04, Tom Eugelink > wrote: >>> >>> I have no problems using JavaFX's animations for my purposes, which are decorative effects. I do not need an editor for that, forced me to use it and it probably will even get in my way. Which BTW was the case with the Flash coding that I have done; I hated that Flash EDI, it was way too much focussed on animation. Actually that is why Adobe created Flex, which basically was flash-for-developers (instead of animators). JavaFX is more a alternative for Flex than Flash. >>> >>> Tom >>> >>> >>> >>> On 24-11-2014 11:20, Felix Bembrick wrote: >>>> Really? My point is, why have such good built-on classes to support the building of everything from simple animations to complex visualisations if it is practically impossible to do so? >>>> >>>> On 24 November 2014 at 21:02, Tom Eugelink > wrote: >>>> >>>> I do not think that JavaFX is aiming at replacing flash, HTML and javascript are doing a great job there, hence animations are not equally important as they were for flash. >>>> >>>> Tom >>>> >>>> >>>> >>>> On 24-11-2014 10:46, Felix Bembrick wrote: >>>> >>>> I am surprised more people have not expressed an opinion on this. To me, >>>> it seems absolutely *vital* to the long term (or any term) success of >>>> JavaFX. >>>> >>>> Haven't any of you ever programmed in Flash? Can you imagine trying to >>>> create any of those complex (or even the simple) animations and >>>> visualisations *without* a visual editor and by doing it code alone? It >>>> wouldn't have been practical (read possible) and similarly, and with JavaFX >>>> having even richer features, to do this "by hand". >>>> >>>> To me, this is the reason why we haven't seen any great >>>> animations/visualisations/applications using JavaFX and we probably never >>>> will until a visual animation editor is available. Specifying and >>>> controlling the motion and appearance of numerous complex objects and their >>>> transitions relying exclusively on code would not be possible for even the >>>> "gunnest" JFX coder... >>>> >>>> On 18 November 2014 at 02:48, Richard Bair > wrote: >>>> >>>> I?m afraid at this time there are no plans for adding an >>>> animation/transition effect editor to Scene Builder, certainly not in the >>>> short-term. >>>> >>>> Thanks >>>> Richard >>>> >>>> On Nov 13, 2014, at 7:34 PM, Felix Bembrick > >>>> >>>> wrote: >>>> >>>> Java applets were the first "programs" to run inside a web browser and >>>> >>>> for >>>> >>>> a (little) while they were flavour of the month. >>>> >>>> But then along came Flash which had several advantages such as faster >>>> >>>> load >>>> >>>> times, consistent loads and antialiased fonts/graphics and soon >>>> >>>> completely >>>> >>>> surpassed applets. >>>> >>>> But the MAIN reason why Flash was initially so successful and went on for >>>> years and years of domination is that the Flash tools had an >>>> Animation/Timeline Editor pretty much from the beginning. This enabled >>>> even a novice to drag images around and draw the path they wanted them to >>>> move along, add all sorts of bouncing effects and sounds and the result >>>> >>>> was >>>> >>>> the birth of the online greeting card company. >>>> >>>> But Flash soon went on to be so much more. As the Adobe tools improved, >>>> >>>> so >>>> >>>> did the SWFs and soon entire websites were written in Flash. >>>> >>>> Meanwhile, applet programmers had absolutely nothing remotely similar and >>>> had to try (and I stress try) to tediously hand code any animations and >>>> transitions and effects and I don't think it ever worked. >>>> >>>> Fast forward 15-20 years and now we have JavaFX which doesn't need to run >>>> in the browser, has even more features than Flash, uses hardware >>>> acceleration for superior performance, has a wide range of built-in >>>> animations, transitions and effects but STILL we have to hand code any >>>> animation/transitions. >>>> >>>> This is INCREDIBLY inefficient and unless Scene Builder incorporates a >>>> powerful, sophisticated animation/transition and effect editor VERY, VERY >>>> SOON I fear that the advanced graphics features are never going to be >>>> >>>> used >>>> >>>> to their full potential (much to the detriment of JavaFX itself). >>>> >>>> Does anyone know if one is in the pipeline? I see this as one of the >>>> >>>> most >>>> >>>> vital features for the JavaFX ecosystem to achieve more penetration and, >>>> eventually, survive. >>>> >>>> Felix >>>> >>>> >>>> >>>> >>> From mike at plan99.net Mon Nov 24 15:29:26 2014 From: mike at plan99.net (Mike Hearn) Date: Mon, 24 Nov 2014 15:29:26 +0000 Subject: What Scene Builder needs YESTERDAY! References: <5473024C.5080805@tbee.org> <547310A1.2010700@tbee.org> <5473267C.6060104@tbee.org> Message-ID: FWIW I've found Scene Builder to work pretty well and haven't missed animation support. Doing it at the code level was good enough. And yes I have built things in Flash, a long time ago. Perhaps my standards are lower, as mostly in the last few years when doing UI work I've been stuck with HTML :-) Scene Builder and FXML are pure bliss compared to that! My main Scene Builder gripe is simply that it could use more keyboard shortcuts, in particular for "wrap in". But that's relatively minor. For animation, before a fancy all-singing all-dancing timeline editor, a few more utilities in the API would go a long way. The animated bind function I posted before is one I've been using a lot. Mostly you have observable state in your model classes which of course don't animate, and you want the UI to animate between states, so an animated bind type construct is exactly what's wanted. It would make little sense to have a more powerful animations framework that didn't work in this way, given that most JavaFX apps are binding data to UI and back again. On Mon Nov 24 2014 at 4:20:14 PM Manfred Karrer wrote: > I have a longtime backgroud in Flash and Flex development and a bit if > iOS, so I would like to add here my 5 cents. > > My first impression and experience with Scene Builder was kind of: Is this > meant serious? It cannot be that Oracle release such a product in year 2014 > when other platform had shipped well working UI - WYSIWYG editors more then > 10 years ago. Sorry I don't want to be rude, but that was my first reaction. > > Beside that it is (at least on mac) pretty buggy and not 2 way compatible > (if you continue to edit in FXML you soon get to the point where you cannot > open it in Scenebuilder anymore because it does not support all what the > compiler supports). That leads either to a very cautious and restrictive > usage of FXML or that you use it just initially for the first UI prototype > and then later don't use it anymore and have the annoying workflow to > compile and run the app to see visual changes. > > I know that a really well working WYSIWIG editor is a challenge, and so > far the only 2 which really worked well from my experience was the Flash > IDE (I did not use later versions anymore so no idea how it is today) and > Xcode. The Flex editor had more or less the same problems like Scene > Builder (in the teams I worked it was considered as a toy). > > One general problem is as soon you have 2 development paths (visual and > xml) it tends that one gets lost behind from proper support of the vendor. > Xcode and early Flash IDE made the radical decision to have only an visual > editor, the workflow does not involve xml editing when you reach the limits > of the editor. That forced the visual editors that they need to make it all > possible, which worked for both platforms pretty well. Of course the Flash > IDE was too limited on the coding side and had another direction, but XCode > combined both worlds in a pretty good way. > > I am not expecting to have support for animations. Thats another hard > challenge and I am not sure if that should not be left out to some external > tools. > I just would be happy to have an visual editor that really represents > correctly what i will see when its compiled and which sticks in sync when > the UI gets more complex and integrated with the projects code base (here > Scene Builder lacks a lot!). > > But beside that, another disappointment for me was (coming from Flex) that > it is pretty slow (for a such a fast runtime like Java). It feels for me > same slow like Flex was, but the Flash runtime used by Flex is a much, much > slower then Java, so how can it be that a Java based UI framework is not > min. 10 times faster? > > Flex used code generation so all was compiled, otherwise it would have > been completely unusable (slow). > JavaFX use reflection and interprets FXML at runtime which introduces 2 > performance penalties: > - The runtime loading (takes 50-200 ms depending on the size of the FXML) > - The parsing and reflection based interpretation which takes another > 50-200 ms (not so sure about that, as in that time the inclusion in the > scene graph is included as well, but if the layout or rendering is so slow, > then that is another question why). > > Every delay larger then 50 ms is very clear visible to the user, resulting > in an UI which just does not feel snappy. > In my current app I use caching to avoid at least the slow loading (after > the initial load). I will probably convert all FXML when the UI is final to > java code to get rid of the second performance penalty. But that of course > is not a satisfying situation! > Hopefully some code generation projects gets mature enough to be really > useful in complex UIs or Oracle take JavaFX serious enough to put more > effort on that. > > Conclusion: > You can see in the UI how well the tools have supported the work process. > If its a pain and a lot of work to get simple stuff done the UI looks like > that. > Flash was very good on that already back in 2002, you could create > stunning animations, effects, designs without pain, it was fun to work on > that. > XCode is pretty good on that as well, Apple has a long tradition to take > the visual aspect and the usability very important. And you can see that. > > Sorry again for the pretty critical and negative feedback. Actually I love > to work with JavaFX, it just feels it could do much better, specially as we > are in 2014 (Flex become mature around 2006). > > Kudos to all who are working hard on the platform. I am totally aware > those are not easy tasks and limited resources produce restrictions... > > br, > Manfred Karrer > > > Am 24.11.2014 um 13:37 schrieb Tom Eugelink : > > > Oh, you are right, if the JavaFX team does not need to make choices on > where to invest their precious time, then all possible usages could be > implemented immediately. Unfortunately they too have to place priorities > and then the most likely usage will get implemented first (since most > usages already have some existing platform, "alternative" or "replacement" > for an that platform comes to mind). > > > > Apparently it is not animations, personally I'm still hoping 3rd party > controls support in SceneBuilder will get higher on the list, but I'm not > getting my hopes up. But as Mike pointed out; it is a missing > functionality, go build it! ;-) > > > > Tom > > > > > > On 24-11-2014 13:18, Felix Bembrick wrote: > >> JavaFX should not be seen as a "replacement" for anything or an > "alternative". It has characteristics of both Flash and Flex along with > Silverlight and especially Qt, (not to mention even HTML5/CSS/JS), but is a > separate and distinct product in its own class. > >> > >> Just because the Flash visual editor may have "got in the way" of your > desire to code directly, that doesn't mean that JavaFX should not have such > an editor for all the same reasons and use cases that Flash had one. > >> > >> Sure, for *your* purposes of "decorative effects", I am confident that > coding would suffice but for *my* purposes (and anyone who has worked in > the animation industry or worked creating visualisations) I really need a > visual editor of the ilk I have described. > >> > >> Why just make one class of user happy but seriously limit the > effectiveness of another (and in doing so possibly significantly limit the > market of JavaFX)? > >> > >> I am sure at least one of the developers on the JavaFX team has at one > point at least envisaged JavaFX being used for complex animations, > visualisations or even non-trivial games. What they need to do now is make > such use cases feasible. > >> > >> On 24 November 2014 at 22:04, Tom Eugelink tbee at tbee.org>> wrote: > >> > >> I have no problems using JavaFX's animations for my purposes, which > are decorative effects. I do not need an editor for that, forced me to use > it and it probably will even get in my way. Which BTW was the case with the > Flash coding that I have done; I hated that Flash EDI, it was way too much > focussed on animation. Actually that is why Adobe created Flex, which > basically was flash-for-developers (instead of animators). JavaFX is more a > alternative for Flex than Flash. > >> > >> Tom > >> > >> > >> > >> On 24-11-2014 11:20, Felix Bembrick wrote: > >>> Really? My point is, why have such good built-on classes to support > the building of everything from simple animations to complex visualisations > if it is practically impossible to do so? > >>> > >>> On 24 November 2014 at 21:02, Tom Eugelink tbee at tbee.org>> wrote: > >>> > >>> I do not think that JavaFX is aiming at replacing flash, HTML > and javascript are doing a great job there, hence animations are not > equally important as they were for flash. > >>> > >>> Tom > >>> > >>> > >>> > >>> On 24-11-2014 10:46, Felix Bembrick wrote: > >>> > >>> I am surprised more people have not expressed an opinion on > this. To me, > >>> it seems absolutely *vital* to the long term (or any term) > success of > >>> JavaFX. > >>> > >>> Haven't any of you ever programmed in Flash? Can you > imagine trying to > >>> create any of those complex (or even the simple) animations > and > >>> visualisations *without* a visual editor and by doing it > code alone? It > >>> wouldn't have been practical (read possible) and similarly, > and with JavaFX > >>> having even richer features, to do this "by hand". > >>> > >>> To me, this is the reason why we haven't seen any great > >>> animations/visualisations/applications using JavaFX and we > probably never > >>> will until a visual animation editor is available. > Specifying and > >>> controlling the motion and appearance of numerous complex > objects and their > >>> transitions relying exclusively on code would not be > possible for even the > >>> "gunnest" JFX coder... > >>> > >>> On 18 November 2014 at 02:48, Richard Bair < > richard.bair at oracle.com > wrote: > >>> > >>> I?m afraid at this time there are no plans for adding an > >>> animation/transition effect editor to Scene Builder, > certainly not in the > >>> short-term. > >>> > >>> Thanks > >>> Richard > >>> > >>> On Nov 13, 2014, at 7:34 PM, Felix Bembrick < > felix.bembrick at gmail.com > > >>> > >>> wrote: > >>> > >>> Java applets were the first "programs" to run > inside a web browser and > >>> > >>> for > >>> > >>> a (little) while they were flavour of the month. > >>> > >>> But then along came Flash which had several > advantages such as faster > >>> > >>> load > >>> > >>> times, consistent loads and antialiased > fonts/graphics and soon > >>> > >>> completely > >>> > >>> surpassed applets. > >>> > >>> But the MAIN reason why Flash was initially so > successful and went on for > >>> years and years of domination is that the Flash > tools had an > >>> Animation/Timeline Editor pretty much from the > beginning. This enabled > >>> even a novice to drag images around and draw the > path they wanted them to > >>> move along, add all sorts of bouncing effects and > sounds and the result > >>> > >>> was > >>> > >>> the birth of the online greeting card company. > >>> > >>> But Flash soon went on to be so much more. As the > Adobe tools improved, > >>> > >>> so > >>> > >>> did the SWFs and soon entire websites were written > in Flash. > >>> > >>> Meanwhile, applet programmers had absolutely > nothing remotely similar and > >>> had to try (and I stress try) to tediously hand > code any animations and > >>> transitions and effects and I don't think it ever > worked. > >>> > >>> Fast forward 15-20 years and now we have JavaFX > which doesn't need to run > >>> in the browser, has even more features than Flash, > uses hardware > >>> acceleration for superior performance, has a wide > range of built-in > >>> animations, transitions and effects but STILL we > have to hand code any > >>> animation/transitions. > >>> > >>> This is INCREDIBLY inefficient and unless Scene > Builder incorporates a > >>> powerful, sophisticated animation/transition and > effect editor VERY, VERY > >>> SOON I fear that the advanced graphics features are > never going to be > >>> > >>> used > >>> > >>> to their full potential (much to the detriment of > JavaFX itself). > >>> > >>> Does anyone know if one is in the pipeline? I see > this as one of the > >>> > >>> most > >>> > >>> vital features for the JavaFX ecosystem to achieve > more penetration and, > >>> eventually, survive. > >>> > >>> Felix > >>> > >>> > >>> > >>> > >> > >> > > > > From anton.tarasov at oracle.com Mon Nov 24 15:35:49 2014 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Mon, 24 Nov 2014 18:35:49 +0300 Subject: Linux (centos), openjdk 8, openjfx and netbeans 8 In-Reply-To: References: <1416667339.70989799@f322.i.mail.ru> <5472E2D3.2040809@oracle.com> Message-ID: <54735055.6050502@oracle.com> Hi Mario, On 24.11.2014 17:19, Mario Torre wrote: > > Hi Anton, > > This is new to me, I think OpenJDK 8 does *not* contain OpenJFX (or JavaFX). > Yes, I was incorrect about it. OpenJDK 8 does not contain OpenJFX. > You are probably referring to the Oracle closed JDK. > I was referring to Java SE 8, available at oracle.com for download, and as early access builds at jdk8.java.net. Thanks for the correction. Regards, Anton. > Cheers, > Mario > > Il 24/nov/2014 08:49 "Anton V. Tarasov" > ha scritto: > > Hello Alexander, > > On 22.11.2014 17:42, ????????? ???????? wrote: > > Hello everybody. > I installed at centos 6.4 openjdk 8, netbeans 8 and build openjfx (via gradle). The only > thing I can't uderstand is how to make netbeans work with built openjfx sdk. As openjdx > sdk is in folder /temp while jdk is in /usr/lib/jvm/java-8... I can't undertand how to add > openjfx to netbeans as everywhere people say that jfx is already in jdk. > So, what now should I do to make all these work together? > > > openjdk8 sdk contains the openjfx sdk binaries. So, you don't need to change the classpath in > order to compile or run your jfx application. Simply add your jdk as a Java Platform. > > In case you want to try your own openjfx build with openjdk in netbeans, you can do the following. > > In the "Project Properties"dialog of your project, select "Libraries" and add jfxrt.jar to the > Compile-time and Run-time libraries. Please, find jfxrt.jar in the "artifacts" of your openjfx > workspace: > > /artifacts/sdk/rt/lib/ext/jfxrt.jar > > Also, you can find the netbeans projects of the openjfx source tree under the following dir: > > /rt/netbeans > > Regards, > Anton. > From chris.bensen at oracle.com Mon Nov 24 15:38:24 2014 From: chris.bensen at oracle.com (Chris Bensen) Date: Mon, 24 Nov 2014 07:38:24 -0800 Subject: [8u40] review request: RT-39182: Enable building 32-bit Linux on 64-bit systems In-Reply-To: <54713871.2090502@oracle.com> References: <54713871.2090502@oracle.com> Message-ID: <49AB90C5-4651-4387-BF8F-49407AEFB2FE@oracle.com> +1 On Nov 22, 2014, at 5:29 PM, Kevin Rushforth wrote: > Dave, Kirill, Anton, Chris, > > Please review the following build changes to enable building 32-bit graphics, media, webkit, and packager binaries on a 64-bit Linux system. > > https://javafx-jira.kenai.com/browse/RT-39182 > http://cr.openjdk.java.net/~kcr/RT-39182/webrev.01/ > > Details are in JIRA. > > -- Kevin > From alexander.casall at saxsys.de Mon Nov 24 15:50:35 2014 From: alexander.casall at saxsys.de (Casall, Alexander) Date: Mon, 24 Nov 2014 15:50:35 +0000 Subject: Focus Traversal Engine Message-ID: <6C6CE4A9B94582468498929459CEEF710FD53233@vmex1.saxsys.de> Hi, is there an elegant way to change the focus traversal order without using Private APIs (TraversalEngine) or creating an own mechanism using EventFilters? Cheers Alex From david.dehaven at oracle.com Mon Nov 24 20:10:15 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 24 Nov 2014 12:10:15 -0800 Subject: [8u40] RFR: RT-38973: Media produces extraneous debugging when running Ensemble8 Message-ID: <9BE970D8-5B5E-4746-A54A-1A2B0E64C137@oracle.com> Kevin, Kirill, please review the following fix for 8u40: JIRA: https://javafx-jira.kenai.com/browse/RT-38973 Webrev: http://cr.openjdk.java.net/~ddehaven/RT-38973/rt.0/ I added an additional (annoying) compiler warning fix. -DrD- From kevin.rushforth at oracle.com Mon Nov 24 20:53:45 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 24 Nov 2014 12:53:45 -0800 Subject: 8u-dev unlocked following this week's sanity testing Message-ID: <54739AD9.8080004@oracle.com> From kevin.rushforth at oracle.com Tue Nov 25 01:46:17 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 24 Nov 2014 17:46:17 -0800 Subject: [8u40] review request: RT-39492: [Accessibility, Mac] NPE in MacAccessible.flipBounds when closing full-screen Stage while running VoiceOver Message-ID: <5473DF69.7040107@oracle.com> Dave, Pete, or Felipe, Please review the following simple fix: https://javafx-jira.kenai.com/browse/RT-39492 The patch is in the JIRA. -- Kevin From felix.bembrick at gmail.com Tue Nov 25 05:15:16 2014 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Tue, 25 Nov 2014 16:15:16 +1100 Subject: What Scene Builder needs YESTERDAY! In-Reply-To: References: <5473024C.5080805@tbee.org> <547310A1.2010700@tbee.org> <5473267C.6060104@tbee.org> Message-ID: Of course Oracle needs/needed to prioritise features in JavaFX and I think they have done a very good job in that respect given that the most common use case would be for forms or dialogs with the odd decorative effect. But, now that this part has been done, I would love to see a lot more work put into the entire 3D subsystem and, as stated, I really do think some tool to assist with visual development of animations and visualisations is needed desperately. I think most people who have to date looked at JavaFX have either come from a Swing background or are in a position to develop a new forms-based application with Java so typical in business scenarios. But I think there is an entirely different class of user who would benefit greatly from the less well-known or lesser used features that Swing simply didn't have. Maybe people are right in that if I am the only one who is in such dire need of a visual animation/visualisation/timeline editor then perhaps I should develop and contribute such a component myself. Anything is possible... On 25 November 2014 at 02:29, Mike Hearn wrote: > FWIW I've found Scene Builder to work pretty well and haven't missed > animation support. Doing it at the code level was good enough. And yes I > have built things in Flash, a long time ago. Perhaps my standards are > lower, as mostly in the last few years when doing UI work I've been stuck > with HTML :-) Scene Builder and FXML are pure bliss compared to that! > > My main Scene Builder gripe is simply that it could use more keyboard > shortcuts, in particular for "wrap in". But that's relatively minor. > > For animation, before a fancy all-singing all-dancing timeline editor, a > few more utilities in the API would go a long way. The animated bind > function I posted before is one I've been using a lot. Mostly you have > observable state in your model classes which of course don't animate, and > you want the UI to animate between states, so an animated bind type > construct is exactly what's wanted. It would make little sense to have a > more powerful animations framework that didn't work in this way, given that > most JavaFX apps are binding data to UI and back again. > > > > > On Mon Nov 24 2014 at 4:20:14 PM Manfred Karrer wrote: > > > I have a longtime backgroud in Flash and Flex development and a bit if > > iOS, so I would like to add here my 5 cents. > > > > My first impression and experience with Scene Builder was kind of: Is > this > > meant serious? It cannot be that Oracle release such a product in year > 2014 > > when other platform had shipped well working UI - WYSIWYG editors more > then > > 10 years ago. Sorry I don't want to be rude, but that was my first > reaction. > > > > Beside that it is (at least on mac) pretty buggy and not 2 way compatible > > (if you continue to edit in FXML you soon get to the point where you > cannot > > open it in Scenebuilder anymore because it does not support all what the > > compiler supports). That leads either to a very cautious and restrictive > > usage of FXML or that you use it just initially for the first UI > prototype > > and then later don't use it anymore and have the annoying workflow to > > compile and run the app to see visual changes. > > > > I know that a really well working WYSIWIG editor is a challenge, and so > > far the only 2 which really worked well from my experience was the Flash > > IDE (I did not use later versions anymore so no idea how it is today) and > > Xcode. The Flex editor had more or less the same problems like Scene > > Builder (in the teams I worked it was considered as a toy). > > > > One general problem is as soon you have 2 development paths (visual and > > xml) it tends that one gets lost behind from proper support of the > vendor. > > Xcode and early Flash IDE made the radical decision to have only an > visual > > editor, the workflow does not involve xml editing when you reach the > limits > > of the editor. That forced the visual editors that they need to make it > all > > possible, which worked for both platforms pretty well. Of course the > Flash > > IDE was too limited on the coding side and had another direction, but > XCode > > combined both worlds in a pretty good way. > > > > I am not expecting to have support for animations. Thats another hard > > challenge and I am not sure if that should not be left out to some > external > > tools. > > I just would be happy to have an visual editor that really represents > > correctly what i will see when its compiled and which sticks in sync when > > the UI gets more complex and integrated with the projects code base (here > > Scene Builder lacks a lot!). > > > > But beside that, another disappointment for me was (coming from Flex) > that > > it is pretty slow (for a such a fast runtime like Java). It feels for me > > same slow like Flex was, but the Flash runtime used by Flex is a much, > much > > slower then Java, so how can it be that a Java based UI framework is not > > min. 10 times faster? > > > > Flex used code generation so all was compiled, otherwise it would have > > been completely unusable (slow). > > JavaFX use reflection and interprets FXML at runtime which introduces 2 > > performance penalties: > > - The runtime loading (takes 50-200 ms depending on the size of the FXML) > > - The parsing and reflection based interpretation which takes another > > 50-200 ms (not so sure about that, as in that time the inclusion in the > > scene graph is included as well, but if the layout or rendering is so > slow, > > then that is another question why). > > > > Every delay larger then 50 ms is very clear visible to the user, > resulting > > in an UI which just does not feel snappy. > > In my current app I use caching to avoid at least the slow loading (after > > the initial load). I will probably convert all FXML when the UI is final > to > > java code to get rid of the second performance penalty. But that of > course > > is not a satisfying situation! > > Hopefully some code generation projects gets mature enough to be really > > useful in complex UIs or Oracle take JavaFX serious enough to put more > > effort on that. > > > > Conclusion: > > You can see in the UI how well the tools have supported the work process. > > If its a pain and a lot of work to get simple stuff done the UI looks > like > > that. > > Flash was very good on that already back in 2002, you could create > > stunning animations, effects, designs without pain, it was fun to work on > > that. > > XCode is pretty good on that as well, Apple has a long tradition to take > > the visual aspect and the usability very important. And you can see that. > > > > Sorry again for the pretty critical and negative feedback. Actually I > love > > to work with JavaFX, it just feels it could do much better, specially as > we > > are in 2014 (Flex become mature around 2006). > > > > Kudos to all who are working hard on the platform. I am totally aware > > those are not easy tasks and limited resources produce restrictions... > > > > br, > > Manfred Karrer > > > > > > Am 24.11.2014 um 13:37 schrieb Tom Eugelink : > > > > > Oh, you are right, if the JavaFX team does not need to make choices on > > where to invest their precious time, then all possible usages could be > > implemented immediately. Unfortunately they too have to place priorities > > and then the most likely usage will get implemented first (since most > > usages already have some existing platform, "alternative" or > "replacement" > > for an that platform comes to mind). > > > > > > Apparently it is not animations, personally I'm still hoping 3rd party > > controls support in SceneBuilder will get higher on the list, but I'm not > > getting my hopes up. But as Mike pointed out; it is a missing > > functionality, go build it! ;-) > > > > > > Tom > > > > > > > > > On 24-11-2014 13:18, Felix Bembrick wrote: > > >> JavaFX should not be seen as a "replacement" for anything or an > > "alternative". It has characteristics of both Flash and Flex along with > > Silverlight and especially Qt, (not to mention even HTML5/CSS/JS), but > is a > > separate and distinct product in its own class. > > >> > > >> Just because the Flash visual editor may have "got in the way" of your > > desire to code directly, that doesn't mean that JavaFX should not have > such > > an editor for all the same reasons and use cases that Flash had one. > > >> > > >> Sure, for *your* purposes of "decorative effects", I am confident that > > coding would suffice but for *my* purposes (and anyone who has worked in > > the animation industry or worked creating visualisations) I really need a > > visual editor of the ilk I have described. > > >> > > >> Why just make one class of user happy but seriously limit the > > effectiveness of another (and in doing so possibly significantly limit > the > > market of JavaFX)? > > >> > > >> I am sure at least one of the developers on the JavaFX team has at one > > point at least envisaged JavaFX being used for complex animations, > > visualisations or even non-trivial games. What they need to do now is > make > > such use cases feasible. > > >> > > >> On 24 November 2014 at 22:04, Tom Eugelink > tbee at tbee.org>> wrote: > > >> > > >> I have no problems using JavaFX's animations for my purposes, which > > are decorative effects. I do not need an editor for that, forced me to > use > > it and it probably will even get in my way. Which BTW was the case with > the > > Flash coding that I have done; I hated that Flash EDI, it was way too > much > > focussed on animation. Actually that is why Adobe created Flex, which > > basically was flash-for-developers (instead of animators). JavaFX is > more a > > alternative for Flex than Flash. > > >> > > >> Tom > > >> > > >> > > >> > > >> On 24-11-2014 11:20, Felix Bembrick wrote: > > >>> Really? My point is, why have such good built-on classes to > support > > the building of everything from simple animations to complex > visualisations > > if it is practically impossible to do so? > > >>> > > >>> On 24 November 2014 at 21:02, Tom Eugelink > tbee at tbee.org>> wrote: > > >>> > > >>> I do not think that JavaFX is aiming at replacing flash, HTML > > and javascript are doing a great job there, hence animations are not > > equally important as they were for flash. > > >>> > > >>> Tom > > >>> > > >>> > > >>> > > >>> On 24-11-2014 10:46, Felix Bembrick wrote: > > >>> > > >>> I am surprised more people have not expressed an opinion > on > > this. To me, > > >>> it seems absolutely *vital* to the long term (or any term) > > success of > > >>> JavaFX. > > >>> > > >>> Haven't any of you ever programmed in Flash? Can you > > imagine trying to > > >>> create any of those complex (or even the simple) > animations > > and > > >>> visualisations *without* a visual editor and by doing it > > code alone? It > > >>> wouldn't have been practical (read possible) and > similarly, > > and with JavaFX > > >>> having even richer features, to do this "by hand". > > >>> > > >>> To me, this is the reason why we haven't seen any great > > >>> animations/visualisations/applications using JavaFX and we > > probably never > > >>> will until a visual animation editor is available. > > Specifying and > > >>> controlling the motion and appearance of numerous complex > > objects and their > > >>> transitions relying exclusively on code would not be > > possible for even the > > >>> "gunnest" JFX coder... > > >>> > > >>> On 18 November 2014 at 02:48, Richard Bair < > > richard.bair at oracle.com > wrote: > > >>> > > >>> I?m afraid at this time there are no plans for adding > an > > >>> animation/transition effect editor to Scene Builder, > > certainly not in the > > >>> short-term. > > >>> > > >>> Thanks > > >>> Richard > > >>> > > >>> On Nov 13, 2014, at 7:34 PM, Felix Bembrick < > > felix.bembrick at gmail.com > > > >>> > > >>> wrote: > > >>> > > >>> Java applets were the first "programs" to run > > inside a web browser and > > >>> > > >>> for > > >>> > > >>> a (little) while they were flavour of the month. > > >>> > > >>> But then along came Flash which had several > > advantages such as faster > > >>> > > >>> load > > >>> > > >>> times, consistent loads and antialiased > > fonts/graphics and soon > > >>> > > >>> completely > > >>> > > >>> surpassed applets. > > >>> > > >>> But the MAIN reason why Flash was initially so > > successful and went on for > > >>> years and years of domination is that the Flash > > tools had an > > >>> Animation/Timeline Editor pretty much from the > > beginning. This enabled > > >>> even a novice to drag images around and draw the > > path they wanted them to > > >>> move along, add all sorts of bouncing effects and > > sounds and the result > > >>> > > >>> was > > >>> > > >>> the birth of the online greeting card company. > > >>> > > >>> But Flash soon went on to be so much more. As the > > Adobe tools improved, > > >>> > > >>> so > > >>> > > >>> did the SWFs and soon entire websites were written > > in Flash. > > >>> > > >>> Meanwhile, applet programmers had absolutely > > nothing remotely similar and > > >>> had to try (and I stress try) to tediously hand > > code any animations and > > >>> transitions and effects and I don't think it ever > > worked. > > >>> > > >>> Fast forward 15-20 years and now we have JavaFX > > which doesn't need to run > > >>> in the browser, has even more features than Flash, > > uses hardware > > >>> acceleration for superior performance, has a wide > > range of built-in > > >>> animations, transitions and effects but STILL we > > have to hand code any > > >>> animation/transitions. > > >>> > > >>> This is INCREDIBLY inefficient and unless Scene > > Builder incorporates a > > >>> powerful, sophisticated animation/transition and > > effect editor VERY, VERY > > >>> SOON I fear that the advanced graphics features > are > > never going to be > > >>> > > >>> used > > >>> > > >>> to their full potential (much to the detriment of > > JavaFX itself). > > >>> > > >>> Does anyone know if one is in the pipeline? I see > > this as one of the > > >>> > > >>> most > > >>> > > >>> vital features for the JavaFX ecosystem to achieve > > more penetration and, > > >>> eventually, survive. > > >>> > > >>> Felix > > >>> > > >>> > > >>> > > >>> > > >> > > >> > > > > > > > > From tbee at tbee.org Tue Nov 25 06:24:31 2014 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 25 Nov 2014 07:24:31 +0100 Subject: What Scene Builder needs YESTERDAY! In-Reply-To: References: <5473024C.5080805@tbee.org> <547310A1.2010700@tbee.org> <5473267C.6060104@tbee.org> Message-ID: <5474209F.7080702@tbee.org> You are completely right, except in the "now that this part has been done". SceneBuilder is no where near to being done yet, that is, assuming SB should work on the level of XCode or the Flash editor. And then the question is, should it be working good in one area or only half in two? Tom On 25-11-2014 06:15, Felix Bembrick wrote: > Of course Oracle needs/needed to prioritise features in JavaFX and I think they have done a very good job in that respect given that the most common use case would be for forms or dialogs with the odd decorative effect. > > But, now that this part has been done, I would love to see a lot more work put into the entire 3D subsystem and, as stated, I really do think some tool to assist with visual development of animations and visualisations is needed desperately. > > I think most people who have to date looked at JavaFX have either come from a Swing background or are in a position to develop a new forms-based application with Java so typical in business scenarios. But I think there is an entirely different class of user who would benefit greatly from the less well-known or lesser used features that Swing simply didn't have. > > Maybe people are right in that if I am the only one who is in such dire need of a visual animation/visualisation/timeline editor then perhaps I should develop and contribute such a component myself. > > Anything is possible... > > On 25 November 2014 at 02:29, Mike Hearn > wrote: > > FWIW I've found Scene Builder to work pretty well and haven't missed > animation support. Doing it at the code level was good enough. And yes I > have built things in Flash, a long time ago. Perhaps my standards are > lower, as mostly in the last few years when doing UI work I've been stuck > with HTML :-) Scene Builder and FXML are pure bliss compared to that! > > My main Scene Builder gripe is simply that it could use more keyboard > shortcuts, in particular for "wrap in". But that's relatively minor. > > For animation, before a fancy all-singing all-dancing timeline editor, a > few more utilities in the API would go a long way. The animated bind > function I posted before is one I've been using a lot. Mostly you have > observable state in your model classes which of course don't animate, and > you want the UI to animate between states, so an animated bind type > construct is exactly what's wanted. It would make little sense to have a > more powerful animations framework that didn't work in this way, given that > most JavaFX apps are binding data to UI and back again. > > > > > On Mon Nov 24 2014 at 4:20:14 PM Manfred Karrer > wrote: > > > I have a longtime backgroud in Flash and Flex development and a bit if > > iOS, so I would like to add here my 5 cents. > > > > My first impression and experience with Scene Builder was kind of: Is this > > meant serious? It cannot be that Oracle release such a product in year 2014 > > when other platform had shipped well working UI - WYSIWYG editors more then > > 10 years ago. Sorry I don't want to be rude, but that was my first reaction. > > > > Beside that it is (at least on mac) pretty buggy and not 2 way compatible > > (if you continue to edit in FXML you soon get to the point where you cannot > > open it in Scenebuilder anymore because it does not support all what the > > compiler supports). That leads either to a very cautious and restrictive > > usage of FXML or that you use it just initially for the first UI prototype > > and then later don't use it anymore and have the annoying workflow to > > compile and run the app to see visual changes. > > > > I know that a really well working WYSIWIG editor is a challenge, and so > > far the only 2 which really worked well from my experience was the Flash > > IDE (I did not use later versions anymore so no idea how it is today) and > > Xcode. The Flex editor had more or less the same problems like Scene > > Builder (in the teams I worked it was considered as a toy). > > > > One general problem is as soon you have 2 development paths (visual and > > xml) it tends that one gets lost behind from proper support of the vendor. > > Xcode and early Flash IDE made the radical decision to have only an visual > > editor, the workflow does not involve xml editing when you reach the limits > > of the editor. That forced the visual editors that they need to make it all > > possible, which worked for both platforms pretty well. Of course the Flash > > IDE was too limited on the coding side and had another direction, but XCode > > combined both worlds in a pretty good way. > > > > I am not expecting to have support for animations. Thats another hard > > challenge and I am not sure if that should not be left out to some external > > tools. > > I just would be happy to have an visual editor that really represents > > correctly what i will see when its compiled and which sticks in sync when > > the UI gets more complex and integrated with the projects code base (here > > Scene Builder lacks a lot!). > > > > But beside that, another disappointment for me was (coming from Flex) that > > it is pretty slow (for a such a fast runtime like Java). It feels for me > > same slow like Flex was, but the Flash runtime used by Flex is a much, much > > slower then Java, so how can it be that a Java based UI framework is not > > min. 10 times faster? > > > > Flex used code generation so all was compiled, otherwise it would have > > been completely unusable (slow). > > JavaFX use reflection and interprets FXML at runtime which introduces 2 > > performance penalties: > > - The runtime loading (takes 50-200 ms depending on the size of the FXML) > > - The parsing and reflection based interpretation which takes another > > 50-200 ms (not so sure about that, as in that time the inclusion in the > > scene graph is included as well, but if the layout or rendering is so slow, > > then that is another question why). > > > > Every delay larger then 50 ms is very clear visible to the user, resulting > > in an UI which just does not feel snappy. > > In my current app I use caching to avoid at least the slow loading (after > > the initial load). I will probably convert all FXML when the UI is final to > > java code to get rid of the second performance penalty. But that of course > > is not a satisfying situation! > > Hopefully some code generation projects gets mature enough to be really > > useful in complex UIs or Oracle take JavaFX serious enough to put more > > effort on that. > > > > Conclusion: > > You can see in the UI how well the tools have supported the work process. > > If its a pain and a lot of work to get simple stuff done the UI looks like > > that. > > Flash was very good on that already back in 2002, you could create > > stunning animations, effects, designs without pain, it was fun to work on > > that. > > XCode is pretty good on that as well, Apple has a long tradition to take > > the visual aspect and the usability very important. And you can see that. > > > > Sorry again for the pretty critical and negative feedback. Actually I love > > to work with JavaFX, it just feels it could do much better, specially as we > > are in 2014 (Flex become mature around 2006). > > > > Kudos to all who are working hard on the platform. I am totally aware > > those are not easy tasks and limited resources produce restrictions... > > > > br, > > Manfred Karrer > > > > > > Am 24.11.2014 um 13:37 schrieb Tom Eugelink >: > > > > > Oh, you are right, if the JavaFX team does not need to make choices on > > where to invest their precious time, then all possible usages could be > > implemented immediately. Unfortunately they too have to place priorities > > and then the most likely usage will get implemented first (since most > > usages already have some existing platform, "alternative" or "replacement" > > for an that platform comes to mind). > > > > > > Apparently it is not animations, personally I'm still hoping 3rd party > > controls support in SceneBuilder will get higher on the list, but I'm not > > getting my hopes up. But as Mike pointed out; it is a missing > > functionality, go build it! ;-) > > > > > > Tom > > > > > > > > > On 24-11-2014 13:18, Felix Bembrick wrote: > > >> JavaFX should not be seen as a "replacement" for anything or an > > "alternative". It has characteristics of both Flash and Flex along with > > Silverlight and especially Qt, (not to mention even HTML5/CSS/JS), but is a > > separate and distinct product in its own class. > > >> > > >> Just because the Flash visual editor may have "got in the way" of your > > desire to code directly, that doesn't mean that JavaFX should not have such > > an editor for all the same reasons and use cases that Flash had one. > > >> > > >> Sure, for *your* purposes of "decorative effects", I am confident that > > coding would suffice but for *my* purposes (and anyone who has worked in > > the animation industry or worked creating visualisations) I really need a > > visual editor of the ilk I have described. > > >> > > >> Why just make one class of user happy but seriously limit the > > effectiveness of another (and in doing so possibly significantly limit the > > market of JavaFX)? > > >> > > >> I am sure at least one of the developers on the JavaFX team has at one > > point at least envisaged JavaFX being used for complex animations, > > visualisations or even non-trivial games. What they need to do now is make > > such use cases feasible. > > >> > > >> On 24 November 2014 at 22:04, Tom Eugelink > tbee at tbee.org >> wrote: > > >> > > >> I have no problems using JavaFX's animations for my purposes, which > > are decorative effects. I do not need an editor for that, forced me to use > > it and it probably will even get in my way. Which BTW was the case with the > > Flash coding that I have done; I hated that Flash EDI, it was way too much > > focussed on animation. Actually that is why Adobe created Flex, which > > basically was flash-for-developers (instead of animators). JavaFX is more a > > alternative for Flex than Flash. > > >> > > >> Tom > > >> > > >> > > >> > > >> On 24-11-2014 11:20, Felix Bembrick wrote: > > >>> Really? My point is, why have such good built-on classes to support > > the building of everything from simple animations to complex visualisations > > if it is practically impossible to do so? > > >>> > > >>> On 24 November 2014 at 21:02, Tom Eugelink > tbee at tbee.org >> wrote: > > >>> > > >>> I do not think that JavaFX is aiming at replacing flash, HTML > > and javascript are doing a great job there, hence animations are not > > equally important as they were for flash. > > >>> > > >>> Tom > > >>> > > >>> > > >>> > > >>> On 24-11-2014 10:46, Felix Bembrick wrote: > > >>> > > >>> I am surprised more people have not expressed an opinion on > > this. To me, > > >>> it seems absolutely *vital* to the long term (or any term) > > success of > > >>> JavaFX. > > >>> > > >>> Haven't any of you ever programmed in Flash? Can you > > imagine trying to > > >>> create any of those complex (or even the simple) animations > > and > > >>> visualisations *without* a visual editor and by doing it > > code alone? It > > >>> wouldn't have been practical (read possible) and similarly, > > and with JavaFX > > >>> having even richer features, to do this "by hand". > > >>> > > >>> To me, this is the reason why we haven't seen any great > > >>> animations/visualisations/applications using JavaFX and we > > probably never > > >>> will until a visual animation editor is available. > > Specifying and > > >>> controlling the motion and appearance of numerous complex > > objects and their > > >>> transitions relying exclusively on code would not be > > possible for even the > > >>> "gunnest" JFX coder... > > >>> > > >>> On 18 November 2014 at 02:48, Richard Bair < > > richard.bair at oracle.com >> wrote: > > >>> > > >>> I?m afraid at this time there are no plans for adding an > > >>> animation/transition effect editor to Scene Builder, > > certainly not in the > > >>> short-term. > > >>> > > >>> Thanks > > >>> Richard > > >>> > > >>> On Nov 13, 2014, at 7:34 PM, Felix Bembrick < > > felix.bembrick at gmail.com >> > > >>> > > >>> wrote: > > >>> > > >>> Java applets were the first "programs" to run > > inside a web browser and > > >>> > > >>> for > > >>> > > >>> a (little) while they were flavour of the month. > > >>> > > >>> But then along came Flash which had several > > advantages such as faster > > >>> > > >>> load > > >>> > > >>> times, consistent loads and antialiased > > fonts/graphics and soon > > >>> > > >>> completely > > >>> > > >>> surpassed applets. > > >>> > > >>> But the MAIN reason why Flash was initially so > > successful and went on for > > >>> years and years of domination is that the Flash > > tools had an > > >>> Animation/Timeline Editor pretty much from the > > beginning. This enabled > > >>> even a novice to drag images around and draw the > > path they wanted them to > > >>> move along, add all sorts of bouncing effects and > > sounds and the result > > >>> > > >>> was > > >>> > > >>> the birth of the online greeting card company. > > >>> > > >>> But Flash soon went on to be so much more. As the > > Adobe tools improved, > > >>> > > >>> so > > >>> > > >>> did the SWFs and soon entire websites were written > > in Flash. > > >>> > > >>> Meanwhile, applet programmers had absolutely > > nothing remotely similar and > > >>> had to try (and I stress try) to tediously hand > > code any animations and > > >>> transitions and effects and I don't think it ever > > worked. > > >>> > > >>> Fast forward 15-20 years and now we have JavaFX > > which doesn't need to run > > >>> in the browser, has even more features than Flash, > > uses hardware > > >>> acceleration for superior performance, has a wide > > range of built-in > > >>> animations, transitions and effects but STILL we > > have to hand code any > > >>> animation/transitions. > > >>> > > >>> This is INCREDIBLY inefficient and unless Scene > > Builder incorporates a > > >>> powerful, sophisticated animation/transition and > > effect editor VERY, VERY > > >>> SOON I fear that the advanced graphics features are > > never going to be > > >>> > > >>> used > > >>> > > >>> to their full potential (much to the detriment of > > JavaFX itself). > > >>> > > >>> Does anyone know if one is in the pipeline? I see > > this as one of the > > >>> > > >>> most > > >>> > > >>> vital features for the JavaFX ecosystem to achieve > > more penetration and, > > >>> eventually, survive. > > >>> > > >>> Felix > > >>> > > >>> > > >>> > > >>> > > >> > > >> > > > > > > > > > From felix.bembrick at gmail.com Tue Nov 25 06:38:57 2014 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Tue, 25 Nov 2014 17:38:57 +1100 Subject: What Scene Builder needs YESTERDAY! In-Reply-To: <5474209F.7080702@tbee.org> References: <5473024C.5080805@tbee.org> <547310A1.2010700@tbee.org> <5473267C.6060104@tbee.org> <5474209F.7080702@tbee.org> Message-ID: On 25 November 2014 at 17:24, Tom Eugelink wrote: > the question is, should it be working good in one area or only half in two? ?That's an age-old problem I guess Tom. Personally I feel that traditional forms/dialogs based applications have enough support in Scene Builder as it is with version 2.0 (and I am sure another release can't be far away) to be able to be done effectively so perhaps more advanced use cases can be given a bit of love now?? From ooo_saturn7 at mail.ru Tue Nov 25 07:00:05 2014 From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=) Date: Tue, 25 Nov 2014 10:00:05 +0300 Subject: =?UTF-8?B?T3BlbkpGWCArIE9wZW5TY2VuZUJ1aWxkZXIgKyBOZXRiZWFucysgT1NHSTog?= =?UTF-8?B?Q29udHJvbGxlciBwYXRo?= Message-ID: <1416898805.352666771@f311.i.mail.ru> Versions:openjfx-8,netbeans-8. So, the problem was that we couldn't add openSceneBuilder to netbeans. We found out that in oracle scene builder there is some binary program that netbeans needs to work with, but in open scenebuilder we didn't find that program. So we decided to write simple netbeans module that starts open source builder (via Runtime.getRuntime().exec..) and passes as argument fxml file. Everything ok. However we use only osgi. So we put our fxml files in src/main/resources/fxml folder. In this case when we open fxml file via our netbeans module, scene builder can't find Controller. In official doc >The path field contains the fully qualified Java class name of the controller class file, which must be located in the same folder, a sub-folder, or a parent folder in which the FXML file is saved. A suggested Java class name is displayed when you click the down arrow that is circled in Figure 8-6 and the controller class location has already been resolved by Scene Builder. And now >If you are using NetBeans IDE with JavaFX Scene Builder and your FXML file is located in a NetBeans project, then the Controller class java file can be located in any java package inside your NetBeans project's src folder. It's clear that in osgi we can't fulfill these conditions. However oracle program somehow can do it. We tried to pass to scenebuilder controllerpath as argument but it tries to parse all argumetns as xml files. So the question, how can we pass the controllerFilePath to scene builder jar file? -- Alex From martin.sladecek at oracle.com Tue Nov 25 08:19:11 2014 From: martin.sladecek at oracle.com (Martin Sladecek) Date: Tue, 25 Nov 2014 09:19:11 +0100 Subject: Focus Traversal Engine In-Reply-To: <6C6CE4A9B94582468498929459CEEF710FD53233@vmex1.saxsys.de> References: <6C6CE4A9B94582468498929459CEEF710FD53233@vmex1.saxsys.de> Message-ID: <54743B7F.1080308@oracle.com> Hi Alex, unfortunately, there's none. The simplest way would be to use ParentTraversalEngine with the risk that you will have to update the code once (and if) the traversal engine goes public. You can never get the 100% correct traversal with event filters as the first node that will be traversed will get picked by some outer traversal engine and only then you can start with your traversal. It's possible to workaround this by placing your preferred first node as the first focusable node in your control's tree and do the same for your preferred last node (for Shift+TAB traversal). The other difficulty event filters have is that you will disable internal traversal of embedded control too, so this is rather something that can be used when you want to handle all the traversable nodes inside your control. Hope it helps, -Martin On 24.11.2014 16:50, Casall, Alexander wrote: > Hi, > is there an elegant way to change the focus traversal order without using Private APIs (TraversalEngine) or creating an own mechanism using EventFilters? > Cheers Alex > From kirill.kirichenko at oracle.com Tue Nov 25 10:07:36 2014 From: kirill.kirichenko at oracle.com (Kirill Kirichenko) Date: Tue, 25 Nov 2014 14:07:36 +0400 Subject: [8u40] RFR: RT-38973: Media produces extraneous debugging when running Ensemble8 In-Reply-To: <9BE970D8-5B5E-4746-A54A-1A2B0E64C137@oracle.com> References: <9BE970D8-5B5E-4746-A54A-1A2B0E64C137@oracle.com> Message-ID: <547454E8.3010701@oracle.com> Approved On 25.11.14 0:10, David DeHaven wrote: > > Kevin, Kirill, please review the following fix for 8u40: > > JIRA: > https://javafx-jira.kenai.com/browse/RT-38973 > > Webrev: > http://cr.openjdk.java.net/~ddehaven/RT-38973/rt.0/ > > I added an additional (annoying) compiler warning fix. > > -DrD- > From matthieu at brouillard.fr Tue Nov 25 14:26:44 2014 From: matthieu at brouillard.fr (Matthieu BROUILLARD) Date: Tue, 25 Nov 2014 15:26:44 +0100 Subject: Public way to monitor JavaFX Windows Message-ID: Hi all, I'd like to know if there is a public way to monitor all "root" window JavaFX objects (Window, Stage, PopupWindow). All what I have found until now is "private impl" - com.sun.javafx.stage.StageHelper.getStages(), observable but relevant only for Stages - javafx.stage.Window.impl_getWindows(), used inside ScenicView but not listenable If there is not a public API, I'll create a JIRA for this. Matthieu From hastebrot at gmail.com Tue Nov 25 14:39:32 2014 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Tue, 25 Nov 2014 15:39:32 +0100 Subject: Public way to monitor JavaFX Windows In-Reply-To: References: Message-ID: Hi! TestFX uses `javafx.stage.Window.impl_getWindows()` to search nodes for user input simulation and state verification. I haven't spotted a public way to retrieve or even monitor windows or stages. Also: Searching for nodes within all windows simplifies tests for open popup window drastically in comparision to e.g. the FEST-Swing test framework. --Benjamin On 11/25/14, Matthieu BROUILLARD wrote: > Hi all, > > I'd like to know if there is a public way to monitor all "root" window > JavaFX objects (Window, Stage, PopupWindow). > > All what I have found until now is "private impl" > > - com.sun.javafx.stage.StageHelper.getStages(), observable but relevant > only for Stages > - javafx.stage.Window.impl_getWindows(), used inside ScenicView but not > listenable > > If there is not a public API, I'll create a JIRA for this. > > Matthieu > From kevin.rushforth at oracle.com Tue Nov 25 15:50:49 2014 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 25 Nov 2014 07:50:49 -0800 Subject: Public way to monitor JavaFX Windows In-Reply-To: References: Message-ID: <5474A559.7050402@oracle.com> There is a JIRA already filed to track this request: https://javafx-jira.kenai.com/browse/RT-36196 -- Kevin Matthieu BROUILLARD wrote: > Hi all, > > I'd like to know if there is a public way to monitor all "root" window > JavaFX objects (Window, Stage, PopupWindow). > > All what I have found until now is "private impl" > > - com.sun.javafx.stage.StageHelper.getStages(), observable but relevant > only for Stages > - javafx.stage.Window.impl_getWindows(), used inside ScenicView but not > listenable > > If there is not a public API, I'll create a JIRA for this. > > Matthieu > From matthieu at brouillard.fr Tue Nov 25 16:22:53 2014 From: matthieu at brouillard.fr (Matthieu BROUILLARD) Date: Tue, 25 Nov 2014 17:22:53 +0100 Subject: Public way to monitor JavaFX Windows In-Reply-To: <5474A559.7050402@oracle.com> References: <5474A559.7050402@oracle.com> Message-ID: Thanks for the info Kevin, I commented the ticket and up-voted it. Meanwhile we'll have to keep the polling on Window.impl_getWindows() Matthieu On Tue, Nov 25, 2014 at 4:50 PM, Kevin Rushforth wrote: > There is a JIRA already filed to track this request: > > https://javafx-jira.kenai.com/browse/RT-36196 > > -- Kevin > > > Matthieu BROUILLARD wrote: > >> Hi all, >> >> I'd like to know if there is a public way to monitor all "root" window >> JavaFX objects (Window, Stage, PopupWindow). >> >> All what I have found until now is "private impl" >> >> - com.sun.javafx.stage.StageHelper.getStages(), observable but >> relevant >> only for Stages >> - javafx.stage.Window.impl_getWindows(), used inside ScenicView but >> not >> listenable >> >> If there is not a public API, I'll create a JIRA for this. >> >> Matthieu >> >> > From anton.tarasov at oracle.com Wed Nov 26 14:10:26 2014 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 26 Nov 2014 17:10:26 +0300 Subject: [8u40] review request: RT-38904 [WebView] data-protocol not supported in sandboxed WebView Message-ID: <5475DF52.4010300@oracle.com> Hi Kevin, Leonid, Please review the fix: https://javafx-jira.kenai.com/browse/RT-38904 http://cr.openjdk.java.net/~ant/RT-38904/webrev.0 Thanks, Anton. From johan at lodgon.com Wed Nov 26 18:11:13 2014 From: johan at lodgon.com (Johan Vos) Date: Wed, 26 Nov 2014 19:11:13 +0100 Subject: JavaFX 8u40 EA for Android Message-ID: Hi, Earlier today, I uploaded an early access build of the JavaFX 8u40 SDK for Android (Dalvik). See https://groups.google.com/forum/#!msg/javafxandroid/hOYMtMhl3HQ/GjwM-YPbUzQJ for the announcement. The source code for this build is in https://bitbucket.org/javafxports/8u40-rt and that repository started as a mirror of the OpenJFX 8udev at November 15 (so we're not behind too much). It is my intention to go over all changes that I had to apply, and to propose them as patches for OpenJFX. However, I took some shortcuts in a few issues that would pollute the OpenJFX tree, hence I need some time to cleanup first. Apart from support for 8u40, the 2 major things in this EA release are: 1) we are now using Monocle instead of Lens. That is, we use the Monocle Glass implementation, but still use the Prism eglfb implementation. Long story on why this is the case, but eventually we will use monocle there as well. 2) we have now support for the android gradle plugin. As a consequence, a JavaFX project with a single build.gradle file can be used to generate an Android Package and install it on a device. This will make life of developers much easier. I think there are 2 more things that are needed in order to lower the barrier for developers: 1) IDE integration. With the single build.gradle file, this should be possible, but I have zero experience in developing plugins. 2) java(fx)packager integration. It would be so nice if we could just build Android packages using the Java Packager. Would this be an option? - Johan From nitin at swapbox.com Wed Nov 26 18:49:00 2014 From: nitin at swapbox.com (Nitin S) Date: Wed, 26 Nov 2014 10:49:00 -0800 Subject: How to change default click-to-focus behavior? Message-ID: Hi all, Is there a way to have TextFields take focus on mouse-released instead of mouse-pressed? We're trying to get closer to iOS behavior where you can scroll down on a ScrollPane even if your finger lands on a control. Current behavior is: as soon as the TextField receives mouse-pressed it takes focus preventing scroll. Nitin From danno.ferrin at oracle.com Wed Nov 26 19:02:41 2014 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Wed, 26 Nov 2014 12:02:41 -0700 Subject: JavaFX 8u40 EA for Android In-Reply-To: References: Message-ID: On Nov 26, 2014, at 11:11 AM, Johan Vos wrote: > Hi, > > Earlier today, I uploaded an early access build of the JavaFX 8u40 SDK for > Android (Dalvik). See > https://groups.google.com/forum/#!msg/javafxandroid/hOYMtMhl3HQ/GjwM-YPbUzQJ > for the announcement. > > The source code for this build is in > https://bitbucket.org/javafxports/8u40-rt and that repository started as a > mirror of the OpenJFX 8udev at November 15 (so we're not behind too much). > It is my intention to go over all changes that I had to apply, and to > propose them as patches for OpenJFX. However, I took some shortcuts in a > few issues that would pollute the OpenJFX tree, hence I need some time to > cleanup first. > > Apart from support for 8u40, the 2 major things in this EA release are: > > 1) we are now using Monocle instead of Lens. That is, we use the Monocle > Glass implementation, but still use the Prism eglfb implementation. Long > story on why this is the case, but eventually we will use monocle there as > well. > > 2) we have now support for the android gradle plugin. As a consequence, a > JavaFX project with a single build.gradle file can be used to generate an > Android Package and install it on a device. > This will make life of developers much easier. > > I think there are 2 more things that are needed in order to lower the > barrier for developers: > 1) IDE integration. With the single build.gradle file, this should be > possible, but I have zero experience in developing plugins. > 2) java(fx)packager integration. It would be so nice if we could just build > Android packages using the Java Packager. Would this be an option? > > - Johan This is (now) possible. I don't think it would be distributed with the Oracle JDK but I put the hooks in for 8u20 to allow external bundlers to be used by the bundling engine. so it can be distributed as a library to be used by the plugin. What I need is a list of instructions on what to do, including software that is assumed to be installed. If the instructions would start from the user providing a set of jars for a JavaFX desktop application, and enumerating what metadata beyond that needs to be provided I could automate the rest. From johan at lodgon.com Wed Nov 26 19:39:26 2014 From: johan at lodgon.com (Johan Vos) Date: Wed, 26 Nov 2014 20:39:26 +0100 Subject: JavaFX 8u40 EA for Android In-Reply-To: References: Message-ID: Hi Danno, Is it possible to execute a gradle script as part of the (external) bundler? We have a rather simple build.gradle file that uses the android plugin and that has almost no metadata (if your application uses external libraries, they have to be added in the dependency section). I added the structure of the simple HelloAndroid demo in attachment. The reason I want to use this gradle script is that it leverages the android plugin which does all the work (convert to dex, build packages etc). We used to do this with an ant build, but that is much more complex. Before I write down the details, it would be nice to hear if this is possible with the current hooks in the packager: 1. create a build.gradle file based on a template and on some metadata (the application jar and external dependencies) 2. also create a AndroidManifest.xml file based on a template and some more metadata (the name of the application, optionally the minimal android version that is required, an icon,...) 3. download the android SDK and JavaFX-Dalvik SDK in case the user doesn't have this yet. The locations of those 2 files are used by the build.gradle file in step 1 4. run the gradle command to execute the gradle script. There are different commands for creating packages (debug/release) and/or for installing them on a device (to test). If this approach is not feasable, I will try to break down the functionality of the Android plugin into a number of steps. Thanks, - Johan 2014-11-26 20:02 GMT+01:00 Danno Ferrin : > > On Nov 26, 2014, at 11:11 AM, Johan Vos wrote: > > > Hi, > > > > Earlier today, I uploaded an early access build of the JavaFX 8u40 SDK > for > > Android (Dalvik). See > > > https://groups.google.com/forum/#!msg/javafxandroid/hOYMtMhl3HQ/GjwM-YPbUzQJ > > for the announcement. > > > > The source code for this build is in > > https://bitbucket.org/javafxports/8u40-rt and that repository started > as a > > mirror of the OpenJFX 8udev at November 15 (so we're not behind too > much). > > It is my intention to go over all changes that I had to apply, and to > > propose them as patches for OpenJFX. However, I took some shortcuts in a > > few issues that would pollute the OpenJFX tree, hence I need some time to > > cleanup first. > > > > Apart from support for 8u40, the 2 major things in this EA release are: > > > > 1) we are now using Monocle instead of Lens. That is, we use the Monocle > > Glass implementation, but still use the Prism eglfb implementation. Long > > story on why this is the case, but eventually we will use monocle there > as > > well. > > > > 2) we have now support for the android gradle plugin. As a consequence, a > > JavaFX project with a single build.gradle file can be used to generate an > > Android Package and install it on a device. > > This will make life of developers much easier. > > > > I think there are 2 more things that are needed in order to lower the > > barrier for developers: > > 1) IDE integration. With the single build.gradle file, this should be > > possible, but I have zero experience in developing plugins. > > 2) java(fx)packager integration. It would be so nice if we could just > build > > Android packages using the Java Packager. Would this be an option? > > > > - Johan > > This is (now) possible. I don't think it would be distributed with the > Oracle JDK but I put the hooks in for 8u20 to allow external bundlers to be > used by the bundling engine. so it can be distributed as a library to be > used by the plugin. > > What I need is a list of instructions on what to do, including software > that is assumed to be installed. If the instructions would start from the > user providing a set of jars for a JavaFX desktop application, and > enumerating what metadata beyond that needs to be provided I could automate > the rest. From danno.ferrin at oracle.com Wed Nov 26 20:36:37 2014 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Wed, 26 Nov 2014 13:36:37 -0700 Subject: JavaFX 8u40 EA for Android In-Reply-To: References: Message-ID: <154A140D-FD71-4D0C-82E8-407BF229D20A@oracle.com> On Nov 26, 2014, at 12:39 PM, Johan Vos wrote: > Hi Danno, > > Is it possible to execute a gradle script as part of the (external) bundler? Possible, yes. I don't think it is a good idea. The bundler would need to depend on a gradle runtime and stand a build dir up and call it. Which would make maven and nested gradle builds a mess. If the build is deeply integrated to the way gradle does things, it bodes poorly for a stand alone packager. Of couse it seems to me that android is deeply embedding itself with gradle so this may be unavoidable. > We have a rather simple build.gradle file that uses the android plugin and that has almost no metadata (if your application uses external libraries, they have to be added in the dependency section). I added the structure of the simple HelloAndroid demo in attachment. > > The reason I want to use this gradle script is that it leverages the android plugin which does all the work (convert to dex, build packages etc). We used to do this with an ant build, but that is much more complex. > That's the point of the bundler. Move it from point A to point B and hiding all of the crazy inner details. > Before I write down the details, it would be nice to hear if this is possible with the current hooks in the packager: > 1. create a build.gradle file based on a template and on some metadata (the application jar and external dependencies) > 2. also create a AndroidManifest.xml file based on a template and some more metadata (the name of the application, optionally the minimal android version that is required, an icon,...) > 3. download the android SDK and JavaFX-Dalvik SDK in case the user doesn't have this yet. The locations of those 2 files are used by the build.gradle file in step 1 > 4. run the gradle command to execute the gradle script. There are different commands for creating packages (debug/release) and/or for installing them on a device (to test). > > If this approach is not feasable, I will try to break down the functionality of the Android plugin into a number of steps. > It is possible, we basically do this for all the bundlers, set up some files and the hand off to InnoSetup, or WiX, or rpm, or dpkg, or mac tools. So that would increase the build reqs to require that Android SDK is installed, the gradle plugin is installed, and gradle is installed somewhere. Are there default/recommended locations for those installs? (at least per platform, one for win, one for Mac, one for linux). Or should I sniff the PATH? > Thanks, > > - Johan > > > > 2014-11-26 20:02 GMT+01:00 Danno Ferrin : > > On Nov 26, 2014, at 11:11 AM, Johan Vos wrote: > > > Hi, > > > > Earlier today, I uploaded an early access build of the JavaFX 8u40 SDK for > > Android (Dalvik). See > > https://groups.google.com/forum/#!msg/javafxandroid/hOYMtMhl3HQ/GjwM-YPbUzQJ > > for the announcement. > > > > The source code for this build is in > > https://bitbucket.org/javafxports/8u40-rt and that repository started as a > > mirror of the OpenJFX 8udev at November 15 (so we're not behind too much). > > It is my intention to go over all changes that I had to apply, and to > > propose them as patches for OpenJFX. However, I took some shortcuts in a > > few issues that would pollute the OpenJFX tree, hence I need some time to > > cleanup first. > > > > Apart from support for 8u40, the 2 major things in this EA release are: > > > > 1) we are now using Monocle instead of Lens. That is, we use the Monocle > > Glass implementation, but still use the Prism eglfb implementation. Long > > story on why this is the case, but eventually we will use monocle there as > > well. > > > > 2) we have now support for the android gradle plugin. As a consequence, a > > JavaFX project with a single build.gradle file can be used to generate an > > Android Package and install it on a device. > > This will make life of developers much easier. > > > > I think there are 2 more things that are needed in order to lower the > > barrier for developers: > > 1) IDE integration. With the single build.gradle file, this should be > > possible, but I have zero experience in developing plugins. > > 2) java(fx)packager integration. It would be so nice if we could just build > > Android packages using the Java Packager. Would this be an option? > > > > - Johan > > This is (now) possible. I don't think it would be distributed with the Oracle JDK but I put the hooks in for 8u20 to allow external bundlers to be used by the bundling engine. so it can be distributed as a library to be used by the plugin. > > What I need is a list of instructions on what to do, including software that is assumed to be installed. If the instructions would start from the user providing a set of jars for a JavaFX desktop application, and enumerating what metadata beyond that needs to be provided I could automate the rest. > > From joeri at lodgon.com Wed Nov 26 21:12:47 2014 From: joeri at lodgon.com (Joeri Sykora) Date: Wed, 26 Nov 2014 22:12:47 +0100 Subject: JavaFX 8u40 EA for Android In-Reply-To: <154A140D-FD71-4D0C-82E8-407BF229D20A@oracle.com> References: <154A140D-FD71-4D0C-82E8-407BF229D20A@oracle.com> Message-ID: Hello Danno, the location to both the android sdk and the dalvik sdk should currently already be provided by the developer by specifying it in the local.properties file. About the need for a gradle installation, can't we use the gradle wrapper for this to specify which gradle version we should depend on. The gradle wrapper was built for this purpose: to download and install the correct gradle version if it couldn't be found on the system. Op 26-nov.-2014 21:37 schreef "Danno Ferrin" : > > On Nov 26, 2014, at 12:39 PM, Johan Vos wrote: > > > Hi Danno, > > > > Is it possible to execute a gradle script as part of the (external) > bundler? > > Possible, yes. I don't think it is a good idea. The bundler would need > to depend on a gradle runtime and stand a build dir up and call it. Which > would make maven and nested gradle builds a mess. > > If the build is deeply integrated to the way gradle does things, it bodes > poorly for a stand alone packager. Of couse it seems to me that android is > deeply embedding itself with gradle so this may be unavoidable. > > > We have a rather simple build.gradle file that uses the android plugin > and that has almost no metadata (if your application uses external > libraries, they have to be added in the dependency section). I added the > structure of the simple HelloAndroid demo in attachment. > > > > The reason I want to use this gradle script is that it leverages the > android plugin which does all the work (convert to dex, build packages > etc). We used to do this with an ant build, but that is much more complex. > > > > That's the point of the bundler. Move it from point A to point B and > hiding all of the crazy inner details. > > > Before I write down the details, it would be nice to hear if this is > possible with the current hooks in the packager: > > 1. create a build.gradle file based on a template and on some metadata > (the application jar and external dependencies) > > 2. also create a AndroidManifest.xml file based on a template and some > more metadata (the name of the application, optionally the minimal android > version that is required, an icon,...) > > 3. download the android SDK and JavaFX-Dalvik SDK in case the user > doesn't have this yet. The locations of those 2 files are used by the > build.gradle file in step 1 > > 4. run the gradle command to execute the gradle script. There are > different commands for creating packages (debug/release) and/or for > installing them on a device (to test). > > > > If this approach is not feasable, I will try to break down the > functionality of the Android plugin into a number of steps. > > > > It is possible, we basically do this for all the bundlers, set up some > files and the hand off to InnoSetup, or WiX, or rpm, or dpkg, or mac tools. > > So that would increase the build reqs to require that Android SDK is > installed, the gradle plugin is installed, and gradle is installed > somewhere. Are there default/recommended locations for those installs? > (at least per platform, one for win, one for Mac, one for linux). Or > should I sniff the PATH? > > > Thanks, > > > > - Johan > > > > > > > > 2014-11-26 20:02 GMT+01:00 Danno Ferrin : > > > > On Nov 26, 2014, at 11:11 AM, Johan Vos wrote: > > > > > Hi, > > > > > > Earlier today, I uploaded an early access build of the JavaFX 8u40 SDK > for > > > Android (Dalvik). See > > > > https://groups.google.com/forum/#!msg/javafxandroid/hOYMtMhl3HQ/GjwM-YPbUzQJ > > > for the announcement. > > > > > > The source code for this build is in > > > https://bitbucket.org/javafxports/8u40-rt and that repository started > as a > > > mirror of the OpenJFX 8udev at November 15 (so we're not behind too > much). > > > It is my intention to go over all changes that I had to apply, and to > > > propose them as patches for OpenJFX. However, I took some shortcuts in > a > > > few issues that would pollute the OpenJFX tree, hence I need some time > to > > > cleanup first. > > > > > > Apart from support for 8u40, the 2 major things in this EA release are: > > > > > > 1) we are now using Monocle instead of Lens. That is, we use the > Monocle > > > Glass implementation, but still use the Prism eglfb implementation. > Long > > > story on why this is the case, but eventually we will use monocle > there as > > > well. > > > > > > 2) we have now support for the android gradle plugin. As a > consequence, a > > > JavaFX project with a single build.gradle file can be used to generate > an > > > Android Package and install it on a device. > > > This will make life of developers much easier. > > > > > > I think there are 2 more things that are needed in order to lower the > > > barrier for developers: > > > 1) IDE integration. With the single build.gradle file, this should be > > > possible, but I have zero experience in developing plugins. > > > 2) java(fx)packager integration. It would be so nice if we could just > build > > > Android packages using the Java Packager. Would this be an option? > > > > > > - Johan > > > > This is (now) possible. I don't think it would be distributed with the > Oracle JDK but I put the hooks in for 8u20 to allow external bundlers to be > used by the bundling engine. so it can be distributed as a library to be > used by the plugin. > > > > What I need is a list of instructions on what to do, including software > that is assumed to be installed. If the instructions would start from the > user providing a set of jars for a JavaFX desktop application, and > enumerating what metadata beyond that needs to be provided I could automate > the rest. > > > > > > From james.graham at oracle.com Thu Nov 27 01:00:36 2014 From: james.graham at oracle.com (Jim Graham) Date: Wed, 26 Nov 2014 17:00:36 -0800 Subject: [8u40] review request: RT-39327 retina windows are double scaled when started from external monitors on Mavericks Message-ID: <547677B4.6070706@oracle.com> webrev: http://cr.openjdk.java.net/~flar/RT-39327/webrev.00/ Jira: https://javafx-jira.kenai.com/browse/RT-39327 ...jim From johan at lodgon.com Thu Nov 27 08:59:21 2014 From: johan at lodgon.com (Johan Vos) Date: Thu, 27 Nov 2014 09:59:21 +0100 Subject: from Glass to Prism Message-ID: Hi, One of the android-specific things (but I think it can be generic) I added to the Android Monocle port, is the configuration change of the screen. When rotating a device, the dimensions of the screen change and the GL context might become invalid. This is now handled by the monocle implementation, and the next time a pulse occurs, everything will be rendered correctly. So in case the Scene contains an animation or something else that will generate a pulse, the whole scene is rendered immediately in the correct dimensions. In the other case, the content of the screen is out of focus until a button is pressed or so. While I see several ways to trigger a pulse from within Monocle (or Glass in general), I was wondering about the most appropriate way to do this? Thanks, - Johan From hastebrot at gmail.com Thu Nov 27 10:34:41 2014 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Thu, 27 Nov 2014 11:34:41 +0100 Subject: Monocle in 8u25 In-Reply-To: References: <545A788D.9030509@tbee.org> <546310E1.8000702@tbee.org> <54659F72.7020603@tbee.org> Message-ID: Well, unit tests for the glass robot are finished and the integration tests pass now. This PR will be pulled into master very soon. :) https://github.com/TestFX/TestFX/pull/159#commits-pushed-11b9b64 Headless mode in TestFX will be behind the properties: -Dtestfx.robot=glass -Dtestfx.headless=true -Dprism.order=sw I decided to keep the AWT robot as default, for compability and because the Node.startDragAndDrop() issue is not resolved. @Neil: >Does that explain what you have seen? I'm not quite sure. Thanks for the hint. I'll need to investigate this futher. On 11/17/14, ngalarneau at abinitio.com wrote: > Hi Benjamin, > > Your progress sounds very good! > > In your email below, you said: "Also I thought that events with > Platform.runLater() will be processed first-in-first-out, but it seems > that this is not the case." > > Kevin, on an email on Nov. 5th to this list, said that the only exception > to Platform.runLater() Runnables being processed in order was in the case > of a showAndWait() being done. That blocks the current thread, which stops > the current Runnable from completing while a new thread takes the next > event/Runnable from the queue. In that case later Runnables would be > processed before the earlier one completes. > > Does that explain what you have seen? > > > Neil > > > > > From: Benjamin Gudehus > To: ngalarneau at abinitio.com, > Cc: Tom Eugelink , "openjfx-dev at openjdk.java.net" > > Date: 11/15/2014 10:50 AM > Subject: Re: Monocle in 8u25 > > > > Small update: > > Regarding (2) "requires interactions to be run withing the JavaFX thread": > Nearly all integration tests for TestFX pass now. However the interactions > freeze when using Glass robot, Node.startDragAndDrop() and > ClipboardContent.putString() together. I guess the timing with > Platform.runLater() needs some work. > > Regarding (3) "retrieve screenshot images in headless mode": I forgot to > use "-Dprism.order=sw". Screenshots work in headless mode. > > --Benjamin > > On Sat, Nov 15, 2014 at 1:48 AM, Benjamin Gudehus > wrote: > You can find the PR for headless support in TestFX here: > https://github.com/TestFX/TestFX/pull/159 > > There are some issues with the Glass robot. We need this robot in order to > simulate user interactions in headless mode. > > One problem is, that the Glass robot (1) requires an JavaFX application to > be set up. TestFX initializes the robots first and then launches the > Application. I worked-around this problem, by initializing the Glass robot > just before the first user interaction is made. > > Another problem is, that the Glass robot (2) requires interactions to be > run within the JavaFX thread. From the integration tests I've wrote it > looks that we need to wait for the events in the JavaFX thread to complete > for certain interactions, e.g. we need to wait after mouseMove() in order > to do mouseClick(). With the AWT robot we only needed to wait for the > events triggered by interactions to complete (let's call them > post-interaction events). Now it seems that we also need to wait for the > interactions itself to complete, which then will also trigger the > post-interaction events. I'll need to visualize different interaction > events, post-interaction events and the event waiting, and decide when we > need to use the semaphore solution we currently use to wait for > post-interaction events. Also I thought that events with > Platform.runLater() will be processed first-in-first-out, but it seems > that this is not the case. > > Yet, another problem is, that I did not manage to (3) retrieve screenshot > images in headless mode with the Glass robot. Although it works in normal > mode. Maybe the JavaFX event robot can retrieve the screenshots. > Interestingly the HeadlessScreen updates it's framebuffer ( > https://github.com/TestFX/Monocle/blob/0ab3986f4c/src/main/java/com/sun/glass/ui/monocle/headless/HeadlessScreen.java#L117 > ). > > Regards, > Benjamin > > > > > > > NOTICE from Ab Initio: This email (including any attachments) may contain > information that is subject to confidentiality obligations or is legally > privileged, and sender does not waive confidentiality or privilege. If > received in error, please notify the sender, delete this email, and make > no further use, disclosure, or distribution. From james.graham at oracle.com Thu Nov 27 20:37:37 2014 From: james.graham at oracle.com (Jim Graham) Date: Thu, 27 Nov 2014 12:37:37 -0800 Subject: [8u40] review request: RT-39327 retina windows are double scaled when started from external monitors on Mavericks In-Reply-To: <547677B4.6070706@oracle.com> References: <547677B4.6070706@oracle.com> Message-ID: <54778B91.8090508@oracle.com> In case Kevin is not back before our code close on Sunday night, anyone with access to a retina machine (or intimate familiarity with MacOS and Glass) feel free to review this fix... ...jim On 11/26/14 5:00 PM, Jim Graham wrote: > webrev: http://cr.openjdk.java.net/~flar/RT-39327/webrev.00/ > Jira: https://javafx-jira.kenai.com/browse/RT-39327 > > ...jim > From diego.cirujano-cuesta at zeiss.com Thu Nov 27 20:59:07 2014 From: diego.cirujano-cuesta at zeiss.com (Cirujano Cuesta, Diego) Date: Thu, 27 Nov 2014 20:59:07 +0000 Subject: VirtualFlow does not render correctly Message-ID: Hi all, We found out, that the controls that use VirtualFlow -ListView, TableView or TreeView- have problems with cells when the cell height depends on the width(for example with a flowpane as graphic of the cell) if the scrollbar of the listview is shown. I would like to know if is there anyone there with something like this in tableview or treeview and if there is any workaround or solution. We also saw where is the error in virtualflow and we will try to provide ideas for the solution of the bug in the ticket. Ticket: https://javafx-jira.kenai.com/browse/RT-39521 Cheers, Diego From johan at lodgon.com Thu Nov 27 21:13:32 2014 From: johan at lodgon.com (Johan Vos) Date: Thu, 27 Nov 2014 22:13:32 +0100 Subject: shader question Message-ID: Hi, I'm not sure this will ever work, but I started looking into JavaFX 3D on Android. This is the info from the GPU on my Nexus 5: Graphics Vendor: Qualcomm Renderer: Adreno (TM) 330 Version: OpenGL ES 3.0 V at 95.0 AU@ (GIT at I68fa98814b) While that looks fine, running a simple JavaFX 3D sample crashes in the render phase: java.lang.RuntimeException: Error creating shader program at com.sun.prism.es2.ES2Shader.createFromSource(ES2Shader.java:158) at com.sun.prism.es2.ES2PhongShader.getShader(ES2PhongShader.java:177) I debugged the native code, and the native call to nCreateProgram in native-prism-es2/GLContext.c fails in the line ctxInfo->glGetProgramiv(shaderProgram, GL_LINK_STATUS, &success); (that is, success = GL_FALSE) Good enough, the error messages are retrieved, and printed in the log: Program link log: --From Vertex Shader: Error: Symbol lights defined with different precision in vertex and fragment shaders. Error: Symbol lights defined with different precision in vertex and fragment shaders. --From Fragment Shader: Error: Symbol lights defined with different precision in vertex and fragment shaders. Error: Symbol lights defined with different precision in vertex and fragment shaders. Does anyone have an idea about this? Or is 3D on Android just over ambitious? Thanks, - Johan From vadim.pakhnushev at oracle.com Fri Nov 28 15:01:50 2014 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 28 Nov 2014 18:01:50 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <54788E5E.3050204@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim From anton.nashatyrev at oracle.com Fri Nov 28 15:24:19 2014 From: anton.nashatyrev at oracle.com (Anton Nashatyrev) Date: Fri, 28 Nov 2014 18:24:19 +0300 Subject: [8u40] Review request: RT-32986: JVM crash while debugging JavaScript in WebView browser Message-ID: <547893A3.6070100@oracle.com> Hello Anton, Leonid could you please review the following fix: Bug: https://javafx-jira.kenai.com/browse/RT-32986 Webrev: http://cr.openjdk.java.net/~anashaty/RT-32986/webrev.00/ Thanks! Anton. From vadim.pakhnushev at oracle.com Sat Nov 29 12:49:16 2014 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Sat, 29 Nov 2014 15:49:16 +0300 Subject: [8u40] Review request for RT-39528: Repeated ListProperty.bindContent() silently breaks the list Message-ID: <5479C0CC.4060002@oracle.com> Hi Kevin, Please review the fix: https://javafx-jira.kenai.com/browse/RT-39528 http://cr.openjdk.java.net/~vadim/RT-39528/webrev.00/ Thanks, Vadim From hastebrot at gmail.com Sun Nov 30 09:09:53 2014 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Sun, 30 Nov 2014 10:09:53 +0100 Subject: Monocle in 8u25 In-Reply-To: References: <545A788D.9030509@tbee.org> <546310E1.8000702@tbee.org> <54659F72.7020603@tbee.org> Message-ID: A snapshot build (testfx-core-4.0.0-20141130.085021-5.jar) with headless support (using Monocle for JDK 8u20 and above) is available at [1]. If you run headless mode for TestFX in a desktop environment, add Monocle as an external jar [2] into your classpath and use the properties: -Dtestfx.robot=glass -Dtestfx.headless=true -Dprism.order=sw If you've managed to run TestFX in an embedded environment please use: -Dtestfx.robot=glass -Dglass.platform=Monocle -Dmonocle.platform=Headless -Dprism.order=sw It will be also included in the first beta build of TestFX 4 (TestFX-4.0.0-beta.1) coming soon. [1] https://github.com/TestFX/TestFX/releases [2] https://github.com/TestFX/Monocle/releases Regards, Benjamin On Thu, Nov 27, 2014 at 11:34 AM, Benjamin Gudehus wrote: > Well, unit tests for the glass robot are finished and the integration > tests pass now. This PR will be pulled into master very soon. :) > > https://github.com/TestFX/TestFX/pull/159#commits-pushed-11b9b64 > > Headless mode in TestFX will be behind the properties: > -Dtestfx.robot=glass -Dtestfx.headless=true -Dprism.order=sw > > I decided to keep the AWT robot as default, for compability and > because the Node.startDragAndDrop() issue is not resolved. > > @Neil: > >Does that explain what you have seen? > I'm not quite sure. Thanks for the hint. I'll need to investigate this > futher. > > > On 11/17/14, ngalarneau at abinitio.com wrote: > > Hi Benjamin, > > > > Your progress sounds very good! > > > > In your email below, you said: "Also I thought that events with > > Platform.runLater() will be processed first-in-first-out, but it seems > > that this is not the case." > > > > Kevin, on an email on Nov. 5th to this list, said that the only exception > > to Platform.runLater() Runnables being processed in order was in the case > > of a showAndWait() being done. That blocks the current thread, which > stops > > the current Runnable from completing while a new thread takes the next > > event/Runnable from the queue. In that case later Runnables would be > > processed before the earlier one completes. > > > > Does that explain what you have seen? > > > > > > Neil > > > > > > > > > > From: Benjamin Gudehus > > To: ngalarneau at abinitio.com, > > Cc: Tom Eugelink , "openjfx-dev at openjdk.java.net" > > > > Date: 11/15/2014 10:50 AM > > Subject: Re: Monocle in 8u25 > > > > > > > > Small update: > > > > Regarding (2) "requires interactions to be run withing the JavaFX > thread": > > Nearly all integration tests for TestFX pass now. However the > interactions > > freeze when using Glass robot, Node.startDragAndDrop() and > > ClipboardContent.putString() together. I guess the timing with > > Platform.runLater() needs some work. > > > > Regarding (3) "retrieve screenshot images in headless mode": I forgot to > > use "-Dprism.order=sw". Screenshots work in headless mode. > > > > --Benjamin > > > > On Sat, Nov 15, 2014 at 1:48 AM, Benjamin Gudehus > > wrote: > > You can find the PR for headless support in TestFX here: > > https://github.com/TestFX/TestFX/pull/159 > > > > There are some issues with the Glass robot. We need this robot in order > to > > simulate user interactions in headless mode. > > > > One problem is, that the Glass robot (1) requires an JavaFX application > to > > be set up. TestFX initializes the robots first and then launches the > > Application. I worked-around this problem, by initializing the Glass > robot > > just before the first user interaction is made. > > > > Another problem is, that the Glass robot (2) requires interactions to be > > run within the JavaFX thread. From the integration tests I've wrote it > > looks that we need to wait for the events in the JavaFX thread to > complete > > for certain interactions, e.g. we need to wait after mouseMove() in order > > to do mouseClick(). With the AWT robot we only needed to wait for the > > events triggered by interactions to complete (let's call them > > post-interaction events). Now it seems that we also need to wait for the > > interactions itself to complete, which then will also trigger the > > post-interaction events. I'll need to visualize different interaction > > events, post-interaction events and the event waiting, and decide when we > > need to use the semaphore solution we currently use to wait for > > post-interaction events. Also I thought that events with > > Platform.runLater() will be processed first-in-first-out, but it seems > > that this is not the case. > > > > Yet, another problem is, that I did not manage to (3) retrieve screenshot > > images in headless mode with the Glass robot. Although it works in normal > > mode. Maybe the JavaFX event robot can retrieve the screenshots. > > Interestingly the HeadlessScreen updates it's framebuffer ( > > > https://github.com/TestFX/Monocle/blob/0ab3986f4c/src/main/java/com/sun/glass/ui/monocle/headless/HeadlessScreen.java#L117 > > ). > > > > Regards, > > Benjamin > > > > > > > > > > > > > > NOTICE from Ab Initio: This email (including any attachments) may contain > > information that is subject to confidentiality obligations or is legally > > privileged, and sender does not waive confidentiality or privilege. If > > received in error, please notify the sender, delete this email, and make > > no further use, disclosure, or distribution. > From sven.reimers at gmail.com Sun Nov 30 14:53:16 2014 From: sven.reimers at gmail.com (Sven Reimers) Date: Sun, 30 Nov 2014 15:53:16 +0100 Subject: EA builds of 8u40 and 9 for arm (RaspberryPi) Message-ID: Hi guys, hope this is the correct mailing list to ask.. I was looking for ea builds of 8u40 and 9 for arm (RaspberryPi) on jdk8.java.net and jdl9.java.net, but I can't find them there... Any chance they get published once again? 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 * JUG Leader JUG Bodensee: http://www.jug-bodensee.de * Duke's Choice Award Winner 2009 * Blog: https://www.java.net//blog/sven * 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 vadim.pakhnushev at oracle.com Sun Nov 30 17:27:30 2014 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Sun, 30 Nov 2014 20:27:30 +0300 Subject: [8u40] Review request for RT-35133: Android: Some preview images in Ensemble8 are not displayed Message-ID: <547B5382.7020708@oracle.com> Jim, Please review this fix: https://javafx-jira.kenai.com/browse/RT-35133 http://cr.openjdk.java.net/~vadim/RT-35133/webrev.00/ Thanks, Vadim