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

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
-----Original Message-----
From: platform-swt-dev-admin@xxxxxxxxxxx [mailto:platform-swt-dev-admin@xxxxxxxxxxx]On Behalf Of Steve Northover
Sent: Thursday, October 23, 2003 10:52 AM
To: platform-swt-dev@xxxxxxxxxxx
Subject: RE: [platform-swt-dev] ordering problem adding buttons to a GridLayout


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



Back to the top