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