Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-ui-dev] 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



Back to the top