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

["Joe Winchester" <WINCHEST@xxxxxxxxxx>]

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.