Maybe a hint?

Posted Jan 15, 2026 10:43 UTC (Thu) by lunaryorn (subscriber, #111088)
In reply to: Maybe a hint? by rgmoore
Parent article: Debian discusses removing GTK 2 for forky

I don't think Gtk did breaking releases just for the sake of it.

Gtk 2 was released in 2002, and it's reasonable to assume that its entire architecture modeled contemporary hardware. Let's remember how computers looked back then: No touch input, no multi-DPI setups, no HiDPI, few plug and play setups, no compositing, etc. I don't think we even had hardware accelerated 2D drawing back then. That was a time when you had to reboot your computer to plug a new mouse.

From this perspective I find it amazing that Gtk 2 actually managed to hold out for twenty years.

It's perhaps also worth noting that in between Gtk 2 and Gtk 4 Qt, which has orders of magnitude more resources to maintain backwards compatibility, did three breaking major releases. Qt 3 was released end of 2001, and now we're at Qt 6. And that doesn't even consider the vast amount of changes C++ has seen since 2002.

to post comments

Maybe a hint?

Posted Jan 15, 2026 14:07 UTC (Thu) by geert (subscriber, #98403) [Link] (7 responses)

Sure Linux had hardware accelerated 2D drawing in 2002! FWIW, Precision Insight demoed hardware accelerated 3D in 1999.

I didn't dig too deep, but even in 1994, XFree86 supported hardware acceleration on graphics chipsets from eight vendors:
https://www.nic.funet.fi/pub/linux/doc/html/install-guide...

Maybe a hint?

Posted Jan 15, 2026 14:43 UTC (Thu) by paulj (subscriber, #341) [Link]

There was hardware 3d before that I think. John Carmack was working on Matrox G100 / G200 drivers for Linux in the late 90s (was that the start of Linux DRI? Or GLX? I don't remember the project(s)). 2D acceleration was definitely well established. The Matrox Mystique, Millenium and S3 Virge and some others had 2D accells.

Maybe a hint?

Posted Jan 15, 2026 14:51 UTC (Thu) by LionsPhil (subscriber, #121073) [Link] (5 responses)

Additionally, by 2002, USB was pretty mature for keyboards and mice.

A helpful snarky way to remember how old USB is is that the "plugging in a USB printer causing a BSOD on stage" Windows gaffe was showcasing new '98 features. :)

Maybe a hint?

Posted Jan 16, 2026 7:54 UTC (Fri) by lunaryorn (subscriber, #111088) [Link] (4 responses)

I believe the story on Linux is a bit different. According to Wikipedia Linux only got proper USB support with kernel 2.4 in 2001, and X.org didn't support hotplugging until much later (Xorg 1.4 in 2007). So presumably, when Gtk 2.0 was released in 2002, USB input was the hot new thing on Linux, and hotplugging was not a thing for years to come.

Maybe a hint?

Posted Jan 16, 2026 8:24 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (3 responses)

That's a little misleading - support for USB input devices had landed in fairly early 2.2 (my recollection is that Linus got irritated with the existing rudimentary USB support and replaced it with something he wrote, but this is my recollection from over 25 years ago - but I certainly had Linux running on USB-based Macs before 2.4 came out), and while hotplug wasn't directly supported by X, all mouse input was multiplexed into /dev/mice and all keyboard input went to the current terminal, so hotplug devices would just about work as long as X was configured appropriately.

Maybe a hint?

Posted Jan 16, 2026 17:53 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link] (2 responses)

I think the big thing that came with 2.4 was devfs, which made hot plug practical. In 2.2, /dev was static and had to be populated with every conceivable device when it was created, which wasn't really compatible with hotplug. With devfs, /dev became dynamic and could add new devices as they were connected. I certainly remember following 2.4 development very carefully because USB support was insufficient for ordinary desktop use. Fore example, I had to use my fancy new optical mouse through a USB-to-PS2 converter because USB support wasn't good enough.

Maybe a hint?

Posted Jan 19, 2026 10:27 UTC (Mon) by taladar (subscriber, #68407) [Link] (1 responses)

Devfs didn't last very long though before it was replaced by udev.

Maybe a hint?

Posted Jan 19, 2026 19:15 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

And eventually got replaced back by the new devfs :)

I actually used devfs way into 2010 on my own device (a RouterBoard) by porting the devfs. It was easier with a minimal userspace than udev.

Maybe a hint?

Posted Jan 15, 2026 20:32 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

The low level of GTK3 was mostly fine. It was the overall UI/UX experience of GNOME3 that went off the rails.

They threw away literally EVERYTHING and had this "dynamic activities" model: https://youtu.be/S0lIpCntwv8?t=309

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) [Link] (6 responses)

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?

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