6 ms·

It's pretty ridiculous since GIMP is 22 years old and GEGL is 18 years old. In a lot of ways gimp feels like it's perpetually stuck as a clone of Photoshop 4.0

It's pretty ridiculous since GIMP is 22 years old and GEGL is 18 years old. In a lot of ways gimp feels like it's perpetually stuck as a clone of Photoshop 4.0 or 5.0. If it can finally get adjustment layers that will help somewhat. You can theoretically do almost everything in gimp that you can in photoshop, but since CS, photoshop has lots of functionality that makes things much easier (fewer steps), so the ergonomics of GIMP seem pretty bad in comparison now.

opencl 8y ago
Most of the bugs linked in the "we might do this at some point in the future" part of the roadmap are 15+ years old. Adjustment layers are supposedly coming in 3.2. Who knows how many years that'll take though.
- mschaef 8y ago
  Once they're done with adjustment layers, they'll get to this lower priority task: > Shape tool - Easily create circles, rectangles, N-side polygons, stars etc. (That's in the future list, and not planned for any of the next three releases. Not fully sure I understand that priority call...)
  - hiccuphippo 8y ago
    Personally I use Inkscape for that stuff, and it excels at it, and then export/import into Gimp. Cumbersome but it works.
    - rhizome 8y ago
      Inkscape has scripting as well, so maybe a lot of that cumber can be automated. I've never looked into it, but you can be sure a lot of google results will take the form of "can i automate [x] with inkscape?"
      - opencl 8y ago
        Or you can script GIMP to do it directly. GIMP in fact already includes a script for drawing shapes under Filters->Render->gfig. The UI could stand to be improved but the feature is basically already there.
        mschaef 8y ago
        And that's been there for quite a while... Sad reality is, people expect more. There's something satisfying about being able to click a 'draw shape' icon on a tool bar and then click and drag to draw the shape on a canvas. That's an expectation that dates back to at least MacPaint in 1984, and it's a huge difference from drawing a shape using a rendering plugin buried under three menu levels.
        rhizome 8y ago
        Even better!
  - prokoudine 8y ago
    The priorities are simple. GIMP is targeted for hi-end workflows. Your average matte painter or photographer doesn't usually need to draw a rounded-corners rectangle, but he sure needs adjustment layers. Hell, even the CHANDRA X-Ray observatory guys need adjustment layers for coloring their FITS files! So that gets a priority. What the 2018 report specifically says though is that most things from the 'Future' section can be done right now by a new interested developer. That includes drawing shapes.
    - mschaef 8y ago
      I still don't follow the prioritization, but thank you for your work on Gimp. I've used it on-again/off-again since version 0.54 (95-96), and it played a formative role in my own software career.
newnewpdro 8y ago
My understanding is there are very few people contributing to GIMP development. The only regular GIMP-related anything I see on planet.gnome.org comes from the ZeMarmot project. It's hard to progress anything without participation...
- mschaef 8y ago
  This is my understanding, as well. I don't know why it happened that way, but contributor mindshare really moved away from Gimp years and years ago. Other similar projects have been released and surpassed Gimp in feature compatibility in the time since Gimp has been released. Sad, really, given the important role Gimp played back in the late 90's. Gimp was initially the G in GTK, and was closely related to the foundations of Gnome. (And Gnumeric.... which, to my understanding, has the same sorts of issues as Gimp.)
  - jay_kyburz 8y ago
    I have read that there are few contributors because the current maintainers are a little hostile towards people who want to try and improve GIMP.
    - mikekchar 8y ago
      I had heard the same thing, but the article linked here seems to indicate a very healthy attitude towards cooperation. I wonder how much of our impression is appropriate at this point. Possibly the project is suffering from bad press than no longer applies? Here's to hoping, anyway!
      - antt 8y ago
        The whole gtk ecosystem smells off. I don't know why but projects that pick qt are by and large friendlier, better maintained and more successful. Back in the day I tried to port xournal to gtk3 and it was a nightmare because there was so much breakage between gtk2 and 3. So much so I gave up. By comparison porting my own stupid python scripts between major versions of qt was painless.
chongli 8y ago
Caveat: I have never looked at the source for the Gimp. I wonder how much of the slow pace of development can be attributed to technical debt? As such an old project, I would imagine a great deal of the code involves old compromises that no longer make sense on modern PCs. With such limited available developer time it can be really demoralizing to have to deal with that stuff. Moreover, with old APIs and languages you lose out on the productivity gains made by modern tech.
- slondr 8y ago
  This is definitely one of the bigger issues. Early on, GIMP adopted the Emacs development style of building a solid core of functionality in C combined with a REPL for a scripting language within which other features can be developed. Unfortunately they picked Lua instead of developing their own language like Emacs did. Lua is pretty notorious for having an absolutely abysmal implementation and is very hacky itself. It's also unfortunate that the GIMP team didn't have the same hardline commitments as the GNU devs to code correctness (GNU will often delay project releases long past their expected drop dates just to make sure the code is maintainable and nothing is hacked together - see the year-long delay in the release of IceCat Quantum for a recent example of this). This situation got even worse when the devs decided to abandon the graphical toolkit the whole thing was written in in version 0.60 to invent their own, which didn't even include bindings for the scripting language they themselves were working in...it soon became quite a time commitment for any major feature to be implemented because the code base just wasn't designed with futureproofing in mind. Eventually GTK grew out of scope for GIMP and became a GNOME project. Around this time large parts were rewritten again in glib when GIMP became a GNU thing. Add twenty years, and GIMP is essentially a giant steaming pile of hacks that never made sense in the first place, full of components that barely work on their own, much less together. It's a sad state of affairs, especially considering the project had so much potential back in the day. It could have been the Emacs of photo editing, but poor planning from the get-go dashed that possibility.
  - alexhutcheson 8y ago
    > Lua is pretty notorious for having an absolutely abysmal implementation Do you know of any blog posts or articles about this? I'd be curious to read more about what the problems with the implementation are.

opencl 8y ago

Most of the bugs linked in the "we might do this at some point in the future" part of the roadmap are 15+ years old. Adjustment layers are supposedly coming in 3.2. Who knows how many years that'll take though.

mschaef 8y ago
Once they're done with adjustment layers, they'll get to this lower priority task: > Shape tool - Easily create circles, rectangles, N-side polygons, stars etc. (That's in the future list, and not planned for any of the next three releases. Not fully sure I understand that priority call...)
- hiccuphippo 8y ago
  Personally I use Inkscape for that stuff, and it excels at it, and then export/import into Gimp. Cumbersome but it works.
  - rhizome 8y ago
    Inkscape has scripting as well, so maybe a lot of that cumber can be automated. I've never looked into it, but you can be sure a lot of google results will take the form of "can i automate [x] with inkscape?"
    - opencl 8y ago
      Or you can script GIMP to do it directly. GIMP in fact already includes a script for drawing shapes under Filters->Render->gfig. The UI could stand to be improved but the feature is basically already there.
      - mschaef 8y ago
        And that's been there for quite a while... Sad reality is, people expect more. There's something satisfying about being able to click a 'draw shape' icon on a tool bar and then click and drag to draw the shape on a canvas. That's an expectation that dates back to at least MacPaint in 1984, and it's a huge difference from drawing a shape using a rendering plugin buried under three menu levels.
      - rhizome 8y ago
        Even better!
- prokoudine 8y ago
  The priorities are simple. GIMP is targeted for hi-end workflows. Your average matte painter or photographer doesn't usually need to draw a rounded-corners rectangle, but he sure needs adjustment layers. Hell, even the CHANDRA X-Ray observatory guys need adjustment layers for coloring their FITS files! So that gets a priority. What the 2018 report specifically says though is that most things from the 'Future' section can be done right now by a new interested developer. That includes drawing shapes.
  - mschaef 8y ago
    I still don't follow the prioritization, but thank you for your work on Gimp. I've used it on-again/off-again since version 0.54 (95-96), and it played a formative role in my own software career.

newnewpdro 8y ago

My understanding is there are very few people contributing to GIMP development. The only regular GIMP-related anything I see on planet.gnome.org comes from the ZeMarmot project. It's hard to progress anything without participation...

mschaef 8y ago
This is my understanding, as well. I don't know why it happened that way, but contributor mindshare really moved away from Gimp years and years ago. Other similar projects have been released and surpassed Gimp in feature compatibility in the time since Gimp has been released. Sad, really, given the important role Gimp played back in the late 90's. Gimp was initially the G in GTK, and was closely related to the foundations of Gnome. (And Gnumeric.... which, to my understanding, has the same sorts of issues as Gimp.)
- jay_kyburz 8y ago
  I have read that there are few contributors because the current maintainers are a little hostile towards people who want to try and improve GIMP.
  - mikekchar 8y ago
    I had heard the same thing, but the article linked here seems to indicate a very healthy attitude towards cooperation. I wonder how much of our impression is appropriate at this point. Possibly the project is suffering from bad press than no longer applies? Here's to hoping, anyway!
    - antt 8y ago
      The whole gtk ecosystem smells off. I don't know why but projects that pick qt are by and large friendlier, better maintained and more successful. Back in the day I tried to port xournal to gtk3 and it was a nightmare because there was so much breakage between gtk2 and 3. So much so I gave up. By comparison porting my own stupid python scripts between major versions of qt was painless.

chongli 8y ago

Caveat: I have never looked at the source for the Gimp. I wonder how much of the slow pace of development can be attributed to technical debt? As such an old project, I would imagine a great deal of the code involves old compromises that no longer make sense on modern PCs. With such limited available developer time it can be really demoralizing to have to deal with that stuff. Moreover, with old APIs and languages you lose out on the productivity gains made by modern tech.

slondr 8y ago
This is definitely one of the bigger issues. Early on, GIMP adopted the Emacs development style of building a solid core of functionality in C combined with a REPL for a scripting language within which other features can be developed. Unfortunately they picked Lua instead of developing their own language like Emacs did. Lua is pretty notorious for having an absolutely abysmal implementation and is very hacky itself. It's also unfortunate that the GIMP team didn't have the same hardline commitments as the GNU devs to code correctness (GNU will often delay project releases long past their expected drop dates just to make sure the code is maintainable and nothing is hacked together - see the year-long delay in the release of IceCat Quantum for a recent example of this). This situation got even worse when the devs decided to abandon the graphical toolkit the whole thing was written in in version 0.60 to invent their own, which didn't even include bindings for the scripting language they themselves were working in...it soon became quite a time commitment for any major feature to be implemented because the code base just wasn't designed with futureproofing in mind. Eventually GTK grew out of scope for GIMP and became a GNOME project. Around this time large parts were rewritten again in glib when GIMP became a GNU thing. Add twenty years, and GIMP is essentially a giant steaming pile of hacks that never made sense in the first place, full of components that barely work on their own, much less together. It's a sad state of affairs, especially considering the project had so much potential back in the day. It could have been the Emacs of photo editing, but poor planning from the get-go dashed that possibility.
- alexhutcheson 8y ago
  > Lua is pretty notorious for having an absolutely abysmal implementation Do you know of any blog posts or articles about this? I'd be curious to read more about what the problems with the implementation are.