Skip to main content

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

Hey all,

I believe this past post is a good segue into a question I have, and
that is the history of SWT from a design standpoint.  I have been able
to find Eclipse history, but none pertaining to specifically to SWT.  It
is interesting to note that SWT (presumably, since Eclipse started with
IBM) has its origins in IBM, but also that the original announcement of
JFC back in 1997 at JavaOne introduced JFC as a joint effort between
Sun, Netscape, *and* IBM.  So if IBM was involved in both JFC and SWT,
what gave cause to IBM to pursue a different path than Swing, and create
SWT?  Were there specific problems (performance, interoperability, etc.)
in Swing viewed as too big to overlook, or a difference in opinions on
design that caused IBM to pursue a different direction?  If Swing was a
joint effort, why not just change Swing?  Following, once that decision
was made to create SWT, what were the key issues in the design
discussions, and what determined the final design of SWT?

BradO 

> -----Original Message-----
> From: platform-swt-dev-admin@xxxxxxxxxxx 
> [mailto:platform-swt-dev-admin@xxxxxxxxxxx] On Behalf Of 
> Scott Stanchfield
> Sent: Thursday, January 16, 2003 10:29 AM
> 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/platfo> rm-swt-dev
> 




Back to the top