[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-swt-dev] Re: FW: SWT History and Design Decisions ( WAS: [platform-swt-dev] AWT Toolkit using SWT (was: From Swing to SWT))
|
Title: Message
I
definitely agree that a common way to help GUI builders inspect SWT
components is way valuable.
However, I just took a peek at the bug report and description of Sweet,
and I don't quite agree with this approach.
I'd rather see an external metadata (similar to BeanInfo, perhaps
just a BeanInfo extension) to describe SWT components, rather than decorators.
These co-classes would provide all the data needed for a GUI builder. Several
advantages come to mind, such as the "design-time" info doesn't need to be
distributed, metadata can be supplied for existing components/subGUIs without
changing them, etc. I think Sun was on the right track with the BeanInfo
co-class idea, but they missed a few details in the
BeanInfos...
I'm
happy to chat about this -- perhaps we could come up with some proposed
enhancements to BeanInfo (or just come up with a BeanInfo
sub-interface?)
--
Scott
Hi
Lane,
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. <<SNIP>>
Perhaps I didn't communicate clearly enough: We don't disagree on the
point you raise above. To the contrary, we agree that there is room for
many SWT GUI builders and that choice and competition in the market is a good
thing! :-)
About a week ago, you were asking for input
about how to approach supporting SWT in your GUI builder. The official
response from the SWT team was, "Develop an adapter (or GUI builder API)
layer."
However, upon reading that, our
concern was that if (for
example) you write a SWT GUI builder API layer and we write a separate
SWT GUI builder API layer and Scott and Ramen also write their own SWT API layers for their
respective SWT GUI builders, that a market for third-party SWT custom
controls will never succeed. This is because third party
custom control authors would be forced to decide what GUI builders to
support, thus fragmenting the market for
SWT custom controls. Consequently, the market for the GUI
builders themselves would be likely to remain small because the
usefulness of a GUI builder is partially related to the wealth of its
corresponding third-party custom control
market.
To
mitigate this risk to all of us, Advanced Systems Concepts would like to work
together with all other GUI builder authors such as yourself, Scott, and Ramen
to agree on a common SWT API layer that we all will support.
We also believe that such a layer ideally belongs inside Eclipse itself
rather than maintained and managed by any of our respective
companies.
The
result was that (as one of the other developers on the list put it), we put
our money where our mouth is:
Since we had already created a GUI builder API layer for SWT, we
open-sourced it as a starting point for everyone's Eclipse GUI builder
API and opened bug #30022 as a place for public comment on the matter.
We attached the complete source code (licensed under the CPL) to the bug
report and invite your, Scott's, Ramen's, and anybody else's
comments.
Coming back to where we started this whole
discussion: about a week ago you asked for input about how to approach
supporting SWT in your GUI builder. Now you don't even have to develop
the layer the SWT team proposed. It's available to you, free for the
taking under the same license terms as you got Eclipse itself.
:-)
If
you don't like something in the API, let's discuss your
concerns on Bugzilla. We can all decide by vote which ideas to
include in the final API. And hopefully, our friends in SWT development
will see fit to include our collective result as part of Eclipse
itself. ;-)
Let's write some great code
together. I apologize if my previous post was unclear about our
intentions. :-)
Best
Regards,
Dave
Orme
Advanced Systems Concepts
PS:
I'll post a similar message momentarily on e.tools so all stakeholders will
have fair notice of this opportunity.