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
Applications
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:
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.
Non-Flatpak applications don’t have as many controllable integration points.
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 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
Display
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:
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!
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.
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.
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.
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.
Mutter
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.
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.
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:
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.
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!
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.
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.
GUADEC
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 Sausages
Vegan Lasagna
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 😛
Talks
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!
GJS
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.
GTK
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!
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:
Tobias’ GNOME To Do mockups in my engineering notebook.
I was also excited to see GNOME To Do stickers there:
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.
Epilogue
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!
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.
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.
You’ll be warned when running Settings with Flatpak.
Spotlights to the blueish “I am a development version” header bar:
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:
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:
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!
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.
If you were having crashes and problems, please upgrade immediately. Quite a few crashers were fixed, and a few polishes went in too. Hopefully the experience of using Calendar will be much more pleasant now.
This new version was available in Flathub just half an hour after yesterday’s official announcement. Flathub is the only distribution mechanism that I officially support – if you rely on distro packages, please ask your distro maintainers to update.
at this point, I think it’s safe to assume that many of you already heard of a memory leak that was plaguing GNOME Shell. Well, as of yesterday, the two GitLab’s MRs that help fixing that issue were merged, and will be available in the next GNOME version. The fixes are being considered for backporting to GNOME 3.28 – after making sure they work as expected and don’t break your computer.
First, I’d like to thank the GJS maintainer, Philip C., for all the hand-holding, the reviews, and the incredibly insightful discussions we had. Secondly, to my employer, Endless, for the support they gave me to fix this issue. And last but not least, to the Ubuntu folks, which made a public call for testing with the changes – this will give us confidence that the fix is working, and that backporting it will be a relatively safe and smooth process.
As always, great new features and fixes are a courtesy of Endless
I’m writing this blog post with three goals in mind:
Explain in greater details what is the issue (or at least, what we think it is), the journey to find it, and how it was fixed.
Give more exposure to important extra work from other contributors that absolutely deserve more credits.
Expose a social issue that showed up during this time, and open a discussion about it.
Memory Leak
To me, it all started when I saw GitLab’s ticket #64 passing by in the IRC channels. It was challenging enough, I was curious to dig into GNOME Shell/Mutter/GJS internals, perfect match. Of course, when you’re not familiar with a given codebase, the first step to fixing a bug is being able to reproduce it, so I started to play around with GNOME Shell to see if I could find a reliable way to reproduce it.
Well, I found a way and wrote a very simple observation: running animations (showing and hiding the Overview, switching applications using Alt+Tab, etc) was reliably increasing memory usage. Then a few people came in, and dropped bits of useful information here and there. But at this point, it was still pointing to a wide range of directions, and definitely there was not actionable task there. This is when OMG! Ubuntu first wrote about it.
Carlos Garnacho then came in and wrote a pretty relevant comment with important information. It was specially insightful because he put numbers on the guts of GNOME Shell. His comment was the first real solid step to uncover what was going on.
A week passed, and I experimented different toys tools in order to have a better understanding of memory management inside GNOME Shell. This is the kind of tedious work that nobody talks about, but I learned tons of new stuff, so in the end it was worth the hassle. I even wrote about my crazy experiments, and the results of this long week are documented in a long comment in GNOME/gnome-shell#64. I kept experimenting until I reached heapgraph, an interesting tool that allowed generating the following picture:
Notice the sudden drops of memory at x=42 and x=71
Well, as stated in the comment, GJS’ garbage collect was indeed collecting memory when triggered. Problem is, it wasn’t being triggered at all. That was the leading clue to one of the problems that was going on. One idea came to my mind, then, and I decided to investigate it further.
A Simple Example
Consider that we have a few objects in memory, and they have parent/child relationships:
The root object is “1”
Lets suppose that we decided that we don’t need the root object anymore, so we drop a reference to it, and it is marked for garbage collection.
The root object is now marked for garbage collection
If we destroy the root object, we would need to destroy the other objects related to it, and go destroying everyone that depended, directly or indirectly, on the root object. Traditionally, JavaScript objects track who they own, so the garbage collector can clean up every other dependent object. Here’s the problem: C objects don’t track who owns them; instead, they only track how many owners they have. This is the traditional reference counting mechanism, and it works fine in C land because C is not garbage collected. To the garbage collector, however, the C objects would look like this:
The garbage collector has no means to know the relationships between C objects.
The garbage collector, then, will go there and destroy the root one. This object will be finalized, and the directly dependent objects will be marked for garbage collection.
Only the directly dependent objects are marked for the next garbage collection.
But… when will the next GC happen? Who knows! Can be now, can be in 10 minutes, or tomorrow morning! And that was the biggest offender to the memory leak – objects were piling up to be garbage collected, and these objects had child objects that would only be collected after, and so it goes. In other words, this is not really a memory leak – the memory is not being lost. I’d label it as a “misbehavior” instead.
The Solution
While people might think this was somehow solved, the patches that were merged does not fix that in the way it should be fixed. The “solution” is basically throwing a grenade to kill ants. We now queue a garbage collection every time an object is marked for destruction. So every single time an object becomes red, as in the example, we queue a GC. This is, of course, a very aggressive solution.
But it is not all bad. Some early tests shows that this has a small impact on performance – at least, it’s much smaller than what we were expecting. A very convincing explanation is that the higher frequency of GCs is reducing the number of things that are being destroyed each GC. So now we have smaller and more frequent garbage collections.
EDIT: Looks like people need more clarification here, since the comments about it are just plain wrong. I’ll be technical, and precise – if you don’t understand, please do some research. The garbage collector is scheduled every time a GObject wrapped in GJS has its toggle reference gone from >1 to 1. And scheduled here means that a GC is injected into the mainloop as an idle callback, that will be executed when there’s nothing else to be executed in the mainloop. The absolute majority of the time, it means that only one GC will happen, even if hundreds of GObjects are disposed. I’ve spotted in the wild it happening twice. This fix is strictly specific to GObjects wrapped by GJS; all other kinds of memory management, such as strings and whatever else, aren’t affected by this fix. Together with this patch, an accompanying solution landed that reduces the number of objects with a toggle reference.
This obviously needs more testing on a wider ranger of hardwares, specially on lower ends. But, quite honestly, I’m personally sure that this apparently small performance penalty is compensated by the memory management gains.
Other Improvements
While the previous section covered my side of this history, there are a few other contributors that did a great job, and I think it would be unfair with them if their work was not properly highlighted.
Red Hat’s Carlos Garnacho published two merge requests for GJS that, in my testing, substantially improved the smoothness of GNOME Shell. The first one changes the underlying data structure of JS objects, which allows us to stop using an O(n) algorithm and starting an O(1) one. The second one is particularly interesting, and it yields the most noticeable improvements in my computer. Gross, it vastly reduces the number of temporary memory allocations. He also has a number of patches on Mutter and GNOME Shell.
Another prominent contributor regarding performance is Canonical’s Daniel van Vugt, which helped early testing the GJS patches, and is doing some deep surgeries in Mutter to make the rendering smoother.
And for every great contributor, there is a great reviewer too. It would be extremely unfair if those relevant people haven’t had their work valued by the community, so please, take a moment to appreciate their work. They deserve it.
Final Thoughts
At this point, hopefully the cautious reader will have at least a superficial knowledge on the problem, the solution, and other relevant work around the performance topic. Which is good – if I managed to communicate that well enough, by the time you finish reading this blog post, you’ll have more knowledge. And more knowledge is good.
You can stop here if you want nothing more than technical knowldedge.
Still around?
Well, I’d like to raise an interesting discussion about how people reacted to the memory leak news, and reflect upon that. By reading the repercussions of the news, I found it quite intriguing to read comments like these:
As a regular contributor for the last few years, this kind of comment sound alien to me. These comments sound completely disconnected to the reality of the development process of GNOME. It completely misses the individuality of the people involved. Maybe because we all know each other, but it is just plain impossible to me to paint this whole community as “they”; “GNOME developers”; etc. To a deeper degree, it misses the nuances and the beauty of community-driven development, and each and every individual that make it happen.
To some degree, I think this is a symptom of users being completely disconnected to GNOME development itself.
It almost feels like there’s a wall between the community and the users of what this community produces. Which is weird. We are an open community, with open development, no barriers for new contributors – and yet, there is such a distance between the community of users and the community of developers/designers/outreachers/etc.
Is that a communication problem from our side? How can we bridge this gap? Well, do we want to bridge this gap? Is it healthy to reduce the communication bandwidth in order to increase focus, or would it be better to increase that and deal with the accompanying noise?
I would love to hear your opinions, comments and thoughts on this topic.
It’s been a long time I don’t write here. These past months were excruciatingly busy and intense, and lots of things happened but I didn’t manage to keep up with the blog posts. I’ll try to condense everything that happened and is still happening and will happen here.
Calendar & To Do
I spent a good part of January polishing and fixing bugs in Calendar and To Do. Just to name a few:
The support for weather forecast in Calendar was polished.
Calendar’s codebase was modernized and cleaned up. This has no user-visible side effects (except, of course, the bugs that are avoided because of that), but maintaining a clean and modern codebase is absolutely essential to keep the project healthy, the maintainers motivated, and the new contributors excited.
Many warnings and crashes were fixed.
GNOME To Do
The Todoist integration was reworked, and is much more stable and functional now. More improvements will land before 3.28, but this was already a remarkable rework.
The Todo.txt integration also received some attention, but is not yet where I want it to be. The support for subtasks was temporarily dropped until we figure out a way to implement it correctly. If anyone knows something about it, please comment below.
The Flatpak support matured a lot in the past few days, and now the Flatpak Nightly version will enable tracing by default. This will simplify the lives of users that want to test it and report bugs; and maintainers (read: me) that want to fix stuff before the stable release.
I’m feeling a bit pressured to put these apps in a good shape for GNOME 3.28, specially To Do, since it was selected to be installed by default on Ubuntu and I don’t want the new users having a bad and unstable experience. I also don’t want to deal with hundreds of possibly bugs after the release.
Settings (aka Control Center)
I’ve been working a lot recently on GNOME Settings, and reviewed (quite literally) more than a hundred patches in the past couple of weeks. Lots of interesting stuff landed:
GNOME Settings switched to Meson. The build times were cut down by a factor of 5, it is amazing!
A new Background panel is in the works, and appearently reaching a good state. Hopefully it’ll be ready before 3.28.
A new privacy option is about to be added (we’re just figuring out the wording) that blocks phoning home to detect the network status. Privacy-aware users will enjoy that new option.
Lots of smaller cleanups and code refactorings.
Now, something happened to Settings these days; it lost its maintainer. I’ve been trying to act as a maintainer during this blackout, and I’d be happy to continue doing that. Fortunately, there are many other heroes involved (shouts to Bastien Nocera, Debarshi Ray, Robert Ancell, Julian Sparber, Ondrej Holy, and many others for your contributions and being great maintainers.)
Hopefully Settings is already in a good shape for 3.28, and will get even more solid in the following weeks.
A New Master
Big news: I’ve finished writing my Masters’ thesis, and it’s over now. It was a hell of a ride, and seeing in retrospective, I think enrolling a Masters did me more harm than good.
I’m finishing it with a bittersweet taste in my mouth; I’ve learned a lot, but, for many reasons, it was a bad experience overall that led me to a few burnouts and episodes of night terror and depression. I made the mistake of not stopping when I should, and advancing in this shitswamp had pretty catastrophic implications, including physical ones (in one of these nights of terror, I cut my own hand with a knife, and it was painful to use the computer for a couple of weeks.)
It is now over, and I’ll need to recover from the past 2.5 years. Which leads us to…
A Goodbye
But hey, it’s only for a month! I’ll be taking some weeks off and disconnecting from everything (including GNOME, Endless, family and everything else), a time that I’ll spend backpacking through some places around the world. I’ll refrain to tell where since I want to avoid being recognized (it’s not like I’m famous, but who knows!). I’ll be with my wife, and only her, during this period.
I just hope my apps don’t fall apart during this time. For someone who is routinely connected and helping others on IRC channels, disconnecting will be an interesting experience; perhaps agonizing in the first few days, but only time will tell.
It’s been a long time with no news. I guess work and masters are really getting in the way… good news is that I’ll finish masters in 2 months, and will have some free time to devote to this beloved project.
“Bad” news is that, after almost 6 years, I’ll finally take some time to have a real vacation. I’ll stay 3 weeks out of the loop in February, a time where I’ll be traveling to the other side of the world, watching the sunset at the beach with my wife. Without a computer. While it’s unfortunate to the community, I think this time is necessary for my mental health – I’ve gone way too many times through the almost-burned-out state recently.
But even with all of these thing in our way, thanks to the help of awsome old and new contributors, Calendar and To Do received a lot of new features!
Calendar
Lets begin with my beloved Calendar. My focus for the past weeks was rewriting the Month view. It was a hard, painful process, but I can say for sure now that, of the very few responsive widgets in GNOME, the Month view is the best one! 😛
The most substantial changes were:
The day numbers are at the top of each cell now. This is thanks to the hard design work of Allan Day, Jean-François and Lapo.
Each cell now only shows the overflow button when absolutely necessary. When implementing this new behavior, a few longstanding issues were fixed.
The Month view now finally has a fully working, sane code to deal with RTL languages.
When clicking the +N button, the cell “zooms in” and display the list of events. This is a big design improvement over the popovers that we were using.
Code-wise, the Month view code that position the events is an order of magnitude simpler and easier to read. It may sound like a purely technical matter, but it has user-visible effects too: easier, cleaner code means more features and less issues in the future.
Of course, no words can make people as excited as a sequence of pictures! Lets check this out:
The animations were implemented usuing the animation framework in libdazzle, all thanks to Christian Hergert’s work on GNOME Builder. Kudos!
For the next cycle, thanks to the hard work of a new and awsome contributor Florian Brosch, this is what’s coming next:
Weather indication
We’re on track to land the features that were proposed for this cycle. You can check out the plans at the Roadmap page of Calendar. You can also get help us with these tasks with design, code and testing!
To Do
GNOME To Do also received a lot of attention already. We’re going through a big redesign, thanks to the leading design work of Tobias Bernard, and the results are already gratifying.
The immeditaly noticeable change is the tasklist view:
New tasklist view in To Do 3.27
The rows are entirely draggable now. I’ll continue working on these features, but more importantly, I want people to take some of this work over and contribute to the project!
Talking about managing tasks, GNOME To Do was moved to GitLab! I can’t state how much of an improvement it is over the previous Bugzilla approach. We now have an updated and organized Kanban Board:
GNOME To Do in GitLab: the Kanban Board
The reason for that is to have a consolidated workflow:
A designer moves the task to “Design” column and works on it.
Once design is settled, a developer moves the task to the “Development” column and fixes/implements the task.
When the task if implemented, the developer moves the task to “Code Review” column, and a maintainer will review the code.
Once the code is reviewed and the code landed, the task is moved to the “QA” column, where a tester will pick up and test it.
When all the regressions and issues of that task are fixed, the task is closed
So far, the experience with this workflow has been outstanding. We were able to find out much more bugs due to QA being a first-class citizen in the process. Filing bugs is now a breeze too! There are bug templates already available, and I took the burden and made a colossal cleanup and organization of the bug list:
GNOME To Do in GitLab: Issue Templates
I encourage everyone to not trust me and go check it out: https://gitlab.gnome.org/GNOME/gnome-todo. The downside is that I’m feeling incredibly demotivated to check Calendar bugs in Bugzilla now 😦
We’re Not Quite There Yet
While many of these changes are super exciting, this is just the first part of the cycle. There are much more to work on, and the more people get involved, the more we will accomplish. Things are moving in a fast pace, and I’m incredibly happy with the direction of these projects.
To help pushing community involvement, I went ahead and wrote a page describing how can you help testing. With Flatpak, this is ridiculously easy – and yet, absolutely necessary! So, don’t hesitate to get in touch and help us shaping the next GNOME version.
