[jsword-devel] BibleDesktop in SWT

[DM Smith]

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 
containers.
    Pros: This gets us up and running fairly quickly. We can migrate 
piecemeal.
    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 
maintain.
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 
JFace.
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?