Disclaimer: my intended audience is the reader, not specifically the person I’m replying to. (m4){4}, your comment about Inkscape merely triggered a brain dump; this isn’t a message specifically to you.

Toolkits are a spectrum.

On the one hand, you have ones that are libraries that do things like providing widgets and event handling - writing a table widget or a drop-down with submenus and check items entirely from scratch is a PITA.

As the feature set line increases, you get things like support for copy/paste, desktop clipboard integration, mime type clipboard handling, and - eventually - abstracted filesystems and integrated DBs that allow you to port to other platforms without writing and maintaining a bunch of OS-specific code yourself. At that end, it’s no longer a library that your program uses, but a platform or framework upon which you’ve implemented your application. On the one end, you could theoretically replace the library with another with a minimum of fuss, depending on how well you abstracted your library use; on the other end, it’s impossible to change platforms without essentially rewriting the entire application.

Qt tends to be more of a platform. GTK tends to be more of a library. They’re both pretty close to the center. X and Wayland are both libraries. The trade-off is a lot of convenience for hard dependency. I have no knowledge of Inkscape’s GUI implementation, but I’d bet they have what amounts to their own internal GTK implementation; and that probably took a lot of effort to write, and it’s code they have to maintain (probably by now it doesn’t take much developer time, being mostly static - especially for X, which doesn’t often change).

I really, really hate platforms. The convenience is almost always a Trojan Horse of bugs, unexpected API breakages, lock-in, and hidden costs. You can’t easily fix the bugs, because they’re deep in the toolkit and you have to maintain a fork until upstream accepts (if ever) your PR. You can only hope that API breakages are announced well in advance and accompany a test bed so you can prepare your application; and still, it’s someone else creating work you have to address on their schedule. Lock-in is the worst, though, because if the platform disappears, changes usage costs or licensing, goes on a different direction than you want to – any number of reasons for wanting to change platforms – you almost always have to completely rewrite your application from scratch. The hidden costs are bad, too: platforms tend to be things that are really fun and easy as long as you stay in a box, but the moment you need it to do something it doesn’t know about, it’s 100x harder than if you were just using a library - and sometimes, it’s almost impossible to do what you want to.

You’re damned if you do, and damned if you don’t. Don’t use a GUI library, and you spend a lot of time writing code that is incidental to the solution you really wanted to write. Use a platform, and you get up and running fast, and can focus on the problem; but you’ll inevitably pay a painful cost later.

I find interesting parallels between the low-level API <-> platform spectrum and compiled <-> evaluated programming language spectrum. Compiled, type checked, rigid PLs have an up-front cost, and often a smaller but still significant ongoing development cost: they’re usually slower to write. Interpreted, loosely typed languages, OTOH, you can often whip out code and solutions faster than it takes to even properly set up a project in a compiled language (some exaggeration there, but still). But you pay the cost down the road, in runtime performance, dependency breakages, finding type errors at runtime, all that jazz.

My rule of thumb on these thing is: if I don’t expect the program to be used long enough to encounter the long-term costs, use the easy solution: the framework, or the scripting language. If it’s something that I expect to be using long term, go as low level with libraries and toolkits, and use a type safe, compiled language.

There is no TL;DR. It’s just a brain dump, worth exactly a much as you paid for it.

The issue with “talking Wayland directly” is that Wayland as a definitive entity that all Wayland hypervisors understand or can run doesn’t exist. Wayland has a very tiny base library and everything else is implemented by the specific running hypervisor. And those can do things under the hood very differently to each other, with APIs that can be mostly compatible but differ in small details. So when you “talk Wayland directly” you have to say “this only runs on proton and hyperland but not sway and Mutter, but maybe on Weston” (just an example for a sentence) because that’s what you have tested and found that it works with your implementation or you have to implement all the different ways in which the Wayland implementations do their things (and maybe implement workarounds if one of them doesn’t implement a specific function (like HDR support or fractional scaling) at all. “Talking Wayland directly” is a huge pile of very basic level stuff that you have to implement and maintain and keep track of to change in case one of the implementations changes something in a newer version that is incompatible to your code oh and better implement it in a way so you are still compatible with the old code too because that will be in use for the next 100 years on Debian.

There is a very good reason to use a framework that handles all that stuff and provides the stable API and functions that the display manager should provide (and what it did with X for decades).