September 21, 2019

Back to University

I stopped my master degree 6 years ago, partly because it was not compatible with open-source development. And with a bachelor degree that is worth something on the job market, I was able to apply to job offers and start working, and that’s what I did. But I now regret it, I was not satisfied by my day job, and when I see job offers requiring a bachelor degree in Belgium, most of the time I’m not interested.

So, I’ve taken the hard decision to start again studies, to finish my master degree in computer science!1) It’s a bit strange to go again to courses, studying etc. But I’m re-adapting.

In my last blog post I said “back to GNOME developmentâ€�, but this time around my studies are the priority. And to avoid stress/burnout, I try to no longer work the evenings and weekends, so it drastically limits my time that I’ll devote to GNOME.

Footnotes   [ + ]

1. At the UCLouvain University, in the modern and pedestrian city of Louvain-la-Neuve, Belgium (link to the gastronomy page, the most important thing 🙂 ).

September 20, 2019

Maintainer wanted: gnome-directory-thumbnailer

tl;dr: I’m giving up maintaining gnome-directory-thumbnailer as it no longer scratches my itch — it’s yours if you want it.

gnome-directory-thumbnailer is a little project I started a while ago for creating thumbnails for directories (rather than showing a plain directory icon for them in the file manager). Times change, I no longer have the itch that it was developed to scratch, and so I’m giving up maintenance of it after making the 0.1.11 release.

If you use it, or think you should use it, please care about it and take over maintenance. It needs porting to Meson, and some changes to handle working in the brave new world of sandboxed thumbnailers. It’s not a complicated code base to maintain.

If you’re interested, please get in touch, or send a merge request through.

The Cause and the Effect

This week Richard Stallman resigned as president of the Free Software Foundation. It is long overdue, and I am grateful to Selam G., the writer of the blog post that sparked it.

I was disappointed to read that Michael Meeks’ post Tuesday on Planet GNOME repeated the excuses I’ve seen on Twitter and Reddit about mob rule and mischaracterization. Michael is of course entitled to that opinion, and unlike most Twitter and Reddit threads I’ve seen, has expressed it thoughtfully (which is why I think I can actually achieve something by writing this in turn.) I personally believe that that opinion does not stand up under scrutiny, and I hope writing a counterpoint might give him or others in the GNOME community food for thought.

I believe that we — especially in the GNOME community where it’s a goal to hold ourselves to high standards of treating each other well — must not let ourselves fall into the trap of saying ‘Stallman was just defending a friend, out come the pitchforks, just for one email, who will they come for next’ and thereby fail to see the whole picture. If it was really just one email and not years of well-documented bad behaviour and refusal to change, we’d be having an entirely different conversation.

Many who are grateful that Stallman has finally left the FSF are nonetheless anxious or grieving in some way: for the ideal of someone who may have been a hero to us before we realized what he was like in person; for trepidation about the future of the free software movement; or even for having to watch Stallman bring himself down in an avoidable, decades-long slow-motion train wreck. This is all understandable, but we should not let grief channel itself into minimizing or excusing or working around bad behaviour, or rules-lawyering about the interpretation of Stallman’s words. These two lines from Leonard Cohen and Sharon Robinson, singing about a different kind of grief, seem oddly fitting here:

Do not choose a coward’s explanation
That hides behind the cause and the effect

I will also refer you to Thomas Bushnell’s reflections from which I’d like to emphasize this paragraph, which is a response (expressed better than I could myself) to anyone who thinks that this one event can be regarded in isolation:

RMS’s loss of MIT privileges and leadership of the FSF are the appropriate responses to a pattern of decades of poor behavior. It does not matter if they are appropriate responses to a single email thread, because they are the right thing in the total situation.

The words of Matt Blaze are also appropriate here:

We will, as always, be treated to much examination of the precise nature and mass of the last straw, with observations that it would not by itself be sufficient to cause spinal damage in camels, and is therefore utterly harmless.

This post is my personal opinion, and is not written on behalf of the GNOME Foundation, its board of directors, nor anyone else.

September 19, 2019

2019-09-19 Thursday.

  • ownCloud conference, met another set of interesting people and caught up with the new OCIS, Phoenix developers.

September 18, 2019

2019-09-18 Wednesday.

  • More work on slides in the morning, headed back to the conference.
    ownCloud / Collabora talk as hybrid PDF

  • Up late .

Epiphany Technology Preview Users: Action Required

Epiphany Technology Preview has moved from to The old Epiphany Technology Preview is now end-of-life. Action is required to update. If you installed Epiphany Technology Preview prior to a couple minutes ago, uninstall it using GNOME Software and then reinstall using this new flatpakref.

Apologies for this disruption.

The main benefit to end users is that you’ll no longer need separate remotes for nightly runtimes and nightly applications, because everything is now hosted in one repo. See Abderrahim’s announcement for full details on why this transition is occurring.

September 17, 2019

Towards a UX Strategy for GNOME (Part 3)

This post is part of a series on UX strategy. In my previous two posts, I described what I hope are the beginnings of a UX strategy for GNOME. In the first post, I described some background research and analysis. In the second post, I introduced what I think ought to be the high-level goals and principles for the UX strategy.

Now it’s time for the fun bit! For this instalment, I’m going to go over recent work that the GNOME design team has been doing. I’m doing this for two reasons. First: I want to show off some of the great work that the design team has been doing! Second, I want to show this design work fits into the strategic approach that I’ve previously described. A key element of that plan was to prioritise on areas which will have the biggest impact, and I’m going to be using the prioritisation word a lot in what follows.

This post is intended as an overview and, as such, I’m not going to go into the designs in great detail. However, there are detailed designs behind everything I’m presenting, and there’s a list of links at the end of the post, for those who want to learn more.

Core System

In my previous post, I argued that prioritisation ought to be a key part of our UX strategy. This is intended to help us drive up quality, as well as deliver impactful improvements. One way that we can prioritise is by focusing on those parts of GNOME that people use all the time.

The obvious place to start with this is the core elements of the GNOME system: those parts of the software that make up the most basic and common interactions, like login, app launching, window switching, notifications, and so on. I believe that improving the level of polish of these basic features would go a long way to elevating the standing of the entire platform.

Unlock and Login

Login screen mockup

The design team has longstanding ambitions to update GNOME’s unlock and login experience. The designs have continued to evolve since I last blogged about them, and we continue to return to and improve them.

System unlock is a classic example of a touchstone experience. People unlock their computers all the time and, as the entry point to the system, it comes to define the overall experience. It’s the face of the system. It is therefore critical that unlock and login leave a good impression.

The new designs are intended to reduce the amount of friction that people experience when they unlock. They require users to take fewer steps and involve going through fewer transitions, so that people can get to their session faster and more seamlessly. This will in turn make the experience feel more comfortable.

The designs are also intended to be beautiful! As an emblematic part of the GNOME UX, we want unlock and login to look and feel fantastic.


Notifications popover mockup

The design team has been systematically reviewing almost all parts of the core GNOME system, with a view to polish and refine them. Some of this work has already landed in GNOME 3.34, where you will see a collection of visual style improvements.

One area where we want to develop this work is the calendar and notifictions list. The improvements here are mostly visual – nicer layout, better typography, and so on – but there are functional improvements too. Our latest designs include a switch for do not disturb mode, for example.

There are other functional improvements that we’d like to see in subsequent iterations to the notification list, such as grouping notifications by application, and allowing notification actions to be accessed from the list.

Notifications are another great example where we can deliver clear value for our users: they’re something that users encounter all the time, and which are almost always relevant, irrespective of the apps that someone uses.

System Polish

System menu and dialog mockup

Our core system polish and refinement drive knows no bounds! We have designs for an updated system menu, which are primarily intended to resolve some long-standing discoverability issues. We’ve also systematically gone through all of the system dialogs, in order to ensure that each one is consistent and beautiful (something that is sadly lacking at the moment).

These aren’t the only parts of the core system that the design team is interested in improving. One key area that we are planning on working on in the near future is application launching. We’ve already done some experimental work in this area, and are planning on building on the drag and drop work that Georges Stavracas landed for GNOME 3.34.


The principle of prioritisation can also be applied to GNOME’s applications. The design team already spends a lot of time on the most essential applications, like Settings, Software and Files. Following the principle of prioritisation, we’ve also been taking a fresh look at some of the really basic apps that people use every day.

Two key examples of this are the document and image viewers. These are essential utilities that everyone uses. Such basic features ought to look and feel great and be firmly part of the GNOME experience. If we can’t get them right, then people won’t get a great impression.

Today our document and image viewers do their jobs reasonably well, but they lack refinement in some areas and they don’t always feel like they belong to the rest of the system. They also lack a few critical features.

Document viewer mockup
Document viewer mockup
Image viewer mockup
Image viewer mockup

This is why the design team has created updated designs for both the document and image viewers. These use the same design patterns, so they will feel like they belong together (as well as to the rest of the system). They also include some additional important features, like basic image editing (from talking to GNOME users, we know that this is a sorely missed feature).

It would be great to extend this work to look at some of the other basic, frequently-used apps, like the Text Editor and Videos.

There’s a lot of other great application design work that I could share here, but am not going to, because I do think that focusing on these core apps first makes the most strategic sense.

Development Platform

Another way that we can prioritise is by working on the app development platform. Improvements in this area make it easier for developers to create apps. They also have the potential to make every GNOME app look and behave better, and can therefore be an extremely effective way to improve the GNOME UX.

Again, this is an area where the design team has already been doing a lot of work, particularly around our icon system. This is part of the application platform, and a lot of work has recently gone into making it easier than ever to create new icons as well as consume the ones that GNOME provides out of the box. If you’re interested in this topic, I’d recommend Jakub’s GUADEC talk on the subject.

GTK widget mockup
Mockups for menus, dropdown lists, reorderable lists, and in-app notifications

Aside from the icon system, we have also been working to ensure that all the key design patterns are fully supported by the application development platform. The story here is patchy: not all of the design patterns have corresponding widgets in GTK and, in some cases it can be a lot of work to implement standard GNOME application designs. The result can also lack the quality that we’d like to see.

This is why the design team has been reviewing each of our design patterns, with a view to ensuring that each one is both great quality, and is fully supported. We want each pattern to look great, function really well, and be easy for application developers to use. So far, we have new designs for menus, dropdown lists, listboxes and in-app notifications, and there’s more to come. This initiative is ongoing, and we need help from platform and toolkit developers to drive it to completion.

What Next?

UX is more than UI: it is everything that makes up the user’s experience. As such, what I’ve presented here only represents a fraction of what would need to be included in a comprehensive UX strategy. That said, I do think that the work I’ve described above is of critical importance. It represents a programme to drive up the quality of the experience we provide, in a way that I believe would really resonate with users, because it focuses on features that people use every day, and aims to deliver tangible improvements.

As an open, upstream project, GNOME doesn’t have direct control over who works on what. However, it is able to informally influence where resources go, whether it’s by advertising priorities, encouraging contributions in particular areas, or tracking progress towards goals. If we are serious about wanting to compete in the marketplace, then doing this for the kind of UX programme that I’ve described seems like it could be an important step forward.

If there’s one thing I’d like to see come out of this series, it would be a serious conversation about how GNOME can be more strategic in its outlook and organisation.

This post marks the end of the “what” part of the series. In the next and final part, I’ll be moving onto the “how”: rather than talking about what we should be working on and what our priorities should be, I’ll set out how we ought to be working. This “how” part of the equation is critical: you can have the best strategy in the world, but still fail due to poor processes. So, in the final instalment, we’ll be discussing development process and methodology!

Further Reading

More information about the designs mentioned in this post:

September 16, 2019

GNOME relationship with GNU and the FSF

On Saturday, I wrote an email to the FSF asking them to cancel my membership. Other people who I greatly respect are doing the same. This came after the president of the FSF made some pretty reprehensible remarks saying that the “most plausible scenario is that [one of Epstein’s underage victims] presented themselves as entirely willing” while being trafficked. This isn’t the only incident, but it is the straw that broke the camel’s back.

In my capacity as the Executive Director of the GNOME Foundation, I have also written to the FSF. One of the most important parts of my role is to think of the well being of our community and the GNOME mission. One of the GNOME Foundation’s strategic goals is to be an exemplary community in terms of diversity and inclusion. I feel we can’t continue to have a formal association with the FSF or the GNU project when its main voice in the world is saying things that hurt this aim.

I greatly admire the work of FSF staffers and volunteers, but have now reached the point of concluding that the greatest service to the mission of software freedom is for Richard to step down from FSF and GNU and let others continue in his stead. Should this not happen in a timely manner, then I believe that severing the historical ties between GNOME, GNU and the FSF is the only path forward.

Edit: I’ve also cross-posted this to the GNOME discourse instance.


Morning at Thessaloniki

Sorry for blogging lately, better late than never. :)

Thessaloniki is very peaceful place, every morning I liked to walk along the seaside to the venue. As usual, it was a great and enjoyable GUADEC, thanks to everyone who helped to make it.

In core days I attended a lot of great talks in this year, I learned a lot of latest status of GNOME, and here are my favorite talks, “Managing GNOME Sessions with Systemd“, “State of the Shell“, “Packing up Boxes“, “Modernizing Desktop Linux Development with Containers“, “Is the Linux Desktop Really Dead?“.

I also enjoy watching Lighting talks every year. In this year Britt Yazel’s lighting talks, I knew the GUADEC App was based on Connfa, and it’s also an open source project. This App is very convenient, I could check schedule at any time.

And after the core days, I took part in “Rust BoF” by SebastianDröge , it’s a great BoF to learn the Rust and GStreamer step by step. And of course the Beach BoF, not to be missed, the amazing beach is unforgettable.

GNOME Bingo is a very good ice-break game, it gave me a lot of fun. From it I knew about the current GNOME staffs, GNOME ‘s Old Farts Club, Daiki Ueno could speak 4 languages counting c++, and so on.

I hope that we could also have GNOME.Asia App and GNOME.Asia Bingo in GNOME.Asia Summit. :)

Sunset at Thessaloniki

As usual I would like to thanks the GNOME Foundation for sponsoring my trip to Greece and making all this possible, it gave a good chance to meet old and new friends. And also thanks Canonical for conference leave.

Meet the GNOMEies: Sammy Fung

Sammy is a freelancer, community organizer, and GNOME enthusiast from Hong Kong. For almost 20 years, Sammy has been using, GNOME and building community in Asia.

A photo of Sammy Fung holding up two firefox signs. He is wearing a suit jacket and a blue collared shirt. He has glasses and his hair is sticking up.

Tell us a little bit more about yourself.

Currently, I am a freelancer which works on web scraping, python, data analytics, Linux, and networks. I was an owner and the director of small IT business, with my experiences in the open source, technology, community, and business, I organise local and regional open source communities and conferences in Hong Kong and Asia, travel between Asian and US cities to attend, speak, and organise open source events.

What is your role within the GNOME community?

I co-lead at GNOME Asia committee

Do you have any other affiliations you want to share?

I’m a Mozilla Representative, the President at Open Source Hong Kong, organiser of PyCon HK, and founder of Hong Kong Open Source Conference.

Why did you get involved in GNOME?

I am a GNOME user since 2000, and I think that GNOME is the most important software for Linux desktop. I thought that we should organise an event in Hong Kong for Linux desktop to promote and develop it. GNOME is the key.

Why are you still involved with GNOME?

As a user in Hong Kong, we embrace the different cultures from West and East. I keep my contributions to link up with East and West in different Asia cities when my living and income allows me to do so.

What are you working on right now?

After I take over the leadership at GNOME Asia Committee, I called for meetings for the GNOME.Asia Summit. I communicate with the local team for it.

What are you excited about right now – either in GNOME or free and open
source software in general?

It is not easy to sustain a desktop project, but GNOME is still the number one desktop environment on Linux!

What is a major challenge you see for the future of GNOME?

To sustain and grow GNOME, I hope that more GNOME contributors can be employed to achieve different missions of the project, to create more resources (e.g. marketing and documentation) for GNOME. On the other hand, we should also consider how to integrate GNOME and the open web seamlessly. I hope GNOME can become software that is not just a desktop environment, but a desktop ecosystem. It is not only in technical but also in business, the community, and the market.

What do you think GNOME should focus on next?

  1. Community building;
  2. Educating youth about the open desktop; and
  3. Turning the desktop environment to the desktop ecosystem.

Edited for content and clarity. Photo provided by Sammy Fung.

September 15, 2019

GNOME and gestures, Part 2: HdyLeaflet

This is part 2 of a mini-series. Part 1.

Shortly after the WebKit gesture was merged, I started experimenting with making this gesture more widely available. The first step was porting it to Vala and decoupling from WebKit. Since I wrote this part of the gesture tracker from scratch anyway, it was simple and straightforward. The resulting playground project was also used as a convenient place to quickly iterate on the WebKit gesture itself. Later I also reimplemented rendering to match the WebKit one. Here’s how it looked at various points of time:

Swipe demo 1 Swipe demo 2 Swipe demo 3 Swipe demo 4

Other than that, I used the swipe tracker to make a few more demos for Tobias Bernard:

Phosh mockup Back gesture mockup

Check out his GUADEC talk showcasing the second demo! :)

At the same time, I started integrating it into libhandy by supporting back/forward swipe in HdyLeaflet. And there I hit four problems:

1. Transitions and visible-child

A folded HdyLeaflet, just like GtkStack, shows one of its children at any given moment, even during child transitions. The second visible child during transitions is just a screenshot. But which child is “real” and which is a screenshot? Turns out the real child is the destination one, meaning the widget switches its visible child when the animation starts. It isn’t a problem if the animation is quick and time-based, but becomes very noticeable with a gesture. Additionally, it means that starting and cancelling a gesture switches the visible child two time.

One solution would be only switching the visible child at the end of the animation (or not at all if it was canceled). The problem is that it’s a major behavior change: applications that listen to visible-child to know when to update the widgets, or sync the property between two leaflets will break.

Another solution would be to draw both children during transitions, but it still means that visible-child changes two times if the gesture was canceled. The problem here is similar: applications wouldn’t expect the other child to still be drawn, but at least it’s just a visual breakage. And it still means that starting and canceling the gesture would mean two visible-child changes.

The second solution may sound better, and yet the current WIP code uses the first one.

2. Visuals

Leaflet had many issues in this area, such as over transition not making sense spatially and bottom widget being visible through the top widget. Additionally, Adrien liked the drop shadow and dimming in WebKit and the demo and wanted to have it in leaflet as well. :)

The first issue was solved by splitting the transition into over and under and clipping the bottom child. Similarly, I implemented shadow and dimming, though it’s pending on those transition types for mode transitions being merged first, so that the shadow can also be added to those, so that it’s consistent.

I’m also not happy with how the dimming and shadow are implemented, neither here nor in WebKit: it’s custom drawing with hardcoded values. Ideally, this needs to be controlled from CSS somehow. GTK itself uses gadgets for things like this (for example, the overshoot effect in GtkScrolledWindow), but that API is private. Having dimming and drop shadow widgets is an overkill, at least until GTK 4 arrives and makes GtkWidget instantiable. Maybe foreign drawing could work…

3. Syncing animation

Often, GTK applications have two leaflets: one in the window’s content area and one in titlebar. Their visible child is always changed at the same time, so it looks like they are one tall leaflet spanning both titlebar and content. This still needs to work with the gesture. And while it’s easy to make nice-looking throwaway demos that do this, syncing actual HdyLeaflets has to be a proper API.

Initially I suggested what I thought was a nice solution with having swipe tracker as a public object and connecting multiple widgets to it. Benjamin Otte and other people immediately pointed out many problems with it, so I researched how other platforms do it. The answer is simple: most platforms don’t. :)

Android has a rather silly way to sync multiple widgets together, but it’s rarely needed, as app bars are just widgets, so they can be packed into a ViewPager without a need to sync two pagers together.

Another constraint is that the solution must not expose animation progress as a write-able property, so it must not be possible to set this value to something arbitrary and get the transition stuck.

4. Interaction with GtkScrolledWindow

GTK event propagation works in two phases: capture and bubble. Widgets can connect to event signal and receive events on bubble phase. Then they return a value to either stop the event or propagate it further. More recently, GTK added various event controllers that allow choosing the phase where they run. With GTK_PHASE_CAPTURE it’s possible to handle events on the capture phase… But their signals don’t support fine-grained stopping/propagation, i.e. don’t have return values (they do in GTK4 though).
All in all, it means that there’s no way to get an event on capture phase and stop it atbitrarily…

Except there is, it’s private and it’s used by GtkScrolledWindow. This widget captures scroll events and stops some of them. For example, if the scrolled window has a vertical scrollbar, but not horizontal, it stops vertical scrolling events and propagates horizontal scrolling. This is harmless, but it also always stops events with is_stop set to TRUE, meaning a leaflet containing a GtkScrolledWindow will get stuck at the end of the gesture. So every single way of receiving events fails in a different and exciting way.

This last issue made me hate life and put the project on a long hiatus.

More demos

A while later while doing another demo (more on that in the next post) I discovered the horrible workaround: the private function for capturing events in GTK has a very simple implementation, so it’s easy to set this handler manually. And of course, with this workaround it just works. This solves the issue #4.

For the issue #3 I made a crude solution similar to already existing HdyHeaderGroup: HdySwipeable and HdySwipeGroup. It’s an RFC at this point, so criticism is welcome.

That allowed me to make a fully working (though still buggy) prototype of swipeable leaflet:

(Yes, that’s a bug there on 0:21)

Another visible problem in the video is that HdyHeaderGroup showing and hiding buttons doesn’t really work with the gesture. One possible solution here would be to show all buttons on all headerbars when folded, but that would once again involve an API break.

The (still very messy) code is here. Even though it’s not ready yet, Shortwave app already makes use of it:

Swipeable leaflet in Shortwave

This also uncovered a crash when a leaflet is created in unfolded state. Oops.

Thanks Felix Haecker for testing, and once again Tobias Bernard for feedback and suggestions while iterating on it.

September 14, 2019

It's time to talk about post-RMS Free Software

Richard Stallman has once again managed to demonstrate incredible insensitivity[1]. There's an argument that in a pure technical universe this is irrelevant and we should instead only consider what he does in free software[2], but free software isn't a purely technical topic - the GNU Manifesto is nakedly political, and while free software may result in better technical outcomes it is fundamentally focused on individual freedom and will compromise on technical excellence if otherwise the result would be any compromise on those freedoms. And in a political movement, there is no way that we can ignore the behaviour and beliefs of that movement's leader. Stallman is driving away our natural allies. It's inappropriate for him to continue as the figurehead for free software.

But I'm not calling for Stallman to be replaced. If the history of social movements has taught us anything, it's that tying a movement to a single individual is a recipe for disaster. The FSF needs a president, but there's no need for that person to be a leader - instead, we need to foster an environment where any member of the community can feel empowered to speak up about the importance of free software. A decentralised movement about returning freedoms to individuals can't also be about elevating a single individual to near-magical status. Heroes will always end up letting us down. We fix that by removing the need for heroes in the first place, not attempting to find increasingly perfect heroes.

Stallman was never going to save us. We need to take responsibility for saving ourselves. Let's talk about how we do that.

[1] There will doubtless be people who will leap to his defense with the assertion that he's neurodivergent and all of these cases are consequences of that.

(A) I am unaware of a formal diagnosis of that, and I am unqualified to make one myself. I suspect that basically everyone making that argument is similarly unqualified.
(B) I've spent a lot of time working with him to help him understand why various positions he holds are harmful. I've reached the conclusion that it's not that he's unable to understand, he's just unwilling to change his mind.

[2] This argument is, obviously, bullshit

comment count unavailable comments

September 13, 2019

GNOME Firmware 3.34.0 Release

This morning I tagged the newest fwupd release, 1.3.1. There are a lot of new things in this release and a whole lot of polishing, so I encourage you to read the release notes if this kind of thing interests you.

Anyway, to the point of this post. With the new fwupd 1.3.1 you can now build just the libfwupd library, which makes it easy to build GNOME Firmware (old name: gnome-firmware-updater) in Flathub. I tagged the first official release 3.34.0 to celebrate the recent GNOME release, and to indicate that it’s ready for use by end users. I guess it’s important to note this is just a random app hacked together by 3 engineers and not something lovelingly designed by the official design team. All UX mistakes are my own :)

GNOME Firmware is designed to be a not-installed-by-default power-user tool to investigate, upgrade, downgrade and re-install firmware.
GNOME Software will continue to be used for updates as before. Vendor helpdesks can ask users to install GNOME Firmware rather than getting them to look at command line output.

We need to polish up GNOME Firmware going forwards, and add the last few features we need. If this interests you, please send email and I’ll explain what needs doing. We also need translations, although that can perhaps wait until GNOME Firmware moves to GNOME proper, rather than just being a repo in my personal GitLab. If anyone does want to translate it before then, please open merge requests, and be sure to file issues if any of the strings are difficult to translate or ambigious. Please also file issues (or even better merge requests!) if it doesn’t build or work for you.

If you just want to try out a new application, it takes 10 seconds to install it from Flathub.

GNOME and gestures, Part 1: WebKitGTK

This is part 1 of a mini-series. Part 2.

Re-publishing, the original post is too old to show up on Planet GNOME at this point. It was published on August, 8th initially.

Swipe gesture in Epiphany

I’m a big fan of responsive touchpad gestures. For the last half a year (mostly January, February and during the summer) I’ve been working on improving gestures in many areas throughout GNOME. In this series I will do a (belated) overview.

Back/Forward Swipe

Late in the 3.32.x cycle, I saw a commit by Jan-Michael Brummer adding a back/forward swipe to Epiphany. It was really nice to finally have gestures, but it didn’t have any visual feedback. Less importantly, the direction was reversed, as if when scrolling with Natural Scrolling being off. I wanted to give a shot at improving it.

A proper gesture would have to “stick to finger”, showing screenshot of the previous or next page during the gesture, more or less what Safari does on macOS. Specifically, Epiphany would have to take screenshot of every page that is added into back/forward history, show it while the gesture is performed, then continue showing it until the next page loads enough to replace it. Unfortunately, this isn’t really possible to achieve in Epiphany itself: while WebKit does provide API to take snapshots, there’s no way to know when the previous/next page has loaded “enough”.

So I started looking into WebKit instead, where I found out that Safari’s gesture is actually implemented right there! Most parts are present, but the code was not cross-platform. So I started slowly adapting it for GTK. For the most part, the reusable code was a large part of the back end: page snapshot store and snapshot removal logic. That code is now shared between the platforms. The other parts, like actual event processing and drawing, had to be written from scratch.

One interesting detail about the gesture is that it doesn’t actually use gesture events! Libinput defines swipe gestures as synchronous movement of three or more fingers in the same direction. Mac gesture API is even more strict: it’s three fingers only, with four-finger swipes being reserved for the OS. But the gesture uses two fingers, how is this possible? Turns out it actually uses scroll events instead. (That’s also why it works with Magic Mouse in macOS, even though the code does not special-case anything for it)

When using scroll events, one has to be very careful. Touchpads generate scroll events continuously, in GTK it means that these gestures have GDK_SCROLL_SMOOTH scroll direction. At the very end of the scrolling, there will be a special event with is_stop field set to TRUE, which is used as a signal to start kinetic scrolling or, in our case, to end a swipe.

But there are other input devices, for example, mice. Most mice have “clicky” wheels that generate scroll events with direction instead of deltas. These events are impossible to use for swipes, so there’s no point in even trying to handle them. But there are also mice with freely scrolling wheels which generate the same events as touchpad, except there’s no event with is_stop == TRUE at the end. This means that they can be used to start a swipe, but it will get stuck as soon as the wheel stops. So, these mice have to be skipped too. Then there are touch mice where scrolling probably works same as on touchpad. I suspect swiping can work very well with them, same as it does with Magic Mouse on macOS, but there’s no way to distinguish these kinds of mice, at least as far as I know, so I had to disable it for any mice.

Another problem is that in order to not interfere with actual scrolling, the gesture controller must check whether it is possible to scroll the page first. Maybe there’s still space to scroll, maybe the page intercepts the scroll events. Then there has to be a threshold so that it’s hard to accidentally trigger the gesture. Thankfully, this part is shared with the Mac gesture. :)

A side effect of using scroll events is that this gesture still works with X11 and/or older semi-mt touchpads for which Libinput normally does not support any gestures.

So, now the gesture sticks to fingers. But there’s still an important bit missing: a snap-back animation. In order for a gesture to feel natural, it should snap back smoothly as soon as you lift your fingers, respecting the momentum. This was a lot easier to do than I expected, and after a few iterations applying Tobias Bernard’s suggestions I had an animation that I’m very satisfied with. How it works:

  • The animation uses easeOutCubic interpolation
  • Duration is naturally calculated as remaining distance divided by velocity, or if the velocity is 0, by a constant value instead
  • After that, duration is multiplied by 3, matching easeOutCubic derivative at t=0. This ensures that initial velocity is same as it was before lifting the fingers
  • Finally, the duration is clamped into [100ms, 400ms] range. This ensures that it’s never too slow or too fast, while still allowing it to respect momentum when possible
  • If the page was swiped less than halfway through the window, there’s a small velocity threshold. If fingers are lifted when not moving, the gesture will be canceled and the page will smoothly slide back. On the other hand, if the page was swiped more than half way through, just lifting the fingers would finish the gesture, and one has to specifically flick back to cancel it
  • If one starts swiping again while the animation is going, it will actually be stopped. This allows to continuously grab and release the page

Interestingly, Mac has a helper function that takes care of all this, and WebKit makes use of it.

Finally, the gesture should look nice. On Mac it uses CoreAnimation for drawing; WebKitGTK has to use Cairo. Since I didn’t have any mockups to work with, I reused Apple’s visuals, consisting of a dimming layer and a long subtle gradient for drop shadow, intending to replace them with something else later. But everybody whom I showed it liked it, so I left it as is.

The end result is that since version 2.24.0, WebKitGTK optionally supports 2-finger swipe gestures on touchpad.

Unfortunately, I was a little too late to enable it in Epiphany 3.32.0, but it was merged into 3.32.1 nevertheless. In 3.34.x, Yelp and Devhelp will also support it. Additionally, it’s enabled in Eolie and Odysseus browsers.

A bit later I also added touchscreen support. That was easy, because WebKit literally generates scroll events for touch scrolling, so it was simply a matter of feeding those events into the gesture controller. Additionally, I had to implement canceling, as all touchscreen gestures have to support it. Since scrolling on touchscreen is 1-finger swipe, the gesture is performed the same way.

This will be available in upcoming WebKitGTK 2.26.x, corresponding to GNOME 3.34.

This can be very disruptive feature in many cases, such as authentication widgets, so applications wanting to use it have to opt in by changing the value of this property.

Pinch Zoom

A smaller change was getting pinch zoom gesture to work on touchpads. Since this gesture was already available on touchscreens, it involved simply feeding touchpad gesture events into the gesture tracker, but the performance is severely lacking on heavy pages. Speeding it up is unfortunately still above my skill level. :)

Pinch zoom is enabled unconditionally, so it already works everywhere where WebKitGTK is used, including but not limited to Geary and documentation view in GNOME Builder.

I want to say thanks to the following people:

  • Michael Catanzaro and Carlos Garcia Campos for code review and helping me with understanding WebKit codebase
  • Tobias Bernard for testing and numerous design suggestions
  • Jonas Dreßler for testing and feedback, especially on a touchscreen

Part 2 here.

September 12, 2019

Unit-testing static functions in C

An annoying thing about C code is that there are plenty of functions that cannot be unit-tested by some external framework - specifically anything declared as static. Any larger code-base will end up with hundreds of those functions, many of which are short and reasonably self-contained but complex enough to not trust them by looks only. But since they're static I can't access them from the outside (and "outside" is defined as "not in the same file" here).

The approach I've chosen in the past is to move the more hairy ones into separate files or at least declare them normally. That works but is annoying for some cases, especially those that really only get called once. In case you're wondering whether you have at least one such function in your source tree: yes, the bit that parses your commandline arguments is almost certainly complicated and not tested.

Anyway, this week I've finally found the right combination of hacks to make testing static functions easy, and it's:

  • #include the source file in your test code.
  • Mock any helper functions you'd need to trick the called functions
  • Instruct the linker to ignore unresolved symbols
And boom, you can write test cases to only test a single file within your source tree. And without any modifications to the source code itself.

A more detailed writeup is available in this github repo.

For the impatient, the meson snippet for a fictional source file example.c would look like this:

'example.c', 'test-example.c',
dependencies: [dep_ext_library],
link_args: ['-Wl,--unresolved-symbols=ignore-all',
install: false),

There is no restriction on which test suite you can use. I've started adding a few of test cases based on this approach to libinput and so far it's working well. If you have a better approach or improvements, I'm all ears.

GUADEC 2019 wrap-up

This year is the third edition of the GUADEC. Things were slightly different now: I was not a GSoC student anymore and I had my first jet lag. Three flights, some trains (including a type of train which rails were suspended in the air) were enough to go to Thessaloniki lands. When I arrived to Greece, I was a bit scared of the language since the alphabet would be almost impossible to type in my smartphone. However, I could easily reach the accomodation point.

My purpose for this GUADEC was different than the past ones. In the past I went basically to talk about my Google Summer of Code projects, but this time I wanted to show to the attendees the project I was working on as part of my dissertation project. I wanted to re-write almost everything of what I did and in the best case my plan was to find a contributor to my project. I am very happy to say that I found one contributor to this project. The project I talk about consisted on adding face overlay effects to Cheese developing a GStreamer plugins which elements should be better than gstfaceoverlay and gstfacedetect. The code of the project I made for my dissertation project can be found on this link and the one that is being written from scratch can be found on this repository. The slides are available on Google Docs and the full details (actually the thesis document) is written (in Spanish) in this document.

My lightning talk about face effects in Cheese.

Although this GUADEC has not been very productive to me in the sense that I was pretending to make more progress on this project, I feel very happy to have shared my knowledge with a polish guy I met the first day I arrived to Thessaloniki. His name is Mieszko Mazurek and he has never been a GSoC student or contributed to any project. However he is very talented, and has a company that develops drivers and software to manage embeded systems using GNOME-based technologies. I taught him about GStreamer, how to create an application, and he learned on his own to make a GStreamer plug-in. That was amazing! He is from Poznan (Poland) and coincidentally I was going there to have some vacations there. So we agreed to meet each other for further discuss about my project.

The conference days have been very informative as always. I got very hooked up for the Engagement team announcement and found out very interesting some intern lighning talks specially the ones about Usability given by Clarissa, who would later become a nice friend, and the one about the thumbnail generator for Polari. A talk that I liked the most was one about controlling GNOME Shell windows with a VR remote controller. That was a actually a project from Lubosz who works for Collabora and who was doing a Google Summer of Code in parallel to my first GSoC. Was nice to see him again but it was also nice to test his project. He is a really skilled guy. Finally, among other talks other that I found very intersting was the one about GTK4 and its new ways to define layouts.

During the event I met some of the Endless people I’ve been working with. I met also some ex-endlessers who I worked with, Cosimo and Meg. I had some time with Manuel Quiñones, who works with me on Hack, which develops software in top of Endless OS which is intended to teach kids to learning to code. We were also discussing about our workflows, commenting about some possible improvements on the software we develop and, because I had with me the Hack Computer, we showed Cosimo our progress in such software. It was really a pleasure to talk with each of these people in person. Also, I cannot skip to say that it was a surprise to hear about the donation of Endless to the GNOME Foundation for the “Coding Education Challenge”.

guadec2019-endless-folks1.jpg guadec2019-endless-folks-manuel-quinones.jpg
Endless people With Manuel Quiñones

I also attended to the GStreamer-related BOFs/workshops. It was basically a workshop about developing a simple webcam application in Rust with GStreamer. The workshop was lead by Sebastian Droge. Unfortunately, I couldn’t be there during the whole session, but I stayed there most of its duration. I will set the personal goal of learning Rust by February of the next year. During the event, I also had the opportunity to talk with Sebastian Droge and Tim, GStreamer maintainers, and told them to review some very old patches I have. I am not in a hurry, but I hope that happens soon. Now I remember, that I also talked with another GStreamer developer about the possibility of writing a GStreamer element that inherits from GstOpenCVVideoFilter in Python. There is an issue regarding this, since cv::Mat types are not introspectable. So even when I tried to write my own filter similar to GstOpenCVVideoFilter in Python from scratch, I faced that I couldn’t access the raw data of the GstVideoInfo of each plane. I wrote a patch long time ago that I did not published but faced with the problem that I could not wrap that raw data info about the frames in a GLib.Array (from Python) without creating a copy.

The conference was an enjoyable event. Definitevely this event is more than its talks and about meeting people, discussing ideas for future projects and having some fun there. There were scheduled and non-scheduled social events. I also had some fun going to spontaneous dinners, having some drinks and a small boat trip and the visit of the various museums in Thessaloniki. Finally, I want to thank to the foundation for sponsoring me. To be honest, I was not expecting to go this year to the conference, but there I was.


After GUADEC I had some vacations in Greece for about one week more and then I was going to Poznan, Poland. As I mentioned, the first day of the event I met Mieszko Mazurek who actually lives in that city. He was showing me the city and his office in which he works were he develops low-level and high-level software to control batteries. He uses GNOME-based technology for this high-level software. I also continued to show him and explaining him about the Cheese Face Effects project. Finally, that day I could get the code I wrote during the event with the help of him to work as expected. Now I am on Krakow, and he is going to do an inter-city trip to continue talking about the mentioned project.

Mieszko and I trying the gst-plugins-cv repository

September 11, 2019

Gdk-pixbuf modules - call for help

I've been doing a little refactoring of gdk-pixbuf's crufty code, to see if the gripes from my braindump can be solved. For things where it is not obvious how to proceed, I've started taking more detailed notes in a gdk-pixbuf survey.

Today I was looking at which gdk-pixbuf modules are implemented by third parties, that is, which external projects provide their own image codecs pluggable into gdk-pixbuf.

And there are not that many!

The only four that I found are libheif, libopenraw, libwmf, librsvg (this last one, of course).

Update 2019/Sep/12 - Added apng, exif-raw, psd, pvr, vtf, webp, xcf.

All of those use the gdk-pixbuf module API in a remarkably similar fashion. Did they cut&paste each other's code? Did they do the simplest thing that didn't crash in gdk-pixbuf's checks for buggy loaders, which happens to be exactly what they do? Who knows! Either way, this makes future API changes in the modules a lot easier, since they all do the same right now.

I'm trying to decide between these:

  • Keep modules as they are; find a way to sandbox them from gdk-pixbuf itself. This is hard because the API is "chatty"; modules and calling code go back and forth peeking at each other's structures.

  • Decide that third-party modules are only useful for thumbnailers; modify them to be thumbnailers instead of generic gdk-pixbuf modules. This would mean that those formats would stop working automatically in gdk-pixbuf based viewers like EOG.

  • Have "blessed" codecs inside gdk-pixbuf which are not modules so their no longer have API/ABI stability constraints. Keep third-party modules separate. Sandbox the internal ones with a non-chatty API.

  • If all third-party modules work indeed as I found, the module API can be simplified quite a lot since no third-party modules implement animations or saving. If so, simplify the module API and the gdk-pixbuf internals rather drastically.

Do you know any other image formats which provide gdk-pixbuf modules? Mail me, please!

Please welcome Acer to the LVFS

Acer has now officialy joined the LVFS, promoting the Aspire A315 firmware to stable.

Acer has been testing the LVFS for some time and now all the legal and technical checks have been completed. Other models will follow soon!

September 10, 2019

Talking at GUADEC about defending against USB-borne attacks

Ouf, long time no blog. Sorry about that. Life is.. busy these days. One of my occupations has been to defend against USB-borne attacks, as mentioned before. Probably the most known is the BadUSB attack which masquerades as a mass storage device but also is a keyboard. Then, the device would inject keystrokes which hack your machine. This class of attacks is difficult to defend against, because the operating system can hardly determine whether the user did indeed want to plug a device with those capabilities in. There is another class of attacks, though, which is a bit easier to defend against, I think. That other class is based on buggy drivers which the malicious USB device pulls in. So once you attach your device, the host’s kernel will look for the appropriate driver and let it speak with the device. That’s very convenient because it makes devices just work. However, certain drivers might not be of the same quality than others and there have indeed been cases which allow a malicious USB device to interact with a bit-rotten driver which in turn led to fatal consequences.

I have been thinking a lot about how to defend against either class of attacks. You can easily come up with various solutions based on pop-ups interrupting the user and authoring the device before it will be ready for use. Or with a policy-based solution that requires you to generate a firewall-like description of what the machine is allowed to do. Or a mixture of those two attempts. And that’s what has been done, already. Arguably, none of these solutions has been successful, as I am not aware of any built-in protection scheme for any major operating system. The reason, I believe, is that users expect things to just work and once you make it not work, users get grumpy. So the challenge is to unfold protection capabilities without changing the users’ experience.

The short version of our approach is that we are trying to be smart about the user’s intent. That is, if the screen is locked, then we block the device. If a new keyboard is present and it tries to perform “dangerous” actions, we block them. Of course, you may very well expect that device to work when the screen is locked or the new keyboard to perform actions deems dangerous. This is why is make sure you have a way to opt out of the mechanism and continue to enjoy your GNOME experience. Almost all credits go to Ludovico for coming up with a set of patches as well as following up to make sure we can get it merged. Our slides are here and the video of our presentation is here:

But I wanted to write more about GUADEC… This year’s GUADEC was in Thessaloniki, Greece, and I had the pleasure to be talking about the above mentioned protection. It was the end of the summer so the city was nicely warm and comfy. The coffee, juices, pastries, and other food and drinks in small shops on the streets were amazingly fresh and yummie. Arriving in Thessaloniki was okay. I’ve had better airport transfers in my life, but since there were only two buses it was hard to get lost. I needed to pay attention to the GPS, though, to find my right stop. It’s been long since I’ve slept in a bunk bed, but because we’re all GNOME people we had a good time.

The conference had a few interesting talks which can be followed on the recordings page. I enjoyed watching Daiki presenting about plans and ideas for managing credentials in a sandboxed world, Benzo talking about user sessions with systemd, and the (not recorded) one by Giannis on the impact of the GDPR. Of course, the 45 minutes or so we had for discussing all the facets of the GDPR were too short and I think that I would have focussed on other aspects such as choosing an appropriate legitimate ground, transfer to non-member states, or dealing with requests from data subjects. But it’s been a good introduction and I am happy to see non-technical topics at the conference.

Meeting friends, old and new, is really good and I have had a fantastically efficient time talking to people. It’s so much better to meet in-person and talk directly rather than via email or bug tracker.

Sponsored by the GNOME Foundation

Towards a UX Strategy for GNOME (Part 2)

This post is a part of a short series, in which I’m setting out what I think could be the beginnings of a UX strategy for GNOME. In this, the second post, I’m going to describe a potential GNOME UX strategy in high-level terms. These goals are a response to the research and analysis that was described in the previous post and, it is hoped, point the way forward for how GNOME can achieve new success in the desktop market.

Strategic goals

For me, the main goals of a GNOME UX strategy could be:

1. Deliver quality

If GNOME is going to succeed in today’s desktop market, UX quality has to be job #1.

UX quality includes what the software looks like and how it is designed, but it also refers to how the software functions. Performance and bugs (or the lack of them) are both aspects of UX!

More than anything else, people are looking for a desktop that Just Works: they want a solution that allows them to get their work done without getting in their way. This means having a desktop that is reliable, stable, which does what people want, and which is easy to use.

People value solutions that Just Work. They’re also prepared to abandon them when they don’t Just Work.

To its credit, the GNOME project has historically recognised the importance of Just Works, and it has delivered huge improvements in this area. However, there is still a lot of work to be done.

My sense is that driving up quality is one of the key strategic challenges that the GNOME project needs to face up to; I’ll be returning to this topic!

2. Factor in the cloud

In my previous post, I worte about how the cloud has reconfigured the landscape in which GNOME operates. Accordingly, it’s important for our UX strategy to account for the cloud. There are various ways we can do this:

  • Focus on those bits of the desktop that are used by all users, even if they mainly use a web browser. This includes all the parts of the core system, as well as the most essential desktop apps.
  • Enable and encourage native cloud applications (including Electron and Progressive Web Apps)
  • Add value with high-quality native apps.
  • Integrate with existing cloud services, when it is safe to do so.

The last point might seem counter-intuitive, but it makes sense: in a world where the web is dominant, a fantastic set of native apps can be a powerful differentiator.

At the same time, GNOME needs to be careful when it comes to directly competing with sophisticated web apps and services, and it needs to recognise that, nowadays, many apps aren’t worth doing if they don’t have a cloud/cross-device component.

3. Grow the app ecosystem

The primary purpose of a platform like GNOME is to run apps, so it stands to reason that the number and quality of the apps that are available for the platform is of critical importance.

Recently, Flatpak has allowed the GNOME project to make great progress around application distribution, and this is already positively impacting app availability for GNOME. However, there is a lot of work still to be done, particularly around GNOME’s application development platform. This includes work for both designers and developers.

4. Support modern hardware

One of the things that my research revealed is that, for most users, their choice of desktop OS is thoroughly entwined with hardware purchasing choices, with hardware and software typically being seen as part of the same package. Attracting users to GNOME therefore requires that GNOME be available for, work well with, and be associated with high-quality hardware.

A lot of hardware enablement work is done by distros, but a lot also happens in GNOME, including things like high-definition display support, touchscreen support, screen casting, and more. This is important work!

Do less, prioritise

Any UX strategy should address the question of prioritisation: it ought to be able to determine how resources can be directed in order to have maximum impact. This is particularly important for the GNOME project, because its resources are limited: the core community is fairly small, and there’s a lot of code to maintain.

The idea of prioritisation has therefore both influenced the goals I’ve set out above, as well as how I’ve been trying to put them into practice.

When thinking about prioritisation in the context of GNOME UX, there are various principles that we can follow, including:

  • User exposure, both in terms of the proportion of people that use a feature, and also the frequency with which they use it. Improvements to features that everyone uses all the time have a bigger impact than improvements to features that are only used occasionally by a subset of the user base.
  • User needs and desires: features that are viewed as being highly attractive by a lot of people are more impactful than those which are only interesting to a small subset.
  • Common underpinnings: we can prioritise by focusing on common subsystems and technical components. The key example here is something like GTK, where improvements can surface themselves in all the apps that use the toolkit.

When we decide which design and development initiatives we want to focus on (either by working on them ourselves, or advertising them to potential contributors), principles like these, along with the high-level goals that I’ve described above, can be very helpful.

I also believe that, in some cases, the GNOME project needs to have some hard conversations, and think about giving up some of its existing software. If quality is job #1, one obvious answer is to reduce the amount of software we care about, in order to increase the overall quality of everything else. This is particularly relevant for those parts of our software that don’t have great quality today.

Of course, these kinds of conversations need to be handled delicately. Resources aren’t fungible in an upstream project like GNOME, and contributors can and should be free to work on what they want.

What’s next

In my previous post, I described the research and analysis that serves as inputs to the strategy I’m setting out. In this post I’ve translated that background into a high-level plan: four strategic goals, and an overarching principle of prioritisation.

In the next post, I’m going to introduce a raft of design work which I think fits into the strategy that I’ve started to lay out. GNOME is lucky to have a great design team at the moment, which has been pumping out high-quality design work over the past year, so this is a great opportunity to showcase what we’ve been doing, but what I want to do is also show how it fits into context.

September 09, 2019

Gthree – ready to play

Today I made a new release of Gthree, version 0.2.0.

Newly added in this release is support for Raycaster, which is important if you’re making interactive 3D applications. For example, it’s used if you want clicks on the window to pick a 3D object from the scene. See the interactive demo for an example of this.

Also new is support for shadow maps. This allows objects between a light source and a target to cast shadows on the target. Here is an example from the demos:

I’ve been looking over the list of feature that we support, and in this release I think all the major things you might want to do in a 3D app is supported to at least a basic level.

So, if you ever wanted to play around with 3D graphics, now would be a great time to do so. Maybe just build the code and study/tweak the code in the examples subdirectory. That will give you a decent introduction to what is possible.

If you just want to play I added a couple of new features to gnome-hexgl based on the new release. Check out how the tracks casts shadows on the buildings!

September 08, 2019

WebKit Vulnerabilities Facilitate Human Rights Abuses

Chinese state actors have recently abused vulnerabilities in the JavaScriptCore component of WebKit to hack the personal computing devices of Uighur Muslims in the Xinjiang region of China. Mass digital surveillance is a key component of China’s ongoing brutal human rights crackdown in the region.

This has resulted in a public relations drama that is largely a distraction to the issue at hand. Whatever big-company PR departments have to say on the matter, I have no doubt that the developers working on WebKit recognize the severity of this incident and are grateful to Project Zero, which reported these vulnerabilities and has previously provided numerous other high-quality private vulnerability reports. (Many other organizations deserve credit for similar reports, especially Trend Micro’s Zero Day Initiative.)

WebKit as a project will need to reassess certain software development practices that may have facilitated the abuse of these vulnerabilities. The practice of committing security fixes to open source long in advance of corresponding Safari releases may need to be reconsidered.

Sadly, Uighurs should assume their personal computing devices have been compromised by state-sponsored attackers, and that their private communications are not private. Even if not compromised in this particular incident, similar successful attacks are overwhelmingly likely in the future.

A reason to go to GUADEC

There is only one reason to attend GUADEC: To learn about GNOME.

You may not know much about the GNOME project or the GNOME community. From my experience in the GNOME community for more than eight years, I can list some reasons to get to know more about it:

1. GNOME is a worldwide project and community

It is usual that people work in a company that has functional areas such as marketing, technology, human resources, accounting, and finance. It is also usual that people work with other local people face-to-face in a fixed schedule on weekdays. GNOME has the same functional areas managed by people from many parts of the world. Each person has a different way of working, different time zone, and different culture – but they all have the same mission: to improve the GNOME software and the GNOME community. You are more than welcomed to contribute to GNOME as a developer, designer, translator or any role you prefer!

Pictured on the left, we see Linux enthusiasts: Nuritzi and Sri from the USA, Sigu and StellaMaris from Kenya, and Julita from Peru 😉  On the right side, all the GNOMEies gathered at GUADEC 2019. You can get GNOME as a final user or get the code in gitlab as a developer.

2. GNOME creates breakthrough technologies

I got to know about Red Hat because I attended GUADEC 2012 and I saw Marc Andre and Zeeshan proudly wearing their red hats. Now in 2019, I am aware of the partnership of GNOME with Purism and was able to see the elegant work of Tobias Bernard at GUADEC and how GNOME can now be used for Linux smartphones. I want to also highlight the work of Peruvian Fabian Orccon, who is doing volunteer technical work for Cheese. This application captures static faces to apply effects, and now with Fabian’s help, it detects faces in movement and applies effects used in technologies like Snapchat and on Facebook. Finally,  at this GUADEC, Lubosz Sarnecki from Collabora moved GNOME to another reality. He used Virtual Reality(VR) to simulate a virtual desktop environment.
These three innovative efforts I just mentioned came from three of GNOME’s former Google Summer of Code (GSoC) students. You can learn more about Google Summer of Code opportunities for GNOME here.

3. GNOME supports and empowers all of its members

GNOME has defined guidelines for members who want to participate in GNOME. Following these guidelines, I have designed some initiatives that I have applied within my local Linux community in Peru: Peru Rumbo GSoC 2018, GNOME PERU Challenge 2017 – I,  and Lets CONTRIBUTE Peru. These were some of the volunteer programs I created in order to promote the use of and contribution to GNOME in my country. GNOME believed in my efforts and supported these ideas by providing the material resources I needed as well as some online support from other GNOME members. I feel that I only succeed once because Cesar Fabian Orccon was the only Peruvian that also became a GNOME Foundation member and not my other students. Even if I made mistakes along the way, GNOME appreciates my effort, time, and money I invested during more than 8 years.

Regarding my own story, I started in GNOME as a technical writer, and over the years I became a representative of GNOME and a speaker at Linux events. For instance, I gave a talk in Portland at the API 2017 conference where I did a workshop using GTK and C. That is only part of my experience with GNOME, and that is also the case for other members such as Carlos Garnacho, Maria, Nuritzi, and Sebastian, who works in Ubuntu. At this year’s GUADEC, I met Sigu and StellaMaris who have promoted Free Software in Africa for around four years!  Pictured on the bottom left: GNOME members are taking selfies as a part of a workshop at this year’s GUADEC.

4. GNOME allows you to leave a legacy

GNOME has more than 20 years of existence and it has also been translated into more than 20 languages thanks to the contribution of volunteers around the world. In order to have a successful Linux project, you must attract a new generation of contributors and pass along the know-how to them. In this matter, GNOME has joined the GSoC program and Outreachy to reach newcomers.
I have met the GNOME students in Thessaloniki and I am glad that Carlos Soriano keeps this effort since he was a previous GSoC student and he is sharing his expertise with newbies.

5. GNOME helps build friendship around the world

First, you meet someone and then it can be hard to make the change from acquaintances to friends. I am so glad to share that I have been invited from GNOME members to be part of their lives and they kindly hosted me in their houses when I traveled abroad. That is the case for Andre Klapper in 2012 when we stayed at his apartment to attend the Documentation Hackfest in Brno. In 2014, I visited UK at Kat’s place, and in 2016 in order to attend to the ISC conference (a non GNOME conference), I stayed at Tobias Mueller’s house and I met his lovely wife.

It is priceless that somebody trusts you enough to give you the key of their house. It was very exciting to see these people again at GUADEC 2019! Petr Kovar’s is just in the collection of photos because I had no other choice 🙂 Felipe Borges taught me GTK on Python once in a Hackfest, and keep many other valuable stories in my mind from Javier, Sam, Rosanna, David and Bin Li that were also pictured for this post. Finally, even though I did not visit Nuritzi’s home, I feel that she is my friend not only because she supports my ideas and initiatives, but because a real friend tells you in your face good and bad things in order to be a better person. Nuritzi did that in this GUADEC, and I will try to behave better for the sake of humanity. I will post Zeeshan’s photo when he will take me on his plane! 😀
Additional thanks To Federico Mena, Marina, Karen, Shaun McCance, Phil Bull, Siska and all the GNOMErs that did not attend the GUADEC 2019 but they are definitely in my mind and heart 💜

6. GNOME is constantly working on user-friendly changes

A project exists based on a user’s need. Nowadays, an IT project must be enough to solve the needs of two generations such as millennials and members of Generation Z. These two generations are closely impacted by the presence of technology, then GNOME has been reinvented during the latest years. The first substantial evolution I witnessed was the implementation of  GNOME 3.x. This effort is constantly improved by developers of GNOME, due to the ubiquity and online-oriented information demand. The GNOME technologies that are created must be adequate for the sake of the project and for all its members and users. There is also a board of directors of GNOME that are supervising all the efforts done by the GNOME members.

Pictured are Philip Chimento who is in charge of GJS, the GNOME Javascript engine, and Robert McQueen who is the CEO Endless, ex CTO and co-founder of Collabora and long-term contributor to FOSS projects like GNOME, Flathub, Flatpak and, and currently serving as the President of the GNOME Foundation Board of Directors.

You might see the full schedule of the projects presented at GUADEC 2019 here.

7. GNOME rewards your efforts

Meritocracy is a basic principle that GNOME has demonstrated over the years. As GNOME people contribute to the GNOME project and community, they are prized by being sponsored to attend different Linux conferences around the world. In my case, GNOME recognised my effort by featuring me as a people side of GNOME. It definitely raised my confidence. Moreover, I feel strongly connected with GNOME when I read posts of other GNOME international members such as Philip Chimento and Felipe Borges where they showed empathy towards my work.

In this GUADEC 2019, I met again and shared my table with the GNOME Asia members. I had the honour to travel to Asia to meet the strong GNOME Asia community in 2015. Glad to talk to BinLi, he is one of the most active members for several years and works for Open SUSE in China.The “Bingo” prized the effort that some people did in this GUADEC to meet GNOME in deep. I will never forget that I won twice! That is the first time in my life that  it happened!

8. GNOME is an important part of my life

Over the past 8 years of contributing to GNOME, my life has changed from the routine to a life of trips, and continuous learning because the world of technology also constantly changes. GNOME gave me trust in myself and that is, in my eyes, more valuable than anything else. I have moved to the USA and the UK in the last two years. Starting off has been so difficult since living abroad implies acquiring new mindset and ways to behave in a different culture. However, wherever I go, I try to spread the Linux word, especially the GNOME and Fedora word. You can see that in the two interviews that ORNL did to me in the USA: 1, 2; and here is the video that summarizes my volunteer work as the general organizer of  Linux at Edinburgh, an event where a did a talk about GNOME and Fedora.

Thank you so much again GNOME for second 0.3 in GUADEC 2015, the 1:31 on GUADEC 2012, My GUADEC 2014, My GUADEC 2017, and My version of the Desktop Summit 2011, My own video of my talk at GUADEC 2012 and my lighting talk at GUADEC 2015.

9. GNOME made challenge myself

I have recently completed my masters in Computer Science when I won the OPW 2011 for GNOME. I started in the GNOME documentation team, and then I realized that learning Linux will help me get better career opportunities. Unfortunately, I have never been hired by any partner company of GNOME such as Red Hat, Collabora, CodeThink, Canonical or Purism as most of the current GNOME members are.  However, my entrepreneurship allowed me to achieve my Red Hat Certified Professional and then I was able to work in IBM Peru. This opened me other doors such as being a Linux teacher in universities in Lima, Peru. Later, I was involved in High Performance Computing researcher projects.

I dare to say that GNOME made me find myself as a blogger, photographer, teacher, sysadmin, international speaker, developer, IT event organizer, and nowadays I am acquiring skills as a researcher in the HPC field.Taking GNOME people’s backs represented my challenge at this GUADEC because I usually take pictures of people’s fronts. I am also excited to see ARM as part of the GNOME sponsors.

10. The GNOME heart is left wherever the GUADEC is held

Throughout these eight years, I met GNOME communities around the world. I got fascinated when I saw in person different volunteer workgroups making possible GUADECs. This GUADEC 2019 in Greece has definitely a lovely group behind the scenes.Thank you so much Efstathios Iosifidis, Mariet Vaina, Eirini Basdani and all the team! �

� Special thanks for the proofreading service to Nuritzi Sanchez and KittyKat  ✨

September 07, 2019


This year I did a bit of traveling in Greece before going to GUADEC in Thessaloniki with Tobias, Regina and from Athens Jordan. We started from Kos, a small island close to Turkey. After a couple of days we took a ferry to Athens, where we met up with Jordan, our local tourist guide ;)

Regina, Tobias, and I in front the Parthenon.
Jordan as archaeologist ;))

After visiting Athens and the Acropolis we took upon us the long journey to the oracle of Delphi. Close to Delphi is Mount Parnassus, one of the highest mountains in Greece. Sadly we didn’t manage to climb the peek, but we still had an awesome hike around it.

Mount Parnassus

After the holidays we took the train to Thessaloniki to meet with other Gnomies. Sadly Regina didn’t join us for GUADEC.

So, what have I been up to during GUADEC:

I finally got the icon export feature merged into Icon Preview. I fixed issues with this literally right up until Jakub’s demo, but it was worth it: During his demo the export worked flawlessly. As soon as there’s a new release, you’ll be able to export hicolor and symbolic icons directly from the same template, which improves the icon authoring experience a lot. You can also export a nightly version of the symbolic icon, which is automatically generated with no extra work. We’ve wanted this for a very long time, and it’s great to finally see it come to fruition. Expect Nightly icons in nightly versions of GNOME apps soon!

I also created a new tool (still work in progess) which takes an SVG file and exports a PDF where each page is defined by a rectangle with a specific size and color. Some people (i.e. GNOME designers) like to make their slides in Inkscape (since it’s the only decent free visual editor we have), but since Inkscape doesn’t support multiple pages it’s a real pain to export the slides to PDF. The code isn’t ready to show therefore it isn’t public, yet. I hope to make this into an actual app soon though, to make this workflow feasible for more people.

I also talked to a couple of people about the future of folks (the library powering gnome-contacts) and what possibilities we have to improve the status quo.

Many thanks to everybody involved in organizing GUADEC. It has been a lot of fun, I can’t wait for next year. Special thanks also to the GNOME Foundation for sponsoring my attendance!

How to design a status icon library in 2019

So the year is 2019 and people still use system trays on their desktops. I’m not going to get into if that is good or bad but lets discuss an implementation to sanely use them and what existing ones get wrong. I hope this is somewhat informative to developers using or implementing status icons.

Lets start with some high level goals:

  • Don’t use X11

    I’ll start with this because its simple and everybody knows it by now. If you want to set a tray you can’t use X11 because not everybody uses X11. So you need a different solution and on Linux that is a DBus service that applications talk to.

  • Safely handle and expose if the tray works

    There are always going to situations where the tray will not work such as using a desktop that doesn’t support it or bugs like the service crashing and going away. This should always be reported to the application as soon as possible as this avoids issues like an application having a hide window feature but no tray to show it.

  • Be designed for a sandboxed future

    We are now at a point where desktop software is getting sandboxed so that means certain actions are limited such as reading/writing files on the host, talking to or owning arbitrary DBus names, having a PID that means anything to the host, etc. On top of that applications should expect a permission system where they are denied using a tray.

  • Recommended features

    This is more opinionated but I’d say you need to support:

    • Showing an icon and changing it (with scaling ideally)
    • Reacting to clicks and maybe scrolling
    • Exporting a menu to be shown

Ok I think that covers the basics lets look at the real world solutions:

- GtkStatusIcon (GTK)

  • ❌ Uses X11
  • ✔️ It does expose if the tray is “embedded” or not (almost nobody listens to this).
  • ❌ Sandbox friendly (its X11)
  • ✔️ Features

Nobody should use this API in new code if you want to target non-X11 but this is the classic API everybody has lived with for years and it got the job done. Since it no longer exists in GTK4 due to not being portable a replacement had to come.

- AppIndicator (Canonical)

  • ✔️ Uses DBus (but falls back to X11)
  • ❌ Failure not exposed by default
  • ❓ It is kinda sandbox friendly
  • ✔️ Features

While nobody should be using the DBus service anymore many use the libappindciator library which behind the scenes uses StatusNotifier these days. It has a complete feature-set for the most part though menu handling is overly complex.

There are quite a few problems with this implementation however. It is designed to silently fail by default; It falls back to X11 automatically and unless you override the fallback handling XEmbed failing yourself (maybe literally nobody does) you will not know it did. It does tell if you if the DBus portion is connected but as long as it fallsback you don’t know what is going on.

It isn’t quite sandbox friendly because it does require talking to an insecure service and it allows referencing icons by path. However it doesn’t require bus name ownership which is a positive.

Lastly the library is entirely unmaintained for many years and libdbusmenu is just disgusting, so its not something I’d recommend in new code.

- StatusNotifier (KDE)

  • ✔️ Uses DBus
  • ✔️ You can detect failure if you try
  • ❌ Not sandbox friendly
  • ✔️ Features

This is the de-facto standard at the moment that many people are using now. It has its positives and its negatives.

The biggest problem with this API is that it is clearly not designed with a sandbox in mind. Quoting the spec:

Each application can register an arbitrary number of Status Notifier Items by registering on the session bus the service org.kde.StatusNotifierItem-PID-ID, where PID is the process id of the application and ID is an arbitrary numeric unique identifier between different instances registered by the same application.

So this bad on a few levels. For one it requires name ownership in the KDE namespace which I personally do not understand why. Flatpak blocks all ownership except for your app-id. I’m not even sure a well-known name is required at all.

Secondly it requires putting your PID in the name which is a no-go for any PID namespace on Linux as they will almost always have the same values inside the sandbox.

Lastly it has the same issues AppIndicator exposed such as talking to an insecure service, referencing icons by path, etc. It also reuses the DBusMenu spec for exporting menus which is still completely awful and unmaintained.

I’d say it is the best solution we have but it needs improving.

- StatusIcon (Linux Mint)

  • ✔️ Uses DBus (but falls back to X11)
  • ❌ Failure not exposed
  • ❌ Not sandbox friendly
  • ❌ Features

So last comes Mint with a new interface which repeats the issues of the past.

Failure is not exposed at all so applications have no idea if it works.

It has all of the sandbox problems of StatusNotifier nearly copy paste. It requires name ownership, it uses your PID in said ownership, etc.

In the end it does not expose as many features as the previous solutions as you can only set an icon, label, and tooltip. I understand why to a degree for menus because libdbusmenu is seriously evil but they could have went a more minimal approach and reused GMenu in GLib which perfectly handles exporting a menu over DBus.

This announcement is clearly why I am writing this as I hope they will consider some of the sandboxing cases and better expose if a tray is working in the future. I just do not want to see past mistakes repeated and for adoption to happen before they are solved.

P.S. Don’t use the org.x namespace and don’t do blocking IO.

- What I want to see (or maybe create)

  • Supports features mentioned above
  • Backed by DBus service
    • This must be a robust service, validating the sent icon data in a sandbox
      • All icons must be sent as data or icon-names, no paths allowed
    • Not require well-known name ownership outside of app-id namespace
      • Uniqueness is up to the application already
    • Support more minimal menus than DBusMenu (via GMenu IMO, but anything similar)
    • Be exposed by xdg-desktop-portal which handles permissions
  • Library that exposes if the tray is working or not
    • Also don’t fallback to XEmbed, at least not silently

Goodbye, GUADEC!

As we at the GNOME Foundation celebrate the end of summer, we’re also celebrating another successful GUADEC.

A selfie of five people in front of a standee saying "GUADEC" at the Thessaloniki Airport.
Photo courtesy of Cassidy James Blaede.

This GUADEC was really special for the Foundation, as it was the first year that there was a significant staff presence. In addition to many years of Rosanna Yuen, and lately Neil McGovern, we had four other staff members at the conference. As most of us were hired in the past year, thanks to several very generous donations, this was our first opportunity to come together, meet in person, and plan for the future of the GNOME Foundation.

While Kristi — along with an amazing group of volunteers — was hard at

A photo of ten people -- the GNOME Foundation Board and friends -- sitting around a table outside in thessaloniki. They are smiling.
Photo courtesy of Nuritzi Sanchez.

work pulling together the last minute details of the conference, Neil and Rosanna met with the Board of Directors to the GNOME Foundation to make important plans for the next six and twelve month periods, and to look five and ten years into the future of all the projects that fall under the GNOME umbrella.

Several of us met with the Advisory Board, a collection of organizations with a stake in the future of GNOME projects, who advise us on the needs of their communities, and who help push the project forward through various kinds of support.

A photo of Kristi Progri, smiling and wearing fabulous flower earrings, in front of some trees. She is holding a blue balloon that has the GNOME logo on it.
Photo courtesy of Richard Brown. Licensed CC-BY-NC.

GUADEC kicked off with a warm welcome from Kristi and we embarked on three days of talks, unconference time, and, of course, fun with GNOMEies. We had updates on various parts of GNOME projects, visions of the future for Linux on the desktop, strategic discussions, and calls to focus on accessibility, global access, and environmental concerns. Personal highlights include learning about the open source community in Africa from Sigu and Stellamaris; hearing about the messaging of the Engagement Team from Britt Yasel; the keynotes by Dr. Luis Falcon, from GNU Health, and Deb Nicholson, from the Software Freedom Conservancy; lightning talk from GNOME interns; and the conversations I had during the coffee breaks. A collection of videos from the conference is available for your viewing pleasure!

Another highlight for me was the AGM — the Annual General Meeting. The AGM was open to all attendees of GUADEC. It also provided an opportunity for GNOME Foundation Members to have discussions and vote on two proposals: modifying the bylaws to use gender neutral language; and extending the terms of Board members. Both proposals passed.

A photo of Neil McGovern, Ecexutive Director of the GNOME Foundation in August 2019. He is wearing a suit. Behind him is a sign that says "GUADEC" and "Private Internet Access."
Photo courtesy of Richard Brown. Licensed CC-BY-NC.

We heard from Neil and newly elected president of the Board of Directors, Rob McQueen. There were also updates from various committees on their activities over the past year. GUADEC attendees had the opportunity to speak directly with the Board and Staff in a public fourm. We discussed topics like the sustainability of the GNOME Foundation, future technical directions of the project, and environmental sustainability.

Perhaps the most exciting thing from the AGM was the announcement of a collaboration between Endless and GNOME: a year long competition, to develop new tools, strategies, and methodologies for teaching coding using free and open source software. You can read the press release online, and I’ll be writing a bit more about it in the near future.

Following the three core days of the conference, there were two days of

A photo of two smiling people standing in front of trees. The one on the left is wearing a black shirt, and the one on the right a blue dress. They are both holding a blue balloon with the GNOME logo on it.
Photo courtesy of Richard Brown. Licensed CC-BY-NC.

BoFs. I personally attended the Engagement BoF, the Inclusion & Diversity BoF, and SpinachCon. There were also sessions for newcomers, GTK, documentation and localization, vendor themes, Rust, content apps, GStreamer, and Flatpak — to name a few. During these sessions we hacked, had strategic discussions, made decisions about our work moving forward, and welcomed new members to teams and initiatives.

Perhaps the most important part of GUADEC came at the very end of the conference: the Museum BoF and the Beach BoF. Those brave souls who stayed through the final days split into two groups, one that visited various museums around Thessaloniki and one that went to Eponami beach. Both groups had a great day, exploring, learning, and relaxing in our own ways.

GUADEC was amazing. I learned so much about GNOME, and I find myself more enthusiastic than ever to be working for the success of the project and all its endeavors. Even though I am new to the community, everyone made me feel welcome and valued. I had amazing conversations and hatched exciting plans for the future, which I am looking forward to sharing with you as they develop.

I’d like to personally thank the volunteers, various teams, and especially the local team that made GUADEC 2019 possible! I’d like to give a special shout out to Mariet, Stathis, and Vivia! On behalf of the organization, I would like to thank the sponsors of the event: Private Internet Access, Redhat, Endless, Ubuntu, openSUSE, CodeThink, Igalia, arm, our host the University of Macedonia, ubicast, for providing recording and streaming services, and Centricular, for bringing us drinks and snacks during the coffee breaks.

A photo of six smiling GUADEC volunteers.
Photo courtesy of Richard Brown. Licensed CC-BY-NC.

Whether you were there in person, participated online, or skipped GUADEC entirely, I hope to see you next year!

September 05, 2019


Last week I was in Thessaloniki (Greece) for this year’s GUADEC. This time I took vacations before the conference, visiting Athens and Delphi among other places, before coming to Thessaloniki.

View from the Acropolis in Athens

Conference Days

I made an effort to see more talks this year, because there were so many interesting ones. Kudos to the speakers and organizers for getting such an excellent program together! Among my favorites were Allan’s talk on UX strategy and tactics, Cassidy’s about his research on dark styles, and Deb Nicholson’s closing keynote on building a free software utopia.

On Sunday I gave a talk about adaptive patterns and making GNOME apps that work well across form factors, from phones all the way to desktops. There is a video of my talk, and the slides are here.

Julian, myself, Bastian, Adrien, and Heather waiting for the Foundation AGM to start (and Sigu photobombing)

Monday: GTK

I spent most of Monday in the GTK BoF, where we discussed (among other things) menus, dark styles, upstreaming Libhandy widgets, and a new pattern library for GNOME. Since there were so many app maintainers in the room, we inevitably also talked about random things in various apps, such as the Mouse/Touchpad settings, the Display settings, and Evince.

Pattern Library

One of the things we’ve talked a lot about recently on the GNOME design team is making it easier to implement our UI patterns.

Many of the platform widgets are in GTK directly, which makes them easy to use, but hard to iterate on since we don’t want to break API there. Other things are in third party libraries, such as Libzazzle or Libhandy, but those are not “official”, and app developers have to know about them. Other widgets are just copy-pasted between apps, or completely custom everywhere. This makes it needlessly complex to follow our design guidelines, and has resulted in inconsistency in how different apps implement patterns. One idea to fix this was to have a separate official pattern library, and a new widget factory that showcases these patterns. This library could move significantly faster than GTK, and its release cycle could be better aligned with GNOME.

On a parallel track we’ve also been discussing for some time (both within Purism and GNOME) how best to upstream the widgets in Libhandy. Some of the things in there are fairly generic and should go into GTK (e.g. HdyColumn), but since GTK3 is stable we can’t upstream them directly before GTK4. Other widgets are more GNOME-specific (e.g. HdyPreferencesWindow), and would ideally be able to move at a faster speed, so a separate library would be a better fit.

We discussed this at length over the course of GUADEC, and this seems like the most likely way forward: For GTK4 we’ll have a separate GNOME pattern library outside GTK, which contains “official” widgets implementing patterns from the GNOME HIG. Some of these widgets would come from currently separate libraries such as Libhandy, while others might be moved out of GTK (e.g. GtkShortcutsWindow). The new library would have a clearly defined inclusion/review process for new widgets, and would be kept in sync with the HIG.

For GTK3 it seems like the path of least resistance is to just adopt Libhandy upstream, after removing a few things that are too specific or no longer needed (e.g. HdyDialer and HdyArrows), and instituting the same review process for new widgets as for the GTK4 library.

It’s still early days for all of this, but this is the current consensus as I understood it from various conversations at GUADEC.

Adrien and Bastian in front of the Arch of Galerius

Tuesday: Vendor Themes

On Tuesday we had a BoF with various interested parties (including design team, distros, and app developers) to discuss a possible future Vendor Styles API.

GNOME does not currently support making changes to the platform stylesheet/icons, and app developers build their apps with this in mind. Changing these means ripping out API from under developers, which often results in apps looking broken. Some downstreams are doing it however, which is a problem for our overall platform developer story.

The good news is that some of these downstreams realize this is an issue, and are willing to work upstream to improve the situation. During the BoF we discussed the motivations for changing the platform style, and the kinds of changes they’re interested in. We broadly categorized these changes in 3 groups:

  1. Accent Colors”: Making it possible to change some UI colors (at both the system and app level) without breaking things
  2. Upstreamable”: Stylistic changes which upstream might be interested in (such as rounded menus, flatter checkboxes, etc.)
  3. Here Be Dragons”: Anything that touches widget sizing, margins, and the like (because changes to these break apps the hardest)

We spent most of the BoF discussing the “Accent Colors” category, because that’s where most of the low-hanging fruit is. The main things we need to figure out for this are

  • Which and how many variables do we want (and can realistically be supported)?
  • How would app developers test for different color combinations? What kind of tooling do we need to make that easier?
  • How do we ensure good contrast?
  • Can colors be set arbitrarily or are there constraints?
  • How are the colors set? What should that API look like?
  • Could we do this for GTK3 given that it’s stable? Would it be GTK4 only?
  • How would we handle Appstream screenshots looking different from the app once installed?

We discussed most of these questions in some detail, but all of this needs a lot more work before we can definitively say if and how we’ll go forward with it. At the BoF we outlined some first steps in this direction, namely documenting the current set of color variables within Adwaita, and looking at what other variables we might need. For more on this read the Discourse topic.

Once all of that is figured out though, there are some pretty exciting things on the horizon. For example, some third party app developers would like to use color in more interesting ways in their apps, but the way Adwaita is set up, this is currently not easy. If done right, making Adwaita more flexible would not only allow for vendor styles, but also empower app developers to do more cool stuff.

Epiphany uses a blue header bar in incognito mode. This kind of thing would be much easier to implement with an accent color API.

Another potential benefit is that a lot of the work around ensuring contrast on different background colors, better documentation around color variables, etc. would be needed anyway if we get a global “prefer dark” preference. If and when that happens, it will be a much easier transition if we’ve already worked out some of these things.

Lunch with some Purism people and other GNOME friends

Software Freedom/Ethics Ratings

I also sat down with François on Tuesday to discuss the software ethics rating system we’ve been thinking about for a while. The goal of this initiative is to make the value of software freedom more tangible to people when they’re looking for applications in an app store (e.g. “this app won’t leak your data” instead of “this app is licensed GPLv3+”). On the developer side, the goal is to encourage ethical practices (e.g. encryption) and discourage unethical ones (e.g. tracking). So far we’ve mostly discussed this idea internally at Purism, but as with everything else we’d ideally want it to be a ecosystem-wide thing others can benefit from rather than something we do downstream.

There’s plenty of relevant art for nudging people towards more ethical choices. In other industries there are many examples for both info badges/warnings (e.g. food labels with nutritional information) and indirect incentives (e.g. higher taxes on unhealthy foods). In the software realm, interesting examples include FDroid’s anti-feature warnings, and Terms of Service; Didn’t Read, which has curated summaries and letter grades.

Screenshot of the ToS;DR rating for Twitter

In our case we have limited options in the short term, because we have to deal with multiple different software sources (someone might have apps from a distribution repo, multiple Flatpak remotes, and who knows what else). In addition to that, giving a simple answer to the question “Is this app safe to use?” is often complicated and somewhat subjective. For example, it’s impossible to build an email client that doesn’t send unencrypted messages, or an RSS app that doesn’t connect to servers which could track you. Does that mean we should mark these apps as insecure/unethical?

There currently isn’t a trusted entity which could make the complex value judgements that are involved with deciding whether applications are ethical at scale, for many different software sources.

My feeling is that instead of coming up with a complicated process that may or may not work the way we expect it to, it would be good to first experiment with some leaner solutions and test the general approach. A potential first step we discussed could be something similar to the anti-features on FDroid, perhaps tied in with the existing Appstream metadata we have. In combination with Flatpak sandboxing/permissions there are a number of cases where you can actually say with relative certainty that an app is safe/ethical without complicated judgement calls (e.g. fully sandboxed apps without network access). If we can find a few such categories of apps this could be a good starting point, to see if this helps us reach our goals.

Obviously this needs a lot more work, but I’m hoping to do at least some mockups/prototypes soon. Also, I haven’t talked to a ton of people about this so far, but I imagine other projects with a focus in software freedom/ethics might be interested in this problem as well. If you work on such a project and have ideas/comments/concerns, let’s chat!

Wednesday: Beach BoF!

After 5 intense days of GUADEC and BoFs we had a more chill day at the beach on Wednesday. We still had lots of productive discussions about GNOME stuff there of course, maybe even better in some ways because we didn’t have our laptops distracting us :)


I’d like to thank the organizers for putting together an awesome GUADEC, all of my GNOME friends old and new for being there, and the GNOME Foundation for sponsoring my attendance!

September 04, 2019

GUADEC 2019 - Thessaloniki

I recently attended GUADEC 2019 in Thessaloniki, Greece. This is the seventh GUADEC I've attended, which came as a bit of a surprise when I added it up! It was great to catch up in person (some again, and some new!) and as always the face to face communication makes future online interactions that much easier.

Photo by Cassidy James Blaede

This year we had seven people from Canonical Ubuntu desktop team in attendance. Many other companies and projects had representatives (including Collabora, Elementary OS, Endless, Igalia, Purism, RedHat, SUSE and System76). I think this was the most positive GUADEC I've attended, with people from all these organizations actively leading discussions and a general consideration of each other as we try and maximise where we can collaborate.

Of course, the community is much bigger than a group of companies. In particular is was great to meet Carlo and Frederik from the Yaru theme project. They've been doing amazing work on a new theme for Ubuntu and it will be great to see it land in a future release.

In the annual report there was a nice surprise; I made the most merge requests this year! I think this is a reflection on the step change in productivity in GNOME since switching to GitLab. So now I have a challenge to maintain that for next year...

If you were unable to attend you can watch the all talks on YouTube. Two talks I'd like to highlight; the first one is by Britt Yazel from the Engagement team. In it he talks about Setting a Positive Voice for GNOME. He talked about how open source communities have a lot of passion - and that has good and bad points. The Internet being as it is can lead to the trolls taking over but we can counter that but highlighting positive messages and showing the people behind GNOME. One of the examples showed how Ubuntu and GNOME have been posting positive messages on their channels about each-other, which is great!

The second talk was by Georges Basile Stavracas Neto and he talked About Maintainers and Contributors. In it he talked about the difficulties of being a maintainer and the impacts of negative feedback. It resonated with Britt's talk in that we need to highlight that maintainers are people who are doing their best! As state in the GNOME Code of Conduct - Assume people mean well (they really do!).

Georges and I are co-maintainers of Settings and we had a productive GUADEC and managed to go through and review all the open merge requests.

There were a number of discussions around Snaps in GNOME. There seemed a lot more interest in Snap technology compared to last GUADEC and it was great to be able to help people better understand them. Work included discussions about portals, better methods of getting the Freedesktop and GNOME stacks snapped, Snap integration in Settings and the GNOME publisher name in the Snap Store.

I hope to be back next year!

September 03, 2019

Back to GNOME development

After writing my last blog post – a retrospection about my first 10 years of Free Software development – it made me want to contribute to GNOME again. I didn’t contribute much this past year (in short, too much stress). But I’m back, I hope my keen interest will continue.

I’ve restarted with gedit. I’m improving the documentation for contributors, I’ve written a new roadmap, and done the 3.33.92 development release. Plus already a small yak shaving in jhbuild (doing the release) for the gedit contributors’ docs 🙂


This year again I attended GUADEC, now for the sixth time in a row. It was a great GUADEC, as usual, thanks to the organizers and the attendees for making it as enjoyable as it was!

Friday 🎮

I attended Christian's talk about designing multi-process apps, it sparked the interest of Alexander Mikhaylenko who rapidly started playing with these concepts, as we plan since a long time to run Libretro cores in a subprocess in GNOME Games.

Lubosz presented his work on the VR Linux desktop. Even better, he demoed it, and the next day it was possible to test it in the corridor! So I did, and it was pretty amusing.

I had the pleasure to meet Andrei Lisita and watch his lightning talk about adding advanced savestates support to GNOME Games. It is the first time an intern working on Games attends GUADEC, but sadly this time it's his mentor (Alexander Mikhaylenko) who couldn't attend. One day maybe, an intern and a mentor for GNOME Games will meet. 😛

Games is a newcomer friendly and fun project, which accept interns since about four years now, so don't hesitate to submit your internship projects! Even though I don't maintain the project anymore, I am still really attached to it and it's a true pleasure to see it live without me. 🙂

Saturday 📦

The second day, I attended Patrick's talk about sandoxing WebKitGTK. Given that I'm interested in the development of GNOME Web, I'm very happy to learn that its 3.34 version will sandbox its web precesses.

After that, I attended Emmanuele's update on GTK 4. I am very interested by the development of GTK 4, and I plan to free some time to get more involved in its development. Unless I misunderstood, in GTK 4 containers will be replaced by layout managers, simplifying the widget hierarchy a great deal and dropping child properties in the process.

GTK 4 will introduce a constraint-based layout manager, allowing to implement complex UIs more easily. I'll have to play with all of these changes and learn how to use them properly! Constraints should be added to the layout manager, and they can be implemented either programatically, in a GtkBuilder XML file, or via the dedicated VFL language.

Emmanuele also mentionned gtk-builder-tool --3to4, which should automagically convert GTK 3 builder files to GTK 4.

After that, Jakub talked about designing icons. Drawing icons for GNOME was tedious and virtualy impossible for a developer without a background in art. Luckily I am a failed artist, which helped me designing some icons like the one GNOME Games used for many years, but it definitely was time consuming. Anyway, drawing a complex icon by hand several times didn't work out, so Jakub tried implementing icons with Blender, like the one for Builder. Granted, you didn't have to draw an icon several times, but the skills required to draw an icon where way too high!

So some GNOME designers and developers gathered, and implemented new icon guidelines for GNOME going the other way around: simple shapes, a flat design, and a single scalable icon. Now, you only needed a good idea and some basic knowledge of Inkscape to draw your application's icon! To help support this initiative, a new icon preview app was designed and implemented, allowing you to start a new icon project, draw it with Inkscape with the help of a template, and preview how it would look in GNOME in different circumstances, brilliant! To show how well it worked, he started designing and implementing a new icon with that tool, live, which went as well as all live demos.

As a sidenote, he mentionned that application icons are aligned on the baseline because typically the application's name is displayed below, so not doing so would would create a weird gap. I wonder how well following that logic would work for horizontal covers in media collections like GNOME Games.

Georges talked about maintainership, and how it can crush your soul. All he said was very sound and resonated with my past experiences, which led to abandonning the maintainership of GNOME Games.

Carlos and Sam talked about Tracker 3, which will be built from the ground up with sandboxing in mind, I'm happy to see that coming!

Sunday 🕶�

Cassidy talked about global dark modes and how they can be relevant. I initialy didn't understand the reason for a global dark mode, as I see the dark mode relevant only for applications which deal with graphical content (Videos, Photos, Games…) which is used only sporadically. But this is forgetting an important audience: those who create these contents in the first place. For the same reason graphical media consumption apps tend to use a dark mode, graphical media creation apps tend to do so too, so while graphical artists tend to spend most of their time with dark apps, the few times they switch to another application (a file manager, a web browser…) they can get their eyes burnt by the sudden brightness, causing a sufficient distraction to get out of the zone. A global dark mode would help them to avoid these light bursts. To make the reasoning complete, while a global dark mode is relevant, a global light mode isn't as it would just make the few apps using the dark mode less usable with no benefit.

I still see one downside to a global dark theme: working with a dark theme tends to make you turn you monitor's brightness up more than needed, burning your eyes more than needed without noticing as the screen seems dark, and leading to fatigue. While those working with graphics creation apps will overall benefit from it by avoiding bursts, those who don't need it may enable it simply because dark ⇒ edgy ⇒ cool, ultimately burning their eyes for no good reason.

Regardless of that downside, I agree it's worth implementing. macOS now supports a global dark mode, so does Windows, and, maybe more surprizingly, so does the web. In GNOME, we have the underlying technology to support it, all we need is a global setting to toggle it, and with his elementary hat on, Cassidy suggested making it a fd.o standard for it to work accross desktops. He also suggested toggling it could be scheduled, like for the night light mode.

While WebKit supports the dark mode, WebKitGTK doesn't because of the absence of that setting, to test if your browser supports it, just visit with a browser in dark mode (which should exist on our side yet).

Cassidy also briefly talked about accessibility features as an introduction, and I think he brought something interesting: in elementaryOS, accessibility features are just presented as features. This has two interesting effects: it avoids austracizing those who use these features, and it prevents users who may temporarily benefit from these features from not using them because they would either not think they are for them, or simply not even search in the accessibility category in the first place.

At the end of the day, we had a nice team diner with the other Purism folks in a good vegan restaurant. Apparently, they had the same idea at Endless as they also had a team diner in the same small restaurant at the same time. 🙃

Monday 🛠�

On Monday I attended the GTK hackfest. It has been decided to release GTK 4 in a year (with GNOME 3.40?), and by that time I want to properly fix all the mobile-related issues for which we have a workaround in libhandy or in our downstream patched GTK for the Librem 5, particularly if they are expected to introduce an API or behavior break. I should also merge the adaptive widgets from Libhandy like HdyLeaflet or HdyPaginator, but this could wait if needed.

Christian suggested that a GTK 4 UI designer shouldn't load code, and should instead be stencil-based. That seems really interesting to me, but I wonder how that could work, particularly regarding layouts.

There is a consensus around the need for a GNOME-specific widget library, which would likely receive GtkShortcutsWindow, HdyViewSwitcher, HdyPreferencesWindow, and all the other widgets which are deemed too GNOME-specific to be in GTK itself. This could ultimately remove the need for libegg, libgd, libdazzle, libhandy, and other widget libraries.

Tuesday ��

I attended the vendor theme BoF, it wasn't exactly relevant to me but it was nonetheless interesting to follow the conversation.

I spent most of the day working on my talk submission for LAS, getting the idea for an, hopefully, interesting talk, writting the proposal, and submitting it.

Wednesday ��

Beach BoF! We went to some nice beach less than an hour away from Thessaloniki. The trip there felt a bit surreal to me, the scenery was so… homy. It's basically home, except it's at the other side of the continent! I got fairly sun burnt but I'm doing good and I'm almost healed now. 🙂

Thursday �

Leaving on Thursday was stupidly expensive for me, so I stayed an extra day in Thessaliniki to get a way cheaper flight on Friday. I spent the day hanging out with pals who were still around, relaxing, eating ice cream, and attending a festival in the evening.

γυαδεκ? χκπτγεδ?

GUADEC in Thessaloniki was a great experience, as ever. Thank you once again to the GNOME Foundation for sponsoring my attendence!

Sponsored by GNOME Foundation

Some personal highlights, in no particular order:

  • A lot of useful and informative discussion at the GNOME Advisory Board meeting on Thursday – we ran out of time, which seems like a good sign.
  • After Benjamin Berg and Iain Lane’s great talk on Managing GNOME Sessions with Systemd, Benjamin and I discussed the special-case they had to make to run GNOME Initial Setup’s “copy worker” early in the user session, and whether we might be able to improve this and various other aspects by launching Initial Setup in a different way. (Write-up on an issue to follow…)
  • Via Matthias’ talk on Portals, I got thinking about the occasional requests for an “is this app installed?” portal, and I realised that you can actually fake it with existing machinery in some cases. If you care about a specific app, you probably want to be able to talk to it, so you specify --talk-name=org.example.Foo; at which point you can call org.freedesktop.DBus.ListActivatableNames() and check whether org.example.Foo is in the returned list.
  • The Intern Lightning Talks were inspiring: it’s great to see what has caught the interest of new contributors. This year, I was inspired by Srestha Srivastava’s work on Boxes to send a merge request to osinfo-db to generate the necessary XML for Endless OS. This in turn led to a great discussion with Fabiano and Felipe, and to some more issues and merge requests.
  • Alex Larsson was a tough act to follow at the lightning talks, but based on hallway discussion, my bit on Flatpak External Data Checker was of interest. (I taught it how to update appdata on the flight home. The person sitting next to me told me that writing code on flights is a young-person thing, which I took as a compliment.)
  • Not one, but two talks on user testing! One thing I took away is that while it’s possible to conduct remote usability testing, you’ll miss out on body language cues from the test subjects, and in the specific case of GNOME you’ll either bias the sample towards people who already use GNOME, or you’ll introduce the additional variable of whatever remote access tool the user uses. Not ideal!

On the Endless front, the launch of the Coding Education Challenge, and the various talks from my esteemed colleagues about varied activities, were all great to see.

There were lots of clashes for me, so I’m grateful to the AV team for their great work on recording all the talks. (Unfortunately, one of the talks I couldn’t make it to, on GDPR, was not recorded, to avoid distributing what could be construed as legal advice. Alas!) Many thanks to the local team and the GNOME Foundation staff and volunteers who made the event run so smoothly.

September 02, 2019

Maps and GNOME 3.34

Just released Maps 3.33.92, the last beta release before the GNOME 3.34.0 release next week.

I've already covered other news earlier, such as “search-as-you-type� auto-complete search and the new sharing dialog, allowing opening locations with any application capable of handling geo: URIs. I also implemented support for opening URLs pointing to objects in OpenStreetMap directly in Maps. This can be handy in cases when someone pastes such a URL in a chat for example (and the new sharing dialog allows to copy the same type of URL to the clipboard, or as an e-mail).

James Westman has also implemented a change in how startup works, so that Maps now will open directly at the location you last viewed, instead of starting from a view of the entire world and then animating to the location. We now also remember the map type as set when closing the app the last time (“normal� or aerial view).

Another thing (that is also already available in older versions as well) is that we have updated the tile style we use from MapBox.

I also started working on an idea I've been thinking about for a while, but that will not come in 3.34, so more on that later…

And one last thing, I also sneaked in a small little hidden feature for 3.34, let's see if anyone finds it… �

GUADEC 2019 – India to Greece Journey!

When I started contributing to GNOME, I never thought one day I would travel to Greece to present my work. Travelling to Europe has always been my dream, so when I received sponsorship email from GNOME travel committee, I was very excited. Being a student, it would have been impossible for me to attend GUADEC without sponsorship. Now after a month of planning, reading about Greece and watching past GUADEC videos, finally 22nd August, 2019 had come.

So I had early morning flight from Hyderabad ( my home town ) to Abu Dhabi and then Abu Dhabi to Athens after a layover of 2 hours. I had gone out of India only once before this trip, and never went to Europe before this.
So when we landed at Athens airport, I was very excited for the week to come. I guess one great thing about GUADEC is, they choose amazing locations and since GUADEC runs for 6 days, you’ve great amount of time to get quite familiar with the city. So from here we had one more domestic flight to Thessaloniki. Once we reached Thessaloniki, we met Kat and some other people on the bus. With their help, we reached Stay Hybrid Hostel. Stay hybrid hostel was the official place of accommodation for GUADEC attendees, and it was very nice, like it was in much better condition than the hostels I see in my home town. I really enjoyed my stay here. There was an informal meet at a nice and cozy place on 22nd night , we got a little late but we finally made it. Finally I got to meet Jean, Felipe and many other people. In the days to come, everyday I was interacting with new people. I realised I’ve so much more to learn and so many things I can explore.

On 23rd August, GUADEC 2019 finally started. On first day itself, we had our lightning talks. I didn’t get much time to work on my presentation before, so I sat with Jean and he gave some suggestions, and then at 4 PM, we had our talks. Since this was just a short talk about the work I really enjoyed, I wasn’t very nervous. But it was very nice to present my work in front of so many people, many of whom have done great contributions in the open source community. After the talk, many people came to us and asked more about projects. Those coffee breaks and trivia contest were really good way to meet new people!

In the beginning, I faced few challenges like none of my devices were getting connected to internet, electrical plugs here were different from India, food was very different from Indian food. But I guess facing these challenges is a part of the travel, and it’s all worth it. GUADEC organisers and volunteers were very helpful, we all can’t thank them enough for all the things they’ve done.

First three days were quite hectic, as we were jumping from one talk to another, and because of meal/coffee breaks timings, days were pretty structured. In the hacking days, I discussed some challenges in tracker writeback part of my project with Jean and Sam. Jean also reviewed Tag Editor, I realised there’s still a lot more work that needs to be done. Hacking days were quite chill compared to talk days. I really enjoyed all the social events also. Picnic spot was really awesome, it was like doing picnic on a hill inside a jungle. I liked the food also there, I had good discussion about corporate jobs vs open source development with Umang and Sri. There’s so many different career paths I can take, I can go into corporate, I can do Masters or research, I can continue working for open source organisations, so many decisions to make!

GUADEC days were not all about events organised by GUADEC, I also did lots of sightseeing. The shore side walk from port to White tower was really nice. I also went inside White tower, it was all greek to me, literally, since all the information was in Greek only! But I really enjoyed the view on top of white tower. The location of Stay Hybrid hostel was really amazing, as it was surrounded by many food and market places. The path from Stay Hybrid hostel to University of Macedonia had so many nice spots. Every day I would take a different path and explore the city, many times I stopped at the historical places or churches. I visited so many places like Agia Sophia, KTE tower, museums, etc. I hadn’t done RSVP to the last day beach trip, so I missed that, but instead I went to Athens and visited Acropolis. Overall this trip was really amazing! I really hope to attend more events and conferences like this, there’s so much you learn and enjoy!

Google Summer of Code 2019 Final Report

Google Summer of Code with Pitivi

GSoC with Pitivi

This summer I am working under the mentorship of Alexandru Băluț to improve the user experience of the Effects feature in Pitivi.

In the first phase of my project, I worked on redesigning Pitivi’s “Effect Library” to allow users to easily find, organise and utilize their desired effects.

Current Effect Library UI

My first assignment was to remove the ComboBox at the top and replace it with seperate Expanders for the various categories. In the process, we also decided to move away from showing Audio and Video effects separately, instead choosing to integrate “Audio” just as another category. This enabled us to present a hierarchical yet simple interface which also allowed the user to have multiple categories open at once.

The next order of business was to replace the tiny 4:3 thumbnails we have for the effects with larger and more expressive 16:9 ones (Thanks to Valentin Orient for contributing these beautiful new thumbnails!).

My final task for this phase was to add a “Favourites” feature which would allow the user to gather all the effects of their choice in a separate view for quick and easy access. For this, I added a button to the effects which enables the user to effortlessly check or change its “favorited” state.

New Effect Library UI

Concluding my work on the “Effect Library” and I will now be moving onwards to renovating the “Clip Tab” for the next phase.

If you wish to reach me, you can find me in #pitivi and #newcommers on GIMPNet as yat_irc.

scikit-survival 0.10 released

This release of scikit-survival adds two features that are standard in most software for survival analysis, but were missing so far:

  1. CoxPHSurvivalAnalysis now has a ties parameter that allows you to choose between Breslow’s and Efron’s likelihood for handling tied event times. Previously, only Breslow’s likelihood was implemented and it remains the default. If you have many tied event times in your data, you can now select Efron’s likelihood with ties="efron" to get better estimates of the model’s coefficients.
  2. A compare_survival function has been added. It can be used to assess whether survival functions across 2 or more groups differ.


I am happy to say that every GUADEC that I attended so far was absolutely fantastic. The 2019 edition of the conference, however, will have a special place in my heart for several reasons.

Let’s start with the fact that it happened in Greece. Being a Greek descendant myself, I was particularly excited with the idea of visiting the country of half of my family tree. I then decided to use this chance to travel all over the country with my father, and visit the places where my grandparents came from.

It was a fantastic and emotional journey.

The social aspect of GUADEC is also a big reason for the enjoyment. Over the years, the social aspect of the event is growing in importance to me. Being part of the GNOME community, seeing old friends, sitting down and enjoying some time with great people, this is what makes GUADEC valuable to me. I think part of the reason is that, after finishing masters and starting work full time from home, my daily human interaction is very limited, and I value these interactions much more now.

This GUADEC, I felt we are managing to make our community more diverse and well represented. I was happy to see members of System76, elementary OS, Endless, Collabora, Centricular, and independent contributors deeply engaged with the community.

In addition to all of that, I feel like this GUADEC was extremely productive. Orders of magnitude more than the previous ones.


This is the first GUADEC that I gave talks, and in fact I gave two of them:

State of the Shell

After getting involved with GNOME Shell and Mutter for some time, I was happy to be part of this talk. Even though it’s a deeply technical talk, with many details being hard to understand for those not initiated in the art of compositors and display servers, there was a fair share of public attending it!

As Jonathan Blandford said, these State of the Shell talks are “[…] an acquired taste, but delicious once acquired.” Being on the presenting side of the equation, I can only agree with that!

As I said multiple times in this space, working on Mutter and GNOME Shell is exciting. Exciting to learn about the underlying technologies, exciting to contribute to, exciting to see how every improvement impacts my very own daily usage of it. Naturally, the future of those modules is exciting as well!

About Maintainer and Contributors

This was a non-technical talk about the current state of maintainership in the GNOME community. I wasn’t expecting more than ~10 people in the room, but to my surprise, the room was filled.

When I had the idea for this talk, I wasn’t thinking of a lecture-like talk, with answers to common problems. Instead, I idealized a quicker time of me speaking, and an open discussion after that.

Fortunately, many members of the Engagement team were there and contributed with interesting ideas to this discussion. Some of these ideas, such as a Maintainership Guidelines document, are absolutely feasible in the short term, and I want to try and coordinate some efforts to get them done and see the results.

BoF days

The BoF days were busy. Between Endless ad hoc meetings, corridor hacking, and actually finding the allocated rooms, a lot has happened. I’d like to start mentioning the achievement that makes me proud the most.

Vendor Styles

Vendor Styles is essentially the ability of downstream vendors to change the platform stylesheet without breaking applications. The stance of many GNOME contributors is that this is not at all supported, and there is some truth in that. However, I feel like saying that there’s no support to that and turning our backs to the people that distribute GNOME is not a productive approach.

Distributors likely want to make their brand recognizable, just like we at GNOME want. There is an ongoing tension between these parts.

However, I also feel like this is not an us vs them situation. What we all want is a great desktop experience, and we can (and should) work together to achieve that. Vendor styling is a discussion that’s been carried out for the past few years, and yet without actionable ways to tackle it. Being the maintainer of Settings, I felt like any actions in this topic would eventually reach me; so I concluded that getting involved early in the process would avoid later headaches. This is indeed a complicated problem. My impression was that past attempts of solving it weren’t properly actionable.

I am happy to say that we managed to come up with well scoped and oriented proposal for how to achieve better styling across desktop applications. You can find more details about it here. The general idea is to (1) document the public CSS variables we already have, (2) ensure that the core applications of the platform adhere to the best practices, and (3) improve the guidelines so that developers can find and use the right CSS variables.

Settings BoF

Together with Robert Ancell, we managed to review every single open GNOME Settings merge request. While doing that, we also decided which merge requests are ready to land when the 3.36 development cycle starts, the ones that are feature-accepted but need more reviews, and the ones that are still not ready to land.

All of that, the addition of the new Background panel, and the remarkable polishments that happened during this cycle, make me very happy with the 3.34 release of Settings. I think it will be a fantastic release.

Thanks Robert for being a great co-maintainer and friend!

Mutter & Shell

The time spend on those modules was not limited to the talk. During the BoF days, we managed to sit down and discuss which merge requests should be part of 3.34, and review them. Of course, much more bandwidth will be available during the Mutter Hackfest later this year, but the GUADEC time was still important due to the release cycle.

Thanks to the many reviews of Jonas Ã…dahl, Robert Mader, and Carlos Garnacho, we landed a pet peeve of mine: “Make MetaShapedTexture a ClutterContent implementation (mutter!409).” This is an exciting merge request, since it’s the first big step towards a pure render node rendering in GNOME Shell. Many follow-ups will come, stay tuned.

We also reviewed and started to get the geometric picking branch in shape for landing. Sadly, that merge request is not particularly in a mergeable state right now, and it feels like it is half of what it should be. However, since a few downstream vendors are shipping the patches for some time, we at least have a minimal guarantee that it’s not going to blow anyone’s GNOME session away. We then decided to work on getting it into a minimally mergeable state for now, and create additional merge requests making the geometric picking be what it was supposed to be in the first place.


For those who are following the Sprint series, you may have noticed that I skipped last spring. Furthermore, I will also skip this one. The reason for that is that the vacation time before GUADEC, and GUADEC itself, didn’t allow me to work on this project.

To my surprise, Allan mentioned this Sprint project in their talk as a successful case of design / development coordination. It was a much welcomed validation of the project! You can watch the talk below:

I’m looking forward improving the sprint process and make it produce even more results with even less efforts. If with only 4 iterations we managed to improve so much, it won’t be a surprise if we can improve even more over time.

Starting next week, I will return with the Sprint series again, hopefully with a fresh new set of ideas to implement, polishments to land, and bugs to fix. Let’s see how it goes.

I could only attend this GUADEC thanks to the sponsorship of the GNOME Foundation.

September 01, 2019

Building a foundation of HPC knowledge

It is said that life is a series of decisions. In my case, I was living life as light as a feather, but passionate in anything at the same time. I like challenges and I did not want to be just a woman in computers, I wanted to be a woman that works with supercomputers! Three years ago, I found by chance the HPC (High Performance Computing) program offered by the University of Edinburgh while I was considering higher studies in HPC, since this field has many areas to flourish. Despite my previous HPC experience with my internship at ORNL in the USA, and the ISC 2016 event in Germany, I decided to move to Scotland to learn more about HPC.

The EPCC (which offers this intense HPC year program) has been the international centre for excellence in high-performance computing for over 25 years. I’ll share some memories:

The beginning

I was impressed by the number of ladies I met as classmates. Usually in the “IT world” there are very few women compared to men. The following picture shows that our HPC master group had 14 men and 10 women (1 from the UK, 1 Germany, 1 Peruvian, 7 China).

During classes and workshops

The curriculum for courses are previously arranged in advance by the teachers and teaching assistants and published one week before on the intranet. They consist of the theorical materials and practical exercises to support the theory. Some reinforcing workshops were also used in order to address questions and concerns.

Additionally, a personal tutor is designated in order to help us with any university subject.

Work as part of a group

Some courseworks were set in order to develop our skills of working as a group. Soft skills and other non-technical skills are also part of our educational evaluation. Dealing with students from multicultural societies was a little challenge for me at the beginning. With time, I discovered and learned from different studentship habits and actions.

Communication is the key in any healthy relationship in any circumstances.

Visiting Edinburgh in group

We did not share many moments as a unified group because of the deadlines of the intensive Master program. The first time we were together, it was arranged by the school to have an all-you-can-eat buffet with dishes from all over the world. A second big-group meeting was gathered by the initiative of the Chinese group. We went to the Edinburgh zoo, where we had lots of expectation for the penguin parade! The last one was a two-hour walk to the Arthur’s seat during the first week of our second semester. It was recorded  🙂

I have to say that the Chinese group demonstrated to be a strong community.

My failures and achievements

One of the first coursework that represents a challenge to me was our first MPI assignment, which consisted of divide a figure into pieces, then enhance it, to finally reconstruct it using many MPI processes. At the end, we were asked by the school to deliver a code and a report. Figures of different sizes were used for the experiment and thanks to the help of Holly and Jasmin I was able to complete it! Another challenge I remember I had, was the Student Cluster Competition SCC. I left the team since it represented an extra effort that I was not able to manage at that time.

The experience was useful at the end because my dissertation included the CP2K HPC app.

Inspirational people and friends

Living abroad implies facing hard times, special thanks to Holly, Ruwaida, Racky, Huahua, Andreas and Cris for their understanding and help any time I asked. They stood by my side not only as good classmates, they were very friendly even in my complex mood :p

Meeting pluricultural people and moreover, living together in Bayes was “the experience”.

Unforgettable moments

The picture in the left was taken the first Sunday we meet in Bayes to complete the PS assignment. It was funny to see other groups watching us through the windows as a weird group. The picture in the right was taken in my apartment by my dear Holly, who was trained by me the whole year to have amazing selfies. I am glad she made it 😀

Uncountable stories that at the end someone remembers how others made you feel.

Leveling up people

Special thanks to those people that trusted in myself when I struggled to achieve something related to the master. Thanks to Vanya Yaneva for her support during the practical sessions, thanks to my supervisor during dissertation time and thanks to Abby!

The end

After presenting our dissertation summaries, the school prepared a gathering to close out the university year. I could not believe that this stage in my life finally ended.

All this students were so hard worked and smart in researching. I learned a lot from them.

Thanks EPCC

Scientists of EPCC were so helpful with my questions in the kitchen! Thanks to all EPCC!

New Meson mugs, get them while they're hot!

Since there is no Meson swag available, I decided to make some. Here is the first one.

Now sadly there is no web store and shipping ceramics is expensive, so the only way to get them is to be in the same physical space as me. Unless you live in Finland (or have friends that do and can be persuaded to get one for you) the only real way is to meet up with me in some conference. The next one I'll be going to is CppCon in two weeks. I'm going to be on vacation in New York for one week before that so that is also an option. Supply is limited by how many I can pack in my luggage and survive airport baggage handlers.

Bonus meta logo picture


I arrived for GUADEC on the 22nd and rushed from the hostel to the 10th annual Womens' Dinner. The dinner was held at a local restaurant and we had balloons, lots of shared appetizers, and vanilla fondant spoon sweets  :) Perhaps because the dinner was held before GUADEC, it was very small this year. As always, though, there was a lively conversation and it was great to catch up with old friends and meet new women in the community.

On the first day of GUADEC Manuel Quiñones and I gave a talk on the work that we did on the Hack Computer. It was nice to share the process  of preparing and practicing the talk with one of my old teammates. We introduced the Hack system, and then we each covered the components we had worked on in more depth. I gave a basic outline of the responsibilities of the toolbox. I also discussed some of the thornier issues in the ToolBox component of Hack, like type checking and post-condition validation in JavaScript. When we were putting together the talk I was struck by how the design (both technical and visual) made the Hack project more than the sum of its parts -- it created an imaginative, engaging space where disparate parts of the system worked seamlessly in concert.

When I booked my travel I was still working at Hack, so I had expected to spend time hacking with my co-workers. However, since I am now at a different company that is not related to GNOME I had time to relax and enjoy the conference and the beautiful (and incredibly warm) city of Thessaloniki. The keynote on GNU Health was very thought-provoking, but I was left with some unanswered questions about patient privacy. During the BoF days, I spent some time working on a custom Django app for the Travel Committee. Luckily, though, we spoke with Neil during our meeting on the afternoon of the first day and he told us that some customizations can be added to GNOME's Odoo instance and it will provide us with all the functionality we need. So hopefully before next GUADEC we will have a new, easier system for submitting, processing, and tracking travel sponsorship requests! Since I didn't have to work on the Travel Committee app, that freed up some of my time and I spent a bit of it getting JHBuild set up so I could start on a GJS bug with the help of Philip Chimento.

Thanks to Endless for paying for my plane tickets and the GNOME Foundation for funding my accommodations. Hope to see you all at the next GUADEC!