Re: [Usability] window manager configuration

[Gregory Merchan <merchan phys lsu edu>]

On Fri, Dec 07, 2001 at 06:25:05PM -0500, Havoc Pennington wrote:
> 
> Gregory Merchan <merchan baton phys lsu edu> writes:  
> > 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.)
> 
> Too experimental IMO to be relevant right now. I have no idea how all
> the details would work. I'm happy to see someone experiment with WM
> implementation and figure it out though.

"Once this is done . . ."  It hasn't been done yet. It will probably take time
and iterations with user testing.

I've attached two functions for sawfish which nearly accomplish part of the
paning operation. (They're still buggy.)

> > 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.
> 
> No-borders mode bad, IMO. It effectively disables the computer for
> many users if they accidentally turn it on.

Before sawfish allowed for compound functions to be done with the config tool,
I'd implemented it in my ~/.sawfishrc. The benefit of borderless mode is deep
screen edges. I'm not suggesting that my configuration be standard or even
readily available. I offer it as an example of something that might seem odd,
but that I find genuinely useful.

> If it exists this is a "powertweak" kind of option, not in the default
> control center. Of course Sawfish's current capplet gives us a free
> "powertweak" tool for it without doing any work.

I would have preferred to keep my scripts rather than using the config tool.
Some part of the code changed and for fear of having to maintain my scripts
I decided to use the config tool.

Incidently, there is an app called "powertweak" which deals with hardware.
(I think there's a gtk front-end to it also.)

> I believe the typical use-pattern a windows user would have on your
> small-screen system is to always keep their windows maximized, and use
> Alt+Tab or tasklist to move between them.

Maybe, but would he like it and might he find something else more to his
liking?

> > I use PointerRoot. I can understand click-to-focus. I've yet to grasp why
> > anyone uses sloppy focus; I'm interested to know.
> 
> Because unfocusing all windows when your mouse is over the desktop is
> just pedantic and not useful.

Pedantic? I don't understand how that applies at all.

I usually have the root covered by a window, such as Xchat right now. I tried 
sloppy focus, but since the panel does not accept focus I was often confused 
when I moved to it. Maybe on a larger screen I'd find sloppy useful.

> However I believe this may be one of those not-worth-fighting points,
> it's only about 3 lines of code to implement the third mode in the
> window manager.

The only thing I'm fighting about is the approach. I described my setup hoping
that it might show in part why some things are useful and not indicative of 
drug abuse.

OTOH, if someone decided that only click-to-focus mode or some other option
become a requirement, I might start fighting about that. More likely I'd
suggest that the person fork the project or start his own. X is basic enough
that it could be used to implement any GUI. If someone were so inclined he
might use it to make a MacOS GUI, but he'd have to make clear that he's using
X primarily as a hardware abstaction and not attempting to make an X desktop;
then he could ignore all the conventions, require extensions, require a
specialized OS, and require specialized hardware. He might even succeed.


Cheers,
Greg Merchan

;; pane-side-by-side
;; Takes two windows as arguments - one for the left, one for the right.
;; One way to invoke is:  (pane-side-by-side (select-window) (select-window))

(require 'sawfish.wm.windows)
(require 'sawfish.wm.state.maximize)

(define (pane-side-by-side wl wr)
  (define (resize-hpane w)
    (resize-window-to w (/ (screen-width) 2) (cdr (window-dimensions w)))
    (maximize-window-vertically w))
  (resize-hpane wl)
  (resize-hpane wr)
  (move-window-to wl 0 (cdr (window-position wl)))
  (move-window-to wr (/ (screen-width) 2) (cdr (window-position wr))))

;; pane-top-and-bottom
;; Takes two windows as arguments - one for the top, one for the bottom.
;; One way to invoke is:  (pane-top-and-bottom (select-window) (select-window))

(require 'sawfish.wm.windows)
(require 'sawfish.wm.state.maximize)

(define (pane-top-and-bottom wt wb)
  (define (resize-vpane w)
    (resize-window-to w (/ (screen-height) 2) (car (window-dimensions w)))
    (maximize-window-horizontally w))
  (resize-vpane wl)
  (resize-vpane wr)
  (move-window-to wt (car (window-position wl)) 0)
  (move-window-to wb (cdr (window-position wr)) (/ (screen-height) 2)))