GNOME Bugzilla – Bug 79285
Session Management support
Last modified: 2012-02-22 14:51:38 UTC
This is an outstanding item from the now-gone TODO file. Maybe this just means making sure that all runtime-configurable widgets (e.g. treeviews with reorderable columns) provide methods to serialize/deserialize their configuration.
I think the intention was to provide the complete set of needed primitives so that you could write a session managed app using only GTK+ That is, provide the equivalent of GnomeClient, though perhaps simpler and less XSM specific.
I think there are two aspects here: a) a framework which allows to save all "toolkit-internal state", e.g. paned positions, treeview expansion, textview cursor position, torn-off state of menus and handle boxes, etc. "toolkit state" should be anything that can be modified by user-toolkit interaction without any explicit support from the application. b) provide hooks which allow the application to use the same framework for saving application state, e.g. open files, network connections, etc.
If you really want to despair, consider that this also relates to the "saving window states"/"window history" threads we've had on wm-spec-list, e.g. maybe you want to save paned positions per-document or per-directory or across app startups (regardless of session)... Complexity is yay fun!
I've committed an initial "EggSMClient" proposal to libegg: http://svn.gnome.org/viewcvs/libegg/trunk/libegg/smclient/ README: http://svn.gnome.org/viewcvs/libegg/trunk/libegg/smclient/README?rev=789&view=markup main .c file with gtk-docs: http://svn.gnome.org/viewcvs/libegg/trunk/libegg/smclient/eggsmclient.c?rev=789&view=markup This is basically part b of Matthias's comment above: > I think there are two aspects here: > > a) a framework which allows to save all "toolkit-internal state", e.g. > paned positions, treeview expansion, textview cursor position, > torn-off state of menus and handle boxes, etc. "toolkit state" should > be anything that can be modified by user-toolkit interaction without > any explicit support from the application. > > b) provide hooks which allow the application to use the same framework > for saving application state, e.g. open files, network connections, etc. where part a would probably want to be tied to the GtkApplication framework that Emmanuele has been talking about. However, part b alone, while not perfect, does at least replace GnomeClient, and the new API is much simpler, and theoretically cross-platform. (I've figured out the outlines of how eggsmclient-win32 and eggsmclient-osx will work, though I don't have development environments to finish and test either of them.)
I still maintain GnomeClient can be destroyed (or converted to a "logging out now" notification) instead of replaced... xsmp is a rube goldberg way to implement matthias's point a)
(In reply to comment #5) > I still maintain GnomeClient can be destroyed (or converted to a "logging out > now" notification) instead of replaced... OK, fine. Here's my proposal to replace GnomeClient with a "logging out now" notification. It's called EggSMClient. Seriously, look at the API. This isn't GnomeClient 2.0.
I'm not trying to be a pain, I just don't see the value in all the code in libICE, libSM, gnome-session, metacity, GnomeClient, and the apps themselves - the simpler way that apps use on Mac and Windows works fine^H^H^H^H^Hmuch better and is easier to implement and understand. IMHO the desirable user experience is that state is saved anytime I close and re-open "the same" window, whether it involves relaunching an app, just opening and closing a window without relaunching the app, or logging in/out. I think a GTK+ API could make that "just work" Looking at the API, many XSMP relics are not afaics needed for the user experience I just mentioned: - get state dir (implies multiple states saved at once, which is required by the XSMP spec, but is pretty useless and introduces saved state file garbage collection problems, the need for a restart command separate from the regular Exec=, and probably other difficulties, in addition to API complexity) - get config prefix (ditto) - set restart command (the "save a command" model is fragile, hard to implement in apps, trickier cross-platform - it's good that this api makes manual restart command creation optional, but why have the weird XSMP way of doing things available in the API on all platforms - also, if there's only one global state, the restart command is just any command that runs the app, there's no special way to restart a particular saved state) - client registration (just do it automatically; if as an optimization it would be good to avoid registering if nobody connects to "quit", a boolean flag "emit the session lifecycle signals" might be nicer, or extend glib to let objects know when they have signal handlers attached) (also, if there is no SM or we don't register, the app should still save its state... i.e. across invocations that are in the same session) - option group (only needed because of restart command approach) - ability to end_session() (maybe useful to have some general "control the desktop" portable API including this and e.g. screensaver controls, but I would separate the issue of desktop environment remoting from state saving) I would keep: - quit-requested signal - quit-canceled signal - will_quit() - quit signal - gtk_ (or glib_?) set_desktop_file() which would a) tell some central process to consider putting the .desktop file in the autostart dir if the user "saves current setup" or whatever b) set the default window icon from the .desktop file c) g_set_application_name() from the .desktop file d) maybe more, don't know For state saving, one approach would be something like an API for telling gtk which windows/widgets are "the same" (via some type of window naming presumably) and have gtk just automatically save and restore window states given those window identifiers (with some hooks for saving/restoring extra info if desired). The saving and restoring would happen on the "quit-requested" signal but also whenever a window opens or closes, even within a single run of the app or within a single session. The *entire* burden on the app programmer would be to specify which windows are "the same window" - there would be no other calls to init, to save, to serialize state, handle signals, or anything else. All apps just work as soon as gtk knows which window in the new process is the same as one in the old, at that point gtk can do everything magically. An issue any kind of state save api has to address at least in the docs is which parts of window state the app is supposed to save vs. the environment or toolkit; according to XSMP, the app has to set window class and role in some certain way (don't ask me what way) and then the WM will save and restore window state. So the docs would need to tell apps exactly how to do this. On Windows and Mac GTK+ would need to emulate what the WM would do on UNIX. On UNIX, when there is no XSMP session (within a single app run or two app runs in the same session) then GTK+ should still imo save/restore window states and the WM will not, so the WM emulation should probably also be used on UNIX if there's no session restore in progress. I personally think the WM should be cut out of this, perhaps with some option for the WM to store extra state whenever the app is saving window state so WM-specific window features can be saved; there are some old wm-spec-list proposals along these lines (something like a property on each window that the app should save/restore when it saves/restores state). But for sure the class/role setting stuff needs docs, if using XSMP, since afaict nobody knows how it's supposed to work exactly. If inventing a new API with some way to mark "the same" window, there is a similar question to be answered, though starting from scratch it might be a little easier (class/role are overloaded for other purposes also unfortunately) Anyhow... it's not like I maintain GTK+ or am offering to write any code, I am just saying, I did implement xsmp from every direction at one point (msm, gsmclient, metacity, gnome-terminal) and my .02 is that it's fragile, too hard to implement in apps, and doesn't even produce the most important user result - that apps remember their state *within* each session. I see no real back compat issue, since apps using a "just remember their own state" model as I've advocated will work fine on an XSMP desktop. They can even register with the SM behind the scenes with no new toolkit API; the new API is required only because of XSMP's idea that it should be possible to save multiple states, if you drop that then the .desktop file has sufficient info to save the app and make it session-aware without any work on the app developer's part.
(In reply to comment #7) [...] > I see no real back compat issue, since apps using a "just remember their own > state" model as I've advocated will work fine on an XSMP desktop. They can even > register with the SM behind the scenes with no new toolkit API; the new API is > required only because of XSMP's idea that it should be possible to save > multiple states, if you drop that then the .desktop file has sufficient info to > save the app and make it session-aware without any work on the app developer's > part. IMHO there should be an API at least for at least asking the SM applications to save themselves, halting the shutdown/logout process for as long as necessary in order to allow the apps to present a file save dialog to let the user save their documents. Even if we all agree with your comments, they address the issue of state configuration; I'm talking about document persistence, which is much simpler to handle. This API _has_ to exist, either in GTK+ or elsewhere, but we are all converging to GTK+, so... just my 0.02€
> Even if we all agree with your comments, they address the > issue of state configuration; I'm talking about document persistence, > which is much simpler to handle. My "I would keep" list is the stuff for letting people save documents on logout, the "I would do differently" list is the stuff for state saving, so I think you are saying the same thing I was trying to say.
replying to just a few of the points, not entirely in order > - set restart command (the "save a command" model is fragile, hard to > implement in apps That's why it's not the primary interface. I originally didn't have it at all, but then I noticed that evince's save_yourself handler does just gnome_client_set_restart_command ("evince FILE1 FILE2 FILE3 ..."); because it already saves all of the document-related state independently of the session, so the only thing left to save for the session itself is the list of documents to open. And then it doesn't need any special resume support at all, because resuming the session with that command line is exactly the same as just opening those files at any other time. So basically, egg_sm_client_set_restart_command() is there to make things easier for apps that behave the way *you* think apps should. :-) But anyway, if we had a nice GtkApplication framework, it would hide all of this from the application so we wouldn't even need the convenience API. > - also, if there's only one > global state, the restart command is just any command that runs the app, > there's no special way to restart a particular saved state) I disagree with this; if I start gedit, open foo.txt, quit, and start gedit again, I expect it to start up with a new document. But if I start gedit, open foo.txt, logout and save session, and log back in, I expect gedit to start up with foo.txt. IMHO there IS such a thing as session state, although in most cases it's just the list of windows that are open at a particular time (as with the evince and gedit examples), and everything else should be considered document state. See http://live.gnome.org/SessionManagement/SavingState > - get config prefix (ditto) That's there solely for apps that want to be able to import old GnomeClient saved states when they're first resumed from an old session. > - client registration (just do it automatically There needs to be somewhere to pass in the .desktop file, although having that be an API totally unrelated to SM as you suggested is probably better. (Gtk needs something like gnome_program_new...) The other thing egg_sm_client_register() does now is let us distinguish between apps that want to be restarted but don't need to save any state, and apps that don't want to be restarted at all. Maybe we can get rid of the second group altogether, or have some other way for them to signal their non-restartability. > - option group (only needed because of restart command approach) The GOption setup would happen entirely behind the scenes if EggSMClient were moved into gtk. > - ability to end_session() (maybe useful to have some general "control the > desktop" portable API including this and e.g. screensaver controls, but I would > separate the issue of desktop environment remoting from state saving) Yeah, EggSMClient has 3 orthogonal pieces (save state, handle logout, initiate logout) that have to all be implemented together, but could be exposed to higher levels as entirely unrelated APIs. > I would keep: > - quit-requested signal > - quit-canceled signal > - will_quit() > - quit signal So just to be clear, while this gets rid of a bunch of API, it still leaves most of the actual code (~75%?). > The *entire* burden on the app programmer would be to specify which windows are > "the same window" - there would be no other calls to init, to save, to > serialize state, handle signals, or anything else. Yes, this is what I imagined GtkApplication doing; it knows what windows represent documents, and what sort of information needs to be saved for each of them, and it calls egg_sm_client_get() and connects to save_state on its own to save that state (and egg_sm_client_get_state_dir() at startup time to resume it). > I personally think the WM should be cut out of this Me too. > perhaps with some option > for the WM to store extra state whenever the app is saving window state so > WM-specific window features can be saved Just have the WM set a property on each window containing a list of window properties that the app (meaning the toolkit) should save and restore by itself. Then the WM doesn't need to care about application state at all.
> So basically, egg_sm_client_set_restart_command() is there to make things > easier for apps that behave the way *you* think apps should. :-) Right! But these apps don't need to set a restart command ; they just need to supply args to their .desktop file in the same way e.g. nautilus would if I used the app to launch a document in nautilus. That is, if the API is "set documents to open" or perhaps even more flexible, a callback to "get currently open documents," then the implementation inside gtk is much more flexible and doesn't lock in to xsmp wonkiness, and the app programmer API is also simpler. Even simpler in some ways, apps could simply save their open document list when they get a "logging out" signal, and not save their open document list when quit in other ways. But at least a gtk_save/load_uri_list convenience function might be nice. > I disagree with this; if I start gedit, open foo.txt, quit, and start gedit > again, I expect it to start up with a new document. > But if I start gedit, > open foo.txt, logout and save session, and log back in, I expect gedit to > start up with foo.txt. couple thoughts - - if gedit had only Close on each document and not a global Quit, as maybe the HIG at least used to say, then this situation can't come up - you can't quit gedit with any documents open unless it's at logout, so gedit could just save the currently-open list and assume it will be empty anytime we are relaunching instead of logging in - if Quit exists it could mean a couple things: - "close all documents" - here one would expect to get an empty document on next gedit launch - "save state and shutdown" - here one would expect to get the existing documents on next gedit launch if the former I think "close all" might be a better name for the menu item even... I guess there's some kind of design question here, I don't know what's ideal. In any case I think it'd be nice to avoid *multiple* saved states - i.e. when gedit exits, it can just decide whether to save the open document list or not. If the open document list is supposed to be saved on any quit, then there's probably no reason to involve SM/autostart at all, apps can just do this. If it's supposed to be saved only on logout and not on quit, then the gtk API could retrieve a URI list from the app and save it to pass to the .desktop file on login, or the gtk API could just ignore the issue and allow apps to save their document list only when getting a "logout" request and not in response to their Quit menu item. > So just to be clear, while this gets rid of a bunch of API, it still leaves > most of the actual code (~75%?). I would say that if arbitrary restart commands aren't allowed, and saving multiple states at once isn't allowed, then the code can *potentially* be a lot simpler (though really ripping out code involves an XSMP-free codepath, something I'd personally do but maybe others want to hold off on - the way I'd see phasing out XSMP would be to have it completely replaced and allow apps to use the "new way" exclusively, then allow the number of apps using the "old way" to decline over time). Session management could become little more than 1) list of .desktop files to autostart 2) a single session state per user, with a list of documents to pass to .desktop files 3) a couple method calls and signals for the orderly logout process. Well, and 4) all the random crap in gnome-session that has nothing to do with session management. One approach to the GTK API might be to have a special "xsmp compat" header that pulls in get_prefix and set_restart_command, with the documentation that these are xsmp-specific and may not be available on mac/windows or future linux, and are intended for quickly porting from GnomeClient.
I agree with some of Havoc's points here. Having a simpler api and relegating the xsmp relics (like restart-comand, config-prefix, etc) to a xsmp compat header sounds like it might be compromise. If we ever grow a GtkApplication/gnome_program-equivalent, a lot of the mechanics of connecting to signals on the client object and implementing state-saving can be hidden behind some higher-level api.
(In reply to comment #12) > I agree with some of Havoc's points here. Having a simpler api and relegating > the xsmp relics (like restart-comand, config-prefix, etc) to a xsmp compat > header sounds like it might be compromise. FWIW, I did make some changes after this, and never posted anything about them. In the current version in svn: - egg_sm_client_get_config_prefix() is gone; apps that want to support backward compatibility with GnomeClient can do it by hand. (Or perhaps we could add that to libgnomeui... Hm...) - egg_sm_client_register() is gone; egg_set_desktop_file() in EggDesktopFile takes care of setting an app-wide desktop file, which EggSMClient can then use as it needs. (And egg_set_desktop_file() also takes care of calling g_set_application_name() and gtk_window_set_default_icon_name().) But this makes this bug block on that bug. (bug 415070) - egg_sm_client_end_session() no longer takes an EggSMClient as an argument, making it clearer that it could be moved to some entirely unrelated part of the gtk API. (Its *implementation* is still tied to the rest of the smclient implementation, but that's hidden from the caller.) - (egg_sm_client_set_restart_command() is still there as a convenience API, but it could be killed off.) - The win32 backend works (sans state saving) - State saving is simplified, but not reduced to the model Havoc wants. The app is given a GKeyFile to save its state into, rather than having a whole directory to leak files into. The GKeyFile it is given is actually a copy of its own .desktop file, with the Exec key modified to include "--sm-state-file=%k", which means that in addition to being usable for ordinary XSMP session resuming, it also works as a launcher, which can be copied anywhere (eg, ~/.config/autostart, ~/Desktop, ~/.gnome2/panel2.d/default/launchers, etc) and will restart the application with exactly that saved state.
A recent datapoint, what we've ended up doing in some apps (e.g. mugshot and I think some other thing, I forget) is to copy the .desktop file to the user's autostart directory when the app is launched, and then if the app is ever explicitly exited, we remove the .desktop file. The effect is that the app autostarts unless someone explicitly quits it. The API for this functionality would look like "gtk_set_start_on_login(gboolean)" and would do something like the above on Linux and something else on Windows. This isn't right for all apps but I think is right for say an IM client, Mugshot stacker, maybe a music player that has a tray icon mode, Tomboy, that sort of "desktop component" or "environmental" app. btw, please, take my opinions as just that, though hopefully the rationale I'm giving is at least understandable even if not convincing. Summarizing again in short form what I see as three separate "big picture" problems: - toggle whether the app is auto-started (my suggestion: add/remove .desktop files from autostart dir) - logout notification and negotiation (my suggestion: XSMP should be supported, different thing on Windows, protocol opaque to the app; eventually, we should first look for a dbus service that does this, and fall back to XSMP) - save window states (my suggestion: just have gtk write to a config file or config system, the hard part is which parts of window state to save and which windows are "the same") To kill GnomeClient, I think it would be great to add to GTK an API for logout notification and negotiation, which would use an XSMP backend to start, and a toggle-autostart API that just adds/removes the .desktop file. I'd probably punt the saving window states and do it as a separate patch, since it's relatively hard. However, the goal is really to enable specific user experiences, right - not to replace GnomeClient. GnomeClient was designed to support some wrong user experiences (e.g. multiple sessions), and failed to support some important ones (e.g. saving window states *within* a session, automatically, and per-document), IMO. Just guessing on what you're trying to accomplish by keeping more of XSMP: is the perceived benefit the ability to set up a desktop, say the arrangement of terminal windows you want, and then say "save this and restore it on login"? If so, my first question is: what apps does this apply to other than the terminal? Do we need a generic feature for all apps? Everything I can think of that should be part of a "save my setup," except the terminal, is an "environmental" app like Tomboy, gkrellm, panel, Mugshot, music player, and I think the way those should work is that they just always remember their current state, *including* whether they are currently running. If these just remember their state, an explicit "save my setup" is not needed. I don't know if this is mostly an API problem or mostly a HIG problem. The terminal is unique because you might want it open on login (probably unlike document editor apps); *and* because the terminal's on-login state tends to be distinct from "the last state I had it in." Most apps either aren't useful to open on login (document editors) or their last state is a reasonable guess at the right login state (Tomboy, gkrellm, etc.) If I'm missing the point, or didn't see the thread I should have read, please point me there. To be productive rather than entirely stop-energy: why not just go ahead and put the "logout notification and negotiation" API into GTK, backed by XSMP, which would let many apps start dropping GnomeClient. Then split out and attack the other problems (set_start_on_login(), window state saving) as separate problems, with XSMP as an available tool to solve them? That way most of this code can (probably, I'm not a maintainer) go into GTK pretty quickly since the thorny questions about state saving wouldn't arise. Or maybe I'm the only one that thinks state saving is hard (and best done without XSMP), in that case who knows why this isn't in GTK yet, probably just a matter of harrassing the maintainers enough...
re-reading some of the older comments and what I was just writing, I wonder if there are two different models people have in mind. One we might call the "GNU screen" model; attach/detach, or "I want to be able to logout and login and be right back where I was." The other one, which I'm advocating, is more a specific list of UI behaviors, where apps try to remember what you wanted, and the desktop stays how you last configured it. Maybe this model gets tweaked with some specific features, like a terminal app having a "windows to open on login" feature. Whichever is desirable (maybe both), any API in GTK should be very clear on which of these it is, perhaps mixing the two or having app authors confused about which one they are doing, would result in neither one working properly. Making it more concrete, an example that came up earlier in this bug is evince savings its open documents. For "GNU screen attach/detach" then of course it needs to save this (and the state of each document window, e.g. scroll position, the works). However, my view is that the logout/login should "reset" the desktop, not "reattach," and the documents you had should not come back. Your last settings and "environmental" setup should come back. You should have a list of recent documents if you want to click to open them. If you open a previous document, the window size etc. should be remembered. But whatever mess of stuff you had open should not be automatically restored when you log in again. In the "reset with certain handy things remembered" model, apps have to decide whether to save each piece of state, with some apps and state coming back across a logout/login, and other stuff getting reset. In the "reattach" or "GNU screen" model, apps are supposed to remember everything they possibly can, and the set of running apps is also restored exactly. The goal is a snapshot. Is the only difference between these two whether the list of open documents is saved? I'm not sure that's the only difference, but maybe it is. If it is the only difference, then perhaps if we think of the feature as "remember my open documents" rather than "save current setup," it makes both API and UI clearer; in other words, we'd want to design the desktop to *always* save pretty much everything, but then have this optional check box or whatever to also remember your open documents instead of resetting to a clean desktop. An example of how "remember my open documents" differs from "save current setup" is that if you run an environmental app like gnome-panel, it would *always* remember that it was running and restart on login, with no saving of current setup first. However, with gnome-session today, if you add gnome-panel and didn't have it before, you have to save current setup to keep it.
> Just guessing on what you're trying to accomplish by keeping more of XSMP: > is the perceived benefit the ability to set up a desktop, say the > arrangement of terminal windows you want, and then say "save this and > restore it on login"? When I started working on it, yes, that was the one of the big use cases that people really seemed attached to. The gnome-session rewrite that I was also working on supports having exactly two saved states, to separate out the ideas of "setting up a base session" and "resume this current session on next login". (If you save-on-logout, it would save a new current session, which would be resumed on next login, but the base session would be untouched, and if you didn't save-on-logout again on the next logout, the following login would be back to the base session.) Another issue is that for SUSE, compatibility between GNOME and KDE is important, and KDE seems happy with XSMP (and at the time, had a summer of coder working on things like having ksmserver autosave your session at regular intervals, so you could recover from crashes. Though I'm not sure that went anywhere). A GNOME SM solution that uses XSMP but only supports a single saved state might end up behaving incorrectly under KDE. So my goal was to make the simplest possible API that still implemented XSMP correctly in all cases. (So, eg, if the caller always saves its state to ~/.gnome2/FooApp/state, it won't work correctly in a desktop environment that supports multiple saved states. But the GnomeClient way of making the app author choose a unique file name each time sucks [and most apps got it wrong]. So EggSMClient splits the difference by picking a unique filename itself, and then requiring the app to save its state into that file [and it deals with setting DiscardCommand appropriately, etc]. The app has no way of even being able to find out whether the SM is doing a single saved session or multiple ones.) A third factor was the general feeling that "gtk doesn't impose policy", and so a generic sm client that could have various different possibilities built on top of it was more "gtk-like" than one that imposed a single vision. (Lately gtk has been a lot less anti-policy than in the early GNOME 2.0 days, but in this particular case it's relevant that XFCE also uses XSMP and might not want a simpler model.) (And FWIW, I think you're right that the terminal is a totally oddball use case.) > To be productive rather than entirely stop-energy: why not just go ahead > and put the "logout notification and negotiation" API into GTK, backed by > XSMP, which would let many apps start dropping GnomeClient. I'm not sure about that. I surveyed all of jhbuild back when I started this, and I only found two apps that did logout notification/negotiation (gedit and gnumeric). Certainly part of this is that GnomeClient makes logout handling incredibly difficult, but it also makes state saving pretty hard, and there are about two dozen apps that try to do that anyway (including gedit and gnumeric; there are no apps that do *just* logout handling). Of course, it's not clear if app authors really *wanted* to support state saving, or if they just thought that it was *expected* of them, but that still applies just as much now; unless we had a GNOME-wide consensus that XSMP-style state-saving is bad, it seems like app authors would be reluctant to drop support for it. > the goal is really to enable specific user experiences, right - > not to replace GnomeClient. Sure. Come back when you've figured out what specific user experiences the GNOME community wants to enable. ;-) Which comes back to having policy-free sm client. If we make GtkSMClient DTRT regardless of what model of saved state the desktop supports, then it becomes easy for us to change gnome-session's model later on in the unlikely event that there should actually be a consensus about GNOME's future direction. Or more plausibly, it makes it easy for Fedora to ship gnome-session with one set of gconf defaults and SUSE to ship it with another, and have apps work well in both. But anyway, I mention all of this just to explain what I *was* thinking at the time. I don't care enough about it to actually want to argue any more. If people want EggSMClient minus state saving, I'm totally fine with that. If people want to throw out EggSMClient entirely, I'll be sad, but whatever. I'm sad about GNOME anyway. :)
> A recent datapoint, what we've ended up doing in some apps (e.g. mugshot > and I think some other thing, I forget) is to copy the .desktop file to the > user's autostart directory when the app is launched, and then if the app is > ever explicitly exited, we remove the .desktop file. The effect is that the > app autostarts unless someone explicitly quits it. > > The API for this functionality would look like > "gtk_set_start_on_login(gboolean)" The last round of autostart update proposals I posted to xdg-list (http://lists.freedesktop.org/archives/xdg/2007-January/007436.html) used an "AutostartCondition" key based on KDE's X-KDE-Autostart-Condition, where the idea was that apps that want to be able to have themselves autostarted sometimes would just have their .desktop file in the system-wide autostart dir unconditionally, but gnome-session would only actually autostart them if a certain GConf key was set. This is much easier for the app to deal with than the moving-.desktop-files-around solution, for reasons explained in the post linked above. (It's also already implemented in new-gnome-session, http://svn.gnome.org/viewcvs/gnome-session/branches/new-gnome-session/, which btw lucasr is planning to start hacking on.)
OK, I'm going on the assumption that someone cares / will work on this / will want to figure out the right thing eventually ;-) even if it's not someone on the cc list right now. My worry about policy-free is it doesn't appear to work - going back to the example of say I run an "environmental" app for the first time, gnome-panel or mugshot or Tomboy. What I'm saying should happen is that this app should *automatically* become resident / autostart, until I quit it explicitly sometime. That's just not compatible with XSMP... unless the desktop sits there and does a session-save every 10 seconds or something, or always does one on logout, but then stuff that *shouldn't* be saved gets saved - like (IMO) the list of open documents. Re: KDE compat, I think if GTK apps just always remember their state globally, that is good enough for everything except people doing multiple sessions; and if GTK apps have the same state for two saved KDE sessions, it does not seem like a big deal to me. For logout notification, GTK apps should work fine if XSMP is used for that. > Come back when you've figured out what specific user experiences the > GNOME community wants to enable. ;-) Yeah. I would just say, a good API has to assume some user experience, and so we need to choose. If we can't choose user experiences, then it's impossible to design APIs either. (As a tangent, I don't believe in policy-free in general; I think it's always more precise to talk about module boundaries / abstraction layers. For example, I think it's more precise to say that X11 is responsible for the "hardware abstraction / coordination of the display device across multiple apps" function, with higher layers implementing other functions, than to say that X is "mechanism not policy" - I use the X11 example since X seems to have invented this mechanism vs. policy rathole. I think the "GTK has no policy" thing was a crock that never offered meaningful guidance on what to put in libgnome vs. gtk. Another way to say it, all mechanisms are policies for the layer below, and all policies are mechanisms for the layer above, and so "mechanism not policy" is an empty statement. The non-empty statement is to define the scope and purpose of the module in a way that crisply divides it from the surrounding modules.) I think GTK should define itself as a GUI application framework that makes it easy to do the standard/expected user experience on each platform. So on Linux, I think GTK needs to have a user experience decision here and make it easy for apps to implement that.
So EggSMClient has been getting more and more popular. 2.26 will probably have more apps using EggSMClient than using GnomeClient... EggSMClient supports the gnome-session 2.24 D-Bus API now, although it doesn't use it by default, because the D-Bus API doesn't support state saving, and most apps that are using EggSMClient still expect it to be doing state saving (although maybe the fact that this is broken in gnome-session 2.24 anyway will make people give up on it :). EggSMClient also has working OS X support now (for logout notification and negotiation, which is all OS X does). I know that the new gnome-session 2.24 logout inhibit D-Bus APIs were inspired by Vista's, so presumably it would be possible to add an inhibit-type API to EggSMClient which could work with the win32 and dbus backends, with a fall-back implementation for xsmp and osx (where it would just block the logout itself using the old APIs and pop up its own "i'm inhibiting logout" dialog). Jon has pointed out that the current style of explicitly allowing each app to interact with the user itself does not work well in a fast-user-switching environment, since the apps on user A's desktop are not going to get a chance to do anything if user B tries to reboot. Whereas with an inhibit API, if there was some way for the two gnome-sessions to both communicate their inhibit status to gdm, then it's possible that when user B tries to log out, he could be warned that user A has applications that are requesting to not be logged out right now.
Lots of GNOME applications have copied EggSmClient into their codebase to get rid off GnomeClient / libgnome dependency for GNOME 3. Are there plans to get this officially included into GTK+ soon?
(In reply to comment #20) > Lots of GNOME applications have copied EggSmClient into their codebase to get > rid off GnomeClient / libgnome dependency for GNOME 3. > > Are there plans to get this officially included into GTK+ soon? No. The problem is basically that the people who have an opinion on this subject can be divided into two groups: 1. Those who have managed to bend XSMP to their will. 2. Those who either never tried to use XSMP, or else tried and failed. The people in group 1 want to block any attempt to get rid of XSMP in GNOME (qv the whole gnome-session 2.26 thing), because it is a useful feature for them. And as long as XSMP sticks around they have no real incentive to implement a better replacement for it, because XSMP works fine for what they want to do (since "what they want to do" was shaped by what XSMP can do). The people in group 2 want to block any attempt to add XSMP to gtk (qv this bug) because XSMP is a horrible gross hack that will never work right for most users, and as long as they can do that, they have no real incentive to implement a better replacement for it either, because they're used to not having any session-saving solution and are fine with that. So we remain deadlocked, with application authors feeling like they're not allowed to just drop XSMP support, but with no part of the platform willing to take it on. The right way out of this is clearly for the release team to mandate that EggSMClient MUST be added to gtk for GNOME 3.0, under the assumption that this action will force Havoc to finally implement something better and save us. ;-) Perhaps a more plausible compromise would be to move EggSMClient from libegg to gnome-session (which already has a copy of it anyway), and add a libgnomesession or something, which would be part of the desktop, not the platform, as a way of letting us put off the decision for longer while still getting rid of the egg copy+pasting. This actually makes a moderate amount of sense, since then once we do figure out what we want to do with the client/manager protocol, we can make the changes in the client and server all at once in one place.
To characterize my opinion a bit better, I think group 1 doesn't exist, because XSMP simply can't implement a useful UI design for state saving. People may have managed to successfully implement some kind of useless behavior, but... yay. I didn't try and fail to use XSMP in the sense that I couldn't make it work; I implemented the client side AND server side AND window manager side of XSMP, but concluded that the resulting interaction design (user-visible behavior for state saving) is _useless_ - it's just pointless busywork for developers. As I said I think it's fine for notification "we're about to log out," but just broken for state saving. So the GTK API should just be about logout notification. Apps can perfectly well implement state saving already; using a config file or gconf or whatever; Epiphany does it, for example, among others. There's no need to use XSMP. People should not. EggSMClient should be flat ignored. I think the right way out is for the release team to declare that supporting state saving via XSMP is deprecated. Just drop the feature. It's a bullshit feature. It only ever existed because it was in a spec, and that spec is something like 20 years old, created in a world of twm for god's sake. Just put a bullet in it. Just delete all this code! Problem solved. People are just hitting a nonexistent nail because there's some hammer (EggSMClient) that they are cutting and pasting around without any thought. The bottom line, I think, is this needs to go top down. Someone document the desired UI. Then you can implement API support for it. Release team (or GTK maintainers) should force the UI design, if they force anything. A nail in the coffin of XSMP state-saving model is that it's totally wrong on Windows and Mac. Dan implies that I'm arguing against XSMP on the grounds that we should wait for something better. I'm actually saying that something is worse than nothing in this case, because apps can (and should) just implement state saving with gconf or a .ini file, which isn't that hard. An XSMP API leads people to _waste time_ implementing something useless. So my view is that XSMP is actively worse than nothing (for state saving, not logout notification, of course). I don't think XSMP state saving is even 1% as useful as state saving that spans running the same app twice (at different times) *within* the same session. Neither Mac nor Windows nor iPhone nor anything have the equivalent of XSMP in the platform, so why is it urgent that GNOME have it? I don't see users or designers clamoring for this. It's not some innovative feature that makes GNOME better. Code (and UI) that isn't clearly necessary is bloat. Anyway, it's not like my opinion matters, I don't get to decide. I would just appeal to people's self-respect: if we would not design what XSMP does in a top-down interaction design, but we keep XSMP, we suck. If we can't make a decision on the intended interaction design, we suck. If the designers (or even the developers) design a UI and XSMP actually works as an implementation of it, then great. If people are just all "hey, we have this code, let's use it" then fail.
(In reply to comment #22) > To characterize my opinion a bit better, I think group 1 doesn't exist Um... I think you missed the last few chapters of the saga. Jon dropped support for state saving when he completed my rewrite of gnome-session, and GNOME 2.24 shipped with no support for saved states. Some people filed bugs pointing this out. Eventually people realized that the lack of state saving was an actual design decision, not merely a bug in the code, at which point they went ballistic. There was lots of flaming in bugzilla (bug 552387), angry blog posts, rants on forums, etc. If you google for just "gnome-session", the launchpad bug for the lack of state saving in 2.24 is on the first page of hits. Group 1 exists... and they vote! Anyway, as a result of all of this, the release team more or less mandated that state saving be reimplemented for 2.26, which it was. > I think the right way out is for the release team to declare that supporting > state saving via XSMP is deprecated. Right. Implicit in my comment was the fact that we had already tried to do this and failed. I was assuming that the release team was not likely to simply pull a 180, and that therefore, the only way we would be able to get rid of XSMP would be to replace it with something that we could plausibly argue was in some sense "better". But as I said, no one is working on any such thing; lots of people *say* "everything should autosave, that would be way better than XSMP", but no one is actually writing the patches.
> Anyway, as a result of all of this, the release team more or less mandated that > state saving be reimplemented for 2.26, which it was. And we are dealing with the fallout from this design breakage all over the desktop since then. I am not very inclined to take design advice from the people who inflicted that pain onto us, when we had just gotten rid of it.
> Um... I think you missed the last few chapters of the saga. Indeed, had not seen bug 552387 and didn't know you already did stuff. Thought it was blocking on this bug. I only had this bug as context. Apologies. I commented on this bug again because it was linked as a GNOME 3 todo item in order to get rid of the Egg stuff. I still don't think GTK changes are needed to get rid of the Egg SM stuff. > lots of > people *say* "everything should autosave, that would be way better than XSMP", > but no one is actually writing the patches. But these patches should not require a GTK feature. The way to port off EggSMClient (which keeps getting mentioned in "Project Ridley" type task lists) is to just implement state saving. You can use GKeyFile or GConf or whatever. GTK could certainly have a convenience API or something, but it's hardly required or even that useful. To use XSMP you already had to do all the hard parts... I mean, if you want to be hacky, just save the command line options you would have passed to XSMP in a file, and then merge them with the actual command line whenever you start up... or do some less-hacky conceptual equivalent. I don't see how a GTK feature is needed in order to port off EggSMClient, because apps don't need a replacement, they need to just stop caring which XSMP session they are in, and stop waiting for some XSMP signal before they save state. State can/should be saved always, which means the XSMP notifications about when and where to save it aren't relevant. Useful GTK features might include: * logout notification * convenience API to save/restore window geometry or even all widget states * ways to get internal widget state (see early comments on this bug) * way to add/remove .desktop from the startup folder See earlier comments on the bug (comment 11, comment 14, etc.) But I still think "Session management support" (the bug title) is not something GTK should have. Maybe there should be separate bugs for the specific changes. logout notification is the one that maybe blocks dropping EggSMClient, but also seems like an uncontroversial patch. People can get rid of EggSMClient in their app today and switch to the "right way," at least for state saving. And if that breaks things, the bug is probably in the desktop, not GTK. I understand your comment 21 better now, in any case, thanks.
The wiki seems out of sync with this bug: http://live.gnome.org/SessionManagement/EggSMClient It says EggSMClient is targeted for GTK or GLib. Is that true? The wiki basically encourages everyone to port to EggSMClient on the grounds that it is going in GTK later. If that's the plan it's the right thing for the wiki to say, of course, but it would be nice if the GTK maintainers said the same on this bug (and as time permitted, reviewed EggSMClient and put it in). If it's not the plan, then app developers are being encouraged to waste time, and it's not surprising that there aren't any patches to do things in the way I would argue is right, since there's no guidance telling them to do so. If there is no plan maybe the wiki should say "don't spend time on this yet, please" or "please help figure out the answer" Anyway, whatever. Look I'm just pointing out what I think makes logical sense, for that matter what I'd prefer as a user (I'd like to get my app state back if I just quit the app and restart it, for example). It's also what I'd prefer as an app developer (continuous state saving is easier to code, more cross platform, more likely to get tested). But seriously, nobody should think I'm blocking anything - hopefully nobody does. It's fine to make a decision and move on and ignore bystanders. The main reason I bother to post on this is that (as you can tell) I have an opinion that there's a right decision which is both a better UI _and_ less work, so I keep hoping it's just a matter of figuring out the right way to explain it and people will say "oh! we don't need all this code after all, session management is not a useful concept, really we can unbundle and address separately several features like logout notification, state saving, and startup programs" But, just pick something, surely that's what everyone cares about most, is that some decision is made and life goes on.
(Punting gnome-target - not going to happen for GNOME 2.28)
Havoc, I think most of the people are using EggSMClient to get rid of gnome-client code, what do you suggest to replace it?
In Xfce we also wrote a new session client. We tried EggSmClient, but it didn't really worked for us (we only used the XSMP backend). Code can be found here: http://git.xfce.org/xfce/libxfce4ui/.
Javier, as I said in comment 5 three years ago, and on mailing lists before that, I think the feature is just a wrong feature and should not be replaced (at least not in its entirety; some of the same use-cases should be addressed in different ways, and some of the use-cases were just dumb and don't matter). In short, if there had never been a GnomeClient, I don't think anyone would want to add EggSMClient or add XSMP to GTK+. This is a relic from the same era where GNOME thought it made sense to use Guile, and have GnomeLamp, and have drawers on the panel, and other such highly questionable decisions. XSMP is historical baggage. So you ought to go back to first principles, state what user experience is best (and achievable), and implement it sensibly. I mentioned the three things I would address in e.g. comment 14. Maybe others have other stuff in mind. But, I am not voting or something. I'm not doing any work on this code or any app that uses it. I don't maintain it. As I said in comment 26, what needs to happen here is someone just making some decisions. That isn't me, I'm not the relevant person. I would recommend tracking down some GTK maintainers at a conference or on IRC and just asking them to say yes or no or "we should do xyz" because really any decision here is better than leaving the bug open forever and having app developers not know what to do.
I'm not sure that will help the debate, rather the contrary, but... In the perspective of creating a framework for "activities" or "desktop contexts" (i.e. allowing the user to save and restore later a set of applications, see [1]), we would need apps to be passed an identifier that would allow them to restore a certain state only when asked. For example, you could have two GNOME Terminal windows, one that you use when hacking on GTK+, the other one when hacking on you pet project, and you would only restore one of those at a time. That should not be too hard since apps can save their state in a file named after the ID (or something like that), and only read it when you tell them to restore that precise ID. Now, I know the idea of "desktop contexts" is not highly supported and can be considered as dubious even if that's relatively popular among users we hear on mailing lists. I think it's worth the pain. Passing that ID means we can't leave apps do all of their job by themselves, they need to support that minimal framework; that's not equivalent to bringing back that terrible XSMP either! How do you feel this would fit in a new API? Not really hoping I may have convinced you, still... 1: http://live.gnome.org/GnomeShell/DesktopContexts
(In reply to comment #7) >... > For state saving, one approach would be something like an API for telling gtk > which windows/widgets are "the same" (via some type of window naming > presumably) and have gtk just automatically save and restore window states > given those window identifiers (with some hooks for saving/restoring extra info > if desired). The saving and restoring would happen on the "quit-requested" > signal but also whenever a window opens or closes, even within a single run of > the app or within a single session. > > The *entire* burden on the app programmer would be to specify which windows are > "the same window" - there would be no other calls to init, to save, to > serialize state, handle signals, or anything else. All apps just work as soon > as gtk knows which window in the new process is the same as one in the old, at > that point gtk can do everything magically. > >... Hi all, I want to raise the problem of saving&restoring of application windows positions (size and location on screen). Some facts: 1. GTK documentation states several times N>5 that it is WM task to place windows on screen, so "don't touch that gtk_window_get_position(), gtk_window_move() etc", http://library.gnome.org/devel/gtk/unstable/GtkWindow.html#gtk-window-get-position ; by the way, Rhythmbox, Evince still use them cause they really need them. 2. There are many complaints/requests from users to save&restore app windows positions, e.g. http://brainstorm.ubuntu.com/idea/1442/ , https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/124315 ; the answer to them is "the Gnome development team will not develop Gnome to handle these issues. Saying it is the job of the application to save its state of size and position". So, it is ridiculous to see the point 1 and point 2 together. 3. Ideally, WM should do positioning; but it cannot without additional info from applications. So, as app developer, I suggest a simple API with just one function like this: void gtk_window_position_by_id(GtkWindow *window, const gchar *id) I do not want to force its implementation, but it must solve the problem above. For example, in most cases, when WM is not against explicit positioning (like ubiquitous Metacity and KWin) the functon can be implemented like this: void gtk_window_position_by_id(GtkWindow *window, const gchar *id) { int x, y, w, h; // * loading load_position_by_name_and_binary(id, glibtop_get_proc_state(getpid()).cmd); gtk_window_set_default_size(w, h); gtk_window_move(x, y); // * delayed saving g_signal_connect(window, "configure-event", cache_size_and_position); g_signal_connect(window, "destroy", save_cached_size_position_in_file_or_db_or_etc); } If WM do not like gtk_window_move(), just do nothing. Surely, that simple API is not suitable for every app and may be extended in those cases. What GNOME devs think about the problem and the suggestion? Regards, Ilya Murav'jov
Yes, I can't seem to google up the discussion, but I do think it is correct to set default size and call window_move (and even restore things like maximization), only after the first time the window is shown of course. And I do think the API you propose is pretty much the right one. (Apps must provide an ID to identify "the same" window across runs of the app.) GTK could possibly default to the same kind of heuristic that many WMs use - identify "the same" window using window semantic type, class and title, or whatever. Build an ID based on that stuff. Possibly also, never (by default) save window state for dialogs etc.
While this seems really useful and interesting, I think the implementation will have to deal with some more complicated cases, particularly wrt. different screen geometries (laptops, beamers, extra monitors, and so on). That said, as an end user I'd really appreciate it if GTK/Metacity transparently persists my preferred window layout, especially for frequently used applications like my browser, mail client, and so on.
Better to deal with the complex cases in the library than per-app. (In general, remembering state per-monitor-size-or-setup may be right.) metacity can't do it. The window manager does not know which windows are 'the same' window across invocations of an app. The minimum fix for that is for apps to mark 'the same' windows with an ID... which is exactly this API. In the future, EWMH could invent a hint in which the ID would be provided to the WM. (Or class/role/something could be overloaded, but according to the letter of current specs, iirc those things can't be this ID. though nobody really complies with the current specs anyway.) If the WM could do this reliably without screwing it up, then most window managers probably would. But there's no way to implement it.
I don't think this qualifies as a gnome3 blocker
EggSMClient needs to be ported to GTK+ 3: http://git.gnome.org/browse/libegg/tree/libegg/smclient
Starting with GTK+ 3.4, GtkApplication supports logout notification and negotiation similar to EggSMClient.