4 ms·

While this would be awesome (and progress is underway), what GTK+ needs even more than additional language bindings is documentation and literature. I consider

While this would be awesome (and progress is underway), what GTK+ needs even more than additional language bindings is documentation and literature. I considered Rust for my current project, but passed it on due to the frontier nature of the GTK+ Rust bindings. I ended up using C++ instead, and even there the documentation is extremely limited. You get a basic intro that shows the most trivial use of the important widgets, and a class/api reference, and that's it. There are no books that I'm aware of that cover GTK3 (forget about GTKmm-3), client side decorations, or theming, and GTK4 is right around the corner. With the current state of documentation, learning GTK+ is impossible unless you are willing to dive into dozens of other people's projects in multiple programming languages to figure out how all the pieces come together. The lack of literature also makes it hard to know the difference between good, idiomatic constructs (within the context of Gobject/GTK+), and hacks which work by coincidence. I get the feeling many GTK+ based projects suffer from lack of manpower, and I'm pretty sure this is why.

rleigh 10y ago
Likewise. It took me weeks to figure this out when I learned GObject/GTK+ back in the early 2000s. I ended up writing my own tutorial on the subject due to the existing documentation being so utterly lacking (https://gitlab.com/rleigh/ogcalc https://gitlab.com/rleigh/ogcalc is its current home). I later ported all of my GObject-C code to C++; GObject has few redeeming qualities. It's a good example of "just because you can, doesn't mean you should". Yes, you can do OO in C; no, it's not a good idea. It's the wrong tool for the job, and you should use a more appropriate tools. Manually constructing vtables, manually casting all type information away, manually propagating exceptions and creating closures etc. It doesn't take long to realise that this is all pointless make-work. Just use C++. It has classes, inheritance, exceptions and proper type safety, all built in. What takes several hours with GObject-C takes just a few minutes with C++, and... there are zero bugs. With GObject-C, all that hand-crafting of vtables and other fiddly details are a source of subtle bugs; the compiler won't pick up on a lot of stuff you can get wrong while the C++ compiler does it all for you. This is something which becomes increasingly bad when you try to refactor--it may have been correct and then be subtly incorrect, and you won't realise. When I ported all this to C++, it uncovered a few nasty and obscure bugs which had been hidden for years. All this adds up to why many GTK+ projects lack manpower. Writing, maintaining and extending these codebases are a Sisyphean task. Unfortunately, the "C at all costs for all situations" mentality driving much of this (and I was guilty of such an attitude before I discovered that C was not the be-all and end-all of languages) prevents them being moved to more maintainable languages despite it being pretty straightforward to do so (I've done it for several codebases). Back in the mid-2000s I was employed to write a commercial application using GTK+; I used GTKmm and the other C++ bindings. Even then, it was an exercise in pain; bugs galore at all levels and poor or nonexistent documentation; there's a reason lots of developers were and are abandoning it for Qt, and the documentation and quality of implementation are key factors in that. It's unfortunate because it didn't have to be that way. But in reality, using GTK+ doesn't make economic sense--it takes longer to produce something which is of inferior quality and harder to maintain, so it's both more expensive in developer time, and it's a poorer product for the end user. While it's now years since I used it seriously, I look at the current dropping of piles of functionality and APIs which have been around for two decades, and I wonder if they have even the slightest concern for the two decades of third-party code using this stuff. It's rhetorical; they clearly don't. Sad that hacking on the toolkit for its own sake has a much higher priority than using it to develop actual applications, but that's what it is.

rleigh 10y ago

Likewise. It took me weeks to figure this out when I learned GObject/GTK+ back in the early 2000s. I ended up writing my own tutorial on the subject due to the existing documentation being so utterly lacking (https://gitlab.com/rleigh/ogcalc https://gitlab.com/rleigh/ogcalc is its current home). I later ported all of my GObject-C code to C++; GObject has few redeeming qualities. It's a good example of "just because you can, doesn't mean you should". Yes, you can do OO in C; no, it's not a good idea. It's the wrong tool for the job, and you should use a more appropriate tools. Manually constructing vtables, manually casting all type information away, manually propagating exceptions and creating closures etc. It doesn't take long to realise that this is all pointless make-work. Just use C++. It has classes, inheritance, exceptions and proper type safety, all built in. What takes several hours with GObject-C takes just a few minutes with C++, and... there are zero bugs. With GObject-C, all that hand-crafting of vtables and other fiddly details are a source of subtle bugs; the compiler won't pick up on a lot of stuff you can get wrong while the C++ compiler does it all for you. This is something which becomes increasingly bad when you try to refactor--it may have been correct and then be subtly incorrect, and you won't realise. When I ported all this to C++, it uncovered a few nasty and obscure bugs which had been hidden for years. All this adds up to why many GTK+ projects lack manpower. Writing, maintaining and extending these codebases are a Sisyphean task. Unfortunately, the "C at all costs for all situations" mentality driving much of this (and I was guilty of such an attitude before I discovered that C was not the be-all and end-all of languages) prevents them being moved to more maintainable languages despite it being pretty straightforward to do so (I've done it for several codebases). Back in the mid-2000s I was employed to write a commercial application using GTK+; I used GTKmm and the other C++ bindings. Even then, it was an exercise in pain; bugs galore at all levels and poor or nonexistent documentation; there's a reason lots of developers were and are abandoning it for Qt, and the documentation and quality of implementation are key factors in that. It's unfortunate because it didn't have to be that way. But in reality, using GTK+ doesn't make economic sense--it takes longer to produce something which is of inferior quality and harder to maintain, so it's both more expensive in developer time, and it's a poorer product for the end user. While it's now years since I used it seriously, I look at the current dropping of piles of functionality and APIs which have been around for two decades, and I wonder if they have even the slightest concern for the two decades of third-party code using this stuff. It's rhetorical; they clearly don't. Sad that hacking on the toolkit for its own sake has a much higher priority than using it to develop actual applications, but that's what it is.