[jsword-devel] BibleDesktop in SWT
dmsmith555 at yahoo.com
Sat Jun 25 08:28:13 MST 2005
I finished the book. As I see it there are only two challenges/problems
in using SWT.
1) We need to determine whether we can get the Browser component to work
for our custom protocols. If we can't do it directly, we could probably
change the urls to be to a port on localhost that the application
listens to and speaks HTTP over it. I've done it before but I'd rather
not go there.
2) We will need to remove the MDI interface, ultimately replacing it
with a mechanism to view passages side by side.
It looks like everything else is doable.
But we have a few choices to make on how we use SWT.
First some background, for the most part SWT is a low level replacement
for AWT and JFace provides ease of use for SWT.
While it is tempting to say that JFace is to Swing as SWT is to AWT, it
is not the case. JFace and SWT play together well.
An alternative to JFace is SwingWT, which implements Swing in terms of
SWT. (I have not looked at SwingWT. Just read about it)
Also, it is possible to embed AWT and Swing into SWT.
SWT by itself is not usable without creating ease-of-use for it. The
biggest difference I see between SWT and AWT/Swing (and perhaps the rest
of Java) is that objects that hold references to system objects must be
explicitly released by calling that object's dispose method. Every
container calls the dispose method on the objects it contains. But if a
member variable needs to be disposed, then that object needs to override
the dispose to call it on the member variable. Examples of such objects
are windows, fonts, colors, images, and so forth. JFace provides
managers that take care of this. In general you create on of these
objects and store it by a program defined key in the manager. When the
manager is disposed automatically at the end of the program, it disposes
the managed resources.
The second big difference is that SWT does not provide for an MVC
paradigm. SWT's list contains strings. JFace provides an MVC paradigm
which maps objects to the strings that it contains.
So the choices that I see are (Pros and cons are not exhaustive, but
just my first reaction to reading the book):
1) Migrate from Swing by embedding the screen objects we have into SWT
Pros: This gets us up and running fairly quickly. We can migrate
Cons: There are places where it does not work well. It does not
provide the advantages of going to SWT. We would have two metaphors to
2) Use SwingWT.
Pros: Low cost of entry.
Cons: Does not implement all of Swing, perhaps something we depend
upon. We would still need to use SWT directly in those instances. This
probably would entail using JFace as well. Requires swingwt.jar and
perhaps jface jars.
3) Use SWT without JFace rolling our own layer.
Pros: We have already abstracted a lot of usability layers over
Swing, migrating these is will need to be done anyway. What are a few
more. Perhaps we could just snag the ones we need from JFace.
Cons: Some of the cool things that we want to do are in JFace (e.g.
docking, user preferences). Some are in Eclipse code that is built with
4) Use SWT and JFace.
Pros: JFace is built and tested. It already provides much of what we
do and want to do. It duplicates a lot of code we already have (read we
can eliminate some code).
Cons: Requires more jars.
Perhaps an advantage of replacing AWT/Swing is that the program can be
built and run with GNU's java, providing a complete open source solution.
I think the next step is to create a demo Bible Browser that uses SWT
(and perhaps JFace), and handles hyperlinks to other bible verses.
I'll be on holiday next week through July 5, so I may be offline.
DM Smith wrote:
> I am reading a book on SWT to see where the differences between it and
> Swing are.
> I'm not interested so much in the how, but the what. I expect that SWT
> has a different way
> of doing the same thing. Specifically, I want to figure out what SWT
> does not do that Swing
> does that we care about.
> The first that I found is that SWT uses the class Decorations to do
> something like MDI (JInternalFrame)
> but according to the book, on resize (split pane or window) the
> internal windows are layed out
> all over again with their original positions and sizes. I think that
> this is unacceptable.
> Personally, I find that MDI is only of value to look at passages
> side-by-side. If that is its only value
> then I think that we can figure out how to provide that feature a
> different way (e.g. parallel tab sets).
> Any other thoughts?
More information about the jsword-devel