Description David J. Orme 2004-06-15 13:20:19 EDT

What is an SWT control?

Traditionally, widget toolkits use inheritence to create new controls.  However,
SWT is an exception to this.  Indeed, most SWT controls specifically do not
allow subclassing.  The recommended way to create a new control is to subclass
Composite or Canvas.

However, observing SWT itself reveals that SWT does not always follow this rule.
 For example, some invisible SWT controls inherit from Widget.  And "controls"
that are contained by specific other controls inherit from Item.

Going beyond SWT, we find that Eclipse itself doesn't follow this rule.  For
example, JFace objects inherit from Object.

Extending this logically, one can see instances where a SWT control could
logically inherit from *anywhere* in the Java class hierarchy.

So what really logically constitutes an SWT control?  This bug report is
intended to be an essay and a discussion about this issue so we can discuss it
and make sure that we get this essential part of VE's SWT support right the
first time.  The discussion here will start with the technical requirements for
something to function as an SWT control and will derive the requirements for
something to be an SWT control from there.

Technically speaking, SWT controls have exactly one requirement:

- They must pass their containership parent to the constructor.

From a technical perspective, that's it.

By convention, SWT and JFace add a second requirement:

- SWT controls always use a 2-arg constructor (parent, int style).

Note that the type of the parent object is undefined.  Within SWT itself, you
can find objects that use Composite, Decorations, Control, Table, Widget, and
more as the type of the parent argument.

A second observation is that when one is extending SWT, it sometimes makes no
sense at all to support the "int style" parameter to the constructor.  There
simply are no style bits accepted because the contained control has a fixed set
of style bits that it *must* use.  An example of this case is the "View" class
in the open-source SWTworkbench RCPLite framework.

Lastly, as a practical matter, all of the standard SWT controls follow JavaBean
naming conventions for defining properties and events.  This appears to be the
only thing consistent about SWT's design.  It's also a good thing that this part
of the design is consistent, because otherwise VE support for SWT would be
nearly impossible.

All of this leads to the following definition of a SWT control.  An SWT control is:

- An arbitrary Java object

- That inherits from anything

- That contains either:
    a 1-arg constructor of the form Class(parent)
    a 2-arg constructor of the form Class(parent, int style)

- That follows JavaBean naming conventions for property accessors/setters and
event definition

- That can optionally supply BeanInfo in order to provide a builder with
additional information about properties, events, icons, etc.