Why do some want to get rid of GTK2 and all applications that depend on it?

Posted Jan 17, 2026 19:42 UTC (Sat) by anton (subscriber, #25547)
In reply to: Maybe a hint? by lunaryorn
Parent article: Debian discusses removing GTK 2 for forky

Touch input: None of my devices have touch input. And why would adding touch input cause a backwards-incompatible change?

Multi-DPI setups: That certainly existed in 2002. In any case, why would it cause a backwards-incompatible change?

HiDPI: Why would that cause a backwards-incompatible change?

Plug and play was a buzzword in the 1990s, which PCI clearly having it and ISA gaining PnP features. By 2002 PnP was universally available. I don't see that this has any relevance GTK. Maybe you are thinking of hotplugging, which has been available since at least USB (introduced 1996, and also widely available in 2002). Why would that cause a backwards-incompatible change?

Compositing: I don't know what that's about, but why would it cause a backwards-incompatible change?

2D acceleration became important with Windows in the 1990s, and in 1994 or so the 2D-accelerated S3 928 was the thing to have, and in 1995 the Matrox Millenium was introduced and was the next thing to have (and I bought it). By the end of the 1990s, 3D acceleration became available, and I bought a Voodoo 3 3000 in 1998. By 2002, 3D acceleration was widely available. In any case, why would 2D or 3D acceleration cause a backwards-incompatible change to GTK?

Plugging in a mouse with a serial interface does not require rebooting. Plugging or unplugging a PS/2 mouse is supposedly safer if you power down the computer (we did some live unplugging and plugging and never had a hardware failure from that, though). Plugging or unplugging a USB mouse does not require rebooting. USB has available since 1996.

And 32-bit colours, which you did not mention were also available in 2002 (already the Matrox Millenium supported that).

What are reasons for backwards-incompatible changes?

You need to support something that does not fit in the existing interface, and where you cannot provide the existing interface in addition to the new one. Did this happen with GTK3 and GTK4? One would hope that they learn from that and make the interfaces sufficiently flexible that this does not happen again. One would hope that they have learned that lesson by GTK2.
Contrasting example: The Linux kernel was released in 1991, when many of the hardware features you mentioned really were not there yet, yet there is no backwards-incomatible Linux2, Linux3, or Linux4 (admittedly, the removal of a.out in Linux 5.1 eliminated backwards compatibility with binaries created up to 1998).
You have a cool new idea for the interface to your clients, that you want to pursue, and you don't want to do the footwork to integrate it in a backwards-compatible way. From the descriptions I have read here, that's what happened with GTK3, and again with GTK4. That's ok, but then you need to be aware that you have now created an additional maintenance cost to someone: Either someone maintains the old and all the cool-new-idea interfaces, or the clients of your library will need to be rewritten for one of your cool new interfaces at some point, or these clients will become unusable (a cost to the users of these applications).

That being said, what is broken with GTK2 that some people want to eradicate it and all the applications that depend on it?

to post comments

Why do some want to get rid of GTK2 and all applications that depend on it?

Posted Jan 17, 2026 20:08 UTC (Sat) by pizza (subscriber, #46) [Link] (5 responses)

> Touch input: None of my devices have touch input. And why would adding touch input cause a backwards-incompatible change?

You are in a tiny, tiny, tiny minority.

But it's not that "touch input" is backwards-incompatible in of itself, but rather that touch-oriented UIs need to be designed differently to be effective.

> Multi-DPI setups: That certainly existed in 2002. In any case, why would it cause a backwards-incompatible change?

No, the entire system ran at a single DPI. And $deity help you if you tried to change it from 96dpi.

> HiDPI: Why would that cause a backwards-incompatible change?

Because traditionally, the goal of higher resolution was to cram more onto the screen (making things smaller for a given screen size), whereas "HiDPI" is about keeping visual elements the same perceptual size on different resolution (but identically sized) screens.

The reason it's not "backwards compatible" is that this requires your UI layouts to be specified in resolution-independent units (as opposed to, say, "pixels").

> That being said, what is broken with GTK2 that some people want to eradicate it and all the applications that depend on it?

Other than the minor detail that many(most?) GTK2 applications directly rely on X11-isms.. like having a fixed dpi for all UI elements, there's the more fundmental problem about how GTK2 has been unmaintained for over five years. It turns out that folks complaining aren't stepping up to maintain anything.

Why do some want to get rid of GTK2 and all applications that depend on it?

Posted Jan 17, 2026 20:38 UTC (Sat) by Wol (subscriber, #4433) [Link]

> But it's not that "touch input" is backwards-incompatible in of itself, but rather that touch-oriented UIs need to be designed differently to be effective.

And that many devices are now "touch only". Personally, I think that's awful, and my windows computers are configured to disable touch if a mouse is present (which it almost always is). I wish I knew how to do it on linux.

But at the end of the day, we now live in a world where "touch only" is the norm :-(

Cheers,
Wol

Why do some want to get rid of GTK2 and all applications that depend on it?

Posted Jan 17, 2026 23:06 UTC (Sat) by anton (subscriber, #25547) [Link] (3 responses)

You are in a tiny, tiny, tiny minority.

As demonstrated by the resounding success of Windows 8 (pre 8.1) designed for touch, right?

But it's not that "touch input" is backwards-incompatible in of itself, but rather that touch-oriented UIs need to be designed differently to be effective.

We have a lot of applications that are designed for being effective with a mouse, and are not going to be redesigned. They work for those who use a mouse. Why is there the drive to get rid of them?

No, the entire system ran at a single DPI. And $deity help you if you tried to change it from 96dpi.

X11 fonts (bitmap fonts, not faces) come in 75dpi and 100dpi sizes (and that has already been so around 1990, i.e., long before GTK2), and I can tell every application instance which font it should use. And I certainly had 107 dpi on my laptop screen (1024x768 on a 12" screen) and ~10 dpi on the 120" screen that the projector displayed on. I did not need $deity, it all worked fine.

"HiDPI" is about keeping visual elements the same perceptual size on different resolution (but identically sized) screens.
The reason it's not "backwards compatible" is that this requires your UI layouts to be specified in resolution-independent units (as opposed to, say, "pixels").

Such units may be a good idead if you have a clean slate, but if you have a legacy of applications to support, then the idea of applying a scale factor to UI elements looks better to me (and I have seen options for setting such scale factors in various GUIs).

Of course the clean slate looks very desirable to programmers compared to the mess of dealing with backwards compatibility, but for a library it means abandoning you client base, and making it clear to all prospective clients that they better steer clear of your library.

Experience tells us that GTK4 and Wayland will be abandoned when the next shiny cool idea comes around.

there's the more fundmental problem about how GTK2 has been unmaintained for over five years.

And the problem with that is what? I use lots of software that has been unmaintained for over five years.

Why do some want to get rid of GTK2 and all applications that depend on it?

Posted Jan 18, 2026 4:20 UTC (Sun) by pizza (subscriber, #46) [Link] (2 responses)

> As demonstrated by the resounding success of Windows 8 (pre 8.1) designed for touch, right?

We're up to Windows 11 now; the overwhelming majority of the devices sold with it have touch screens.

> We have a lot of applications that are designed for being effective with a mouse, and are not going to be redesigned. They work for those who use a mouse. Why is there the drive to get rid of them?

You mean besides the fact that the overwhelming majority of devices sold for the past decade lack any other input mechanism other than a touchscreen, and even if you plug a physical keyboard+mouse into one, they can't run those applications anyway?

> X11 fonts (bitmap fonts, not faces) come in 75dpi and 100dpi sizes (and that has already been so around 1990, i.e., long before GTK2), and I can tell every application instance which font it should use. And I certainly had 107 dpi on my laptop screen (1024x768 on a 12" screen) and ~10 dpi on the 120" screen that the projector displayed on. I did not need $deity, it all worked fine.

Your projector and laptop screen both claimed to be 96dpi as far as X and all of its applications are concerned. Change that at your own peril; nearly every X11-native application will break because non-font elements will not scale, resulting in text that either overflows or is truncated by its bounding box. (most notably in menu bars, single-line input forms and labels). Ironically the applications that don't horribly break bypass X11 font rendering (along with most other X11 primitives) entirely, relying instead on client-side rendering and just slinging the resultant pixmaps to the X server. (In other words, the same paradigm that Wayland is built around)

> Such units may be a good idead if you have a clean slate, but if you have a legacy of applications to support, then the idea of applying a scale factor to UI elements looks better to me (and I have seen options for setting such scale factors in various GUIs).

Congratulations, you just answered your own question about why toolkit APIs needed to be restructured. And again, there's not currently a way to have X11 apply a blanket scale factor on an application-by-application (much less element-by-element) basis.. because dpi is a global, immutable attribute.

> Experience tells us that GTK4 and Wayland will be abandoned when the next shiny cool idea comes around.

Experience tells us that GTK4 will be directly supported for at least a decade, and closer to two. Meanwhile, while Wayland won't last forever, it will remain relevant for at least the next two decades due to numerous long-support-lifecycle industries (eg automotive) basing their software stacks around it.

Why do some want to get rid of GTK2 and all applications that depend on it?

Posted Jan 19, 2026 4:37 UTC (Mon) by jcelerier (guest, #181931) [Link] (1 responses)

> Your projector and laptop screen both claimed to be 96dpi as far as X and all of its applications are concerned. Change that at your own peril; nearly every X11-native application will break because non-font elements will not scale, resulting in text that either overflows or is truncated by its bounding box. (most notably in menu bars, single-line input forms and labels). Ironically the applications that don't horribly break bypass X11 font rendering (along with most other X11 primitives) entirely, relying instead on client-side rendering and just slinging the resultant pixmaps to the X server. (In other words, the same paradigm that Wayland is built around)

I've been using Xft.dpi to adjust DPI since 2014 and it's always worked for me, even for apps that AFAIK end up calling raw X11 drawing primitives (for instance PureData which uses TCL/Tk). Do you have example of broken apps?

Why do some want to get rid of GTK2 and all applications that depend on it?

Posted Jan 19, 2026 12:47 UTC (Mon) by pizza (subscriber, #46) [Link]

> I've been using Xft.dpi to adjust DPI since 2014 and it's always worked for me,

Xft.dpi is purely for font scaling, it leaves the X server's core dpi setting unchanged. It also only affects truetype (==scaleable) font rendering, not "classic" X11 fonts which are fixed bitmaps.

See: https://unix.stackexchange.com/questions/596765/is-x-dpi-...