🚀 go-pugleaf

Epoch's only dependency on Motif is that, by itself, Epoch has no
menus facility at all.  The rest of Epoch's look and feel is GNU
Emacs, which seems like a good idea for an X11 based GNU Emacs...

In terms of menus, the only Epoch requirement is that something else
post the menu.  The following code will use the binary "xmenu" to post
a menu:

(defun interpret-output (process output)
  (command-execute (intern-soft output)))


(defun do-menu (foo)
  (interactive)
  (set-process-filter (start-process "xmenu"
				     nil
				     "xmenu" "-heading" "Epoch X-Emacs Menu"
				     "Run KEE=lanllisp"
				     "Run KEE and Load Rocky-2=run-rocky-2"
				     "Load Rocky-2=load-rocky-2"
				     "Compile Rocky-2=compile-rocky-2"
				     "Save Buffer=save-buffer" 				     
				     "Buffer Menu=list-buffers"
				     "Dired=dired"
				     "Read Mail=rmail"
				     "Read News On Beta=beta"
				     "Read News on Mica=mica"
				     "Exit Minibuffer=exit-minibuffer"
				     "Exit Menu=exit-menu")
		      'interpret-output))


(defmouse ':global "C-Middle" 'mouse-ignore 'do-menu)

This has the following features:

    1. It is slow because the xmenu executable must be started each time.
    2. The menu's look and feel depends entirely on the implementation
       of xmenu (which uses Athena widgets, a Motif version should be
       trivial).
    3. The Epoch code is easy to write because there is a simple way
       to make Epoch wait until "xmenu" returns a result.

The following is the code I use to have gwm post a
menu:

;;; gwm-menus.el -*- emacs-lisp -*- Epoch support for simple GWM menus
;;; Original code by Colas 1991-02-18
;;; Heavily hacked by Dan Pierson, Encore Computer Corp, 2/28/91
;;; 	Explicity specify all Epoch commands in string passed to GWM
;;; 	Gratuitously reformat

;;;============================================================================
;;;                    Sane EPOCH_EXEC
;;;============================================================================

;;; here we add a handler to read code from X properties without trashing
;;; epoch in case of errors in sent code.

(defun epoch-exec::property-init ()
  "private property to avoid handler lost from external error"
  (push-property "EPOCH_EXEC"
		 (function (lambda (type prop screen)
		   (let ((cw (selected-window))
			 (action (get-property prop screen)))
		     (unwind-protect
			  (progn
			    (select-window (epoch::selected-window screen))
			    (and (stringp action)
				 (eval (read action))))
		       (select-window cw)))))))

(epoch-exec::property-init)

;;; use by sending to X property EPOCH_EXEC the code:
;;;      (let ((protect epoch::event-handler))
;;;        (unwind-protect
;;; 	     (progn 
;;; 
;;; 	       ... [code to excecute via the property] ...
;;; 
;;; 	       (setq epoch::event-handler protect))))
;;; 

;;; General menu popper, expects a list of the form:
;;; 	'("Title"
;;;       ("Item" epoch-code)
;;;       ...)

(defun gwm-pop-menu (items)
  (epoch::set-property "GWM_EXECUTE"
			 (concat "(progn (require 'epoch)(list-menu-make "
				 (prin1-to-string items)
				 "))"
				 )))

;;; Application: pop a menu with epoch buffers:

(defun gwm-choose-buffer (arg)
  (let ((buflist (cons "Epoch Screens"
		       (mapcar (function (lambda (buf)
				 (let ((name (buffer-name buf)))
				   (list name
					 'switch-to-buffer
					 (concat "\"" name "\"")))))
			       (buffer-list)))))
    (gwm-pop-menu buflist)))

(global-set-mouse mouse-right mouse-control-shift 'gwm-choose-buffer)

;;; end of gwm-menus.el

This has the following features:

    1. It is fast, because GWM is already up and running.
    2. GWM determines the look and feel.
    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.

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.  As a hint towards such a thing, here is all of
the GWM support for these menus:

;;; Code to communicate with epoch
;;; Colas 1991-02-18
;;; Heavily hacked by Dan Pierson, Encore Computer Corp, 2/28/91
;;; 	Explicity specify all Epoch commands in list passed to GWM (as
;;; 	a string)
;;; 	Gratuitously reformat
;;;
;;; this needs the epoch code "gwm-menus.el" loaded into epoch

;;; routine to send a string to be executed by epoch, supposed to be the 
;;; current window 

(defun send-epoch (code)
  (set-x-property "EPOCH_EXEC"
		  (+ "(let ((protect epoch::event-handler)) (unwind-protect "
		     code
		     "(setq epoch::event-handler protect))))"
		     )))

;;; Menu package:
;;; How to make a menu of arbitrary Epoch commands

(defunq list-menu-make (args)
  (pop-menu (menu-make-from-list
	     (+ (list (list 'pop-label-make (# 0 args)))
		(mapfor s (sublist 1 (length args) args)
			(list 'item-make (# 0 s)
			      (list 'send-epoch-command
				    (sublist 1 (length s) s))))))))

(defun stringify (args)
  (with (t (type args))
    (cond ((eq t 'string) args)
	  ((eq t 'list)
	   (with (s "(")
	     (for i args (setq s (+ s (stringify i) " ")))
	     (+ s ")")))
	  ((or (eq t 'atom)
	       (eq t 'number))
	   (+ "" args))
	  (t ""))))

(defunq send-epoch-command (args)
  (send-epoch (stringify args)))

;;; All done

(provide 'epoch)

--

                                            dan

In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,linus,necis,decvax}!encore!pierson
Internet: pierson@encore.com

In article <PIERSON.91Jul1163832@xenna.encore.com>, pierson@encore.com (Dan L. Pierson) writes:

> [ An excellent post, which is completely correct ]

> 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.

A final point is our view on this. We don't believe that Epoch should
do menus - we believe that it is the wrong place to put that
functionality, for exactly the reasons Mr. Krolikoski brought up - it
would tie Epoch to a particular look&feel for menus. What we'd really
like to see is a standard mechanism where the WM can be requested to
generate a menu, and pass back the result. The code that Dan posted
shows a way to do this with GWM now, which is one reason we have a
preference for that WM.

As part of my thesis work, I will be producing a general Motif widget
server, which will talk to Epoch*, and it should be released about the
time I graduate, later this year.

*We have an internal version in use, although it's _not_ ready for
release.

-- 
Alan M. Carroll          <-- Another casualty of applied metaphysics
Epoch Development Team   
Urbana Il.               "I hate shopping with the reality-impaired" - Susan

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.
				   *

In article <1991Jul4.164307.8393@m.cs.uiuc.edu> carroll@cs.uiuc.edu (Alan M. Carroll) writes:
>A final point is our view on this. We don't believe that Epoch should
>do menus - we believe that it is the wrong place to put that
>functionality, for exactly the reasons Mr. Krolikoski brought up - it
>would tie Epoch to a particular look&feel for menus. What we'd really
>like to see is a standard mechanism where the WM can be requested to
>generate a menu, and pass back the result. The code that Dan posted
>shows a way to do this with GWM now, which is one reason we have a
>preference for that WM.

I'm not sure that the "menu server" should have to be part of the window
manager. Although I like Gwm alot, tieing users to a particular window
manager is taking a big step backward in the X world. Besides, you'd end up
losing alot of "customers" by asking them to use a wm that they don't want
to use, or a wm that isn't supported within their organization. OSF/Motif
users may prefer mwm, HP VUE users will want to get the "rooms"
capabilities provided by vuewm, "Open" Look users will want olwm, and
various others will want to use the various virtual WMs available.

That's why I think that UI server functionality should be separable from
the window manager, and that's why approaches such as the Richard Hess' Xmu
menu server running atop my WINTERP Motif Widget INTERPreter is the right
way to go. For more info on WINTERP/Xmu, see my previous posting in reply
to Dan Pierson's post.

>As part of my thesis work, I will be producing a general Motif widget
>server, which will talk to Epoch*, and it should be released about the
>time I graduate, later this year.

Have you considered WINTERP?? WINTERP can be used as "a general Motif
widget server" but it is more than that since it contains an embedded tiny
lisp interpreter (based on David Betz' XLISP 2.1) which allows you to put
dialog and application code into WINTERP.

Input to WINTERP's lisp evaluator is through a server socket (either inet
or unix domain) which thereby allows for other applications and processes
to talk to WINTERP.  Most people use WINTERP to build entire applications
entirely within Winterp-Lisp, but you can also use WINTERP as a UI server
for an application running as a separate process.

WINTERP 1.13 (release date unknown) will also contain an interface to Don
Libes' "expect" library -- this will allow for communication with
subprocesses connected to WINTERP via ptys, and will allow for concurrent
interaction with multiple unix subprocesses all controlled by a
non-blocking Motif-based UI. The effect is similar to emacs' process-filter
and process-sentinel capabilities, and will allow WINTERP to become a
general GUI-wrapper for terminal-based programs. The same facilities can
also be used to communicate with other serverized applications (via telnet
or rlogin).  I have a good part of this working already, but more testing,
coding, and documentation needs to be done before release.

A further advantage of using WINTERP is that it is relatively portable,
stable and reliable because it has been publicly available since the MIT
X11r4 contrib release. The current release, version 1.12, runs on a
number of different unix machines, e.g.
        * HP9000s3xx (68030/68040) running HPUX 7.0, HPUX 6.5.
        * HP9000s8xx (HP's PA-RISC) running HPUX 7.0, HPUX 3.1.
        * HP9000s7xx (HP's PA-RISC 1.1) running HPUX 8.0
        * Sun Sparc 2 running SunOS Release 4.1.1
        * Data General AViiON (m88k, DG/UX 4.30, GNU C 1.37.23)
        * DECStation 3100 running Ultrix.
	* SGI 4D ("MIPS, SGI Unix, latest release (Cypress)")
I've received reports that previous versions of WINTERP have run on the
following:
        * IBM RS6000 AIX 3.1
        * Sun 3 running SunOS 4.0.3
        * MIPS (Mips RS2030)
        * Intel System Vr3.2 v2.2 (using Intel X11R3 with Intel Motif v1.0.A and TWG/TCP v3.1)
        * Apollo's 680xx machines.

			--------------------

Since my mention of WINTERP may generate many "what is WINTERP" e-mails,
I'll go ahead and answer that now with my standard WINTERP blurb:

==============================================================================

WINTERP: An object-oriented rapid prototyping, development and delivery
environment for building user-customizable applications with the OSF/Motif
UI Toolkit.

------------------------------------------------------------------------------

WINTERP is a Widget INTERPreter, an application development environment
enabling rapid prototyping of graphical user-interfaces (GUI) through the
interactive programmatic manipulation of user interface objects and their
attached actions. The interpreter, based on David Betz's XLISP, provides an
interface to the X11 toolkit Intrinsics (Xtk), the OSF/Motif widget set,
primitives for collecting data from UN*X processes, and facilities for
interacting with other UN*X processes. WINTERP thus supports rapid
prototyping of GUI-based applications by allowing the user to interactively
change both the UI appearance and application functionality. These features
make WINTERP a good tool for learning and experimenting with the
capabilities of the OSF/Motif UI toolkit, allowing UI designers to more
easily play "what if" games with different interface styles.

WINTERP is also an excellent platform for delivering extensible or
customizable applications. By embedding a small, efficient language
interpreter with UI primitives within the delivered application, users and
system integrators can tailor the static and dynamic layout of the UI,
UI-to-application dialogue, and application functionality. WINTERP's use of
a real programming language for customization allows WINTERP-based
applications to be much more flexible than applications using customization
schemes provided by the X resource database or OSF/Motif's UIL (user
interface language).

An environment similar to WINTERP's already exists in the Gnu-Emacs text
editor -- WINTERP was strongly influenced by Gnu-Emacs' successful design.
In Gnu-Emacs, a mini-Lisp interpreter is used to extend the editor to
provide text-browser style interfaces to a number of UN*X applications
(e.g. e-mail user agents, directory browsers, debuggers, etc). Whereas
Emacs-Lisp enables the creation of new applications by tying together
C-implemented primitives operating on text-buffer UI objects, WINTERP-Lisp
ties together operations on graphical UI objects implemented by the Motif
widgets. Both achieve a high degree of customizability that is common for
systems implemented in Lisp, while still attaining the speed of execution
and (relatively) small size associated with C-implemented applications.

Other features:
        * WINTERP is free software -- available via anonymous ftp from
          export.lcs.mit.edu.
        * Portable -- runs without porting on many Unix systems.        
        * Interface to gnuemacs' lisp-mode allows code to be developed
          and tested without leaving the editor;
        * Built-in RPC mechanism for inter-application communications;
        * XLISP provides a simple Smalltalk-like object system.
        * OSF/Motif widgets are real XLISP objects -- widgets can be
          specialized via subclassing, methods added or altered, etc.
        * Automatic storage management of Motif/Xt/X data.
        * Contains facilities for "direct manipulation" of UI components;

You may obtain the latest released version of the WINTERP source,
documentation, and examples via anonymous ftp from internet host
export.lcs.mit.edu (18.30.0.238): in directory contrib/winterp you will
find the compress(1)'d tar(1) file winterp-???.tar.Z. (??? represents the
version number). Slides, papers and further documentation can be found in
directory contrib/winterp/papers.

If you do not have Internet access you may request the source code to be
mailed to you by sending a message to winterp-source%hplnpm@hplabs.hp.com
or hplabs!hplnpm!winterp-source.

There is also a mailing list for WINTERP-related announcements and
discussions. To get added to the list, send mail to
winterp-request%hplnpm@hplabs.hp.com or hplabs!hplnpm!winterp-request.

For discussions about XLISP, see the USENET newsgroup comp.lang.lisp.x.

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

>    2. The menu's look and feel depends entirely on the implementation
>       of xmenu (which uses Athena widgets, a Motif version should be
>       trivial).

  I posted xmenu2 (a Motif version of xmenu) to comp.sources.x earlier this
year.  Here's the header from that posting;

: From: cimshop!pleione!rhess@uunet.UU.NET (Richard Hess)
: Newsgroups: comp.sources.x
: Subject: v12i015: xmenu2 -- an OSF/Motif version of "xmenu"... [ plus enhancements ], Part01/01
: Date: 10 Mar 91 22:27:50 GMT
: 
: Submitted-by: Richard Hess <cimshop!pleione!rhess@uunet.UU.NET>
: Posting-number: Volume 12, Issue 15
: Archive-name: xmenu2/part01
: 
: [  This "little" OSF/Motif 1.1 toolkit program produces a popup menu on the
: [  screen taking the command line arguments as menu entries.  Both simple and
: [  cascading menus are supported in this version.  This release also supports
: [  automatic submenu generation when the maximum menu entry limit is exceeded
: [  (see xmenu2.man for more detailed info).
: 
:   Xmenu2 is designed to be plug compatible with the original xmenu release
: from Richard Hesketh (rlh2@ukc.ac.uk).


Dick...
  
+------------------------------------------------------------------------------
WHO:	Richard Hess			CORP:	Consilium
TITLE:	Staff Engineer			VOICE:	[415] 691-6342
    [ X-SWAT Team:  Special Projects ]	USNAIL:	640 Clyde Court
UUCP:	...!uunet!cimshop!rhess			Mountain View, CA 94043
+------------------------------------------------------------------------------