Skip to main content

[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 Joe.

Let's not forget that the info that can be got must include event listeners.

Bob

From: "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.
>
>
>
>
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
>



Back to the top