[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-swt-dev] From Swing to SWT
|
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
>