GNOME Bugzilla – Bug 536685
applications from legacy session file are not started
Last modified: 2009-03-08 21:33:03 UTC
append_legacy_session_apps() will append applications from ~/.gnome2/session to the list of applications to start; however no phase (GsmApp->phase) is given to them, so they get GSM_SESSION_PHASE_STARTUP (0), while the first start_phase() call is done with GSM_SESSION_PHASE_INITIALIZATION (1). This means those applications are not started. I worked around it with the following patch but it may not be enough as applications are then started but they don't seem to get their sessions correctly restarted (window/workspace position and such things). --- app-resumed.c (revision 4718) +++ app-resumed.c (working copy) @@ -79,9 +80,12 @@ "client-id", id, NULL); + GSM_APP(app)->phase = GSM_SESSION_PHASE_APPLICATION; + key = g_strdup_printf ("%d," SmProgram, n); val = g_key_file_get_string (session_file, "Default", key, NULL); g_free (key);
I haven't tried out this patch. but by looking at this, some part of this may not work since a typical session file will contain the window manager, panel, file manager, all these are started before the GSM_SESSION_PHASE_APPLICATION phase. Since the legacy session apps are loaded last, those apps which have been started in the earlier phases will not be happy. Some kind of filtering would be necessary.
(In reply to comment #1) > I haven't tried out this patch. but by looking at this, some part of this may > not work since a typical session file will contain the window manager, panel, > file manager, all these are started before the GSM_SESSION_PHASE_APPLICATION > phase. Since the legacy session apps are loaded last, those apps which have > been started in the earlier phases will not be happy. Some kind of filtering > would be necessary. That could be solved easily by simply matching desktop files to XSMP and resumed apps and inheriting the desktop file settings (phase / is_disabled / is_conditionally_disabled) to the resumed/XSMP entries by reading the startup id from the legacy app entry, removing the legacy entry and adding the desktop file entry (all that in gsm-manager.c:append_app).
Created attachment 122081 [details] [review] Proposed fix Patch as described in comment #2. Starting apps from an old saved session works beautifully now (when used together with my patch in bug 559450). This patch also obsoletes (includes a better version of) the diff in the original report.
(In reply to comment #3) > Created an attachment (id=122081) [edit] > Proposed fix > > Patch as described in comment #2. > Starting apps from an old saved session works beautifully now (when used > together with my patch in bug 559450). > > This patch also obsoletes (includes a better version of) the diff in the > original report. This patch has one problem, though: The provides list is not inherited from the desktop file to the resumed app entry. This is not a problem for most apps, but for the required ones: If e.g. compiz is started with the session and metacity is started as required app, it will depend on timing which WM you'll end up using. Probably the better fix would be to - Try opening the desktop file corresponding to SmProgram in gsm-resumed-app.c - Inherit phase and provides from there, if possible.
We won't support the old saved session file anymore as it's pretty much incompatible with the current gnome-session code. Session saving has been implemented in a new way now (bug #552387). Closing this one as WONTFIX.