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
  7. This is really great. Love your work!

    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 an element from t…

Adaptive GNOME Web

I started working on making GNOME Web work well on the Librem 5; to be sure it fits a phone's screen I want the windows to fit in a 360 points width, which is definitely small. To do so I started with the advices from Tobias Bernard to make Web have two modes that I named normal and narrow. The normal mode is Web as you know it, while the narrow mode moves all buttons from the header bar but the hamburger menu to a new action bar at the bottom, letting the windows reach yet unreachable widths. Web autmatically adapting to small sizes. And now, with device rotation on a tablet. The code is overall ready, I still need to break it into reviewable bits before submitting it upstream.Once this get merged:we want to not show tabs in narrow mode and instead to display a popover listing the available pages,we want to make the search bar shrink rather than to limit the minimum window size,we consider migrating away from the application menu model.A quick layout test of the pages popover. P.S.…