Re: GNOME 2.0 Must Fix - Sawfish

[Kenny Graunke <kenny whitecape org>]

<quote who="Maciej Stachowiak">

> On 05Sep2001 06:24PM (-0700), Kenny Graunke wrote:
> > Hi all,
> > 
> > http://boom.whitecape.org/Fixes/sawfish.html has draft 2 of the sawfish must
> > fix list. Comments and suggestions are welcome.
> >
> 
> Man, I knew I shouldn't have subscribed to this list, I just can't
> stop having opinions. 

Hehe. ;-)

> The proposal is a mixture of specific individual suggestions and a
> suggestion to use the Klarth theme as the default. I'll put in my two
> cents about the Klarth theme and then comment on the individual
> suggestions (many of which I like).
> 
> My main comment about the Klarth theme is that while it may have some
> usability improvements compared to Crux, it does not look as good. In
> particular it doesn't match the Crux Gtk+ theme (as seen in the
> screenshot), although I don't know if that's a big deal. I suspect it
> also wouldn't match the default Gtk theme very well either. The main
> problem is that in Klarth tthe title bar and buttons have gradients
> and edges that make them appear to indent in slightly, while in crux
> gtk everything bulges out slightly.

Good point... An older screenshot is available at:

http://runic.whitecape.org/the-gimp-with-klarth.png

...in that one it buldges out. I was originally planning on making it an
option, but I'm not sure. This definately matches Crux better, and is a
trivial change.

> The combination is not so good. Of
> course, I am a bit biased because the Crux Gtk and Sawfish theme
> combination is the first and only one ever to make me forget that the
> window manager is a separate program. 
> 
> I also don't like the fact that the whole title bar is colored with
> the selection color. Is there a reason this is useful? It's kind of
> visual overkill.

Not really. It's partially to look like NeXTstep/Window Maker, but mostly
because implementing a nice transitioning image like Crux's tumbly blocks
was going to be a royal pain due to the dynamic gradients and resizing
titlebars. I am sure it is possible with some effort, though, I will look
into this some more.

> Now onto comments about the specific suggetsions (some of which I
> think we should try to apply to the Crux sawfish theme).
> 
> * Respecting Gtk theme colors: good
> * Title bar height adjusting for font: good
> * button order: good
> * button graphics being [+] [-]   [x] : good (wow, I can't stop agreeing here)

:-)

> * More flexibility in choosing button order: this may be good, but
> only if we dump a bunch of the other current sawfish settings from the
> control center; there's too many right now to add something that takes
> that much screen space

It's an idea. I'm not sure I really find this much better than having a list
of common OS orders and providing a good default, personally.

> * Window shading: sounds fine.
> 
> * button states changing: I suggest the default theme not provide a
> way to vertical-only or horizontal-only maximize, as this is a
> confusing feature and and worse yet makes the maximize button have
> four different states.

Agreed.

> * buttons taking filling the full titlebar height: I think the
> usability argument for this is spurious, given the fact that on MacOS
> 9, MacOS X, Win9x, etc the button does not take the full height and I
> don't hear about a lot of users accidentally closing windows. Most
> windows that are dangerous to close will ask for confirmation (web
> browser windows being one admitted exception).

I suppose I'm just being paranoid here...

> Having the button take the full height looks worse, and does not as
> strongly convey the fact that it is a button. Also, you don't need to
> make the window resizable from the corner closest to the close button
> just because the button does not take the full height. In fact, this
> is not the case on MacOS X or MacOS classic (they both provide a large
> and obvious resize affordance in the lower right corner of the window;
> I'm not sure how easy that is to do on the X window system given how
> window managers work.

I don't know...I guess it is what you're used to. Although I think having
borders around there implies that you can resize there. On MacOS, you cannot
resize from most of the borders, simply the corner - but with Crux and other
themes, you can resize from any edge. So having one corner where you cannot
resize would be weird, IMO.

> * resize handles: the top border should be a resize handle! Otherwise
> it's unnecessarily complicated to resize windows downwards. The
> corners adjacent to the top side are debatable for reasons cited but
> surely the top edge is uncontroversial.

Indeed. Again, simply because I hadn't thought of it, then technical issues
- making the top of the titlebar resize is definately on my TODO list.

> * Resize handles on maximized windows: this is debatable, but how
> about leaving them in and automatically turning off the maximized
> state for the window if the user resizes it? I personally would find
> it convenient at times to make a window full screen, and then resize
> it to somewhat smaller without having to do a separate unmaximize step
> first.

I suppose that would be alright too. Clearly if the resize handles are
there, they should turn off the maximized state and resize the window. One
of the reasons for removing them is to maximize screen space available to
the window, presumably the goal of maximizing. Another reason could be
Fitts' Law compliance - easier access to the scrollbar, though I think with
current applications this is not really achieved anyhow.

> * context menus: maybe we should have this off by default. No major
> mainstream GUI has a window manager context menu. Perhaps there should
> be an advanced setting to turn it on.

Agreed. I believe we inherited this "feature" from MS Windows, where they
have a menu button...

> * Window attributes... dialog: at least this part should definitely be
> off by default.

It's better than having things in a context menu, but hopefully users
shouldn't have to use it. If we decide to make these advanced functions
available, then we should have this dialog. Otherwise, I agree completely -
let it rest in peace.

> * Titlebar text: consider ellipsizing in the middle rather than at the
> end, for the same reason I suggested it for the task list earlier
> (many windows will have titles with an identical prefix and a unique
> suffix).

Sure. I've implemented ellipsizing at the end (though probably horridly
inefficiently) already - I'll have to look into this.

> * Confusing options: I think it's at least as important to remove more
> of these from the beginner level as it is to remove some from expert.

Indeed, it is far more important. With a good set of defaults, I don't see
why a beginner should have to change any settings. Perhaps they may want to
change their theme. Changing focus models or other such things would
probably qualify them as an intermediate user.

> * Option wording: I really like the suggestions included here. How
> about having even more specific suggestions instead of a general
> complaint about the wording?

Sure. I wrote a lot of the content at the end of the document late last
night and didn't get much of a chance to edit it or put in as much useful
information as I would have liked.

> Perhaps I can help patch Sawfish and the control-center with some of
> these suggested improvements if no one else is available to do it (a
> lot of them sound easier to implement than the Nautilus suggestions
> :-).

That would be greatly appreciated, thanks. :-)

>  - Maciej

--Kenny