rms@PREP.AI.MIT.EDU.UUCP (03/12/87)
One of the few ways the MIT Lisp Machine window system suspasses X is with its mouse help window. This is a line of text near the bottom of the screen which describes what the mouse buttons would do, given the current mouse position and the current modifier key status. It is possible for an individual program running under X to display its own mouse help, but most programs do not do so because there is no standard expectation that they should. Also, if each program does this independently, each window must allocate space for the purpose. The Lisp Machine has just one space which serves all the windows you have. That is much better, but only the server can decide which window's status ought to be displayed there at any time. In addition, help for button/modifier combinations that are grabbed should come from the grabbing program. Merging the documentation for grabbed buttons with the documentation from the current window's client for nongrabbed buttons can only be done by the server. Having a mouse help line makes it much easier to use an application program without a manual. It is worth a special feature in the protocol. Here is the feature I suggest: Have a command to associate with a window a set of triples button/modifier-status/text string. It should be possible to add, delete or replace individual triples. There are two classes of such triples: grabbed and nongrabbed. The two classes are independent; a window can have both a grabbed triple and a nongrabbed triple for the same button/modifier combination. Grabbed triples take precedence, but they can exist only for button/modifier combinations that are grabbed. When a combination is ungrabbed, any grabbed triples for it are deleted. The actual display of the mouse help window should be done by a client. This service might normally be provided by the window manager. To do this, the client program must be able to query the text associated with a button combination and the current mouse position. Then it could update the help window once per second, as is done on the Lisp machine. Immediate updating is also possible, but that requires an additional new feature: the client must receive events telling it when an update is required. This would be necessary every time the mouse enters or leaves a relevant window and every time a relevant modifier key state changes.
rms@PREP.AI.MIT.EDU.UUCP (03/12/87)
What's important for a mouse documentation line is that it exist as a standard user-level feature and that the application programs use it. General window properties as a mechanism are a good idea, but it is not enough to provide a mechanism that can be used to implement a mouse documentation line. The mouse documentation window has to be a standard feature so that application implementors will see the worth of arranging to provide the information for it.
RWS@ZERMATT.LCS.MIT.EDU.UUCP (03/12/87)
We are in complete agreement (I think). All I was saying is that no change to the protocol is required to support what you (and I) want. What is required at a minimum is for someone to propose the property-related information and policies to standardize on. What it takes to really make things happen is for someone to volunteer to write a client that will create and control the documentation window, and to contribute interfaces (and implementations!) for C routines to exist at the Xlib or Toolkit level to make it convenient for applications to define documentation. I don't think anyone would object if you or your organization volunteered. Despite how wonderful and important I think the idea is, the reality is that there are only finite resources presently committed to getting the base V11 implementation out the door on schedule. Other people are going to have to contribute if they want to see their favorite policies incorporated.
KK%sierra@ti-csl.CSNET.UUCP (03/12/87)
This is a good notion. The Lisp machine mouse documentation window is certainly a useful feature. As you suggest, this deserves to be implemented as a single resource shared by all clients. Still, I think it's healthy to maintain a conservative attitude toward protocol extensions. So, it's worthwhile considering how the mouse doc feature could be implemented within the existing protocol. Here's one approach; in fact, it follows from the suggestions in your previous proposal. It relies upon the services of a window manager client. The basic ideas are: 1. The mouse doc window is created and "owned" by the window manager. 2. Each client is responsible for displaying its own mouse doc info (if any) in the mouse doc window. Although the server could know when and how to do this, it is certainly true that the client itself has this knowledge. The window manager would be responsible for communicating the mouse doc window id to each client, via a pseudo-event message. Note that this scheme may mandate a particular style of window manager, i.e. one that is aware of the initiation of client programs. I imagine that the window manager might also communicate a default mouse doc string, which could be redisplayed when the client's string is removed. As for the requisite client-side processing, I envision this as a toolkit-style package. The client would be responsible for selecting mouse entry/exit events for all mouse-doc'ed windows. The mouse doc tool would provide for registering associations between client windows and doc string quadruples (button /modifiers /grabbed-string /ungrabbed-string) and for preprocessing mouse entry/exit events and displaying the correct mouse doc string (of course, such events would not be consumed and would be passed along for further client processing). The mouse doc tool could also provide a special interface to grabbing/ungrabbing in order to maintain the correct status of each window's mouse doc quadruples. Beyond its use of standard X protocol, this approach has an additional advantage of efficiency: no transaction between client and window manager/server processes is needed to change the mouse doc window. Likewise, periodic polling of the mouse position would not be required. However, this method does not provide for changing the mouse doc string when a modifier key changes -- say, when the the shift key is pressed. This represents an argument, albeit a minor one, in favor of changing the X protocol to communicate modifier key events.
rms@PREP.AI.MIT.EDU.UUCP (03/13/87)
There are several serious problems with that design: 1. It requires the window manager to know about creation of clients. 2. It requires clients to handle mouse enter/exit events and do complicated things. 3. It does not work at all for grabbed buttons. The individual clients to do not know what buttons are grabbed by other clients (including those grabbed by the window manager) and would not know what documentation to give for them even if it did know they were grabbed. 4. Because in X the modifier keys always drastically affect the meaning of the mouse buttons, a mouse documentation window that fails to deal with them is a failure. I think that design does not work.
rms@PREP.AI.MIT.EDU.UUCP (03/13/87)
My experience tells me that it is hard just fitting explanations of three buttons onto a line of text. I have seen programs that change this line according to the modifiers currently pressed, and it works well. You are arguing that a certain technique is ok because you don't see any problems. However, it is just a gedanken experiment. The fact that problems don't seem like much in a gedanken experiment doesn't count for much. I hope people won't be lulled by this into thinking that the problems aren't there.