emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Infrastructural complexity.


From: Thomas Lord
Subject: Re: Infrastructural complexity.
Date: Sun, 19 Jul 2009 13:18:39 -0700

On Sun, 2009-07-19 at 21:23 +0300, Juri Linkov wrote:
> > Why should they need menu bars and tool bars etc? I think they would
> > be useful without it.
> 
> Have you seen Eclipse screenshots?  Eclipse and other IDE framelets have
> tool bars and tab bars.

This is more idle brainstorming than anything else:

Some quick thoughts about how I think about this design
space:

1) A useful concept is that toolbars, tab bars, and menu
bars are all "virtual input devices".   Their main function
is to give users a way to generate a distinct class of input
event types.   This concept is reflected in the existing 
support, of course, but it's useful to state it explicitly.
What kinds of "virtual input device" we have is necessarily
kind of ad hoc but that's ok because having just a few, general
purpose ad hoc virtual input devices goes a long way in terms
of utility.

2) We don't have to slavishly follow Eclipse or another
program to determine our list of virtual input devices.
When we pick virtual input device types and their behavior,
whenever possible, virtual input devices that make some sense
on plain-text smart terminals are extra nifty to have.

Given Emacs' huge command set, I'd really like to see a
virtual input device that resembled, say, the command menu
system of old PC programs like Lotus whatsit or any of the
spreadsheet programs.   This also resembles the command
menu interfaces of some HP calculators, as I recall.  Basically,
a narrow area for listing a thin menu of commands but with a 
"tree structure" so you can dig down to sub-commands or pop 
back up to parent menus.   With a "home" or "clear" command for
getting back to the root of the command tree.

-t






reply via email to

[Prev in Thread] Current Thread [Next in Thread]