[553] in Athena User Interface
Re: Configuration of sawfish, panel, gnome-terminal, control-center
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Jan 1 01:34:46 2001
Message-Id: <200101010634.BAA16703@egyptian-gods.MIT.EDU>
To: "Christopher D. Beland" <beland@MIT.EDU>
cc: ghudson@MIT.EDU, aui@MIT.EDU, sbjones@MIT.EDU
In-Reply-To: Your message of "Sun, 31 Dec 2000 23:35:36 EST."
<200101010435.XAA24504@ten-thousand-dollar-bill.mit.edu>
Date: Mon, 01 Jan 2001 01:34:40 -0500
From: Greg Hudson <ghudson@MIT.EDU>
> - Sawfish defaults have the system-custom dichotemy, right?
Yup.
>> * Menus (also determined by the site-defaults file)
Based on what you said, it sounds like this is best:
Left button - Window ops, including "new terminal window"
Middle button - List of windows
Right button - Allocate for FM
> Well, to reiterate the results of the previous discussion, we
> compromised on not having any "Editor" launcher on the panel. The
> reasoning was that different editors would be appropriate for
> different tasks, and that different people have different
> preferences for what editor to use for a given task.
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 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. As I've noted before, we can't add launchers to the
default set (only new accounts would get them, and that's a
documentation nightmare), and switching over the "editor" launcher to
a word processor is a potentially dangerous suprise. I'm also not
sure how to make icons which distinguish between "text editor" and
"word processor", since the distinction is mostly artificial.
> 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.)
> I agree with Richard; distributed maintenance is very important and
> I personally think the lack thereof was Dash's downfall.
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.)
That said, nothing about the release machinery I'm proposing will
actually dictate how the menus are maintained.
/usr/athena/share/gnome/apps will be a symlink into an AFS area, and
AFS permissions are certainly flexible enough to permit just about any
maintenance scheme we want. What we won't get is the easy ability for
users to add lockers to their menus.
> The current practice of making the "Favorites" menu what comes up
> from the Gnome footprint is somewhat confusing, but on the other
> hand, I really like being able to customize the top-level menu.
(Did you guys ever consider what happens in your scheme when Athena
wants to add or remove a top-level menu? Putting the default
top-level menu selections under "Favorites" seems like a total lose
for that. Easy user-customizability is neat, but it's less important
than the ability to make system-wide changes without creating a
documentation nightmare.)
My plan is:
Programs (gnome-induced title; I wish this could go away)
--------
Help (however we reorganize this stuff)
Courseware
.
.
.
--------
Favorites ->
Run...
--------
Lock screen
Log out
> I'm also wondering how users will get the neo-AUI login both during
> the testing phase and in the actual release?
My plan was to put this stuff in the default dotfiles and beat on it a
lot with the test accounts using machines in the bleeding-edge
cluster. Making the actual release software to users on regular
Athena machines is not an easy thing. (Although, keeping the aui
locker more in sync with the planned release in terms of configuration
might make our usability testing more helpful.)
> I'm sure it will be great fun dealing with users logging in on
> different versions of Gnome which live in different Athena releases.
> 8)
We'll burn the incompatible-transition bridges when we get to them.
Red Hat has to deal with some of the same issues, so we won't be
totally alone.
> There was also that idea of fixing the login sequence to be more
> user-friendly. Has that been pushed off until after summer 2001?
Unless I feel extremely inspired some weekend or the resources make
themselves known, it ain't happening by this summer.
