Re: Ugly flashing when opening a css-styled stage
Thanks but it does not seem to improve the situation.
btw, I am using 1.8.0_05-b13 on Mac OS 10.9.3 on a retina MBP.
On Sun, Jun 1, 2014 at 9:59 PM, Jeff Martin j...@reportmill.com wrote:
I haven't seen this, but here's a hack you can try:
// Show stage transparent once to get proper drawing
_stage.setOpacity(0); _stage.show(); _stage.hide();
_stage.setOpacity(1);
I've done this before to trigger Stage to set it's width/height property
(which I needed to position the stage property).
jeff
On Jun 1, 2014, at 3:18 AM, Robert Krüger krue...@lesspain.de wrote:
Hi,
I'm in the process of evaluating Java FX 8 for our currently
Swing-based product (also Java 8) on OSX.
My first attempt to style a stage's background resulted in an ugly
flashing effect which I would classify as a show-stopper for
delivering a commercial product. This looks like it is caused by the
stage being drawn at least once before the style has been applied, and
I am wondering what the mistake is since my code is more or less a
straight-forward hello world:
package jfxtest;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;
public class JXTest extends Application {
@Override
public void start(Stage primaryStage) throws Exception {
final StackPane pane = new StackPane();
final Button closeButton = new Button(Close);
closeButton.setOnAction(event - primaryStage.close());
pane.getChildren().add(closeButton);
final Scene scene = new Scene(pane, 800, 600);
scene.getStylesheets().add(dark.css);
scene.getStylesheets();
primaryStage.setScene(scene);
primaryStage.setTitle(getClass().getSimpleName());
primaryStage.show();
}
public static void main(String[] args) {
launch(args);
}
}
with dark.css being:
.root {
-fx-background: rgb(54, 54, 54);
}
Is this a Mac-specific problem? Is there a workaround? Which of the
two mailing lists is the more appropriate one to post these things
(JFX problems which look like they might be platform-specific) to?
Thanks,
Robert
Re: Ugly flashing when opening a css-styled stage
To rule out CSS is the reason you could directly set the background:
pane.setBackground(new Background(new BackgroundFill(Color.rgb(54, 54,
54), CornerRadii.EMPTY, Insets.EMPTY)));
Does that improve the situation?
Tom
On 02.06.14 09:51, Robert Krüger wrote:
Thanks but it does not seem to improve the situation.
btw, I am using 1.8.0_05-b13 on Mac OS 10.9.3 on a retina MBP.
On Sun, Jun 1, 2014 at 9:59 PM, Jeff Martin j...@reportmill.com wrote:
I haven't seen this, but here's a hack you can try:
// Show stage transparent once to get proper drawing
_stage.setOpacity(0); _stage.show(); _stage.hide();
_stage.setOpacity(1);
I've done this before to trigger Stage to set it's width/height property
(which I needed to position the stage property).
jeff
On Jun 1, 2014, at 3:18 AM, Robert Krüger krue...@lesspain.de wrote:
Hi,
I'm in the process of evaluating Java FX 8 for our currently
Swing-based product (also Java 8) on OSX.
My first attempt to style a stage's background resulted in an ugly
flashing effect which I would classify as a show-stopper for
delivering a commercial product. This looks like it is caused by the
stage being drawn at least once before the style has been applied, and
I am wondering what the mistake is since my code is more or less a
straight-forward hello world:
package jfxtest;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;
public class JXTest extends Application {
@Override
public void start(Stage primaryStage) throws Exception {
final StackPane pane = new StackPane();
final Button closeButton = new Button(Close);
closeButton.setOnAction(event - primaryStage.close());
pane.getChildren().add(closeButton);
final Scene scene = new Scene(pane, 800, 600);
scene.getStylesheets().add(dark.css);
scene.getStylesheets();
primaryStage.setScene(scene);
primaryStage.setTitle(getClass().getSimpleName());
primaryStage.show();
}
public static void main(String[] args) {
launch(args);
}
}
with dark.css being:
.root {
-fx-background: rgb(54, 54, 54);
}
Is this a Mac-specific problem? Is there a workaround? Which of the
two mailing lists is the more appropriate one to post these things
(JFX problems which look like they might be platform-specific) to?
Thanks,
Robert
Re: Ugly flashing when opening a css-styled stage
No, it does not. So it is not the CSS.
On Mon, Jun 2, 2014 at 10:04 AM, Tom Schindl
tom.schi...@bestsolution.at wrote:
To rule out CSS is the reason you could directly set the background:
pane.setBackground(new Background(new BackgroundFill(Color.rgb(54, 54,
54), CornerRadii.EMPTY, Insets.EMPTY)));
Does that improve the situation?
Tom
On 02.06.14 09:51, Robert Krüger wrote:
Thanks but it does not seem to improve the situation.
btw, I am using 1.8.0_05-b13 on Mac OS 10.9.3 on a retina MBP.
On Sun, Jun 1, 2014 at 9:59 PM, Jeff Martin j...@reportmill.com wrote:
I haven't seen this, but here's a hack you can try:
// Show stage transparent once to get proper drawing
_stage.setOpacity(0); _stage.show(); _stage.hide();
_stage.setOpacity(1);
I've done this before to trigger Stage to set it's width/height property
(which I needed to position the stage property).
jeff
On Jun 1, 2014, at 3:18 AM, Robert Krüger krue...@lesspain.de wrote:
Hi,
I'm in the process of evaluating Java FX 8 for our currently
Swing-based product (also Java 8) on OSX.
My first attempt to style a stage's background resulted in an ugly
flashing effect which I would classify as a show-stopper for
delivering a commercial product. This looks like it is caused by the
stage being drawn at least once before the style has been applied, and
I am wondering what the mistake is since my code is more or less a
straight-forward hello world:
package jfxtest;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;
public class JXTest extends Application {
@Override
public void start(Stage primaryStage) throws Exception {
final StackPane pane = new StackPane();
final Button closeButton = new Button(Close);
closeButton.setOnAction(event - primaryStage.close());
pane.getChildren().add(closeButton);
final Scene scene = new Scene(pane, 800, 600);
scene.getStylesheets().add(dark.css);
scene.getStylesheets();
primaryStage.setScene(scene);
primaryStage.setTitle(getClass().getSimpleName());
primaryStage.show();
}
public static void main(String[] args) {
launch(args);
}
}
with dark.css being:
.root {
-fx-background: rgb(54, 54, 54);
}
Is this a Mac-specific problem? Is there a workaround? Which of the
two mailing lists is the more appropriate one to post these things
(JFX problems which look like they might be platform-specific) to?
Thanks,
Robert
Re: Ugly flashing when opening a css-styled stage
Hi Robert,
Which of the
two mailing lists is the more appropriate one to post these things
(JFX problems which look like they might be platform-specific) to?
FYI: the JDK Mac OS X Port Project has been completed long time ago, so
currently the macosx-port-dev@ mailing list isn't appropriate for almost
anything.
Please report JavaFX bugs at: https://javafx-jira.kenai.com/
AWT/Swing/JDK bugs can be reported at:
http://bugreport.java.com/bugreport/ (or http://bugs.sun.com/ )
If you wish to participate in the development of the technologies (e.g.
you want to contribute a patch for JavaFX or JDK platform), then you're
welcome to post your suggestions on the appropriate development mailing
lists (openjfx-dev@, awt-dev@, swing-dev@, etc.)
--
best regards,
Anthony
On 6/1/2014 12:18 PM, Robert Krüger wrote:
Hi,
I'm in the process of evaluating Java FX 8 for our currently
Swing-based product (also Java 8) on OSX.
My first attempt to style a stage's background resulted in an ugly
flashing effect which I would classify as a show-stopper for
delivering a commercial product. This looks like it is caused by the
stage being drawn at least once before the style has been applied, and
I am wondering what the mistake is since my code is more or less a
straight-forward hello world:
package jfxtest;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;
public class JXTest extends Application {
@Override
public void start(Stage primaryStage) throws Exception {
final StackPane pane = new StackPane();
final Button closeButton = new Button(Close);
closeButton.setOnAction(event - primaryStage.close());
pane.getChildren().add(closeButton);
final Scene scene = new Scene(pane, 800, 600);
scene.getStylesheets().add(dark.css);
scene.getStylesheets();
primaryStage.setScene(scene);
primaryStage.setTitle(getClass().getSimpleName());
primaryStage.show();
}
public static void main(String[] args) {
launch(args);
}
}
with dark.css being:
.root {
-fx-background: rgb(54, 54, 54);
}
Is this a Mac-specific problem? Is there a workaround? Which of the
two mailing lists is the more appropriate one to post these things
(JFX problems which look like they might be platform-specific) to?
Thanks,
Robert
Re: Integrating JFX Dialog/Stage in Swing application
Platform.setImplicitExit(false)
This is the correct answer. Please see the javadoc for more details.
--
best regards,
Anthony
On 5/31/2014 10:19 PM, Jeff Martin wrote:
You might try calling that new JFXPanel() in your application main. Maybe go
ahead and call Platform.setImplicitExit(false) as well.
jeff
On May 31, 2014, at 9:46 AM, Robert Krüger krue...@lesspain.de wrote:
That was quicker than I had hoped. Invoking close() on the stage
constructed in this way results in this here:
[ERROR|16:24:23] d.l.m.MediaTool Uncaught exception in thread JavaFX
Application Thread: [JavaFX Application Thread]
java.lang.IllegalStateException: This operation is permitted on the
event thread only; currentThread = JavaFX Application Thread
at com.sun.glass.ui.Application.checkEventThread(Application.java:427)
~[jfxrt.jar:na]
at com.sun.glass.ui.View.isClosed(View.java:409) ~[jfxrt.jar:na]
at
com.sun.glass.ui.mac.MacTouchInputSupport.notifyNextTouchEvent(MacTouchInputSupport.java:122)
~[jfxrt.jar:na]
at
com.sun.glass.ui.mac.MacGestureSupport.notifyNextTouchEvent(MacGestureSupport.java:77)
~[jfxrt.jar:na]
I checked in the debugger and com.sun.glass.ui.Application#eventThread
is null. This makes me believe the environment is not properly
initialized despite the invocation on new JFXPanel() that I have in
the EDT before the stage is built.
On Sat, May 31, 2014 at 4:15 PM, Robert Krüger krue...@lesspain.de wrote:
Hi Jeff,
thanks, yeah, that's a workaround I have also found. I am just asking
myself (and the JFX developers on this list) why this kind of
Integration is not supported directly.
Good to know that you have used this quite a bit. So I'll try using it
until someone brings up a nicer solution or I run into any problems
:-).
Cheers,
Robert
On Sat, May 31, 2014 at 3:57 PM, Jeff Martin j...@reportmill.com wrote:
I'm sure this isn't the proper answer, but I have used this call to initialize
the FX toolkit on demand from various Swing contexts and it has always worked
for me:
new javafx.embed.swing.JFXPanel();
Then you would need the Platform.runLater(). Usually for the whole method that
creates your UI and shows the Stage. In some cases, I would make the first line
of my method that ends up invoking the JFX dialog something like this:
public void doSomething()
{
// Ensure we're on FX thread
if(!Platform.isFXApplicationThread()) {
Platform.runLater(new Runnable() { public void run() {
doSomething(); } return; }
… create FX UI and do stage.show() ...
}
I've done quite a bit of this and it works without problems (for me).
jeff martin
On May 31, 2014, at 7:27 AM, Robert Krüger krue...@lesspain.de wrote:
Hi,
I am trying something which I thought would technically be the easiest
way of migrating parts of an existing application from Swing to JFX,
i.e. have a Swing JMenuItem trigger the showing of a JFX stage because
I thought this would technically even be cleaner than to have a swing
dialog containing an JFXPanel.
Doing this results in the following Exception:
java.lang.IllegalStateException: Toolkit not initialized
at com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:276)
~[jfxrt.jar:na]
at com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:271)
~[jfxrt.jar:na]
at javafx.application.Platform.runLater(Platform.java:78) ~[jfxrt.jar:na]
at
de.lesspain.mediatool.menu.ToolsSubmenu$1.actionPerformed(ToolsSubmenu.java:20)
~[
javadoc of runLater states:
This method must not be called before the FX runtime has been
initialized. For standard JavaFX applications that extend Application,
and use either the Java launcher or one of the launch methods in the
Application class to launch the application, the FX runtime is
initialized by the launcher before the Application class is loaded.
For Swing applications that use JFXPanel to display FX content, the FX
runtime is initialized when the first JFXPanel instance is
constructed.
So this is consistent. Still I am wondering, why it should not be
supported to just trigger opening a stage from a Swing menu? Either by
Platform.runLater autoinitializing or offering a separate method like
Platform.ensureInitialized().
Am I missing something obvious?
Thanks,
Robert
--
Robert Krüger
Managing Partner
Lesspain GmbH Co. KG
www.lesspain-software.com
--
Robert Krüger
Managing Partner
Lesspain GmbH Co. KG
www.lesspain-software.com
Resizing stage creates delays in platform.runLater pool?
Hi, I have encountered severe lag in my application when resizing the stage while an animation is running. I've made this very simple example code to reproduce the issue: https://github.com/Drakkoon/LWJGL-FX/blob/master/src/JavaFXResizeTest.java This is only a tread that acquires a semaphore, prints the System.nanotime() delta and releases the semaphore. There's a button on the stage that can clicked on to start a fade animation and stop it. Resizing the stage while it is animating will create huge deltas in the thread. Stopping the animation brings everything back to normal. Restarting the animation once resized and stopped does not create the huge deltas until you resize again. Does anyone know what is at play here, what underlying system creates the lag and how to avoid this? Thanks.
Re: Resizing stage creates delays in platform.runLater pool?
My guess would be that the number of resize events is swamping the event queue. On Jun 2, 2014, at 7:20 AM, Guillaume Anctil drakk...@gmail.com wrote: Hi, I have encountered severe lag in my application when resizing the stage while an animation is running. I've made this very simple example code to reproduce the issue: https://github.com/Drakkoon/LWJGL-FX/blob/master/src/JavaFXResizeTest.java This is only a tread that acquires a semaphore, prints the System.nanotime() delta and releases the semaphore. There's a button on the stage that can clicked on to start a fade animation and stop it. Resizing the stage while it is animating will create huge deltas in the thread. Stopping the animation brings everything back to normal. Restarting the animation once resized and stopped does not create the huge deltas until you resize again. Does anyone know what is at play here, what underlying system creates the lag and how to avoid this? Thanks.
Re: Resizing stage creates delays in platform.runLater pool?
It might be something like that. But it seems to be in the platform, not application related. When detecting a resize, I tried putting the thread to sleep for a long amount of time. Something like 5 seconds before adding a new Runnable in the Platform.runLater queue. It's still very slow when it starts again. (Only when there's an animation running). Could it be that the animation pulse + resize swamps he queue and it never gets back to full speed again? Does the pulse have a high priority? The fade animation on the button never seems to slow down. On Mon, Jun 2, 2014 at 10:23 AM, Richard Bair richard.b...@oracle.com wrote: My guess would be that the number of resize events is swamping the event queue. On Jun 2, 2014, at 7:20 AM, Guillaume Anctil drakk...@gmail.com wrote: Hi, I have encountered severe lag in my application when resizing the stage while an animation is running. I've made this very simple example code to reproduce the issue: https://github.com/Drakkoon/LWJGL-FX/blob/master/src/JavaFXResizeTest.java This is only a tread that acquires a semaphore, prints the System.nanotime() delta and releases the semaphore. There's a button on the stage that can clicked on to start a fade animation and stop it. Resizing the stage while it is animating will create huge deltas in the thread. Stopping the animation brings everything back to normal. Restarting the animation once resized and stopped does not create the huge deltas until you resize again. Does anyone know what is at play here, what underlying system creates the lag and how to avoid this? Thanks.
Re: Resizing stage creates delays in platform.runLater pool?
You may be hitting this bug: https://javafx-jira.kenai.com/browse/RT-36796 Please try running with -Dprism.order=sw and see if this changes anything. -- best regards, Anthony On 6/2/2014 6:20 PM, Guillaume Anctil wrote: Hi, I have encountered severe lag in my application when resizing the stage while an animation is running. I've made this very simple example code to reproduce the issue: https://github.com/Drakkoon/LWJGL-FX/blob/master/src/JavaFXResizeTest.java This is only a tread that acquires a semaphore, prints the System.nanotime() delta and releases the semaphore. There's a button on the stage that can clicked on to start a fade animation and stop it. Resizing the stage while it is animating will create huge deltas in the thread. Stopping the animation brings everything back to normal. Restarting the animation once resized and stopped does not create the huge deltas until you resize again. Does anyone know what is at play here, what underlying system creates the lag and how to avoid this? Thanks.
Re: Resizing stage creates delays in platform.runLater pool?
Yes. -Dprism.order=sw does fix the issue. Looking at that bug's sample code and how to reproduce, it looks very similar. Thank you. I'll run it in software mode for now and see how bad it affects performance. I can always apply a hacky workaround of stopping animations when I detect a resize and restarting them once the resize is done. So I guess this is on your radar, and it is being looked into? On Mon, Jun 2, 2014 at 10:43 AM, Anthony Petrov anthony.pet...@oracle.com wrote: You may be hitting this bug: https://javafx-jira.kenai.com/browse/RT-36796 Please try running with -Dprism.order=sw and see if this changes anything. -- best regards, Anthony On 6/2/2014 6:20 PM, Guillaume Anctil wrote: Hi, I have encountered severe lag in my application when resizing the stage while an animation is running. I've made this very simple example code to reproduce the issue: https://github.com/Drakkoon/LWJGL-FX/blob/master/src/ JavaFXResizeTest.java This is only a tread that acquires a semaphore, prints the System.nanotime() delta and releases the semaphore. There's a button on the stage that can clicked on to start a fade animation and stop it. Resizing the stage while it is animating will create huge deltas in the thread. Stopping the animation brings everything back to normal. Restarting the animation once resized and stopped does not create the huge deltas until you resize again. Does anyone know what is at play here, what underlying system creates the lag and how to avoid this? Thanks.
Re: Resizing stage creates delays in platform.runLater pool?
I suggest you add yourself to the bug. At this time, we are not sure what is causing it. It could be graphics or event queue related as there is evidence that changing either solves the problem. Steve On 2014-06-02, 10:51 AM, Guillaume Anctil wrote: Yes. -Dprism.order=sw does fix the issue. Looking at that bug's sample code and how to reproduce, it looks very similar. Thank you. I'll run it in software mode for now and see how bad it affects performance. I can always apply a hacky workaround of stopping animations when I detect a resize and restarting them once the resize is done. So I guess this is on your radar, and it is being looked into? On Mon, Jun 2, 2014 at 10:43 AM, Anthony Petrov anthony.pet...@oracle.com wrote: You may be hitting this bug: https://javafx-jira.kenai.com/browse/RT-36796 Please try running with -Dprism.order=sw and see if this changes anything. -- best regards, Anthony On 6/2/2014 6:20 PM, Guillaume Anctil wrote: Hi, I have encountered severe lag in my application when resizing the stage while an animation is running. I've made this very simple example code to reproduce the issue: https://github.com/Drakkoon/LWJGL-FX/blob/master/src/ JavaFXResizeTest.java This is only a tread that acquires a semaphore, prints the System.nanotime() delta and releases the semaphore. There's a button on the stage that can clicked on to start a fade animation and stop it. Resizing the stage while it is animating will create huge deltas in the thread. Stopping the animation brings everything back to normal. Restarting the animation once resized and stopped does not create the huge deltas until you resize again. Does anyone know what is at play here, what underlying system creates the lag and how to avoid this? Thanks.
Re: Resizing stage creates delays in platform.runLater pool?
We also experienced laggy animation with a stage slide out/down animation. The animation would change stage size and it appeared to have only 2 or 3 frames. Workaround was to use a different animation style: keep stage size but move it 20 px down while changing opacity from low to full, both animated. Maybe this is an option for you, too. Werner On 02.06.2014 16:20, Guillaume Anctil wrote: Does anyone know what is at play here, what underlying system creates the lag and how to avoid this?
Re: Resizing stage creates delays in platform.runLater pool?
Does running with the software pipeline fix the problem as suggested in https://javafx-jira.kenai.com/browse/RT-36796 ? Steve On 2014-06-02, 11:10 AM, Werner Lehmann wrote: We also experienced laggy animation with a stage slide out/down animation. The animation would change stage size and it appeared to have only 2 or 3 frames. Workaround was to use a different animation style: keep stage size but move it 20 px down while changing opacity from low to full, both animated. Maybe this is an option for you, too. Werner On 02.06.2014 16:20, Guillaume Anctil wrote: Does anyone know what is at play here, what underlying system creates the lag and how to avoid this?
Re: Ugly flashing when opening a css-styled stage
Hi Anthony On Mon, Jun 2, 2014 at 3:01 PM, Anthony Petrov anthony.pet...@oracle.com wrote: Hi Robert, Which of the two mailing lists is the more appropriate one to post these things (JFX problems which look like they might be platform-specific) to? FYI: the JDK Mac OS X Port Project has been completed long time ago, so currently the macosx-port-dev@ mailing list isn't appropriate for almost anything. Oh, that's a surprise. I thought it was more or less the successor of apple-java-dev, i.e. where one discusses issues/problems/questions specific to the Mac port of the JDK/JRE and Java development on the Mac in general. Please report JavaFX bugs at: https://javafx-jira.kenai.com/ Submitted as RT-37372 AWT/Swing/JDK bugs can be reported at: http://bugreport.java.com/bugreport/ (or http://bugs.sun.com/ ) If you wish to participate in the development of the technologies (e.g. you want to contribute a patch for JavaFX or JDK platform), then you're welcome to post your suggestions on the appropriate development mailing lists (openjfx-dev@, awt-dev@, swing-dev@, etc.) I've been subscribed to the two lists for a while now and my impression is, it is also a place where people running into problems with the platform's limitations exchange their experience which has been very valuable especially when dealing with a rather new platform but I guess I need to move to the OTN community for this. Thanks and best regards, Robert
Re: Resizing stage creates delays in platform.runLater pool?
Probably not (that code is gone so I don't know for sure). For some other (Mac-related) reason, the software pipeline was already used for our internal testing. Didn't seem to make a difference. FWIW, there was also an NPE occurring if someone was crazy enough to show that popup many times by clicking on the button which triggers it - while the previous animation did not yet finish. I think two animations were competing over the same animated properties if that is even possible. Anyway, not an issue anymore. Werner On 02.06.2014 17:16, Stephen F Northover wrote: Does running with the software pipeline fix the problem as suggested in https://javafx-jira.kenai.com/browse/RT-36796 ? Steve
[8u20] Review request RT-37304: [Mac] handleOnMenuValidation may not be called when using system menu bar
Hi Steve, Petr, Please review the fix: https://javafx-jira.kenai.com/browse/RT-37304 -- best regards, Anthony
Done with weekly JavaFX 8u20 testing
We are done with JavaFX 8u20 (in)sanity testing for this week. The repo is open for commits again. -- Kevin
Re: Extending a Region to create a JUNG Layout
Except the license.txt page points to the OSI page that is... BSD 2 Clause. Here's the zoom pane as BSD 2 clause... https://github.com/shemnon/FollowTheBitcoin/commit/effd601965875fec8891f8202afea1f84f1daf54 If you really want me to add the non-endorsement clause I can, but it is kind of awkwardly worded for individual contributors. On Sun, Jun 1, 2014 at 10:49 PM, Jeffrey Guenther guenther.jeff...@gmail.com wrote: BSD - 3 Clause - http://jung.sourceforge.net/license.txt On Sat, May 31, 2014 at 6:17 PM, Danno Ferrin danno.fer...@shemnon.com wrote: The new matrix classes exposed in JavaFX 8 help a lot. I'll re-license it BSD. 2 clause, 3 clause, new? Can you point me to a preferred header? On Fri, May 30, 2014 at 6:11 PM, Jeffrey Guenther guenther.jeff...@gmail.com wrote: Danno, thanks! It works super well and has so little code! If I use the class in my JUNG work, I need a BSD license. The rest of that codebase is BSD already. I’ll contact you off list if I go that direction. Right now, I’m trying to get my head wrapped around what it would take to modernize JUNG. On May 30, 2014, at 4:20 PM, Danno Ferrin danno.fer...@oracle.com wrote: You may find this class valuable, it is a pane that listens to zoom and mouse scroll events in a group, essential for large graphs: https://github.com/shemnon/FollowTheBitcoin/blob/master/src/main/groovy/com/shemnon/btc/view/ZoomPane.java I haven't had time to harden it and componentize it into a standalone release. If you don't like the license let me know what license you would like. --Danno - Original Message - From: sven.reim...@gmail.com To: guenther.jeff...@gmail.com Cc: openjfx-dev@openjdk.java.net Sent: Friday, May 30, 2014 1:27:48 AM GMT -07:00 US/Canada Mountain Subject: Re: Extending a Region to create a JUNG Layout Hi Jeffrey, I did some prototyping with Jung JavaFX and Java 8, the results are here https://bitbucket.org/sreimers/jung8 It uses gradle to build and contains an additional library for jungfx. Enjoy -Sven On Fri, May 30, 2014 at 8:44 AM, Jeffrey Guenther guenther.jeff...@gmail.com wrote: Hi, I'm in the midst of exploring how I might port JUNG( http://jung.sourceforge.net/index.html) to JavaFX. JUNG is a graph/layout tool my lab uses for some of their data visualizations. With the release of JavaFX 2, we've started building our prototypes in JavaFX. Rather than use the JFXSwingPanel, I want to try modifying the JUNG to work natively in JavaFX. In the long term, I'd like to see JUNG ported completely to JavaFX using properties, CSS and the like. I've built a quick demo ( https://gist.github.com/jrguenther/9d0c37329f9928a2b56e) and need help going forward. I've been reading the docs and hitting google, but I think I need more info. Can someone point me to a detailed explanation of how to extend Region to create my own layout? In particular, how can I get a region to relayout it's children when it's being resized? When does a the region's parent call layoutChildren()? If the height and width of the region are set to Double.MAX_VALUE indicating the area can grow infinitely, how does the region know what size to set itself to? Thanks, Jeff -- 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
hg: openjfx/8u-dev/rt: RT-36844 [Monocle] Implement modality support for monocle
Changeset: f3841fb9697d Author:lisa.se...@oracle.com Date: 2014-06-02 16:39 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f3841fb9697d RT-36844 [Monocle] Implement modality support for monocle Reviewed by dblaukopf Tested with HelloSanity ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleWindow.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/MonocleWindowManager.java ! modules/graphics/src/main/java/com/sun/glass/ui/monocle/input/MouseInput.java
hg: openjfx/8u-dev/rt: [BUILD] adding include file to fix errors in monocle
Changeset: b245bc977cc5 Author:ddhill Date: 2014-06-02 17:04 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b245bc977cc5 [BUILD] adding include file to fix errors in monocle Reviewed-by: kselle ! buildSrc/crosslibs/crosslibs-armv6hf.sh ! modules/graphics/src/main/native-glass/monocle/dispman/DispmanScreen.c
hg: openjfx/8u-dev/rt: [ACCESSIBILITY ONLY] Remove unnecessary ROLE code
Changeset: edb590702b98 Author:snorthov Date: 2014-06-02 17:25 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/edb590702b98 [ACCESSIBILITY ONLY] Remove unnecessary ROLE code ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/PaginationSkin.java
