I just download the latest nightly build and voilá they have now:

• Autocompletion in the CSS-Editor for -fx properties
  
• Autocompletion in the FXMl-Editor for element properties
  

Both of those features are also available in e(fx)clipse since a long time.

• CSS autocompletion
  
• FXML autocompletion
  

I’m currently working on improving the autocompletion for fxgraph and fxml for the upcoming 0.0.14 release. I wish I had more time to work on e(fx)clipse because this tooling stuff is more fun I ever thought it is. I have soooo many ideas and improvements but no time to implement them all.

The none release builds are not mirrowed and so downloading a build to verify my bugs is takeing for hours because they are throttled. My suggestion was to provide developers privileged access to downloads from Eclipse.org servers to solve the problem and so Denis asked me to file a bug. It was fixed in less than one week.

So if you are an eclipse committer next time you go to download.eclipse.org pay close attention to the download site:

Yes it is the small things that matter!

I’m try to collect some of the reasons why I think Eclipse 4 is superior to Eclipse 3 (and Eclipse 3 RCP) in the next few weeks and cover them in a blog post like this one.

Easier to add features / fix bugs

I’ve just released a feature to Eclipse 4 which took me no more than 5 minutes to implement (Bug 355763). I’ve also worked on the same feature in 3.x and there it took me around 2 days to understand how this whole thing works and another few days coming up with a fix which finally could not be applied because it didn’t worked in some corner cases (Bug 355750).

Advantage 1: Committers can fix bugs much faster

Not every feature is hardcoded in the workbench plugin

Many features like e.g. the collapsing of empty containers is not hard coded into the workbench code itself but implemented with so called addons who listen to the workbench application model and react upon changes in there (e.g. the removal of children in a container, …) but because the thing is an addon and you miss the durable feature (like many people did in 3.x for a long time) and don’t find a committer to implement it for you can now do it your own by replacing only a small discrete piece of code.

Advantage 2: Developers can add features / fix problems themselves without waiting for up-stream committers to implement it for them
Advantage 3: We the platform committers don’t own all the worlds problems because we have to implement it in our code and have to deal with the maintenance

Here’s the builder:

and this an resulting example code:

Now the problem is that make a builder for all FXClasses one uses is not really a practical thing but the nice thing is that most of them are Beans so I added a builder method that accepts a class as the first parameter and uses reflection to create an instance.

and even autocompleteing still works in this case:

I pushed the sources to my github repo. Maybe there’s a better solution to the reflection workaround I used but currently this looks quite good.

JavaFX 2.x API is already designed to be used for lambda expression support which will come with Java 8 so e.g. all event handlers accept a SAM type as their sole parameter. xtend already provides lambda expressions and so one can write less code.

Java:

b.setOnAction(new EventHandler<ActionEvent>() {
  public void handle(ActionEvent arg0) {
    // Some expression goes here
  }
});

xtend:

b.setOnAction [
  // Some expression goes here
]

// or if you have an equal-sign fetish :-)
b.onAction = [
  // Some expression goes here
]

The same is true for bean properties which look like this:

Java:

Button b = new Button();
b.setText("Say hello");
String v = b.getText();

xtend:

val b = new Button();
b.text = "Say hello"
val v = b.text;

The complete source code looks like this:

I’ve recorded a small video showing how to create a JavaFX project which uses xtend to the final exported application. The video highlights the amazing new feature the itemis guys added to their latest milestones when running your xtend code in debug mode – good job.

I’ll try to explore more xtend features like using the builder support but I need to first understand how this really works (too bad I missed their EclipseCon tutorial)

• The Eclipse 4 Application Platform explained – PDF
• e(fx)clipse – Eclipse Tooling and Runtime for JavaFX – PDF

• Tuesday:The Eclipse 4 Application Platform explained – This talk will explain the Eclipse 4 Application Platform which can be used to write JavaFX application using OSGi, Dependency Injection and central application model
• Wednesday:e(fx)clipse – Eclipse Tooling and Runtime for JavaFX – will provide you an overview of the e(fx)clipse features for tooling and runtime
• Thursday:Eclipse 4 Meets CDO: Now You See It, and So Do They! – this one will be really cool. We show you how the JavaFX version of the above application and the SWT one can communicate using CDO – opening and zooming an image on the one will be reflected automagically by the other
• Hot Product Show Case – I’ll be presenting e(fx)clipse at this event to interested people
• Kai Tödter and myself think about setting up a BoF to discuss the future of JavaFX for the Eclipse 4 Application Platform

Hope to see you at my talks or talk to you in the hallways or the bar about Eclipse, e4, JavaFX, …

All in one downloads

To say the all in one-downloads are well received is an understatement – they are a huge success. The 0.0.12 release has been downloaded 1385 time (windows 1200, linux 110, mac 75) – that linux outperforms OS-X is interesting.

This release provides you the following updates:

• Updated to Eclipse 3.7.2 and 4.2-M6
• Update to egit 1.3.0
• Update to Xtext 2.3.0-M6: I thought long about this update but finally decided its worth it because while we are entering the final release phase for Juno and the fxgraph stuff uses experimental xtext features this step had to be made

Runtime

Deployment/Provisioning

I’ve already teasered this new feature in a blog post. When writing and provisioning equinox based JavaFX applications you can now select a deployment model that suites you best:

• System installation: This deployment model requires your users to have JavaFX pre-installed on their system
• Next to your app installation: This deployment model requires you to place javafx next to your RCP/IDEs launcher – similar to how you can deploy a JRE with your Eclipse Application
• As a bundle installation: Here you place your javafx.jar into an OSGi-Bundle and the e(fx)clipse runtime will take care of extracting and wireing – see the tooling section on how e(fx)clipse helps you create such a bundle

e4 renderers

I’ve invested a lot of time into so called JavaFX-Renderes for the Eclipse 4 Application Platform.

The application in the back is rendered using only JavaFX. The one in the front is using SWT as the rendering technology for the workbench stuff (Tab, Menus, …) and JavaFX for the parts contents (like the list on the left, …) – in fact the classes making up the inner parts are 100% the same for the JavaFX and SWT-Version of the application

Even the Application.e4xmi is the same the only difference is that once the applications starts with the JavaFX-RenderingEngine and once with the SWT one – cool eh

JavaFX in 3.x Views

For those who simply want to use JavaFX to implement a view for the Eclipse IDE (3.x and 4.x) there’s a new feature which provides you an easy integration. The feature only holds one class named “FXViewPart”.

Tooling

Exporting

I received some mails from Matthias Pieroth – creator of PFRotator.FX which allowed me to track down problems in this area.

The exporting of JavaFX-Projects using the ant-tasks provided by JavaFX has been improved. Siging now works as expected and the Webstart export is now useable

Support for javafx-osgi bundle

e(fx)clipse will not provide you pre-packaged JavaFX-OSGi bundles because of various reasons (the most important one is that while 2.1 builds are published weekly this doesn’t make a whole lot of sense) but the tooling provides which allows to assemble such a bundle very easily.

Preview

The preview provides you the possibility to scale the previewed content which comes in handy if your UI is to big to be displayed without scrolling.

Like the screenshot depicts it looks like the latest Preview builds for JavaFX have fixed SWT/JavaFX-Embeding problems and so I’ve removed the alpha label from the linux builds.

Bugfixes

A list of bug fixes can be retrieved from our ticket system. I hope they help you get a better developer experience.

EclipseCon

I’m heading to EclipseCon 2012 tomorrow where I’ll take part in various sessions and in all of them e(fx)clipse will play a role:

• Tuesday:The Eclipse 4 Application Platform explained – This talk will explain the Eclipse 4 Application Platform which can be used to write JavaFX application using OSGi, Dependency Injection and central application model
• Wednesday:e(fx)clipse – Eclipse Tooling and Runtime for JavaFX – will provide you an overview of the e(fx)clipse features for tooling and runtime
• Thursday:Eclipse 4 Meets CDO: Now You See It, and So Do They! – this one will be really cool. We show you how the JavaFX version of the above application and the SWT one can communicate using CDO – opening and zooming an image on the one will be reflected automagically by the other
• Hot Product Show Case – I’ll be presenting e(fx)clipse at this event to interested people
• Kai Tödter and myself think about setting up a BoF to discuss the future of JavaFX for the Eclipse 4 Application Platform

The problem people face is that in Eclipse JavaFX has to run in an OSGi-Environment and JavaFX is not prepared for that leading to all sorts of problems when one applies the standard strategies (e.g. simply repackaging the javafx.jar as an OSGi-Bundle).

I’m happy to announce that the upcoming e(fx)clipse release 0.0.13 will fix your problems and make it very easy to use JavaFX inside your Eclipse Views.

The important changes that went into 0.0.13 is that different deployment models are going to be supported:

• System installation: This deployment model requires your users to have JavaFX pre-installed on their system
• Next to your app installation: This deployment model requires you to place javafx next to your RCP/IDEs launcher – similar to how you can deploy a JRE with your Eclipse Application
• As a bundle installation: Here you place your javafx.jar into an OSGi-Bundle and the e(fx)clipse runtime will take care of extracting and wireing

If you want to see it in action you can download a self-contained win32/32bit version of a RCP using this link which uses the 3rd deployment strategy.

The sources are checked into the e(fx)clipse git-repo.

Once 0.0.13 is released (which is going to be next weekend) I hope I can come up with a tutorial.

Jasper was nice enough to provide me an SVG-Version of it and so I was able to use my SVG-To-FXML-Converter to make some fun stuff with the logo he provided.

After the conversion I rearranged some parts in the FXML to group them and make them locateable through CSS-Selectors.

Next was to loaded the fxml-File:

Group g = FXMLLoader.load(LogoAnimation.class.getResource("efxclipse2.fxml"));

Use the extremly cool Node.lookup(String) to locate some of the elements in the FXML.

// hide the logo
Group logo = (Group) g.lookup("#logo");
logo.setOpacity(0);

// move the text to the right
Group text2 = (Group) g.lookup("#text_clipse");
text2.setTranslateX(-220);		

Next thing was to make the text move to the right and then make the logo FX-text fade in with this code:

TranslateTransition tt = new TranslateTransition(new Duration(3000), text2);
tt.setFromX(-220);
tt.setToX(0);
		
FadeTransition ft = new FadeTransition(new Duration(2000), logo);
ft.setFromValue(0);
ft.setToValue(1.0);
		
ScaleTransition st = new ScaleTransition(new Duration(2000),logo);
st.setFromX(0);
st.setToX(1);
		
SequentialTransition t = new SequentialTransition(tt,new ParallelTransition(ft,st));
t.setDelay(new Duration(2000));
t.setAutoReverse(true);
t.setCycleCount(Animation.INDEFINITE);
t.play();

Finally I wrapped it up in a transparent stage:

StackPane p = new StackPane();
p.getChildren().add(g);
		
Scene s = new Scene(p);
s.setFill(Color.TRANSPARENT);
		
primaryStage.initStyle(StageStyle.TRANSPARENT);
primaryStage.setWidth(657);
primaryStage.setHeight(237);
primaryStage.setScene(s);
primaryStage.show();

Last step is to use the built-in application export of e(fx)clipse which uses JavaFX’s ant-task to export an application

so that one can launch it on a double click

If you want to take direct look on the sources you can find them in e(fx)clipse’ git-repo.

I know that this is only a small example but it hightlights how easy designers and developers are able to interact with the use of Java, JavaFX, FXML and e(fx)clipse.