Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.lang.c
Subject: Re: Iconitis
Message-ID: <38800@think.UUCP>
Date: 7 Apr 89 17:33:11 GMT
References: <1930@dataio.Data-IO.COM> <11555@lanl.gov> <1360@uw-entropy.ms.washington.edu>
Sender: news@think.UUCP
Reply-To: barmar@kulla.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 28

In article <1360@uw-entropy.ms.washington.edu> charlie@mica.stat.washington.edu (Charlie Geyer) writes:
>  The main defect of any menu-driven application
>whether it uses mice and icons or not is that it is not programmable
>and will do nothing not thought of by the original programmer, who
>probably had very little idea what you want done.

You are comparing two unrelated qualities here.  There are many
keyboard-driven applications that are not user-extensible.  And there
is nothing inherent in menus that prevents user-extensions.

In fact, there is nothing that prevents an application from providing
both styles of user interface simultaneously, and allowing both to be
extended.  The UIMS on Symbolics Lisp Machines does precisely this.
When you are defining a command within an application you can specify
a full command name, a menu name, and a single-character keyboard
accelerator.

I've also used a Macintosh version of MicroEmacs that allowed most
commands to be invoked either using the normal Emacs-style keyboard
commands or the Macintosh menu bar.  I don't think it had any
extension capability, but if it did I'd expect it to allow extending
the menu bar.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar