All posts by mclasen

App folder configuration

Continuing my 3.12 recap, this post is about gnome-software. I’ve done much less work on it this cycle than the previous one. All the heavy lifting has been done by Richard. The one feature that I did add to gnome-software this cycle is app folder configuration.

GNOME SoftwareGNOME has been moving away from hierarchical menus for applications. It is problematic for many reasons. One problem is the need for a global, hierarchical classification (‘categories’) – the world is just not that simple, and applications don’t always fit into these predefined categories. Another problem is that menus don’t really scale beyond a single level of submenus or beyond more than 10-15 items per menu.   Not to mention that menus are hard to use on touch devices.

The transition from menus and categories to a scrollable grid for applications was pretty much complete in 3.10. But there is still some need for grouping of related applications, and this is where app folders come in. In 3.10, we provided predefined folders for ‘Utilities’ and ‘Sundry’.

In 3.12,  we are adding an easy way for users to create  their own folders.  We chose to add this feature in the application that always shows you a list of all installed applications anyway, gnome -software.

Installed appsThe alternative would be do implement this directly in the shell overview, but that would be pretty complicated, requiring either a selection mode or complex drag-and-drop, so we decided not to do this (at least for now).

Once you’ve selected the apps you want to group, you can select an existing folder in the ‘Add to Folder’ dialog:

Add to FolderOr you can click on the ‘+’ button to create a new folder:

New FolderOnce you have done this, the new dialog will show up in the GNOME shell overview:

OverviewAnd that’s all there is to this feature!

If you are not using gnome-software, the app folder configuration is also available via gsettings.  It is using relocatable schemas, so the required gsettings command-line looks a little different from the usual, and may be worth showing. First,

$ gsettings get org.gnome.desktop.app-folders folder-children
['Utilities', 'Sundry', 'Feet']

will show you the list of defined app folders. Then,

$ gsettings get org.gnome.desktop.app-folders.folder:/org/gnome/desktop/app-folders/folders/Feet/ apps
['dconf-editor.desktop', 'd-feet.desktop', 'devhelp.desktop']

will list the apps that are in the folder named ‘Feet’. The folder schema has a few more settings that you can explore or change with similar commands.

The new gnome-initial-setup

As the development cycle for 3.12 is winding down, I want to take the time to look back at some of the things I’ve worked on this cycle.

First, gnome-initial-setup has received a design overhaul that I’ve implemented together with Jasper. The pages now look a lot more uniform and polished. We use headerbars and we are consistently using list boxes for selections.

The first few pages are about language, region and input.

Language

Region

Input

The network page is skipped if a we have a connection.

Wifi

The timezone map is now properly sized.

Timezone

Online accounts have been moved earlier.

Online Accounts

This lets us pick up avatar and name for the account page from a configured online account, which is something we’ve wanted to do all along:

Account

The on-screen keyboard works during initial setup now:

On-Screen Keyboard

Setting a password has been separated from the account creation:

Password

And thats all!

Summary

Getting the details right

I’ve recently explained how GTK+ does quite a few things for you out of the box.

  • Theming ? You got it.
  • Accessibility ? You’re covered.
  • Keynav ? Sure.

But as it turns out, default implementations can’t always provide the optimum. To go from an application that works ok to one that is gets the details just right, some fine-tuning may be required.

Today, I want to take a look at a few examples of such fine-tuning for keyboard navigation, in particular around lists. I hope this also shows how you can learn tricks and borrow well-working code from other applications. If you ask yourself

How did they do this, and why does my app not do this ?’

look at the source! We all do it, and don’t feel bad about it.

Why lists ? They come in all sizes and shapes, from straightforward and simple to interactive and complex. It is no wonder that GtkTreeView with its supporting classes has around 40000 lines of code.

Connected lists

My first example is about segmented lists of controls. These have become more common in gnome-control-center panels. Here is the accessibility panel:

Accessibility panelWhen you use the arrow keys to navigate among the buttons, the default behavior of GTK+ is to stop when you come to the edge of the container. But in the situation above, we all would expect the focus to jump from the first list to the second.

Thankfully, GTK+ emits a ::keynav-failed signal when you use the arrow keys to go beyond the end of a container, and we can use this to our advantage:

static gboolean
keynav_failed (GtkWidget        *list,
               GtkDirectionType  direction,
               CcUaPanel        *self)
{
  CcUaPanelPrivate *priv = self->priv;
  GList *item, *sections;
  gdouble value, lower, upper, page;

  /* Find the list in the list of GtkListBoxes */
  if (direction == GTK_DIR_DOWN)
    sections = priv->sections;
  else
    sections = priv->sections_reverse;

  item = g_list_find (sections, list);
  g_assert (item);
  if (item->next)
    {
      gtk_widget_child_focus (GTK_WIDGET (item->next->data), direction);
      return TRUE;
    }
...
}

We use this signal handler on every list:

g_signal_connect (list, "keynav-failed",
                  G_CALLBACK (keynav_failed),
                  self);

And thats all! Here is a quick video of this in action (I’m repeatedly using the Down arrow key):

If you watch closely, you’ll notice another fine point of this example – we scroll the panel to keep the focus location visible. This functionality is built into GTK+’s container widgets, and we activate it by setting a focus adjustment on the box that contains all the lists:

adjustment = gtk_scrolled_window_get_vadjustment (GTK_SCROLLED_WINDOW (panel));
gtk_container_set_focus_vadjustment (GTK_CONTAINER (content), adjustment);

These code examples were taken from cc-ua-panel.c in gnome-control-center.

The same trick is also used in the gnome-control-center overview to allow arrow keys to move between several icon views.

Tabbing out

GTK+ uses the Tab key to connect all active UI elements into a focus chain.  The default behavior of GtkListBox is to put all rows into the focus chain – that makes a lot of sense for the previous example where each row contains controls such as buttons, or brings up a dialog when activated.

Sometimes, it is more natural to treat a list as a single item in the focus chain, so that the next Tab key press takes you out of the list. The list content will still be keyboard-accessible with the arrow keys.

A sidebar like in gnome-logs is an example where this makes sense:

A sidebar listTo achieve this behavior, we can override the focus vfunc of our GtkListBox subclass:

widget_class->focus = gl_category_list_focus;

with a function that special-cases Tab key presses:

static gboolean
gl_category_list_focus (GtkWidget *listbox, 
                        GtkDirectionType direction)
{
  switch (direction)
    {
    case GTK_DIR_TAB_BACKWARD:
    case GTK_DIR_TAB_FORWARD:
      if (gtk_container_get_focus_child (GTK_CONTAINER (listbox)))
        {
          /* Force tab events which jump to
           * another child to jump out of the
           * category list.
           */
          return FALSE;
        }
...
}

This code example was adapted from gl-categorylist.c

A back button

The last example does not involve lists, but a simple Back button. For example, gnome-software has one:

A back buttonYou will probably add a mnemonic to the button label, so it can be activated using the Alt-B shortcut. But your users will also expect the Back key on their keyboard to work, and many will probably try Alt-Left as well, since that is what they use in their web browser.

Key events in GTK+ bubble up from the focus widget, and until they are definitively handled by one of the intermediate containers, they eventually reach the toplevel GtkWindow. Therefore, to make the Back key work regardless where the focus currently is, we can override the key_press vfunc of the window:

static gboolean
window_key_press_event (GtkWidget *win,
                        GdkEventKey *event,
                        GsShell *shell)
{
...
  state = event->state & 
       gtk_accelerator_get_default_mod_mask ();
  is_rtl = gtk_widget_get_direction (button) == GTK_TEXT_DIR_RTL;

  if ((!is_rtl && state == GDK_MOD1_MASK &&
        event->keyval == GDK_KEY_Left) ||
      (is_rtl && state == GDK_MOD1_MASK && 
        event->keyval == GDK_KEY_Right) ||
      event->keyval == GDK_KEY_Back)
    {
      gtk_widget_activate (button);
      return GDK_EVENT_STOP;
    }

  return GDK_EVENT_PROPAGATE;
}

If you pay attention to detail, you’ll notice that we use Alt-Left or Alt-Right, depending on the text direction — your Hebrew-speaking users will appreciate.

This code example was taken from gs-shell.c

On portability

There has been a lot of hand-wringing lately about how GNOME is supposedly forcing everybody to use systemd, and is not caring about portability.

That is of course not true at all.

Theory

Portability has been a recurring topic in the discussions of the GNOME release team (of which I am a member). We don’t make it a secret that modern Linux is the primary target that we are developing on and for. And we are aiming to use technologies that are best suited for the task at hand – which has led us to use more of the services implemented by systemd (some of which are direct descendants of earlier mechanisms shipped with gnome-settings-daemon).

But we are happy for everybody who wants to try GNOME on other platforms, and we have a strong interest in making GNOME work well there.

Reasonable patches to help with this are always welcome. The shape of those patches can vary from case to case: it could be reduced functionality, alternative backends, or a shim that puts systemd-like interfaces in place.

Practice

To show that these are not just empty words, here is a screenshot of GNOME running on FreeBSD:

GNOME on FreeBSDThe screenshot was provided by Ryan Lortie, who has done a lot of work on making jhbuild work on FreeBSD.

And here is a video showing GNOME running on OpenBSD, courtesy of Antoine Jacoutot:

GNOME on OpenBSD

Pointers

Go here  to read more about the release team position on portability.

If you are interested in helping out with making and keeping GNOME running on more platforms, this page is another good place to go. It lists platforms that are well supported by GLib.

Connecting the old with the new

I spent some time recently on modernizing the look of  the application chooser in GTK+. Here is how it will look in 3.12:

appchooser-new

appchooser-fail2

As you can see, I added a search button, as it was showing up in the mockup I was working from.  Of course, I had to come up with some answer for how to make it do the expected thing. The application chooser has always supported typeahead search: if the focus is on the list, just type to search. This is an old feature of GtkTreeView:

appchooser-typeahead

But we’ve recently added a nice new search bar widget to GTK+, and I wanted to see if I can’t combine the old treeview search with the new search bar:

appchooser-searchbarThankfully, it turns out that this is very easy. You just  call

gtk_tree_view_set_search_entry (treeview,
                                search_entry)

and all the right things are happening automatically behind the scenes. The full commit that does this in the app chooser looks a bit more complicated, but that is mainly because the app chooser is broken up into separate dialog and widget classes.

If you have a treeview that could benefit from a more explicit search option, you should consider doing something like this.

Here is a video that shows this in action:

A quick glance at GNOME 3.11.5

The GNOME 3.12 cycle was a little lighter in terms of screenshot-friendly feature work, with lots of effort going ‘under the covers': Wayland porting, developer documentation improvements, application installation infrastructure, etc. But I still managed to find a few things worth showing while smoketesting the 3.11.5 release this morning.

System status refinements

The system status area was all new in 3.10, so naturally, there was some follow-up to incorporate feedback that we’ve received on the new implementation. One point that was raised by many people is that they rely on the system status area to know about wired network connections. So, we’re bringing it back:

System status refinements

 

Airplane mode improvements

Another thing we’re correcting is the subpar integration of airplane mode in the wifi submenu. In 3.10, the ‘Select network’ dialog was unaware of airplane mode. Now, it offers to turn wifi on when needed:

Wifi selectionDesktop file actions

In another corner, applications can now provide ‘static actions’ in their desktop files. This is useful for actions that are meaningful when the application is not running, mainly alternative ways to launch the application.

These actions are now included in the right-click menu of applications in the overview:

Application actionsIt looks like this in the desktop file:

[Desktop Action NewDocument]
Name=New Document
Exec=libreoffice --writer
X-TryExec=oowriter

Thats all! GNOME 3.11.5 will be out later today, so you can try these things out for yourself.

Attention to details

In this post, I want to highlight some of the small things GTK+ does for your application that you may have never noticed, or haven’t thought about. GTK+ has many of these, and toolkit developers loose sleep over them, so you don’t have to.

Keyboard navigation

It is important that the entire UI of your application can be reached with the keyboard − a mouse may not be around, or the user may not be able to use it. To this end, GTK+ lets you move the focus between widgets using the Tab key. The order in which widgets are reached is referred to as focus chain. In most situations, GTK+ comes up with a reasonable order by itself. But you can always force a different order with gtk_container_set_focus_chain().

Focus

Apart from tabbing, GTK+ also provides directional navigation using the arrow keys, mnemonics to directly move the focus to specific widgets, and accelerators for actions in menus. Mnemonics are keyboard shortcuts that use Alt in combination with an underlined character; accelerators often involve the Ctrl key.

Internationalization

Most applications are translated in many languages. But you may have never seen how your application looks in one of its translations. You should check it out. In languages with a right-to-left writing direction, it is not enough to replace all strings by their translations; it is also expected that the interface adapts to the change in direction.

We casually call this flipping, and most GTK+ container widgets do it automatically when appropriate.

FilechooserResoohcelifIn the rare case where flipping is not appropriate (say, if you are dealing with maps, and you want to show an arrow that indicates West), you can override the locale-derived direction by calling gtk_widget_set_text_direction().

Baseline alignment

The human eye is very sensitive to jumps of the baseline as it moved over a line of text. If that happens, it leaves a ransom note feeling. The most common case where this can be a noticeable problem in UIs is when controls are layed out in a grid with labels.

Baselines GTK+ has the ability to align widgets with respect to their baseline. To take advantage of this, you must set the valign property of the widgets to GTK_ALIGN_BASELINE.

Accessibility

AccessibilityIn modern UIs, many controls use just an icon. This looks nice and saves space, but it might be a problem if you can’t actually see the contents of the screen very well. A screen reader can only help if it knows how to translate those icons into meaningful text. For many standard icon names (such as the icons shown in this example), GTK+ does this automatically. If you are using other icons, you should use atk_object_set_name() to set a name on the accessible of the button.

And now, popovers

GTK+ has seen a fair bit of new development over the last year. We’ve gained new containers such as list box and flow box and stack and new widgets like the search bar, places sidebar, header bar and action bar. The Wayland backend has come a long way, and we’ve gotten hi-dpi support and client-side decorations.

One feature that we haven’t gotten until today, and that has been on the wishlist for a while is popovers. 

Popovers are transient views that are somewhat in the middle between menus and dialogs. The are transient like menus – you don’t expect to keep them open for more than a single action. On the other hand, they can display arbitrary information and allow input and interaction like a dialog. One big advantage of popovers over menus is that they are much easier to interact with using touch.

These are of course very popular in mobile UIs, but it makes a lot of sense to have them available on the desktop as well.

Inside GTK+, we’ve had some nascent support for this style of UI with the touch selection work that Carlos Garnacho merged almost exactly a year ago.

Touch selection

Carlos has now generalized this work and turned it into a full-blown GtkPopover implementation. Since the work has only been merged today, I can’t really link to API documentation yet. But the API is very easy: you create a popover with gtk_popover_new(). It is a container like any other, so can just pack your content as usual. And you control its visibility with gtk_widget_show(). The direction of the ‘tail’ that points to the parent widget can be set with gtk_popover_set_position().

popover = gtk_popover_new (parent_widget);
gtk_container_add (GTK_CONTAINER (popover), my_content);
gtk_widget_show (popover);

We don’t yet have any users of popovers inside GTK+ apart from touch selections, but I expect that to change soon.

Many thanks to Carlos for getting this done!

Even more client-side decorations

The design for the new GTK+ color chooser had its buttons at the top from the beginning. When I implemented it, we just didn’t have client-side decorations and headerbars to realize this aspect of the design. Now we do, so we can complete the redesign of the color chooser:

Of course, it doesn’t make sense to do this only for one dialog, so the other dialogs that are included in GTK+ have received a similar facelift.

Apart from recovering vertical space (do you really need the typical dialog title “Open a file” to remind you that the window you are looking at is a file chooser ?), the main advantage of this change is consistency: There is always a control at the top right corner of a window to close it.

These new-style dialogs are also more consistent with applications using client-side decorations, like all the modern GNOME applications. But of course, GTK+ is not just a toolkit for GNOME, therefore we’ve done our best to introduce this change in a way that does not upset our other audiences.

The use of header bars in GTKs built-in dialogs is controlled by a setting, GtkSettings::gtk-dialogs-use-header, whose default value is FALSE.  As usual, the setting is backed by an Xsetting, Gtk/DialogsUseHeader. For 3rd party dialogs which are derived from GtkDialog, header bars can be enabled with the construct-only property GtkDialog::use-header-bar. Buttons that are added with gtk_dialog_add_button() or its variants are automatically relocated to the header bar. And if you are manually adding content to the action area, we will keep it visible.

You can try these dialogs with the development branch GTK+. If you are using running gnome-settings-daemon, it is as simple as overriding the Xsetting with:

gsettings set org.gnome.settings-daemon.plugins.xsettings \
    overrides "{'Gtk/DialogsUseHeader':<1>}"

The changes in GTK+ master are not 100% complete yet, I expect that we will make some adjustments to the dialogs.

Client-side decorations, continued

Time to talk again about client-side decorations (csd).

buttonsA while ago, I’ve talked about themes and what adjustments they need to make csd windows look respectable. Back then, I avoided the most thorny issue with csd: window controls. Window controls are the close, minimize, and maximize buttons that window managers have traditionally put into their titlebars.

Early in the GNOME3 era, we tried to save some vertical space by simply hiding titlebars when the they containing important information. This is particularly relevant for maximized windows on small screens, where vertical space is scarce. This was the hide-titlebar-when-maximized property. As we soon found out, the lack of a reliable close button in the upper right corner with this approach is a big problem for many users.

More recently, we’ve switched to a different approach: Reclaim the area that has traditionally been taken up by the titlebar for applications. To this end, we’ve introduced the GtkHeaderBar widget, which lets applications use this space for its own purposes. This was pretty successful. Many GNOME applications are making good use of this now, e.g. nautilus:

headerbar2These custom titlebars require window managers to have support for mwm hints, so we can convince them to not show their own titlebar. These hints have traditionally been well-supported in window managers — so far, the only problematic case we’ve found is xfwm4.

As you can see in that nautilus screenshot, there is a window control — a close button in the upper right corner, which will stay in there as the window is maximized, addressing the problem with hidden titlebars. Since the header bar is application area, the close button is only shown if the application author explicitly allows this by setting the show-close-button property.

This is a nice and clean story, but of course, things never stay that simple.

Window decorations, and in particular window controls are a traditional area for distro differentiation and theming (you may still remember the discussion about Unity buttons), and unsurprisingly, we soon got requests to allow some themability.

In 3.10, GTK+ added a style property, gtk-decoration-button-layout, to let themes control the button layout. At first, we only respected this property for  client-side titlebars that were not explicitly added by the application. This turned out to be insufficient and opened us up to some (justified) criticism about the (lack of) consistency with client-side decorations.

So, shortly before christmas, I’ve gone back and redone the configuration mechanism one more time, changing it to a combination of a setting, GtkSettings::gtk-decoration-layout, and a regular property, GtkHeaderBar::decoration-layout, whose default value is taken from the setting. The settting is backed by an xsetting, Gtk/DecorationLayout.

This adds more flexibility: Themes can influence the default value of the setting (via their settings.ini file), distributors can set a default value and users can override it via the xsetting (hopefully soon from gnome-tweak-tool).

But application developers / designers have the last word: they can hardcode the property to just show a close button on the left, if the application design does not accommodate wild variations in the header bar layout. Or they can read the setting and make adjustments, e.g. for the case of split header bars, as can be seen in the new gedit design:

geditIf you want to experiment with this, GTK+ ships a two interactive testcases, testtitlebar and testsplitheaders:

TestcasesThis is a difficult area for a toolkit. We find ourselves between multiple competing interests:

  • Users expect consistency across applications
  • Distributors expect applications to adapt to whatever environment they are running in
  • Application designers want applications to appear as designed, and not wildly different depending on the environment

I hope that the mechanism that is in place now is flexible enough to allow balancing these interests, and to make GTK+ applications work well in different environments.

One last thing I should mention in this context is the GNOME application menu. GtkApplicationWindow has had a built-in fallback for other environments since day one, but it is not that great.

Application menu fallbackIt uses a mostly-empty menubar, which adds to the vertical space problems, and it duplicates the application name. In GTK+ 3.12, the fallback menu will be integrated in the header bar, and look much more natural:

Better fallbackEnjoy.