[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [platform-swt-dev] AWT Toolkit using SWT (was: From Swing to SWT)

I'm quite partial to the NeXTSTEP approach, where you had associations
which mapped fields/gui-outlets to controllers, who serve up segments of
the model.  These adapters are re-usable, and provide collection and
value links in a more generic way than all that SwingModel crap.

For example, if you have a combo-box widget (one of the more complex
widgets), you connect it to a ComboBoxAssociation , which you also
connect to a Controller object which exposes a List and a variable of
the type contained in the list.  You then set on the Association, the
property of that value Class from which the labels in the combo-box
should be chosen.  The Association is built to listen to any events
coming from the ComboBoxWidget for selection, etc., and in such events
sets the mentioned variable with the appropriate List element.

By using abstract collections and Application-specific Controllers with
generic Widget-specific associations, you can go along way.  If you tie
this approach to something like JDO, you can build quite complex
database-driven applications with fairly little effort.

And the GUI builder was supreme.  I've been toying with a similar
builder for SWT based on the same concept, but have not yet had time to
flesh it out.  But such an approach actually does let you (to some
extent) swap guis.  It's not a wrapper layer, but an adaptor layer.
You'd never automatically swap GUI layers, however, as the process of
trying to automate and create parity between two different GUI widget
sets would be highly complex and fraught with mistakes.

Regards,
Christian.


-----Original Message-----
From: platform-swt-dev-admin@xxxxxxxxxxx
[mailto:platform-swt-dev-admin@xxxxxxxxxxx] On Behalf Of Scott
Stanchfield
Sent: Thursday, January 16, 2003 1:29 PM
To: platform-swt-dev@xxxxxxxxxxx
Subject: RE: [platform-swt-dev] AWT Toolkit using SWT (was: From Swing
to SWT)

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

_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev