Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ucbvax!GJETOST.WISC.EDU!solomon
From: solomon@GJETOST.WISC.EDU.UUCP
Newsgroups: comp.windows.x
Subject: Re:  Uwm extensions, perhaps?
Message-ID: <8702211303.AA01735@gjetost.wisc.edu>
Date: Sat, 21-Feb-87 08:03:22 EST
Article-I.D.: gjetost.8702211303.AA01735
Posted: Sat Feb 21 08:03:22 1987
Date-Received: Sat, 21-Feb-87 19:38:15 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 48

I agree that moving the mouse while holding down some of its buttons
can be awkward, but my biggest problem with uwm as well as other
utilities (particularly xterm) is the use of "inflected" mouse buttons
(mouse hits while shift/control/lock/meta keys are in force).  The
problem has been compounded with all the new goodies in xterm.  In my
opinion, it's not so much a problem with the implementation of uwm, but
with the kinds of user-interaction conventions that are starting to gel
in the X environment.  These, in turn, seem to come from the whole idea
of a separate "window manager" process and from the X notion of
"grabbing".

Here's an example of the problem:  Suppose I want to use the right
mouse button to raise windows.  Then I can't use the right mouse button
to talk to any application, since uwm grabs it "first".  Fortunately,
uwm lets me specify an inflection.  I know V10R3 xterm uses the "shift"
inflection for its own purposes, so I decide to use control/right/up
for f.raise.  Now along comes V10R4 xterm with its snazzy new scroll
bar and scroll button.  Xterm wants to use control/right/scroll-button
to mean "end of buffer".  So I better change my .uwmrc.  I have to (1)
go to the trouble of finding a combination of inflections (say
control/shift/right) that won't conflict with each other or with any of
the applications I may want to use, (2) retrain my fingers to use the
new conventions, (3) never let anybody else sit down at my workstation
and do something while I'm logged in, since his conventions are bound
to be different, and (4) hope and pray that the next application to
come around won't want to use control/shift/right for its own
purposes.

What's the solution?  I think it is to get rid of the idea of window
manager as a separate process, and build "window-manager" functions
into all windows.  For example, have sensitive areas on borders of
windows that can be used to resize them; have "lower" and "iconify"
icons in the title bar; and so on.  Xterm is already doing this to some
extent (see, for example, auto-raise).  Of course, this approach leads
to new problems:  *Every* application has to provide the features.
Lazy programmers may not provide them, and fancy (irresponsible?)
programmers may decide to present the same function in different ways.
The result would be windows that can't be moved, or windows that can
only be moved by a control/meta/lock/right hit 17 pixels to right of
the upper-left corner.  There's no way to prevent this phenomenon
altogether, but it can be minimized by provision of a good, easy-to-use
tool library.  The library should be called in by default (or built
into the server),  and should provide certain functions (say raise,
lower, iconify, move) by default.  Still better would be an
object-oriented approach with inheritance of methods.  Exploration of
that idea deserves much more space than I can devote to it here.  Just
let me point out that the current situation is exactly backward:  The
uwm binding of buttons overrides the application-specific bindings.