karlton@decwrl.UUCP (02/24/87)
The X/V11 protocol allows one to build a window manager in another process that doesn't have this problem. Basically the protocol supports the notion of a window manager that wants to wrap some real estate around the application window. The window manager's user interface can then be implemented as user actions that happen there. The protocol even supports a tiling window manager. This allows you to have a consitent user interface across all your applications, as well as not have huge client binaries since all of the window manager functions don't have to be loaded with each client. It also means that the window manager does not have to "grab" buttons and make them unavailable to the applications. Of course, one does not have to use such a window manager. It is certainly not mandated by the V11 protocol. PK
gancarz@decvax.UUCP (02/27/87)
In article <> karlton@decwrl.UUCP (Philip Karlton) writes: ... > >This allows you to have a consitent user interface across all your >applications, as well as not have huge client binaries since all of the window >manager functions don't have to be loaded with each client. It also means that >the window manager does not have to "grab" buttons and make them unavailable >to the applications. > >Of course, one does not have to use such a window manager. It is certainly not >mandated by the V11 protocol. As Jim Gettys pointed out in his article on 'xmh', client binaries can be relatively small (for a virtual memory machine, anyway) because window management can be handled by a separate process. This is a big win, but I find the advantage described in the second paragraph to be an even bigger win for the user. There are at least 6 window managers written for X10 to date. At times, each one can be useful. The "wraparound" and tiled window managers that can be done under X11 will be desirable additions to the list. Still, there will be times when you will want to be able use several window managers in tandem. (Even those that grab buttons :-) All window managers must make trade-offs of one sort or another, and I can't see how one window manager can possibly meet everyone's needs. It might come close if it were big enough, but then see 'xwm' below. And besides, we must uphold the U*IX tradition of giving the user at least 20 different ways to do the same thing, and therefore 20 different ways to confuse him or her. For those who may be interested, here are the 6 window manglers that I know about and why they're useful: xwm - Small, efficient. Starts quickly. xnwm - Similar to xwm, but also provides window management functions in a pop-up menu or menu bar. Also starts fairly quickly. Can be configured so it doesn't use meta keys. uwm - Flexible meta key bindings. Offers slip-off menus that let you mix window management functions with shell commands and cut buffer operations. Invocation may be slow, depending on the size of your startup file. mwm - Uses no icons. Makes your screen look like a desk covered with sheets of paper. Moving the cursor into a window raises that window. Incredibly popular with certain groups of people. twm - Invokes window management commands at shell level. Useful for scripts and demos. Command syntax is a descendant of uwm's startup file syntax. ??? - I forget the name of this one, but it is essentially 'twm' with an 'xset'-like interface. Lets you do a variety of window management and user interface functions. Ideally, it should replace both 'twm' and 'xset'. There were other window managers in earlier versions of X, but most of them were never ported to X10. Please don't ask how to obtain them or any of those mentioned above. It's probably reasonable to assume that those above which acquire the greatest user followings will likely be available to everyone someday (some already are), but there are no guarantees. --Mike
faustus@ucbcad.UUCP (03/05/87)
The solution that I used with an xterm that I wrote was to make the mouse buttons configurable. It is possible in the .Xdefaults file to have an option of the form "xterm.Button.ShiftMetaLeft: Cut". This way you can distribute the functionality of your buttons any way you like. It also makes it reasonable to have more functions than there are button combinations for, and let the user pick the ones he wants. Another possibility is to restrict the wm functions to certain contexts. For instance, an unshifted click inside an icon can always mean "open". For this to work the wm will have to be able to forward events it doesn't need to the appropriate client, which may be a lot of trouble and too much overhead... Wayne
poepping@sei.cmu.edu (Mark Poepping) (03/06/87)
We had also modified uwm to select on the root window (not grab). However, we did it to depart from the "Magic Button" interface. We've got a lot of 'naive' users who long for a Macintosh style of interface (they wish they had borders). Our alternative is uwm with an unshifted button bound to a Window-Ops menu on the background. Of course, this scheme involves a lot more mouse movement than magic buttons. You need to: move mouse to background, pop up menu, select item, provide parameters if necessary... Of course, I still retain the meta-magic because I can remember three buttons, but most everyone else has been very appreciative of the simple-button menu interface. It has also aided in the programmer portability issue. Everybody leaves the default menu alone. I can go to my neighbor's machine, mouse to background, pop up menu..... just like at home. Of course, I couldn't leave well-enough alone. Puzzled as to why uwm (and xterm and others by the way) had its own menu implementation, I stripped it out and used XMenu instead. In addition, I (now called menuwm) allow extendable menus. So, this default menu pops up from the middle button on background. By default, the window operations pane is all you get, but you can add panes from your .menuwmrc. This helps the standards effort, makes it EASY for people to retain the default menu while still adding their favorite function. Troubles/Changes: - of course XMenu doesn't do color very well, uwm is much better, but I don't have color so I don't miss it. Besides, I like deck-of-cards stacking better than hidden-pane. - Only one real change to XMenu, to get it to place the menus wholly on the screen, it's annoying to have half your menu off the edge. - uwmrc syntax for menus was cleanly extended to allow the definition of multiple panes for a menu, in addition to allowing the addition of panes to existing menus. All in all, it's been a big help. Now if I only had a REAL drawing package, and a postscript previewer, and a netnews reader, and an applications description language... Mark Poepping