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.

Knowing 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.
• It has 24 panels, the latest one being Thunderbolt;
• 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.

Problems

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 😛

Faster CI

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!

Thanks Benjamin for reorganizing the tests!

Documentation

In addition to all this mentioned work, I personally have been working on improving the developer documentation available in GNOME Settings. As first steps in that direction, the current code style was documented and contribution guidelines were added.

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.

Acknowledgements

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.