This has been on my list for some time now and because I was traveling a bit in the last 2 weeks I had some time to hack on such a converter. I’ve not used XSL but instead used xtend (svg-parser (java),fxml-converter (xtend)) (because an XML-File comes with a lot of multiline strings). It took some time to wrap my head around SVG and how I could translate this in FXML/JavaFX 2.0 API calls but I finally I’m at a point where I have something to show off:

Please note that the JavaFX 2.0 image on the left is only made up of primitive JavaFX 2.0 elements (Circles, SVGPaths, Rect, Gradients, …) and it by far does not yet handle all the nifty stuff one can do with SVG but it shows me that such a conversion tool is doable to some extend though e.g. when it comes to filtering, … SVG has much more definitions than the JavaFX-API currently provides.

I was not even able to convert the SVG-Gaussian-Blur to JavaFX’ Gaussian-Blur (but that might just me I’m not an expert in graphics stuff), SVG allows to apply multiple filters/effects to a node, … . So to provide full SVG-Support – without residing to libraries like Batik – in JavaFX 2.x we’d need more API (or at least a tutorial how to e.g. write custom effects) but even with the current API one can get quite far as you don’t notice any missing thing in the above screenshot.

I’ve pushed the orignal svg-File (from the KDE oxygen-theme) and the resulting fxml-File to my git repo so that you can compare them.

So I decided to make another release 0.0.11 which fixes the regression and the packaging. Sorry if this caused trouble to you but this simply slipped through my checks. For those who already downloaded the broken 0.0.10 release I’m sorry but you should redownload version 0.0.11 (it also includes one new feature).

Tooling

FXGraph

Preview Keyword

The keyword has been already part of the language but now its semantics are fully implemented. You can now prefix an attribute in your FXGraph-File with preview and so the content is only passed to the preview but not into the serialized file. I added this feature because sometimes it is necessary to fill controls with data to see how their layout changes. A good example in this sense is the ChoiceBox who layouts itself according to its content.

3 weeks after 0.0.9 (and one day behind schedule because of New Years day) I just pushed 0.0.10 to http://efxclipse.org/. There are many improvements which will take a look later on and take a look at the provided all in one downloads who’ve been received quite well by the community. In the last 3 weeks I registered the following downloads:

1. eclipse-SDK-3.7.1-efxclipse-0.0.9-win32.zip: 101
2. eclipse-SDK-4.2M4-efxclipse-0.0.9-win32.zip: 55
3. eclipse-SDK-4.2M4-efxclipse-0.0.9-win32-x86_64: 49
4. eclipse-SDK-3.7.1-efxclipse-0.0.9-win32-x86_64: 41
5. eclipse-SDK-3.7.1-efxclipse-0.0.9-macosx-cocoa-x86_64: 13

So they are eating up quite some bandwidth (~100GB in December). Let’s now dive into the new features one by one.

All in one downloads

The aim of the all in one downloads has been to give developers an easy way to start writing JavaFX applications. Now that JavaFX is provided as opensource in the openfx-project to give Eclipse users an easy way to contribute I added the mercurial-plugin 1.9.1 to the all in one downloads so that you can access the openjfx-repository without the need to install anything new. I also upgraded to Xtext 2.2.1 and EGit 1.2.0 so that you have the newest bugfixes in your IDE.

Tooling

Internal changes

There are 2 internal changes that happened which you might not directly notice.

SWT-Interop for the LivePreview

One of the internal things I’ve changed was that since 2.0.2 there’s is direct JavaFX-SWT interop available I switched from my hacky JavaFX – Swing – SWT_Swing_Bridge – SWT to it which has 2 consequences:

• JavaFX 2.0.2 is hard requirement for e(fx)clipse 0.0.10
• Mac-Support is working and fully supported
  

JavaFX library look up for the live preview

Until 0.0.9 the look of the JavaFX library for the Live-Preview was done on win32 by consulting the Windows registry and on Mac OS-X by looking for an ENV-Variable (JAVAFX_HOME).

The approach had a draw back because it could have happened that the SDK you had configured in your IDE and the JavaFX version used for the live preview could have gone out of sync. This has now changed and when running inside the IDE the configured SDK version is used instead. This makes it much easier for OS-X users because they now don’t have to reconfigure their ENV to use the live preview.

FXGraph

FXGraph is my custom DSL used to author FXML-Files. I promised that I’ll provide a FXML to FXGraph roundtrip converted but I’ll have to defer this for 0.0.11 or even later.

Support for factory methods

I’ve added support for factory-methods and to really support them I had to change the language a bit which is not a problem because noone could have used this feature because though the language had the keyword for it it was not implemented appropiately.

The syntax looks like this:

New Outline

The outline view in 0.0.9 was the default one provided by Xtext. I’ve invested some time in 0.0.10 to customize it and show informations in a similar fashion the JDT-Outline view does.

Here are screenshots of the results:

Content Assist improvements

The content assist has been improved tremendously by limiting the results to values assignable to the left.

Formatting

The formatting like idents, spaces, line breaks, … have been customized so that you can now press CTRL+SHIFT+F like you are used to in Java-Files and the your source gets formatted nicely.

JavaDoc everywhere

The JavaDoc is now shown everywhere like you are used to it in Java-Files as well. For example when showing the content assist for properties the JavaDoc is displayed next to the proposal.

Autocompleteion for Enum values

Attributes who are represented as enum-Values now provide a content proposal.

Wizard improvements

The wizard has been improved to add support for custom root elements (and remembers them for the next time).

FXML

So in 0.0.9 I switched the FXML-Editor from a custom written to an Xtext backed one (the only feature I had by then was to provide attribute proposals).

So while I also added new features to FXGraph most of the time I spend in this release cycle was on the FXML-Editor front which now has decent sub-element proposals, JavaDoc support, … . The features are yet not as advanced as they are in fxgraph but they are coming along nicely.

Subelement proposals

JavaDoc

Not all elements yet show the JavaDoc appropriate for them but the most important ones already do.

Live Preview

I think that this is the most interesting feature of the FXML-Tooling because it allows you see the resulting UI while you are authoring the FXML-File.

FXML currently does not support to encode custom informations into it because it does not allow one to use itsown XML-Namespace. To make the live preview load the CSS-Files and message.properties one has to add a mapping file in the root directory of the project. The FXML-Wizard will create one for you, if you already have fxml-Files and want to add the configuration-file your own simply create a file named “fxml-preview.properties” in your project (at the toplevel, not inside the src-Folder) and add the following content:

# -------------------------------------
# Configuration setting for FXML-Files
# -------------------------------------

# -------------------------------------
# Values applicable to all FXML-Files
# -------------------------------------

# fxmlpreview.all.stylesheets=test.css            # Comma seperated list of css-styles
# fxmlpreview.all.messagefile=messages.properties # Properties file

# -------------------------------------
# Values applicable to a specific FXML-File 
# (replace ${fxmlfilename} with your filename WITHOUT the fxml-suffix)
# -------------------------------------

# fxmlpreview.file.${fxmlfilename}.stylesheets=test.css              # Comma seperated list of css-styles merged with default styles
# fxmlpreview.file.${fxmlfilename}.messagefile=messages.properties   # Properties file overrules default properties

I think the file is self-explanatory.

Here’s an excerpt:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 100,000 times in 2011. If it were an exhibit at the Louvre Museum, it would take about 4 days for that many people to see it.

Click here to see the complete report.

Tooling

New Wizards

We’ve added new wizards to create a JavaFX Library Project in contrast to JavaFX Project which is the main application project. There are new wizards to create an Preloader and Application class.

Preview improvements

The Preview control can be put into a mode where it loads the associated controller and creates an instance of it, including all bindings defined, … . The foundation for this feature was to provide the whole projects classpath to the FXMLLoader which is needed to reference e.g. custom controls developped in your project as well as other none JavaFX components like the MigLayout port for JavaFX.

FXGraph features

I’ve started documenting the DSL at http://efclipse.org/fxgraph.html.

Language changes

I decided to redefine some keywords (previewCssFiles is now called styledwith, previewResourceFile is now called resourcefile, previewClasspathEntries is not needed anymore because the projects classpath available in the preview).

New features

Namespaces

I’ve added the (optional) concept of namespaces to the DSL which makes sense once you want to reference other FXGraph components inside your FXGraph-Definition.

So your DSL file can now start with something like this:

Including other components

At the language level this feature was already present since the start but it was not implemented until now.

The Preview currently does not support loading those subcomponents but I’ll try to make this work in 0.0.10.

Support for translations from resource files

There’s a new keyword rstring which allows you to mark that a given string should be looked up in the given resource file instead of used as is.

Improved (singlevalued) attribute content proposals

The class proposal displayed for single valued attributes now take the accepted object type into account which reduces the number of proposals tremendously in most cases.

FXML

Reading the above paragraphs one might think e(fx)clipse is only about my custom DSL but to demostrate this is not I’ve started – as promised – on an FXML-Tooling support. Please note the support is currently really rudimentary (only simple attributes on elements) but what I have now is a foundation to build on in the next release.

I’ve experimented a lot in the last days (e.g. building an in memory logical model using SAX) but I finally once more used Xtext to built up an in memory model of the XML-File because there would have been so many things I’d have had to write my own when doing the parsing myself.

The Preview component does not yet support the FXML-Files but is scheduled to get supported with 0.0.10 with many more FXML improvements as well as bidirectional FXGraph to FXML conversion. Because of this planned feature the fxml-Document created from FXGraph-Files is now written next to the FXGraph-File.

Runtime

No new features have been released in the runtime components but Kai is busy working on the e4 front and we hope to provide new features with 0.0.10.

Other soft facts

Up-to-date components

I’ve updated to Xtext and Xtend 2.2 which are now a prerequisit because I’m using some of their bleeding edge features in the DSL. The All-In-One downloads are now built on top of Eclipse 3.7.1 (For the cowards) and 4.2M4 (For the adventurous) and naturally also include Xtext and Xtend 2.2.

Bugtracking and contributing

We now have a bugtracker at http://efxclipse.org/trac if you are seeking for a feature, discover bugs (which is very likely), … I can only hope you’ll find the time to report them.

Release Schedule

I plan to release a new version every 3 weeks which is half the time of an Eclipse Milestone cycle. So every time the Eclipse SDK releases a new version so does e(fx)clipse. The only exception might be support for 3.7.2 where an All-In-One build with the latest e(fx)clipse version at time will be provided.

I have to admit it feels extremly cool getting to the google campus. Thanks to Lars Vogel accepting me as a co-speaker and the Eclipse Foundation and Google Open Source Program Office organizing the event.

I hope I get once more the possibility to show up at this amazing event and talk about Eclipse Technologies, meet old friends and make some new ones.

Here is a link to the slides.

The author there talks about FXGraph and that it limits the appeal of e(fx)clipse which is think is not correct because nobody is forced to use the DSL I’ve been working on (use what ever you want – Java, GrooveFX, ScalaFX, …). It’s true that I currently don’t provide good tooling support for FXML but I plan to work on an FXML tooling so that people who want to directly edit them get decent support for it.

I think an important fact when it comes to FXGraph is that the DSL is not translated into Java or JavaByte code but into FXML so you can think of FXGraph-Files as a nicer textual representation of the FXML files content. The advantage of spitting out FXML are in my opinion:

• No lock in – you are not forced to work with FXGraph for ever because the generated FXML-File should be supported by e.g. Netbeans, IDEA, … you can switch to another IDE and continue with the work there
• Tool exchange – My opinion is that FXML is designed as an interchange format between different tools and not really designed to be authored directly so all upcoming tools (e.g. Scene Builder) will use it as interchange format
• No runtime layer – FXGraph-Files get translated automatically in FXML while coding and so you don’t need an extra library to make things work

Here’s a small diagram how I think FXML is designed to be used:

What’s missing at the moment is an FXML to FXGraph translator but this is something not really hard to implement so it’s already on my TODO-List for 0.0.10.

This makes it super easy for you to take e(fx)clipse for a spin – just grab the package appropriate for your platfrom, unpack and start writing your first JavaFX 2.0 application (after you configured the SDK-Location in Window > Preferences > JavaFX).

• Eclipse 4 Application Platform: Not commonly known features of the new platform
• State of Eclipse 4: What happened in 4.1 and what’s cooking for 4.2