Re: Some thoughts about window management

[Matthew Thomas <mpt myrealbox com>]

Yaron Tausky wrote:
> 
> On Thu, 2005-06-23 at 02:56 +1200, Matthew Thomas wrote:
>...
>>The main problem with this is that most programs would not add extra
>>items to their menu, either because they didn't need to, or because
>>their developers didn't get around to it because it was a near-invisible
>>feature. So in most cases, you'd have a menu where *most* of its items
>>(the window management items) were in a submenu, which would be very
>>strange.
> 
> This problem is easily solved by using the default menu when the
> application doesn't specify any entries of it's own, and using the
> sub-menu when it does. Furthermore, we could set a threshold -- one or
> two app-specific items will be added to the default menu, but three or
> more will move the window functions to the sub-menu.

But that breaks your muscle memory. You remember that (for example)
Maximize is the fifth item up, so you right-click and move up five
items, click, and ... you've just opened the "Accounts" window by
mistake (in the Gaim example).

Better, I think, to add the app-specific items above the window
management items, and leave the window management items where they are
no matter how many other items there are. With the existing window
management items that could lead to a long menu. But that could be
solved by removing most of them, since most of them only make sense if
you can see the window anyway, and if you can see the window anyway it's
much more obvious to access them from the window frame's menu instead.
The only items that need to be in the window's window list menu are
those which help you if you don't want someone peering over your
shoulder to see the window while you hide it: Minimize and Close.

>...
> The idea is to use this function with my other proposition (i.e. adding
> a WM hint that creates an icon-only window button) in order to REPLACE
> the software-provided notification area icon. Many people (including me)
> consider docking applications to the notification area an ugly hack that
> should be solved (this problem also exists in Windows, and I suspect we
> accidentally ported it to UNIX desktops by copying the way Windows
> handles these things).

True. Same goes for window management items in the window list menu, I
suspect. :-)

> This hack is a huge usability nightmare -- just
> compare the ways Gaim, Muine and Rhythmbox handle left/right-clicks on
> their icons, or closing their window (Gaim continues to run in the
> notification area, the other two just quit).

Agreed. In the absence of an accurate definition of the area (it's
called a "notification area" but it's too small for understandable
notifications, which is why Windows 2000+ has to sprout balloons from it
all the time, and the most useful uses of it aren't notifications
anyway), and with a too-flexible API, it has become a free-for-all.

> Implementing my ideas --
> subject to discussion and modification, of course -- would result in
> these apps providing the same functionality, with the added bonus of
> standard behaviour (and thus better usability) and simply "doing it
> right".
>...

Good. There are other ways you could make it consistent, too. For
example, you could require that all status applets be buttons that
respond to single left clicks. Or you could take the OS X +
MenuExtraEnabler approach, and require that all status applets be menus
(with some extension of what's allowed inside a menu, so for example a
volume slider could be inside an Audio menu, and a search field inside a
Beagle menu). Since for technically minded people the window list is
often crowded, it might be better to choose such an approach that didn't
require status applets to be sharing the same space as the window list.

-- 
Matthew Thomas
http://mpt.net.nz/