HIG Libraries and GTK4

Details

• When: January 11th, between 17:00 UTC and 19:00 UTC
• Where: meet.gnome.org

Agenda

• Are there any pieces that should move from libhandy to gtk ?
• What things are hard or impossible to do in hig libraries because of missing plumbing or private apis in gtk ?

• What reasons do you have for requiring code for HIG patterns ChristianHergert

• Design patterns which are currently lacking support (old-ish review can be found here). Potential examples:

  • ListBox-based lists

  • In-app notifications
  • Drop-down lists
  • Tagged entries
  • Initial and empty states
• Is it even the direction we want to move forward with, as in would there be complaints later?

• Are there widgets to move from gtk to libhandy (e.g. GtkShortcutsWindow and stuff)

Notes

Proposal is to move some widgets out of GTK into a new libadwaita. This would replace existing libraries like libhandy and libdazzle.

Motivations from the GTK side:

• Reduces short-term APIs - allows more instability. means that they don't have to maintain APIs for short-term fashionable design patterns. goal is to reduce surface area in GTK
  • Examples include selection mode, in-app notifications. Didn't get implemented in GTK yet. Also shortcut windows: a GNOME-specific experiment which currently lives in GTK.
• Benjamin - Adwaita is GNOME-specific. Aren't needed by GTK. If all of the platform libraries want the same widget, it should go into GTK. Otherwise, it should go in the platform library. Some widgets have evolved; others are fairly static (eg. checkboxes).
• Matthias - we still need a theme for GTK.
• Benjamin - do we want GTK to be a more basic framework for building platform libraries (analogy to the web). Christian - counter example of qt quick/qml where they originally had no styling and weren't liked.
• Question of platform-specific libraries. eg. a Windows GTK theme.
  • Emmanuele - who will create their own extension library? XFCE in 5 years? It's reliant on a lot of other people doing a lot of work.
  • Of course, a lot (most) of apps just use their own individual styling across platforms.
• Would we pull the file chooser out of GTK? Emmanuele - no. We need to provide one.
• Allan: design team interests (well, his interests):
  • An easy way for app developers to implement our documented design patterns (from the HIG). Should be reasonably stable-ish.
  • A more experimental place where new ideas can be explored and developed before they land in the HIG library.
• Adrien/Tobias - we've also had a lot of new patterns come along that have evolved fairly rapidly, in the responsive/mobile/libhandy space. (Implication that we don't want to close the door to those patterns.)
• Allan: but then we also need to document what we're making available. Someone needs to be able to use the platfrom library and it not have unfinished/immature/obsolete/undocumented widgets in there. The developer platform needs to be a package.
• What's hard/impossible to do because of missing plumbing or private APIs in GTK?
  • Alexander: major issue is inconsistent input handling.
  • Daniel: main issues have been GNOME-ism in GTK. eg. Action areas in dialogs.
• Are there widgets to move from GTK ot libhandy?
  • Alexander: the problem is that Elementary are using libhandy. Would like to keep GNOME stuff optional. [ebassi screams. No, we're not going to that.]
  • Matthias: it's hard to do platform libraries that are cross-platform. ebassi - if multiple platforms use the same widget, they should go in GTK.
  • Adrien - there are 2 libhandy widgets that Elementary uses - the "deck" widget, which is fairly complex, and the avatar widget, which is simple but fairly seasonal.
  • Tobias - the main reason to use deck is that GTK lacks the backswipe gesture - if that were supported it could help. On the GNOME side we might want to experiment with some of this - that flux could make it difficult to get it into GTK right now.
• Christian: most things in dazzle should be done declaratively in future - no need for code.
  • Declarative UIs need a UI editor
  • Alexander - you also need an animation framework, in order to handle input without having to code it yourself (which is a lot of what libhandy is doing today). Example of the new tab widget - it's a lot of code.
• ACTION (Matthias): look at deck and stack, compare what they do and whether the differences can be reconciled.
• Adrien: one of the biggest outstanding questions is the future of Adwaita. Want to be able to force the theme for apps. Want a private api to recolour apps.
  • Emmanuele - GTK needs a fallback theme. There are other things we can do to expose the CSS as a resource.
  • Benjamin - potential for dependency problems between the version of adwaita in GTK and the version that libhandy wants to use.
  • Plan on libhandy side is to create libadwaita, based on the current libhandy, also including the Adwaita theme.
• Would libadwaita include the patterns from the HIG? It has some of them.
  • Allan - questions about how it will work - who will maintain it, what the process will be like for adding patterns, how long it will be supported for, where it will be developed, what the main communication channels will be.
  • ACTION: Adrien to write this up and share for feedback.
  • Emmanuele - will need to be a migration guide, for both existing libhandy users and for those who have custom implementations of the design patterns.
  • Matthias: the part of the proposal around themeing isn't clear enough for GNOME 40. Adrien: we won't do that for GNOME 40 - it's for the future.
  • It ought to be obvious how the library relates to the HIG and vice versa.
  • Matthias - how would we create new patterns and iterate on them if libhandy goes away. Would we create a new place to do that?
  • Adrien - new major versions every year, year and a half. Not afraid of deprecating things. Discussion about cadence of deprecations - Christian: you should give a cycle's notice for deprecations so app developers don't have to scramble to update.

Actions

• ACTION: Compare HdyDeck with GtkStack for similarities/differences

• ACTION: Outline the maintenance and design pattern inclusion/deprecation policies for libadwaita