After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 676051 - Export from save dialogue
Export from save dialogue
Status: RESOLVED NOTABUG
Product: GIMP
Classification: Other
Component: User Interface
2.8.0-RC1
Other All
: Normal enhancement
: ---
Assigned To: GIMP Bugs
GIMP Bugs
: 679093 680987 722499 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-05-14 21:39 UTC by nofewfudtefcity
Modified: 2014-01-18 17:55 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description nofewfudtefcity 2012-05-14 21:39:44 UTC
In 2.6.x releases of Gimp, all formats of images could be saved from one single menu just by changing the file extension. In 2.8.x you are required to use the "export" menu to save anything besides an .xcf.

While this sounds like a good idea, it's mildly bothersome for people like me who are used to just using one interface and a few keystrokes to save both an XCF and PNG in a few seconds.

There is a dialogue box that appears when someone tries to save anything that isn't an XCF rather than export it, saying the user must export it instead. I believe it should have the option to export it instead right from that box rather than requiring the user to close the save dialogue and open the export dialogue.

To be extra clear, I am not asking for a shortcut to the export menu from the save menu. I'm suggesting that, if, from the save menu, a user tries to save a non-XCF file, it'll ask if they'd rather export it instead, and if they click "yes", then it'll act as if they did everything right through the export menu; Gimp should just ask for the compression options and such right away and not require the user to re-enter any data in a new export dialogue.


As another related feature if this is accepted, I suggest making an option not to even ask. Just assume the user meant to export automatically (Restore 2.6.x functionality).
Comment 1 Michael Natterer 2012-05-14 21:51:20 UTC
Sorry, not going to happen, see:
http://gui.gimp.org/index.php/Save_%2B_export_specification
Comment 2 nofewfudtefcity 2012-05-15 12:30:52 UTC
(In reply to comment #1)
> Sorry, not going to happen, see:
> http://gui.gimp.org/index.php/Save_%2B_export_specification

After reading the document you linked twice and my feature request twice, I fail to see why this cannot be implemented. Please read my request carefully.

Your document essentially explains that you are concerned people will save to the wrong format. Although the text does, in a way, directly prevent my feature request, the way I have made the request (at least the second one) would still comply with your intentions.

Let me state this again. In my first request, the end user, upon trying to save a non-XCF file, would explicitly have to tell Gimp to proceed with an export instead. The default would be to pop a warning up and tell them they will loose data.

In my second request, I asked to make it /configurable/. In other words, the default would not just suppress that message and proceed with an export. It would function as it does as of 2.8. The end-user would have to explicitly go find the parameter somewhere in Gimp's config and alter it to suppress the message.


In case you want me to do the work for you: Change the wording of the popup from:
"You can use this dialog to save to the GIMP XCF format. Use File→Export to export to other file formats."
to: "Saving to anything but XCF is lossy. If you wish to continue saving in (.THIS) format, click "Export anyway".

Replace "(.THIS)" with the file format and add a button saying "Export anyway". Make the default "Cancel".


As for the second request (Which you may want to implement in place of my primary request), the default is still to keep 2.8's functionality. The end-user would have to manually change an option to revert to 2.6's.


If you are sure this is against your intentions, please state your reasons as to why. Don't just tell me "Eh, no.".
Comment 3 Alexia Death 2012-05-15 12:57:27 UTC
It's not an "Eh, no." It's "We designed it this way for a reason. Here are the reasons.".
Comment 4 nofewfudtefcity 2012-05-15 14:34:10 UTC
If that's the case, please explain exactly why you're saying that document prevents my second request from being realized.
Comment 5 strata_ranger 2012-05-18 16:42:11 UTC
I agree.  When GIMP displays the message that "Save is for XCF only; use Export for other formats", is there any absolute reason that it CAN NOT offer the user a set of buttons labelled "Export", "Save as XCF", and "Cancel" ?
Comment 6 André Klapper 2012-09-19 12:08:32 UTC
*** Bug 680987 has been marked as a duplicate of this bug. ***
Comment 7 André Klapper 2012-09-19 12:08:48 UTC
*** Bug 679093 has been marked as a duplicate of this bug. ***
Comment 8 Michael Schumacher 2014-01-18 16:09:46 UTC
*** Bug 722499 has been marked as a duplicate of this bug. ***
Comment 9 jeebajaabajoobahaaba 2014-01-18 17:00:23 UTC
I am getting angry just reading the first lines of that "Save + export specification" wiki entry linked. Let me please cite it and politely enrage myself over it:

** This change tries to achieve some specific goals:
**
**    - simplify and clarify the user model: what you see on the canvas
**      is always GIMP content;

How is breaking conventions that have been accepted for at least 30 years any simpler than just abiding by them? There is NO improvement gained from having to export for 99% of formats and only being able to save in one.
Also the argument that this clarifies the user model makes me want to scream out in agony. Anyone who can grasp the concept of using a plastic device on the table to move a pointer on a display should be able to quickly learn that saving in a different file format is done by "Saving as". How much clarification must there really be? I think this is crossing a line between intelligent design and design for the unintelligent. Software is for people. People are intelligent.


**    -enforce that what is on the canvas is only safe when saved as an
**     xcf file—or its compressed variants;

What is the reason for this? There is no good reason for this? Why can't the canvas be safe inside a JPEG? Or anything for that matter? Why impose a format that has NOTHING to do whit what you are working on? If I am a 3D Modeller and want to quickly edit a texture image, WHY ON EARTH would I need XCF for that? Believe it or not, my 3D Suite would probably not even know what that is. So why hassle me with it? This is completely unnecessary and even somewhat arrogant.


**    - give primary support for a high-end workflow where the work is
**      saved in xcf, and for ‘delivery’, it is (repeatedly) exported
**      to the required format;

Primary support for a way of doing things? How about giving primary support for a versatile user that is never twice the same. And does not want to be forced into doing what others think is right for them?


**    - give secondary support to workflows where the input and output are the same non-xcf file; the reason for this is not the often touted ‘prosumer photo jpeg–to–jpeg’ workflow, because for complying with the GIMP product vision there is no need for optimising this. A much better reason for optimising are situations where high-end GIMP users have to do some quick touch-ups on graphic files for mates or clients, and send them back. 

WE ARE THE 99%!! STOP FRAKKING WITH US!!
Comment 10 strata_ranger 2014-01-18 17:45:22 UTC
We have a GIMP mailing list for this kind of discussion.... (discussion, not ranting)

In other news, 2.8.10 mitigates the issue a little by adding a link to the warning message so you can access the proper command in a single click.
Comment 11 jeebajaabajoobahaaba 2014-01-18 17:55:51 UTC
I am sorry I got carried away (politely so). I shall discuss them with your mailing list, with the same intensity, but less insult (even though this was very polite insult). But first a look at 2.8.10.