Note: Fedora Atomic Workstation has recently been renamed to Team Silverblue. Learn more here.
I am still going with my attempt to use Fedora Atomic Workstation fulltime as my main development system. As part of that, I am figuring out how to do GTK+ development on an immutable OS, using GNOME Builder.
As I’ve explained in a previous post, one thing I figured out early on is that while the flatpak support in GNOME Builder is optimized for desktop applications, you can use it for other things. In my case, that means developing GTK+.
Build Configurations
GNOME Builder knows what and how to build via its build configurations. It can have multiple such configurations for each project – the Build Preferences page has a list of them. In the flatpak case, build configurations correspond more or less 1:1 to flatpak manifests that are stored as json files in the source tree. Last time, I created one that launches the gtk4-demo application.
Currently, creating a new build configuration means copying an existing flatpak manifest to a new file, but in 3.28, GNOME Builder will support copying build configurations directly in the Build Preferences.
Environment
Influencing GTK+ at runtime for debugging purposes is often done via environment variables, such as GTK_DEBUG for controlling the debug output. Unfortunately, setting environment variables is not the most obvious in GNOME Builders flatpak support, currently.
There is an Environment section in the Build Preferences, but it sets environment variables at build time, not in the runtime sandbox that gtk4-demo will run in. GNOME Builder currently has no UI for setting up the runtime environment. We can still do it, by manually adding –env options in the finish-args section of the flatpak manifest:
"finish-args" : [
"--share=ipc",
"--share=network",
"--socket=x11",
...
"--env=GTK_DEBUG=modules"
],
This is hardly elegant, and it has the big downside that any change to the flatpak manifest will cause GNOME Builder to rebuild the project, even if the change only affects the runtime setup, as is the case here. I hope that GNOME Builder will gain proper runtime setup UI at some point.
Terminals
But maybe it would be more natural to get a command prompt and set environment variables as usual, while launching apps from there.
GNOME Bulder can actually give you a terminal, with Ctrl-Alt-Shift-T, but it is a terminal in the build sandbox, not the runtime sandbox.
Thankfully, we can help ourselves in the same way as before: Just create another build configuration, this time using “sh” as the command – that gives us a shell inside the runtime sandbox, and we can launch test apps from there while setting environment variables.
Portals
One aspect of GTK+ that I have worked on in this new setup is module loading. I’ve switched GTK+s printing support to use a GIO extension point, and of course, I wanted to test this before pushing it.
So I was a bit surprised at first that the print dialog in gtk4-demo did not trigger my new module loading code and yet seemed to work just fine. But then I remembered that we are working in a flatpak sandbox now, so GTK+s portal support kicked in and helpfully redirected the print operation to an out-of-process print dialog.
With this project, we want to take the Atomic Workstation as it is today, and turn into something that is not just cool for the few who know it, but useful for everybody who has a need for a Workstation.