swt
standard widget toolkit |
 |
|
Development Resources |
|
Detailed information about developing applications with SWT and porting SWT is available on our developers page.
|
| What's
Happening |
 |
R3.0 Development
|
|
R2.1 Maintenance
- The 2.1 plan is posted here.
- Release 2.1 is available in the download
area.
|
The most succinct description of the Standard Widget Toolkit component is this:
The SWT component is designed to provide
efficient,
portable
access to the user-interface facilities of the operating systems
on which it is implemented.
The SWT component implementors take each of the terms in this statement to have
a very specific meaning:
- "efficient"
-
implies that SWT must be as thin a layer on top of the operating system
facilities as possible. So, for example, SWT avoids the use of a separate peer layer
as is found in the Sun AWT class library, thereby gaining increased speed and space
efficiency at the cost of some amount of implementation flexibility. SWT also
attempts to avoid "sugar coating" the limitations of the underlying operating
system, since doing this always implies significant overhead in
addition to introducing the potential for subtle failures and incompatabilities;
this is the "sometimes you have to let the o/s win" rule. An example of the kind
of problem that SWT would not attempt to hide is the existence of limitations on
cross-threaded access to widgets.
The only exceptions to the rule are cases where a particular operating system is
missing features that are required for it to be a candidate Eclipse platform.
If some small set of specific, clearly defined "workarounds" can be made to enable
Eclipse to run on this target, then they will be implemented. For example, the lack
of a ToolBar type widget on Motif was addressed by providing an "emulated" version
on that window system, since ToolBars are fundamental to the Eclipse look and feel.
- "portable"
-
implies both that it must be possible to create applications (Eclipse, in
particular) which will run on all of the supported operating systems, and that
SWT itself must be simple to port to new operating systems.
The former case is supported by providing a common programming interface.
By coding to this API, applications can be created that run
everywhere where SWT will run. It is important to note that, because SWT uses the
native (i.e. operating system provided) widgets, the look and feel of
applications built with SWT will vary on each operating system so that they match
the expectations of users of that operating system.
The later case, the porting of SWT itself, is supported by ensuring that all but
the lowest-level, direct interface to the operating system is written in Java. In
SWT there truly is "nothing interesting in the C natives", which makes the initial
porting (and subsequent debugging) of SWT considerably easier since it can largely
be done using the facilities of Eclipse, including the built in remote debugging.
In addition, the coding style of SWT is such that it is easy for programmers that
are familiar with a particular operating system to understand and implement the
code.
A side-effect of the SWT implementation strategy is that it is relatively
simple to create operating system specific extensions to SWT to support
particularly important features. An example of this would be ActiveX on Windows,
which Eclipse uses (protected by appropriate platform checks) to support embedded
ActiveX controls and documents. It was felt that to be competitive on that platform,
support for ActiveX was a requirement, even though it was not available elsewhere.
Because SWT is "close" to the platform, this was not a difficult task.
- "access to the user-interface facilities of the operating system"
-
Although this has already been stated, it is worth reiterating that the widgets
that the SWT component provides are those that are provided by the operating systems
on which SWT runs. The intent is to allow access to these native widgets (and the
other operating system user-interface facilities), not to
"roll our own" new widget system. As such, although the SWT component implementors
try very hard to make it possible for consumers of SWT to be able to ignore
which operating system they are running on, developers need to understand that
applications can potentially behave differently to match the operating system
behavior. For example, programatically giving focus to a "radio" button on Windows
will cause it to be selected. Period. Since it would be exceedingly difficult
(and is counter to the Windows user-interface look and feel) to prevent this behavior,
the Windows version of SWT generates events as if the user had
"clicked" the radio button when it is given focus. This means that well-written
applications can ignore the differences, but also means that smart developers will
test SWT applications on every platform which they are to be delivered on.
Custom Widgets
If that was all there was to this story, then everything would be clear cut.
However, in addition to the work described above, the SWT component is responsible
for one additional aspect of Eclipse: the implementation of the custom widgets
which provide the specific look and feel (i.e. the "branding") of Eclipse. This is a
complex task, since it requires a delicate balance between the particular vision of
the user-interface designers, and the desire for the widgets to have appearance and
behavior that is consistant with the user-interface guidelines of the
operating system.
It is important to note that, if Eclipse were to be built entirely from custom
widgets and used no native widgets, then the SWT component implementors would
consider their work to be a failure. The intent is to provide a small
set of carefully considered custom widgets to give Eclipse its distinguishing
features in a way that is still strongly oriented towards the look and feel of
the platform. For example, when the user modifies the appearance of their desktop using
platform provided mechanisms (setting default window background colors, border
widths, "skinning", etc.) the custom widgets should reflect these changes
whenever (a) the changes can be detected and (b) they do not specifically contradict
the brand appearance.
Currently, all custom widgets are coded in terms of existing SWT widget and graphics
APIs. They are portable and use underlying SWT mechanisms to ensure that they have
correct appearance. Although this already works quite well, one of the research
areas for the SWT component is to further improve the ability to match the platform
appearance, for example in the presence of "programatic skinning" as provided by
window systems such as GTk.
Embedded Systems
Another exciting aspect of SWT is that it is also being used as part of the
underlying implementation for several embedded systems efforts because of its
small size and focus on efficiency. The most notable of these, currently at least,
is in the AWT implementation provided as part of the VisualAge/MicroEdition class
libraries, where SWT effectively becomes the peer layer for AWT. Further
effort is ongoing to improve SWT's utility in this area.
And finally, one last aside: The above discussion blurs and sometimes ignores the
distinction between operating systems and window systems. We do understand the
difference, but wanted to avoid making things even more verbose than they already were.
| Get
Involved! |
|
If you are interested in participating in the development of the SWT component,
check out the developer's mailing list: platform-swt-dev@eclipse.org.
Chat with people there about your problems and interests, and find out
what you can do to help.
Hey! The SWT component implementors are always looking for smart, dedicated people who "share the vision"
to help us. If you are one such, please do drop us a line.
For more detailed information, check out the Development
Resources.
|