Skip to main content

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




Back to the top