Re: [platform-swt-dev] SWT & Native widgets

[Randy Hudson <hudsonr@xxxxxxxxxx>]

CTabFolder looks inappropriate in Windows too.

Andre Weinand <weinand@xxxxxxx> Sent by: platform-swt-dev-admin@xxxxxxxxxxx 08/08/2002 06:13 PM Please respond to platform-swt-dev

To:        platform-swt-dev@xxxxxxxxxxx         cc:                 Subject:        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

_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev