Restricting users

Using a computer is mostly about executing apps, reading, writing and doing. But it can also be about not doing.

Confusing? Bear with me.

Imagine for a second that you are in an elementary school. The leadership is optimistic on exposing students to technology. They have set up big rooms with rows and rows of computers ready for their students to use.

Would you give complete permissions to these teenagers using the computers? Would you allow them to install and uninstall programs as they wish, access any website they feel like, use for as much time they want?

An elementary question

This is an intriguing situation to think about. At the same time that we want to restrict what the user can do — in this case, the student — we still want them to be able to get stuff done.

Thanks to Cassidy Blaede from the elementary OS team, this school-wants-to-limit-students situation was brought to the roundtable during the Parental Controls & Metered Data hackfest that happened during the second half of April.

The event itself was extensively covered already by Cassidy, and by Philip’s and Iain’s daily reports, and that is not going to be the focus of this article. I’m personally more interested in the design and technological aspects of what was discussed.

Apps or not apps

Naturally, when talking about user restriction, apps are probably the very first aspect of it that comes to our minds. Followed by browsers.

There is not a lot of controversy to the idea of assuming that administrators are likely to be the “supervisors”, and users without administrator privilages are the “supervised”.

At first, the use case we thought we were dealing was mostly about guardians or parents restricting what kind of contents, applications, or websites their kids would be able to access.

This is natural on systems that are heavily app-based. Smartphones have interesting implementations that are not only sane, but also technically feasible. But the traditional way of distributing apps via distro packages, and executing them without restrictions, makes that task incredibly hard, impossible dare I say. Unfortunately, the Linux desktop in general is not quite there yet.

Flatpak to the rescue!

Implementing app restrictions generically may be close to impossible on the traditional desktop, but it is actually very much feasible on newer technologies such as Flatpak.

If you have an OSTree-based immutable filesystem where all user-managed apps are installed via Flatpak, such as Endless OS or SilverBlue, app restrictions suddenly becomes even more realistic.

In fact, we at Endless have implemented something like that already, even if a bit rudimentary.

Endless OS implementation of app restrictions

For the purpose of continuing the hackfest discussions, Allan managed to do a quick sketch about it:

Disclaimer: this is nowhere near being final.

An interesting aspect of the mockups is the “Supervisor Password”; a password that does not give full root permissions, and yet allows whoever is managing the system to assume the role of supervisor. Think of a teacher, without the administrator password, but still able to supervise students’ accounts.

But browsers…

Restricting websites, however, is remarkably tricky to accomplish. It is essentially impossible to whitelist websites, at least when implenting it outside the browsers themselves. In general, blacklisting is easier(ish) than whitelisting because we don’t have to deal with the case of websites accessing contents outside their domains.

I’m pretty sure this is a reasonably studied field though, and I simply lack the pre-existing knowledge.

What about me?

While discussing those aspects of restricting users, it quickly became clear that applying restrictions on yourself is perfectly valid. It is actually branded as “Digital Wellbeing” and similar on various mobile OSes.

Those who work in front of computers and have more control over their schedule will appreciate being able to restrict themselves and improve their health, focus, and productivity.

More mockups (and again, quick sketches, not final)

It is also interesting to see per-app usage:

It is not clear yet how a potential new Focus mode would interact with notifications.


You might notice that those mockups require some sort of a metrics system that would monitor which app the user is using. This could range from a simple event logger to a sophisticated daemon collecting much more. Nothing is settled in this front, no decision was made yet.

Of course, privacy concerns were taken into account. There is absolutely no room for sharing this data. All data would be stored locally.

My attendance to the Parental Controls & Metered Data hackfest was proudly sponsored by the GNOME Foundation.

Rewarding our Friends of GNOME

After my somewhat dark post about being a Free Software maintainer, a very significant number of people got in touch and asked how can they help me, and GNOME, more actively than saying “keep up the good work, we love y’all”. And so I thought that maybe we are not advertising well enough the various ways to contribute to GNOME beyond actually getting involved with the daily activities of the project.

The potentially most effective way to help GNOME is by donating to the GNOME Foundation and spreading the word. GNOME Foundation has two donation programs: one-time donations, and Friend of GNOME.

Becoming a Friend of GNOME is my favorite. The Friends of GNOME donation program is a monthly subscription where you can select a community member. The selected member will send you a thank you post card. Did you know that I can be adopted as a hacker through Friends of GNOME? Not only me but various other great community members!

I’m happy to say that many Friends of GNOME adopted me already! Naturally, I’m supposed to send thank you postcards.

But I won’t.

I think our Friends should be properly rewarded for helping Free Software.

Local Touch

Brazil has a rich and dynamic culture, with lots of influences from Portugal, Spain, Italy, various african “countries” (thinking of Africa in terms of countries is somewhat wrong; countries were defined by europeans, and do not represent the cultural diversity of Africa) and Asia. And I love that we have wide range of artistic and cultural production that covers this diversity.

It happens that I have a long-time contact with the Okinawan community in Brazil, and know a local Brazilian/Okinawan artist that can create fantastic pieces blending those different cultures. You can check her work at @jay_ceramicas on Instagram (and you should, her work is absolutely fantastic). If you appreciate art, and her art in special, consider requesting her artwork!

I asked her to create different pieces for our Friends of GNOME.


The process started with defining the topic of the art that will be produced.

We agreed on representing simultaneously the Brazilian and the Okinawan culture, with the elements that intersect both. Our Friends deserve unique and handcrafted pieces, and that’s what we did.

After she finishing crafting those pieces, I started assembling the gift boxes. It all starts with finding a good box, and gathering the materials:

Next step is preparing the box. First, the essentials: it should feel GNOME, smell GNOME.

Since the box may travel across oceans, let’s ensure the safety of the arts.

Starting to look good!

But that’s not enough. Our Friends chose GNOME to help, so I think it’s safe to assume they would like to show they’re GNOME users. Or at least GNOME supporters. So good set of stickers is a great addition!

The gift box is looking even better now!

Having stickers is excellent, but I don’t want them to turn into a mess when our Friends receive their boxes.

At this point, the boxes look pretty much ready.

But they aren’t! It’s so important to express gratitude. I’m grateful for our Friends to have adopted me, and I want to tell them that.

And now we have something deliverable!

If you are a Friend of GNOME, and adopted me, check your mail box; you might find a surprise… I may have done more than what I wrote here 🙂

And that way, I feel like I’m properly rewarding those who take the next step and, even without the time or the knowledge or the energy to be involved with GNOME, still contribute to the future of the project and of Free Software.

Thanks for supporting Free Software and GNOME.

You are gold.

On Being a Free Software Maintainer

Year is 2013. I learn about a new, alpha-quality project called “GNOME Calendar.” Intriguing.

I like calendars.

“Cool, I’ll track that,” said my younger self. Heavy development was happening at the ui-rework branch. Every day, a few new commits. Pull, build, test. Except one day, no new commits. Nor the next day. Or week. Or month. Or year. I’m disappointed. Didn’t want that project to die. You know…

I like calendars.

“Nope. Not gonna happen,” also said my younger self. Clone, build, fix bugs, send patches. Maintainer’s interest in the project is renewed. We get a new icon, things get serious. We go to a new IRC room (!) and make the first public release of GNOME Calendar.

One year passes, it is now 2015. After contributing for more than a year, Erick made me the de facto GNOME Calendar maintainer ¹. A mix of positive emotions flows: proud of the achievement; excitement for being able to carry on with my ideas for the future of the application; fear, for the weight of the responsibility.

But heck, I am a free software maintainer now.

That was 4 years ago. Time passes, things happen, experience is built. Experience that differs from what I originally expected.

Being a free software maintainer is a funny place to find yourself in. Good things came from it. Bad things too. Also terrible. And weird.

Naturally, there is a strong sense of achievement when you, well, achieve maintainership of a project. Usually, getting there requires a large number of interactions during a long period of time. It means you are trusted. It means you are trustworthy. It means you are skilled enough.

It also usually means stronger community bonds. Getting to know excellent people, that know a lot and are willing to share and mentor and help, is a life-changing experience. There is a huge human value in being surrounded by great people.

For those of us who enjoy coding, hooray! Full plate. Planning releases, coding and doing reviews can be fun too. You will fix problems, find solutions, think and design your code. There is a plethora of problems to fix in this plane of existence, and you have the chance to independently fix a few of them by yourself.

And people. There are good people in this planet. You eventually will receive a thank you email, or you will be paid a coffee. One way or another, people find their way to you.

People really do find their way to you.

See, sometimes the software you maintain, well, it crashes. It may lose someone’s data. Someone may trigger a unique condition inside the code that you never managed to do. These people may get angry, sad, and frustrated ².

And they will find their way to you.

You will be demanded to fix your software. You will be shouted. Sometimes, the line may be crossed, and you will be abused. “How dare you not (use your free time to) fix this ultra high priority bug that is affecting me?” or “This is an absolutely basic feature! How is it not implemented yet (by you on your free time)?!” or even “You made me move to Software Y, and you need to win me back” are going to be realities you will have to face.

You may get emotional about your code. You may feel ashamed of what you did, and do. After all, your code has bugs, there are numerous issues opened at your bug tracker, and people are complaining non-stop. (Oh and, naturally, there will be someone who will try their best to put you down with that.)

At one point, you will look at your issue backlog and feel a subtle despair when realise you won’t ever be able to fix all the bugs.

If you are open to review other people’s contributions, there is a high change you will find challengers disguised as contributors. And your code review will be treated as an intellectual battle between good and evil. And you will need to explain and clarify over and over, and deal with circular logic, and pretty much any tool people might use to win battles instead of improving their code. And that is incredibly tiresome.

You will be told that you need to develop a thick skin. To ignore that, let it go, think positive and don’t pay attention to all the shit that is being thrown at you and why are you so goddamn negative you’re a maintainer for christ sake.

You may not feel the joy of working on what you work anymore. You may want to move on. You may also not do that due to the sense of responsibility that you have to your code, your community, and the people who use your software.

Unfortunately, being a free software maintainer may have a high price to your psychological and emotional health. 

Four years ago, I certainly did not know that.

¹ – And by “maintainer”, I am talking about being an upstream code maintainer, not package maintainer.
² – Rightfully so. Nobody wants to lose their stuff, or have their workflow broken.

GNOME 3.32 and other ramblings

GNOME 3.32 was released this week. For all intents and purposes, it is a fantastic release, and I am already using the packages provided by Arch Linux’s gnome-unstable repository. Congratulations for everyone involved (including the Arch team for the super quick packaging!)

I have a few highlights, comments and thoughts I would like to share about this release, and since I own this blog, well, let me do it publicly! 🙂

Fast, Furiously Fast

The most promoted improvement in this release is the improved performance. Having worked or reviewed some these improvements myself, I found it a bit weird that some people were reporting enormous changes on performance. Of course, you should notice that GNOME Shell is smoother, and applications as well (when the compositor reliably sends frame ticks to applications, they also draw on time, and feel smoother as well.)

But people were telling me that these changes were game changing.

There is a grey line between the actual improvements, and people just happy and overly excited about it. And I thought the latter was the case.

But then I installed the non-debug packages from Arch repositories and this is actually a game changer release. I probably got used to using Mutter and GNOME Shell manually compiled with all the debug and development junk, and didn’t really notice how better it became.

Better GNOME Music

Sweet, sweet GNOME Music

One of the applications that I enjoy the most in the GNOME core apps ecosytem is GNOME Music. In the past, I have worked on landing various performance improvements on it. Unfortunately, my contributions ceased last year, but I have been following the development of this pretty little app closely

A lot of effort was put into modernizing GNOME Music, and it is absolutely paying off. It is more stable, better, and I believe it has reached the point where adding new features won’t drive contributors insane.

GNOME Web – a gem

In the past, I have tried making Web my main browser. Unfortunately, that did not work out very well, due to 2 big reasons:

  • WordPress would not work, and as such, I couldn’t write blog posts using Web;
  • Google Drive (and a few other Google websites) would be subtly broken.

Both issues seem to be fixed now! In fact, as you can see from the previous screenshot, I am writing this post from Web. Which makes me super happy.

Even though I cannot use it 100% of the time (mainly due to online banking and Google Meets), I will experiment making it my main browser for a few weeks and see how it goes.

GNOME Terminal + Headebars = 💖

Do I even need to say something?


As I write this, I am getting ready for next week’s Parental Controls & Metered Data Hackfest in London. We will discuss and try to land in GNOME some downstream features available at Endless OS.

I’m also mentally preparing for the Content Apps Hackfest. And GUADEC. It is somewhat hard once you realize you have travel anxiety, and every week before traveling is a psychological war.

Other Thoughts

This was a peculiar release to me.

This is actually the first release where I spent serious time on Mutter and GNOME Shell. As I said in the past, it’s a new passion of mine. Both are complex projects that encompasses many aspects of the user experience, and cleaning the code and improving it has been fantastic so far. As such, it was and still is a challenge to split my time in such a fragmented way (it’s not like I don’t maintain GNOME Settings, GNOME Calendar, and GNOME To Do already.)

Besides that, I am close to finishing moving to a new home! This is an ongoing process, slow and steady, it is becoming something I am growing to love and feel like home.

GNOME Settings: more GNOME, more settings

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.

New Panels


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:

Applications panel
The new Applications panel showing information and settings of a Flatpak-based application.

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.

Applications panel for a non-Flatpak application
Non-Flatpak applications don’t have as many controllable integration points.

There are more immediate improvements that will land before GNOME 3.32 release, but it’s a great addition already.


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:

Redesigned Sound panel
Redesigned Sound panel with a vertical layout and better organization of the options.

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.

Thanks to Benjamin Berg, however, this is not a problem anymore: the Display panel now uses modern best practices and is composed of smaller widgets. A new monitor scale widget is also on the way, although it potentially can be postponed to GNOME 3.34.

Responsive Panels

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:

Responsive GNOME Settings
Responsive GNOME Settings.

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!

GNOME Shell and Mutter: better, faster, cleaner

The very first update in the series is about GNOME Shell and Mutter. I’ve been increasingly involved with the development of those two core components of GNOME, and recently this has been the focus of my development time.

Fortunately, Endless allows me to use part of my work time to improve it. Naturally, I prioritize my upstream work considering what will impact Endless OS the most. So far, that lead to a series of very nice improvements to Mutter and GNOME Shell.


Most of my work time dedicated to GNOME Shell was oriented to performance and cleanup. At Endless, we have a modified GNOME Shell that constantly needs to be rebased. Since I’m taking care of these rebases now, it makes sense for me to also make myself familiar with the vanilla GNOME Shell codebase.


I’ll start with the work that makes me the proudest: removing the Shell.GenericContainer class.

First, a bit of history.

There was a time when GJS, the JavaScript engine that GNOME Shell is based on, did not support subclassing GObjects and overriding virtual functions. We could only instantiate GObject-based classes, and subclass them, all thanks to GObject-Introspection, but not override their virtual functions. This made, for example, implementing ClutterContent in JavaScript impossible.

For that reason, GNOME Shell developers created ShellGenericContainer: an actor that sends signals for various virtual functions. Because GJS supports signals, that worked well.

There are a few problems with that approach though:

  • Signals are slow, and should not be used on hot paths like layouting or rendering;
  • Going in and out of JavaScript territory is expensive;
  • It makes the JavaScript code slightly more complicated;

Thanks to the fantastic work by Jasper St. Pierre, GJS now supports overriding virtual functions. And that made Shell.GenericContainer obsolete. So I spent quite some time untangling it from GNOME Shell, and results were positive:
In general, running GNOME Shell without Shell.GenericContainer (blue line) led to more stable framerates compared to the current state (red line).

This is now merged and will be available with GNOME Shell 3.32, to be released on March 2019.

Improvements to the texture cache

After various investigations, another potential improvement that showed up was on StTextureCache. Textures (icons, image files, etc) are cached in GNOME Shell by StTextureCache, and that happened by keeping a ClutterTexture object alive.

That turned out to be a problem.

ClutterTexture is deprecated. Clutter has a new interface for drawing the contents of an actor: ClutterContent. It does not necessarily make the code faster, but it allows different actors to share a single ClutterContent without having to override ClutterActor.paint(). In other words, it is a nice and sane abstraction layer to control what an actor is drawing.

So I went ahead and wiped out ClutterTexture from StTextureCache. Then wiped it out entirely from GNOME Shell.

Unexpectedly, it made a small but noticeable difference! Icons are now slightly faster to load, but the most visible impact was in the startup animation.


I did not know how fun and exciting compositors could be. It definitely is a new passion of mine, working on Mutter! So much has happened that it’ll be hard to summarize.

Goodbye, Autotools

During last year’s GUADEC, Jonas Ådahl worked on a Meson port of Mutter. After a series of reviews, and a few follow-up fixes, it reached almost complete feature parity with Autotools – the only exception being installed tests.

So I went ahead and added installed tests to the Meson build too.

And also removed Autotools.

Naturally, builds are much faster now. Saving us a few minutes per day.

Wayland vs X11

Another area that was interesting to work on was untangling X11-specific code from Wayland, and vice-versa. There are a handful of developers working on that already, and I had my fair share in better splitting X11 and Wayland code paths in Mutter.

Specifically, I worked on splitting X11-specific code from MetaWindowActor into subclasses. Mutter already handles different surfaces correctly; on X11 sessions, all surfaces are MetaSurfaceActorX11, and under Wayland, MetaSurfaceActorWayland.

MetaWindowActor has now the same split: Wayland windows have a MetaWindowActorWayland associated, while X11 windows have MetaWindowActorX11.

Interestingly, XWayland windows are X11 windows with a Wayland surface. You can check that using GNOME Shell’s Looking Glass:

wayland vs x11.gif
Example of a Xwayland window; it has a MetaSurfaceActorWayland surface, and a MetaWindowActorX11 actor associated.

There’s a lot more happening in this front, but I’ll spare the words for now. You’ll hear more about it in the future (and not necessarily from me).

CPU-side picking

More recently, I’ve been experimenting with the Cogl journal and ironing out a few bugs that are preventing a completely CPU-side picking implementation.

Picking is the process to figure out which element is beneath the cursor. There are two big approaches: geometry-based, and color-based. On games, the latter is the usual approach: each object in the scene is drawn with a plain color, and the final image is read to find out the color beneath a point. Geometry-based picking is what browsers usually do, and it’s basically math around rectangles.

Clutter uses color-based picking, but has a nice feature around that: a journal that tracks drawing operations and, under some conditions, hits an optimized path and does geometry-based picking. This is interesting for Mutter and GNOME Shell because it avoids sending draw operations to the GPU unecessarily when picking, reducing resource usage.

Unfortunately, due to various bugs and implementation details, we do not hit this optimization, causing GPU commands to be issued when they could be avoided.

Figuring out these bugs is what I’ve been experimenting with lately.



There’s much more that happened, so I will probably do a part 2 of this article soon. But those are big points already, and the post is becoming lengthy.

Many of these experiments and investigations already landed, and will be available with GNOME 3.32. This is all valuable work that is partially sponsored by my employer, Endless, and I’m happy to keep working on it!

Sorry for the silence

It’s been more than 6 months that I do not write in this space. Honestly, that’s the longest period of silence I’ve ever had.

There are various factors that, combined, ended up causing this period of seclusion. Learning about new, massive projects (GNOME Shell, Mutter and GNOME Settings) is one of them. Moving to a new home and marriage is another.

After finishing Masters last year, I have spent the time working with Endless full-time, and dedicating myself to parallel projects, such as Japanese language, music, gardening, and martial arts. It’s being wonderful, but that somehow distracted me from communicating changes to the community.

And for that, my apologies.

I’ll publish a series of blog posts talking about various GNOME-related activities that I’ve been involved since the last update. Hopefully they will be interesting enough.

My Perspective on This Year’s GUADEC

Greetings GNOMEies

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.

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.

GNOME Settings

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!


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:

Tobias' GNOME To Do mockups in my engineering notebook.
Tobias’ GNOME To Do mockups in my engineering notebook.

I was also excited to see GNOME To Do stickers there:

gnome-todo stickers
Sexy GNOME To Do stickers, a courtesy of Jakub

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!

I was proudly sponsored by the GNOME Foundation.

Sponsored by the GNOME Foundation

Going to GUADEC

Another year, another GUADEC, and here I am crossing oceans to see my fellow GNOMEies. This time, it’s going to be particularly challenging: 32 hours of travel, 4 connections, no vegan meal available. I heard GNOME are resilient folk though, perhaps this is the proving?

I am proudly being sponsored by the GNOME Foundation.

Sponsored by the GNOME Foundation

See y’all there!

Improving the development experience for GNOME Settings

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.


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.

You'll be warned when running Settings with Flatpak.
You’ll be warned when running Settings with Flatpak.

Spotlights to the blueish “I am a development version” header bar:

Blue headerbars
Fancy 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 in action
We’re in a good state, everything is building!

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:

CI in Gitlab
The tests run on every commit, and every merge request.

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!


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.


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.