Re: The future of session management in GNOME

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 /
 - 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,
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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]