A history about Gtk+, Vulkan and Wayland

A few weeks ago, I was curious to test Gtk+ 4. I know it has some awsome features like OpenGL rendering, major cleanups and other hot stuff, but didn’t have the chance to check it out until then.

I was mostly excited about Vulkan.

I know both of my laptop’s graphic cards support Vulkan. It’s a hybrid Intel Broadwell G2 + NVidia GeForce 920M, although I don’t use the latter because Linux sucks hard with Dual GPU.

Downloaded the latest Gtk+ source, compiled and… nothing. Immediate segmentation fault. Yay! What a great chance to get involved with the next major Gtk+ version development!

So, this happened:

The Fishbowl running under Wayland and rendered with Vulkan

May not be as exciting, since there are no new visible features but… damn, it’s Gtk+ being rendered with Vulkan on Wayland. It’s basically the state-of-the-art of toolkit support right now. Even better, the absolute majority of applications will gain this for free once they port to Gtk+ 4 series.

Getting this into an usable state wasn’t easy, but fortunately, Vulkan has an ~amazing~ thing called “Validation Layers” that simplified the tedious debugging process a whole lot (of course, only after making the validation layers work with Gtk+). This work even uncovered a driver bug in the Intel driver, which was quickly fixed by Lionel Landwerlin and Jason Ekstrand (thanks folks!)

Of course, there are many improvements that still must be done. A bright future is lying ahead!


CSS blend modes in Gtk+

As part of my work on Endless, I have to maintain and adapt GNOME applications to better suit our needs. This usually includes fixing bugs, working around limitations of the toolkit, and sometimes implementing new features.

Some time ago, I was asked by multiple designers about the CSS blending modes. This is a well-known feature that is widely used in photo manipulation apps like Photoshop®, and recently Adobe is trying to port this to CSS3 spec.

This allows designers to be more flexible and have a finer control over the rendering, and saves some bandwidth because we don’t have to send the blended image as an asset.

This marvelous feature is starting to see its light in Gtk+.

Captura de tela de 2016-07-03 11-45-06
Background blend mode is about to land.

This is the second time I’m working on something big on Gtk+ (the first one being the Other Locations view) and I’m pretty excited! This was requested by our beloved designer Lapo and also by Endless designers.

When it lands on master, we’ll also have a nice demo in Gtk3-demo app. And, as tradition dictates, a demo video:

In the near future, I plan to work and support more blending operations and CSS properties. Hopefully, this puts Gtk+ ahead of many browsers that doesn’t support these operations. What do you think? Share your comments, ideas and suggestions! 🙂

Quick guide to port an app for Gtk+ 3.20

Recently, there was a lot of action happening in Gtk+ git repository. It was the so called CSS Nodes, which supposely came to improve Gtk’s CSS features and other good things. If you want to know more about that, you can check these two great posts by Matthias Clasen: “A GTK+ update” and “CSS boxed in GTK+”. They, however, come with a downside: it needs some fixups from theme authors and developers too.

Since I just ported GNOME To Do and GNOME Calendar to this new model, and I had quite a hard time tracking down some issues, I decided to write this quick, small and incomplete guide for developers to port their applications to Gtk+ 3.19+.

Note: this is totally based on my personal experience porting the applications, so please, please, if you find any errors, report it and I’ll immediately fix.

The 3-step solution

In order to port your application codebase to Gtk+ 3.19+, there are 3 basic steps to follow:

  1. Replace gtk_widget_get_state_flags by gtk_style_context_get_state_flags
  2. Double check gtk_style_context_get* family of functions
  3. Add a CSS name (optional)

Lets check each step closely. I’m using Calendar’s port to use a CSS name as a case study here.

1. Replace gtk_widget_{get/set}_state_flags

Pretty self-explanatory title. An example (relevant section in bold letters):

GtkStyleContext *context;
GtkStateFlags state_flags;

context = gtk_widget_get_style_context (widget);
state_flags = gtk_widget_get_state_flags (widget);

turns into

GtkStyleContext *context;
GtkStateFlags state_flags;

context = gtk_widget_get_style_context (widget);
state_flags = gtk_style_context_get_state (context);

Since we’re now using GtkStyleContext API, the same is valid for gtk_widget_set_state_flags. You should use gtk_style_context_set_state instead.

2. Double check gtk_style_context_get*

Now the part the took most of my time to figure out how to fix. Obviously, if I had read Matthias’ blog post correctly, I would’ve done it way faster. While tracking down Calendar warning messages, they were coming from this function (among others):

gtk_style_context_get (context,
                       "font", &font_desc,

What’s wrong here? The issue is that we’re passing a state that can be different from the GtkStyleContext’s one.

To fix that, we simply have to set the GtkStyleContext’s state before calling the function, as demonstrated below:

gtk_style_context_save (context);
gtk_style_context_set_state (context, GTK_STATE_FLAG_SELECTED);
gtk_style_context_get (context,
                       gtk_style_context_get_state (context),
                       "font", &font_desc,
gtk_style_context_restore (context);

Again, the relevant sections are bolded. Now, the last piece of this cake.

3. Add a CSS name (optional)

This one is quite easy. Instead of using the class type to match it, the widget sets a CSS name in the class_init function. Let’s check:

static void
gcal_event_widget_class_init (GcalEventWidgetClass *klass)
  GtkWidgetClass *widget_class = GTK_WIDGET_CLASS (klass);


  gtk_widget_class_set_css_name (widget_class, "event-widget");

Now we have to update the theme file. In GNOME Calendar, the theme is stored in gtk-style.css:

GcalEventWidget {
  /* CSS properties */
turns into
event-widget {
  /* CSS properties */

Tada! It’s done. You now ported your widget to use a CSS name.


I reiterate that this is only my personal experience adjusting the widgets, and is prone to error. This is an ongoing work, so there may be changes after this guide is published (but I’ll try to keep this document updated).

Feel free to share your comments, ideas and rants 🙂


Free as in available space (Nautilus & Gtk update)

One of the greatest things in contributing to GNOME is the ability to have a really close contact with highly skilled designers. We, mere programmers, learn a freakin’ lot by talking to them and trying to understand their points of view.

While working on the Other Locations view, one of the most requested features was the ability to see the free space of the disk. Seems like a simple and obvious feature, but after reworking a whole lot of components, it isn’t trivial to add it and make it look good, integrate well and behave perfectly.

An usual day in our designers’ life.

And, ladies and gentlemen, here I present you the simple but lovely work that just happened based on Allan’s work:

Captura de tela de 2015-12-11 02-46-39
Available space in filechooser

And, as always, I couldn’t let our beloved file browser behind:

Captura de tela de 2015-12-11 02-45-11
Available space in Nautilus

This work already landed on master, and you can test it with JHBuild. Got any doubts? Comments? Suggestions? Leave a comment 🙂

What the future holds (or plans for GNOME 3.20)

We did it. Yes, we finally made it. We’re having the 3.18 release, and is the best release ever – just like every GNOME release. We saw many cool features landing, a number of awsome project which the GNOME interns (hey, I was one of them too!) worked on this summer and lots of exciting news going around.

Every new GNOME release, however, actually just an excuse for the next one. There’s always room for improvements and the work never ends. I personally like the beginning of new release cycles so that I can plan ahead what I’ll probably work on. And why not share it?


Oh, poor Calendar. Received so little attention for 3.18 release… fear no more! Calendar will receive it’s well deserved love. Here’s what’ll happen:

  • Calendar theme will get some attention. Minor details will be fixed.
  • Every single struggle pointed by Gina’s usability tests is going to be fixed.
  • We’ll finally have Drag n’ Drop support!
  • Hopefully, Week view will be ready.
  • A new view will be available too – but that’s a surprise! 😉
  • Much like To Do, Calendar will receive some error reporting UI too.

To Do

The new kid in town will also receive some love. Since it’s very fresh and young, there’s plenty of ideas to try here:

  • A new flow grid view will land (see Google Keep’s grid view to have an idea).
  • Support for subtasks (and the many cool things we can do with that).
  • Full GOA support (actually depends on Evolution-Data-Server work).


I started working on Nautilus as part of my Summer of Code internship, and – guess what – I won’t abbandon it! Such a core component of GNOME stack must receive as much attention as it possibly can. For this cycle:

  • Improve the way we do bookmarking on Nautilus (possibly will reflect on Gtk+ too).
  • Rework the search UI.
  • Remove the duplicated GtkPlacesView code.
  • Many bugfixes.


Together with Nautilus, I managed to inject some code in Gtk+ as part of my GSoC internship too. And I just realized that I’m the official(?) maintainer of a Gtk+ widget! As such, that’s what I’ll do on Gtk+:

  • Show the free space of local disks, as shown in the mockups.
  • Cleanup & document the code.
  • Expose it as a public widget (and also remove the duplicated code from Nautilus).
  • Improve the places sidebar.

I’m also hoping to work on smaller things with Music and Maps. And last week, I made my first patches for Grilo! Stay tuned for updates on that.

There’s not much to say besides that. I sincerely hope you guys enjoy using the new GNOME 3.18 release, just as much as I enjoyed working on it! See ya!

Final touches to Other Locations view (GSoC report #5)

After fixing many issues with the Other Locations view (a.k.a. GtkPlacesView), it is mostly ready for merge. During the last week and a half, I was able to accomplish:

  • Search support for Other Locations view
  • Empty state (following the proposed guidelines for empty states)
  • Better handling of recent servers
  • Much improved feedback on asynchronous operations like (un)mounting and connecting to servers

And here it goes a preview of the widget:

I really hope you guys are enjoying the work up to this point.

A small reflection

If I were to say, I was very upset with my work until now. Things weren’t going as fast as I thought they should go, and I was feeling bad because of it. Looking at it now, I can see that, while it’s far from finished, it’s not bad or poorly done too. Also, I can’t express how much I’m learning with the whole experience of the Summer of Code, and that is very important too.

I have to congratulate my mentor Carlos Soriano for his endless patience and attention. Also, Matthias Clasen for the very detailed (and totally voluntary) reviews of my patches, and Allan Day for his omnipresence and availability for clarifying questions. They are respectable human beings.