Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GIMP 2.9.4 and our vision for the future

girinstud.io

Post reply on HN
Print view View original

61–70 of 98 posts

Re: GIMP 2.9.4 and our vision for the future

#61

Post by appleflaxen »

StevePerkins wrote: post #34
imurray wrote: post #20

Gimp 2.8 frustrated me: I could no longer open a .png, edit it and easily resave it back to .png. The Gimp developers knew better and made the UI strongly favor saving as .xcf, which makes sense in some use-cases, but not mine. I found this fix, which made quick uses of GIMP less painful for me: http://shallowsky.com/software/gimp-save/ I'm assuming the new save behavior persists in Gimp 2.9.x, but I don't know.

> less painful for me I realize that this is common UX jargon, but is it literally "painful" to click "File->Export" rather than "File->Save"? I frequently hear front-end developer peers arguing that it's "painful" to read 10 or 20 lines of XML. Back-end peers retort that it's more "painful" to look at large complex structures in JSON. There's a hundred other cases in which this comes up. Are people really walking ar…

it's a common figure of speech. it's not confusing, given the context. and "more workful" doesn't sound very natural.

Re: GIMP 2.9.4 and our vision for the future

#62

Post by ebiester »

imurray wrote: post #37
AlecSchueler wrote: post #36

Earlier quoted context omitted.

It's the same amount of clicking, just that 'save' and 'export' do different things.

No it's not the same amount of clicking. From Gimp 2.7 to 2.8 something that used to be ctrl-s and close window went to ctrl-shift-e, and answering four dialog boxes before getting the image saved and the window closed. Around the time Gimp 2.8 came out, I wanted to edit and save around 50 images (in away that wasn't easy to automate). That (without the plugin that gives the old behavior) would be 200 dialog boxes to…

I wonder if a voice-annotated youtube capture of the process might help capture the pain of the process.

Re: GIMP 2.9.4 and our vision for the future

#63

Post by timonovici »

phkahler wrote: post #49

Still waiting. They need to prioritize 3 things IMHO, and those are 1) GEGL integration - this was claimed to be 80 percent done in 6 weeks (several years ago). Updating core code and libraries should be done quickly, not spread out over years concurrently with other development. 2) Update to GTK3. How can a flagship OSS program still be using a many-years-old GUI toolkit? And finally 3) Wayland support. This will be…

It would probably be done in few months, if GIMP had a few full-time developers. But as it stands, with people working in their free time, don't expect miracles. If anything, I find it amazing that it's still developed at all.

Re: GIMP 2.9.4 and our vision for the future

#64

Post by qwertyuiop924 »

goatface wrote: post #51
qwertyuiop924 wrote: post #28

GIMP is a handy tool: I use it for a lot of my image editing needs, for when very basic tools won't do. I rarely need the power of PS, and can't afford it anyway (although I do miss that magnetic lasso: GIMP's magic scissors don't quite have a good enough algorithm). All of this talk about the future is exciting. However, yes, GIMP is quite rarely an acceptable replacement for PS, and I find this unlikely to change a…

GIMP's new (though not actually young) engine - GEGL, contains ffmpeg frame sources and sinks, provides a good abstraction for creating interfaces better than GAP for animation or video editing - see https://www.youtube.com/watch?v=GJJPgLGrSgc for an example of a video that has been edited and encoded using GEGL this year.

Well, yeah, but why would I write a new interface, when Synfig is already there and, to some extent, comparable to Flash?

Re: GIMP 2.9.4 and our vision for the future

#65

Post by chickenfries »

pfranz wrote: post #56
phkahler wrote: post #45

Earlier quoted context omitted.

>> I realize that this is common UX jargon, but is it literally "painful" to click "File->Export" rather than "File->Save"? One can also make that statement to the person who decided the default save format should be different from the one the user opened. IMHO most people want to save in the format they started with and if they want to change it, something other than "save" is warranted.

This isn't just a problem with Gimp. It's a problem with Photoshop and basically every discipline where there's a bunch of file formats that have varying levels of support for features. "Open" would then more correctly called "Import" for most file formats. If you want Open and Save to work with all file formats, you'd then need to restrict the UI to operations that work with the file format you have open. Otherwise,…

If I open a PNG in Photoshop, crop it or resize it, it stays in PNG when I save it. This is such a common workflow that it makes me wonder if you use Photoshop.

I understand your points, but it doesn't mean that there aren't pragmatic UX choices to be made here.

Re: GIMP 2.9.4 and our vision for the future

#66

Post by BashiBazouk »

oggedintocom wrote: post #2

GIMP is an icon of open-source software, but do any professional designers use it full-time over Photoshop? Compare with Sketch, which has taken scores of users from Illustrator.

Mostly depends in what space you work I would think. I work in print production and absolutely need robust pantone support. I could go on endlessly about how few seem to understand what pantone is and how it works but that does not change the fact it is the defacto language for communicating printed color. Last I checked there is no pantone plugin for GIMP and as pantone is proprietary that may not change.

I also deal with large format printers. These are built in the thousands or tens of thousands and don't get the software love that they would if produced on a larger scale. RIP's tend to be finicky and are designed to play nice with the adobe suite, so most stick with those tools.

Re: GIMP 2.9.4 and our vision for the future

#67

Post by pg_is_a_butt »

StevePerkins wrote: post #34
imurray wrote: post #20

Gimp 2.8 frustrated me: I could no longer open a .png, edit it and easily resave it back to .png. The Gimp developers knew better and made the UI strongly favor saving as .xcf, which makes sense in some use-cases, but not mine. I found this fix, which made quick uses of GIMP less painful for me: http://shallowsky.com/software/gimp-save/ I'm assuming the new save behavior persists in Gimp 2.9.x, but I don't know.

> less painful for me I realize that this is common UX jargon, but is it literally "painful" to click "File->Export" rather than "File->Save"? I frequently hear front-end developer peers arguing that it's "painful" to read 10 or 20 lines of XML. Back-end peers retort that it's more "painful" to look at large complex structures in JSON. There's a hundred other cases in which this comes up. Are people really walking ar…

yeah, this guy is retarded... i just hit command-E.

it's literally painful to listen to these ladies whine about being morons.

you're all idiots.

Re: GIMP 2.9.4 and our vision for the future

#68

Post by goatface »

qwertyuiop924 wrote: post #64
goatface wrote: post #51

Earlier quoted context omitted.

GIMP's new (though not actually young) engine - GEGL, contains ffmpeg frame sources and sinks, provides a good abstraction for creating interfaces better than GAP for animation or video editing - see https://www.youtube.com/watch?v=GJJPgLGrSgc for an example of a video that has been edited and encoded using GEGL this year.

Well, yeah, but why would I write a new interface, when Synfig is already there and, to some extent, comparable to Flash?

Synfig focuses on more cartoon based vector animation. What GEGL provides good foundations for doing is video editing/compositing with keyframed properties for filters.

As mentioned in the linked article of this story - having an eco system of applications using GEGL would benefit both these applications and GIMP - since they would be sharing image processing operations and plugins.

Re: GIMP 2.9.4 and our vision for the future

#69

Post by qwertyuiop924 »

goatface wrote: post #68
qwertyuiop924 wrote: post #64

Earlier quoted context omitted.

Well, yeah, but why would I write a new interface, when Synfig is already there and, to some extent, comparable to Flash?

Synfig focuses on more cartoon based vector animation. What GEGL provides good foundations for doing is video editing/compositing with keyframed properties for filters. As mentioned in the linked article of this story - having an eco system of applications using GEGL would benefit both these applications and GIMP - since they would be sharing image processing operations and plugins.

Well, I AM doing cartoon animation. Although video editing/compositing is always handy. Do you know if sombody's created a UI for this stuff yet?

Re: GIMP 2.9.4 and our vision for the future

#70

Post by qwertyuiop924 »

StevePerkins wrote: post #34
imurray wrote: post #20

Gimp 2.8 frustrated me: I could no longer open a .png, edit it and easily resave it back to .png. The Gimp developers knew better and made the UI strongly favor saving as .xcf, which makes sense in some use-cases, but not mine. I found this fix, which made quick uses of GIMP less painful for me: http://shallowsky.com/software/gimp-save/ I'm assuming the new save behavior persists in Gimp 2.9.x, but I don't know.

> less painful for me I realize that this is common UX jargon, but is it literally "painful" to click "File->Export" rather than "File->Save"? I frequently hear front-end developer peers arguing that it's "painful" to read 10 or 20 lines of XML. Back-end peers retort that it's more "painful" to look at large complex structures in JSON. There's a hundred other cases in which this comes up. Are people really walking ar…

XML IS actually more painful than JSON: There's more syntax, and it looks less distinct, especially if it's not properly indented. JSON look a lot cleaner, and the extra metadata that XML provides is rarely needed for casual reading.
Post reply on HN