Re: [Gimp-developer] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposed solution for: protection from information loss
On Fri, 2008-06-13 at 06:20 +0200, [EMAIL PROTECTED] 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 -- 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 www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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 -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposed solution for: protection from information loss
> Von: Akkana Peck <[EMAIL PROTECTED]> > 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 -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposed solution for: protection from information loss
[EMAIL PROTECTED] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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 -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer