GTK-2-on-3 wrapper

Posted Jan 17, 2026 8:33 UTC (Sat) by gioele (subscriber, #61675)
In reply to: Maybe a hint? by wtarreau
Parent article: Debian discusses removing GTK 2 for forky

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

to post comments

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.