FW: SWT History and Design Decisions (WAS: [platform-swt-dev]
AWT Toolkit using SWT (was: From Swing to SWT))
> 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. :-)