[
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,
I
think you have finally nailed the issue, which is a philosophical one.
You mention that there is a trade-off between "those buidling GUI builders"
vs. "those creating SWT user-interfaces". I personally believe that
looking at the big picture, those two camps aren't really divided, but
the same. "Those buidling GUI builders" and "those creating SWT
user-interfaces" are both API consumers that build SWT
user-interfaces. Perhaps they go about it in different ways, but not
necessarily so. And with respect to the degree to which an API will be
pervasive as the basis for a market-leading end-user technology, ignoring
builder concerns creates obstacles to this end. And for the record, these
being "builder" issues is actually somewhat of a misnomer -- these
aren't builder concerns, they are dynamic usage concerns which even non-builder
apps could use.
So
anyway, the philosophical issue seems to be this: is SWT meant to be a
middleware GUI toolkit, a facade on the native OS that provides its feature and
hiding some of the unfortunate nuances of the OS (addressing the concerns of all
users in the process) -- or is SWT meant to be a bridge that exposes the
native OS to Java. The answer may be a blend of both, but I think SWT
leans heavily to the latter. And that's fine. With this in mind,
I'll aim to solve these problems in my app.
BradO
Agree. The trade off here is "those building GUI
builders" vs "those creating SWT user-interfaces". Currently, there are
more people not writing GUI builders so we are optimized for that case.
Hopefully, the "maintenance and implementation nightmare" should be easier for
those higher up the chain. For example, you must have a data structure
somewhere that captures the properties of each control. You need this in
order to generate code and to know which properties are the default and which
have been set by the user. Even if SWT controls were full JavaBeans, you'd
still need one of these. Therefore you know what an uninstantiated
Control looks like and how to create one. Furthermore, you shouldn't
have the ordering and query issues that SWT controls have. For example,
a hypothetical SWT text control that had no parent and therefore no operating
system peer needs to provide a complete implementation of the API (that
exactly matches the behavior of the operating system) so that code that
manipulates it before the operating system resources are acquired behaves
exactly the same as code that manipulates it after the resources are acquired.
Furthermore, thie private state for this implementation needs to be copied
back and forth or kept up to date as the operating system control is created
and destroyed. Presumably, a GUI builder doesn't have this problem because the
controls are not programmed in arbitrary ways at design time?
The fact that a discussion happens again
and again indicates that there is a legitimate problem but sometimes there is
no good solution, only trade offs.
|
| "Brad O'Hearne"
<brado@xxxxxxxxxxxxx>
Sent by: platform-swt-dev-admin@xxxxxxxxxxx
10/23/2003 10:05 AM
Please respond to platform-swt-dev
|
To:
<platform-swt-dev@xxxxxxxxxxx>
cc:
Subject: 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
