I'm still investigating this one (who knew IBM & Sun were having such a huge pissing contest just out of view), but to help kick the discussion off and focus my investigations here are a couple of starter questions.
- What makes SWT the right choice for this project?
- What implications does that choice have on components, tools, etc, etc? (eg if I find some fancy Swing based graph widget, can I integrate it with GeneaPro)
My main bias towards SWT is that it makes a Java program really look and perform like a native app in the two logical target platforms Windows and Linux. And I think this is important, because our audience will be used to using mostly Windows-based apps, we need to make them think this is practically the same thing.
One item I am settled on too is the Eclipse IDE, and since it is implemented in SWT, it was proof to me that fairly complex and slick apps can be made and deployed.
What I don't like about SWT is it's limited platform support, but that is improving slowly and the platforms we care about now - Windows and Linux are covered. So this is a small hit.
The other limitation you mentioned, lots of spiffy widgets in Swing/AWT, not to mention more and better GUI designer tools, etc. is a greater concern. But the flip side is I don't think we want GeneaPro to look like Frankenstein's monster either, with peices from all over the playground.
So I think SWT is the right overall choice, but as with most choices of this kind, there are give and takes.
Personally, I'd vote for Swing, because "standard is better than better", and Swing is standard w/Java.
(More programmers use it, more software uses it, more tools support it, etc.)
Having said that, I think that SWT vs. Swing is not going to make or break this project. So, if you want to use SWT, do it.
This prompted me to lookup all the SWT vs. Swing comments out on the net and I have to say again I think SWT is the right choice of GUI standard for this project.
We are trying to introduce researchers to a new way of doing genealogy using the GenTech process - making this look as slick (or slicker) than the commercial applications being used today on Windows is an important consideration.
Also realize that we are looking for developers who focus on the genealogy and may not be as strong in the Java - SWT is clearly a bit easier for them, and as the GUI is not expected to get extremely complex, we should not bump into significant limits later on.
And in the spirit of a "standard is better than better" - SWT is the standard for this project, even though Swing may be better. <grin>
A postscript - we are being diligent is separating the code for processing a genealogical object from its use/display - this is part of the modular design of GeneaPro. I would suggest that this would allow a Swing-aholic to design their own GUI, whether as drop-in replacement or modular add-on. However, this would not be an initial project goal, as there are enough things to do here without managing the development of two redundant GUIs.
I did do some additional investigation, but never wrote up the results.
To answer my original Swing/SWT compents/tools/integration question, it looks like the two can be integrated, but not easily. There is some Swing on SWT and SWT on Swing work going on, but it's rudimentary at best.
SWT won't exist on *any* target customers platforms (heck, most developers don't even have it), so it represents an additional installation dependency.
There are many more Swing components available than SWT components, so if you want to use a graph drawing package to layout your family tree/network or if you want to plot family migrations using a mapping package, you're going to have to use Swing.
As you might guess from the examples above, I don't agree with the statement "the GUI is not expected to get extremely complex."
I think, at a bare minimum, the ability to integrate Swing based components is critical.
The other aspect of this is the impact that the choice will have on the availability of programmers for the project. The assertion was made that SWT is better because it's easier to learn for novices. I'd argue that if you find yourself with UI novices on your hands, you put them to work on something else. The question then becomes will Swing or SWT be more attractive to the most UI engineers. I think I agree with the previous poster than Swing wins on this account.
I understand from the previous reply that the decision is final, but I think it's still important to elucidate the pros and cons of that decision.
OK, this topic has come up enough that I am willing to take some time and look at/prototype some Swing/AWT GUI code. I'm still of the opinion SWT/Jface is the look and feel we should go for, and I will focus more on merging and using Swing components for the stuff we simply can't solution with SWT/Jface. I think the major limits to Swing use have more to do with Eclipse plugins, as a standalone app, I do not believe we are as limited there, but a simple prototyping exercise will let us know for sure.
You're dicussion here grabbed my interest.
I develop java applications in SWT for a company in Ireland, and have just a few points on issues raised here:
1. Swing integration with SWT is not essential, in fact, there's absolutely no need. The only widget missing as far as I've come accross is the Spinner control, but there's already an opensource version of that out.
2. Bundling the SWT jar and library file is no big deal.
3. The performance and stability is well worth it. You'll notice the start up time more then anything. We were apprehensive about leaving Swing, but have not looked back. You get so much for "free". And applications look really native.
4. Fancy graphs etc... are all possible with SWT's graphics object. And there's a fantastic project, also on sourceforge, that allows you to integrate Java2D with SWT at native speed. See: www.holongate.org
5. The one problem you may come accross is not having the amount of developers readily available as you may have in Swing. The learning curve form one to the other is quite small.
Hope this is of some help,
Thanks for the feedback Anthony. It's always good to have an opinion backed by real world experience.
Just to clarify on the graphs, I was talking about the node/arc (or edge/vertex) type, not the pie chart type. If you had a large network (ie graph) of connected relatives that you wanted to create a chart for the graph layout and editing features of something like JGraph could be quite useful as a basis to build on.
The Holongate site seems to support my earlier evaluation that SWT/Swing integration is possible, but requires work. For example, the Batik port is currently output-only because "No functionality from the JSVGComponent is resued, as many of them do not cleanly fit into the SWT event and threading model. Text selection needs complete rewrite as the AWT event queue and objects are used."
You mentioned bundling the SWT jar & native library. Do you guys use a multiplatform installer and bundle all the different libraries for your deployment platforms or do you create a kit per platform?
Thanks again for the feedback.
Log in to post a comment.