Helixsoft

It is said that every problem in Computer Science can be solved by adding another layer of indirection. In this case we added two just to be sure 🙂

As I wrote before, Thomas’ project is to make PathVisio toolkit-independent so we can draw Pathways to an SWT Widget, a Swing JPanel or even an SVG file directly through the Graphics2D abstraction layer.

This work is now complete, the Pathway drawing component is now completely toolkit independent. In the screen shot below, you can see three different versions of PathVisio running side-by-side. In the top-left you see the old SWT version. In the bottom you see a Swing-only version, and in the right you see the new Graphics2D Pathway widget inside the old SWT GUI.

In the latter case, the Pathway drawing is rendered with Graphics2D onto a Swing JPanel, which is then wrapped inside the SWT app using the SWT-AWT Bridge. Surprisingly, there is hardly any performance overhead.

But what’s the advantage? Using Thomas’ code I now have an easy way to visualize my Pathway difference sets to SVG. My original idea was to generate SVG directly using one of the XML writing libs in java, but now I can use Batik and the Graphics2D functions which is much easier. I just managed to get the first graphical output of my gpmldiff tool. It would have taken me at least a week longer if I had to write the SVG directly.

When we started on the PathVisio project more than a year ago, I had to choose which GUI toolkit we were going to use. I chose the SWT toolkit instead of the more commonly used Swing toolkit.

At the time I had a bit of experience with Swing interfaces, and I knew how ugly they can be. One of the first things you learn to do in Swing is to enable the “system look and feel”, to at least have the illusion of integration with the rest of the operating system.

Swing was touted by Sun as enabling a “cross-platform look and feel” meaning that the program would have the same look, whether you use it on Solaris, Windows or the Mac. I think this is a silly feature. Most people never run a program on different platforms. The only people who do that are either the application developers themselves, or they work at Sun, where people are blind to subtleties of modern desktops. The consequence, of course, is that you can recognize Swing apps a mile away because of the look of the GUI

SWT was supposed to fix that. SWT lets you create a GUI that is much more integrated with the rest of the operating system. Since the PathVisio project is heavily focused on usability, this sounded like a good match. But, as I found out over time, SWT is not without its problems either.

• You always have to package a huge extra library, including native libs for each target platform.
• SWT, Webstart, Mac OS X: Pick only two. You simply cannot have all three.
• SWT is relatively new and hence relatively buggy. We’ve hit a number of SWT bugs during PathVisio development. Luckily, some get fixed with each new version.
• And not least of all, the choice for SWT has prevented us from integrating PathVisio with other applications, most notably Cytoscape.

But we can get the best of both worlds by factoring out the SWT dependent code and creating a toolkit-independent layer. Luckily such a toolkit-independent layer already exists: it is called Graphics2D and is officially part of Java. There is no Graphics2D implementation as part of SWT, but if you search around you can find other open source projects that ran into the same problem and already provide a partial solution.

Integrating this idea into PathVisio will in fact be the first step of the project of Thomas Kelder, another GSOC student working for GenMAPP. I really hope it works out as planned because this is going to open a whole new set of possibilities.