Maybe a hint?

Posted Jan 15, 2026 23:18 UTC (Thu) by rgmoore (✭ supporter ✭, #75)
In reply to: Maybe a hint? by pizza
Parent article: Debian discusses removing GTK 2 for forky

I don't mean to sound overly critical! I've written software that is still in use long, long after I ever expected it to remain in service, and it's 100% luck that I wrote it in a language that hasn't required endless maintenance since then. I'm definitely a member of the crew who wants to write it and forget it. I wish that we could stop the constant churn of underlying technologies that drive the development churn. I understand that we can't stop this stuff completely- we do learn things that need to be incorporated into language and tool design- but there seems to be an awful lot that is driven by software companies' desire to sell new licenses rather than anything that genuinely needs updating.

to post comments

Maybe a hint?

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

In GTK's case, the deprecations/removals are because there are just a handful of GTK core developers/maintainers. They cannot reasonably maintain forever all APIs, which is understandable.

However as noted in an earlier comment, a "gtk-legacy" and "gtk-future" modules could be created to provide partial compatibility layers.

Maybe a hint?

Posted Jan 18, 2026 12:00 UTC (Sun) by pizza (subscriber, #46) [Link] (3 responses)

> In GTK's case, the deprecations/removals are because there are just a handful of GTK core developers/maintainers. They cannot reasonably maintain forever all APIs, which is understandable.

Absolutely.

>However as noted in an earlier comment, a "gtk-legacy" and "gtk-future" modules could be created to provide partial compatibility layers.

Maintained by whom, exactly? The same folks that "understandably" removed all of the old APIs because they don't have the resources to "reasonably maintain them forever"?

If that maintenance is by some other mythical entity, what stops them from simply maintaining GTK2 in its current state?

Maybe a hint?

Posted Jan 19, 2026 3:11 UTC (Mon) by swilmet (subscriber, #98424) [Link] (2 responses)

What I had in mind is that big projects like Linux Mint, MATE, Ardour, GIMP and others would coordinate some efforts to ease GTK usage outside what GTK maintainers are able to provide. What I've achieved for text editor projects is a few libgedit-* modules. For example libgedit-amtk for extending GTK 3 with an alternative API to create menus and toolbars (because GtkUIManager is deprecated in GTK 3).

Maybe a hint?

Posted Jan 19, 2026 17:08 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

What I had in mind is that big projects like Linux Mint, MATE, Ardour, GIMP and others would coordinate some efforts to ease GTK usage outside what GTK maintainers are able to provide.

I don't know that those projects have the resources to do what you're suggesting. For example, GIMP is still in the process of fully transitioning from their old libraries to GEGL. They don't have spare developers to devote to maintaining old GTK; if they had more resources they'd want to devote them to speeding up development of their graphics stack rather than maintaining underlying libraries. I agree that maintaining those old libraries would be a worthwhile task, but I don't think projects that are already operating on a shoestring are the place to find the resources.

Maybe a hint?

Posted Jan 20, 2026 9:23 UTC (Tue) by swilmet (subscriber, #98424) [Link]

At this point we can say that probably almost all FLOSS desktop components are under-resourced, except rare exceptions (thinking about Qt, Blender, LibreOffice maybe?).