e(fx)clipse e4 renderers go astray (rendering Swing)


I gave some talks at EclipseCon about our e4 renderers for JavaFX and showed of how the our renderers are built and different to those you find in the SWT implementation coming with Eclipse.

screen_rendering

On the left you see how the SWT one works and on the right handside how the JavaFX one is structured. The cool thing is that all the complex logic with lazy activation, … is implemented in an toolkit agonostic way and abstracted throught W*-Interfaces (git-repo).

Here’s an example of the WWindow abstraction we are using:

public interface WWindow<N> extends WWidget<MWindow> {
	
  public void setMainMenu(WLayoutedWidget<MMenu> menuWidget);
  public void setTopTrim(WLayoutedWidget<MTrimBar> trimBar);
  // ... left, right, bottom

  public void addChild(WLayoutedWidget<MWindowElement> widget);
  public void addChild(int idx, WLayoutedWidget<MWindowElement> widget);
  public void removeChild(WLayoutedWidget<MWindowElement> widget); 
	
  public void show();
  public void close();
}

That’s the whole interface you need to implement. Back to EclipseCon so showed off this concept and on the last day I was approach by a guy who immediately recognized that this renderering can be used to renderer with other UI-Toolkits like FX as well.

He’s been interested in a Swing one! He asked me for an estimate how much time it would take to get such a thing going and I answered: “Not more than a week”. He could not believe that is doable so had to proof it to some extend!

All the conversation happened before the start of a talk and I have to confess I don’t know anything about what the talk was about because I started hacking right on a Swing renderer, and before the 35 minutes talk had been finished I could show him this little app.

screen_swing

The most of the time it took to implement the bootstrapping of the OSGi-Application (25 minutes) implementing the SwingWindowWidget was a simple task. If you happen to be in need of a e4 on Swing-Renderer I’d suggest you take a look at the prototype I hacked together in 30 minutes.

I’ve pushed the code to an extra repository for now (it is not part of the e(fx)clipse code base donation to Eclipse.org).

We (BestSolution.at) currently have no plan to develop any Swing-Renderers but if you are interested in doing so or want to hire us to do it for you just get in touch with me because 99% of the code builds the foundation for our JavaFX renderer story (where we provide commercial support) a swing implementation automatically inherits all improvements and bugfixes we are implementing.

Before someone asks: Yes I know about Kai’s prototype doing something similar but he approaches the problem in a different way. In our case being able to implement Swing renderers is only a (nice) side effect of our rendering design concept which makes it super easy for you to implement custom JavaFX renderers (e.g. writing SWT-Renderers with our engine would/will never work!)

This entry was posted in e(fx)clipse. Bookmark the permalink.

4 Responses to e(fx)clipse e4 renderers go astray (rendering Swing)

  1. Kai Tödter says:

    I support Tom’s approach for JavaFX renderers. My approach was supposed to bridge the gap between SWT and other renderers, mainly to suggest an architecture that makes it easy to provide JavaFX renderers as first class citizens in an Eclipse 4 context. But this comes with a price. Tom’s approach is much better suited for UI toolkits that support an API like the one JavaFX (and even Swing 🙂 provides. In my point of view it would be great to have Swing renderers based on Tom’s approach.

  2. François Rey says:

    Actually an HTML5 renderer would be much more forward-looking than a Swing renderer which I would consider as backward-looking. Vaaclipse certainly comes to mind, but they are on a separate path for now, since they initially forked their rendering code from Kai’s approach. So they would have to rewrite a good chunk of their code in order to use Tom’s design. They mentioned this as a possibility but not a necessity, so that may not happen any time soon.
    So what’s the likeliness of ever getting such a port? Has anyone else expressed interest in this?

    • Tom Schindl says:

      We are not investing time into this. I’m happy to implement any type of renderer (swing, qt, html5) as long as someone pays me to do it.

  3. Wendell Beckwith says:

    Hi, Tom, I just saw this post and I was the guy you helped. I was completely blown away about how you helped. I was just looking for a bit of knowledge as to if it was doable, and then you started hacking away before the session. I appreciated everything you were doing but didn’t want you to miss the session, so I kept updating you, hey the sessions about to start, um we are 10 min it, etc. About 25 min into the session, you then triumphantly nudge me and show me the results. Simply amazing. If I make it to EC 2014, I’ll owe you a round at the bar.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.