Re: [Usability] window manager configuration

[Gregory Merchan <merchan phys lsu edu>]

On Fri, Dec 07, 2001 at 01:23:09AM -0500, Havoc Pennington wrote:
> 
> Hi,
> 
> Today's questions from me are:
> 
>  - which window manager options are not crack-ridden bogosity?
>  - which crack-ridden bogus options do you have to offer 
>    despite their bogosity, since people are grumpy?

This is a bad way to approach this. Accusing users of drug abuse does not
solve any problems. Research and reason are better guides.

What can existing window managers do?
For each answer:
  Why was this function created?
  Why is it used?
  How is it used?
  Is there a better way to satisfy the user's purpose?
  What interfaces are provided for this function?
  What interface is best for this function?

Once this is done there may be things yet unseen that should be available
and it might be worthwhile to find them. Window-in-window MDI applications
provide some functions that I've not seen (by default) in any window manager,
such as the ability lay two windows half-maximized and side-by-side and use
a pane handle to shift the allocation. (Think of HTML frames.)

> Here is my list of options that are probably reasonable:
> 
>   Titlebar font size
>   Titlebar font family
>   Number of workspaces (once you assume workspaces are OK ;-)
>   Name of each workspace
>   Current theme ("border style") (theme doesn't include the font, just the 
>                                   frame appearance)
>  
> Here are some possible options for the "advanced" tab:
> 
>   Keybindings use Alt (MOD1) vs. Windows/Meta key (HYPER/SUPER)
> 
>     (I hate this one, but basic deal is that the Windows key is
>      better, if it exists, but often it doesn't - I'm not sure trying
>      to autodetect this is a good idea since it'll result in
>      inconsistency, so I think Alt by default, but the option to
>      switch to Windows key for people that want to reduce keybinding
>      conflict issues with legacy apps)
> 
>   Custom keybindings in general 
> 
>     (I hate this too, but realistically people need to work around
>      applications; on Windows the long-standard navigation keybindings
>      mean that apps never conflict with them. Also, people hate to
>      re-learn keybindings, and you just can't fight the system.)

I have one of the more unusual configurations I've known. I have a laptop
with an pencil-eraser-like mouse in the middle of the keyboard, and a small
(800x600 10.4") screen. It's hard to accidentally move the mouse and screen
space is precious.  I use focus-follows-mouse mode and my window frames (when
present) are a one-pixel blue border. The functions that are ordinarily
accessed from a title bar I access through keybindings; when I need to see
the title of the window I use the tasklist applet. For maximized windows I
remove even that one-pixel border; I only use it so that text does not bleed
between windows.

These are the keybindings I have:

Global:
                     Menu   Show/Hide panels
 Meta               +Home   New Terminal
 Meta               +Esc    Popup root menu       (rarely used)
 Meta               +Menu   Popup window list     (very rarely used)
            Ctrl+Alt+Left   Move viewport left
            Ctrl+Alt+Right  Move viewport right
            Ctrl+Alt+Up     Move viewport up      (bound but not used,
            Ctrl+Alt+Down   Move viewport down      workspace is 4x1)
                 Alt+Tab    Cycle windows

Window:
      Shift+Ctrl+Alt+PgUp   Toggle vertical maximization
      Shift+Ctrl+Alt+PgDn   Toggle horizontal maximization
            Ctrl+Alt+PgUp   Unframe and maximize
            Ctrl+Alt+PgDn   Unmaximize and frame
      Shift+Ctrl    +PgUp   Raise
      Shift+Ctrl    +PgDn   Lower
 Meta               +Pause  "Iconify" (I've yet to see an icon ;-)
                 Alt+Space  Popup window menu.
                 Alt+F4     Close

I move windows with Alt+Button1Move and resize them with Alt+Button3Move.

You can try this yourself, but it probably won't make any sense unless you
have hardware like mine.


>   Click-to-focus/sloppy focus (follows mouse?)

There are three now common focus methods:
 Click-to-focus
 PointerRoot    (a.k.a., focus-follows-mouse, enter-exit focus)
 Sloppy         (a.k.a., enter-only focus)

I use PointerRoot. I can understand click-to-focus. I've yet to grasp why
anyone uses sloppy focus; I'm interested to know.

>   Stuff from "Actions" tab in KDE window behavior control panel:
> 
>     titlebar double-click maximizes vs. shades?
>     titlebar single-click actions for buttons 1/2/3?
>     first click action for buttons 1/2/3? (pass through first click?)
>     Alt+click action for buttons 1/2/3?
> 
> Options I hate a lot but people probably want:
> 
>   Maximize covers panel or not
>   Panel is on top vs. below vs. raise-on-mouseover/focus
> 
> Sound about right?
> 
> What is the control panel (or panels) called that contains these
> items?
> 
> Havoc