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!

This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to Mutter & GNOME Shell Hackfest

  1. Baptiste Mille-Mathias says:

    Hi Florian,

    Thanks for the report on improvements.
    is there any way that one day we can have gnome-shell flatpak in nightly so we can test new feature, or is there too many friction with other components ?


    • fmuellner says:

      It is difficult.

      I’ve played around with this in the past, and managed to run a (nested) Mutter flatpak with the right CLI switches and environment magic.

      Unfortunately I lost the spell book, and the old flatpak no longer runs here.

      Getting gnome-shell to run will be even more challenging due to the often tight coupling with other core components like gnome-settings-daemon and gnome-session; the plethora of bus names that gnome-shell wants to claim itself (and take over from the existing session); and nowadays the reliance on systemd’s user session.

      I think the only (possibly) feasible option would be to run a separate D-Bus daemon inside the sandbox; not that I know anybody who has done that though.

      All of this will likely only work for nested mode (if ever), as a full session requires more host access than any sandboxing holes provide. And that would only be of limited value for testing, as things like keybindings or agents for system services (polkit, network-manager, …) would still be provided by the host instance.

      In the end, a system component like gnome-shell is simply out of scope for flatpak.

      I know people are looking into having buildstream produce OSTree images that can be used in a VM. It’s not as streamlined as the flatpak-based workflow for applications, but it’s a lot more realistic for a system component.

Comments are closed.