solomon@GJETOST.WISC.EDU.UUCP (02/21/87)
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.
rusty@weyl.Berkeley.EDU.UUCP (02/23/87)
In article <8702211303.AA01735@gjetost.wisc.edu> solomon@GJETOST.WISC.EDU (Marvin Solomon) writes: >... > >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. That scares me. Wouldn't we then have the problem that suntools has where the suntool binaries are huge? On my sun 3/50 the suntools program itself is 728 blocks and the various other tools that run under suntools are 952 blocks. Yuck. How about setting up some sort of standard? For example, all window managers must use control+shift when the mouse is in a window or an icon, and when it's in the background the control+shift is optional. -------------------------------------- rusty c. wright rusty@weyl.berkeley.edu ucbvax!weyl!rusty
wohler@sri-spam.UUCP (02/23/87)
In article <8702211303.AA01735@gjetost.wisc.edu> solomon@GJETOST.WISC.EDU (Marvin Solomon) writes: >What's the solution? for applications to be cognizant of uwm and vice-versa. i agree, the key bindings can be confusing. >For example, have sensitive areas on borders of >windows that can be used to resize them; please, no! not having to go to the namestripe or border is one of the features that makes x a "faster" system than suntools. --bw
jef@ucbvax.Berkeley.EDU@charming.UUCP (02/23/87)
I agree with Marvin Soloman's concerns about collisions between uwm's use of mouse commands and various applications use of same. But it's more than just that. The general problem is that there just aren't enough different mouse commands, so of course there will be collisions. Now I can understand why multi-click type commands are not implemented (the timings would have to be interpreted in the server, complicating the protocol). But what about chords? Last time I played with uwm, it couldn't handle chord-style commands. I don't see any fundamental reason why not -- it's just a matter of programming, isn't it? --- Jef
don@BRILLIG.UMD.EDU.UUCP (02/24/87)
Date: 23 Feb 87 19:44:43 GMT From: cartan!weyl.Berkeley.EDU!rusty@ucbvax.berkeley.edu (Rusty Wright) In article <8702211303.AA01735@gjetost.wisc.edu> solomon@GJETOST.WISC.EDU (Marvin Solomon) writes: >... > >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. That scares me. Wouldn't we then have the problem that suntools has where the suntool binaries are huge? On my sun 3/50 the suntools program itself is 728 blocks and the various other tools that run under suntools are 952 blocks. Yuck. How about setting up some sort of standard? For example, all window managers must use control+shift when the mouse is in a window or an icon, and when it's in the background the control+shift is optional. -------------------------------------- rusty c. wright rusty@weyl.berkeley.edu ucbvax!weyl!rusty I see just the same problem with XToolKit. I would like to see the ToolKit as a client that you would normally run on the same machine as the server, for speed. Interactive widgets would be much more interactive, you wouldn't have to have a copy of the whole library in every client, and there would be just one client to configure. The big question is how do your clients communicate with it? Are the facilities in X11 sufficient? Or would it be a good idea to adopt some other standard for communication between clients? At the X conference, it was said that the X11 server should be used by clients to rendezvous with each other, but not as a primary means of communication. Why is that? Setting a standard on any kind of key or mouse bindings would be evil. The window manager should be as transparent as possible. It solves lots of problems for it to be able to send any event to the clients. For example, how about function to quote an event that the window manager would normally intercept, and send it on? Perhaps the window manager is the place to put the ToolKit? -Don
ken@hpcvlo.UUCP (02/24/87)
> 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". Another fix is to make uwm obey it's own conventions. For example specify that an event should be handled by uwm in a root only context. Then have uwm respond to this event only when the mouse is over the root window, and let the other applications get this event first when the mouse is over their window. We made this change to uwm, and everyone in our area is running the modified uwm. It works fine. We added a total of 30 lines of code to uwm in scattered places. If anyone wants these changes I will be glad to submit them in some appropriate form to an appropriate place, (or perhaps set up an anonymous ftp?). For example here is an except from my .uwmrc file that allows me to use the left mouse button to circle_up windows, without stealing the left mouse button from application windows. With a slightly modified uwm the left mouse button as set here is context sensitive with respect to the mouse position. A left mouse button on the root window will circle up, and a left mouse button on an icon or window is ignored by uwm to be handled by the application. f.raise = meta : w|i :left down f.circleup = meta : r :left down f.moveopaque = meta : w|i :left delta f.iconify = meta : w|i :middle down f.circleup = : r :left down -Ken Bronstein hp-pcd!ken
glennw@hercules.UUCP (02/26/87)
I have done the same bug fix to UWM to prevent it from stealing button combinations from applications just to get that button over the root window. The change is simple, mainly in uwm.c, but in Menu, Move, MoveOpaque, NewIconify, and Resize all calls to XGrabButton and Grab must be replaced by XGrabMouse and XUngrabMouse. On window manager architectures, I believe that 1. X default user interface policies need to be better thought out and agreed on. 2. Willy-nilly expansion of chording, multiple clicks, and other complex ways to give selection input will make X user interfaces impenetrable. Therefore making 1. happen is imperative. 2. A separate window manager process is necessary to use the V11 facilities to pull inconsistent application mouse usages into consistency (via sending events) and the give users control of their user interfaces. But the overhead of this redirection means it needs to be used sparingly, therefore 1. is still necessary. 3. An "external model" UI that owns the V11 widgets for integrated applications is the way to go. How this piece plays with the window manager is an interesting architectural question. ----------- 692a693 > char NeedRootInput=1; 695c696,713 < Grab(bptr->mask); --- > if ((bptr->context & (WINDOW | ICON | ROOT)) == ROOT) > /* don't grab buttons if you don't have to - allow application > access to buttons unless context includes window or icon > The rest of uwm must be careful to only use GrabMouse! */ > { > /* instead, select input on the root window */ > if(NeedRootInput) > { > XSelectInput(RootWindow, EVENTMASK); > NeedRootInput = 0; > } > } > else > { > /* context includes a window, so must grab */ > Grab(bptr->mask); > } > ----------------------- < old Move, > new Move 2c2 < static char *rcsid_Move_c = "$Header: Move.c,v 1.3 87/01/23 07:56:03 glennw Exp $"; --- > static char *rcsid_Move_c = "$Header: Move.c,v 1.4 87/02/10 13:25:45 glennw Exp $"; 72c72 < * Change the cursor. --- > * Change the cursor and grab the mouse even if button already down. 74c74,75 < status = XGrabButton(RootWindow, ArrowCrossCursor, mask, EVENTMASK); --- > status = XGrabMouse(RootWindow, ArrowCrossCursor, EVENTMASK); > 76c77 < Error("Move -> Unable to grab button and change cursor."); --- > Error("Move -> Unable to grab mouse and change cursor."); 166c167 < Grab(mask); --- > XUngrabMouse(mask); 190c191 < Grab(mask); --- > XUngrabMouse(mask); -- Glenn Widener
len@geac.UUCP (Leonard Vanek) (02/27/87)
In article <9884@sri-spam.istc.sri.com> wohler@sri-spam.UUCP (Bill Wohler) writes: > >>For example, have sensitive areas on borders of >>windows that can be used to resize them; > > please, no! not having to go to the namestripe or border is one of > the features that makes x a "faster" system than suntools. > I second that! I am not familiar with Suntools, but I find Macintosh windows hard to use because the Mac requires such precise mouse positioning to get at the correct control in the window borders or to get at part of the information near the edge of the window. I often end up moving windows when trying to close them. Also, controls in the borders waste space on the screen. Len Vanek Geac