[
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
|
Steve,
It
isn't a matter of seeming evil (but for the record, no, you don't seem
evil). While I understand there's no merit in an endless rehash, on the
other hand, there's probably good reason that "these discussions have all
happened before, a million times". Its probably a good indicator of a
legitimate problem that needs to be solved. As for the issue of "working
around them is a disaster" -- the problem isn't eliminated by ignoring it in the
API -- it is simply propagated to a higher level of the application (to the
API consumer). So the "maintenance and implementation nightmare" now
belongs to the API consumer to solve. Going back to the original
point, it isn't a matter of seeming evil, it's more a matter of being open to
address legitimate issues and alternative approaches.
BradO
-----Original Message-----
From:
platform-swt-dev-admin@xxxxxxxxxxx
[mailto:platform-swt-dev-admin@xxxxxxxxxxx]On Behalf Of Steve
Northover
Sent: Wednesday, October 22, 2003 7:02 PM
To:
platform-swt-dev@xxxxxxxxxxx
Subject: RE: [platform-swt-dev] ordering
problem adding buttons to a GridLayout
Hey Brad,
Sorry if I seem evil but these discussions have all happened before, a
million times. The summary is that GUI builders want JavaBeans but
JavaBeans don't map well to the operating system. There are plenty of native
GUI builders and tools out there so it can't be impossible to build them using
the technology of the platform. The problem is that bogus restrictions are the
downside of being native, and SWT sometimes inherts them. Generally speaking,
attempting to work around them is a disaster. In this case, we determined that
it would be a maintenance and implementation nightmare.
Steve
| "Brad O'Hearne"
<brado@xxxxxxxxxxxxx> Sent by: platform-swt-dev-admin@xxxxxxxxxxx
10/22/2003 03:24 PM Please respond to platform-swt-dev
| To:
<platform-swt-dev@xxxxxxxxxxx> cc:
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/platform-swt-dev