[Usability] Window List (not the applet)

[Gregory Merchan <merchan phys lsu edu>]

GNOME does not have an interface to manipulate groups of windows, except
the Show Desktop button. There is no way to tile or cascade a set of windows.

MS Windows provides tiling and cascading from a right-click menu near
the window buttons on its taskbar. It seems to affect all visible windows,
though I'm not sure how which are selected.

OS/2 featured a Window List when both mouse buttons (a.k.a., Button 2 or
the middle button) were clicked on the desktop or Ctrl+Esc was pressed.
With it, the user could perform operations on a single window or a
user-selected set of windows.

Here is a screenshot of a window similar to the OS/2 window list:

  http://www.phys.lsu.edu/students/merchan/shots/WindowList.png

OS/2 users will immediately recognize some differences, surely.
I'll address those before going on to describe the rest. I last used Warp3,
so I'm basing this off a screenshot of Warp4's window list and my
recollection. Here's the screenshot:

  http://www.contact.net/os2/TOUR/01.gif


Differences between Warp4's window list and the proposed window list
--------------------------------------------------------------------
One obvious difference between GNOME and OS/2 (and Windows) is that GNOME
has workspaces. (Though, I believe extensions provide these on OS/2 and
Windows.) Because workspaces group windows, a tree is better than a
simple list for representing the state of the environment.

GNOME has a separate Run dialog, so including a command line here would
just be clutter.

OS/2 had some features which are not obvious, useful, or existent in GNOME.
One of these is window hiding as a user perogative. Hiding removes a window
from both the screen completely, leaving no minimized or iconic
representation. Because GNOME doesn't have this, there are no Hide or Show
buttons in that screenshot.

A GNOME control panel has a Close button that closes it. Providing a Close
button in the window list for closing the selected window would be confusing.

Windows in GNOME are not object views, so a Settings button would be
meaningless even if it could be implemented.

I left out the Help button because it didn't seem necessary here and the
interaction model (described in a moment) makes it odd.

Warp4 seems to allow only horizontal tiling. Where they have one button,
I've put two: one for each horizontal and vertical tiling.

I don't know what the Filter button in Warp4's window list does.

I can't tell from the screenshot whether Warp4 had the right-click menu
for listed windows that Warp3 had.


Details of the proposed window list
-----------------------------------
The list will be shown in response to clicking mouse button 2 or
pressing Ctrl+Esc. It may also be available from a menu or a launcher.

The list is modal. The mode is left by completing an action, focussing
another window, or pressing Escape. All of these close the window, as
does using the close button. The list is not so useful that leaving it
visible until explicitly closed would not be an impediment.

The list will be on top of all windows when shown. It would be an unhelpful
redundancy to include the window list's window in any list of windows, so it
will not be shown in the window list applet, the pager, or similar items.

The first-ever-run size of the window will be about one third the screen
width and one half the screen height. The first-ever-run position should
be the center of the screen.

It can be moved and resized, and possibly rolled up. Rolling up, as treated
by the HIG, is a quick way to get a look at what's under a window. That's
why it's to be supported for almost every window. Its size and position
will be maintained across invocations. Its _NET_WM_WINDOW_TYPE is
_NET_WM_WINDOW_TYPE_UTILITY.

Spacings:
  12px around the content of the window.
  12px between the list and the buttons below it.
   6px between the buttons

The list will have scrollbars if and only if the content exceeds the visible
area.

The branch of the current workspace will be expanded when the list appears.
Those of the other workspaces will be collapsed. The scroll position, if
needed will be such that the current workspace branch is visible.
Branch state is not preserved across invocations, because: the list is
likely to change between invocations, the visibility of the current
workspace branch can't be guaranteed if branch state is preserved, the
number of workspaces may also change.

Within each branch, windows will be listed in initial mapping order.

Windows omitted from other lists and pagers will be omitted from the list.

Multiple windows can be selected simultaneously.

When the window is resized, to fill the given space:
  the area of the list will grow in height and width,
  the buttons will grow in width, but not height.

The button sizes will be homogeneous.

Actions:  All of these leave the mode, thus closing the window list window.

  Double-clicking in the list will focus a window or switch to a workspace.

  Dragging windows to another workspace will move windows to that workspace.

 For these actions, at least one window must be selected.

  Minimize and Maximize perform their normal operations on all selected
    windows.

  Restore will unminimize or unmaximize all selected windows.

 These next actions are only available when two or more windows on a
   single workspace are selected.

  Cascade will place the earliest mapped selected window near the top-left
    corner of the screen, then the next earliest down and to the right of
    it, and so forth. The distance between the top-left corners of windows
    (to be determined) will be constant. The stacking order for these windows
    will be their initial mapping order, with the earliest mapped window
    below all the others. When the positions are too far down and to the
    right to be useful, the cascade will start again from a position near
    the top-left corner of the screen, but adjusted to not completely
    overlap any other cascaded window.

  Tile Horizontally will move and resize windows so they fill the screen
    from left to right. Each window will grow to maximum height. The width
    of each window will be changed, within hint constraints, so that every
    is nearly the same width. Horizontally order will be preserved as
    windows are moved into position; the left-most window will still be
    the left-most window after tiling. When window sizes do not permit
    exact tiling, a small overlap is permitted, but a small gap is not.

  Tile Vertically acts like Tile Horizontally with directions and dimension
    changed appropriately.



Implementation Problem
----------------------
There is no standard window manager message to tile or cascade windows.


Cheers,
Greg