Re: [Usability] window manager configuration

[Havoc Pennington <hp redhat com>]

Jeff Waugh <jdub perkypants org> writes:
> 
> I'd suggest that what Sawfish refers to as 'viewports' is "the one thing
> that we have that works correctly".
> 
> For instance, I can set a key combination to change viewports (M-Left and
> M-Right to go left and right), and a similar one to change viewports taking
> the current window with me (C-M-Left and C-M-Right).
> 
> I can't do that with workspaces. They're designed to *not* be coherent parts
> of a larger work area, which seems less sensible for our final choice.
> 

I haven't thought about this all that carefully and I can't sleep
right now so I'll think out loud. ;-)

Traditionally viewports have a geometric relationship to each other so
they have the arrow key bindings, but you could also pretend the
desktops have a geometric relationship and implement arrow keybindings
for those. That's what KWin does.

I'll use the terminology from the WM spec, which is:

  - desktop: a conceptual area in which windows may be placed, 
             perhaps larger than the screen. a "virtual screen" - 
             imagine a stack of screens you can switch between.

  - viewport: a screen-sized window onto a desktop. Imagine 
              the desktop larger than your monitor, and 
              your monitor is the viewport; you move the desktop 
              around to see different bits of it through the monitor

So the fundamental thing that distinguishes a desktop from a viewport
is that if a window is only partially visible on a viewport, you would
expect the rest of the window to be visible on the adjacent
viewport. While for a desktop, if a window is partially off the
desktop, it's off the screen and simply truncated.

Implementation-wise, KWin and Metacity have desktops that are always
the same size as the screen, and each desktop has a single viewport
which is the same size as the screen/desktop. So the viewports
technically exist but are completely irrelevant.

AFAIK Sawfish has desktops which can be any multiple of the screen
size, and you can move the viewport to any of the grid positions
(i.e. if your desktop is 3x3 screens in size, there are 9 viewport
positions allowed). In principle a window manager could have an
arbitrarily-scrollable viewport instead of the predefined grid of
possible viewport positions. Also in principle a window manager could
have desktops that weren't a multiple of screen size.


The user-visible concept is "workspaces" and could refer to either
desktop or viewport. IMO the user should never need two different
words (desktop/viewport), because they should never end up with
multiple desktops each containing multiple viewports - way too
complicated.

You could imagine a config option that changed whether the workspaces
numbered 1-4 in the pager are 4 screen-sized viewports onto one big
desktop, or 4 screen-sized desktops, but I have no idea what you would
call that option. Both would be similarly-represented by the pager,
again the main visible difference is whether a window can overlap more
than one workspace. The default for this hypothetical config option
is the main UI question here. No I don't think the option should
actually exist. ;-)


The viewport concept seems easier to explain in one sense (you have
one big screen and can look at 4 parts of it), but some other things
don't make sense (you have to pretend the panel is "stuck to the
glass" to explain its behavior). Desktops have a straightforward
conceptual explanation too; you have 4 "screens" and can move between
them. Of course both of them are too complicated for many users
anyway...


The pager we have in the GNOME 2 panel right now will get totally
confused by viewports, btw, because I didn't implement any support for
them yet. ;-) Also it allows the desktops to be layed out in different
ways (in a single row, in a grid), which of course has issues with the
geometric keybindings. Waldo from KDE has suggested on wm-spec-list
that the pager should tell the window manager about its current layout
so the WM can do the right bindings. GNOME has an issue KDE doesn't
there though, which is that you can start up multiple pagers with
different layouts - and then you're pretty much doomed on geometric
keybindings.

I think left/right arrow key bindings are probably OK even if you
don't define geometry, since they can be interpreted as simply
"next/prev workspace."

Havoc