RE: [platform-swt-dev] ordering problem adding buttons to a GridLayout

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

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
>