Is there a nice way to abstract the GUI so SWT or Swing can be used?

Question

I'm writing an application that has an SWT GUI currently, but would like the end-users to be able to choose between SWT and Swing. I've experimented with abstracting the GUI details before at different layers in the program, but have never been really satisfied with the results. Is there an agreed-upon or nice way to do this?

Answer 1

Unfortunately I don't believe there's a toolkit-agnostic API or similar.

So perhaps it's worth looking at the model-view-controller pattern. You need to abstract as much functionality away from the GUI into the controller such that the GUI components are thin and are dedicated to the particular windowing toolkit that you've chosen.

This will allow you to slot in a Swing view in place of a GWT view (or vice versa) with the minimum of duplicated code.

Note also that this makes testing a lot easier, since as much as possible has been folded into the controller or model.

Answer 2

Is there an agreed-upon or nice way to abstract away GUI-specific code?

The answer, in short, is no.

The trouble using any particular GUI library is that each GUI comes with a set of basic design tenets that influence every use of the library. Unless one comes across two such libraries that agree in every particular on these design tenets, there's no simple substitution of one GUI for another.

There are a number of libraries that attempt to impose their design upon a bunch of disparate GUIs underneath each with their own design, but these libraries require ferocious amounts of programming. As well, the attempt to force one set of design paradigms into another is not usually completely successful.

Examples of these libraries are QT, wxWidgets, and, of course, Java's base AWT.

In the end, you pretty much have to accept that you are going to choose a library and get stuck with it.

Answer 3

If your only goal is to let users choose between SWT or Swing drawing their UI, then SWTSwing would have been an option. You could code in SWT and choose the SWT implementation jar during startup and adapt your classpath accordingly.

SWTSwing is an implementation of the SWT API using Swing. It does the same thing that every native SWT implementation does: it provides the bridge to the underlying GUI API.

Why do I write "would have been"? Unfortunately the project seems dead, stuck in an unfinished implementation of SWT-3.2, even though lots of the work seems to be done as you can see in the webstart demo. The sister project EoS (Eclipse on Swing) had even a running prototype. So I cannot really recommend using it, even though I like the idea.