[platform-swt-dev] SWT & Native widgets

[snickell@xxxxxxxxxxxx]

Hi,

SWT (and other parts of eclipse) have a large number of widgets written
in "Pure Java" (the "common" directories). While technically speaking
these will run on any platform, many of them are effectively designed
for a specific platform: Windows. By way of example, the CTabFolder
widget matches Windows titlebars very nicely, but looks inappropriate in
GTK. Additionally, the GTK notebook widget could easily replace this
widget providing native functionality and looks (because GTK allows for
the packging of arbitrary widgets into tabs the pulldown menu and close
button can be added to provide identical features to the Java version).

Because each platform has its own unique constraints, appropriate
widgets, and special widgets that other platforms do not have, it would
be useful to be able to take *any* widget in Eclipse and replace it with
a native version.

There are two problems with this right now:

1) The current infrastructure does not seem to allow for the common
directory to contain a set of all pure-java widgets, but then to allow
native versions to provide an implementation of those widgets as an
alternative. Widgets either have to be native-on-all-platforms or
native-on-no-platforms.

2) SWT uses default visibility on a number of key fields and functions
in Composite, Widget, etc that would be necessary to subclass native
widgets from these. Effectively that means that the SWT infrastructure
can not be used to provide native replacements. Making these fields
protected would allow the definition of useful native versions of
widgets outside of org.eclipse.swt.widgets.

Because GTK and Motif currently don't display a high degree of stylistic
unity it is easy to get away with having a bunch of pure-Java widgets
that "look like Windows". However, as a GTK style progressively evolves
(and is pushed forward by the GNOME-Human Interface guidelines) more and
more of these widgets will need GTK versions to look and feel right.
Also platforms such as MacOS/X will need a huge amount of native UI code
really pass them off as a "native" application. Everything from CoolBars
to CTabFolder to the way dialogues work will need to be customized to
create an application that integrates even tolerably well with Aqua. So
I think the principle of being able to replace any UI piece with a
native functional-equivalent is pretty important, and will become
increasingly important in the future.

-Seth