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

["Brad O'Hearne" <brado@xxxxxxxxxxxxx>]

Oops...one error in my code...

>   public Object getProperty(String name) {
>   ...
>   }

The return value should have been an object.

> -----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 8: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
>