Save and restore may be coming to GNOME

LWN.net needs you!

Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing.

One of the features that users often miss when moving from X11 to Wayland is the ability to save and restore the position of windows between sessions. At GUADEC 2026, held in A Coruña, Spain, Adrian Vovk provided an overview of work that has gone into providing a platform-wide save and restore framework for GNOME. After two failed attempts at landing an API, he believes that the third try will be the one to succeed—though not in time for the upcoming GNOME 51 release due in October.

I did not attend GUADEC in person this year, but I watched the video of Vovk's talk after it was streamed. The individual talk videos have not been posted yet, but his talk is available at 5:40 in the full video from day two of the conference. The slides from the session have not yet been posted.

The idea behind the save and restore feature, Vovk said, is simple. A person is using their system and has applications open while working on something, then they need to log out of the desktop or reboot for some reason. When they log back into their desktop, they would like to restore the previous session: that is, application windows resume their previous positions and sizes, re-open the same documents, and so forth. Currently this is not possible in GNOME, at least not without additional extensions.

There are GNOME extensions that try to emulate this behavior, such as "Restore Geometry" and the creatively titled "Another Window Session Manager". However, the functionality is arguably something that should be available in GNOME itself.

Benefits

Save and restore is a commonly requested feature for GNOME, Vovk said. Its absence is also something that people often cite as a deficiency in Wayland when comparing it to X11. It has practical benefits, he noted, in recovering from application and system crashes.

He said one of the benefits he found most interesting about save and restore was that it could encourage users to update more often. Updates often require rebooting the system, and users of immutable systems must reboot to apply updates: "However, rebooting the system is quite disruptive. You lose everything you were working on." He admitted that he would get his workspace set up as he liked it and avoid applying updates for one or two weeks so he would not have to start over again.

The groundwork for save and restore could also be used for "other, fancier features". For instance, mobile phone operating systems save the state of an application and shut it down to save power or RAM, then restore it when the user switches back to the application. It might be possible to do something similar on the GNOME desktop. Another way the framework could be used is to implement something like Apple's Handoff feature that allows users to move an application's state on one device to another and continue working on the target device.

Vovk emphasized that he was not promising those features would be implemented or even worked on, but the save and restore framework would set the groundwork for such things.

History

With X11, applications would register with the session manager using the X Session Management Protocol (XSMP), which provided a uniform mechanism to allow sessions to be saved and restored. The applications were responsible for communicating their state and for restoring themselves. "Theoretically we could have used this with Wayland, but it has some problems", Vovk said. He noted that X11 session save and restore had been broken in GNOME for quite a few years; then the code for it was dropped entirely when X11 session support code was removed from GNOME in GNOME 50.

The big problem, he said, is that XSMP was all command-line driven, which meant that an application would provide a command for the session manager to run at the next login, usually with a file that had the application's state saved to it in some fashion. "Of course, that means that none of this works with a sandbox. I mean, we don't want sandboxed apps to be able to tell the operating system to run some commands at login."

To ensure that save and restore works with sandboxing, Vovk's replacement for XSMP would be an XDG desktop portal. This does not diverge too far from the way that XSMP worked, he said. Applications still register with the GNOME session manager, and it still keeps track of what to restart on the next login. Applications are relaunched by using the desktop entry rather than passing a command line for the manager to run. When an application is started again, it is given a "restore reason" which tells it what to do:

So it'll tell the app, "Hey, this is just a normal launch. You should restore maybe your window position, but not the contents inside of the window." Or it can say, "You're doing a full session restore; restore as much as you can", or it could say, "You just crashed, so maybe restore some things, but be careful not to get yourself into a crash loop". And I'm glossing over lots of complexity.

With XSMP on X11, the application was responsible for saving everything itself, including the window-management state. It would ask the X server for its position, size, "and all the window-management flags it felt like asking about. Then it would write them down and later restore them."

However, on Wayland, applications cannot position themselves for lots of reasons, Vovk said, though he did not elaborate on those reasons. Instead, Wayland offers the xdg_session_management_v1 protocol. The application does not save its own state, "it asks the compositor, 'hey, can you save my state and give me a token?' which is just a big random number, essentially". The compositor, such as GNOME's mutter, saves everything. Later, the application can provide the token to the compositor, which will restore "whatever makes sense to restore".

Vovk said that it was better than what GNOME had with X11. First, it was more consistent: what is saved and restored is centralized with the compositor, which can execute policy that makes sense for the desktop. For example, he explained that when an application launches, it might restore its position, but users may not want the application to restore the workspace it had been on previously as well. "It would be really weird if you were on the third workspace and you launched the app, and it opens on the first workspace because that's where it was last time".

With the "old X11 way of doing things", an application would need to be aware of workspaces, which it might not have been, and handle those edge cases. "And different desktops do things differently, and it becomes this whole mess." With the Wayland protocol, Vovk said, the compositor can decide what makes sense to do when starting an application. "During normal launches on this desktop environment, it doesn't make sense to restore workspaces, so it doesn't do that".

GTK

The hardest part of all this, Vovk said, was GTK. What was missing with XSMP was a "nice, high-level API for apps to interact with session save and restore, and so it wasn't that popularly implemented by apps". If applications are going to support save and restore, then they need an easy way of hooking into this system. The overall approach that he wanted for GTK was for Gtk.Application(), which handles session management, to manage everything. "It talks to the portal, it handles the Wayland protocol, and so on." The implementation would be built around what he called "state snapshots".

The idea was that GTK can decide to collect all of an application's state and save it to be restored at a later date. There were quite a few edge cases to consider, he said. For example, if an application has a saved state and the user double-clicks a file in the Nautilus file manager that is associated with the application, "does it restore first? Does it open a new file to handle the file? It's not really clear." He said that it was similar to the case where an application was already running with a couple of windows open already, and then it was sent an activation request to open a new file.

So my thinking here is that restoration isn't really that different from an app that's been running for a while and the user's already done some things in there. So what GTK will do is when you launch the app, it will restore the app first. And that will bring the app up to the state where conceptually it's the same state as if the user has been using the app for a while, has a couple windows open, and so on.

And then we give the app the activation request. And that means that all the edge cases of save, restore, lifecycle kind of go away because we pretend that that case is the same as the case of an app already running.

GTK has a periodic auto-save feature, he said, for crash resilience. Every 15 seconds, by default, GTK will take a snapshot of the application's state. If there is a crash "you lose at most 15 seconds of what you were doing in your last-focused app". The goal is for GTK to hide all the complexity, he said, of the Wayland protocol and edge cases. He described a scenario where a user closes an application and then restarts it before it completely exits. "Maybe the app is being held running by a search provider, or it's running some task in the background, whatever." GTK needs to restore the application window, but not the parts of the application that were "still alive".

First API

The first API that made it into GTK was "quite simple" and completely synchronous, he said. "We just emit the signal, and when all the signal handlers return, we assume we're done. We assume all the state has been collected." It was pretty close to landing in the final releases GNOME 50 and GTK 4.22, which were announced on March 18, 2026. "We almost released this." The first API had a few drawbacks, however, which held it back.

Some of the drawbacks were that the implementation required "a lot of repetitive kind of code", and that it didn't take into account an application's full hierarchy of windows. The first API was not well-suited for the kind of navigational hierarchy, such as subpages with their own states, that an application would have. "There was no helper for building up a tree of state that you would want to then kind of pass down your navigation hierarchy."

It also lacked bulk data support. He cited the example of GNOME's text editor: "You may have all the window state you want to restore, but then you also have this unfinished text document in there that may be many megabytes in size." It was undesirable to copy that text document into the save and restore system, "because then we're copying the data into memory and we're then writing it all to disk, and it's so much unnecessary work". It would be better to save the data to a file "off to the side" and keep the state snapshot small so that the entire system is quick.

But the biggest drawback of the first API, he said, was that applications want to do asynchronous things, but the API was fully synchronous. In the GNOME text editor example, saving the text document to disk should be an asynchronous operation: the file could be large, the disk could be slow, "we don't want to hang the app while we serialize everything".

The asynchronous problem is what killed the first API, Vovk said. This issue came up, Vovk said, because he had published the API for developers to test and there were a few applications adapted to use it. "One of the big pieces of feedback was, 'well, I want to do something async here, but I can't.'". He had to tell them "actually, you can't do that". He thought originally that it would be possible to retrofit asynchronous support into the API, but it involved "a big, big pile of race conditions that we couldn't fix". So, shortly before the GTK 4.22 release, "we pulled this API. We just hid it, basically. All the public API pieces got deleted, and the plumbing is still inside GTK, but it got hidden".

Second and third try

After the GNOME 50 release, he hoped that it'd be possible to implement a second API in time for GNOME 51. His second attempt had asynchronous support, managed window hierarchy, and had a solution for bulk data as well; but the way it was implemented, using asynchronous GObject signals, was "overwhelmingly rejected" by the maintainers. "The bit of feedback I got was that async signals is not something people are interested in, which, fair enough."

For the last few weeks, Vovk has been working on a third API proposal that keeps the benefits of the second API with a slightly different way of doing it. There are no more async signals; it uses asynchronous methods or virtual functions (vfuncs). "It's just an interface, and there's no weird machinery."

"So, when is all of this landing?" Vovk asked rhetorically. The Wayland bits are mostly there and the protocol has been released. It is ready for use by toolkits and compositors. The mutter side of save and restore landed in GNOME 51 beta, "however, there are some bugs to iron out when you actually put this together in a full session". The Wayland parts for GTK were released in GNOME 51 alpha but it is not usable by applications yet.

The XDG session save/restore portal is not quite done yet. He said that he had talked to KDE developers and Firefox developers who had agreed with the core concepts of the portal, but the details still need work, such as the specific restore reasons and some of the other language. The work is being tracked in this pull request on GitHub. He is also working on an API for the GNOME Session Manager, and there is a merge request that is waiting for other pieces to land.

The basics of the third API are in a branch awaiting feedback from GTK maintainers, "which I'm sure I will be getting at some point within the next few weeks". He was not sure what the reaction would be, yet. He said he would like to have some applications ported to the API before it's made stable in GTK. "We really need to be aware of what the ergonomics look like before using it, before stabilizing it." Ultimately, he said, it will not make it in time for GNOME 51. He encouraged developers with feedback on the API to contact him.

Questions

One audience member had a question that was difficult to hear, but Vovk thought they wanted to know if there would be an option to turn save and restore off. He said that there would be a user-facing option in GNOME's settings application to turn it off, and noted that applications would have to opt in to supporting the API as well.

Another person wanted to know if it would be possible to implement the save and restore feature at a lower level than GTK. Vovk said that the problem was that it needed to use GtkApplication() because there is involvement with Wayland, and with talking to an XDG portal, "which GTK will do, but GLib isn't doing". The feature also needs to be aware of GTK windows, "because otherwise we get all these edge cases you have to handle yourself" in an application, which he did not think was feasible.

The final question was about the GNOME extensions that currently implement save and restore features; what would the introduction of a proper GNOME feature mean for those extensions? He said that the extension probably would not be necessary long-term, but there would be a transition period while applications were ported to use the feature that it might make sense to continue using the extensions.