[gnome-session.wiki] Update Session Saving Notes

[Ray Strode <halfline src gnome org>]

commit 8ee71e403035d26d740c70a654e2c72813655824
Author: Ray Strode <halfline gmail com>
Date:   Mon Jan 17 17:51:48 2022 +0000

    Update Session Saving Notes

 Session-Saving-Notes.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
---
diff --git a/Session-Saving-Notes.md b/Session-Saving-Notes.md
index 8b437e9..72ad3e0 100644
--- a/Session-Saving-Notes.md
+++ b/Session-Saving-Notes.md
@@ -9,8 +9,7 @@ Broadly speaking, there are two main parts to application session handling: Ensu
   - Flatpak'd applications can use the [autostart flag of the RequestBackground xdg-portal 
API](https://flatpak.github.io/xdg-desktop-portal/#gdbus-method-org-freedesktop-portal-Background.RequestBackground)
 to get automatically started at session login.
   - Under the hood, this API just writes out an [autostart desktop 
file](https://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.html) which is started by 
gnome-session. 
   - systemd has [support for loading autostart desktop files](https://github.com/systemd/systemd/pull/15226) 
now, too, but we aren't currently using it. There's [a 
branch](https://gitlab.gnome.org/GNOME/gnome-session/-/tree/benzea/systemd-condition-evaluator) that gets us 
closer to using it, but [it may not be worth the 
effort](https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/13#note_496268)
-
-- There's not yet a general API for requesting an application gets started when the starts.  There's a 
request for [adding one to GLib] (https://gitlab.gnome.org/GNOME/glib/-/issues/2445)  though the API is yet 
to be determined. We should figure that out and probably make it use the xdg-portal api transparently under 
the hood for flatpaks.
+- There's not yet a general API for requesting an application gets started when the session starts.  There's 
a request for [adding one to GLib] (https://gitlab.gnome.org/GNOME/glib/-/issues/2445) though the API is yet 
to be determined. We should figure that out and probably make it use the xdg-portal api transparently under 
the hood for flatpaks, or alternatively figure out what a new portal api might look like if the existing one 
doesn't fit well.
 
 ## Application Saving
 - There are some aspects of session saving the application can't directly control. For instance, the 
workspace an application is started on or its global position.  Applications will need some way to request 
mutter opaquely track that information on a surface by surface basis, and then upon app start up the 
application could request that mutter put specific toplevel surfaces "back the way they were before".  
Samsung has one proposal for such [a protocol] 
(https://lists.freedesktop.org/archives/wayland-devel/2018-February/037236.html).
@@ -20,4 +19,5 @@ Broadly speaking, there are two main parts to application session handling: Ensu
   - There's some concern that having all applications handle this on their own could lead to the "thundering 
herd" problem where many different applications are all saving at the same time.
   - There's also the reality that the bits of application state that mutter should track (like workspace 
etc) need to be stored separately from the rest of the application state.
   - There's a proposal to consolidate state saving behind an api provided by gnome-session 
[here](https://gitlab.gnome.org/pwithnall/gnome-session/-/commits/session-restore). It provides a new 
`RegisterRestartData` method where the application tells the session manager about a GtkApplication bus 
object that has `RestartData` GVariant property on it. The GVariant gets synched to a gvdb managed by 
gnome-session.
-
+    - That proposal also automatically starts applications at session start up that use it.
+    - I'm a little leery about consolidating state between various sandboxed applications in one central 
place, just because it opens the possibility that one app might be able to look at another apps state.
\ No newline at end of file