[557] in Athena User Interface
Re: Configuration of sawfish, panel, gnome-terminal, control-center
daemon@ATHENA.MIT.EDU (Christopher D. Beland)
Mon Jan 1 20:08:17 2001
Message-Id: <200101020108.UAA320964@whack-a-mole.mit.edu>
To: ghudson@MIT.EDU
cc: aui@MIT.EDU, sbjones@MIT.EDU
Date: Mon, 01 Jan 2001 20:08:13 -0500
From: "Christopher D. Beland" <beland@MIT.EDU>
> Maybe, but the Athena release supports emacs as the recommended
> editor. It's not the friendliest or prettiest thing out there, but
> it's pretty solid, it doesn't lose people's work, and we have a very
> good handle on its behavior with regard to backups and autosaves.
It could, in fact, still do that without having an icon on the panel.
This would be useful for the purpose of forcing people to realize that
there alternative programs available. On the other hand, people who
are dissatisfied with Emacs are likely to go searching for something
else anyway, and the panel menus as currently configured in the gtest
account I think make alternatives easy to find.
> It is an interesting question what we will do come the far-off day
> when we have a fully-supported word processor in the Athena
> environment.
Well, it would be possible, with an intelligent enough script, to
cause a new icon to appear on the panel for people with the default
settings, and/or to advertise a way to make the change to everyone.
But ya, it would be messy. Anyway...
> > The Gnome Menu/Main Menu distinction is extremely problematic and
> > should go away.
> That's out of scope for us. (I notice there's a new type of menu,
> "Global main menu", whose selections seem to be determined in a
> non-editable system area. I wonder if we should make use of that.
> People can always switch to "Main menu" if they want to customize.)
Er...what I mean is that there's this menu you get when you
right-click on the panel, and there's the menu you get when you click
on the Gnome footprint. IIRC, when you try to configure the footprint menu
in Control Center, you actually end up configuring the other one,
which most people don't even realize exists. (I myself had quite a
lot of trouble figuring out what was going on, until Brad explained it
to me.)
Would it be terribly complicated to cause the right-click menu and the
footprint menu to behave exactly the same, or to disable the latter?
(Being configurable from CC in an intuitive way would be a big bonus.)
> I think Athena wants to keep a fair amount of control over these
> menus. Perhaps you guys see Dash as having fallen down because you
> want these menus to contain "just every X program in any locker on
> Athena that people might use." Such a vision is well beyond the
> scope of the Dash menus, and the maintenance of such a menu scheme
> is probably an unsolvable problem. (Merely invoking the phrase
> "distributed maintenance" doesn't solve the problem.)
Such a catalog pretty much already exists in What Runs Where. In
creating the current gtest menu scheme, I mostly just pruned that
listing down, added a number of Gnome things and pointers to
critically useful web sites (mostly in Help/Info, I think), and tried
to sanify the organization.
I think the single-AFS-tree scheme Greg is proposing meets most of the
important goals for the menu system, including the potential for
distributed maintenance (think of it what you will). The strengths of
the locker-based system it sacrifices are:
- Modularity in sharing. Joe User can't share his menus with Jane
User. Not a big deal, I think; people can exchange this information
by copying dotfiles or by making changes manually.
- Modularity in viewing. Everyone gets *all* the system-wide menus,
whether they are useful or not. This might make it harder to find
stuff, though good organization could help that.
On the upside, I think Greg's system will work a *lot* better with the
mainline gmenu (the menu-editing GUI). It will also give everyone
easy access to all programs in the system without having to discover a
locker name by some out-of-band means.
Here's an interesting but potentially messy idea: Would it be
possible, under this system, to create special AFS groups to which
people could add or remove themselves? Each list would correspond to
a menu or submenu; when user is added/removed, they gain/lose
permission to read that directory, and thus, the menu or submenu is
hidden or made visible, as appropriate. </babbling>
-B.
===============================================================
Christopher Beland - http://web.mit.edu/beland/www/contact.html
MIT STS/Course 6 (EECS) - MIT Athena User Interface Project
===============================================================
