Edit (in response to jgreen10)
>Are you suggesting no one has a car?
No, I am suggesting that the logic "cheaper stuff outsell more expensive stuff" is wrong.
The thing almost every user expects it that saving the file just saves over the old file in the format it was originally in. IIRC, it used to work that way, and then one day it changed for the worse.
Mind you, I've never contributed the tiniest bit of code or funding to Gimp, so I can't really complain.
That's utterly silly. If you take yourself seriously as a graphics editing program, then inevitably you have to move to one format that you can then convert into others. Otherwise you have to implement every single operation on every single file format you support. With the One True Format, (.otf) you can convert your .jpgs to the .otf and then do the operation there.
This then presents a problem. Tech-savvy users know that there will be a loss of data when you save to a consumption format. But the rest of us don't. If you allowed open and save in the same format, people will make the intuitive leap, that they're actually editing the files in that format, when they're not. They'll think all the layers they made will carry over into the PNG and that they'll be there when they re-open the file, when in fact they won't.
It would be a nightmare, because nobody will know what will save and what won't. You'd have to then educate users that to get everything to save properly, you have to save to .otf. Or you could just bake that logic directly into the app.
I know users don't read, etc, but the trade you're making is that the simple process of editing a file and saving it is now much more annoying. I just want to make changes to my PNG, not deal with the One True anything.
The stated goal was to make it harder (still? I guess people clicked through the warning without reading) to accidentally save in .png or .jpg and lose the layers. But the result, for someone whose usual workflow is to open a .png/.jpg, edit, and save back to .png/.jpg, could not be more user-hostile and obnoxious.
In response to a complaint, someone on the forums wrote:
> This is the way Gimp now works. Of course you can consider this a PITA. But for other folks, losing work because they saved as JPG instead of XCF is also a PITA. The philosophy is that people that are impacted negatively by this change are people with very simple work-flows who would be better off using simpler software (XnView, Digikam, Lighttable...)
In other words, all of you people with simple workflows, that worked just fine in Gimp for years? Now you have to go off and learn some new software, because Gimp is for Serious Graphic Design™ only. Ugh.
I got excited researching this because I found a changelog for Gimp 2.8.4 that mentions patching the behavior to be sane, but then I realized that's only a patch in the unofficial OS X build. On Linux, the same nonsense in the latest version.
Every program I use saves to the original format by default, most warning you if there will be data loss. Whether you like it or not, this is how software works and how users expect it to work. If you want to automatically backup a different format that's fine.
GIMP should have option "also save as native format in image repository" that is on by default, if the developers care so much about the conversion losses.
If you want to save the full format of the file, including layers and whatever other GIMP magic you've created, you'd best save it in GIMP-native format.
If you're just doing some quick tweaks, you'll get used to the export option and ignore the prompt to save on quit.
Since most of what I do are quick edits of screenshots, the latter works fine for me. If I were a graphic artist, I'd probably get more than slightly peeved if my afternoon's work were lost due to an incompatible file format save w/o prompt.
Not prompting the user leads to massive loss of user work and state. Prompting the user is a minimal overhead to avoid this risk.
From a technical point of view I can certainly approve the change. Back in my time I've had couple of my images ruined by badly timed save (user error [tm]), so the non-destructive approach certainly has its merits. However, the new behaviour breaks a lot of ingrained casual use flows. So maybe the best approach would for Gimp to remember the original filename when it's opened and if the filetype is anything except XCF, simply do two saves: create a new $filename.xcf automatically with all the changes the user has made, and also auto-export with the old name.
That way the more casual users could still just do "open, edit, save" for their quick edits. As a bonus, since the XCF file is non-destructive, the original file would still be in there. This might give the best of both worlds: it wouldn't break existing workflows, and it would automatically prevent accidentally changing the original image. Plus it would make the save/export split less of a headache for new users.
Just an idea.
It's virtually every time; I just request JPG exports to go along with the PSD, because otherwise I won't know it's missing.
(To be fair, some of that last bit is due to Adobe patents)
So my point is: The same goes for cars vs. bikes. Most people wouldn't mind using a bike to go to work, but it feels weird to pay only a couple of bucks for a bike, when you've learn that the price to go to work is the price for a car.
The reasons for this could probably be rightly chalked up to obfuscation and other below-board shenanigans on the part of certain companies, but the end result is still that you don't use the FOSS version if you're serious.
>I was more referring to compatibility, here.I was more referring to compatibility, here.
Yeah I know, but I got carried away :)
i mean, really, i love GIMP, but, it'll take some time ...
Anyway, Android (Linux) dominates the mobile space, and Linux dominates the server and a lot of the embedded space. So yes, cheap stuff outsells expensive stuff.
And I think it is an interesting question, someone knows some statistics regarding that?