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.
It’s mostly right, though. Except that a platform often comes with best practices that can be easier to follow for things that need to be updated quickly, like security.
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.
It’s mostly right, though. Except that a platform often comes with best practices that can be easier to follow for things that need to be updated quickly, like security.