[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Sep 11 17:53:43 1993 
Subject:Re: emacs & ved; flame-bait. (The RHM system) 
From:"A.Sloman" 
Volume-ID:930911.04 

Steve:
> Come again, a "preference option"?  My own complaint is that VED and
> Poplog has an enormous space of customisation but no uniform way of
> doing it.  The Poplog UI is a step in the right direction -- but it
> needs much, much more fleshing out.

I've developed what I call the "Recursive Hypermenu" system (RHM), which
is intended to provide a lot more scope for customisation, and to make
it easier for beginners to get into Poplog and VED. (I plan to use it
for teaching the AI courses here at Birmingham this October. Some people
have already been using it.)

It consists of a new menu mechanism based on Lib Propsheet, which
currently works only on OpenLook because I don't know how to convert the
motif version of Propsheet to produce relocatable vertically oriented
collections of menu buttons. No doubt someone else could do it.

If Lib propsheet had been better structured that would have been easy.
Or maybe I should have been using a different mechanism that would have
made RHM more portable. (Later I'll use GO see below)

RHM contains an extendable menu mechanism, and lots and lots of sample
autoloadable menus. I can send a compressed uuencoded tar file
containing all of it to anyone who is interested in trying it out.
(Especially anyone willing to try to make it work for Motif.) It is
usable, but is still under development and still needs many features to
make customisation easier. In particular, VED is used to edit menu
definitions, and some menu options should be provided to simplify this.
(Bootstrapping.)

It's recursive because it allows menus to invoke one another, in a
cyclic fashion.

It's incremental - menus are compiled, using autoloading, only when
needed. E.g. this can occur when they are invoked from another menu (or
from the command line.)

It's "soft" in that a menu can be redefined without rebuilding a
complete menu tree. (There is no tree: hierarchies are too restrictive
and unfriendly.)

It is not restricted to driving VED or even Poplog. It can also be used
to drive non-poplog processes. E.g. the button to start up a new xterm
window running top remotely logged in on a machine called 'sun5' could
be defined thus:

    ['Sun5Top' [POP11 ps_xterm('sun5', 'top ')]]

('ps_' is the prefix I've used for names of utilities and global
variables in this propsheet-based system. Maybe the prefixes should be
changed to 'rhm_'.)

In that example, the button label would be Sun5Top. Clicking on it would
run the Pop-11 procedure ps_xterm with the two strings as arguments.

By contrast, here is the definition of a button that will (on Berkely
type Unix systems) run ps and grep to produce a list of the user's
current processes, which are then read into a VED buffer (using
vedgenshell):

  ['MYPROCS' [UNIX 'ps -aux | grep "$USER|USER"']]

It could be simpler, but this illustrates how a Unix piped sequence can
be run from a menu button and the final output read into VED. A slight
change should make the example work on HP-UX or Solaris.

Here's how you specify a button labelled 'MENUS...' that invokes another
menu, in this case the top level menu, which can be invoked from ANY
other menu, e.g. to make it reappear it if had been dismissed, or to
uncover it if it had been covered.

    ['MENUS...' [MENU ps_menu_toplevel]]

The current keywords for action specifications are
    POP-11 = run the text as pop-11
    UNIX   = use vedgenshell to spawn a Unix sub-process
            (If vedgenshell and lib pipein were generalised to VMS it
            would work with VMS)
    MENU   = invoke the named menu
    ENTER  = invoke a dialogue box which will build up a VED
             command.

There are other options also. E.g. a simple string is just given to
veddo, as in this button specification.

    ['HelpMenus' 'help ved_menu']

(I forgot that Xved menus used vectors rather than lists for button
specifications. I could change RHM to improve consistency, but the two
systems are so different that that may not be relevant.)

Autoloadable menu definitions are stored, one per file, in directories
included in a special search list used for autoloading, and also used
for the showmenu command used for examining their definitions. (By
analogy with SHOWLIB).

Thus, as with vedhelplist popautolist, etc. an individual, or group of
individuals, or site can share collections of menus as well as the
system default menus. A user or group directory can contain menu
definitions that shadow the system default definitions for those
particular menus. So a group of students might be given certain
menus with only a subset of options to avoid initial confusion.

Of course, you don't have to use Xved to run this, so you are not
forced to put up with all those windows! You don't even have to run VED
(I think...).

The notation for defining menus and buttons has evolved over time. It
could be changed easily to be a bit more readable by those who don't
know Pop-11 syntax. A menu specification is just a Pop-11 list. Special
syntax words could easily be defined to produce more English like
definitions (or something like vedset). But I suspect it's not necessary
or desirable.

There are no walking menus. They aren't needed: a sub-menu is just
another menu, and if you know its name it can be invoked directly from
any menu or by the VED command "ENTER menu <name>". All menus are born
equal! This is a democratic system.

People who use twm or olwm, or derivatives, may find that it is easier
to edit and extend an RHM menu to invoke Unix or X utilities than to
change the usual window manager menus. (I don't know about motif wm).

The default placement of RHM menus is something not everyone will agree
with, but after some experimentation I've found that it works with a
number of different types of users, including a temporary secretary who
used VED only for a week, e.g. for reading and sending mail and typing
in files.

All but the top level menu get stacked in a pile as they are used, with
the top level menu to one side of the stack. Because it is easy to cycle
round this stack (at least with the "raiselower" function in TWM-type
window managers) this makes it not too difficult for users to retrace
their steps. A graphical map of selections would be better, but most
screens are too small and cluttered to make this realistic, and anyway I
have not had time yet! Menus can be dismissed (from the screen)
individually or all at once.

Each menu has a name and they invoke one another by name. If the name
gets a new value the old menu will be garbage collected (at present I
don't have a destroy property to ensure that they are removed from the
screen -- one of several fixes still needed.)

Any menu can be used to invoke the top level menu. Some families
of related menus invoke one another, to facilitate rapid switching
between options, and they can have an intermediate top-level.

Some menu buttons directly produce actions. Some get other menus. Some
get dialogue boxes that can be used to specify an action before it is
performed. E.g. the "replace" button on the search menu gets you a
dialogue box that allows you to specify whether it's interactive, the
scope (file, range, or current procedure, whether embedded strings are
accepted, etc.)

Where appropriate, when an action is performed, VED's status line is
updated with the command that would have achieved the action, so that
this can help people learn ENTER commands. This is a menu system
designed to wean users off it! That also facilitates REDO, or REDO after
a slight edit. For packages using several sub-menus, users can define
their own intermediate toplevel, and, if appropriate, make them appear
as a separate group from the main poplog menus. But most screens are too
small!

Later the system will be re-implemented using the new GO (Graphical
Objects) system, to give greater flexibility. Probably the PUI should
also be reimplemented to use that. I regard flexibility as far more
important than consistency with either Motif or Openlook (or Windows?),
neither of which, I suspect, addresses the problem adequately.

Available on request is quite a long paper describing the system (part
of the final report of the UIDE project) available as a 1400 line ascii
file in VED HELP format, or a framemaker-generated postscript file.

Aaron



> > : > Oh, and  *why*, except for implementation reason,   does  ved hae this
> > : > fetish for line-orientation?


>
> It doesn't.  Indeed, Andy points this out himself when discussing
> XVED.
>
> If you are using XVED then you'll find that there is
> a general text selection region as well as marked ranges.  I think
> the distinction between these two is rather annoying -- I'd like to
> see the marked range as an alternative way of selecting text.  I
> also think that there is a confusion between selection of text and
> copying to the clipboard.  These concepts should be clearly separated.
> [Andy states this himself, later in his posting.]
>
> [I'll also note that Andy's interpretation of marked ranges
> being the most common unit of selection in VED has absolutely nothing
> to do with the line-based implementation of VED buffers.  In my view,
> this is a connection that has no support.  By contrast, I know that a
> key element in the decision to use marked ranges was the inability
> to highlight an arbitrary selection range on many TTYs.  As a compromise,
> I believe, the selection of lines was supported and the visible mark in
> column 1 was provided.  With the advances in VDU technology, this
> decision should be revisited.]
>
>
> > : > And... wait for it... NO UNDO!!! Until you have to  put up with a yank
> > : > which calls  itself undo you  have no  idea how irritating  it is. But
> > : > I've had this argument before.....
> >
> > [Aaron's long and valuable discourse on undo...]
>
> There's no controversy.  VED should support arbitrary
> undo operations.  These operations should be categorised.  The user
> should be given two ways of interacting with the undo-list -- through
> sequential ordering (undo the last done thing) and through category
> (undo the last line deletion).
>
> This supports both Andy's way of working and Aaron's way of working.
> Unlimited levels of undo should be supported, modulo storage requirements.
> See the postscript for details on how this might be done.
>
> Steve
>
> P.S.
> To correctly implement this type of storage management a new kind of
> temporary property (or reference) needs implementation -- a sticky
> property.  Sticky properties temporary properties that can lose entries
> that AREN'T garbage.  Very stickly properties hang onto their entries
> quite strongly -- until the garbage collector struggles.  Unsticky properties
> are like "tmpclr" properties -- they forget their entries at any garbage
> collection.
>
> Sticky properties are very useful indeed.  They are the kind of properties
> that are best used for memoisation, for example, and other kinds of
> sophisticated memory management.  I've put in an enhancement request
> asking for sticky properties to be added to Poplog.
>
>
> P.P.S.
> I'll also note that Andy's interpretation of marked ranges
> being the most common unit of selection in VED has absolutely nothing
> to do with the line-based implementation of VED buffers.  In my view,
> this is a connection that has no support.  By contrast, I know that a
> key element in the decision to use marked ranges was the inability
> to highlight an arbitrary selection range on many TTYs.  As a compromise,
> I believe, the selection of lines was supported and the visible mark in
> column 1 was provided.  With the advances in VDU technology, this
> decision should be revisited.
>