Re: [Gimp-developer] proposed solution for: protection from protection from data loss
Hi, On Thu, 2008-06-12 at 02:09 +0200, [EMAIL PROTECTED] wrote: 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. That is exactly why JPEG should not be offered as a save format. Saving to a JPEG file is clearly an export. No one will be surprised that an exported file can't be edited again. The user needs to save the file to XCF (or whatever the next generation file format will be called). 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
On Thu, 12 Jun 2008 08:36:39 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Thu, 2008-06-12 at 02:09 +0200, [EMAIL PROTECTED] wrote: 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. That is exactly why JPEG should not be offered as a save format. Saving to a JPEG file is clearly an export. No one will be surprised that an exported file can't be edited again. The user needs to save the file to XCF (or whatever the next generation file format will be called). Sven Hi, I agree there is a certain logic to that approach but it should not involve constant importing and exporting as extra steps if working on a foreign file format, png for example. If open png becomes an import then save will duplicate the file as an xcf unless it is explicitly exported again. There's a danger this could all cause a lot of duplication of large files and yet more user interactions to a simple task of opening, changing and saving an existing image , which will almost certainly not be gimp's native format. Anyone wanting to undo changes made to a lossy format like jpeg clearly has no understanding of graphics formats anyway. This request does not even apply to gimp's target user base. If it becomes possible to maintain an undo history across gimp sessions in the native format that would be a nice feature. Beyond that the user had better learn what the characteristics of the different formats he is using are, and the value of keeping backups of different stages of one's work. /gg ___ 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 all, Sven Neumann wrote: [..] JPEG should not be offered as a save format. Saving to a JPEG file is clearly an export. this is totally true. The problem is that this violates widely accepted UI standards. Usability shows it's ugly side here by demanding conformance to users' expectations even if those were formed by broken standards. In fact, the whole concept of 'Save to Harddisk' is fundamentally broken from a pure UI perspective [1]. Despite of that, the GIMP will have to support the Open-Edit-Save cycle for quite some years. This hints at providing different UIs: one that emphasises on technical soundness and a standard one which potentially jumps through hoops to meet users' expectations. While beeing an ugly thought at first, this opens up a lot of possibilies. Looking from outside, i've gotten the impression that the GIMP project has been beaten by similar issues before. I feel like too many GUI changes got discussed to death, because no one managed to come up with solutions which fit all user groups (let alone the coding perspective). At times, the project gets partially paralyzed by the lack of usability input. Sven's unanswered calls for specs are strewn throughout the archives. Quite paradoxically, splitting UI development into GIMP-Pro and GIMP-Standard could be beneficial for the GIMP as a project. This is not saying that such a split is desirable or unavoidable, the point is that it may speed up UI development by not hunting for the one unified GUI anymore. In case of the Export/Save logic such a solution may even be impossible due to problem roots outside the GIMP. I see the current state of Export/Save as the result of a not-untangled development process. The Pro users, in utter need of Export workflow automation features, get thwarted by useless dialogs (from their perspective), while Standard users are confused and usability measures are shurely subterraneous. No one is happy with that. The corresponding arguments in turn have been ping-ponged for years. Every now and then, someone new comes by and restarts the whole cycle, like myself. If all this energy could be freed for speccing coding less universal UIs, i guess GIMP would make quick advances towards both an efficient Pro interface and a reasonably conforming Standard UI. The golden way, of course, would be to follow the Firefox path and allow new UIs to ripen as plug-ins [2]. This requires an omnipotent plug-in API, thus putting even more burden on the coders (as far as i can see). Dreaming of Adam's Pupus Pipeline[3] for nearly a decade now, i doubt the upcoming GEGL goodness will fill in that role anytime soon. Is it imaginable to have multiple GUIs for the GIMP? 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 protection from data loss
On Thu, Jun 12, 2008 at 10:56 PM, [EMAIL PROTECTED] wrote: Dreaming of Adam's Pupus Pipeline[3] for nearly a decade now, i doubt the upcoming GEGL goodness will fill in that role anytime soon. GEGL is basically Pupus, it doesn't do network transparent buffers yet, but it has an infrastructure already used for shared disk swap between processes on the same machine. Almost all of what Adam outlined in his mail about pupus applies to todays GEGL. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.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] 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
