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

["Mike Wilson" <Mike_Wilson@xxxxxxx>]

I'm going to jump in and answer this original posting, even though I know there are other follow ons. 
(Also, I'm cross-posting to UI dev, so they'll see the UI L&F related comments.)

First off, the "pure java" widgets (which we call "custom") do *not* look like any given platform. In the early days of the project, we had several UI designers work to provide a particular "look" (aka "branding") for Eclipse, which was intended to be functional, but in addition to provide a certain "something extra" which would make users think that every effort had been made to make Eclipse a world-class IDE. That _really_is_ why the widgets look the way they do, and if that turns out to look similar to a particular point in time of the Windows UI design, then that's because that was what was considered by the majority of users (although not by me) to be what "good" UIs looked like at the time. Of course, the sad thing is that current Windows implementations (i.e. XP) don't even use, for example, the "gradient fill on tabs" look any more, so in some sense we currently l!
 ook "dated" rather than "Windows-like". It's probably time to look at updating our L&F again.

In your point 1), you say that we do not have an "infrastructure" that allows for widgets to be custom on some platforms and native on others. This is blatantly false. The "infrastructure" (which is as thin a layer as the rest of SWT) is:

- a widget which is going to be native on a particular platform is defined in the subfolder (of the "Eclipse SWT" folder in the the "org.eclipse.swt" project) whose name matches the platform.

- a widget which is going to be emulated on a particular platform is defined in a subfolder of the "emulated" subfolder, and the .classpath_<platformname> file (and related build scripts) is set to include this folder.

That's all that is required. The reason why you are not seeing this for cases like CTabFolder is because it was *deliberately* chosen to look as it does (and thus different from all platforms), and so it would be *incorrect* to let it have a particularly platform L&F *until* the Eclipse UI design is changed to allow this. You can argue that it was a wrong to make this decision, but that's a discussion you need to have with the UI team, not with us.

Having said that, the SWT team is *happy* to use native widgets whenever we can. That's our reason for getting into this in the first place. So if the community decides that they would rather have native widgets in *any* part of the UI, rather than the custom ones, we will do the work necessary to move stuff around and make it work. Remember: the other thing you get from using custom widgets is that you are freed from the constraints of the underlying operating system -- don't ask for a native StyledText unless you want its API gutted.

Your point 2) seems to basically be an implementation detail. Rather than talk about things like this as generalities, it's better to find the specific field which is preventing you from doing what you want, and send us an explanation of why this is a problem for you, complete with example code if possible. For cases where we have not been able to find a simpler way of  solving the problem, we will change the field's visibility. Note: Java is *brittle*, so changes like this are potentially harder than they should be. Even so, we will make the change, even if it takes a "deprecated" cycle to do it.

Finally, I can't speak to the progress of the GTK UI community, but I have been heavily involved with the Mac port of Eclipse and I can tell you that it *already* looks much like all other Mac applications, even though it is still using emulated CoolBar and Table widgets. Once these are fixed to be done natively (as they are on Windows), I assure you that the appearance will be satisfyingly Mac-like.

McQ.

-----------original post follows----------------------------

On Thursday, August 8, 2002, at 05:37 PM, snickell@xxxxxxxxxxxx wrote:

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
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev