Accéder au contenu principal


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.


  1. Valuable blog,Informative content...thanks for sharing, Waiting for the next update…
    What is GST?
    Benefits of GST

  2. We construct bespoke compositions only and they are always counterfeit free which consistently meet the faculty requirements. Our Assignment Writing Help has consistently earned excellent academic grades for understudies.



Enregistrer un commentaire

Posts les plus consultés de ce blog

libhandy 0.0.10

libhandy 0.0.10 just got released, and it comes with a few new adaptive widgets for your GTK app. You can get this new version here . The View Switcher GNOME applications typically use a GtkStackSwitcher to switch between their views. This design works fine on a desktop, but not so well on really narrow devices like mobile phones, so Tobias Bernard designed a more modern and adaptive replacement — now available in libhandy as the HdyViewSwitcher . In many ways, the HdyViewSwitcher functions very similarly to a GtkStackSwitcher : you assign it a GtkStack containing your application's pages, and it will display a row of side-by-side, homogeneously-sized buttons, each representing a page. It differs in that it can display both the title and the icon of your pages, and that the layout of the buttons automatically adapts to a narrower version, depending on the available width. We have also added a view switcher bar, designed to be used at he bottom of the window: HdyView

Moving the Blog

I am moving this blog to greener lands: . The existing articles will remain here on Blogger, and new articles will land on the Plume instance.

GTK+ Apps on Phones

As some of you may already know, I recently joined Purism to help developing GTK+ apps for the upcoming Librem 5 phone . Purism and GNOME share a lot of ideas and values, so the GNOME HIG and GNOME apps are what we will focus on primarily: we will do all we can to not fork nor to reinvent the wheel but to help allowing existing GTK+ applications to work on phones. How Fit are Existing GTK+ Apps? Phones are very different from laptops and even tablets: their screen is very small and their main input method is a single thumb on a touchscreen. Luckily, many GNOME applications are touch-friendly and are fit for small screens. Many applications present you a tree of information you can browse and I see two main layouts used by for GNOME applications to let you navigate it. A first kind of layout is found in applications like Documents, I'll call it stack UI : it uses all the available space to display the collection of information sources (in that case, documents), clicking a