The New libhandy 0.0.10

• About
• Latest Posts

Purism

Beautiful, Secure, Privacy-Respecting Laptops, Tablets, PCs, and Phones

Latest posts by Purism (see all)

• PureOS Crimson Development Report: October 2024 - November 14, 2024
• PureOS Crimson Development Report: September 2024 - October 16, 2024
• Quantum Safe Communication with Purism - September 23, 2024

Libhandy 0.0.10 just got released, and you can get this new version here. It comes with a few new adaptive widgets for your GTK app we’d like to tell you about:

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 one 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 the bottom of the window: HdyViewSwitcherBar (and we’d like to thank Zander Brown for the prototypes!).

The Squeezer

To complete the view switcher design, we needed a way to automatically switch between having a view switcher in the header bar, and a view switcher bar at the bottom of the window.

We added HdySqueezer; give it widgets, and it shows the first one that fits in the available space. A common way to use it would be:

<object class="GtkHeaderBar">
  <property name="title">Application</property>
  <child type="title">
    <object class="HdySqueezer">
      <property name="transition-type">crossfade</property>
      <signal name="notify::visible-child" handler="on_child_changed"/>
      <child>
        <object class="HdyViewSwitcher" id="view_switcher">
          <property name="stack">pages</property>
        </object>
      </child>
      <child>
        <object class="GtkLabel" id="title_label">
          <property name="label">Application</property>
          <style>
            <class name="title"/>
          </style>
        </object>
      </child>
    </object>
  </child>
</object>

In the example above, if there is enough space the view switcher will be visible in the header bar; if not, a widget mimicking the window’s title will be displayed. Additionally, you can reveal or conceal a HdyViewSwitcherBar at the bottom of your window, depending on which widget is presented by the squeezer, and show a single view switcher at a time.

Another Header Bar?

To make the view switcher work as intended, we need to make sure it is always strictly centered; we also need to make sure the view switcher fills all the height of the header bar. Both of these are unfortunately not possible with GtkHeaderBar in GTK 3, so I forked it as HdyHeaderBar to, first, make sure it does not force its title widget to be vertically centered, and hence to allow it to fill all the available height; and second, to allow for choosing between strictly or loosely centering its title widget (similarly to GtkHeaderBar).

The Preferences Window

To simplify writing modern, adaptive and featureful applications, I wrote a generic preferences window you can use to implement your application’s preferences window: HdyPreferencesWindow – and organized it this way:

• the window contains pages implemented via HdyPreferencesPage;

• pages have a title, and contain preferences groups implemented via HdyPreferencesGroup;

• groups can have a title, a description, and preferences implemented via rows (HdyPreferencesRow) or any other widget;

• preferences implemented via HdyPreferencesRow have a name, and can be searched via their page title, group title or name;

• HdyActionRow is a derivative of HdyPreferencesRow, so you can use it (and its derivatives) to easily implement your preferences.

The next expected version of libhandy is libhandy 1.0. It will come with quite a few API fixes, which is why a major version number bump is required. libhandy’s API has been stable for many versions now, and we will guarantee that same stability starting from version 1.0.