Re: [Gimp-developer] Specs for Export/Save User Interface
On Sat, 2008-06-14 at 19:17 +0200, Ingo Ruhnke wrote: > On Sat, Jun 14, 2008 at 6:59 PM, Robert Krawitz <[EMAIL PROTECTED]> wrote: > > One issue that needs to be considered with that is what is done with > > very large images. > > In a perfect work there would be a way to not save the image itself, > but only the operations done on it since the last save, which could > then be replayed back at recovery. > > For the short term a simple "Do not auto-save when larger then X > bytes" switch would likely be enough. I also work with large (or largeish) images on a daily basis. I don't always have disk space to save a copy, and even if I did, it can be a wait of several minutes, especially on the laptop, just for a 10,000 x 7,000 pixel image. A Do-not-autosave-if-larger-than is a hack, and I fear it would remove any motivation for a better fix -- I'd rather wait for the Coming of the Goat, when a reworked undo system and non-destructive editing may make this a lot easier to implement. 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] Specs for Export/Save User Interface
Ingo Ruhnke wrote: > On Sat, Jun 14, 2008 at 4:29 PM, <[EMAIL PROTECTED]> wrote: > > The basic idea is to forbid 'Save' to PNG here. > > Which of course would be stupid, since PNG is a perfectly valid > information-loss-free choice in many cases err, that sentence was with regard to the example in discussion. Where loss free saving is possible, no nags would appear (compression loss get neglected). Still this would give some user surprise: "last time ctrl-s worked, but now that i have added some text, ctrl-s gives a nag screen?" [..] > A useful addition to Gimp would be an auto-save. Not only could it be > used to periodically save the image to prevent data loss in case of > crashes, it could also be used to store .xcf files for exported files > automatically i bet that's the path GIMP will finally follow. peter -- 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] Specs for Export/Save User Interface
On Sat, Jun 14, 2008 at 6:59 PM, Robert Krawitz <[EMAIL PROTECTED]> wrote: > One issue that needs to be considered with that is what is done with > very large images. In a perfect work there would be a way to not save the image itself, but only the operations done on it since the last save, which could then be replayed back at recovery. For the short term a simple "Do not auto-save when larger then X bytes" switch would likely be enough. -- WWW: http://pingus.seul.org/~grumbel/ Blog: http://grumbel.blogspot.com/ JabberID: xmpp:[EMAIL PROTECTED] ICQ: 59461927 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Specs for Export/Save User Interface
Date: Sat, 14 Jun 2008 18:32:04 +0200 From: "Ingo Ruhnke" <[EMAIL PROTECTED]> A useful addition to Gimp would be an auto-save. Not only could it be used to periodically save the image to prevent data loss in case of crashes, it could also be used to store .xcf files for exported files automatically, when opening such an exported file Gimp could then offer an option to recover the original .xcf data from the auto-save. One issue that needs to be considered with that is what is done with very large images. For example, I have a 96 megapixel image that with multiple layers and all that winds up at over 900 megabytes. Even with a very fast computer and RAID array, the autosave delay will be significant; on the computer I created this on (Athlon 64 3000+ with 2 GB and a drive that would get 40 MB/sec on a good day) the delay would be unacceptable (as I recall, it took at least a minute to save this, sometimes several minutes). There's also the storage implication of this. -- Robert Krawitz <[EMAIL PROTECTED]> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gutenprint --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Specs for Export/Save User Interface
On Sat, Jun 14, 2008 at 4:29 PM, <[EMAIL PROTECTED]> wrote: > The basic idea is to forbid 'Save' to PNG here. Which of course would be stupid, since PNG is a perfectly valid information-loss-free choice in many cases, same with many other data formats. Not every work includes dozens of layers and stuff, many image manipulation happen without any of that and thus is perfectly save in almost any format, introducing a forced export would we very cumbersome and non-intuitive. To sum some of my thoughts things up: The export file dialog is currently a bit confusing, since the meaning of 'Ignore' isn't obvious. I think "Ignore" should either be renamed to "Save Current Layer" or removed and the same functionality offered via a menu entry "File/Save Current Layer". I found "File/Save As Copy" a little confusing at first, since its not obvious how it differs from a plain "Save", in its functionality it is similar to what other applications offer as "Export", except that it doesn't restrict the exported format, which is a good thing, since I always found it annoying to be forced to switch to another dialog just because I wanted to save in a different format. So while not obvious at first, it does what the name says, is used in other Gnome apps and doesn't cause any damage when used instead of "Save". So leave it as is. When it comes to information loss due to compression as with JPEGs a reorder/rename/change of the File menu functions won't help. The user simply needs to learn what a JPEG does, something that could be easily done for example with a better JPEG export dialog that gives a preview of the current quality setting. xcf file ending is a non-intuitive, it is not obvious that this is the native Gimp for format. It is already listed at the top in the file format box, maybe it could be made even clearer, for example by inserting a separator between the native formats and the non-native ones. "Gimp xcf image" could be renamed to something more obvious "Native Gimp image" or something like that to make it clearer that it is the 'real thing' instead of just an export format. There already is a nag-screen informing the user of what he is going to do, so I don't see any real danger of information loss. A way to perfamently hide the nag screen however might be nice. A useful addition to Gimp would be an auto-save. Not only could it be used to periodically save the image to prevent data loss in case of crashes, it could also be used to store .xcf files for exported files automatically, when opening such an exported file Gimp could then offer an option to recover the original .xcf data from the auto-save. Overall I really don't see a need to completly revamp Gimps Export/Save interface, the current one is working quite well, a bit polish here and there can't hurd, but the overall workflow is quite ok. -- WWW: http://pingus.seul.org/~grumbel/ Blog: http://grumbel.blogspot.com/ JabberID: [EMAIL PROTECTED] ICQ: 59461927 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Specs for Export/Save User Interface
Hi, Akkana Peck wrote: > [EMAIL PROTECTED] writes: > > 3) Putting Text on a .png (in-place file editing) > > - Open bla.png > > - Text layer created > > - Export to bla.png exporting to currently opened file > > is admittedly ugly, but > > consistent. The image stays dirty > > as the layer data > > has not been saved. > > - confirm overwrite protection > > - check result in web browser > > - Modify Text size > > - Export to bla.png again > > - confirm overwrite protection > > - check result OK > > - last finetuning, e.g. brightness > > - Save dialog pops up, warning of layer > > data loss > > - Convert to PNG (dialog button)layers get merged, image gets saved > > to bla.png > > and flagged clean. > > - Close no warning here > > Two problems/questions on this workflow: > > 1. Every checkpoint of the file (saving in case of disaster), > something which now is just a Ctrl-S, becomes an operation that > requires going through at least one scary dialog (the overwrite > one) and sometimes two (at least the first time, where the user > has to select the same filename that GIMP already knows). yes, this is tedious. To support this workflow, an 'Export' command should be added as a companion of the 'Export as' entry. Analogous to Save/Save_as, Export would write to the current file without confirmation while Export_as would ask for a filename. This way, checkpoints become a one-click operation. Please note that currently Save doesn't work as in 'Save my life' and there is one nag-screen included. > 2. Why would a user use Export for every save except the last one, > then suddenly switch to using a completely different command to save? The basic idea is to forbid 'Save' to PNG here. Instead of just disabling the 'Save' command, the nag-screen offers all sensible alternatives. By clicking 'Convert to PNG' in the dialog the data loss is made explicit. So the reason to use 'Save' in the last operation is to mark the endpoint of the workflow. This way, GIMP knows that no confirmation on Close is required. > How would they learn to do this? Because of GIMP warning them when > they try to quit that the file hasn't been properly saved? Won't > most users say "But I just saved it!", click Quit Anyway, and then > go complain to someone about how GIMP often, but not always, says > images haven't been saved when they really have? yep, they will learn this workflow by the nag-screens if they don't read the manual. From an uninformed user's point of view the sense of 'Export as' is to avoid the nag-screen on 'Save as'. 'Save', in turn, looks like a workaround for the 'Close?' confirmation. Poor user. > This model seems much more confusing for users agreed, 80%. I don't think the nag-on-save behaviour a good solution myself. It may get accepted as technically sound by advanced users for it's workflow support, but shurely gets low usability grades. I'm quite confident with the Conversion Rules though. 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] Specs for Export/Save User Interface
[EMAIL PROTECTED] writes: > 3) Putting Text on a .png (in-place file editing) > - Open bla.png > - Text layer created > - Export to bla.png exporting to currently opened file is > admittedly ugly, but > consistent. The image stays dirty as > the layer data > has not been saved. > - confirm overwrite protection > - check result in web browser > - Modify Text size > - Export to bla.png again > - confirm overwrite protection > - check result OK > - last finetuning, e.g. brightness > - Save dialog pops up, warning of layer data > loss > - Convert to PNG (dialog button)layers get merged, image gets saved > to bla.png > and flagged clean. > - Close no warning here Two problems/questions on this workflow: 1. Every checkpoint of the file (saving in case of disaster), something which now is just a Ctrl-S, becomes an operation that requires going through at least one scary dialog (the overwrite one) and sometimes two (at least the first time, where the user has to select the same filename that GIMP already knows). 2. Why would a user use Export for every save except the last one, then suddenly switch to using a completely different command to save? How would they learn to do this? Because of GIMP warning them when they try to quit that the file hasn't been properly saved? Won't most users say "But I just saved it!", click Quit Anyway, and then go complain to someone about how GIMP often, but not always, says images haven't been saved when they really have? This model seems much more confusing for users since they have to understand a lot more about what makes an image compatible with each format they might save to. (I know it seems patently obvious to anyone on this list why adding a text layer is different from doing a crop, but when you talk to users who mostly edit photos, a lot of them aren't very clear on differences between image formats.) ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Specs for Export/Save User Interface
Hi again, here's the first correction: in section Conversion Rules, read 'common format affected' as 'one example of a format affected by this dialog'. The conversion rules are listed by the current dialogs' texts to present the user's point of view. These dialogs are triggered by format capabilities mismatch and cover all file formats, not just the examples mentioned. Btw, this is a great strength of gimpexport.c peter -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Specs for Export/Save User Interface
Hi all, here is a spec which claims to clean up the existent save/export features in a consistent manner. Problems addressed: - insufficient protection from data loss regarding layer & alpha information. This is considered a UI bug [7]. For an example see [1]. - too many dialogs which pop up in an unpredictable manner [5]. Not a bug, but an annoyance - obsoleted Bugs: #75328 - Add "skip this question" to export dialog boxes. #75459 - Add persistent defaults for the Export dialog #119545 - Merge Export features into the Save dialog #164709 - Export dialog should not allow to ignore mandatory export actions Rationales: a) the image window must be a reliable view on the image file data. This rules out showing a .png as flagged clean while multiple layers are present [1]. b) the user's data should be protected by warnings. Usability experts disagree here [2], but consistency with the other parts of the application is more important within the scope of this spec. c) format converters should follow the principle of least surprise. That means that the image window of a re-opened converted file should look like the image window of the original file, as closely as possible. Notes: - Spec Version: Draft 0.6 - Gimp 2.4.2 is referenced as current implementation. - for clarity, the more technical term 'Export' is used in favor of 'Save_a_Copy' throughout this document. See Discussion below. ## User Interface # Semantics from a user's point of view Save: Store all my work. I will continue working from there or finish. Save_as: Same as Save, possibly with a notion of changed artistic direction. Export: Store an independent and possibly incomplete copy of my work. I will continue working from what i have in the image window. Regarding the workflow, Save and Save_as are inline with the workflow, while Export means branching. # Export Export never touches the current image (as before). Export and Save_as form the sole interface for file format conversions. In general, there is no need to warn the user about conversion loss as the current image remains unchanged. The current Export implementation lacks separation of concerns: Format conversion means preserving as much information as possible in the new format, following rationale c). Anything else is part of workflow automation, which should have it's own facility with an interface of it's own (for examples see [3], [4]). Hence the various 'Export File' pop-ups become obsolete. A future automation mechanism might enable users to recreate the removed bits of functionality. The interface for file sub-type specification (rgb, indexed or grayscale) is Image->Mode. While this menu is not easily discovered in the context of format conversion, its is relevant only for advanced users who desire optimal files. Most users will be satisfied with the defaults (as specified in Conversion Rules below). Steps: 1 - file selection dialog, titled 'Export image'. Former: 'Save a copy of the image'. 2 - overwrite protection (as before) 3 - internal file type conversion using a copy of the image. See Conversion Rules below 4 - file type specific settings dialog, defaults to OK (as before). # Save A successful Save operation syncs the image window with the file contents, flagging the image as clean. Save and Open must be roundtrip save (not considering compression loss). Anything else is considered unsuccessful. The File->Save menu command must be independent of the currently selected drawable [5]. Quite ironically, the Save operations are only place were actual data loss may happen besides the Close operation. Steps: 1 - check if image is a new, yet unsaved one. In that case switch to Save_as (as before). 2 - check file format capabilities: if successful saving is impossible, offer alternatives in a nag-screen: # You might loose some data: PNG plugin can't handle layers [...] # #| Save as .xcf |Use gimp's native format XCF, storing all your data. # You can export your image to PNG format later on. # #| Export |Only store a copy of your image as PNG. Your image will remain unchanged. # #| Convert to PNG |Discard all data which doesn't fit into PNG format # #| Cancel | 3 - possible results: - successful saving possible: do as before. The image gets flagged clean. - 'Save as .xcf': switch to Save_as dialog with extension forced to .xcf. The image gets flagged clean, provided saving is successful. - 'Export': switch to Export dialog, thereby not flagging the image as clean. - 'Convert to PNG': has the same consequences as exporting the image and opening the exported file: all losses are reflected in the image window and the imag
