[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [platform-swt-dev] ordering problem adding buttons to a GridL ayout
|
Brad,
Thanks for clarifying your goals. It seems to me that there is little
actual disagreement then about what needs to be done; the only area of
disagreement is in what software layer it needs to be implemented.
The position of the SWT people (that I've come to agree with) is that SWT
needs to do one thing well: provide a portable API to platform-specific
widgets. That anything else (providing JavaBeans features, etc) belongs in
a layer somewhere above SWT.
Conclusion: Since lots of useful software needs JavaBeans-like features,
what is needed is a *standard* layer above SWT that provides the ability to
implement these JavaBeans-like services.
In fact, there is an open source project devoted to doing just that. It's
called Sweet and can be found at sweet-swt.sourceforge.net. I created the
project when I ran into just the problems you're describing while creating
the SWTworkbench native SWT GUI builder.
At ASC, we realized that any JavaBeans layer for SWT needed to have a
standard implementation, so we created the Sweet open source project and
opened a bug report against Platform/SWT indicating the need for this
additional layer to be added to Eclipse itself. We are right now working
with Eclipse to get Sweet moved out of SourceForge and into Eclipse, so it
looks like this effort will be successful.
But it's not done yet. Of course, there's a ton of stuff that such an
abstraction layer really needs that Sweet doesn't do yet or only does
partially. So if you need these services and are going to write them, I'd
encourage you to come join us over at the Sweet project and let's add these
services to Eclipse once for everyone. :-)
Regards,
Dave Orme
Sweet project maintainer
> -----Original Message-----
> From: Brad O'Hearne [mailto:brado@xxxxxxxxxxxxx]
> Sent: Thursday, October 23, 2003 9:04 AM
> To: platform-swt-dev@xxxxxxxxxxx
> Subject: RE: [platform-swt-dev] ordering problem adding
> buttons to a GridLayout
>
>
> Put simply, dynamic loading via a ClassLoader, and dynamic
> adding and removing of Controls at runtime from a Composite.
> The application for such operations are numerous, far beyond
> any specific thing that I am doing. However, in my case, I
> would sum up by saying that my efforts revolve around an SWT
> abstraction, an SWT builder, GUI persistence, a separation of
> visual elements (widgets) vs. behavior elements (essentially
> event hanlding), and some other automation which I will not
> go into here.
>
> Understand too that I never stated that working with SWT or
> creating a builder with SWT was impossible. I know well the
> options I am facing to accomplish what I need to get done.
> Its understanding these needs that caused me to appeal to the
> dev list to point out certain shortcomings of the API.
> Certain things could be done to make API usage much simpler,
> and return such aforementioned abilities to the user.
>
> Please keep in mind -- I'm not down on SWT, moreover, I am
> very high on SWT. There's little in our technical world
> that's perfect, and so this was just an appeal at
> improvement. My overall goal though, is to see Java compete
> with Microsoft on the desktop. That's a whole other
> conversation which I won't get into, except to say that
> whenever we as Java engineers overlook the big picture, we
> drift farther from that end.
>
> > -----Original Message-----
> > From: platform-swt-dev-admin@xxxxxxxxxxx
> > [mailto:platform-swt-dev-admin@xxxxxxxxxxx]On Behalf Of Dave Orme
> > Sent: Thursday, October 23, 2003 9:18 AM
> > To: 'platform-swt-dev@xxxxxxxxxxx'
> > Subject: RE: [platform-swt-dev] ordering problem adding
> buttons to a
> > GridLayout
> >
> >
> > Brad,
> >
> > If I may ask, what are you really trying to implement?
> >
> > All of the questions you are asking relate to
> implementation details
> > of some larger project you're working on. Perhaps there's
> another way
> > to do what your attempting, but I wouldn't know for sure
> because you
> > haven't provided enough information for me to make any suggestions.
> >
> > I'm curious because I'm the author of several tools that manipulate
> > SWT controls generically (SWTworkbench, a native SWT GUI
> builder, and
> > the pure reflection-based implementation of XSWT, an XML
> description
> > format for SWT layouts. (XSWT had a couple of other authors too; I
> > just did the generic reflection-based implementation.) So
> I may have
> > already done what you need to do. Or I may have done
> something close
> > enough to it that I might know the solution...
> >
> > (And I'm sure that I'm not the only one around here who
> could provide
> > this
> > information.)
> >
> >
> > Dave
> >
> > > -----Original Message-----
> > > From: Brad O'Hearne [mailto:brado@xxxxxxxxxxxxx]
> > > Sent: Wednesday, October 22, 2003 2:24 PM
> > > To: platform-swt-dev@xxxxxxxxxxx
> > > Subject: RE: [platform-swt-dev] ordering problem adding
> buttons to a
> > > GridLayout
> > >
> > >
> > > Mike,
> > >
> > > Thanks for the response, and I really do appreciate your
> addressing
> > > the technical aspects of the problem. Comments:
> > >
> > > > Here's the problem: The platform APIs that SWT is built on,
> > > require a
> > > > parent when widgets are created (er....period). There were two
> > > > choices, either mirror this in the API, or duplicate
> every bit of
> > > > state the widget maintains so that the widget could exist in an
> > > > un-parented state (state stored
> > > > locally) or a parented state (state stored in the OS).
> > >
> > > I understand well the problem (as does everyone else confronting
> > > this issue), because by not solving it in the black-box
> of the SWT
> > > API wrapper around the platform APIs, it is a problem that is
> > > propagated to the API consumers to solve. And that's
> exactly what I
> > > am doing -- wrapping the SWT API in a manner that removes this
> > > requirement. It makes sense that the decision was to have SWT is
> > > merely mirror the design of the underlying platform
> > > components...though it would have been nice to improve on the
> > > platform design. ;-)
> > >
> > > > Even assuming that this could have been implemented without
> > > > consistancy problems (and I have never seen evidence that
> > > *any* system
> > > > that attempted to do this was 100% successful) it would
> have meant
> > > > significant overhead in *every* widget API as the code
> > > checked which
> > > > state it was in and handled the situations differently.
> > >
> > > This is terrific reason why the SWT API is a great the place to
> > > solve this problem, rather than in a secondary wrapper that each
> > > consumer has to design for themselves. Chances are that this is
> > > going to be a challenge redundantly addressed by multiple
> consumers
> > > of the API, and if it is that difficult to get right,
> then solving
> > > the problem once for all consumers within the SWT API could have
> > > saved a lot of work, and by your assertion, a lot of failed
> > > projects.
> > >
> > > > In addition, zero argument constructors are not a
> requirement for
> > > > building automation. There has been extensive
> discussion of this
> > > > in the SWT mailing list in the past. Both GUI builders, and
> > > "robots" can
> > > > be/are being built on top of SWT in its current form.
> If you would
> > > > like to turn the discussion to how this might be achieved,
> > > you're much
> > > > more likely to get a constructive discussion going here.
> > >
> > > Understood, but it creates hoops to jump through. My statement
> > > wasn't that building automation was impossible, it was that not
> > > providing zero argument constructors is a detriment the SWT API's
> > > ease of use, specifically eliminating the ability to use dynamic
> > > class instantiation with a ClassLoader. That's a
> powerful facility
> > > that the Java platform provides, it would have been a
> good move not
> > > to eliminate it as a factory option for API consumers. Thanks
> > > for the tip on the previous discussion, although I'm actually
> > > fairly aquainted with this problem already...there are
> two options:
> > > 1) widget wrappers or 2) carnal knowledge of the widgets you
> > > are creating, which is a whole lot less powerful than being
> > > able to generically create widget instances -- think
> > > persistence issues, etc.
> > >
> > > Anyway, I do appreciate the response. It appears that
> the issue of
> > > adding zero-argument constructors is not up for discussion, so I
> > > don't suppose I need to trouble the list with any more
> discussion on
> > > this topic.
> > >
> > > BradO
> > >
> > >
> > > _______________________________________________
> > > 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
> >
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platfo> rm-swt-dev
>
