RE: [platform-swt-dev] AWT Toolkit using SWT (was: From Swing to SWT)

["Scott Stanchfield" <scott@xxxxxxxxxxxx>]

Take a look at some past notes from me on this topic. Basically, I started
doing this, then stopped because I was deathly afraid that I'd be the one
responsible for turning Eclipse into a FrankenUI -- some stuff would look
native, others would look like Swing.

Raise your hand if "ewww"...

I think folks are approaching the SWT/AWT thing from entirely the wrong
angle.

I keep hearing talk of abstractions that will cover SWT and AWT/Swing, but
this is exactly the reasoning that made AWT so problematic.

The trouble is, when you abstract a UI toolkit, you can't take advantage of
the "bonus" items in one toolkit or another (without providing lots of
custom implementations for the toolkit that doesn't have the bonus item).
AWT is a good example of this, where they dumbed down which components were
available across platforms because some platforms didn't have certain
widgets.

Trying to abstract AWT and SWT would become a task of picking and choosing
which features to allow. In the end, you really couldn't create a UI using
the abstraction that really takes advantage of SWT or AWT.

IMHO, the "right" thing to do is to get people to realize that creating UIs
isn't that big of a deal. (And GUI builders help this a lot). One thing I'm
working on at work is a UI framework concept that provides an MVC/Command
patterned separation of UI and Business logic, so the UI is "pluggable".

Having a pluggable UI is really the key, here. In particular, if this is
done right, the UI could be SWT, AWT, Swing, JSP, or anything else for that
matter.

What this does is let you utilize whatever you need to make a particular
type of UI good. You can set up your JSP to create a good *html* interface,
and you can use SWT to create a good *GUI* interface, and not worry about
having to code the UI so that both work. Each is independent.

With good MVC/Command separation, the UI layer becomes quite thin, basically
a matter of "respond to user interaction by running a command".

(As always, open to thoughts and comments...)
-- Scott

====================
Scott Stanchfield
FGM, Inc.
scotts@xxxxxxx
====================

> -----Original Message-----
> From: platform-swt-dev-admin@xxxxxxxxxxx
> [mailto:platform-swt-dev-admin@xxxxxxxxxxx]On Behalf Of Jim White
> Sent: Thursday, January 16, 2003 11:51 AM
> To: platform-swt-dev@xxxxxxxxxxx
> Cc: lane@xxxxxxxxxxxxx
> Subject: [platform-swt-dev] AWT Toolkit using SWT (was: From Swing to
> SWT)
>
>
> Brad O'Hearne wrote:
> > Lane,
> >
> > I am sure you have already considered this (and hence the "hard to do"
> > conclusion), but it seems that the answer for both Swing and SWT is an
> > abstraction layer that wraps around both Swing and SWT.
> > ...
>
> Yes, that is correct.  That abstraction layer and attendant factory
> class is called java.awt.Toolkit.
>
> I believe the simplest and best answer to all this AWT-and-SWT
> interoperability jazz is to create an AWT Toolkit implementation using
> SWT.
>
> I did some work on this while ago, but have not done anything on it for
> almost a year.  If someone else wants to pick it up, I'm willing to
> provide some assistance. This is certainly a necessary and worthwhile
> project as it will get plenty of users and is essential (IMHO) for SWT
> to get standardized through JCP.
>
> (I had meant to follow up with you Lane after your talk at the LAJUG
> last week but have been busy...)
>
> Jim
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev