Re: Android Port: Next Steps
Hi Steve,
if you're using new Android studio then resolving dex max method limit
issue won't be so easy. Android studio is based on gradle build system
with android gradle plugin which doesn't allow modifying of dex task to
generate more .dex files. You have to stick with good old ant for now.
-Tomas
On 01/03/2014 06:41 PM, Johan Vos wrote:
Thanks Steve, that makes sense.
I'll be back in the Android/JavaFX world in a few days, and will work on
this.
About the dex-max-method-references: that is a known issue that is fixed if
you use the gradle script in android-tools. Explanation and how-to-fix at
https://bitbucket.org/javafxports/android/issue/5/compiling-ensemble8-fails-because-of-dex
- Johan
2014/1/2 Stephen F Northover steve.x.northo...@oracle.com
Hi Johan,
I looked and the kinds of changes that you are making in
https://bitbucket.org/javafxports/android-graphics-rt and I can see that
they fall into a number of different categories:
1) JDK8 Language Features
- work arounds for ObservableList default methods
- work arounds for the use of lambda (in test and example code)
- work arounds for the lack of final declarations (in test and example
code)
I have entered https://javafx-jira.kenai.com/browse/RT-35165 to track the
defender method problem.
Eventually, OpenJFX will embrace lambda expressions and it is likely that
iOS and Android will need to use RetroLambda. When we embrace lambda,
there will be a JIRA that covers the work and you an watch progress there.
In the meantime, you could look into RetroLambda now and see if it will
help you. Since it works on byte codes, you won't be able to step in the
debugger because the source won't match the executable. This might not be
an issue for you. ASIDE: I've attempted to build the code under Android
Studio and it runs out of method handles in dex during compile. Any ideas?
In the case of final declarations, I think that there are so few of them
right now that we can just fix them as then sneak in. You will need to
keep track of them as they happen. Eventually, if you earn commit rights,
you can just fix them.
2) JDK8 Library (modules/compat/src)
- missing classes and annotations (such as FunctionalInterface)
- missing API in JDK7 classes (I thought I had gotten rid of these)
This code is not part of OpenJFX and should not be in the repo. Instead,
you need to maintain and build the code somewhere else and make a jar
available as part of your build. For example, when OpenJFX is built, it
gets the SWT jar from Eclipse.org. You will need to do something similar
when OpenJFX for Android or iOS is built.
3) Android Build Files and Tools (android-tools and more)
- files like dalvik.gradle and shell scripts etc.
Some of this is being tracked by
https://javafx-jira.kenai.com/browse/RT-35123 . I suggest that you enter
JIRA for each part that you want moved over. For example, android-tools is
not covered by this JIRA.
4) Android Specific Files (New and Changed files)
- src/dalvik
- android.h, LensApplication.c etc.
You will need to enter JIRA for these. I'm not sure which changes are
needed and which are not. FX embedded committers will need to go over the
changes as Android and Lens share the same code.
5) Unnecessary Changes
- these are mostly due to being out of sync with OpenJFX
- some of these are related to FunctionalInterface which you should add to
your JDK8 compat library
As more of your code moves over to OpenJFX, the list of changes here will
become zero. I suggest that you browse all the changes that you have and
get rid of as many as you can while preparing patches for OpenJFX.
Best of luck Johan! Our goal is to bootstrap you port as quickly as we
can subject to the rules of the OpenJDK which we must follow. Please enter
JIRA as necessary to track your work and we can interact there.
Happy New Year!
Steve
On 2013-12-31 3:47 AM, Johan Vos wrote:
Steve,
The main issue is currently getting bootstrapped. If we want to build the
Dalvik-runtime using open-jfx, we need a location on where to put the
dalvik files. This is what I tried to describe in
https://javafx-jira.kenai.com/browse/RT-35123
Please note that we're not really doing an Android port, but a Dalvik
port. The (excellent) work done by Oracle in the past allowed for both
using Dalvik as well as an Oracle-internal VM. There are no indications
that the latter is ever going to fly, so I don't want to have an
abstraction on top of {Dalvik, OracleVM} if only the first one exists. I do
hope there will be other VM's (Oracle VM and more) later, as that will make
it easier to have Java 8 and so on, but right now we have to stick with
what we have (dalvik).
Without these files, we can supply patches for existing files in
open-jfx, but by no means we can build the runtime. I do understand it is
not trivial to add a directory for the sake of a port, but then, a port
is not trivial as well. I'm open to all suggestions.
The longer we wait, however,
hg: openjfx/8u-dev/rt: TOYS ONLY: Add quit button to HelloSanity
Changeset: 29e103b816cb Author:snorthov Date: 2014-01-06 11:26 -0500 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/29e103b816cb TOYS ONLY: Add quit button to HelloSanity ! apps/toys/Hello/src/main/java/hello/HelloSanity.java
Re: properties of custom controls in SceneBuilder
Thanks! On Jan 6, 2014, at 8:33 AM, Eric Le Ponner eric.le.pon...@oracle.com wrote: I would say it's deeply embedded. SB2 currently defines a fixed list of property classes that can be edited in the Inspector panel. Extending this list with a new type means: - adding some specific metadata that help Scene Builder to edit/create FXML text - adding some specific UI logic that enables the Inspector panel to present and let the user edit the value Doing this requires a pretty deep understanding of SB2 architecture. Eric Le 6 janv. 2014 à 17:20, Richard Bair richard.b...@oracle.com a écrit : If somebody else wanted to contribute, where should they go looking for those limitations and how to remove them? Or is it very deeply embedded in the code? On Jan 3, 2014, at 2:15 AM, Eric Le Ponner eric.le.pon...@oracle.com wrote: Yes, SB currently makes a filtering : for custom components, it displays: - properties that are inherited from JavaFX core classes - properties with basic java types (integer, double, string, boolean). We'll try to remove some of those limitations over the time. Eric Le 3 janv. 2014 à 11:01, Tom Eugelink t...@tbee.org a écrit : Adding the controls in JFXtras to SceneBuilder worked without a problem, but scene builder does not show all their properties. For example CalendarTextField has 5 properties like Locale, Calendar, DateFormat, but only promptText is shown by SceneBuilder.
Re: properties of custom controls in SceneBuilder
If somebody else wanted to contribute, where should they go looking for those limitations and how to remove them? Or is it very deeply embedded in the code? On Jan 3, 2014, at 2:15 AM, Eric Le Ponner eric.le.pon...@oracle.com wrote: Yes, SB currently makes a filtering : for custom components, it displays: - properties that are inherited from JavaFX core classes - properties with basic java types (integer, double, string, boolean). We'll try to remove some of those limitations over the time. Eric Le 3 janv. 2014 à 11:01, Tom Eugelink t...@tbee.org a écrit : Adding the controls in JFXtras to SceneBuilder worked without a problem, but scene builder does not show all their properties. For example CalendarTextField has 5 properties like Locale, Calendar, DateFormat, but only promptText is shown by SceneBuilder.
Re: scenebuilder and migpane
MigLayout is a very popular layout engine in Swing and SWT (and also gaining ground on Android), I think it would be good for SceneBuilder to better support MigLayout. +1, I’d love to see enough support in SceneBuilder that any 3rd party layout container could supply editor support, so that the SceneBuilder team doesn’t have to hard code support for different layout containers. This was one of the goals of the “Design Time API for Java Beans” JSR (273, or 277? I don’t remember) to do the same for Swing. We haven’t got that far with Scene Builder but I think the idea is great. MigLayout is widely used enough that we could just add hard-coded support for it (maybe you or another person could contribute that?). Ideally it would be something any 3rd party layout vendor could provide — but in practice there are not that many widely used 3rd party layouts — even in the Swing world. Richard
Re: JavaFX on headless Jenkins
On 1/4/14, Jan 4, 3:57 PM, Tom Eugelink wrote: I'm trying to run JavaFX UI tests using TestFX on a headless Jenkins server (Ubuntu / Debian). I've gotten to the point where the UI is actually started by Jenkins, but then the test fail with a no suitable pipeline found. Any suggestions how to fix that? This has long been a challenge with FX. I even modified Glass/Lens to get a headless with a VNC option working on Linux Mac (Windows probably needed a little porting). This has never been a priority though, only a casual hobby. Daniel is working on a refresh of Glass/Lens that may make it even easier to do headless (as a side effect). If there is any interest, I can provide more information on the current Glass/Lens headless. Dave :*test* Executing task ':test' (up-to-date check took 0.054 secs) due to: No history is available. Starting process 'Gradle Worker 1'. Working directory: /var/lib/jenkins/workspace/JFXtras8.0 Command: /usr/lib/jvm/jdk1.8.0-ea/bin/java -Djava.security.manager=jarjar.org.gradle.process.internal.child.BootstrapSecurityManager -Dfile.encoding=UTF-8 -ea -cp /var/lib/jenkins/.gradle/caches/1.9/workerMain/gradle-worker.jar jarjar.org.gradle.process.internal.launcher.GradleWorkerMain Successfully started process 'Gradle Worker 1' Gradle Worker 1 executing tests. jfxtras.labs.scene.control.test.ListSpinnerEditableTest enterSelectValueByTyping STANDARD_ERROR Graphics Device initialization failed for : es2, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:300) at com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:244) at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:179) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:210) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:653) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678) at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:56) at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:158) at java.lang.Thread.run(Thread.java:744) Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:98) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:128) ... 1 more Exception in thread Thread-4 java.lang.RuntimeException: No toolkit found at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:191) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:210) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:653) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678) at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:56) at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:158) at java.lang.Thread.run(Thread.java:744) -- David Hill david.h...@oracle.com Java Embedded Development On a clear disk, you can seek forever.
Re: properties of custom controls in SceneBuilder
I would say it's deeply embedded. SB2 currently defines a fixed list of property classes that can be edited in the Inspector panel. Extending this list with a new type means: - adding some specific metadata that help Scene Builder to edit/create FXML text - adding some specific UI logic that enables the Inspector panel to present and let the user edit the value Doing this requires a pretty deep understanding of SB2 architecture. Eric Le 6 janv. 2014 à 17:20, Richard Bair richard.b...@oracle.com a écrit : If somebody else wanted to contribute, where should they go looking for those limitations and how to remove them? Or is it very deeply embedded in the code? On Jan 3, 2014, at 2:15 AM, Eric Le Ponner eric.le.pon...@oracle.com wrote: Yes, SB currently makes a filtering : for custom components, it displays: - properties that are inherited from JavaFX core classes - properties with basic java types (integer, double, string, boolean). We'll try to remove some of those limitations over the time. Eric Le 3 janv. 2014 à 11:01, Tom Eugelink t...@tbee.org a écrit : Adding the controls in JFXtras to SceneBuilder worked without a problem, but scene builder does not show all their properties. For example CalendarTextField has 5 properties like Locale, Calendar, DateFormat, but only promptText is shown by SceneBuilder.
Re: JavaFX on headless Jenkins
Hi Tom! On Jan 4, 2014, at 12:57 PM, Tom Eugelink t...@tbee.org wrote: I'm trying to run JavaFX UI tests using TestFX on a headless Jenkins server (Ubuntu / Debian). I've gotten to the point where the UI is actually started by Jenkins, but then the test fail with a no suitable pipeline found. Any suggestions how to fix that? This was one of my long-standing TODO items: have a “headless” glass that would allow us to run quantum / prism tests headless. However for running scene graph or UI control tests, you should be using the “StubToolkit” instead of QuantumToolkit. The StubToolkit is located in Graphics/src/test, so for using it for 3rd party tests (like JFXtras) you would need to jar up the classes produced during a test run of FX. Then just specify the stub toolkit via -Djavafx.toolkit=com.sun.javafx.pgstub.StubToolkit Now, longer term I wanted to nuke the StubToolkit. If we had a headless Glass then we could test with Prism/Quantum directly instead of the stubs. But this isn’t straightforward so it hasn’t been attempted yet. Hope that helps. Richard :*test* Executing task ':test' (up-to-date check took 0.054 secs) due to: No history is available. Starting process 'Gradle Worker 1'. Working directory: /var/lib/jenkins/workspace/JFXtras8.0 Command: /usr/lib/jvm/jdk1.8.0-ea/bin/java -Djava.security.manager=jarjar.org.gradle.process.internal.child.BootstrapSecurityManager -Dfile.encoding=UTF-8 -ea -cp /var/lib/jenkins/.gradle/caches/1.9/workerMain/gradle-worker.jar jarjar.org.gradle.process.internal.launcher.GradleWorkerMain Successfully started process 'Gradle Worker 1' Gradle Worker 1 executing tests. jfxtras.labs.scene.control.test.ListSpinnerEditableTest enterSelectValueByTyping STANDARD_ERROR Graphics Device initialization failed for : es2, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:300) at com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:244) at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:179) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:210) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:653) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678) at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:56) at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:158) at java.lang.Thread.run(Thread.java:744) Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:98) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:128) ... 1 more Exception in thread Thread-4 java.lang.RuntimeException: No toolkit found at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:191) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:210) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:653) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678) at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:56) at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:158) at java.lang.Thread.run(Thread.java:744)
Re: JavaFX on headless Jenkins
Yes please, I've got Jenkins setup so it starts a vncserver and it runs on linux, so I'm interesting in the option you mention (as long as it doesn't require too many hoops I need to jump through). Tom On 2014-1-6 17:36, David Hill wrote: On 1/4/14, Jan 4, 3:57 PM, Tom Eugelink wrote: I'm trying to run JavaFX UI tests using TestFX on a headless Jenkins server (Ubuntu / Debian). I've gotten to the point where the UI is actually started by Jenkins, but then the test fail with a no suitable pipeline found. Any suggestions how to fix that? This has long been a challenge with FX. I even modified Glass/Lens to get a headless with a VNC option working on Linux Mac (Windows probably needed a little porting). This has never been a priority though, only a casual hobby. Daniel is working on a refresh of Glass/Lens that may make it even easier to do headless (as a side effect). If there is any interest, I can provide more information on the current Glass/Lens headless. Dave :*test* Executing task ':test' (up-to-date check took 0.054 secs) due to: No history is available. Starting process 'Gradle Worker 1'. Working directory: /var/lib/jenkins/workspace/JFXtras8.0 Command: /usr/lib/jvm/jdk1.8.0-ea/bin/java -Djava.security.manager=jarjar.org.gradle.process.internal.child.BootstrapSecurityManager -Dfile.encoding=UTF-8 -ea -cp /var/lib/jenkins/.gradle/caches/1.9/workerMain/gradle-worker.jar jarjar.org.gradle.process.internal.launcher.GradleWorkerMain Successfully started process 'Gradle Worker 1' Gradle Worker 1 executing tests. jfxtras.labs.scene.control.test.ListSpinnerEditableTest enterSelectValueByTyping STANDARD_ERROR Graphics Device initialization failed for : es2, sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:300) at com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:244) at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:179) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:210) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:653) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678) at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:56) at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:158) at java.lang.Thread.run(Thread.java:744) Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:98) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:128) ... 1 more Exception in thread Thread-4 java.lang.RuntimeException: No toolkit found at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:191) at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:210) at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:653) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678) at com.sun.javafx.application.LauncherImpl.access$000(LauncherImpl.java:56) at com.sun.javafx.application.LauncherImpl$1.run(LauncherImpl.java:158) at java.lang.Thread.run(Thread.java:744)
Re: scenebuilder and migpane
Le 6 janv. 2014 à 17:19, Richard Bair richard.b...@oracle.com a écrit : MigLayout is a very popular layout engine in Swing and SWT (and also gaining ground on Android), I think it would be good for SceneBuilder to better support MigLayout. +1, I’d love to see enough support in SceneBuilder that any 3rd party layout container could supply editor support, so that the SceneBuilder team doesn’t have to hard code support for different layout containers. This was one of the goals of the “Design Time API for Java Beans” JSR (273, or 277? I don’t remember) to do the same for Swing. We haven’t got that far with Scene Builder but I think the idea is great. The idea is great I agree. However defining an API that opens the user interactive gestures of a tool like SB is not a trivial task. And FXML brings some additional complexity. IMHO the Design Time API from JSR 273 would require several amendments to be implementable in the context of SB. May be for SB 4.0 ?… ;) MigLayout is widely used enough that we could just add hard-coded support for it (maybe you or another person could contribute that?). Ideally it would be something any 3rd party layout vendor could provide — but in practice there are not that many widely used 3rd party layouts — even in the Swing world. In the middle term, I think hard-coded support is probably the best option, I think. Richard Eric
How I do connect two panes?
I want to connect two panes. panes are dragable so: I need dinamic line... Which API should I look at? ı am waiting for answers...thanx
How to draw line to connect Two components at run time?
Hi; I met a problem and need urgent help from you here, I am new in javafx ... draw lines between any two components(are panes) at RUN-TIME, not at design time pls advice how to do it?
[8u] Code Review Request - RT-34951: Provide a way to exit when the screen is first rendered
Hi Kevin, Please review this extension to PulseLogger to exit after processing a given number of pulses. This is for benchmarking VM startup time using FX samples. https://javafx-jira.kenai.com/browse/RT-34951 http://cr.openjdk.java.net/~dblaukop/webrev-20140106-2341-RT-34951/webrev/ Thanks, Daniel
Re: How to draw line to connect Two components at run time?
Investigate SplitPane? Not sure what the question is. Steve On 2014-01-06 4:45 PM, Amine Tengilimoglu wrote: Hi; I met a problem and need urgent help from you here, I am new in javafx ... draw lines between any two components(are panes) at RUN-TIME, not at design time pls advice how to do it?
hg: openjfx/8u-dev/rt: RT-35196 Fix IntelliJ configuration files for version 13
Changeset: 881be4494731 Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2014-01-07 00:12 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/881be4494731 RT-35196 Fix IntelliJ configuration files for version 13 Reviewed-by: snorthov ! .idea/gradle.xml ! .idea/vcs.xml
Re: JavaFX on headless Jenkins
On the linux nodes on travis.org xvfb is used to mimic a GUI environment on headless nodes. Have a look at : http://about.travis-ci.org/docs/user/gui-and-headless-browsers/ you might be probably able to do something like that on your linux box. Matthieu
SceneBuilder build instructions
Hi! Is there a manual how to build SceneBuilder? I'm trying to run gradle apps task, but scenebuilder doesn't builds. I'm using linux, gradle 1.8 and latest jdk1.8 build (b121). After dirty hack, by adding next lines to the sampleAppsJar task into /apps/build.xml file: ant dir=scenebuilder/SceneBuilderKit target=jar inheritAll=true/ ant dir=scenebuilder/SceneBuilderApp target=jar inheritAll=true/ i got SceneBuilderApp.jar in apps/scenebuilder/SceneBuilderApp/dist directory. After that I was able to run SceneBuilder with the following command: java -cp ./SceneBuilderApp.jar:../../SceneBuilderKit/dist/SceneBuilderKit.jar com.oracle.javafx.scenebuilder.app.SceneBuilderApp Is there a simpler way to build and run SceneBuilder? Thanks, -Roman
Re: JavaFX on headless Jenkins
Ok. I saw xfvb passing by, but most blogs talked about xvnc, I'll give that a spin. Thanks. Tom BTW: the Travis environment keeps reporting errors; it has trouble downloading one of the supporting jar from maven. On 2014-1-6 23:49, Matthieu BROUILLARD wrote: On the linux nodes on travis.org http://travis.org xvfb is used to mimic a GUI environment on headless nodes. Have a look at : http://about.travis-ci.org/docs/user/gui-and-headless-browsers/ you might be probably able to do something like that on your linux box. Matthieu
Re: scenebuilder and migpane
On 2014-1-6 17:19, Richard Bair wrote: MigLayout is a very popular layout engine in Swing and SWT (and also gaining ground on Android), I think it would be good for SceneBuilder to better support MigLayout. +1, I’d love to see enough support in SceneBuilder that any 3rd party layout container could supply editor support, so that the SceneBuilder team doesn’t have to hard code support for different layout containers. This was one of the goals of the “Design Time API for Java Beans” JSR (273, or 277? I don’t remember) to do the same for Swing. We haven’t got that far with Scene Builder but I think the idea is great. MigLayout is widely used enough that we could just add hard-coded support for it (maybe you or another person could contribute that?). Ideally it would be something any 3rd party layout vendor could provide — but in practice there are not that many widely used 3rd party layouts — even in the Swing world. Sure, if I can get some help getting started. (Aka if somebody tells me which class needs implementing and -reading that one post- how to build SceneBuilder, I'll bring the MigPane knowledge to the party.) Tom
