Ray Strode wrote:
>
>> * XSMP does a number of useful session-managey things (logout
>> notification, logout cancellation, specifying apps that
>> should be restarted right away if they crash, specifying
>> commands to run at logout, etc) which we currently have no
>> other way of doing, so we'd be forced to reinvent half of
>> XSMP if we ditched it.
>>
> So at this point I'm sort of of the opinion that logout cancellation
> isn't really useful.
>
Then you'd need to decide whether application state and overwrite all
open documents, or throw everything away or somehow allow the user to
individually decide (by cancelling logout!)
An alternative would be to save a snapshot of current state and current
open documents into a versioning filesystem and offer the user a choice
of which state to restore upon login. Until versioning filesystems
become more common, this would be complicated and I'm not sure there is
a clear way to present the snapshot restore options on login. Maybe
something like OSX's time machine.
I've been thinking about a few other things which may fit into "the
future of session management."
Why do we ever log out?
1) For security (A good screensaver will give you
this.)
2) To switch users (Sun Ray does this, but couldn't gdm
also eventually provide fast user switching without logout?)
3) Reset application environment states (Improvements to the
session management GUI could reduce the need for logout here)
4) Free up resources. ???
Reason 4 is especially interesting for multiuser systems, especially
thin clients. It might be interesting for embedded uses of GNOME
(laptop/child, maemo...) to reduce resources when user isn't looking.
Currently, when I pull my card out, it appears that I'm "logged out",
but the GNOME applications, applets, anything with dynamic content is
refreshing, polling, consuming CPU, memory and network bandwidth even
though the session is no longer attached to a keyboard and monitor.
Would it be possible to:
Have session manager tell (galago?) "I'm not here" when user selects
"logout/switch user" or a session card is removed.
Have embedded and other devs detect "I'm not here" from keyboard
timeout, suspend switch, closed lid...
Use this presence information to tell applications/applets with
dynamic content and UI polling to hibernate for a while.
Make sure screen saver and session manager (and a user selectable
set of applications) are immune to this "hibernate" signal.
It's just an idea. Just let me know if it's cracked or if it sparks off
a better idea. I like the fact that I never have to log out and it
takes 0.5 seconds to get back to work in the morning. And I love the
fact that I can take my session home with me and continue work there in
0.5 seconds. Is the "eternal portable gnome session" paradigm workable?
>
>> So I'm volunteering to do all of this:
>>
>> * Write up a more detailed proposal than the above
>>
>> * Propose extensions to fdo autostart spec, and a spec
>> covering the XSMP extensions and clarifications. (Hopefully
>> the XSMP stuff could also go into the autostart spec.)
>>
>> * Finish/rewrite msm, add a migration path from gnome-session,
>> propose for 2.18 (or maybe 2.20)
>>
>> * Reimplement GnomeClient as GtkClient, propose for gtk
>> 2.something.
>>
> awesome.
>
>
>> Does this make sense or does someone want to put forth a stronger
>> argument for killing XSMP?
>>
> I don't have a strong argument against it, but I don't see what it
> really buys us. Apps either don't support it, or support it very
> minimally. I wouldn't say it's that well understood, either. It's
> pretty ambiguous in places.
>
> Having said that, I would love to see some improvements on this front,
> and I'm sure you'll come up with something reasonable.
>
What (I think) XSMP does buy us is some session restore compatibility
with applications from KDE, CDE and other desktops.
_______________________________________________
desktop-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
