[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[platform-ui-dev] Re: [platform-swt-dev] SWT & Native widgets
- From: Seth Nickell <snickell@xxxxxxxxxxxx>
- Date: 09 Aug 2002 12:09:58 -0500
- Delivered-to: email@example.com
> 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
> 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
> 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.