Shell hacking on Silverblue

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:

host$ toolbox create --container jhbuild
host$ toolbox enter --container jhbuild

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:

toolbox$ ./ gnome-shell

Setting it up to run gnome-shell

We can now use jhbuild to build GNOME modules, just like we would do normally ((And as normally, we install any missing dependencies that we run into, while cursing at the computer in despair)):

toolbox$ jhbuild build --skip=WebKit gnome-shell

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:

toolbox$ su -c ./
toolbox$ jhbuild run dbus-run-session gnome-shell --wayland --nested

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:

host$ ./

And that’s it!

All scripts mentioned in this post are available on my GNOME GitLab ((as well as a couple of convenience wrappers)); issues and merge requests are open, in case you have any suggestions.

Posted in Uncategorized | Comments Off on Shell hacking on Silverblue

Mutter & GNOME Shell Hackfest

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 daybyday 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!

Posted in Uncategorized | 2 Comments

The future of AlternateTab, and why you need not worry

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…

Posted in Uncategorized | 8 Comments

Polari joined the Gitlab pilot project

I am happy to announce that yesterday Polari joined the Gitlab pilot project. This means that if you encounter any issue that has not been reported yet, it should now be reported in GNOME’s gitlab instance.

Happy hacking!

Posted in gnome | 1 Comment

A small note on window decorations

If you have updated to the recently released GNOME development version, you may have noticed that some window decorations look slightly different. Of course it is quite normal for the theme to evolve with the rest of GNOME, but in this case the visual changes are actually the result of some bigger changes under the hood which deserve some more explanation.

It is well-known that GTK+ gained support for client-side decorations a while ago – after all, most GNOME applications were quick in adopting custom titlebars, which have become one of the most distinguished patterns of GNOME 3 applications. However it is less well-known that client-side decorations may also be used for windows with no custom decorations, namely when using GDK’s wayland backend.

Why is this interesting?

It isn’t really. Whether the non-customized decorations are provided by the window manager or by the toolkit is transparent to the application, and there is no reason why users should care either.

Except that on GNOME 3.14, decorations looked like this:


Client- and server-side decorations in GNOME 3.14

Ouch. There is an all-too-obvious visual difference for something that should be an implementation detail, and the possibility of users encountering both styles in the same session doesn’t help either.

Of course it would be easy to just blame the GNOME design team – after all, while the metacity-1 theme format used by the window manager is hugely different from CSS as used by GTK+, it would still be possible to create a more consistent look from the lowest common denominator of both formats. But if the goal is to have both types of decorations match as closely as possible, using different themes and expecting an already overworked team to put additional work into papering over the differences is hardly the best solution.

Did I mention that the metacity-1 format is also plainly unpleasant?

So from GNOME 3.16 on, the window manager theme will be gone. Instead, window manager decorations will use the same theme information GTK+ uses for its client-side decorations. As you would expect, both types of decorations now look much more consistent as a result:


Client- and server-side decorations in GNOME 3.15

Besides the improved consistency, using a single theme has some additional benefits:

  • users who use a different GTK+ theme no longer need to hunt for a matching window manager theme
  • one less (tweak) option that can be a bit hard to explain (“Window decorations. Except not all of them. Oh, and some of the colors may actually come from another theme.”)
  • the GNOME design team no longer needs to maintain two different but matching themes
  • sharing a theme also means sharing code, we were able to remove a bit over 10,000 lines from mutter

Now it would be dishonest to pretend that there aren’t any downsides – the metacity theme has been around a decade longer than GTK+’s client-side decorations, so it is hardly surprising that there is a greater selection of the former around. And support for window-decorations in 3rd party GTK+ themes is often dodgy, if it exists at all. However with more and more GNOME applications using custom titlebars and the upcoming transition to wayland, it does not get easier to ignore GTK+’s decorations – some broken decorations may be better than all broken decorations, but the correct way forward is of course to fix GTK+ themes. It’s CSS after all, which is much more familiar to most artists than the old format, and quite a bit nicer as well, so here’s hoping that the situation will improve rapidly.

In the meantime, let those of us who stay with the default theme enjoy some nicer-looking decorations for all windows …

Posted in gnome | 25 Comments

GNOME Shell, GSettings and keybindings

Some of you may already know: it has been roughly a week since metacity/mutter switched to GSettings. The fallout has been quite small, so this seems like a good time to sum up the changes which may be of wider interest:

  • no more hidden binding_name_list settings – while the System Settings panel still only allows to assign a single keybinding to each action, keybindings are always stored as lists, so it is possible to have multiple bindings per action
  • no more custom keybindings in Metacity/Mutter – the Custom Shortcuts section in the Settings panel uses gnome-settings-daemon, there’s no point in having an additional hidden mechanism for the same functionality
  • the keybindings to take screenshots have been moved to gnome-settings-daemon – those actions are not window manager related at all, they were provided by Metacity purely due to historic reasons; it is worth mentioning though, as the move breaks the shortcuts in the overview for the time being
  • the keybinding to launch a terminal has been removed – I know some people will be pissed off by this, but well … you can define arbitrary keybindings in System Settings, there’s really no point in having a pre-defined (unset-by-default) shortcut for terminals (note how all other pre-defined launchers default to hardware keys found on some keyboards)
  • GNOME Shell no longer overrides the theme preference – Metacity has defaulted to ‘Adwaita’ for quite some time, so there’s no good reason to keep a different preference for GNOME Shell; as a consequence, if you changed /desktop/shell/windows/theme, the change will not be migrated automatically – you’ll have to set org.gnome.desktop.wm.preferences theme manually (or just go with the great default theme!)
  • the way Mutter handles keybindings has been mostly rewritten – the interesting part of this is that extensions may now use meta_display_add_keybinding() to define their own keybindings

So that’s it for today – if you encounter any issues not mentioned above, feel free to file bugs.

(Hopefully my next blog post will be a bit more interesting …)

Posted in gnome | Tagged | 18 Comments

Ick hab noch eenen Koffer in …

Desktop Summit Bannerdeswejen fahr ick nächstens wieder hin

Also I’m probably expected to mention my joint talk with Jakub, though I feel slightly bad that he does not appear anywhere in the announcement. But then, maybe it’s him who should feel bad for weaseling out of all the paper stuff …

See you there!

Posted in gnome | Comments Off on Ick hab noch eenen Koffer in …

¿HOT or NOT?


I’m Florian Müllner and I’m one of the hundreds who worked on GNOME 3 …

So the weeks of craziness have come to an end – the awesomeness of GNOME 3 is out and the time to celebrate has come.

It is a great achievement, and I am proud and happy to be a part of it and the community which made it happen.

If you have not tried it out yourself yet, do so now. Seriously.

Just be warned – once you’ve fallen for it, there’s no turning back. One of those little details will get at you, and you’ll live happily ever after. What will it be for you? The new System Settings? Streamlined Nautilus? Resident notifications? Chat integration? Topic-based help? The modern and polished theme?

All of those are awesome, but it’s actually a very tiny detail which does it for me:

Each time I find myself forced to use GNOME 2 now, I end up throwing the pointer to the upper left corner, followed by mild irritation and the feeling of something seriously missing. Muscle memory at its best …

Indeed, this is one of the many ways that we’ve made GNOME 3 better.

Posted in gnome | Tagged | 1 Comment

A quick notice

The relayout has landed, further development will happen on the master branch. All those who switched their build to the overview-relayout branch should update their .jhbuildrc-custom to revert to master.

Thanks for the patience everyone!

Posted in gnome | Tagged | 11 Comments

Moving forward

Yesterday I finally opened a Bugzilla bug to land the overview-relayout branch, so the review process has now started and hopefully the work will appear on master soon.

Most recent changes have been internal, but as seen above, the overall design has been tweaked a bit (not least thanks to Allan Day‘s input): the large black boxes around the currently selected view are gone, and the controls to add/remove workspaces have been moved to the screen edge (yup, the F–word!) and slide out on hover and during drags. Also the animation when entering or leaving the overview has been modified to only zoom the window previews — addressing a common complaint about the animation being visually expensive (well, or just “too much”), and resulting in the first bug filed explicitly against the overview-relayout branch — woops.

Add or remove a favorite

Remove a favorite

Apart from those tweaks I managed to implement Dash DND, so it is now possible to add / reorder / remove favorites from the dash using DND. The implementation probably still will require some adjustments, but the first reactions have been quite positive, so you might want to give it a try; the impatient can add branches['gnome-shell'] = (None, 'overview-relayout') to their .jhbuildrc, otherwise stay tuned for those changes coming to a Shell near you soon …

Posted in gnome | Tagged | 40 Comments