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!

Commentaires

  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?

    RépondreSupprimer
    Réponses
    1. Hi, maybe I didn't understand your project but it looks very similar to GtkBuilder to me, am I wrong? https://developer.gnome.org/gtk3/stable/GtkBuilder.html

      Supprimer
    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.

      Supprimer
    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?

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

    RépondreSupprimer
  3. Hi, how that work compares with Emeus https://github.com/ebassi/emeus ?

    RépondreSupprimer
  4. Here how Lollypop handle responsive design with current GTK 3.22:
    https://www.youtube.com/watch?v=9OgoBXjyQ4A

    RépondreSupprimer
  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.

    RépondreSupprimer
  6. We developed a widget at Endless that you might find useful: https://github.com/endlessm/eos-knowledge-lib/blob/master/js/app/widgets/spaceContainer.js

    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.

    RépondreSupprimer
  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.

    RépondreSupprimer
    Réponses
    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.

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

    RépondreSupprimer

Enregistrer un commentaire

Posts les plus consultés de ce blog

The Path to GNOME Games 3.26

Games received a non-negligible amount of changes that you will find in 3.26. These changes can be big as much small, and more are to come!Building the Games CollectionGames presents your games collection and if everything goes as expected, it does so without the need of any input from you. From an implementation point of view it sounds simple to do, just ask Tracker “Hey, gimme all the games” and it’s done. If only it was that simple! 😃 The system has no idea which files represent games and which doesn’t, but it can associate a MIME type to each file thanks to shared-mime-info. shared-mime-info already had a few video game related MIME types and we added a lot more such as application/x-genesis-rom.That done, we can query Tracker for files having specific MIME types that we know to often represent video game files. Unfortunately, each of these files doesn’t necessarily represent a game and a game isn’t necessarily represented by a single file: some files may be invalid and hence rep…

GNOME Games 3.24

GNOME 3.24 will be out in a few weeks and with it will come Games 3.24. This new version will offer a few new features and many refinements, some of which have been implemented by new contributors theawless and Radhika Dua, kudos to them!Find how to get the latest nightly and (soon) stable Flatpak versions of Games on its web page.A Libretro Core Descriptor SpecificationIn its version 3.22, Games stopped using a hardcoded list of well known Libretro cores and instead looked for the right one to run a game by parsing files describing their corresponding Libretro core's capabilities. These files came from the libretro-super repository and were slightly modified to better suit Games' needs.The concept was great but the format of these files proved to be not very well suited for the job: many information were not useful to Games, some information it needed were lacking, the syntax wasn't specified, complex cases like firmwares were implemented in a messy way, some useful infor…