Summary: | SWT needs a component model layer | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | David J. Orme <daveo> | ||||||
Component: | SWT | Assignee: | Steve Northover <steve_northover> | ||||||
Status: | CLOSED WONTFIX | QA Contact: | |||||||
Severity: | enhancement | ||||||||
Priority: | P3 | CC: | bogofilter+eclipse.org, clayberg, gmendel, jgossage, Konstantin.Scheglov, Winchest | ||||||
Version: | 2.0.2 | ||||||||
Target Milestone: | --- | ||||||||
Hardware: | All | ||||||||
OS: | All | ||||||||
Whiteboard: | stalebug | ||||||||
Attachments: |
|
Description
David J. Orme
2003-01-22 16:57:06 EST
Created attachment 3089 [details]
Proposed Component API layer (Sweet for SWT); initial release
Here's some additional help for anyone who downloads the above plug-in: Since the Sweet API hasn't been even accepted by Eclipse.org, much less frozen, I have not documented it beyond its own internal JavaDoc and comments. This comment is intended to overcome that limitation by explaining Sweet's overall structure for someone who is unfamiliar with it. Hopefully, this will quickly provide enough background so that an experienced SWT developer can quickly understand Sweet's structure and get to the point that the Javadoc becomes the most useful documentation. Sweet is basically a bunch of interfaces and convenience classes that provide default implementations of these interfaces. These classes also function as base classes for inheritance. In order to quickly get a feel for Sweet's structure, the easiest way is to load class Peer into the inheritance view and expand all children. The classes, unsurprisingly, follow the same inheritance structure as SWT itself. The basic idea is to create a set of peer classes for the SWT objects where the Sweet side of the relationship adds the features needed by a GUI builder. The code uses the terminology "Sweet peer" to refer to the Sweet class and "SWT peer" to refer to the SWT class in this peer relationship. The structure isn't a full Decorator pattern, however, in that the Sweet classes are not expected to wrap each individual method in the underlying SWT classes. Rather, Sweet takes the JFace approach of providing getControl() methods for accessing the underlying SWT Widgets. The one exception to the "follow the SWT inheritance structure" principle is that Sweet has no class corresponding with Scrollable. This is because we have not yet encountered anything that Scrollable does in addition to Control that requires additional support from a GUI builder, so we have followed the principle of "doing the simplest thing that could possibly work." Peers of Scrollables (Sweet peers of List and Tree) currently should extend ControlPeer. Lastly, the Sweet library is designed to create the inheritance structure from which actual SWT widget's peers will be created. We anticipate that a library of these peers will be provided by a separate plug-in that will be a part of the Eclipse project (probably org.eclipse.sweet.components). We are prepared to develop (or help develop) and support such a plug-in in addition to Sweet but would like to get the contents of the Sweet API finalized before investing a large amount of effort in creating peers. Since Sweet itself does not include any examples of actual Sweet peers, here is a skeleton peer for Composite to illustrate what a typical peer actually contains (I have deliberately not implemented some methods since the purpose here is to illustrate the structure of a Sweet peer rather than provide a complete working example): public class PComposite extends CompositePeer { public PComposite() { // Default to GridLayout setLayoutManager(new PGridLayout()); // Turn the border on by default Set styles = new TreeSet(); styles.add(new Integer(SWT.BORDER)); setStyle(styles); // Add IPropertyDescription objects here... } /** * @see org.eclipse.sweet.interfaces.WidgetPeer#createWidget(Widget) */ public Widget createWidget(Widget parent) { return new Composite((Composite)parent, getStyleBits()); } /** * @see org.eclipse.sweet.interfaces.IComponentPeer#getPropertyNames() */ public String[] getPropertyNames() { // Return an array of property names for a Composite... } /** * @see org.eclipse.sweet.interfaces.IComponentPeer#getValidStyleNames() */ public String[] getValidStyleNames() { // Return an array of SWT.XXX names that are the valid style bit constants // for a Composite } /** * @see org.eclipse.sweet.interfaces.IComponentPeer#getValidStyles() */ public Integer[] getValidStyles() { // Return an array of the integer values corresponding to the style names // returned by getValidStyleNames } } The purpose of the above is to illustrate how straightforward it is to create a Sweet peer for a nontrivial SWT class, along with a default layout manager, etc. If anyone has any questions about the above, please let me know. Rather than using concrete classes for each widget I think the approach should be similar to the BeanInfo approach used by JFC classes. I think having a composite peer is too limiting as it seem to be driven by the need to re-cycle the SWT control when one of its style bit values changes, however this should be left up to the GUI builder to decide how to do. Instead the specification should be driven more along the lines of a description of how the SWT control' properties are made up, what cell editors and label providers work with each property. In the case of the BeanInfo java.beans.PropertyDescriptor the assumption is made that the PropertyDescriptor represents a get and set method, however with SWT it should provide three different descriptor types, one for a get and set method pair, one for a public field, and another for a style bit. Having retrieved the structure and design time behavior of an SWT control from its metadata the metadata class should not actually be used inside the IDE. The metadata could be described in a class format or, my preference, would be an XML based descriptor. Basically - I love the idea of a metadata descriptor for SWT controls in a builder, however I am opposed to the idea of this being in the form of a peer layer inside the IDE and would rather see it be a declarative format. Created attachment 3128 [details]
Plugin.xml (was missed from the "package plugin jars" function)
Created a page on the Wiki for discussing and resolving people's concerns about the current design: http://eclipsewiki.swiki.net/248 You guys need to continue your discussions on the Wikki. I probably won't get a chance to take part in this until after 2.1 ships. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it and remove the stalebug whiteboard tag. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- |