Florian Müllner

It has been a while now that I switched to Fedora Silverblue as my primary operating system, and I really dig the separation of using

• an immutable operating system
• flatpak for graphical applications
• toolbox for non-graphical development

You probably know that flatpak is not only a great option for running graphical applications, but also for developing them — in particular when using the amazing GNOME Builder.

It is however not an option for developing core desktop components like gnome-shell — sadly old-fashioned JHBuild is still the tool of choice there. And on Silverblue, the cleanest option for installing that tool is inside a toolbox container.

The whole process is not completely straight-forward and took me a while to figure out, which is why I’m now sharing it in this friendly service blog.

Creating a toolbox

Fortunately that first step is easy enough:

Installing jhbuild

Next we need to install jhbuild inside the toolbox. That process is not fundamentally different from installing it on a traditional distribution like Fedora Workstation, except for one caveat: The jhbuild sysdeps command relies on PackageKit, which is not available inside the container.

Using dnf builddep is one way to get around that, I opted for a small helper script that automates the jhbuild setup:

Setting it up to run gnome-shell

We can now use jhbuild to build GNOME modules, just like we would do normally¹:

For most modules, we are done now — we can simply run them through jhbuild run inside the toolbox.

Big surprise though: That doesn’t apply to running a wayland compositor like gnome-shell. We need quite a bit more there, namely

• suitable graphics drivers
• access to the “real” /tmp directory
• access to the host’s logind

Graphics drivers are a relatively easy problem to fix, we just need to install the correct package. And for the last two items, toolbox thankfully makes the host filesystem available under /run/host inside the container.

As you may have guessed: There’s another script to automate those steps, which then allows us to run gnome-shell in nested mode:

Setting up a jhbuild session

In a lot of cases, nested mode is good enough for testing changes. But sometimes we really want to test a full session.

With some help from this excellent guide, here’s a last script which sets up a dedicated JHBuild session that can be selected at login time:

And that’s it!

All scripts mentioned in this post are available on my GNOME GitLab²; issues and merge requests are open, in case you have any suggestions.

1. And as normally, we install any missing dependencies that we run into, while cursing at the computer in despair [↩]
2. as well as a couple of convenience wrappers [↩]

A couple of weeks ago, I was fortunate enough to attend the Mutter & GNOME Shell hackfest in Leidschendam.

The Mutter side has already been covered in detail by Carlos (in a day–by–day blog series) and Georges (here), so I will fill in the Shell side a bit:

• We finally landed Marco’s big “actorization” cleanup, which departs with the delegate pattern used all over gnome-shell (a JS object with an associated actorproperty, and a monkey-patched _delegateproperty that links back to the JS object). This was originally planned for 3.34, but was postponed as it’s an intrusive change that requires many extensions to adjust, and we were already in deep freeze territory. Plus there was some bit in there that I disliked, which we finally resolved in a nicer way at the hackfest.
• Georges continued his mission to replace ClutterClones. Clones are an evil hack that disable important drawing optimizations in the source actor, so this will be a very welcome change.
• Someone at the hackfest ran into a common trap, where StBin shadows some properties of its ClutterActor (grand)parent class. This is a long-standing source of confusion, but so far we shied away from addressing it because of the API break. Alas, we already have breaking changes lined up for 3.36, so this is finally fixed.
• Getting together face-to-face allows for much quicker code-review iterations, so we managed to squeeze in a couple of smaller tasks like a redesigned power-off section in the status menu, a cleanup of system dialogs, wiggling entries after entering a wrong password, shadows in window screenshots, as well as plain bug fixes.
• There was a small discussion about moving extension management out of GNOME Software and providing a less misleading way of doing extension updates
• And last but not least of course, some exciting discussions about the designers’ masterplan for world domination that was already hinted at by Carlos and Georges

Besides the productive bits,it is always good to put faces on IRC nicknames: It was nice to finally meet Niels and Jonas D. in person.

Big thanks to Hans for hosting the event, and Maria and Carlos for accommodation and company (with an additional shoutout to Ada and Lis!).

As I am (finally) writing this, I am on a train to Barcelona for the Linux application summit – hope to meet many of you there!

Any time someone publishes a “The top n GNOME Shell extensions” article, there’s a fair chance that it will include the AlternateTab extension.

That is a bit sad to be honest. Not because it would be wrong for users to prefer a more traditional switcher, mind you, but because the actual functionality has been built-in for years — all the extension does is intercept one keyboard shortcut and pretend that it was a different keyboard shortcut.

So without further ado, this is how to set up the window switcher without using the extension:

But wait, if the extension doesn’t do anything really, why does it even exist?

Well, until very recently, the extension was still used in GNOME Classic, so that the same <Super>Tab> shortcut would bring up the default application switcher in the regular GNOME session and the window switcher in the Classic session.

In GNOME 3.30 this now works without the extension, which brings us to the extension’s future mentioned in the title. After the above explanation it shouldn’t come as a surprise that there is none — the extension will be retired for GNOME 3.32. If you are currently using it, please set up the built-in “Switch Windows” shortcut as outlined above, and enjoy having one less extension to worry about on updates…