Re: [platform-swt-dev] Re: FW: SWT History and Design Decisions (WAS: [p

[Lane Sharman <lane@xxxxxxxxxxxxx>]

Greetings,

First, I am not absolutely certain that multiple choices for a SWT GUI Builder
is bad. If there ends up a couple of Builder choices down the road, this
may make SWT and Eclipse more vibrant.

As to the value of Orme's project at Advanced Systems Concepts, I would have
to look at the API docs, the GUI property model, editability and scritability
factors. Anyone can inspect Conga's api docs at 

http://opendoors.com/conga/2.2/docs/javadoc // for api docs
http://opendoors.com/conga/2.2/docs/mvcGuide.pdf

The latter link provides the reader with a snapshot of how one builds a conga
app. When I see comparable Builder docs for some alternate Builder approach,
I will be able to comment with some factual observations.

Kindest,

Lane



Jan Venema wrote:

Can we see it. I mean download and try?


Dave Orme wrote:

> Steve Northover wrote:
> Lane and others, SWT is a direct interface to the operating
> system.  As stated on the SWT component page, our intent is
> to be as thin a layer as possible.  Thus, it is unlikely that
> we will be adding any low level support for GUI builders in
> the near future.  We consider functionality that does not
> directly correspond to anything the operating system provides
> to be suspect.
>
> We believe that the right answer at this point is to use
> adapters.  If this turns out to be an unworkable strategy, we
> can look at it again. 

At Advanced Systems Concepts, we have been working on a pure SWT GUI builder for some time now and basically came to the same conclusion as Steve's above (see bug #19913 for our earlier discussion with the SWT team).

However, we also believe that it is important for the ongoing health of the SWT community that such a GUI builder adapter (or API) layer become a standard, supported by all SWT GUI builders, because this would enable a thriving third-party SWT custom control market to evolve.

On the contrary, if every GUI builder author invented his or her own component API layer, then there would be as many component models as GUI builders, forcing custom control authors to choose which GUI builders to support.  In the long term, this would stifle or possibly eliminate the opportunity for a thriving, vibrant third-party SWT custom control market, something we consider essential to the maximum success of all GUI builders on the SWT platform.

Consequently, we feel that having a standard SWT GUI builder adapter layer is *essential* to the ongoing health of the SWT community and Eclipse add-in market.

As I mentioned at the start, we have been working on a GUI builder for quite some time; consequently, our GUI builder product already has a SWT component API layer supporting:

- Automatic property and method discovery, getting, and setting

- Properties that are really style bits on the SWT widget's constructor--the user interface designer can change these on the fly (even though SWT doesn't allow this).

- Lazy loading of control classes into the GUI builder

Although I expect that there will be a few changes before our component API supports all features that would be desirable, its code base has been stable for awhile now;  I would consider it to be beta quality right now.

Steve, Veronica, (and those SWT heroes whose names I don't yet know): Advanced Systems Concepts would like to donate all of this work to the Eclipse project as the start of a standard GUI builder adapter layer.

We are willing to work with anybody (including but not limited to the SWT team and other stakeholders such as Lane and Scott) to make sure that the final result meets everybody's needs.  We are willing to be the official committers for work done on this plug-in so that this will not result in the SWT team needing to do any additional work.

Lastly, we are open to including this work officially as a part of SWT (even though it would be a separate plug-in similar to JFace), making it a separate project under Eclipse.tools, or structuring it however you feel is most appropriate.

How can we do this so that the interests of all stakeholders here are best served?

Warmest regards,

Dave Orme
Advanced Systems Concepts

PS: Although everyone is welcome to speculate about our product, please don't expect us to answer questions about it yet since it is still officially unannounced.  Expect a formal announcement fairly soon though.  :-)

-- 
Lane Sharman
http://opendoors.com Conga, GoodTimes and Application Hosting Services
http://opendoors.com/lane.pdf BIO