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

[Dave Orme <DaveO@xxxxxxxxxxxxxxx>]

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
>