GUADEC + Unconferences | 2017

This year’s GUADEC was amazing. I’m really happy I could attent it this year (even though my tasks are accumulating and I’m really afraid to look at my emails again…). I’m still in Manchester so, if anyone wants to meet me and buy me a tea, do get in touch!

There were quite a few talks that I enjoyed. I can’t really name one that I liked the most, but on the top of my list are:

I had a special interest in Richard’s talk. He raised many relevant questions and exposed how complicated it can potentially be the problem of donations and payments. More about that in the future.

Calendar & To Do

I had the chance to sit down and see a power user interacting with GNOME Calendar. It was an unique and enlightening experience. I was able to see a few areas where Calendar can do better in terms of UI/UX.

Unfortunately, GNOME To Do didn’t have the same luck. I’m still somewhat unhappy with the current UI of To Do, but I’m running out of ideas on how to improve it without a complete rewrite (which I simply don’t have time to do now). If you’re a GNOME user with any kind of background on design, ~please~ get in touch: I’d love to gather some feedback on To Do!

GTK4

I had the chance (and honor) to be present at the discussions for GTK4. In these discussions, we did a big list of topics and discussed each one of them in details.

This slideshow requires JavaScript.

I admit that, during these discussions, I felt like a kid at times – the GTK hackers are incredibly smart and skilled people. The other side of the coin is that, while I was feeling like lagging behind them, I also felt honored and happy to be surrounded by such amazing people.

The biggest problem to solve now is the accessibility stack. After digging into the topic and clarifying how it works, we concluded that this topic was too big and complex for that moment, and deserved a hackfest of its own. We’ll organize one during the next months.

Wrapping up, I can’t state how productive these discussions were. Thanks to Matthias Clasen, Benjamin Otte, Christian Hergert, Cosimo Cecchi and everyone else that drove the discussions. We now have a solid GTK4 roadmap that I’ll move to the GNOME Wiki in no time.

GNOME Shell

An unexpected thing happen during the Unconference days. When talking to my good friend Mario we asked ourselves: how can we improve our own Endless tasks by upstreaming our features?

Endless OS shell has many features that GNOME Shell doesn’t, and maintaining downstream patches is expensive and simply not cool. One of these features was specially important, as it is difficult to maintain and lots of GNOME users frequently ask for.

This specific feature was considered in the past, but had many design constraints and we end up never solving it design-wise, nor implementing it.

This is about to change.

After a rather spontaneous group discussion, we found solid solutions for all the relevant edge cases of this feature 🙂  I’m sure Mario will write about it in the future, and probably will implement it as well, so stay tuned!

Because, in case you forgot:

banner down

(And yes, I purposely didn’t say which feature I’m talking about – but I’m sure many of you can guess that :P)

Mutter

After a long explanation and discussion with Florian Müllner (and of course, getting him a well deserved beer for being the GNOME Shell and Mutter maintainer!) the path for quarter-tiling is much clearer now.

The original idea is to implement tiling support using constrained edges, rather than tiling states. But this is hard, and now I believe it’s effectively impossible to do that.

Olivier Fourdan tried to propose a Wayland protocol for that, but discussion ended up freezing and no progress was made for a long time. I admit I’m kinda scared to try to send  these changes upstream… see the bug’s feedback (sometimes I forget that the GNOME community is much more welcoming than many other FOSS communities).

I now have a real problem to solve, and the time is not enough. Perhaps it’s time to declare bankruptcy?

Acknowledgements

I’d like to thank the GNOME Foundation for sponsoring me. I sincerely hope that my engagement and contributions pay off this investment!

I also thank my employer Endless to let me join. The upstream contributions we’re doing are valuable for the community, and in turn it helps us lowering the number of downstream changes to maintain.

sponsored-badge-shadow

Advertisements

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:

captura-de-tela-de-2017-01-17-09-24-32
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,
                       GTK_STATE_FLAG_SELECTED,
                       "font", &font_desc,
                       NULL);

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,
                       NULL);
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.

Conclusion

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?

Calendar

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).

Nautilus

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.

Gtk+

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.