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

[Scott Stanchfield <scott@xxxxxxxxxxxx>]

Kinda similar to what I mean by a pluggable UI, but:

1) The pluggable UI concept should be a design choice, not forced by the UI
builder. Builders can have specialized support for such a pattern, but they
should also support other styles of visual design

2) My concept of pluggable UI is really based on two sets of pieces:
   a) An interface (as in Java interface) that allows commands
      to ask questions of a UI as well as provide feedback
   b) Commands that allow a UI to interact with the business logic/model

If done right, this should allow the same business logic to be used for
AWT/Swing, SWT, JSP, or whatever other Java UI you'd like...

-- Scott

==============================================================
Scott Stanchfield    scott@xxxxxxxxxxxx    http://javadude.com

Lead author of "Effective VisualAge for Java, Version 3"
                                      http://javadude.com/evaj

VisualAge for Java Tips and Tricks     http://javadude.com/vaj
Visit for Java Enlightenment!             http://www.jguru.com
==============================================================

> -----Original Message-----
> From: platform-swt-dev-admin@xxxxxxxxxxx
> [mailto:platform-swt-dev-admin@xxxxxxxxxxx]On Behalf Of Christian Gruber
> Sent: Thursday, January 16, 2003 6:37 PM
> To: platform-swt-dev@xxxxxxxxxxx
> Subject: 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
>
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev