A while ago, I’ve described how to handle restarting Flatpak apps when they are updated.
While I showed working code back then, the example was a bit contrived, since it had to work around GApplication’s built-in uniqueness features.
With the just-landed support for replacement in GApplication, this is now much more straightforward, and I’ve updated my example to show how it works.
Restart yourself
There are a few steps to this.
First, we need to opt into allowing replacement by passing G_APPLICATION_ALLOW_REPLACEMENT when creating our GApplication:
app = g_object_new (portal_test_app_get_type (), "application-id", "org.gnome.PortalTest", "flags", G_APPLICATION_ALLOW_REPLACEMENT, NULL);
This flag makes GApplication handle a –gapplication-replace commandline option, which we will see in action later.
Next, we monitor the /app/.updated file. Flatpak creates this file inside a running sandbox when a new version of the app is available, so this is our signal to restart ourselves:
file = g_file_new_for_path ("/app/.updated"); update_monitor = g_file_monitor_file (file, 0, NULL, NULL); g_signal_connect (update_monitor, "changed", G_CALLBACK (update_monitor_changed), win);
The update_monitor_changed function presents a dialog that offers the user to restart the app:
if (response == GTK_RESPONSE_OK) portal_test_app_restart (app);
The portal_test_app_restart function is where we take advantage of the new GApplication functionality:
const char *argv[3] = { "/app/bin/portal-test", "--gapplication-replace", NULL }; xdp_flatpak_call_spawn (flatpak, cwd, argv, ...);
We call the Spawn method of the Flatpak portal, passing –gapplication-replace as an commandline option, and everything else is handled for us. Easy!
Update 1: If D-Bus is not your thing, there is a simple commandline tool called flatpak-spawn that can be used for the same purpose. It is available inside the sandbox.
Update 2: I forgot to mention that GApplication has also gained a name-lost signal. It can be used to save state in the old instance that can then be loaded in the new instance.
Simple applications like PortalTest could be probably restarted without users confirmation; for anything more complex, it would be nice if the application state (things like focused widget, opened files, cursor position, scrolling position) could be passed to the new instance. If I understand it correctly, session manager is responsible for tracking the application state on X; what is the role of session managers on Wayland and will there be some replacement for XSMP? Do you have any recommendations for handing the state?