RE: [platform-swt-dev] From Swing to SWT

[Scott Stanchfield <scott@xxxxxxxxxxxx>]

The real solution is that we're all smart folks, and learning a separate UI
toolkit really isn't a big deal. Creating adapters will only lead to
minimized utilitization of the target toolkit features -- the end UI can't
be as effective as if it were just programmed usin the target toolkit.

The right way to do things (IMHO) is:

1) refactor your app (if necessary) so that the UI is "thin" -- all the
business logic belongs outside the UI

2) learn SWT (more below)

3) Create a completely new UI in SWT that uses the same business logic. If
you use the same design/layout of the old UI, this should be very
straightforward/quick.

I can hear the screams already, but think about it. How long does it take to
program a UI? The design/layout is really the hard part. Once you learn a UI
toolkit, programming UIs is really pretty trivial.

On learning SWT (when one knows Swing)
The missing piece here is a guide mapping "if you did X in Swing, you do Y
in SWT". I'd like to write such a thing, but I don't have the time... Of
course, once my UI builder is done, that'll ease things a bit, as the
builder can worry about how to create the objects (constructors with args or
not), not the programmer.

-- 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 Brad O'Hearne
> Sent: Thursday, January 16, 2003 11:01 AM
> To: platform-swt-dev@xxxxxxxxxxx
> Subject: RE: [platform-swt-dev] From Swing to SWT
>
>
> 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.  For example,
> the problem with having no default constructors in SWT could possibly be
> handled by a custom factory class.  The builder invokes the factory
> class without parameters, and the factory class creates the actual
> widget, using whichever constructor is appropriate.  This effectively
> gives a parameterless interface to the builder, while allowing the
> existing parameterized constructors to be used.  Likewise, it seems like
> get/set property methods could also be a class wrapper around the actual
> widget.  This is all probably a pain, yes, and alleviated by simply
> changing the design of the widgets themselves, but it is a possible
> answer.  I guess a nice side benefit is that your builder would be
> completely agnostic to the underlying widget implementation -- the
> interface is the same for AWT, Swing, SWT, or whatever new
> implementation might come along.  Because the interface is a wrapper
> around the widget library, there also is a separation between widget
> implementation and builder needs, which for maintenance of the widget
> library is probably a nice division of labor.  A simple set of classes
> that demonstrate this follow:
>
> e.g.
>
> public class BuilderWidget {
>
>   public BuilderWidget(o.e..swt.Widget w) {
>     this.widget = w
>   }
>
>   private o.e..swt.Widget widget;
>
>   public void setProperty(Object val) {
>   ...
>   }
>
>   public void getProperty(String name) {
>   ...
>   }
>
> }
>
> public interface BuilderWidgetFactory {
>
>   public BuilderWidget create(String widgetType);
>
> }
>
> public class SWTBuilderWidgetFactory implements BuilderWidgetFactory {
>
>   public BuilderWidget create(String widgetType) {
>   ...
>     //create the new SWT widget w
>     return new BuilderWidget(w);
>   }
>
> }
>
> Have you done something like this already?  Just an idea...
>
> BradO
>
>
> > -----Original Message-----
> > From: platform-swt-dev-admin@xxxxxxxxxxx
> > [mailto:platform-swt-dev-admin@xxxxxxxxxxx] On Behalf Of Lane Sharman
> > Sent: Wednesday, January 15, 2003 7:25 PM
> > To: platform-swt-dev@xxxxxxxxxxx
> > Subject: Re: [platform-swt-dev] From Swing to SWT
> >
> >
> > Michael,
> >
> > I have been studying this problem for a while and do not see
> > any clean
> > solution. The problem is that neither j.a.Component & Container, nor
> > o.e..swt.Widget and its descendants implement a meta data interface
> > which makes inspection of properties of a widget possible. Thus a
> > conversion tool or a Builder are hard to do for both Swing and SWT!
> >
> > I have written a short expose on the subject of property and
> > meta data
> > in a GUI and there is a JSR on this very topic.
> >
> > http://opendoors.com/conga/2.2/docs/property/siframes.html
> > is a little presentation I wrote on the importance of the property
> > exchange pattern which allows two objects that have no prior
> > knowledge
> > of one another to establish a protocol (aka Interface) to exchange
> > structured information. This is your case. You need a translator that
> > has a protocol map that can look at the dynamic state of your
> > Swing app
> > (not the static code) and then use that property information
> > to map to a
> > corresponding SWT tool.
> >
> > I really wish I could tweak the base class of the SWT to make it a
> > little more GUI builder friendly along the lines of what I
> > work with in
> > Conga.
> >
> > Everytime I study the base class of SWT, I become more
> > frustrated. For
> > example, it is very important that every widget have a local,
> > relative
> > name. There is no setName(), getName(). There is no
> > setProperties(ProperyList), getProperties(PropertyList). Sigghhh.
> >
> > -lane
> >
> > Michael Privat wrote:
> >
> > >Hi all,
> > >
> > >I would be very interested to hear some opinions regarding a
> > process to
> > >convert a swing based application to a SWT based application. I know
> > >there is some effort to create a standard SWT_AWT and vice versa
> > >container to allow mixing the two toolkits but I am interested in
> > >knowing if there are any patterns one might try to follow when
> > >converting to minimize the effort.
> > >
> > >Cheers
> > >Michael
> > >
> > >
> > >
> >
> > --
> > Lane Sharman
> > http://opendoors.com Conga, GoodTimes and Application Hosting
> > Services http://opendoors.com/lane.pdf BIO
> >
> >
> >
> >
> > _______________________________________________
> > platform-swt-dev mailing list
> > platform-swt-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/platfo> rm-swt-dev
> >
>
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
>