Still can't get over the user hostile changes in 2.8 (save/export) and will stick to 2.6.
Are you referring to the separation of the export functionality into a distinct menu item. Is this really something you can't get used to over a 7 year period (particularly when this is how every other similar application does it)?
Classic open source community. Sorry to say it.
This is the exact reason Libre Office looks like it's from 1996 and it stops normal users from using it.
This is unfortunately a very real phenomenon. You're telling me you've never worked with/for a company that went gung-ho on some half-baked pile of junk of a system because some sales guy wowed the execs with some flashy "whitepapers" and pretty demos? If not, then you're luckier than I've been, that's for sure.
But that's not how it works with open source, because I can simply choose not to use your garbage. Do you see the difference?
Libre office added ribbons etc as an option. It is not forced on anybody.
The "small GUI change" was a big fuck you to existing users who've gotten GIMP to the level of visibility it's at today. The existing users just weren't flashy and high status enough.
The "small GUI change" was the GIMP devs pushing a file format absolutely nobody uses in order to attract professional users that aren't going to migrate to GIMP anyways.
Meanwhile actual pro features like CMYK support (because it's more difficult than mangling the UI), tablet support on Windows/Mac (because porting to GTK3 is less important than mangling the UI), and cryptographically signed binaries (because nothing screams professional product like getting binaries from an unknown developer).
Mangling the save/export workflow was done purely out of spite and to minimal/no benefit. And now we have a new version of GIMP on an old version of GTK slowly chipping away at the supposed competitive advantage that GIMP's own format has. Meanwhile integration with actual professional products like Lightroom will continue to be more awkward than necessary.
Kudos.
We do not push any particular file format. We push a safe workflow.
Before 2.8, we got a ton of complaints about saving to JPEG and then not finding layers and other extras upon reopening. Doesn't seem to happen nearly as often with 2.8 and onwards. I wonder why... :)
> Meanwhile actual pro features like CMYK support
Done in the backend, will eventually be done in UI.
> tablet support on Windows/Mac (because porting to GTK3 is less important than mangling the UI)
I have no idea what you are talking about. Care to elaborate?
> and cryptographically signed binaries (because nothing screams professional product like getting binaries from an unknown developer).
DMGs for GIMP are signed since version 2.10.10. What the hell are you talking about? :)
> Mangling the save/export workflow was done purely out of spite
In a fantasy world maybe.
This was a stupid change that added absolutely nothing of value, introduced unnecessary UI complexity and the only reason the GIMP developers did not revert despite all the users requesting it is arrogance as they believe to know better than their own users (which is to be expected by anything related GNOME - see the file dialog woes).
Of course GIMP is free and open source so it isn't like they owe anyone a better UX or anything, they could replace all brushes with bananas and drop all file formats except BMP and nobody would have any right to demand anything from them. But at the same time that doesn't (and shouldn't) stop others from calling stinky something that smells bad.
I can imagine that they made the change due to many beginners being confused about having lost editing capabilities by storing their work as a png. The developers probably spend quite some time on the fora where users report these kinds of questions, so I don't think it is all that arrogant of them to believe that they know what causes confusion and what doesn't. Thinking that as a single user you are more knowledgeable on what is better for the over all ux than the actual developers, that I do think could be seen a little bit arrogant.
This has two additional benefits: 1. the beginner will stop be a beginner at some point, will be informed about the target format they are trying to use and will know how to save, save as, etc so this issue will stop be a problem for them and 2. it will get rid of the useless and annoying "do you want to save" warning whenever you want to create a non-XCF image file (because you already saved with "Export", you just didn't save the image as an XCF).
The current approach makes the (wrong) assumption that everyone works with XCF files and only exports to other formats. This might be true for some cases, but a lot of people want to work with other formats directly.
GIMP since version 2.8: only allow exporting to JPG/PNG/TIFF etc., warn if data wasn't saved. Actual results: only a few cases of lost data.
We did the math. Now you do yours :)
Here is something that actually happens since version 2.8: if you do not treat XCF files as the master image file format, GIMP complains all the time.
I'd like to see you prove me wrong.
That's way more annoying than the current GIMP implementation. I sometimes export the same image a lot of times (to work on reducing gif file size etc.) It's very convenient that I can have a master XCF copy and one-click export without any additional dialogs.
Also JPG is a lossy format, so it doesn't support even saving a one-layer file correctly. Do you really want a supposed "photo editor" to warn people every time they export to JPG?
I'm not even sure what this even means. No matter what file you're editing, you're converting it to a gimp internal format when you open it, you're working with it in a gimp internal format, then if you "save" it back to the format the image started in, what you're saving is a conversion from the gimp internal format.
The UI makes that clear. What people are arguing for is to make the UI less clear, not to change anything technical.
Replace PNG with any other file format (outside of XCF, of course).
The technical side is irrelevant, i am talking about the UI and its behavior here, not how it could be implemented.
Saving is by all intents and purposes understood as being able to resume work after loading the next time you use the software.
The formats available under export do not provide this guarantee, because they lose information one way or another.
Being separate features, I know this is the case without knowing what a .dds or a .tga file is, for example.
Hell, this way I can use GIMP without bothering with file endings altogether. I save the file if I want to continue work. It's automatically saved as .xcf. I export when I want to use the image. It's automatically saved as .png or whatever format I started with. No manual entry required. No understanding of file formats required. It just works, period. And it doesn't take any control from the user.
Think of xcf as the gimp project format, similar to source code, and the exported final image as a compiled binary.
GIMP's workflow and what you describe assume you work primarily with XCF files but this is not always (or even often, for many people) the case when working with images as nothing else supports XCF files. Personally i rarely work with XCF files and only do that if i want to save images with multiple layers, otherwise i prefer to save in PNG files as those files will be editable in pretty much everything out there. For that sort of workflow GIMP's insistence on separating Save and Export is annoying, especially when i want to create a new image and GIMP complains that i didn't save it (but i did, i just saved it as a PNG file instead of the XFC GIMP wants me to use - that i have no real use for).
To be honest, I wish some other apps that have to deal with multiple formats worked this way too.
This is subjective, i do not find it better. "Period."
> doesn't let the misconceptions bite you
There are no misconceptions. I create a blank image, paint an arrow in there, want to save it as a PNG file so others can see it. GIMP complains when i try to exit because i didn't save the image. But i did, i just didn't use GIMP's proprietary file format that GIMP developers want to push.
> What you're describing is just a minor annoyance
Yes it is, i still use GIMP after all despite it. I am merely describing why i see it as an annoyance. Something being a minor annoyance doesn't mean it doesn't exist at all, after all.
Basically, you're angry because GIMP doesn't optimize its UI for MS Paint use-cases. Trading "slightly better for basic usage" with "significantly worse for any other usage" is a bad idea for a software aspiring to be a professional utility.
This is completely misrepresenting and misunderstanding what this file format even is. You might as well complain that saved games are not compatible between Age of Empires and Pokemon.
If existing formats don't support the complexity that software like GIMP requires to save a given state, then it has to fall back to a custom format. The only alternative that comes to mind is using .psd, which clearly wouldn't solve your problem since it is actually a proprietary format.
As for this "agenda" to push some proprietary format, this excerpt from Wikipedia might clear things up:
"A collaborative effort between the developers of GIMP and Krita is underway to design a raster file format called OpenRaster, modelled on the OpenDocument format, for use in both applications in a future version."[1]
The difference is that with "save", the user should be able to expect that all (or at least the most important) aspects of his image editing session are retained. That includes, for instance, all the layers, but could perhaps even extend to the undo-history. It's up to the developers to draw the boundary, I guess.
With "export" on the other hand, such guarentees are not given. If I export my Gimp image to ".jpg" then I won't be able to restore the layer information later on.
Thus, there might be situations where I want to "save a copy as" and also situations where I want to "export a copy as". But they are different things.
Now, all of the above are theoretical considerations. It's not hard to imagine that developers accidentally, or even intentionally, divert from that distinction for whatever reason. But I think it's potentially a useful decision to make, because when you "export", that comes with an implict warning that what ever is written to disk might potentially not retain all information you might want when you wish to continue your editing session later on.
I don't need to separately export it again to png. Because... I opened a png, I made changes, saved it and closed the file.
If gimp not doing it, then it's an issue.
Maybe, don't let people to open other formats. But let them "import" other formats. This will maintain consistency . Whether usability improves is another question.
Note that the "export" workflow could work as it does right now, there is nothing wrong with saving to a separate file (and the program remembering it) without changing the filename of the current image you work on.
That seems needlessly dangerous in the workflows typical for graphical design. Usually you import one or more source images, make your changes, and export a new image, leaving the source intact (specifically so you still have an original copy of the source images for later use in new, entirely-separate projects).
Sure, this makes it a little bit inconvenient for one-off edits, but I suspect one-off editing ain't the target use case for GIMP, much like how it ain't the target use case for Photoshop.
Photoshop has that workflow to entrench its PSD file format. GIMP seems to want to do the same thing instead of treating all formats as equal (technical differences - which can be warned against - aside).
Basically this is the typical pet peeve of $GENERIC_USER in which is exactly how you're saying: developers DO know better than $GENERIC_USER what UX is easier and more functional.
So no, the developers do not know better than $GENERIC_USER, at least not this particular $GENERIC_USER.
- Export is "save the output of my work to a file (which may or may not be import-able afterward)"
So yes, you are right that both of them essentially translate to "save", but they're very different types of saving with different expectations.
The distinction here is that the primary "Save" should be reversible, and should never involve data loss. The 2.6 workflow was actually "dangerous" for this reason.
> Unless you use functionality that the format you are trying to save to doesn't support, then you can resume your work. If you try to use functionality that the target format doesn't support, GIMP could simply tell you so, like what many other programs that support multiple save file formats already do.
There is nothing dangerous about the "2.6" workflow (which is also shared by many other programs) and what you describe is really trying to come up with nitpicky and arbitrary distinctions between saving and exporting to justify their unnecessary separation.
The Save/Export split still catches me out. I'm not about to burn the barn down, but each time it makes me grunt in frustration.
Practically every image editor on the planet split saving in the application's native file format and exporting to foreign file formats.
Hell, even document editors do this.
The expected workflow is, therefore, that exporting is a different dialogue. Not terribly hard.
I do not have many editors installed here, but Paint does have all formats on Save. Paint Shop Pro also has all formats on Save. I do not have it installed, from what i can see in the documentation[0] Paint.Net also has all formats on Save. LazPaint also has all formats on Save.
I'm sure i can find many others if look for (i think GraphicsGale for example also does that but i'm not 100% sure). Those are from the top of my head.
Maybe with "Practically every image editor" you really meant "Photoshop"? Because Photoshop isn't the be all end all of all image editors nor all image editors are meant to be Photoshop clones.
GIMP has been totally reskinned and a whole lot of under-the-hood and feature changes have taken place. Do you actually read their release notes?
Progress has been steady on the non-destructive editing front. It's taken a complete engine rewrite to get the necessary prerequisite features in place.
Why don't you dive in and lend a hand instead of lamenting over how long it's taken?
All of this to avoid saying: "You're converting your working copy into a lossy format. You might lose things."
The save vs export change only hits against habits. It took me a while to figure it out at the time but these days I practically only ever use "Export as" because I know what I want and I know what I'm doing, and how to do it in later Gimp versions.
While I didn't like the change it does make sense. Loading and saving in Gimp is about native formats. Saving to a bitmap format loses much of the data so calling it an export is quite appropriate. Before, Gimp was always nagging about whether I'm sure I want to save as jpeg because I wouldn't be saving my Gimp state that way. That wasn't pleasant either.
It is not a major issue, but it still is an annoyance you have to face constantly if you want to work with other file formats directly as opposed to treating them as second class citizens regardless of what sort of editing you are doing.
Similarly if you are editing an image with a single layer (the background) and save it as a PNG it is always lossless (no need for warning dialog) but if you add a layer and try to save it then it becomes lossy (so show a warning dialog with the option to proceed as the default - being default because that is what the user asked for - and an option to save as XCF instead so that the layer is preserved).
However beginners or not, unless your primary file format is XCF, GIMP will always annoy you about not saving your image even though you did it - just instead of saving it in its own proprietary format that nothing else supports, you saved it in something that can actually be shared.
In nearly every program in common use, the open → edit → save workflow Just Works. In some programs (e.g., Word) you might get a dialog extolling the features of the newest proprietary format, but it won't prohibit you from saving as the original format (.doc, .rtf, whatever).
GIMP does. The functionality is completely removed from the Save dialog. You have to somehow know to cancel your save (talk about unintuitive) and go use the Export dialog.
IMO, this was an unforced error. GIMP copied the Photoshop Save workflow mistake, despite it being the minority position, despite GIMP's own history of the UI for that feature, and despite not having any (published) A-B studies.
As a Mac user, I can't recall seeing this behavior anywhere, so I checked all the graphics programs I have here. Affinity Designer, Graphic (formerly iDraw), and Pixelmator all use "Save" to mean the application's native format, and "Export" for other formats. So do Apple's iWork apps. So do Omni's apps.
In fact, I can't find a single program that works the way you say "nearly every program in common use" does it. The Apple Human Interface Guidelines call for a Save/Export split along these lines, too, so it's not just a lone Adobe mistake.
Is that a Windows convention? The GNOME/Gtk+ community has not tended to follow Windows UI conventions.
Affinity Designer isn't an image editor. Consistent with its name and marketing, it is graphic design software.
Obviously I have no objection to GIMP positioning itself as a graphic design program rather than an image manipulation program. However, if that's the direction they wanna go, perhaps they might consider changing their name to something other than "GNU Image Manipulation Program."
Most programs aren't image editors which can export in a variety of formats as well as save in a native, preserving format. How Microsoft Word works has literally nothing to do with how GIMP works.
> GIMP copied the Photoshop Save workflow mistake
Tens of hours of work done on accident?
> despite it being the minority position
Photoshop a minority??
> despite GIMP's own history of the UI for that feature
A previous major version's UI has relevance to a future major version's UI???
> despite it being the minority position
Who is paying for these studies????
Yes, of course.
But at some point in a 20-year development cycle you might want to switch things up, and a major release is the time to do it.
I don't think anyone had a legitimate complaint when Blender completely revamped their UI a few years ago. It was objectively better, and "it's different than what I'm used to" was not a valid complaint.
As such it is most definitely a positive change, even if it does go against my 'muscle' memory of how I used to work it, and cause me to 'doh' more often than I should.