[139] in Athena User Interface
Re: Updated AUI project summary
daemon@ATHENA.MIT.EDU (Brad Thompson)
Wed Jun 7 22:53:16 2000
Message-Id: <200006080253.WAA05098@manatee.mit.edu>
To: beland@MIT.EDU
Cc: aui@MIT.EDU
In-Reply-To: Your message of "Wed, 07 Jun 2000 20:30:47 EDT."
<200006080030.UAA25506@interstitial-spaces.mit.edu>
Date: Wed, 07 Jun 2000 22:53:11 -0400
From: Brad Thompson <yak@MIT.EDU>
> Maybe I should figure out which HTML editing tool I'm evaluating makes
> the easiest-to-read tables. Blah, bad fonts.
Might I reccommend ed?
If you're looking for something a little more featureful, vi is also nice.
> Yak and I talked some about how programs should be added and removed
> from the Gnome main menus.
[...snip...]
I've had an idea kicking around for how to deal with the gnome menu
contents, but I've failed to tell the right people about it. Beland
talked a little about it in his last mail, but I thought I'd give the
whole story.
For our purposes, the current gnome menu configuration method just
sucks; it is just like dash. It is a bad idea for us to have a single,
predefined menu because it means that whoever is responsible for that
menu must understand the specific needs of each group that wants to use
the menu, and it means that everyone needs to effectively use the same
menu. I believe that we all agree that the dash system should not be
repeated with the gnome menu.
A suggested alternative is to have each menu represent the contents of
a locker. There could be a SIPB menu, with pine, exmh, and vim, an
infoagents menu with netscape 4, netscape 3, and lynx, a matlab menu
with matlab, etc. The problem with this is that it groups things
according to administrative control, not use. You don't want a menu of
things that SIPB maintains, you want a menu of communications tools, a
menu of engineering tools, etc. A solution to this is to use the same
technical solution as you would if each submenu were a locker, but
introduce extra lockers for specicfic categories of program (I think
this is what Beland called "virtual lockers").
These would be real lockers, just like any other. For example, there
could be an "engineering" locker that contained attachandrun scripts
for matlab, maple, ProE, hspice, autocad, and whatever else is common
for engineers to use. This solves the problem of administrative
control, because people are able to choose their own set of lockers,
which can be maintained by anyone. It also means that in the general
case, programs can be grouped by functionality, instead of by who
controls them.
yak
