597
GIMP is gearing up for a massive upgrade (www.gimp.org)
submitted 1 month ago* (last edited 1 month ago) by to c/opensource@lemmy.ml
201 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 2 points 1 month ago (4 children)

"It doesn't necessarily need to be that going forward"

This part does not make any sense. Making GIMP to be able to support any image format is a good thing. Especially for future file preservation.

If it was merely industry standard, if a software already good, people will just use the default format. It already happen with various industries, like comic making in Asia using .CLIP (Clip Studio Paint) instead of .PSD

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 1 month ago (2 children)

    That's nice to have. For both GIMP and the industry's sake, priorities should be:

    • good UX
    • feature-wise competitiveness
    • in any (sensible) format

    GIMP is an alternative to Photoshop. It isn't a psd reader.

    Being the format jack of all trades yet master of none isn't too great of an idea. It'll just exacerbate GIMP's main current problem: an ancient UI Photoshop enthusiasts dread. A lot might consider switching if the bad GIMP UX was better than the also-bad Photoshop UX.

    If I had to say what my main design gripe with gimp is, that'd be modularity. Seperate the ui (skins) from the tools, effects and rendering (formats). The UI is especially egregious in its hard-codedness while effects are pretty well-supported.

    A few more apis would go a long way. Hell, even the closed Photoshop has open(ish) apis, since even Adobe know the value of an ecosystem and not just their internal r&d department!

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 month ago

    @unwarlikeExtortion Sure - what additional things would you like accessible via API? Public docs for reference: https://developer.gimp.org/resource/api/

    As for separation, the styling of elements is done via separate (GTK3 subset of) CSS so that's fairly flexible. The GUI elements themselves are defined in C, which is less flexible but we do separate them out in source in our /widgets and /gui folders as best we can.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 1 month ago

    If you actually follow the dev, they don't seem to prioritize PSD or even trying to be a Photoshop clone at all :)

    It's just that when a feature get introduced, a new feature from other format get supported. Such as upcoming vector layer and shape tool.

    I believe jack-of-all-trades of images is actually a good thing. All newer image editor, whether FOSS or proprietary are jack-of-all trades, like Graphite or Affinity You just can't confined people just to use raster layer, and not vector layer. Or using multiple app just to do some image editing.

    The problem is not jack-of-all-trades itself, but finding a good UI/UX to make it not complex for all user.

  • permalink
  • fedilink
  • source
  • parent