3 ms·

C is also a relatively simple procedural language which constrains the APIs that e.g. GTK can offer. This makes working with GTK in its native platform uglier t

by Macha 5y ago

C is also a relatively simple procedural language which constrains the APIs that e.g. GTK can offer. This makes working with GTK in its native platform uglier than Qt, but does mean alternative bindings can build their own more ergonomic abstractions on top of it. Qt on the other hand is very much a C++ OOP style, so if there's an impedance mismatch representing that in your language, as is the case for Rust, C or Go, then it gets much harder to do. The C++ bindings do present difficulty of course, but you can see from e.g. PyQT that if the pattern works in your language it's one that can be overcome.

nu11ptr 5y ago
This a good point, and I agree that C++ made sense at the time as it is much richer for creating a GUI. I've never tried to use GTK C GObject interface, but I've seen some snippets and it looked nasty to me. However, in hindsight, it at least makes it fairly easy to create bindings for and I suspect many (most?) don't use the GTK C API but some other language bindings, so it turned out to make a lot of sense I think.
tialaramex 5y ago
And there are other choices Qt makes that are unfriendly for, say, Rust too, QString is defined in terms of UTF-16 code units, which was probably a pragmatic choice when Qt was younger, but inconvenient today since of course Rust can't necessarily be confident this is actually Unicode (I tried but was unsuccessful in figuring out what CXX-Qt does about that) and on non-Windows systems Rust doesn't have a built-in representation for this "a bunch of UTF-16 code units" pseudo string, yet on Windows you probably do want that structure because it is what other Windows stuff expects such as the File APIs...
- Macha 5y ago
  Although Windows has gone backwards on that a little with the current recommendation being to use the *A APIs with a UTF-8 code page: https://docs.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page https://docs.microsoft.com/en-us/windows/apps/design/globali...

by Macha 5y ago

nu11ptr 5y ago

This a good point, and I agree that C++ made sense at the time as it is much richer for creating a GUI. I've never tried to use GTK C GObject interface, but I've seen some snippets and it looked nasty to me. However, in hindsight, it at least makes it fairly easy to create bindings for and I suspect many (most?) don't use the GTK C API but some other language bindings, so it turned out to make a lot of sense I think.

tialaramex 5y ago

And there are other choices Qt makes that are unfriendly for, say, Rust too, QString is defined in terms of UTF-16 code units, which was probably a pragmatic choice when Qt was younger, but inconvenient today since of course Rust can't necessarily be confident this is actually Unicode (I tried but was unsuccessful in figuring out what CXX-Qt does about that) and on non-Windows systems Rust doesn't have a built-in representation for this "a bunch of UTF-16 code units" pseudo string, yet on Windows you probably do want that structure because it is what other Windows stuff expects such as the File APIs...

Macha 5y ago
Although Windows has gone backwards on that a little with the current recommendation being to use the *A APIs with a UTF-8 code page: https://docs.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page https://docs.microsoft.com/en-us/windows/apps/design/globali...