proposed solution for: protection from information loss
This discussion is connected to the gimp-developer-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.
More intelligent user protection from information loss
The current protection mechanism for closing images is insufficient as it doesn't differentiate between 'saved' and 'exported'.
Symptom 1: exporting to .png requires clicking a nag-screen
Sympton 2: closing a multi-layered image which has been exported before doesn't give a warning about loosing the unsaved layer information!
So the problem is displaying the correct warning at the wrong time. The information loss doesn't happen when exporting to .png, but when closing an image which hasn't been saved to .xcf
Solution:
1) the export warning for flat file formats should be optional ('do not show this dialog again') 2) closing images, which have not been saved to .xcf, should trigger a warning ('you have already exported this image to .png, but you will loose all your layering/path information if you close the image now')
The UI Brainstorm didn't seem the right place to post this, should i file it as a bug report?
peter
More intelligent user protection from information loss
Solution:
1) the export warning for flat file formats should be optional ('do not show this dialog again')
2) closing images, which have not been saved to .xcf, should trigger a warning ('you have already exported this image to .png, but you will loose all your layering/path information if you close the image now')
I'm going to echo my support for this. The nags on saves are counterproductive. Further more you will get them even when you are doing a "Save as Copy..." that by essence is an intentional export and can cause no dataloss... Any export should be handled with a nag on closing the actual window with the path&layer information, not on export itsself.
More intelligent user protection from information loss
Alexia Death writes:
I'm going to echo my support for this. The nags on saves are counterproductive.
And often they're not even right -- e.g. "The image has transparency, flatten?" shows up on anything with an alpha channel even if every pixel is fully opaque. All those dialogs do is train the user to click OK without reading.
...Akkana
More intelligent user protection from information loss
On Saturday 07 June 2008 20:01:17 Akkana Peck wrote:
Alexia Death writes:
I'm going to echo my support for this. The nags on saves are counterproductive.
And often they're not even right -- e.g. "The image has transparency, flatten?" shows up on anything with an alpha channel even if every pixel is fully opaque. All those dialogs do is train the user to click OK without reading.
Exactly... Witch has bitten me in the ass a few times... Namely the bizare confirmation to save a layer mask pops up right exactly before that. That's another bizare thing about saving... And since the number of dialogs varies between formats has been *click* *click* *click* Close, load "Bah! Mask." How often would someone need to save just the mask? How about having a separate save option for that in the menu?
-- Alexia
More intelligent user protection from information loss
On Sat, Jun 7, 2008 at 12:46 PM, Alexia Death wrote: [..]
Exactly... Witch has bitten me in the ass a few times...
That evil witch has bitten me a few times as well - even with the pentagram drawn under my workstation ;)
Chris
More intelligent user protection from information loss
Alexia Death wrote:
How about having a separate save option for that in the menu?
There are several feature requests about a changed export behavior:
http://bugzilla.gnome.org/show_bug.cgi?id=75328 http://bugzilla.gnome.org/show_bug.cgi?id=75459 http://bugzilla.gnome.org/show_bug.cgi?id=164709
It has also been suggested to merge some of its actions into the save dialog:
http://bugzilla.gnome.org/show_bug.cgi?id=119545
HTH, Michael
More intelligent user protection from information loss
On Saturday 07 June 2008 21:47:06 Michael Schumacher wrote:
There are several feature requests about a changed export behavior:
http://bugzilla.gnome.org/show_bug.cgi?id=75328 http://bugzilla.gnome.org/show_bug.cgi?id=75459 http://bugzilla.gnome.org/show_bug.cgi?id=164709
It has also been suggested to merge some of its actions into the save dialog:
None of which handle he issue as a whole or propose a solutions that have been suggested here... Further more, since the things are still in status quo, I have to deduct that none of these has been considered "The Right Solution" by a person that could actually implement it. Some input from our missing in action GUI guru(Oy Peter, yes you!) would be appropriate here in my opinion, preferably in a form of a spec how this is supposed to work and then perhaps somebody, maybe even me(since my other stuff is waiting for a spec also) could work on it....
Exactly... Witch has bitten me in the ass a few times...
That evil witch has bitten me a few times as well - even with the pentagram drawn under my workstation ;)
You must put that pentagram under your chair, that way it protects your ass. This has worked for me since I did it (or I just have been lucky...) :P.
-- Alexia
More intelligent user protection from information loss
On Sat, 07 Jun 2008 19:46:24 +0200, Alexia Death wrote:
On Saturday 07 June 2008 20:01:17 Akkana Peck wrote:
Alexia Death writes:
I'm going to echo my support for this. The nags on saves are counterproductive.
And often they're not even right -- e.g. "The image has transparency, flatten?" shows up on anything with an alpha channel even if every pixel is fully opaque. All those dialogs do is train the user to click OK without reading.
Exactly!
Too many "friendly" comfirmation dialogues and we find ourselves in MSland where the user just goes yes.. yes.. yes.. without even reading. One big problem I have with my software is a user reports an issue and I ask if there was not an error message. "Err , maybe I'm not sure... I think so, I did not read it".
This is all a result of MS dumbing down the user. All the pointless confirmations like "you just pressed cancel , are you really, really sure you meant cancel? Would you like to try again? " just anesthetise the user to whatever pops up.
So. first thing to realise is that your user is not a complete imbecile (which is the premise of MS). If the user choses to work in png and it does not have layers we don't need to bug him at every turn. He won't "lose his data" it will just be less editable next time.
Second, if we "know" the only way to work is xcf it is not the function of gimp to badger the user into submission if he does not want to user that format for whatever reason.
Once again, gimp claims to be top end this and that , not grandma's tool for removing red-eye from her birthday snapshots. We should credit the user with some intellegence.
Things like this just generally get in the way.
Exactly... Witch has bitten me in the ass a few times... Namely the bizare
confirmation to save a layer mask pops up right exactly before that. That's
another bizare thing about saving... And since the number of dialogs varies
between formats has been *click* *click* *click* Close, load "Bah! Mask." How
often would someone need to save just the mask? How about having a separate
save option for that in the menu?-- Alexia _______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
More intelligent user protection from information loss
Hi,
On Sat, 2008-06-07 at 14:51 +0200, gib_mir_mehl@gmx.net wrote:
The current protection mechanism for closing images is insufficient as it doesn't differentiate between 'saved' and 'exported'.
Yes, that is well-known and the plan is to change that at some point. But there is no one actively working on it. There are so many other much more interesting things to do and GIMP only has a very small group of active developers.
Sven
More intelligent user protection from information loss
On Sunday 08 June 2008 14:28:17 Sven Neumann wrote:
On Sat, 2008-06-07 at 14:51 +0200, gib_mir_mehl@gmx.net wrote:
The current protection mechanism for closing images is insufficient as it doesn't differentiate between 'saved' and 'exported'.
Yes, that is well-known and the plan is to change that at some point. But there is no one actively working on it. There are so many other much more interesting things to do and GIMP only has a very small group of active developers.
And apparently nobody can really work on things whether interesting or not without a spec... So how about making a spec how this is SUPPOSED to be handled, and then hoping somebody interested enough comes along to actually implement it? With spec I'd say chances of that happening are tenfold, and odds of something usable coming out of it are at least 80%.
-- Alexia
proposed solution for: protection from information loss
proposed spec:
File Open/Save/Save_as_Copy only work on .xcf - all other formats must use File Import/Export.[1]
Add File/Import and Export to handle alien formats.
File/New and File/Import would be very similar: they both create a new image with various attributes. New gets the the attributes from the dialog, Import gets them from the image file. Currently, File/New, OK, file/Close does not produce a nag. (good.) File/Import, File/Close would not nag.
File/New currently does not name the image. That gets asked for on save. The same would apply to File/Import: it would not inherit the name. File/Save would default the name to Import name, but using .xcf instead of ext of Import. File/Export would default to the Imported name.ext and type. (example: File/Import foo.gif, File/Save prompts for name, defaults to foo.xcf. File/Export defaults to foo.gif)
command line usage would still work with any format. but that only applies to 'loading' the file, not what it's name is. (i think all save/export cases are covered above)
The only nag will be when trying to close a touched image that has not been "saved" (which by #1 would always be as .xcf)
File/Preference option to turn off the "you will loose info" nag. Possibly some options to tune it, like "Only nag if not saved in any format." (I have a feeling that is more confusing than it is worth, but would be easy enough to implement, and would save my ass when I accidentally close the wrong image window.) I am pretty sure there is a usability law that says an app should always warn before discarding data, so I am pretty sure there should always be the "Save the changes to 'Untitled' before closing?" nag.
I think this would remove the need for all nags except "save unchanged?"
It would add steps when using gimp to edit an alien format. current: gimp foo.gif, (or launch gimp, Open foo.gif), edit, Save, Close. proposed: gimp foo.gif, (or launch gimp, Import foo.gif), edit, Export, Hit Save button (filename defaulted to foo.gif)[2], Close, hit Don't_Save in respose to "Save Unchanged...?"
Damm... there is still something that I am not sure how to handle: When Exporting, should it nag when you are overwriting an existing file? I think the answer is 'yes' which will add another step. I can see gimp being intelligent about this and doing the obvious thing (don't nag if using the default) but that might be crossing a line into automagic. maybe another Preferences option.
One question: should gimps 'normal' behavior make it easy (minimum nags) to edit
A) alien formats,
or
B) gimps native format?
I am kinda liking the idea that gimp makes it easy to edit/save gimp images, and alian formats are derivatives, not the primary storage for images.
Did I mis anything?
Carl K
proposed solution for: protection from information loss
Carl Karsten wrote:
proposed spec:
File Open/Save/Save_as_Copy only work on .xcf - all other formats must use File
Import/Export.[1]Add File/Import and Export to handle alien formats.
Save_as_Copy and Export are the same (the user should be able to export as .xcf).
This approach shifts the problems from saving to opening.
Additionally, the 'forced .xcf' behaviour can be quite nagging - consider
user experience for a quick Levels adjustment to a photo:
1- Open doesn't work
2- Import
3- adjustments, all jpeg-compatible
4- Save only allows .xcf, which is overkill here
5- Step back to Export
6- remaining image mysteriously nags on closing
Where i agree with you, is that gimp should support the typical workflow which centers around a .xcf main document with several regularily updated offsprings. But that is another topic.
To answer your question: please, A and B.
Another idea i'm currently tinkering with: Don't all those export troubles disintegrate once we presume a little more confidence in the undo function?
What if Save foo.jpg would actually flatten the image? If that was not intended, the user could easily undo and use Export the next time. Advantage: The result can be seen, with layers&alpha being lost. This is much more intuitive than textual explanations...
so long, peter
More intelligent user protection from information loss
Sven Neumann wrote:
Hi,
On Sat, 2008-06-07 at 14:51 +0200, gib_mir_mehl@gmx.net wrote:
The current protection mechanism for closing images is insufficient as
it doesn't
differentiate between 'saved' and 'exported'.
Yes, that is well-known and the plan is to change that at some point. But there is no one actively working on it. There are so many other much more interesting things to do and GIMP only has a very small group of active developers.
That means it makes sense to work on a temporary solution before the big UI overhaul happens? Sounds like a good place to start hacking the gimp .->
peter
proposed solution for: protection from information loss
gib_mir_mehl@gmx.net writes:
Additionally, the 'forced .xcf' behaviour can be quite nagging - consider user experience for a quick Levels adjustment to a photo:
[ ... ]
Where i agree with you, is that gimp should support the typical workflow which centers around a .xcf main document with several regularily updated offsprings. But that is another topic.
For that workflow, what would be even more useful is to be able to have a command that could do both: save the current .xcf (.gz or .bz2) AND, from the same menu item or keystroke, save a copy to a simpler format. Then you wouldn't have to go back and forth between Save and Save a Copy every time you make a change, and you wouldn't have to confirm the copy's filename every time you saved it.
It would be great if it were possible to write a plug-in that would do that, even if gimp didn't include it natively. It would need to get the current filename (that's easy already, gimp-image-get-filename) and also what the last "save a copy" filename was (not so easy -- I don't think there's an API to get that now, is there?)
What if Save foo.jpg would actually flatten the image? If that was not intended, the user could easily undo and use Export the next time. Advantage: The result can be seen, with layers&alpha being lost. This is much more intuitive than textual explanations...
That trains users not to save intermediate results in some cases. Consider the case where you need to add text to a jpeg with the result being another jpeg for a website; yet you still might want to try several different fonts, text strings etc. I know, you're thinking "Why not save the intermediates as xcf?" But if there are only a couple of layers and fifteen minutes of work, it doesn't always seem worth the extra disk space to save an xcf in addition to the final jpg.
...Akkana
More intelligent user protection from information loss
Hi,
On Mon, 2008-06-09 at 01:45 +0200, gib_mir_mehl@gmx.net wrote:
That means it makes sense to work on a temporary solution before the big UI overhaul happens?
There is no such thing as the big UI overhaul. It also does not make sense to work on temporary solutions. Instead someone needs to sit down with the UI team and work out a complete solution for Save and Export, and then start to implement it.
Sven
More intelligent user protection from information loss
Sven Neumann wrote:
Instead someone needs to sit down with the UI team and work out a complete solution for Save and Export, and then start to implement it.
In that case I propose an IRC based scheduled and announced meeting on this topic with the UI team? That way anybody who wants to can give input and the output can be a complete spec for this. However the UI team seems to have vanished atm...
-- Alexia
More intelligent user protection from information loss
Hi,
On Mon, 2008-06-09 at 09:32 +0300, Alexia Death wrote:
In that case I propose an IRC based scheduled and announced meeting on this topic with the UI team? That way anybody who wants to can give input and the output can be a complete spec for this. However the UI team seems to have vanished atm...
No need to hurry. We are now talking about changing the Save/Export logic for almost a decade. If we can agree on the spec before 2.6 is out, then we can put it on the roadmap for GIMP 2.8 and actually try to get it done in time.
Sven
proposed solution for: protection from information loss
Von: Akkana Peck
For that workflow, what would be even more useful is to be able to have a command that could do both: save the current .xcf (.gz or .bz2) AND, from the same menu item or keystroke, save a copy to a simpler format. Then you wouldn't have to go back and forth between Save and Save a Copy every time you make a change, and you wouldn't have to confirm the copy's filename every time you saved it.
Something like this has been brought up during the first usability meeting, where some of the boring tasks a user has to do have been identified.
It would be great if it were possible to write a plug-in that would do that, even if gimp didn't include it natively. It would need to get the current filename (that's easy already, gimp-image-get-filename) and also what the last "save a copy" filename was (not so easy -- I don't think there's an API to get that now, is there?)
For ages I've heard rumours about a feature that lets file save plug-ins pass a save operation throught to other save plug-ins. I'm not sure if this does exists, as I haven't seen any example yet (to be fair, I didn't search, either), but maybe this can be used here.
HTH, Michael
proposed solution for: protection from information loss
Hi all,
Carl Karsten wrote:
proposed spec:
File Open/Save/Save_as_Copy only work on .xcf - all other formats must use File Import/Export.[1]
What about using just Import/Export?
The GIMP could take care of saving automatically, e.g. by writing XCFs to a private folder. Import/Export work on all filetypes. Closing an image writes an XCF to the private folder. Closed images can be retrieved via File->Recent
This leaves open the problem of when to delete the XCFs.
Throwing out Open/Save/Save_as_Copy as a whole solves a lot of issues.
cheers,
peter
proposed solution for: protection from information loss
On Fri, 2008-06-13 at 06:20 +0200, gib_mir_mehl@gmx.net wrote:
Hi all,
Carl Karsten wrote:
proposed spec:
File Open/Save/Save_as_Copy only work on .xcf - all other formats must use File Import/Export.[1]
Yesterday I saved an image in xcf by mistake, by mistyping the .png at the end of the filename (left off the dot).
Usually if I type a filename ending in .png though, I don't want an xcf file to be created.
What about using just Import/Export?
The GIMP could take care of saving automatically, e.g. by writing XCFs to a private folder.
How then do I give the xcf file to someone else, or back it up? I'd quickly have several hundred gigabytes of data there if I wasn't careful, too.
Throwing out Open/Save/Save_as_Copy as a whole solves a lot of issues.
A long-term gnomish model might be to make it easier to drag things onto the desktop (or into folders in the file manager), but people use gimp also in other environments.
It's important to remember that some of the interactions between gimp and content management systems are and will remain manual (e.g. when to save an interim "milestone" copy, and when the work is finished...)
Also, right now, I can use Save As, do some changes, undo the changes, and see where I had got to when the image is marked as unchanged (the star goes away from the window title for example).
But maybe a note in the Undo History about "image was saved here" would be even more useful to me and clearer to others.
Liam
proposed solution for: protection from information loss
Hi,
On Sat, 2008-06-14 at 13:43 -0400, Liam R E Quin wrote:
A long-term gnomish model might be to make it easier to drag things onto the desktop (or into folders in the file manager), but people use gimp also in other environments.
You can already do that in GNOME. Drag the image preview from the toolbox (you need to enable the image preview there in the Preferences dialog) to the GNOME desktop or to the file manager and the image will be saved there. The protocol to do this is called XDS and GIMP supports it since version 2.4.
Sven