🚀 go-pugleaf

In article <PIERSON.91Jul1163832@xenna.encore.com> pierson@encore.com (Dan L. Pierson) writes:
> The last feature allows for a fairly simple Motif solution: write a
> Motif-based menu server.  The Epoch community (and much of the X11
> community) would be grateful if someone would release such a tool for
> public use and study.

This has already been done, and it works nicely -- A Motif menu server
(WINTERP/Xmu) was posted to the WINTERP mailing list by Richard Hess
(Consilium, Inc):

| To: uunet!hplabs!hplnpm!winterp@uunet.UU.NET
| Subject: FYI... [ WINTERP-based menu server ][ BETA ]
| X-Mailer: mh6.6 [ GNU mh-e ]
| Date: Wed, 08 May 91 15:50:31 -0700
| From: Richard Hess <cimshop!pleione!rhess@uunet.UU.NET>
| 
|   The following shar file contains the "beta" release of a WINTERP-based "menu
| server" which I've been working on.  The release includes;
| 
|   -- a WINTERP src-server patch...  [ new WINTERP primitive ]
|   -- initialization and library files for WINTERP...  [ menu server specific ]
|   -- a sample app-defaults file for the menu server...
|   -- several shell scripts which start/stop/query the menu server...
|   -- a GNU Emacs interface to the menu server...  [ plus examples ]
|   -- a Perl interface to the menu server...
| 
|   The menu server allows the user to create menu's in a "menu cache" and then
| pop them up when need by calling the server with the menu's "key".  This
| allows for the creation of a collection of re-usable menus for such things as
| command menus in GNU emacs or menu driven shell scripts.  Any menu in the
| server can be accessed thru either the GNU or Perl interface (you just need to
| know the menu's "key").

The "GNU Emacs interface to the menu server...  [ plus examples]" mentioned
above will be of particular interest to epoch and gnuemacs users. After
loading the *.el files, you can do M-X "xmenu-buffer-select" to pop up a
WINTERP/Motif menu with all the buffers you've previously visited in your
gnuemacs editing session. Select a buffer name with mouse button 3 and that
buffer will pop up in gnuemacs. Calling "M-x xmu-demo" will show you how to
build a hierarchical menu in WINTERP/Xmu, and demonstrate how picking an
item on the menu will send a message back to emacs.

Hess' menu server code will be released as part of the WINTERP "contrib"
section in an upcoming release (WINTERP 1.13). For those who want to try
out the current version, send mail to mayer@hplabs.hpl.hp.com and I can
mail you the current menu server code as a shar file. You'll also need
Motif 1.0.x or 1.1.x and WINTERP itself, which is available via anonymous
ftp from export.lcs.mit.edu, dir contrib/winterp, file winterp-1.12.tar.Z;
alternately, to receive WINTERP sources by e-mail, send a message to
winterp-source@hplnpm.hpl.hp.com (or hplabs!hplnpm!winterp-source) and
you'll receive 1.5 Megabytes of source, examples, and documentation as
approx 100 separate messages.

From: pierson@encore.com (Dan L. Pierson)
>
> [gwm menu example]
>
> This has the following features:
> 
>     1. It is fast, because GWM is already up and running.

With WINTERP/Xmu, this is the case as well. Motif applications, just like
most Xt-based applications, take a long time to initialize. By passing
messages across WINTERP's server interface, you can take advantage of
sending messages to a program that is already up and running.

In practice, I do not notice any latency on my
not-very-fast-by-current-standards HP9000s370. Similarly, Hess notes the
following in the Xmu README file: "it seems to be very responsive, even on
my Sun3/60... [ cg4 ]	;-)"

>     2. GWM determines the look and feel.

In WINTERP's case, the look and feel is whatever can be done with the
OSF/Motif widgets (which is far more than the overrestrictive and somewhat
silly OSF/Motif "style guide"). However, because WINTERP has a built-in
high-level programming language, you could build-in a high-level API to the
menu server that allows for multiple look and feels, e.g. enable some menus
to stay "pinned up", or allow menus displaying alot of data to present the
data in a scrolled list.

>     3. The Epoch code is a little trickier because Epoch has to
>        receive it's result via an asynchronous X11 property change.
>     4. IMPORTANT: The communication with the GWM is solely via X11
>        property change events.

Currently, WINTERP doesn't do property changes because I haven't needed
them in our applications of WINTERP at HP Labs. Adding new C-code to
WINTERP is pretty easy to do, however.

Hess' Xmu uses a file-based mechanism to pass the pick back to the emacs
process:
| NOTE:   The menu server currently uses a file-based mechanism [ HACK ] to
| 	return the menu "pick" to the requestor.  One alternative to this
| 	might be to incorporate a "SEND" mechanism similar to the one used
| 	in the TK toolkit developed by John Ousterhout...

I'm planning on stealing Ousterhout's Tcl/Tk code for doing "send", which
is implemented by doing property changes through the X11 server. Of course,
the emacs process needs to be capable of processing property change
notifications (not available in stock emacs, but available in epoch.).
Since Hess' code works on a stock, unmodified gnuemacs, the "send"
mechanism wouldn't apply.

For receiving events, I'll steal my own code for doing callbacks and
event-handler callbacks in WINTERP and apply them towards the property
change notification callbacks in Xt/Motif. This feature and the Tcl/Tk
"send" may even be found in the upcoming WINTERP 1.13 release.

-------------------------------------------------------------------------------
	    Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com
		  Human-Computer Interaction Department
		       Hewlett-Packard Laboratories
			      Palo Alto, CA.
				   *