Libadwaita: Splitting GTK and Design Language

Original Article ↗ Hacker News Discussion ↗

Libadwaita and separation from GTK

  • Many see libadwaita as GTK returning to being a generic toolkit, with GNOME‑specific design moved out.
  • Some compare this to older “libgnome*” splits; others note that even then GNOME‑specific APIs were supposed to live outside GTK.
  • Supporters say this lets GTK be more cross‑platform and stable, while GNOME iterates on its own design language in libadwaita.

Theming and non‑GNOME desktops

  • A core complaint: libadwaita hard‑codes the Adwaita look, making GNOME apps harder to integrate visually with other desktops (KDE, XFCE, Cinnamon, etc.).
  • There are hacks/patches to make libadwaita themeable, but this is seen as a regression from GTK2/3 where global theming was easier.
  • GNOME defenders argue unrestricted theming frequently broke apps and that a consistent, locked‑down design is intentional.

GTK4 direction and API stability

  • Several long‑time GTK users criticize frequent breaking changes, removed widgets (e.g., GtkDialog, GtkMenuBar APIs, GtkSocket/Plug), and harder extensibility, claiming it imposes large porting burdens.
  • Others reply that many removed APIs were buggy, X11‑specific, or misdesigned; deprecations often lasted ~a decade; cross‑platform consistency and simpler internals justify removals.
  • Some non‑GNOME DE developers say GTK4 is now “GTK4+libadwaita for GNOME, bare‑bones GTK4 for everyone else,” forcing them to rebuild lost functionality.

Dialogs, menus, and design language

  • Confusion around GtkDialog/MenuBar: they’re deprecated/removed as widgets, but replacement patterns (GAction‑based menus, GtkAlertDialog, plain GtkWindow + modal flags) still exist.
  • GNOME‑specific libraries now encode button order, labels, and layout conventions, similar to platform HIGs on Windows/macOS.

Window decorations and UX choices

  • Contentious debate over client‑side decorations, headerbars, tray removal, and button placement.
  • Critics see these as hostile to non‑GNOME apps and power users; supporters say CSDs save space, trays weren’t needed, and many users prefer the simpler GNOME workflow.

Ecosystem fragmentation and alternatives

  • Multiple commenters link GNOME’s design and API decisions to the proliferation of GTK‑based DEs (Cinnamon, MATE, Budgie, Pantheon, Cosmic, etc.).
  • Others argue forks and diversity aren’t “wasted effort” but expressions of different UX goals; KDE’s high customizability is contrasted with GNOME’s strong opinions.
  • Some wish for or work on alternative toolkits (Qt, Rust/iced, libxapp, web/Flutter), but note this further multiplies integration/theming problems.

Developer relations and trust

  • Several users report long‑standing bugs, ignored or delayed patches, and hostile issue handling, leading them to abandon GTK/GNOME.
  • Others counter that maintainers are overworked volunteers, that expectations are too high, and that critics should fork or contribute rather than only vent.