Save v Export behaviour
This discussion is connected to the gimp-user-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
Save v Export behaviour | Brendan Scott | 03 Dec 05:37 |
Save v Export behaviour | Richard | 03 Dec 18:26 |
Save v Export behaviour | Brendan Scott | 04 Dec 01:51 |
Save v Export behaviour | Wolfgang Hugemann | 04 Dec 07:42 |
Save v Export behaviour | Andrew & Bridget | 04 Dec 10:34 |
Save v Export behaviour | Brendan Scott | 04 Dec 12:03 |
Save v Export behaviour | Simon Budig | 04 Dec 12:22 |
Save v Export behaviour | Brendan Scott | 04 Dec 12:56 |
Save v Export behaviour | Simon Budig | 04 Dec 13:28 |
Save v Export behaviour | tobias.lunte@hfg-gmuend.de | 04 Dec 19:05 |
Save v Export behaviour | Brendan Scott | 05 Dec 13:03 |
Save v Export behaviour | Richard | 05 Dec 15:39 |
Save v Export behaviour | Mark Bourne | 06 Dec 21:01 |
Save v Export behaviour | Andrew & Bridget | 04 Dec 13:56 |
Save v Export behaviour | Jeffery Small | 04 Dec 17:14 |
Save v Export behaviour | Alexandre Prokoudine | 04 Dec 18:51 |
Save v Export behaviour | qelvin5500 | 04 Dec 20:33 |
Save v Export behaviour | John Meyer | 04 Dec 20:40 |
Save v Export behaviour | qelvin5500 | 09 Dec 16:42 |
Save v Export behaviour | Wolfgang Hugemann | 04 Dec 19:51 |
Save v Export behaviour | Brendan Scott | 04 Dec 12:03 |
Save v Export behaviour | Joseph A Nagy Jr | 05 Dec 01:26 |
Save v Export behaviour | Richard | 05 Dec 04:42 |
Save v Export behaviour | Andrew_Bridget | 05 Dec 07:51 |
Save v Export behaviour | Brendan Scott | 05 Dec 10:19 |
Save v Export behaviour | Andrew & Bridget | 05 Dec 11:51 |
Save v Export behaviour | VintageGimp | 15 Apr 03:49 |
Save v Export behaviour | Liam R E Quin | 15 Apr 04:17 |
Save v Export behaviour | VintageGimp | 15 Apr 10:46 |
Save v Export behaviour | Richard | 16 Apr 03:56 |
Save v Export behaviour | VintageGimp | 15 Apr 11:03 |
Save v Export behaviour | Alexandre Prokoudine | 15 Apr 08:35 |
Save v Export behaviour | VintageGimp | 15 Apr 10:55 |
Save v Export behaviour | Alexandre Prokoudine | 15 Apr 10:59 |
Save v Export behaviour | VintageGimp | 15 Apr 11:30 |
Save v Export behaviour | Tobias Jakobs | 15 Apr 14:00 |
Save v Export behaviour | VintageGimp | 15 Apr 11:46 |
Save v Export behaviour | Alexandre Prokoudine | 15 Apr 12:06 |
Save v Export behaviour | VintageGimp | 15 Apr 12:25 |
Save v Export behaviour | Joao S. O. Bueno | 15 Apr 13:57 |
Save v Export behaviour | Liam R E Quin | 15 Apr 14:18 |
Save v Export behaviour | Alexandre Prokoudine | 15 Apr 15:04 |
Save v Export behaviour
I hadn't wanted to comment on the earlier threads bc they were too heated.
Initially my work was with .xcfs natively, so this wasn't an issue for me. More recently though I've had to do a lot of spot edits on jpgs and pngs. I would welcome a "responsible adult" mode which didn't bug me about saving the file as xcf.
This _even though_ I lost edits last week on a batch of files because I forgot jpgs don't support transparency. Ironically I ignored the save as xcf warnings in that case. More useful I think would be a dialog which identified for what I was about to lose (transparency, layers or whatever) in the target format, and then accepted my decision (and cleaned whatever dirty flag is set on edits) if I clicked ok. Harder to implement though I imagine.
Save v Export behaviour
Date: Tue, 3 Dec 2013 16:37:26 +1100 From: disposableemail@apps.opensourcelaw.biz To: gimp-user-list@gnome.org
Subject: [Gimp-user] Save v Export behaviourMore useful I think would be a
dialog which identified for what I was about to lose (transparency, layers or whatever) in the target format, and then accepted my decision (and cleaned whatever dirty flag is set on edits) if I clicked ok. Harder to implement though I imagine. ------
Telling you what you'd lose is precisely what 2.6 did. It was a useful trivia but it's not really relevant to 2.8's save/export model.
Cleaning the 'dirty' flag after export isn't going to happen - there is a user-made GIMP plug-in that will do this for you (it adds an "Export & Clean" type command to the File menu) but the core behavior isn't negotiable :(
Tip: From 2.8 (.4 I think) onward will inform you if there are no changes since the last export; the warning message will inform you the file was recently exported so you can use this to make your own judgement about whether it's safe to close.
There is however a GIMP plug-in that does an export and cleans the dirty flag, but the core behavior is not
-- Stratadrake
strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.
Save v Export behaviour
On 12/04/2013 05:26 AM, Richard wrote:
Date: Tue, 3 Dec 2013 16:37:26 +1100 From: disposableemail@apps.opensourcelaw.biz To: gimp-user-list@gnome.org Subject: [Gimp-user] Save v Export behaviour
[]
Cleaning the 'dirty' flag after export isn't going to happen - there is a user-made GIMP plug-in that will do this for you (it adds an "Export & Clean" type command to the File menu) but the core behavior isn't negotiable :(
Maybe I'll look into the plug in. Save v export is an annoyance (when I'm in jpg editing mode), but not a life changing one.
Tip: From 2.8 (.4 I think) onward will inform you if there are no changes since the last export; the warning message will inform you the file was recently exported so you can use this to make your own judgement about whether it's safe to close.
There is however a GIMP plug-in that does an export and cleans the dirty flag, but the core behavior is not -- Stratadrake
It's important to note here that the save vs export didn't actually help me when I lost my edits precisely because I had become habituated to ignoring the save warning (and the solution for me to the transparency issue is to export to png/gif rather than xcf btw).
The save/export UI may need more thought.
Save v Export behaviour
The save/export UI may need more thought.
As a Windows user, I am also annoyed by Gimp's behaviour, it's strange. The default behaviour of any Windows program is to save a document in the format it was opened in or possibly suggest you to convert it to a more suitable one, i.e. programs behave the other round, compared to Gimp. So maybe the expected behaviour also depends on the OS you use.
But even under Windows, nobody would expect that a dedicted export routine would clean the dirty flag.
Wolfgang Hugemann
Save v Export behaviour
On 04/12/2013 07:42, Wolfgang Hugemann wrote:
The save/export UI may need more thought.
Why ?
is to save a document in the format it was opened in
So, how do you save to .NEF you have imported from RawTherapee ?
or possibly suggest you to convert it to a more suitable one,
.xcf ?
But even under Windows, nobody would expect that a dedicted export routine would clean the dirty flag.
So saving to .jpg in any other program would maintain layers !
Save v Export behaviour
On 12/04/2013 09:34 PM, Andrew & Bridget wrote:
On 04/12/2013 07:42, Wolfgang Hugemann wrote:
The save/export UI may need more thought.
Why ?
Because if its aim was to prevent me from losing work (transparency edits), it failed. It failed because: * I was so used to hitting "close without saving" to get rid of the irrelevant save dialog box that I didn't realise when it really was relevant; and * even if I had realised, xcf still wouldn't have been my preferred target format.
Save v Export behaviour
On 12/04/2013 06:42 PM, Wolfgang Hugemann wrote:
The save/export UI may need more thought.
As a Windows user, I am also annoyed by Gimp's behaviour, it's strange. The default behaviour of any Windows program is to save a document in the format it was opened in or possibly suggest you to convert it to a more suitable one, i.e. programs behave the other round, compared to Gimp. So maybe the expected behaviour also depends on the OS you use.
But even under Windows, nobody would expect that a dedicted export routine would clean the dirty flag.
1. I'm not hung up on the dirty flag, just trying to brainstorm.
2. What I was proposing was a picture tweaking/editing mode in which that occurred. Not as a default behaviour of export. If I was in my normal usage mode the current implementation suits me fine (default to xcf and no dirty flag reset on export).
Save v Export behaviour
Brendan Scott (disposableemail@apps.opensourcelaw.biz) wrote:
On 12/04/2013 09:34 PM, Andrew & Bridget wrote:
On 04/12/2013 07:42, Wolfgang Hugemann wrote:
The save/export UI may need more thought.
Why ?
Because if its aim was to prevent me from losing work (transparency edits), it failed.
And removing the save/export difference completely would have prevented you from losing work in what way?
bye, Simon
simon@budig.de http://simon.budig.de/
Save v Export behaviour
On 12/04/2013 11:22 PM, Simon Budig wrote:
Brendan Scott (disposableemail@apps.opensourcelaw.biz) wrote:
On 12/04/2013 09:34 PM, Andrew & Bridget wrote:
On 04/12/2013 07:42, Wolfgang Hugemann wrote:
The save/export UI may need more thought.
Why ?
Because if its aim was to prevent me from losing work (transparency edits), it failed.
And removing the save/export difference completely would have prevented you from losing work in what way?
I haven't suggested "removing the save/export difference completely". On the contrary, I have said that the save/export distinction is ordinarily my preferred behaviour. What I have also said is that if the purpose of the distinction is to preserve work, it didn't serve that function for me. That suggests to me that the UI "may need more thought".
You ought to ask your question of someone else.
Save v Export behaviour
Brendan Scott (disposableemail@apps.opensourcelaw.biz) wrote:
What I have also said is that if
the purpose of the distinction is to preserve work, it didn't serve that function for me. That suggests to me that the UI "may need more thought".You ought to ask your question of someone else.
To me it is entirely unclear, what in your workflow differenciates a "good" warning dialog from a "bad" warning dialog.
Without a hint from you we're 100% in the "Do-What-I-Mean-Button" ballpark which is not really helping with the "more thought" we might need.
I gathered from your mail, that you lost work because the save/export distinction conditioned you into clicking the warning away. So, if you don't want us to remove the warning, what are our options?
Bye, Simon
simon@budig.de http://simon.budig.de/
Save v Export behaviour
* I was so used to hitting "close without saving" to get rid of the irrelevant save dialog box that I didn't realise when it really was relevant; and
It is only irrelevant if you are editing images without layers etc. (As the image can be re-opened and re-edited.)
Where as the target audience (from what I understand) that GIMP is being aimed at is the user that requires layers etc, and these users would think that saving to .xcf format is very relevant and should be an important part of that users workflow.
Save v Export behaviour
This entire debate could be ended if the developers would simply add an option to the Preferences that allowed the individual user to select between the new Save/Export mechanism and the old 2.6 Save-to-Type-Opened mechanism (including the "specified extension" override), with the default being the new method. Gimp would continue to operate out of the box in the "professional" mode unless a user made the conscious decision to reassert the previous save method -- knowing exactly what "dangers" this would pose. No one gets hurt. Everyone could be happy.
However, this option has been discussed before and the developers refuse to consider it -- period. I have never heard any reasonable argument for not being willing to implement this solution. It is a great mystery why they wish to alienate such a large portion of the existing user base over what should be a very trivial matter.
Save v Export behaviour
04 . 2013 . 21:20 "Jeffery Small" :
However, this option has been discussed before and the developers refuse
to
consider it -- period. I have never heard any reasonable argument for not being willing to implement this solution. It is a great mystery why they wish to alienate such a large portion of the existing user base over what should be a very trivial matter.
If you are into great mysteries, my recommendation would be Phaistos disk. Lots of room for speculations there. Imagine all the fun you could have :)
Alexandre
Save v Export behaviour
Am 04.12.2013 14:28, schrieb Simon Budig:
Brendan Scott
(disposableemail@apps.opensourcelaw.biz) wrote:
What I have also
said is that if the purpose of the distinction is to preserve work, it didn't serve that function for me. That suggests to me that the UI "may need more thought". You ought to ask your question of someone else.
To me it is entirely unclear, what in your workflow differenciates a
"good" warning dialog from a "bad" warning dialog.
Without a hint
from you we're 100% in the "Do-What-I-Mean-Button"
ballpark which is
not really helping with the "more thought" we might
need.
I
gathered from your mail, that you lost work because the save/export
distinction conditioned you into clicking the warning away. So, if you
don't want us to remove the warning, what are our options?
Bye,
Simon
Based on the various mails on this topic (including "I hate this, give me back my 2.6!") , I'd suggest this
http://tobiaslunte.de/gummibaerchen/save_export_-_confirm_on_close.png [1]
kind of closing-dialog. The stark contrast between the buttons and
the subdued text gives an easy-to-grasp overview on which images have
been saved/exported and the button allows the user to directly take the
necessary actions.
It could be argued whether the first example should
be included considering the product vision; my suggestion would be only
when "export to"/"overwrite" is populated.
Of course this is up for debate, but you wanted a step out of the ballpark and here it is. In case anyone wants to edit the design, here
http://tobiaslunte.de/gummibaerchen/save_export_-_confirm_on_close.xcf [2]
is the corresponding xcf.
--> A similar idea (including only the save-button so that one wouldn't have to go through the images one by one) has popped up before. Unfortunately I couldn't find the original mail in the archives, else I'd be happy to give credit where it's due.
bw,
Tobias Lunte // Tobl
Links:
------
[1]
http://tobiaslunte.de/gummibaerchen/save_export_-_confirm_on_close.png
[2]
http://tobiaslunte.de/gummibaerchen/save_export_-_confirm_on_close.xcf
Save v Export behaviour
is to save a document in the format it was opened in
So, how do you save to .NEF you have imported from RawTherapee ?
Of course there may be import-only formats such as NEF. But if the program can write the format it imported and this format is principly able to preserve the essential information, this is what Windows programs, especially Microsoft programs, do: If you open a CSV with Excel and than try to save it, Excel will save it to CSV by default, but warn you that information might get lost. If you open a DOC file with Word, it is saved as DOC and not as DOCX.
PDF is essentially a graphics format, thus Microsoft considers it probably essentially different from a word processor file. This is why it behaves differently in that situation.
or possibly suggest you to convert it to a more suitable one,
.xcf ?
Yes.
But even under Windows, nobody would expect that a dedicted export routine would clean the dirty flag.
So saving to .jpg in any other program would maintain layers !
I don't see this contradiction. As I said, a dedictated export routine, like exporting a Word processor file as an PDF would not clean the dirty flag. The program would suggest to save your work in its own data format.
As you can take from the CSV / XLS example, the program can warn you if certain features cannot be preserved when saving in the input data format.
...
I've just checked the "Windows 8 User experience guidelines", but they don't seemed to settle this very matter.
Anyway -- no reason to get so excited.
Wolfgang Hugemann
Save v Export behaviour
On 12/04/2013 06:14 PM, Jeffery Small wrote: It is a great mystery why they
wish to alienate such a large portion of the existing user base over what should be a very trivial matter.
Hi
The answer : elitism. Gimp is restricted "to real artists" :-)
Qv
Save v Export behaviour
On 12/4/2013 1:33 PM, qelvin5500 wrote:
On 12/04/2013 06:14 PM, Jeffery Small wrote: It is a great mystery why they
wish to alienate such a large portion of the existing user base over what
should be a very trivial matter.Hi
The answer : elitism. Gimp is restricted "to real artists" :-)Qv _______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
Not this compost again.
Save v Export behaviour
On 12/3/2013 12:26 PM, Richard wrote:
Cleaning the 'dirty' flag after export isn't going to happen - there is a user-made GIMP plug-in that will do this for you (it adds an "Export & Clean" type command to the File menu) but the core behavior isn't negotiable :(
Dirty flag?
Yours in Christ, Joseph A Nagy Jr "Whoever loves instruction loves knowledge, But he who hates correction is stupid." -- Proverbs 12:1 Emails are not formal business letters, whatever businesses may want. Original content CopyFree (F) under the OWL http://copyfree.org/licenses/owl/license.txt
Save v Export behaviour
Date: Wed, 4 Dec 2013 19:26:33 -0600 From: jnagyjr1978@gmail.com
To: gimp-user-list@gnome.org
Subject: Re: [Gimp-user] Save v Export behaviourOn 12/3/2013 12:26 PM, Richard wrote:
Dirty flag?
A.k.a. 'unsaved changes'.
-- Stratadrake
strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.
Save v Export behaviour
Dirty flag?
A.k.a. 'unsaved changes'.
I would like to see the ability to work on an image, export to a certain scale then continue to work on the image without having undo changes due to the scaled export. Could scaling be included in the export routine to over come this ?
Save v Export behaviour
On 12/05/2013 06:51 PM, Andrew_Bridget wrote:
Dirty flag?
A.k.a. 'unsaved changes'.
I would like to see the ability to work on an image, export to a certain scale then continue to work on the image without having undo changes due to the scaled export. Could scaling be included in the export routine to over come this ?
I think that's available in "Save for Web"?
Save v Export behaviour
I would like to see the ability to work on an image, export to a certain scale then continue to work on the image without having undo changes due to the scaled export.
Could scaling be included in the export routine to over come this ?I think that's available in "Save for Web"?
Not in version 2.8...
Save v Export behaviour
On 12/05/2013 12:28 AM, Simon Budig wrote:
Brendan Scott (disposableemail@apps.opensourcelaw.biz) wrote:
What I have also said is that if
the purpose of the distinction is to preserve work, it didn't serve that function for me. That suggests to me that the UI "may need more thought".You ought to ask your question of someone else.
To me it is entirely unclear, what in your workflow differenciates a "good" warning dialog from a "bad" warning dialog.
It "may be" that it's not about warning dialogs. At the moment I'm trying to just describe the issue I have faced.
Without a hint from you we're 100% in the "Do-What-I-Mean-Button" ballpark which is not really helping with the "more thought" we might need.
I gathered from your mail, that you lost work because the save/export distinction conditioned you into clicking the warning away. So, if you don't want us to remove the warning, what are our options?
I will assume then that you haven't seen my earlier posts.
Here is some more detail. Ordinarily (since May when I started using GIMP regularly-ish), I work in xcf and have no desire to export except maybe once at the end. So, the default set up suits me most of the time.
There are two occasions where I used export rather than save. The first was doing some levels and cropping on photos I had taken (scores, but I've not processed them all yet). That went swimmingly, but the close dialogs were annoying. The second was editing out a background on 70 odd (poorly-) chroma keyed photos (to be composited with a background by someone else). I got through a small number before realising that I was exporting to jpg, losing the transparent areas I'd added.
I lost some work because of the format I was using and the save/export distinction didn't avoid that. Partly this was because I was habituated to ignore the save as xcf warning. This is probably because the warning appears no matter what the risk is (or, in the case of my cropping etc, when there was no risk). The save warnings are false positives because they are triggered by an irrelevant condition (ie close with export but no save). The true trigger for a warning was that I was trying to export an image to an inconsistent format (ie image has transparency but format doesn't support it).
I am confident that I would have taken more notice of a warning (because it would be out of the ordinary) if it: (a) didn't pop up the false positives; but (b) did pop up an inconsistent format warning. Apparently this functionality or something like it was in 2.6?
Save v Export behaviour
Date: Fri, 6 Dec 2013 00:03:53 +1100 From: disposableemail@apps.opensourcelaw.biz To: gimp-user-list@gnome.org
Subject: Re: [Gimp-user] Save v Export behaviourI am confident that I would have taken more notice of a warning
(because it would be out of the ordinary) if it: (a) didn't pop up the false positives; but (b) did pop up an inconsistent format warning. Apparently this functionality or something like it was in 2.6?
I'm not familiar with the specifics, but that is right, in 2.6 GIMP would inform you of precisely what (transparency, layers, etc.) could not be output to a given file format.
For the 'crying wolf' (false positive) scenario one idea I've been thinking is a user preferences option to suppress that warning for exported images not attached to an XCF file.
-- Stratadrake
strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.
Save v Export behaviour
Brendan Scott wrote:
On 12/05/2013 12:28 AM, Simon Budig wrote:
Without a hint from you we're 100% in the "Do-What-I-Mean-Button" ballpark which is not really helping with the "more thought" we might need.
I gathered from your mail, that you lost work because the save/export distinction conditioned you into clicking the warning away. So, if you don't want us to remove the warning, what are our options?
I will assume then that you haven't seen my earlier posts.
Here is some more detail. Ordinarily (since May when I started using GIMP regularly-ish), I work in xcf and have no desire to export except maybe once at the end. So, the default set up suits me most of the time.
There are two occasions where I used export rather than save. The first was doing some levels and cropping on photos I had taken (scores, but I've not processed them all yet). That went swimmingly, but the close dialogs were annoying. The second was editing out a background on 70 odd (poorly-) chroma keyed photos (to be composited with a background by someone else). I got through a small number before realising that I was exporting to jpg, losing the transparent areas I'd added.
I lost some work because of the format I was using and the save/export distinction didn't avoid that. Partly this was because I was habituated to ignore the save as xcf warning. This is probably because the warning appears no matter what the risk is (or, in the case of my cropping etc, when there was no risk). The save warnings are false positives because they are triggered by an irrelevant condition (ie close with export but no save).
But jpg is a lossy format, so by exporting to jpg in the first case you were loosing information - so a warning would still be appropriate. It's just that in your first case you were happy with losing information, while in the second case you weren't. How is GIMP to know what you're happy to loose, and what you're not, at any given time?
The true trigger for a warning was that I was trying to export an image to an inconsistent format (ie image has transparency but format doesn't support it).
I am confident that I would have taken more notice of a warning (because it would be out of the ordinary) if it: (a) didn't pop up the false positives; but (b) did pop up an inconsistent format warning. Apparently this functionality or something like it was in 2.6?
Save v Export behaviour
On 12/04/2013 09:40 PM, John Meyer wrote:
On 12/4/2013 1:33 PM, qelvin5500 wrote:
On 12/04/2013 06:14 PM, Jeffery Small wrote: It is a great mystery why they
wish to alienate such a large portion of the existing user base over what
should be a very trivial matter.Hi
The answer : elitism. Gimp is restricted "to real artists" :-)Qv _______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-listNot this compost again.
You do not not seem to appreciate dark humor.
Strange threat...
Qv
Save v Export behaviour
I hadn't wanted to comment on the earlier threads bc they were too heated.
Initially my work was with .xcfs natively, so this wasn't an issue for me. More recently though I've had to do a lot of spot edits on jpgs and pngs. I would welcome a "responsible adult" mode which didn't bug me about saving the file as xcf.This _even though_ I lost edits last week on a batch of files because I forgot jpgs don't support transparency. Ironically I ignored the save as xcf warnings in that case. More useful I think would be a dialog which identified for what I was about to lose (transparency, layers or whatever) in the target format, and then accepted my decision (and cleaned whatever dirty flag is set on edits) if I clicked ok. Harder to implement though I imagine.
It's amazing to see that the fires are still burning on this issue even after several years. But it's not hard to understand why - a clunkier and more insulting UI behaviour is hard to find anywhere. Congratulations to the Gimp team for creating the most controversial UI "feature" in FOSS history!
First of all it breaks the traditional ability to save the file you're working on, a concept common to most other software.
Secondly, it forces you to use a file format which is not universally supported, a surprising decision by a team of open source advocates.
Thirdly it makes it far too easy to overwrite a file unintentionally, as the "overwrite" option sits right next to the "export" submenu and has no confirmation (this has happened to me, more than once!).
Fourthly it insults professional users by unnecessarily enforcing a particular workflow (a big no-no), and by pestering us with inane "warning" dialogs. Hello? Some of us know what file we're editing, what layers are and what lossy vs. lossless formats mean. People who do not understand these concepts have no business using a professional tool (which is that the Gimp is, right?) and frankly deserve to end up with artifact riddled originals and lost layers.
Fiftly(?), it seems to make the assumption that other file formats are somehow "inferior" - as someone who regularly uses PNG, GIF, TIFF, JPEG and PSD (and occassionally other ones too) I beg to differ; there's a time and place for all of them.
Sixthly (this is getting ridiculous) it makes it necessary to create an additional XCF file for every non-XCF image you want to edit, which makes working on web projects a hassle as the additional XCFs have no function and just add bloat to the project.
Seventhly (can you even say that?) having just read some of the vast number of complaints about this "feature" that can be found here and all over the web the whole thing serves to make the Gimp team look like a bunch of arrogant t***s, with their narrow-minded insistence that they alone know what "professional" users need and that the rest of us are somehow stupid for not appreciating the amazing improvement this represents. I'm sure they're all really nice and friendly people, but the defensive attitude they display whenever this issue comes up makes me wonder if there's perhaps some nagging doubts about whether it really was a good idea (hint: it wasn't).
This is the first time I speak up on this issue - and I registered here only to, erm, register my complaint, in the vain hope that it will help push for a more sensible solution. I'm a realist though, and the attitude displayed by the Gimp team makes it abundantly clear that professional users will not be heard on this issue - they obviously already know what is right and have no need to listen to what anyone says. I can't get over the unpleasant feeling that the prime motivator for this stupidity is a desire to force the establishment of XCF as a universal format for images, but if that is the goal I'd suggest you invest your time in making your software competitive with Photoshop not only in functionality but also in usability - then maybe uptake by professionals will increase and the Gimp will become more than the amateur's budget alternative. The fact that you feel the need to point out that some successful artist such-and-such actually uses Gimp speaks volumes.
Thank you for listening.
Save v Export behaviour
On Tue, 2014-04-15 at 05:49 +0200, VintageGimp wrote:
I'm replying only to correct a couple of factual errors, or least places where readers may draw incorrect conclusions.
Thirdly it makes it far too easy to overwrite a file unintentionally, as the "overwrite" option sits right next to the "export" submenu and has no confirmation (this has happened to me, more than once!).
The Save menu item you want back didn't ask for confirmation after the first time either.
Sixthly (this is getting ridiculous) it makes it necessary to create an additional XCF file for every non-XCF image you want to edit, which makes working on web projects a hassle as the additional XCFs have no function and just add bloat to the project.
This is simply false.
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Save v Export behaviour
On Tue, Apr 15, 2014 at 7:49 AM, VintageGimp wrote:
I can't get over the unpleasant feeling that the prime motivator for this stupidity is a desire to force the establishment of XCF as a universal format for images
The only file format we are pushing to become universal is called OpenRaster, and we are not doing it hard enough (fortunately, the MyPaint's team does).
I don't see the point in commenting on the rest of your email. There's not a single insult or a factual error there that I haven't already heard/commented on before.
You will find _pushing_ for something in a free software project while insulting its members and spreading knowingly incorrect information a vain effort.
Alexandre
Save v Export behaviour
The Save menu item you want back didn't ask for confirmation after the first time either.
You are missing my point. The problem is that the "save" option is now next to the [export] option - when it has been my intention to "export" to a new file I have on several occassions clicked [overwrite] by mistake, causing swearing and the throwing of things. Ctrl+S and Ctrl+Shift+S works well in most other software - I and countless others fail to see the benefits of breaking this paradigm.
Save v Export behaviour
The only file format we are pushing to become universal is called OpenRaster, and we are not doing it hard enough (fortunately, the MyPaint's team does).
Then why insisit on allowing users to save their files only in one single proprietary format?
I don't see the point in commenting on the rest of your email. There's not a single insult or a factual error there that I haven't already heard/commented on before.
What I said:
the whole thing serves to make the Gimp team look like a bunch of arrogant t***s, with their narrow-minded insistence that they alone know what "professional" users need and that the rest of us are somehow stupid for not appreciating the amazing improvement this represents. I'm sure they're all really nice and friendly people, but the defensive attitude they display whenever this issue comes up makes me wonder if there's perhaps some nagging doubts about whether it really was a good idea
You're not helping disprove anything here...
Save v Export behaviour
On Tue, Apr 15, 2014 at 2:55 PM, VintageGimp wrote:
The only file format we are pushing to become universal is called OpenRaster, and we are not doing it hard enough (fortunately, the MyPaint's team does).
Then why insisit on allowing users to save their files only in one single proprietary format?
XCF is not proprietary. It's open, documented, and supported by 3rd party software.
What I said:
the whole thing serves to make the Gimp team look like a bunch of arrogant t***s, with their narrow-minded insistence that they alone know what "professional" users need and that the rest of us are somehow stupid for not appreciating the amazing improvement this represents. I'm sure they're all really nice and friendly people, but the defensive attitude they display whenever this issue comes up makes me wonder if there's perhaps some nagging doubts about whether it really was a good idea
You're not helping disprove anything here...
I have no slightest intention disproving anything for you. You did not come to talk and listen here, you came to have an argument. I will not tolerate that.
Alexandre
Save v Export behaviour
This is simply false.
You're right, it doesn't "make it necessary", it only strongly encourages it.
Save v Export behaviour
I have no slightest intention disproving anything for you. You did not come to talk and listen here, you came to have an argument. I will not tolerate that.
I came to complain - both at what I and many others view as a stupid design decision, and the boneheaded attitude of (some of) the developers. With the complaint being registered, and my point about attitude now proven, I have nothing further to add except this:
I think it is a terrible shame that the only viable alternative to Photoshop fails on usability - and fails so badly that it makes it impossible to fully make the switch. I know I'm not alone in having to keep a computer running Windows for the sole purpose of using Photoshop, not because it provides any functionality that The Gimp is lacking, but because the workflow is so clunky and painful as to make any serious amount of work in it a chore. The reason so many people are upset about this is not that it would take any huge amount of effort on the part of its developers to correct these shortcoming, but because they chose to ignore their users and follow some religious "vision" instead. The "save vs export" controversy is not the only problem here, there are many other annoyances for those who are used to the way the market leading application does things, which of course is why it remains the market leader. Adobe clearly have nothing to fear from your efforts, but it's unfortunate that you inadvertently limit the uptake of Linux as a serious platform for imaging professionals. I use Linux exclusively for _everything_ else, and have found many great FOSS applications to replace the closed source Windows equivalents I used for almost two decades - Inkscape is one good example, which I now actually _prefer_ over Illustrator, LibreOffice is another, with its small footprint and (compared to Word) uncluttered UI. It clearly is possible for Open Source software to not just be good, but actually better than the proprietary applications it competes with - but The Gimp remains a tragic exception.
Save v Export behaviour
XCF is not proprietary. It's open, documented, and supported by 3rd party software.
Surely you are jesting? There are NO other editing applications capable of fully using this format. None. Zip. Zero. It may be open and documented (which is great) - but 3rd party support is still woefully lacking. Perhaps "proprietary" is not the right word here, I'll give you that, but it doesn't seem it would matter much if it was. Sure, there are some viewers, and some applications allow import or export, but natively opening and saving XCFs is not possible in any application that I know of - including, I might add, in Photoshop. Give me a TIFF any day, or a PNG - hell even BMPs are more widely supported.
Save v Export behaviour
On Tue, Apr 15, 2014 at 3:46 PM, VintageGimp wrote:
Perhaps "proprietary" is not the right word here
Only "perhaps"? Since you are referencing to Wikipedia as a credible source, let's use it again:
http://en.wikipedia.org/wiki/Proprietary_format
A proprietary format is a file format of a company, organization, or individual
- that contains data that is ordered and stored according to a particular encoding-scheme, designed by the company or organization to be secret, such that the decoding and interpretation of this stored data is only easily accomplished with particular software or hardware that the company itself has developed. The specification of the data encoding format is not released, or underlies non-disclosure agreements.
Or a proprietary format is a file format
- whose encoding is in fact published, but is restricted (through licences) such that only the company itself or licencees may use it.
None of that applies to XCF. Simply put, you are using words that you don't even understand the meaning of.
I came to complain
http://www.gimp.org/mail_lists.html
Code of Conduct
Mailing lists are an important communication channel between contributors and users of GIMP. Therefore we urge you to follow the following common etiquette rules. Failure to observe them, or instructions from the moderators, may be grounds for reprimand, probation, or removal.
- Be considerate and respectful. Every email in our most popular mailing lists, gimp-user@ and gimp-developer@, will be read by ca. 1,000 subscribers and then aggregated to be seen by an even larger audience. ____Please make sure that you add value to the discussion, avoid repetitive arguments, flamewars____, trolling, and personal attacks.
Alexandre
Save v Export behaviour
None of that applies to XCF. Simply put, you are using words that you don't even understand the meaning of.
Yes, I used "proprietary" incorrectly, my apologies. My point was that XCF is a poorly supported file format - a point which I think was quite clear despite the mistake.
Mailing lists are an important communication channel between contributors and users of GIMP. Therefore we urge you to follow the following common etiquette rules. Failure to observe them, or instructions from the moderators, may be grounds for reprimand, probation, or removal.
Go on then, you know you want to. I know I'll be joining a long list of other banned users who have complained about the same thing. Silencing voices of dissent may make you feel better but won't do much to help your project.
"I cannot lie to you about your chances, but you have my sympathies" - Ash
Save v Export behaviour
I had started a reply on some roadmaps ideas we had discussed on the save/export behavior over the past face to face developer meeting.
Since the thread degenerated into a "gimp developers are stupid" thing yet again, I will refrain from posting what we have talked about and is proposed to the (possibly far away) future.
Now what becomes relevant here instead is that one other thing we've talked about in the meeting is the need of a code of conduct to places of discussing GIMP, that will access proper behavior in discussion forums - so people wanting to bash GIMP may want to try learning to do so in constructive ways before the code of conduct is in place. Ad-hominem attacks will certainly be addressed by that.
Regards,
js -> wrote:
None of that applies to XCF. Simply put, you are using words that you don't even understand the meaning of.
Yes, I used "proprietary" incorrectly, my apologies. My point was that XCF is a poorly supported file format - a point which I think was quite clear despite the mistake.
Mailing lists are an important communication channel between contributors and users of GIMP. Therefore we urge you to follow the following common etiquette rules. Failure to observe them, or instructions from the moderators, may be grounds for reprimand, probation, or removal.
Go on then, you know you want to. I know I'll be joining a long list of other banned users who have complained about the same thing. Silencing voices of dissent may make you feel better but won't do much to help your project.
"I cannot lie to you about your chances, but you have my sympathies" - Ash
--
VintageGimp (via www.gimpusers.com/forums) _______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Save v Export behaviour
2014-04-15 13:30 GMT+02:00 VintageGimp :
I use
Linux exclusively for _everything_ else, and have found many great FOSS applications to replace the closed source Windows equivalents I used for almost
two decades - Inkscape is one good example, which I now actually _prefer_ over
Illustrator,
Not that I'm trying to shock you, but Inkscape will switch to the same Save/Export behavior then Gimp has in on of the next releases.
Regards, Tobias
Save v Export behaviour
On Tue, 2014-04-15 at 10:57 -0300, Joao S. O. Bueno wrote:
Ad-hominem attacks will
certainly be addressed by that.
A difficulty is that people often wait until they are very frustrated before complaining. Sometimes it sounds like a small child, "waaah i have to press control-e or control-shift-e instead of control-s or control-shift-s like i've been doing since i was six years old" but I do think there are some real issues behind the complaints. [1]
The answer isn't "revert". I think it's to move to more of a "project-based workflow" and make the distinction more useful and obvious.
Liam
[1] I don't mean to suggest that "VintageGimp" is behaving like a small child, but that the cumulative effect of many people's complaints seems to be, "don't make any changes" so that after a while there's a danger it's how we perceive the complaints.
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Save v Export behaviour
On Tue, Apr 15, 2014 at 5:57 PM, Joao S. O. Bueno wrote:
Now what becomes relevant here instead is that one other thing we've talked about in the meeting is the need of a code of conduct to places of discussing GIMP, that will access proper behavior in discussion forums
That sounds a bit like patronizing.
Frankly, I don't want to impose our CoC on 3rd party discussion forums. If local administrators are fine with some quite amazing examples of hostility towards the GIMP team, so be it. If they think that freedom of speech excuses disruptive behavior, I most certainly am not the person to tell them it's not the way to build a healthy community.
P.S. Also, I think, this discussion rather belongs to gimp-developer@.
Alexandre
Save v Export behaviour
Date: Tue, 15 Apr 2014 12:46:21 +0200 From: forums@gimpusers.com
To: gimp-user-list@gnome.org
CC: team@gimpusers.com
Subject: [Gimp-user] Save v Export behaviourThe Save menu item you want back didn't ask for confirmation after the first time either.
You are missing my point. The problem is that the "save" option is now next to the [export] option - when it has been my intention to "export" to a new file I have on several occassions clicked [overwrite] by mistake, causing swearing and the throwing of things.
That can vary depending on what your source file format is. A freshly opened JPEG file, for example, will not silently overwrite the original unless you've previously exported it within the same session, since format settings like compression level aren't detectable at file load time.
Unfortunately it is still true that an accidental overwrite is not as harmless as an accidental save (a particular risk for those who often perform resized exports).
-- Stratadrake
strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.
--
VintageGimp (via www.gimpusers.com/forums) _______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list