Community
Participate
Working Groups
SWT needs its own Component API model because of the following significant SWT programming constraint: Some Widget properties are implemented as style bits that are passed to the Widget's constructor. These properties cannot be changed after the object has been constructed. What this means is that whenever the GUI builder user changes a property that is actually implemented via a style bit, the changed control plus all controls it contains must be dispose()d and recreated. There is no way to change this without introducing a new layer of Java objects on top of the existing SWT objects (which are really just native operating system objects that are wrapped by SWT). Although there are other limitations that impede creating a GUI builder directly on top of SWT, this is the one that proves to be fatal. But whose design defect is this? Because SWT does not maintain its own layer of objects on top of the operating system's objects, SWT is really just inheriting the design of the underlying operating system API (mainly the Windows API). Visual Studio, Delphi, and so on have exactly these same low-level constraints to deal with: this is how the Windows API works for them too. What has happened on Windows is that the VBX, Active-X, and VCL APIs have been created on top of the Windows API to wrap and hide these issues. SWT is like the Windows API for cross-platform controls. SWT just needs its own Component API that wraps the messiness just like VBX, Active-X, and VCL have done for single-platform Windows applications. However, it is important for the ongoing health of the SWT community that such a Component API layer become a standard, supported by all SWT GUI builders, because this would enable a thriving third-party SWT custom control market to evolve. On the contrary, if every GUI builder author invented his or her own component API layer, then there would be as many component models as GUI builders, forcing custom control authors to choose which GUI builders to support. In the long term, this would stifle or possibly eliminate the opportunity for a thriving, vibrant third-party SWT custom control market, something we consider essential to the maximum success of all GUI builders on the SWT platform. The ideal place for such a standard SWT component model would be inside Eclipse itself. Then it would be clear to all GUI builder writers and third party custom control authors what API is the preferred way to support SWT. In order to help this work be done in the fastest and most expedient way possible, Advanced Systems Concepts has developed such a component layer for SWT. In order to maintain separation of concerns, we have made it a separate plug-in similar to JFace. We would like to submit it to the SWT team for possible inclusion into Eclipse as the community's "first cut" at producing a standard SWT component API. Attached to this bug report is a copy of the complete plugin including source code. Please let us know if the attached code will meet the above-described needs and can be included. Also, please let us know if you feel that we have missed anything either in our design or our implementation so we may rectify it and submit a fixed version.
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. --
