Before deep diving into the more extensive architectural changes that I’ve been working on GNOME Shell and Mutter, let’s take a moment to highlight the latest changes to GNOME Settings.
Being the (co)maintainer of Settings for a full year now, the development pace has been great so far. I would go as far as to say that the project is healthy and sustainable now. The shared maintainership model that we adopted allows us to decrease the review time, and yet make sure that every single contribution is reviewed by at least one maintainer.
Looking at the numbers, we managed to review 110 merge requests targeting 3.32 (and more if we consider the ones targeting 3.30 as well!). That is almost one merge request reviewed and merged every single day. Considering that this is mostly composed of volunteer work, I am comfortable to say that we found a very efficient maintainership model.
Without further ado, let’s see what happened during this cycle.
Mockups for controlling application settings were around and being discussed for some time now, but it eventually came the day where they were to be implemented. And thanks to the fantastic work by Matthias Clasen, we now have a new Applications panel:
Flatpak-based applications naturally have more system integration points. There are ongoing ideas being discussed about which other integration points should be, but nothing settled so far.
Robert Ancell has been working on the Sound panel redesign for some time now, and it’s close to landing. This is how it looks like so far:
Thanks to the awesome work of Outreachy intern Clarissa Borges, we have user testing results of this new layout. And they look pretty damn good! Overall, the testing clearly shows how much of an improvement the redesigned panel is.
Under the Hood
The Display panel is one of the hardest ones to deal with. Mostly because the almost entirety of the UI is programatically done. This was incredibly annoying, since it is somewhat hard to replace bits of the code with template widget without accidentally changing a lot of code.
Purism is a great upstream player in GNOME, and so far demonstrated deep understanding on how upstream communitites work. Naturally, I had the chance to review and eventually land some fantastic working making GNOME Settings responsive:
More to Come
Thanks to the hard work of these and many other awesome contributors, GNOME Settings is improving the way users can control their systems. But these are not the only improvements that will be part of 3.32, and of course, there is much more being targeted to 3.34!
This year, I had the pleasure to attend GUADEC at Almeria, Spain. Lots of things happened, and I believe some of them are important to be shared with the greater community.
This year’s GUADEC happened in Almería, Spain. It turns out Almería is a lovely city! Small and safe, locals were friendly and I managed to find pretty good vegan food with my broken Spanish.
Vegan Quinoa Balls
I was particularly happy whenever locals noticed my struggle with the language, and helped and taught me some handy words. This alone was worth the entire trip!
Getting there was slightly complicated: there were no direct flights, nor single-connection routes, to there. I ended up having to get a 4 connection route to there, and it was somewhat exhausting. Apparently other people also had troublesome journeys there.
The main accommodation and the main venue could have been closer, but commuting to there was not a problem whatsoever because the GUADEC team schedule a morning bus to there. A well handled situation, I must say — turns out, commuting with other GNOME folks sparked interesting discussions and we had some interesting ideas there. The downside is that, if anyone wanted the GNOME Project to die, we were basically in a single bus 😛
There were quite a few interesting talks this year. My personal highlights:
To me, the BoFs were the best part of this year’s GUADEC. The number of things that happened, the hard talks we’ve made, they all were extremely valuable. I think I made a good selection of BoFs to attend, because the ones I attended were interesting and valuable. Decisions were made, discussions were held, and overall it was productive.
I was particularly involved in five major areas: GNOME Shell & Mutter, GJS, GTK, GNOME Settings, and GNOME To Do.
GNOME Shell & Mutter
A big cleanup was merged during GUADEC. This probably will mean small adaptations in extensions, but I don’t particularly think it’s groundbreaking.
At the second BoF day, me and Jonas Ådahl dived into the Remote Desktop on Wayland work to figure out a few bugs we were having. Fortunately, Pipewire devs were present and we figured out some deadlocks into the code. Jonas also gave a small lecture on how the KMS-based renderer of Wayland’s code path works (thanks!), and I feel I’m more educated in that somewhat complex part of the code.
As of today, Carlos Garnacho’s paint volume rework was merged too, after extensive months of testing. It was a high-impact work, and certainly reduces Mutter’s CPU usage on certain situations.
At the very last day, we talked about various ideas for further performance improvements and cleanups on Mutter and GNOME Shell. I myself am on the last steps of working on one of these ideas, and will write about it later.
As I sidenote, I would like to add that I can only work on that because Endless is sponsoring me to do that. Because
Exciting times for GNOME Shell ahead!
The git master GJS received a bunch of memory optimizations. In my very informal testing, I could measure a systematic 25~33% reduce in the memory usage of every GJS-based application (Maps, Polari and GNOME Shell). However, I can’t guarantee the precisions of these results. They’re just casual observations.
Unfortunately, this rework was making GNOME Shell crash immediately on startup. Philip Chimento tricked me into fixing that issue, and so this happened! I’m very happy with the result, and looks like it’ll be an exciting release for GJS too!
Thanks Philip for helping me deep dive into the code.
Matthias already wrote an excellent write-up about the GTK BoF, and I won’t duplicate it. Check his blog post if you want to learn more about what was discussed, and what was decided.
At last, a dedicate Settings BoF happened at the last day of the conference. It had a surprisingly higher number of attendees than what I was expecting! A few points on our agenda that were addressed:
Maintainership: GNOME Settings has a shared maintainership model with different levels of power. We’ll add all the maintainers to the DOAP file so that anyone knows who to ping when opening a merge request against GNOME Settings.
GitLab: we want to finish the move to GitLab, so we’ll do like other big modules and triage Bugzilla bugs before moving them to GitLab. With that, the GitLab migration will be over.
Offloading Services to Systemd: Iain Lane has been working on starting sessions with systemd, and that means that we’ll be able to drop a bunch of code from GNOME Settings Daemon.
Future Plans: we’ve spent a good portion of this cycle cleaning up code. Before the final stable release, we’ll need to do some extensive testing on GNOME Settings. A bit of help from tech enthusiasts would be fantastic!
We should all thank Robert Ancell for proposing and organizing this BoF. It was important to get together and make some decisions for once! Also, thanks Bastien for being present and elucidating our problems with historical context – it certainly wouldn’t be the same without you!
GNOME To Do
Besides these main tracks, me and Tobias could finally sit down and review GNOME To Do’s new layout. Delegating work to who knows best is a good technique:
I was also excited to see GNOME To Do stickers there:
It’s fantastic to see how GNOME To Do is gaining momentum these days. I certainly did not expect it three years ago, when I bootstrapped it as a small app to help me deal with my Google Summer of Code project on Nautilus. It’s just getting out of control.
Even though I was reluctant to go, this GUADEC turned out to be an excellent and productive event. Thanks for all the organizers and volunteers that worked hard on making it happen – you all deserve a drink and a hug!
After Bastien and Rui announced that they were stepping down from maintainership of GNOME Settings, I went ahead and volunteered to take care of it. This was not a random act, though; for quite some time, I’ve been adding and changing code all around. I was pretty involved in moving to the new layout, and with the help of other contributors, implemented the redesigns of various panels. Clearly, I have a technical debt to the app.
Adding to that, assuming maintainership over it also aligns well with the goals of my employer, Endless, and gives a nice upstream/downstream overlap. With that, I can spend a bigger chunk of my work time on upstream tasks. Moreover, it allows us to have a stronger relationship with the GNOME community — after all, it allows me to bridge the insights and knowledge we gain from our users to a wider community.
Turns out, GNOME Settings is a pretty popular app amongst our users. It is one of the top apps that our users run. Developing and improving it became an important part of our fixed set of tasks. Specially now that we’re on the verge of a big release and one exciting new feature (amongst many!) was added into Settings. I’ll write more about it soon, hold your horses! 🙂
Without further ado, let’s start by checking some facts about Settings.
It has 371 unique dependencies (give or take, depending on the distro);
As of today, there are more than 17,500 commits and 500 tags;
It has roughly 440,000 lines of code, effectively making it part of the huge apps of GNOME, together with Evolution, GNOME Builder and Mutter.
First commit dates back to February 10th 1998, 21:22:12
As you can see, this is really no regular GNOME app. It has an old code base, half a million lines of code, dozens of thousands of commits and went through a lot of contributors. During all this time, it has being serving as the central hub of hardware and modules setting management. This gives us the dimension of this app.
But life is not a bed of roses.
Of course, during this time, GNOME Settings aged, was rewritten at least three times, and more recently was ported to another build system, Meson. Maintaining an app of this size, with such a colossal amount of knowledge involved, is not easy.
As I learn and find my way around the code base, a few problems were found:
You need to have the development packages of everything to build it. This is obvious, but I don’t really enjoy messing up with my host system.
It is not trivial to debug Settings. There was only a rudimentary logging system around.
There are at least 4 different code styles being used, and none documented.
Tests were scattered all around the code base.
With that, the reader hopefully has enough context to follow the rest of this article: the recent changes that make the development experience of GNOME Settings smoother and more streamlined.
Flatpak, Flakpat, Flaptak, Flatkap, Flapkat!
Flatpak is an application distribution module, and has high adoption from the GNOME community. Turns out, Flatpak also became an excellent development tool, much beyond my initial expectations. It allows me, as a developer, to have a finer control over the build and execution environment, and keeps my system clean and organized. It allows me to install multiple versions of a given app, and they’ll share every common file they have. It’s awesome.
Flatpak is also tightly integrated into GNOME Builder, and developing apps on Builder with Flatpak is a super smooth experience these days. Thanks to Christian Hergert, we have a prime quality IDE!
This led to the creation of a Flatpak manifest for GNOME Settings. Of course, GNOME Settings is not meant to run as a Flatpak by end users. The Flatpak integration is strictly for development purposes.
Spotlights to the blueish “I am a development version” header bar:
These details might seem small, but they transform the development experience from a burden to a breeze. One can literally clone GNOME Settings from GNOME Builder and just press the Run button – everything will happen automatically. Besides that, Flatpak integration means I can develop GNOME Settings in a locked host system, such as Endless OS or Fedora Atomic, without having to unlock it and install development packages.
This work was partially done in my work time. Thanks Endless for letting me improve my own workflow 😛
GNOME Settings gained rudimentary CI support just before the 3.28 release. It allows us to have fancy green icons on commits, like these:
CI is important to make sure everything is always building and working fine. Merge requests are always built before being merged, and having a more automated contribution workflow benefits everyone.
But it was inefficient and bloated.
Thanks to the independent contributor Claudio André, the CI was completely revamped. The build process was shrinked, the build environment was standardized so we can reliably reproduce build failures, and the fat was trimmed. In fact, CI times were cut down from 17 minutes to 3 minutes in average.
Thanks Claudio for your contributions!
Tests, More and Better
Another important aspect of improving the development experience is adding more tests, that validate a larger portion of the code base.
Thanks to Red Hat’s Benjamin Berg, the tests in GNOME Settings were reorganized and improved. As a courtesy, more network tests were also added. These tests are integrated into the CI, and every contribution is tested in a job:
For obvious reasons, tests are absolutely important to avoid regressions. Unfortunately, though, the tests available in GNOME Settings don’t cover even a tiny fraction of the code base. Writting tests is a great way to start contributing to GNOME Settings!
The goal here is that people unfamiliar with the code base can find answers about code style by their own, reducing the communication overload and making the whole contribution process more efficient. It is also important to clearly document what is the expected behavior of contributors.
Improving the documentation is another wonderful and easy way to contribute.
But That’s not all
Even though these advancements mark a real improvement over the current state, there is a long way ahead. Ideally, we want to automate everything that can be automated, and test everything that should be tested. Settings needs and deserves to have some fresh air and code!
A unmerged feature that Claudio worked on is generating development Flatpak bundles. This is useful to lower the testing barrier, since one wouldn’t need to build Settings AND all the dependencies whatsoever. Just download, double-click the file, install and run. Dead easy.
If you have ideas on how the DX can be improved, feel free to share them! I’d love to hear your comments, suggestions, and ideas.
I’d like to thank my employer, Endless, for letting me use part of my work time to develop what I developed. I’d also like to thank Red Hat’s Benjamin Berg for reworking the test suite; independent contributor Claudio André, for making the CI smooth and fast; and specially Bastien Nocera, for helping and advising and reviewing code even after stepping down from the maintainer position.
Y’all know that we’re taking big steps to move Settings (a.k.a Control Center) to a brand-new, super shiny layout. As a courtesy of our beloved designer, Allan Day, we have mockups of a new Settings layout that is both modern and preserves (most of) the functionality we already have. He blogged about it in the past.
I found those mockups quite nice, so I decided to work on them!
As YouTube people say nowadays: I’m a simple man. I see a good mockup, I implement it.
Before switching to the new layout, though, we needed to get rid of the panels with a sidebar. Namely: Online Accounts, Keyboard, Network, Printers and User Accounts. Thanks to Felipe Borges, who reimplemented a few panels himself, we were able to progress faster than expected!
This time, I added the new Wi-Fi panel. Check this out:
Compare this with the current Network panel, which still has a sidebar:
With the new Wi-Fi panel, we’re close to making the new Settings shell the default one; the biggest blocker now is the Network panel, which I’m already working on. And finally, after more than a year working on the new Settings layout – and with the help of many super awsome contributors! – we’re almost there 🙂
And our traditional sequence of pictures:
Oh, and did you notice? The connection editor dialog was also redesigned! It’s much simpler and saner now, do try it out and let me know what you think.
The new Wi-Fi panel has a few advantages:
It’s beautiful 🙂
It handles multiple Wi-Fi adapters slightly better
It’s just easier to use
(Future) When the host doesn’t have a Wi-Fi adapter, the panel won’t be visible
I’d like to say a big and warm thank you to all contributors that made this possible, and specially to Bastien Nocera and Rui Matos for reviewing all this work and many other patches.
There’s still quite a lot of work to do, and it won’t be easy, but we’ll eventually make it 🙂
If you’re watching closely the GNOME Control Center iterations, you probably noticed it already has a bunch of new panels: Keyboard, Mouse & Touchpad, and other panels like Sharing, Privacy and Search that don’t need to be ported.
I’m pleased to announce that the Online Accounts panel joined this family.
Check this out:
This panel was easier to be ported since the codebase was already somewhat recent. It now features a single-column layout, which fits perfectly the next shell of GNOME Control Center.
Editing and creating accounts are now handled in a separate dialog:
But that’s not all!
The new Printers panel
Thanks to the always awsome Felipe Borges, we have a brand new, super shiny Printers panel. Most importantly, it has colored ink indicators! Dude, what else could you ask for?
I’ll let Felipe himself write this one in details, but why not tease the audience? 🙂
Lets shout a big thanks to this great GNOME contributor!
In order to permanently switch to the new shell (the one in the screenshots), there are three major panels to be reworked:
Sounds: required to switch to the new shell, the Sounds panel will probably be very time consuming.
Networks: another required and hard panel. This panel will be split into Wi-Fi, Mobile Broadband, and Networks, and it’ll probably require a lot of work too.
Details: each tab in the Details panel will be split into a separate panel. It’ll be mostly manual work, and it’s easy (anyone interested in picking this one up? 🙂 )
This work can be tracked here. Excited? Join us in creating the next generation Settings application – contributions are so appreciated!
After Allan give his usual show with new mockups (didn’t you see? Check it here), . Check this out:
Working on this panel had me take a few conclusions:
The new programming tools and facilities that Gtk+ and GLib landed make a huge difference in code legibility and code quality.
GObject is awsome. Really.
Since GObject is awsome, lets use all the functionality it gives us for free 🙂
I tend to overdocument my code.
And our beloved set of sequential pictures and music:
Excited? This is still unders heavy development, and we just started the reviews. You can check the current state here, or test the wip/gbsneto/new-keyboard-panel branch. As always, share your comments, ideas and suggestions!
Hello, GNOMErs! As some of you may be aware, I’m working on porting our beloved GNOME Control Center to match the latest mockups. Not alone, however; we’re a Team.
The Porting Team
We’re short on human resources here, but we’re doing our best to make the new Control Center for 3.22 release. Meet the Team:
Bastien Nocera (the maintainer), an amazing long-term contributor who is doing a quite huge work on porting it to Network Manager 1.2, and reviewing all the patches that goes in. Thanks to his reviews, the code quality is always top-notch.
Felipe Borges, who ported the Mouse & Touchpad and now is working on porting the Printer and the Users panels. He’s the leading force of porting the panels, and an awsome guy.
Georges Basile (I), who’s working on the new Shell with a sidelist and will port some panels as well.
Feel free to contact any one of us and get in-depth details abot The Plan.
We’ve been attending secret meetings (in plain open #gnome-hackers room :P) and we came up with a plan on how we’ll work on moving things forward. Here are the outlines:
A new non-installed binary gnome-control-center-alt will be introduced.
The panels that must be ported are: Online Accounts, Networks, Sound, Users, Printers, Details and Keyboard.
We’ll port as much panels as we can, obviously prioritizing the panels above.
As we port the panels, we test them both with the current icon grid and the new sidelist.
The old icon grid will be removed and this binary will be the official Control Center after all the required panels are ported.
Everyone will be happy 🙂
The reason we’re doing it this way is safety. We’re absolutely not releasing a half-backed feature in such an important component. Worst case scenario, we’ll release the current GNOME Control Center with properly tested ported panels.
The work on these features have a real, concrete impact. This is not coming out of nowhere. Out of my head, some of the benefits we gain are:
The Control Center will be able to work on really small screens AND big screens, out of the box. This would probably won’t affect the current regular GNOME user, but there are millions out there who can only afford a Tube TV with 720×480 resolution (and yes, my employer Endless opened my eyes to this reality).
Much improved interaction. Thanks Allan for working on that.
Easier to find panels.
Much more GNOMEish.
Excited? Read below.
How To Be Part of It
There are plenty of ways to contribute with this monumental task. Don’t like coding? You can test, update the documentation and spread the word. Every single contribution is absolutely appreciated.
These patches need testing, love and work. Are you new to GNOME? No problem, there is a page crafted for you: Newcomers. Feel free to ping us to get some directions, join the #newcomers IRC room and, as always, you’re very welcomed to be part of this community!
This work wouldn’t be possible without the support of my employer Endless, and also Red Hat for allowing Bastien and Felipe to work on that.