GdMainBox — the new content-view widget in libgd

Now that I have written at length about the new fluid overview grids in GNOME Photos, it is time to talk a bit about the underlying widgets doing the heavy lifting. Hopefully some of my fellow GNOME developers will find this interesting.

Background

Ever since its incubation inside Documents, libgd has had a widget called GdMainView. It is the one which shows the grid or list of items in the new GNOME applications — Boxes, Photos, Videos, etc.. It is where drag-n-drop, rubber band selection and the selection mode pattern are implemented.

However, as an application developer, I think its greatest value is in making it trivial to switch the main content view from a grid to a list and back. No need to worry about the differences in how the data will be modelled or rendered. No need to worry about all the dozens of little details that arise when the main UI of an application is switched like that. For example, this is all that the JavaScript code in Documents does:

  let view = new Gd.MainView({ shadow_type: Gtk.ShadowType.NONE });
  …
  view.view_type = Gd.MainViewType.LIST; // use a list
  …
  view.view_type = Gd.MainViewType.ICON; // use a grid

Unfortunately, GdMainView is based on GtkIconView and GtkTreeView. By this time we all know that GtkIconView has various performance and visual problems. While GtkTreeView might not be slow, the fact that it uses an entirely separate class of visual elements that are not GtkWidgets limits what one can render using it. That’s where GdMainBox comes in.

GdMainBox

GdMainBox is a replacement for GdMainView that is meant to use GtkFlowBox and GtkListBox instead.

GListModel *model;
GtkWidget *view;

model = /* a GListModel containing GdMainBoxItems */
view = gd_main_box_new (GD_MAIN_BOX_ICON);
gd_main_box_set_model (GD_MAIN_BOX (view), model);
g_signal_connect (view,
                  "item-activated",
                  G_CALLBACK (item_activated_cb),
                  data);
g_signal_connect (view,
                  "selection-mode-request",
                  G_CALLBACK (selection_mode_request_cb),
                  data);
g_signal_connect (view,
                  "selection-changed", /* not view-selection-changed */
                  G_CALLBACK (selection_changed_cb),
                  data);

If you are familiar with with old GdMainView widget, you will notice the striking similarity with it. Except one thing. The data model.

GdMainView expected applications to offer a GtkTreeModel with a certain number of columns arranged in a certain order with certain type of values in them. Nothing surprising since both GtkIconView and GtkTreeView rely on the existence of a GtkTreeModel.

In the world of GtkListBoxes and GtkFlowBoxes, the data model is GListModel, a list-like collection of GObjects [*]. Therefore, instead of columns in a table, they need objects with certain properties, and methods to access them. These are codified in the GdMainBoxItem interface which every rendered object needs to implement. You can look at this commit for an example. A nice side-effect is that an interface is inherently more type-safe than a GtkTreeModel whose expected layout is expressed as enumerated types. The compiler can not assert that a certain column does have the expected data type, so it left us vulnerable to bugs caused by inadvertent changes to either libgd or an application.

But why a new widget?

You can definitely use a GtkFlowBox or GtkListBox directly in an application, if that’s what you prefer. However, the vanilla GTK+ widgets don’t offer all the necessary features. I think there is value in consolidating the implementation of those features in a single place that can be shared across modules. It serves as a staging area for prototyping those features in a reasonably generic way so that they can eventually be moved to GTK+ itself. If nothing else, I didn’t want to duplicate the same code across the two applications that I am responsible for — Documents and Photos.

One particularly hairy thing that I encountered was the difference between how selections are handled by the stock GtkFlowBox and the intended behaviour of the content-view. Other niceties on offer are expanding thumbnails, selection mode, and drag-n-drop.

If you do decide to directly use the GTK+ widgets, then I would suggest that you at least use the same CSS style classes as GdMainBox — “content-view” for the entire view and “tile” for each child.

The future

I mentioned changing lists to grids and vice versa. Currently, GdMainBox only offers a grid of icons because Photos is the only user and it doesn’t offer a list view. That’s going to change when I port Documents to it. When that happens, changing the view is going to be just as easy as it used to be.

gd_main_view_set_view_type (GD_MAIN_BOX (view), GD_MAIN_BOX_LIST);

[*] Yes, it’s possible to use them without a model, but having a GListModel affords important future performance optimizations, so we will ignore that possibility.

New GNOME API key for Google services

Tl;dr: update evolution-data-server to stop your client from misbehaving; update gnome-online-accounts to shield yourself from other buggy clients.

Recently, a few bugs in evolution-data-server were causing various GNOME components to hit Google’s daily limit for their CalDAV and Tasks APIs. At least evolution, gnome-calendar and gnome-todo were affected. The bugs have since been fixed, but until every single user out there installs the fix, everybody will be susceptible even if they have a fixed copy of evolution-data-server. This is because Google identifies the clients by the OAuth 2.0 API key used to access their services, and not the version of the code running on them.

We are therefore phasing out the old Google API key used by GNOME so that users updating their systems will have no connection to the one that was tainted by these bugs.

Fedora Users

If you are using Fedora 25, make sure you have evolution-data-server-3.22.3-1.fc25 and gnome-online-accounts-3.22.3-1.fc25. For Fedora 24, the versions are evolution-data-server-3.20.6-1.fc24 and gnome-online-accounts-3.20.5-1.fc24.

GNOME Distributors

If you are distributing GNOME, make sure that you are shipping evolution-data-server-3.22.3 and gnome-online-accounts-3.22.3, or evolution-data-server-3.20.6 and gnome-online-accounts-3.20.5.

Core Apps Hackfest 2016: report

I spent last weekend at the Core Apps Hackfest in Berlin. The agenda was to work on GNOME’s core applications: Documents, Files, Music, Photos, Videos, Usage, etc.; to raise their overall standard and to make them push beyond the limits of the framework. There were 19 of us and among us we covered a wide range of modules and areas of expertise.

I spent most of my time on the plumbing necessary for Documents and Photos to use GtkFlowBox and GtkListBox. The innards of Photos had already been overhauled to reduce its dependency on GtkTreeModel. Going into the hackfest we were sorely lacking a widget that had all the bells and whistles we need — the idiomatic GNOME 3 selection mode, and seamlessly switching between a list and grid view. So, this is where I decided to focus my energy. As a result, we now have a work-in-progress GdMainBox widget in libgd to replace the old GtkIconView/GtkTreeView-based GdMainView.

In fact, GtkListBox and GtkFlowBox was a recurring theme at the hackfest. Carlos Soriano and Georges were working on using them in Files, and whenever anybody uses them in a non-trivial manner there is the inevitable discussion about performance. Good thing that Benjamin was around. He spent the better part of a tram ride and more than an hour at the whiteboard, sketching out a strategy to make GtkListBox more efficient than it is today.

Like last year, Øyvind joined us. We talked about GEGL, and I finally saw the new GIMP in action. I rarely use GIMP, and I am not sure I have ever built it from source, but I have been reading its sources on a semi-regular basis for almost a year now. It was good to finally address this aberration. Øyvind had with him a cheap hand-held DLNA media renderer that was getting stuck when trying to render more than one image with dleyna-render and Photos. Zeeshan helped me poke at it, but unfortunately we didn’t get anywhere.

Other than that, Petr Stetka impressed everyone with his progress on the new Usage application. Georges refreshed his patches to implement the new Online Accounts Settings panel, Carlos Garnacho helped me with GtkGesture, and I reviewed various patches and branches that had been on my list for a while.

Many thanks to Red Hat for sponsoring me; to Carlos Soriano and Joaquim for organizing the event; to Kinvolk for being such gracious hosts; and to Collabora for the nice dinner.

Content Apps Hackfest 2015: report

I spent most of the previous week attending the Content Apps Hackfest in Madrid. The agenda was to work on GNOME’s content applications: Documents, Files, Music, Photos and Videos; to identify missing features and sore points; and raise the standard of the overall content experience in GNOME. Of these, I focused mainly on Documents and Photos.

The first day was spent discussing high-level goals:

• Previews – should the content applications take over the role played traditionally by Evince and Eye of GNOME?
• Status and plans about sharing. We are still waiting for a platform-wide sharing framework, but since it is a crucial feature for some of the applications, it has become a case of perfection being the enemy of good.
• Porting away from GtkIconView to GtkFlowBox. GtkIconView has some very visible problems – it becomes terribly slow when the images are updated; the grid’s content doesn’t re-flow when the size of the widget changes leading to an awkward gutter appearing on the side; cannot pack any GTK+ widget into a GtkCellRenderer.

I set up a live Google Hangouts stream on my laptop to let those who couldn’t attend in person to join us remotely. With Andreas’ help, I fixed the HiDpi breakage in Photos’ cropping tool, Bastien fired some new LibreOffice builds, while the other Bastian revamped Documents’ wiki page.

The second day started with breakfast in Florian’s flat. It was less chatty with people quietly hacking away, presumably, to rest their tired throats. Bastien picked up Pranav’s patches to integrate LOKDocView widget in Documents. I worked a bit on polishing rough edges in Photos’ editing code, and tried to keep up with the endless stream of patches from Alessandro and Umang.

Discussions picked up a bit on the third and final day. Allan spent a lot of time talking to the developers of each application. UX reviews were done, new designs were made, and future plans were sketched out. I spent some time with him working on a roadmap for Photos. We are still cleaning up our rough notes and transferring them to the wiki, but I think it is good enough for others to take a look. Øyvind paid us a surprise visit, and we grabbed the opportunity for some impromptu chat.

Many thanks to Red Hat for letting me attend and sponsoring me, and to Medialab-Prado for being such wonderful hosts.

GNOME Documents: come join us

GNOME 3.12 is out and it is time to look forward to the next release. Lots of new features to implement and bugs to fix. I spent some time with Allan Day preparing a list of bugs for Documents that are waiting for someone to attack them. The list is here. Pick one that interests you and attach your patch to the bug.

This is part of an experiment that Allan started. We will keep adding new bugs to the list as they come in, and other modules might join the experiment in future.

So, fire up your text editors and see you in bugzilla!

Documents and Photos: a content application update

We have continued our work towards having a nice set of core applications for finding and selecting the user’s content. Documents, which is the eldest, received a round of thorough bug squashing for GNOME 3.12. It is a much more mature and well-behaved application now than it was six months ago, mainly due to the work of our QA teams – both upstream and downstream. Photos received a set of nice new features and is well on its way towards fulfilling the role it was designed for.

Facebook

Álvaro Peña added support for browsing Facebook photos based on his libgfbgraph library.

Search

This was something that was sorely lacking in the previous releases. With the increase in the number of online sources, the inability to be able to filter the content based on some parameters was badly felt. But not any more.

User help

The documentation team has paid a lot of attention to the end-user help for these two applications. Older pages have been refreshed and newer ones written, and I can easily say that GNOME 3.12 will be one of the best in terms of documentation coverage.

GNOME: driving to the sky, one step at a time

In the new GNOME 3.x series there has been a push to integrate the user’s online accounts into the desktop. At the same time we have been working on a new set of core applications for finding and selecting the user’s content. Documents is one such application. It lets you view and search your documents that are stored both locally and online.

GNOME 3.6, which will be released in September this year, will have lots of improvements and new features in this regard. One of them is the integration of Microsoft’s SkyDrive file hosting service. Go to the Online Accounts panel in System Settings (hit the super key or the Activities button and type “online”) to enable your Windows Live account, and you will be able to access your SkyDrive from Documents just as you are now able to do with your Google account.

Here, in these screenshots, you can see that I am viewing the PDFs of the famous Linux Device Drivers (3rd edition) book which are stored on my SkyDrive account.

The development of this new and exciting feature is being tracked here. You can either wait for GNOME 3.6 to come out in September, or you can get the latest copies of gnome-online-accounts, gnome-documents and libzapojit to try it out.