Why are you posting two copies of every message
today? (Cross-posting, at that.) ;-}
Bob
----- Original Message -----
Sent: Friday, August 09, 2002 1:20
PM
Subject: Re: [platform-swt-dev] SWT &
Native widgets
One last point I'd like to
make, and then I'm going to get off the soap box:
There is always going to be a tension between platform
look&feel requirements and Eclipse look&feel and portability
requirements. The goal of the SWT team is to create an acceptable compromise
between these. It's clear that we will never be able to meet every possible UI
guideline for every possible platform since, as you indicate below, they are
incredibly platform specific. What we hope is that, we can make efficient use
of platform widgets to create a UI which lets people get their work done. We
are always looking for better ways to access the platform capabilities (like
the current effort to figure out how to deal with platforms which have
markedly different default key bindings (eg. the Mac)), and we welcome
contributions from people which would add to this (ideas or implementations),
but what's really important is that Eclipse *works* on these platforms.
To me, in some sense, this is like
the "near human" problem in animation -- it's only because we are as close as
we are that you even *notice* issues like the ones you are presenting. I
really *do* believe that we are close to the ideal of being multi-platform
while still being platform specific. I also think that discussions like this
are useful, but concrete implementations are what counts.
McQ.
| Seth Nickell
<snickell@xxxxxxxxxxxx> Sent by: platform-swt-dev-admin@xxxxxxxxxxx
08/09/2002 01:09 PM Please respond to platform-swt-dev
| To:
platform-swt-dev@xxxxxxxxxxx cc:
platform-ui-dev@xxxxxxxxxxx Subject:
Re: [platform-swt-dev] SWT & Native
widgets |
> 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 look "dated" rather than "Windows-like". It's probably time
to > look at updating our L&F again.
Discerning what the
"majority" thought was a good UI obviously results in a Windows look and
feel. So even if the UI designers didn't go out to make the widgets look
like any given platform, using that sort of metric will result in windows
that look like Windows. The fact that this LNF needs to be updated owing to
changes in Windows, in my mind at least, only re-inforces that this UI
decision was essentially made for teh Windows platform. Similarly, the lack
of colouring in the toolbars prior to mouse-over. Windows used to use this,
but it has never been appropriate on MacOS or GTK. "good" UI is an
incredibly platform dependent sort of thing.
> 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: >
My exact words: "The current
infrastructure does not seem to allow for the common directory to contain a
set of all pure-java widgets". I was not trying to be misleading or spread
lies, I intentionally worded this to emphasize that this was just "what I
could find". Obviously the problem was that I didn't discover that widgets
could be moved out of common and into emulated instead where they wouldn't
conflict with native implementations.
> make this decision, but
that's a discussion you need to have with the UI > team, not with
us.
Fine by me.
> 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.
Though I do wonder if GTK could do a competent StyledText
widget at this point... The new text widget is quite powerful. But
Off-Topic :-)
> Your point 2) seems to basically be an
implementation detail.
Of course, I didn't mean to imply this was a
big architectural issue, just an implementation detail that would need to
be tweaked to allow this.
> > 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.
OK, this I 100%
disagree with. The Mac version of Eclipse looks nothing like a native
MacOS/X application. Look through the MacOS HIG. It breaks practically
every rule there. The only resemblance to MacOS X is that it uses native
widgets. But as I've tried to stress over and over, platform style is a
*LOT* more than drawing an interface using native widgets. Ask any MacOS X
interface designer worth their salt what they think of Eclipse on that
platform. Even from a screenshot I think you'll get reamed. When you
actually interact with Eclipse its even worse (everything from non-sliding
motion, to deferred applied preferences).
The GTK/GNOME version of
Eclipse actually fits in better because GTK/GNOME is a lot closer to
Windows stylistically than MacOS X, but even there things are radically
wrong.
-Seth
_______________________________________________ platform-swt-dev
mailing
list platform-swt-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
|