Re: [Gimp-developer] Export File dialog question
Sven Neumann wrote: Hi, On Tue, 2008-06-10 at 17:54 -0400, Liam R E Quin wrote: Could make sense to ask on the gimp-user list. But as far as I can see, saving the current drawable is the only reasonable use case. We might want to consider to make this easier by adding Save Layer and removing the Ignore choice from the Export dialog. Maybe also Save Visible Layers in that case? It's not clear what Save Visible Layers would do. Would it save the merged image of all visible layers into a single layer or would it ask you to specify a filename for each visible layer? Both options don't seem to be very useful in general. If someone needs this functionality, it can easily be added as a script. So basically the whole dialog is useless and could just as well be replaced by assuming that the user clicked Export... and maybe a notice in save dialog that any other format except xcf may cause some data loss. That should be simple to implement... Any chance that could be done before 2.6? Its a small change but would make a decent usability difference. -- Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Export File dialog question
Hi, On Wed, 2008-06-11 at 09:14 +0300, Alexia Death wrote: So basically the whole dialog is useless and could just as well be replaced by assuming that the user clicked Export... and maybe a notice in save dialog that any other format except xcf may cause some data loss. That should be simple to implement... Any chance that could be done before 2.6? Its a small change but would make a decent usability difference. I don't quite understand. What dialog is useless? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Export File dialog question
Sven Neumann wrote: Hi, On Wed, 2008-06-11 at 09:14 +0300, Alexia Death wrote: So basically the whole dialog is useless and could just as well be replaced by assuming that the user clicked Export... and maybe a notice in save dialog that any other format except xcf may cause some data loss. That should be simple to implement... Any chance that could be done before 2.6? Its a small change but would make a decent usability difference. I don't quite understand. What dialog is useless? Export file... dialog you get on saves to formats that are not xcf. It does ask in some formats for conversion options but I doubt many people have ever done anything else there than just clicked export. If someone wants to ie. flatten instead of merge they can do that beforehand. -- Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Export File dialog question
Hi, On Wed, 2008-06-11 at 09:45 +0300, Alexia Death wrote: I don't quite understand. What dialog is useless? Export file... dialog you get on saves to formats that are not xcf. It does ask in some formats for conversion options but I doubt many people have ever done anything else there than just clicked export. If someone wants to ie. flatten instead of merge they can do that beforehand. I don't quite follow that argument. The choices are important. Imagine you are saving a multi-layered image to the GIF format. You get to choose between saving an animation, saving a flattened or a merged version. That choice is not trivial to avoid. Changing these things is not trivial. Both from the user interface point of view (writing the spec) and from an implementation point of view. I don't think we want to address this for 2.6. But we can very well try to get it done for 2.8. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Export File dialog question
Sven Neumann wrote: Hi, On Wed, 2008-06-11 at 09:45 +0300, Alexia Death wrote: I don't quite understand. What dialog is useless? Export file... dialog you get on saves to formats that are not xcf. It does ask in some formats for conversion options but I doubt many people have ever done anything else there than just clicked export. If someone wants to ie. flatten instead of merge they can do that beforehand. I don't quite follow that argument. The choices are important. Imagine you are saving a multi-layered image to the GIF format. You get to choose between saving an animation, saving a flattened or a merged version. That choice is not trivial to avoid. Changing these things is not trivial. Both from the user interface point of view (writing the spec) and from an implementation point of view. I don't think we want to address this for 2.6. But we can very well try to get it done for 2.8. You are right... In case of gif it is not trivial and there are probably many other nontrivial cases. I was oversimplifying the issue. I still think that discussion and spec'ing of this matter should happen as soon as possible... -- Alexia ___ 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 image is
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
Re: [Gimp-developer] Export File dialog question
From my user perspective, I'm ok with the save / export separation. - Save only for XCF - Export for other formats (using the current method, guess format by extension, or manual selection of the output format). We users are used to save anything, despite if it's a lossy format or not, and that's bad for our workflow. I guess it will take some time to get used to the new method and break the habit of pressing CTRL+S to save when we are working on a jpeg file (for instance). But in the end it will be educative and possitive. The right way to manage files is separating the native, loseless format from the lossy, export file formats. The benefit will be a reduction of accidental data loss and an improvement in the work flow. I'm concerned about the save a copy command, though. It will certainly present a usability problem. Should it save, export, or both? Should it be removed? My guess is that it should not be removed, because it provides a useful solution when working with different versions of the file. In my oppinion, it should do the same that the save command. It means that it will no longer export to different formats, just xcf. Again, that will force users to adopt a better workflow (much people uses save a copy for exporting to a lossy format keeping the original). These changes can be quite traumatic for some users but in the long term will benefit the usability and interface coherence of the program, so in my honest oppinion, they have to be performed. Guillermo Espertino ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Export File dialog question
On Wed, 2008-06-11 at 08:08 +0200, Sven Neumann wrote: It's not clear what Save Visible Layers would do. Would it save the merged image of all visible layers into a single layer Yes. I.e. like doing a flatten and then a save and then an undo. I don't have strong feelings about it, but since most end formats don't have layers, it seems to me a common case. 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] Export File dialog question
Hi, On Wed, 2008-06-11 at 13:17 -0400, Liam R E Quin wrote: On Wed, 2008-06-11 at 08:08 +0200, Sven Neumann wrote: It's not clear what Save Visible Layers would do. Would it save the merged image of all visible layers into a single layer Yes. I.e. like doing a flatten and then a save and then an undo. I don't have strong feelings about it, but since most end formats don't have layers, it seems to me a common case. It's what Export - Merge Visible layers should give you. I don't see why we need an extra menu entry for it. Regardless of that, the way this should be implemented is that file plug-ins should have a way to get read-only access to the projection. That would avoid the hassle of merging and it would guarantee that what is saved is what the user sees. 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 protection from data loss
Hi, Alchemie foto\grafiche wrote: gib_mir_mehl wrote: Don't all those export troubles disintegrate once we presume a little more confidence in the undo function? More confidence will require a option to save undo history. As it is now once the image is closed its Undo History vanish,forever lost, so can't be used to correct saving's errors This keeps me thinking. Given the case gimp cares for saving the undo history, where should it be stored? Saving inside the image file would create bloat and is not possible for most formats. So it must be saved separately. This is feasible on the local computer. But what if files are transferred between computers and users suddenly miss their undo history? What would a user interface look like for exporting undo history and for merging the history with the image again? Are there already proposals for this? 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
Re: [Gimp-developer] proposed solution for: protection from protection from data loss
On Thu, 12 Jun 2008 01:35:27 +0200 [EMAIL PROTECTED] wrote: What would a user interface look like for exporting undo history and for merging the history with the image again? Are there already proposals for this? Just my take... is this not something that GEGL and the non-destructive editing will take care of? Given the possibility to adjust a curve applied 25 steps ago at any point, the only remaining use for undo will be on drawables. -- Jon Senior [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 protection from data loss
Jon Senior wrote: [EMAIL PROTECTED] wrote: What would a user interface look like for exporting undo history and for merging the history with the image again? Are there already proposals for this? Just my take... is this not something that GEGL and the non-destructive editing will take care of? Given the possibility to adjust a curve applied 25 steps ago at any point, the only remaining use for undo will be on drawables. No, i'm thinking of the case where you saved those 25 steps to a jpeg and the next day, sitting in the plane to your customer, you discover that this curve should be tweaked a litte bit more. 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
