[201] in Athena User Interface
Re: Session mgmt, MOTDs, HOTDs
daemon@ATHENA.MIT.EDU (Thomas Bushnell, BSG)
Wed Jun 21 05:30:35 2000
To: "Christopher D. Beland" <beland@MIT.EDU>
Cc: BSG@MIT.EDU, aui@MIT.EDU
From: tb@MIT.EDU (Thomas Bushnell, BSG)
Date: 21 Jun 2000 05:30:31 -0400
In-Reply-To: "Christopher D. Beland"'s message of "Wed, 21 Jun 2000 05:16:19 -0400"
Message-ID: <u1hk8fjwfd4.fsf@oliver.mit.edu>
"Christopher D. Beland" <beland@MIT.EDU> writes:
> Anyway, one day, several months later, I'm working in W20 on a big
> project, and I have twenty different C files open on my desktop. I
> realize the last SafeRide is about to leave for Boston, but I'd rather
> not have to reopen all my windows when I get home. Or maybe I'm on my
> lunch hour, and have to run to class before I finish what I'm working
> on. It would be nice to have a little button on the logout dialog
> which says "remember all the windows I have open right now, and open
> them again next time I log in."
>
> Gnome as it stands has the latter, "short-term memory" feature, which
> is nice, except it doesn't work for windows you open from the command
> line. Unfortunately, this is also the mechanism by which I'm supposed
> to get the former "long-term startup persistance" funtionality.
> Combine that with windows you've opened from the command line, which
> aren't remembered, and you've got a real mess.
Does this mean you want a way to say "remember these windows the next
time I log in, but only that once", and distinguish this from
"remember these windows as part of my normal setup"?
I agree that this might be a useful feature.
> If push comes to shove, I'd say make some sane way of specifying
> startup sequence, and punt the "short-term memory" feature. (I would
> say don't do it unless we can solve the unmanaged window problem.)
So the existing feature, the long-term one, is fine. Maybe the
short-term one would be cool too, but our goal is simply not "recreate
windows", nor should it be. It isn't any less intuitive. I agree
that the short-term memory feature is a nifty one, but I don't agree
that lacking it is counter-intuitive. But that's nothing to worry
about.
I agree we should try and solve the unmanaged window problem; I don't
agree that if we can't do it we should punt the session management
long-term memory entirely. It's a good thing to have, even if it
doesn't remember every single window correctly.
> I don't know about the Debian, but in the current RedHat-AUI build of
> the capplet, the "Browse Currently Running Programs" dialog is the
> only interface to session-managed startup. There's no way in this
> dialog to add programs to the sequence, though you can remove them.
> It looks like whatever programs you had running when you last chose
> "Save this setup" in the logout dialog are what's here. But that's
> an entirely un-obvious connection, and in my opinion, really messed
> up.
I used Settings > Session Manager Properties. It brought up a little
window called the session properties capplet, which lists everything I
have on startup. It shows all the current windows on my screen.
If I start an xterm not from the panel, the session manager capplet
notices. It has lots of little frobs to manipulate its startup state,
as far as I can tell.
So a "session managed" program is one which the session manager knows
about and keeps track of. It does not automatically imply to me that
in order for a program to be session managed it is ipso factor started
up on every startup, though Gnome might have that property.
> You can tell Gnome to save your "setup" - i.e. what session-managed,
> Gnome-started programs are running - at every login. In this state,
> "session-managed" programs are those that persist from login to login
> and change as you start and finish tasks. Without that auto-save
> feature, they become "all the things you had running last time you
> saved the state of the world on logout." On some level, this is very
> close to "all the things you told me you wanted to run on every
> startup last time you bothered talking to me (the capplet)" and thus
> creates redundancy and confusion.
So the capplet edits the exact same list that the session manager
does. I don't see why this is confusing; it seems a lot easier to
understand than one which has separate lists.
> There's also the matter of system programs, which I always want to run
> (and if I don't there are other, more proper ways to stop them from
> running) vs. my own startup programs, which I might change
> occassionally. A good interface will not put these two things on the
> same list in such a way that they might be easily confused.
I disagree. If by "system programs", you mean "panel", then we should
absolutely list it in the same list. We should not hide from the user
the fact that the panel is a program like any other that the user can
choose to run or not. (I have spoken to users who hated dash and had
absolutely no idea it was possible to use Athena without dash.)
If you mean things like "sync" and "mount", then they aren't there
now.
Thomas
