[
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)
|
It's
not necessary to make changes to SWT to make it "Builder Enabling" -- it just
requires a different approach to builders than the JavaBeans model that Sun
uses.
My GUI
builder uses a model that's independent of the target toolkit (basically
keeping track of "what" an item is and what property values have been set, what
"connections" between pieces exist, and so forth). The target toolkit is used
for presentation, but the way you manipulate the on-screen pieces doesn't care
about whether the target toolkit requires constructor args or
not.
The
presentation and code generation plugins are the only pieces that do care. The
main builder allows different sets of plugins for different types of components.
AWT/Swing presentation plugins create a real AWT/Swing UI behind the scenes and
take snapshots of it that the GUI builder shows on the screen. The AWT/Swing
code generator plugin generates code to create the target application, JavaBeans
style.
SWT
presentation/code generation plugins take the same approach, but they
create an SWT UI to visualize, and generate SWT code.
Like
any good MVC app, a visual builder has layers, and if they're done
right, the builder can easily adapt to different styles of UI toolkits.
Never
try to change the actual thing you're modeling (unless it's really for the sake
of the "actual thing's design"); tools should adapt!
--
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
AWT & Swing FAQ Manager,
jGuru.com
Visit for Java
Enlightenment!
http://www.jguru.com
==============================================================
Scott
Stanchfield wrote:
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".
Bongo,
FreeBongo, and now Conga radically cuts the programming out of the GUI
construction phase: the content designer is essentially drawing java objects
without knowledge that he is manipulating a hierarchy of java instances.
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".
UIs
do not just generate action button commands. They render notifications,
updates, test (if they can) for proper input patterns, repaint. A good GUI
deals well with Z ordering of layers. Double Buffering. Having worked
with a GUI Builder for about seven years now, my hat is truly off to the
original authors of Conga.
On a supportive note, I really appreciate
this dialog. I am now of the opinion that some thought should given to an
interface API for GUIs. This interface API would insulate the client
applications, the Builder and most of the runtime from the underlying
implementation classes. We have some good examples of this in j.sql.* which is
mostly a set of interfaces which "providers" implement. However, this is
really hard stuff to get right. It should not be tackled without some serious
thought to who, how much time, what ultimate benefit, cost and ultimate
return.
I have read again the principles of SWT: "efficient",
"portable", and "access to the user-interface facilities of the operating
system". I would like to add one more "Builder
Enabling". If I could make some strategic changes to
the base class , there would be a foundation on which to create a
Builder.
Just some thoughts.
-Lane
(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
--
Lane Sharman
http://opendoors.com Conga, GoodTimes and Application Hosting Services
http://opendoors.com/lane.pdf BIO