Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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
>

Back to the top