Accéder au contenu principal

One Widget to Adapt Them All and to The Librem 5 Port Them

In my previous article I shared my plans to help porting existing GTK+ applications to Purism's upcoming Librem 5 phone without having to fork them. This article will present the GTK+ widget I developed for Purism to make this happen.

For more information on what Purism is working on for the Librem 5, please check Nicole Faerber's latest article.

C'est pas sorcier

The underlying idea is to allow applications to dynamically switch between the two main GNOME application layouts: a row of panels — each panel being the view of an element from the previous one — and a stack of panels. The goal isn't to changes applications using the stack paradigm but the ones using the row one, allowing them to reach smaller sizes and to be usable on constrained sizes while keeping their initial paradigm and design when the screen space is sufficient. The development cost to port the applications to this adaptive design should be as low as possible.

To achieve that, I wrote a GTK+ widget which acts similarly to a GtkBox when there is plenty of space for its children, but which adapts automatically and acts similarly to a GtkStack when there isn't, displaying only one of its children. I called this widget HdyStackableBox and it is being developed for the libhandy library.

The widget's minimum size is the minimum size of its visible child, matching the minimum size of a GtkStack. The widget's natural size is the sum of the natural sizes of its children, matching size of a GtkBox.

The threshold below which the widget will turn into a stack is the sum of the natural sizes of its children — hence, when allocated less than its natural size the widget will turn into a stack. In box mode, the minimum size allocated to the children is their natural size, combined to the previously defined threshold this allows a collapsing priority property to naturally emerge as, when nesting HdyStackableBoxes, the wrapping one will collapse into a stack before the nested one. This is what I consider the biggest feature of this widget: this widget offers an adaptive behavior with no magic number involved.

Features of HdyStackableBox

HdyStackableBox is still in development, here is a list of already implemented features.

  • Mode: box or stack.
  • Adaptive design.
  • Box homogeneity.
  • Stack homogeneity.
  • Mode transition:
    • None and slide animations.
    • Its duration is settable up to 250ms (like GtkRevealer).
  • Child transition:
    • None animation.
    • Its duration is settable up to 200ms (like GtkStack).
  • Named children.
  • Unlimited children.

Here is a list of features that may or may not be implemented later.

  • Draw on its own windows: the animations currently causes the widget to draw out of its allocated space.
  • Mode transition: slide over animation, similarly to hiding the left panel of DzlBin.
  • Child transition: slide animation.
  • Orientation: this is partially implemented.
  • Text direction: right-to-left languages should be supported.

Gimme! Gimme! Gimme!

The code is currently hosted at my fork of libhandy. You can test the widget by cloning the repo in GNOME Builder, moving to the wip/aplazas/stackablebox branch, building and running the project.

To test the widget in real world applications, I quickly tested it on GNOME Contacts. It is mostly ported and should work just fine, if not don't hesitate to report any strange behavior to me but only regarding the adaptive port.

GNOME Contacts with adaptive design and full navigation in stack mode

Adaptive GNOME Contacts running on an i.MX 6 development board and a phone screen.

I also tested it on Geary, there is no navigation implemented yet but it's a good test case of a complex UI with a HdyStackableBox nested into another.

Geary and its nested stackable boxes.

Adaptive design is useful even on the desktop for Geary.

Sorry for the graphical glitches, I suspect they are caused by a mix of out-of-bound drawings and improper/missing resizing and redraw queries, they will be fixed. You can test these by yourself by cloning, building and running these branches in GNOME Builder.

Keep in mind that my libhandy, GNOME Contacts and Geary forks are expected to disappear at some point in the future, and that I don't guaranty their quality as this is all in development.

/* TODO */

As you can see in the list of unimplemented features and in the videos, there is still a lot to do, polishing the widget to make it featureful and bug free will take time, probably a few more weeks of focused development. In the meantime, feedback from designers on what this widget could be used for and — perhaps more importantly — what it shouldn't be used for is more than welcome!

Once ready, what about turning it into GtkStackableBox? That would help its adoption by important applications like Settings, which probably don't want an extra dependency just for a widget but which could then work on the Librem 5 without yet another major redesign.

Commentaires

  1. Awesome work! I had my doubts about using gtk instead of kirigami but they are dissapearing quickly. I hope once the component will be finished a lot of apps take advantage of it. Btw, the repos links are inverted.

    RépondreSupprimer
  2. I really love your work.

    Getting a GtkStackableBox will bring lot of benefits to Desktop applications, like for users using their applications divided on screen. With addaptive designs generally available, developers can help users to monitor more than one application at the same time, like keep their mail open on one side while use other application in a bigger size.

    Adding a bolean developer_mode property in your widget, can help developers to test their addaptive design, by forcing a Phone size.

    RépondreSupprimer
  3. I am absolutely looking forward consuming these new widgets in Calendar and To Do once they land in upstream GTK! *Please* try and get this new widget in GTK :)

    RépondreSupprimer
  4. I'm doing this by hand in Lollypop but will migrate to your widget as soon as it's available in mainstream GTK, very useful, good job!
    https://www.youtube.com/watch?v=9OgoBXjyQ4A

    RépondreSupprimer
  5. I'm posting this here because Nicole's blog doesn't have comments. Since you are using Wlroots, please try to support redshift for color temperature adjustment!

    RépondreSupprimer
  6. There are a lot of things in the likes of handy and dazzle (and granite) that would it would be great to have merged into Gtk4 much as happened prior to Gtk3 release

    RépondreSupprimer

Enregistrer un commentaire

Posts les plus consultés de ce blog

GTK+ Apps on Phones

As some of you may already know, I recently joined Purism to help developing GTK+ apps for the upcoming Librem 5 phone . Purism and GNOME share a lot of ideas and values, so the GNOME HIG and GNOME apps are what we will focus on primarily: we will do all we can to not fork nor to reinvent the wheel but to help allowing existing GTK+ applications to work on phones. How Fit are Existing GTK+ Apps? Phones are very different from laptops and even tablets: their screen is very small and their main input method is a single thumb on a touchscreen. Luckily, many GNOME applications are touch-friendly and are fit for small screens. Many applications present you a tree of information you can browse and I see two main layouts used by for GNOME applications to let you navigate it. A first kind of layout is found in applications like Documents, I'll call it stack UI : it uses all the available space to display the collection of information sources (in that case, documents), clicking a

libhandy 0.0.10

libhandy 0.0.10 just got released, and it comes with a few new adaptive widgets for your GTK app. You can get this new version here . 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 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 he bottom of the window: HdyView

Boxes' hardening sprint: two weeks in

Finishing my 4th year of CS studies I spent the last two weeks working hard on the report and the presentation of the project my colleagues and I worked on all the semester long: creating the Stibbons multi-agent system programming language and development environment. I am very proud of what we accomplished and I’ll probably present it to you in the upcoming weeks. =) Planning the port of Boxes' installation wizard to GtkAssistant All this work unfortunately let me little time to work on Boxes, but I nonetheless took some time to look at how its installation wizard is implemented and planned how to port it to GtkAssistant. Boxes' installation wizard Currently, the wizard is ordered that way: WizardWindow WizardToolbar: the toolbar containing the navigation buttons Wizard: the stack of pages Most of the wizard’s intelligence seems to lie in Wizard and its pages, I’ll have to dig further into Boxes' code in order to fully understand how th