Accéder au contenu principal

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 the collection will focus on it, displaying its content stacked on top of the collection and letting you go back to the collection with a Back button. Applications sporting this layout are the most phone-enabled ones as phone apps typical following a similar layout. Some polish may be needed to make them shine on a phone but overall not so much. Other applications using this layout are Music, Videos, Games, Boxes…

A second kind of layout is found in applications like Contacts, I'll call it panel UI: it displays all the levels of information side-by-side in panels: the closer the information is from the left, the closer it is from the root, each selected node of the information tree being highlighted. This is nice if you have enough window space to display all this information and focus on the leaves isn't required by the user as it allows to quickly jump to other elements of the collection. Unfortunately window space is rare on phones, so these applications would need to be adjusted to fit their screens. Other applications using this layout are Settings, Geary, Polari, FeedReader…

Of course, other layouts exist and are used, but I won't cover these here.

Stack UIs respond to size changes by displaying more or less of the current level of information, but panel UIs tend to seemingly arbitrarily limit the minimum size of the window to keep displaying all the levels information, even though some may not be needed. The responsibility of handling the layout ans sizes to display more or less of some levels of information is sometimes offloaded to the user via the usage of GtkPanel, who then has to manually adjust which information to hide or to display by changing the width of columns every time they need access to another information or when the window's size changes. A notable example of hurtful GtkPanel usage is Geary, which can be a bit of a pain to use half-maximized on a 1920×1080 screen.

Responsive GTK+ Apps

Panel UIs need to be smarter and should decide depending on the window's size which information is relevant to the user and should be displayed. As we don't want to replace the current experience but to extend it, the UIs need to respond to window size changes and explicit focus change requests.

One way of doing it would be to stack the panels one on top of the other to show only one at a time, adding extra Back buttons as needed, effectively switching the UI between panels and a stack.

Another one would be to have floating panels like on KDE Discover. I am not a fan of this method, but on the other hand I'm not a designer.

I expect that to make applications like Geary easier to use even on laptops.

Implementing GtkResponsiveBox

I will try to implement a widget I call GtkResponsiveBox. It contains two children displayed side by side when the box's size is above a given threshold and only one of them when the size is below it.

I expect this widget to look like a weird mix of GtkPaned and GtkStack, to be orientable and to have the following sizes:

  • minimal size = max (widget 1 minimal size, widget 2 minimal size)
  • natural size = widget 1 natural size + widget 2 natural size
  • threshold size = widget 1 minimal size + widget 2 minimal size

I am not completely sure yet how to implement it nor if this widget is a good idea overall. Don't expect anything working soon as it's the first time I subclass GtkContainer. I'll let you know how implementing the widget goes, but in the meantime any comment is welcome!

Thanks Philip for your guide detailing how to implement a custom container, it helps me a lot!


  1. My library, called libgreattao are information/action focused. In this library, you can set importance of action/information to the user. Maybe the same do for the widget?

    1. Hi, maybe I didn't understand your project but it looks very similar to GtkBuilder to me, am I wrong?

    2. It's similar to GtkBuilder in approach to allow to define UI in XML-like files, but it's go rather to allow users to define UI by creating window classes. Window classes contains templates and app telling to LGT "I support exit/cancel/ok/whatever action" and LGT creates labels, buttons and other widget. But, what is important due to my previous post, application can tell to LGT "save action is very important", so save action is placed in window menu and on toollbar. LGT places action additionally in toolbar, because it's very important. I suggest to teach GTK to do something similar, so app told GTK this button is important, so GTK will make it big and place at top of button list.

    3. Sorry for writing too many posts, but what about adding to GtkBuilder something like query tags, which will be similar to query selector from CSS?

  2. Don't reinvent the wheel. Use Kirigami.

  3. Hi, how that work compares with Emeus ?

  4. Here how Lollypop handle responsive design with current GTK 3.22:

  5. With emeus you could actually set different set of restrictions and then one could add a state so depending on this state you would transition between different restrictions this changing the layout. The animation part would be fun as we would have to animate between two layouts defined only implicitly. Looks like a fun widget to work on.

  6. We developed a widget at Endless that you might find useful:

    It's written in JS and for some time it's been on my list to rewrite it in C and propose to include it in GTK as "GtkOverflowBox". Mathias and Benjamin seemed to be positive about this plan, but I'm lacking time.

    Emeus is also worth checking out. Probably this widget could be rewritten easier with Emeus, but you should talk to Emmanuele Bassi about that.

  7. PS. I don't know if you were aware, and I know you didn't make the video, but the video cover frame showed up as the cover image for your post in my RSS reader... it's a bit alienating to see that wallpaper on the top of a professional programming post, so it's probably worth selecting a different image (like your A-B diagram) as the cover image.

    1. Many made a similar comment on the quality of the background of the video (that I indeed didn't make) and I agree: I just dropped it, thanks.

  8. What are the the main apps you plan to optimise for the phone?

  9. Thanks for sharing nice blog.

  10. Nice Blog! I love your writing style keep posting more
    Python course in Hyderabad


Enregistrer un commentaire

Posts les plus consultés de ce blog

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

Moving the Blog

I am moving this blog to greener lands: . The existing articles will remain here on Blogger, and new articles will land on the Plume instance.