Re: Some thoughts about window management

[Yaron Tausky <decaycell gmail com>]

On Thu, 2005-06-23 at 02:56 +1200, Matthew Thomas wrote:
> Yaron Tausky wrote:
> > 
> > On Mon, 2005-06-20 at 17:00 +0300, Yaron Tausky wrote:
> >>
> >>1. The context menu for tasks in the taskbar is not very helpful. Most
> >>of the functions it offers are rarely used (rollup, anyone?), even
> >>though it's the best place to put the most used ones, since it's always
> >>accessible (as the panel is always visible). I suggest that some sort of
> >>API would be implemented to allow the application developers to add
> >>app-specific functions to that menu, and put all the window management
> >>stuff under a "Window management" submenu.
> >...
> > http://www.geocities.com/decaycell/mockup.png
> 
> 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.

> And with the Gaim example you show, there's the problem that it's
> duplicating items that are already in the panel applet menu. If your
> mouse pointer is in the middle of the screen, which do you go for -- the
> panel applet menu, or the window list menu? Dither, dither ...

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). 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). 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".

> Also, how would this work with the "Window Grouping" preferences?

Just as it works without it, I guess -- the current menu structure
simply adds the individual menus as sub-menus of the group button.
However, the window list shouldn't group button and icon windows
together, as usually the main app window is represented by the icon, and
child windows are buttoned (e.g. Gaim buddy list and chat windows).

> I agree on getting rid of the "Roll Up" item, though. The use case for
> rolling up is to temporarily get a window out of the way so you can see
> what's behind it. If you're near the window list, minimizing and
> restoring does the same thing, much more quickly, so there's no point in
> having Roll Up in the menu.

The only usable way to implement window shading, IMHO, is by scrolling
on the title bar (at least that's how it works for me). I used to use it
a lot on XFce, but never used it after moving to GNOME.
-- 
Yaron Tausky <decaycell gmail com>