Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!ti-csl.CSNET!KK%sierra From: KK%sierra@ti-csl.CSNET.UUCP Newsgroups: comp.windows.x Subject: Re: Mouse help window Message-ID: <2751554486-9385756@Sierra> Date: Thu, 12-Mar-87 11:41:26 EST Article-I.D.: Sierra.2751554486-9385756 Posted: Thu Mar 12 11:41:26 1987 Date-Received: Fri, 13-Mar-87 22:06:18 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 44 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.