🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.windows.x
Article #25087

Mouse help window

#25087
From: rms
Date: Wed, 11 Mar 1987 22:56
49 lines
2949 bytes
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.
Technical Details
Message-ID: <8703112256.AA02851@prep.ai.mit.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!PREP.AI.MIT.EDU!rms

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!PREP.AI.MIT.EDU!rms
From: rms@PREP.AI.MIT.EDU.UUCP
Newsgroups: comp.windows.x
Subject: Mouse help window
Message-ID: <8703112256.AA02851@prep.ai.mit.edu>
Date: Wed, 11-Mar-87 17:56:33 EST
Article-I.D.: prep.8703112256.AA02851
Posted: Wed Mar 11 17:56:33 1987
Date-Received: Fri, 13-Mar-87 02:04:25 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 49