Dan Winship wrote:
> But as you also said, XSMP is policy-free
I meant more to say "policy-free" in ironic quotes ;-)
>>> * The "Save current state" checkbox at logout will now
>>> say something like "Restart the currently-running
>>> applications the next time I log in". This would
>>> save state for a *single* logout/login, rather than
>>> saving your current state for all time until you
>>> save a new state. And perhaps the button remembers
>>> its state between sessions?
>
> aka "having apps guess that their last state is the one you're likely to
> want again next"
The user-visible difference is: if I just exit the app or close a
document, then relaunch it or reopen it, was state saved; or is state
only saved if I "save session" i.e. explicitly save state for all
applications.
> * Pretty much everyone seems to agree that more state saving in
> general is good. And once you've got per-document/per-window state
> saving implemented, it's not much harder to implement session
> saving on top of that (you just need to remember *which*
> documents/windows are open in addition to what their individual
> states are).
Right. If you code magic state saving across application/document launch
(instead of across sessions), and you have autostart, then all xsmp adds
is a way to stick the windows to open into the command line, plus some
stuff you don't want (like having the WM save window positions, multiple
saved sessions, ...).
So in principle you can "save session" by listing the .desktop files and
the documents to open them with (just as if I drag-and-drop some files
from nautilus onto the desktop file to open those files).
> And suddenly rather than "Die, XSMP! Die!", it looks like, "well, why
> *wouldn't* we want to keep XSMP session saving around?"
My point really isn't die xsmp die (I am indifferent), but that it
allows a lot of things that aren't useful, which are bad if they leak
into the UI or API.
What I would say is that the application and user model should be
reduced to maybe three things for state saving (ignoring
logout-notification):
- does the app start on login (autostart)
- saving each window's state including child widgets and app-specific
properties, when that window is closed or the app is quit, and
restoring on each app/window launch
- storing the set of open windows, perhaps in a single global default
setup, OR for some apps it's probably better to just save it per-app
or do it in some app-specific way
Things in XSMP state saving that needlessly complicate the application
or user model:
- multiple saved sessions (= multiple autostart dirs /
open-window-lists)
- having the window manager save the window states [1]
- local vs. global vs. both
- clone command vs. restart command
- discard command
- having to set a command at all, for apps that could just set a
document list and the name of their desktop file, or for
document-less apps, apps that could just set the name of their
desktop file
[1] this one is a real compatibility issue; it needs to be killed
because it's very flaky and doesn't work in the more useful state-save
case within a session. But if you kill it, "old" xsmp-using apps won't
work. Except noncompliant ones like gnome-terminal that just save their
own geometry and I guess fight with the WM over which saved geometry
wins ;-)
> Eg, something like:
>
> gboolean (*save_state) (GtkClient *client, GKeyFile *state_file)
>
> The app just writes stuff to the GKeyFile and then returns TRUE.
It's the right idea. To really make it solid, I think you also want to
be able to just gtk_write_window_states(state_file), and have that be
the default handler for save_state even. heck, gtk could even write out
the list of open windows for you also, since each window has an ID.
The thing is though, this window state saving should also happen when a
window is just closed, not just when there's a desktop global save state
event.
I'd guess the API should be designed so it's primarily around saving
window states on unmap and restoring them just before map; and then
build a "globally save all windows in the desktop" magic functionality
on top of that.
>> On the implementation front, there is some amount of intrinsic problem
>> with libICE/libSM - they are total junk and make it difficult to write a
>> robust session manager app.
>
> But gnome-session and msm have both already dealt with this, right? Does
> the libICE/libSM suckiness leak, or can it be completely contained
> within the SM and GtkClient?
It is containable, it's purely pain for the SM implementor.
> And again, part of the point is that by adding just a little bit more
> code on top of the existing state-saving that you agree the app should
> be doing anyway, that the app gets both set-up-ability and
> resume-after-logout-ability (and, potentially in other session managers,
> recover-from-session-autosave-ability,
> multiple-different-set-up-ability, etc.)
As long as the layering is right (apps spend most of their code worrying
about the per-app/document state saving and not
per-session/special-global-save-event state saving) and then the
session-state-save is built on top, I think it would work out fine as
you say.
However, I think the only thing you need in the actual SM protocol in
order to do it this way is a single save-yourself signal for "save the
list of currently open documents and give me the .desktop file to stick
in autostart" - everything else in XSMP is cruft. (everything else state
saving related that is, again the logout notification is fine)
> If there was a strong argument for getting rid of XSMP to begin with,
> then I might not argue for adding XSMP-style session saving to its
> replacement. But if we want to keep XSMP for compatibility or whatever
> anyway, and if there's a salvageable feature (or two!) hiding in XSMP
> session saving, it seems worth it to keep that functionality.
I don't have a strong view on this, I just think it's a mistake to let
XSMP define what you're trying to accomplish. And if XSMP legacy keeps
the normal/useful kind of state-saving from working, or crufts up the
control panels, then I think it would be a shame.
Havoc
_______________________________________________
desktop-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
