[49] in Athena User Interface
Re: sawfish configuration
daemon@ATHENA.MIT.EDU (Brad Thompson)
Thu May 18 13:20:22 2000
Message-Id: <200005181720.NAA23568@snow-goon.mit.edu>
To: mjs@eazel.com, danw@helixcode.com
cc: aui@MIT.EDU
In-Reply-To: Your message of "18 May 2000 00:45:11 PDT."
<lq4s7ws3nc.fsf@pythagoras.eazel.com>
Date: Thu, 18 May 2000 13:20:17 -0400
From: Brad Thompson <yak@MIT.EDU>
Maciej says:
> Consider also the fact that destroy-type operations (the equivalent of
> XKillClient()) are evil anyway. Maybe it is a good thing not to make
> it easily accessible from the UI, since it is primarily a way for
> users to hurt themselves. An operation that at least tries a clean
> close before resorting to XKillClient would be slightly less bad.
I agree. The intent was to hide the kill functionality from users
who don't really want it. The problem is to make sure that users
who know what they are doing have access to it. The modifier-click
thing was a hack. As mentioned in an earlier mail, I think putting
xkill under the gnome menu would be a better idea.
Maciej says:
> Sides should resize. Sides moving the window is annoying and not what
> most users will expect. Don't design defaults for thousands of users
> based on your own unusual personal tastes. You are more likely to have
> the clues needed to change the default settings than they are. Sides
> resize on win9x and NT for what it's worth.
I was confused about what Windows did. I tried it out, and you are
right about that. However, I also thought the way they did it was
horrible from a UI standpoint. The frame and title bar look like a
single object---the top of the window just has a thicker frame and
has a title and some buttons in it. Clicking on any part should do the
same operation. I believe that this operation should be to move the
window. It allows users to move windows when the title bar is off the
screen or obscured by another window. The corners should be visually
distinctive to let the users know that they do something different.
I am not ``designing defaults for thousands of users based on my unusual
personal tastes''. My personal tastes are far more unusual than this;
for evidence, look at http://web.mit.edu/yak/Public/.xsession.
> Consistency with other GUIs should be a consideration, because the
> most intuitive interface is the one you already know. But of course,
> doing it right is more important than doing it the same.
And I believe that window frames moving the window is the right thing.
FWIW, MacOS does move the window when you click in the frame.
danw writes:
> Second, don't forget that (a) sawfish is very themable, (b) there are
> lots of themes out there for people to pick from, and (c) they almost
> all share certain core functionality that you're talking about
> changing. Having the Athena theme be different from all other themes
> could be weird.
Almost all themes are crap. I have no problem with changing core
functionality expected by enlightenment users who feel guilty about
running emacs and xterm on a $500 video card. On the other hand, I
would ideally like to use someone else's theme with at most minor
modifications, because it makes life easier. If I remember correctly,
there was a helixcode theme that seemed sane, as well as some of the
themes that come with sawfish.
Unfortunately, most themes rip off the Win95 idea of having the three
buttons in the top right corner and a menu in the top left. It is my
intention to try to elimate the menu without sacrificing functionality
for 99% of users.
> This seems to assume that people will change their GTK theme but not
> their sawfish theme, which seems like an odd assumption given that
> they're equally trivial to change.
If possible, we should make it so users only need to change one theme.
It could be possible for GTK to have separate themes for scrollbars and
buttons, but that would be wrong, even if they were both easy to
change.
> There aren't that many sawfish themes that track GTK themes, and no
> one seems to mind. Many WM themes come with suggestions on matching
> GTK themes, and Helix Code has someone working on "metatheme"
> packaging this summer (i.e., GTK themes packaged with matching sawmill,
> Enlightenment, IceWM, etc themes, and some sort of picker to set all
> of them together). No idea on the time frame of getting that out
> though. I can find out if you want.
This would be a good alternative to using a GTK-tracking sawfish theme,
if it is ready by the time we want to ship.
> Don't Windows and MacOS both put "close" on the opposite side of the
> title bar from min/max? Someone here commented that it's easier to hit
> maximize of it's the outermost button and you don't have to worry
> about hitting "close" instead.
MacOS puts "close" on the left, and "zoom" and "windowshade" on the the
right. Windows puts "minimize", "maximize", and "close" on the right.
I don't think that hitting close when you mean maximize is a serious
problem. Putting all the buttons together is more aesthetically
pleasing, so in the absence of a good reason to do something else, we
should keep them together.
> Then take a shower. And then go watch users. In my experience, they
> use the WM menus a lot, even for things that can be down with
> mouseclicks, because they don't know the relevant mouseclicks. (Eg,
> button3 in the title or border in sawfish will raise the window if
> it's not on top, or lower it if it is, but there's no way to just know
> that [unless you turn on sawfish tooltips])
I am not trying to steal functionality from users. My intent was to
make it obvious how to do all of the operations the users would go to
the menu for. If you can send a window to the taskbar by clicking an
obvious icon, then you don't need a menu item for it.
yak
