Maybe a hint?

Posted Jan 15, 2026 12:20 UTC (Thu) by pizza (subscriber, #46)
In reply to: Maybe a hint? by pabs
Parent article: Debian discusses removing GTK 2 for forky

>I wonder why people without lots of resources for maintenance add dependencies on projects with a reputation for fast development and backwards incompatibility in the first place.

Uh, GTK2's (directly supported) lifecycle was just shy of two decades. Actively-supported GTK3 is well over a decade into its lifecycle, and GTK4 is about five years in.

If that is "fast development" then I'd hate to see what you call anything its more "modern" contemporaries.

to post comments

Maybe a hint?

Posted Jan 16, 2026 13:20 UTC (Fri) by wtarreau (subscriber, #51152) [Link] (2 responses)

Maybe what's missing is a "gtk2-on-3" wrapper that presents gtk2 API and semantics from gtk3 ?

GTK-2-on-3 wrapper

Posted Jan 17, 2026 8:33 UTC (Sat) by gioele (subscriber, #61675) [Link] (1 responses)

> Maybe what's missing is a "gtk2-on-3" wrapper that presents gtk2 API and semantics from gtk3 ?

That's kind of hard to do because GKT 2 and GTK 3 are paradigmatically different. It is not just a matter of updating a couple of functions from a deprecated API to a new one. For example the base "class" GtkObject is gone and pretty much all APIs related to custom widgets or surface drawing have been removed and replaced by Cairo.

And even if a GTK 2 to GTK 3 wrapper were possible, a GTK 3 to GTK 4 is categorically impossible (or possible only in very limited cases) because the API for the main event loop has changed. (And all the styling is fundamentally different, so an application would look seriously broken with widgets all over the place.)

A GTK 2-to-3 wrapper only would buy us a few years before GTK 3 is fully abandoned upstream and we are back to the same discussion.

Compatibility layers

Posted Jan 18, 2026 9:39 UTC (Sun) by swilmet (subscriber, #98424) [Link]

The GTK project removes *all* deprecated API in the next major version. So to ease the port, compatibility layers could be created for some features.

For example GtkTreeView (tree and list widget, quite a complex beast) is deprecated in GTK 4, so it'll go away in GTK 5. GtkTreeView could be maintained in a separate module to still provide that API for GTK 5.

The same for GtkUIManager (deprecated in GTK 3 and so removed from GTK 4). It could be maintained for GTK 4 as a compatibility layer.

Perhaps it's time to create a gtk-legacy module. Classic desktop environments (Cinnamon and its X-apps, or MATE) would benefit from it.

Another, complementary way would be a gtk-future module, back-porting some new APIs to a previous major version.