[
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))
|
I agree with Scott here
The problem should not be based around how a builder should construct an
SWT control from its properties, but rather how the properties should be
presented, rendered, edited and applied. The existing analogy in Java is
BeanInfo and JavaBeans - the BeanInfo describes how a JavaBean should
behave in an editor tool but once it has been introspected and its
descriptor classes retrieved it does not play any part in how the live
instance is actually hosted - just how it is presented.
The reason BeanInfo won't do the job right now is that
java.beans.PropertyDescriptor assumes that the property is controlled
through a get and set method, and also java.beans.ProperyEditor pre-reqs
java.awt.Component for its editor. However, you could follow the BeanInfo
pattern and have something such as org.eclipse.swt.info.PropertyDescriptor
that had three subclasses - one for get and set method properties, one for
public field access, and one for constructor style bits. The
PropertyDescriptor would contain the LabelProvider class name, the
CellEditor class name. As well as PropertyDescriptors you would need
eventDescriptors that would be similar to BeanInfo ones, expect that they
would need to deal with untyped listener pattern of SWT.
Bottom line - I love the idea of having a tools metadata layer for SWT,
however I very strongly believe that it should be a descriptive layer than
a component peer layer as proposed by Sweet. The descriptive layer could
either be explicit classes ( which BeanInfo is ) or else it should probably
be declared in XML.
Best regards
Joe Winchester
WebSphere Studio tools development - Visual Editor for Java
Scott Stanchfield <scott@xxxxxxxxxxxx>@eclipse.org on 24/01/2003 04:20:11
Please respond to platform-swt-dev@xxxxxxxxxxx
Sent by: platform-swt-dev-admin@xxxxxxxxxxx
To: platform-swt-dev@xxxxxxxxxxx
cc:
Subject: RE: [platform-swt-dev] Re: FW: SWT History and Design Decisions
( WAS: [platform-swt-dev] AWT Toolkit using SWT (was: From Swing
to SWT))
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
-----Original Message-----
From: platform-swt-dev-admin@xxxxxxxxxxx
[mailto:platform-swt-dev-admin@xxxxxxxxxxx]On Behalf Of Dave Orme
Sent: Thursday, January 23, 2003 6:04 PM
To: 'platform-swt-dev@xxxxxxxxxxx'
Subject: RE: [platform-swt-dev] Re: FW: SWT History and Design Decisions
( WAS: [platform-swt-dev] AWT Toolkit using SWT (was: From Swing to SWT))
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.