[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] SWT & Native widgets
|
Yes, this is a big issue for the MacOS X port too:
For example SWT provides a native progress bar if you know the range
in advance.
If you don't know this range JFace adds a "Pure Java" progress bar
that is animated
by a separate thread. On windows the "Pure Java" progress bar closely matches
the native progress bar, on the Macintosh the native bar has a nice
animated Aqua look
and the "Pure Java" emulated bar still has the Windows look.
Other examples from MacOS X:
- JFace draws a separator line between the window's menu bar and the
windows's content.
However on MacOS X the menu bar is not located within the window.
So there is a
gratuitous separator at the top of a window.
- the CTabFolder looks inappropriate in Aqua.
- the pulldown menu of a toolbar item looks inappropriate in Aqua.
- Eclipse "panes" with the gradient fill in the title area and the
hard shadow around their border
look OK on windows but naive on Aqua.
There must be a way to replace "Pure Java" custom widgets by the
appropriate native widgets.
--andre
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
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
