4 ms·

Why stick with such an old codebase? Wouldn't it just make sense to start a new Rust project with editable shaders. It could have an extensible, clean task-base

by dsego 10y ago

Why stick with such an old codebase? Wouldn't it just make sense to start a new Rust project with editable shaders. It could have an extensible, clean task-based interface, instead of the antiquated control room with lots of buttons and switches. Or maybe even a dispatcher/server with protocols to send graphic commands from UIs to different image processors.

dsego 10y ago
I asked an honest question. But it seems a gobject codebase in C must be a delight to work with. And then you wonder why it takes long to implement new stuff.
- chris_wot 10y ago
  It might have been an honest question, but so many of us here have seen this sort of thing and the disaster it entails that it's not at all surprising people were downvoting...
coldtea 10y ago
Because above a level of experience developers know that "rewriting" is not some magic bullet, and can in fact take you years back and kill your project. And rewriting in a still-developing language du jour, even less so.
Freak_NL 10y ago
> Why stick with such an old codebase? Because it works and is a full-featured mature product. Nothing stops anyone from starting a new project based on modern insights and try to become the next GIMP, but such an endeavour does not imply that this project should simply stop its development. The GIMP is used by a lot of people in their daily work or for personal projects. It's free, it works, and most crucially, it's here today. Why abandon it? I'm sure the GIMP developers will adopt new technologies as they come along when and where they make sense (they are migrating to GTK3, and who knows, perhaps some parts will be replaced by Rust code).
- mathw 10y ago
  There's a push by some GNOME community people to get a good story going for using Rust with GNOME tech, which could be applied to GIMP, being based also on GObject and GTK+. Hopefully that will work out.
  - uabstraction 10y ago
    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.
zo1 10y ago
I upvoted you for your ambiguous sarcasm. GIMP has been around for a very long time, and I'm sure they're considered all the options with the amount of developer time they have available.
woliveirajr 10y ago
I like this post about it: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
krapp 10y ago
It's free software - so feel free to start your Rust fork whenever you like, and update us on your progress.
chris_wot 10y ago
Try it and find out :-) Believe me, the stuff The Gimpnhave been doing for over a decade and a half now is not easy, and I can assure you full rewrites never quite go as expected. Still, I suspect it would be fun for someone to try!
anthk 10y ago
Because Rust is no fucking mature and old and experienced C developers know security and safety pretty well. Also, gobject, albeit odd, wraps a lot over stdio.

by dsego 10y ago

dsego 10y ago

I asked an honest question. But it seems a gobject codebase in C must be a delight to work with. And then you wonder why it takes long to implement new stuff.

chris_wot 10y ago
It might have been an honest question, but so many of us here have seen this sort of thing and the disaster it entails that it's not at all surprising people were downvoting...

coldtea 10y ago

Because above a level of experience developers know that "rewriting" is not some magic bullet, and can in fact take you years back and kill your project. And rewriting in a still-developing language du jour, even less so.

Freak_NL 10y ago

> Why stick with such an old codebase? Because it works and is a full-featured mature product. Nothing stops anyone from starting a new project based on modern insights and try to become the next GIMP, but such an endeavour does not imply that this project should simply stop its development. The GIMP is used by a lot of people in their daily work or for personal projects. It's free, it works, and most crucially, it's here today. Why abandon it? I'm sure the GIMP developers will adopt new technologies as they come along when and where they make sense (they are migrating to GTK3, and who knows, perhaps some parts will be replaced by Rust code).

mathw 10y ago
There's a push by some GNOME community people to get a good story going for using Rust with GNOME tech, which could be applied to GIMP, being based also on GObject and GTK+. Hopefully that will work out.
- uabstraction 10y ago
  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.

zo1 10y ago

I upvoted you for your ambiguous sarcasm. GIMP has been around for a very long time, and I'm sure they're considered all the options with the amount of developer time they have available.

woliveirajr 10y ago

I like this post about it: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

krapp 10y ago

It's free software - so feel free to start your Rust fork whenever you like, and update us on your progress.

chris_wot 10y ago

Try it and find out :-) Believe me, the stuff The Gimpnhave been doing for over a decade and a half now is not easy, and I can assure you full rewrites never quite go as expected. Still, I suspect it would be fun for someone to try!

anthk 10y ago

Because Rust is no fucking mature and old and experienced C developers know security and safety pretty well. Also, gobject, albeit odd, wraps a lot over stdio.