Libadwaita: Splitting GTK and Design Language

Original Article ↗ Hacker News Discussion ↗

GNOME’s move to separate its Adwaita design language into a dedicated libadwaita library, leaving GTK4 as a more generic cross‑platform toolkit, is reigniting long‑running tensions over the direction of the Linux desktop. Supporters see a cleaner split that lets GTK focus on core widgets while desktops define their own “design language” layers; critics argue it entrenches GNOME‑specific look‑and‑feel, breaks theming and compatibility for non‑GNOME environments, and continues a pattern of disruptive API and UX changes that fragment the ecosystem. Across comments, broader concerns surface about developer trust, accessibility, and whether major projects like GNOME adequately balance design vision with interoperability and user feedback.

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.