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
sorry, the links got chopped off in my previous post: [1] Why does the user have to Save to disk at all? Are there inevitable hardware reasons why software can't take care of user's data? I don't think so. And old story and quite outside GIMP's scope, of course: http://jef.raskincenter.org/humane_interface/summary_of_thi.html [2] as has been indicated by Akkana Peck some days ago: http://lists.xcf.berkeley.edu/lists/gimp-developer/2008-June/020311.html [3] http://lists.xcf.berkeley.edu/lists/gimp-developer/2000-December/013952.html 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, 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
Re: [Gimp-developer] proposed solution for: protection from protection from data loss
[EMAIL PROTECTED] wrote: > 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. > > [...] > > Is it imaginable to have multiple GUIs for the GIMP? > > peter > > Hi Peter First of all, thanks for showing enthusiasm in hepling GIMP UI wise. It seems however that you have not noticed the UI progress that has been put into GIMP through the work of mailny Peter Sikking. In fact, several UI related specifications has been written by Peter Sikking and implemented by the core developers. I suggest you check out the UI wiki [1] to get a view of the current GIMP UI state, and then coordinate with the existing UI people. Regarding multiple UIs, the big problem with that is that it multiplies the required efforts in several areas: coding, documentation, knowledge when giving help, and so on. Best regards, Martin Nordholts ___ 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, On Thu, 2008-06-12 at 23:56 +0200, [EMAIL PROTECTED] wrote: > Quite paradoxically, splitting UI development into GIMP-Pro and > GIMP-Standard could be beneficial for the GIMP as a project. I don't think so. Such a split would make coding a lot more difficult and less fun. Since our product vision clearly targets the pro user, I don't see why we should go through the hassle of adding an extra user interface for the people who actually don't need a professional image editor. > 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. It is up to the user interaction designers to solve this. But I doubt that the whole user interface needs to be split in order to do that. If there's really a need for a pro mode when it comes to saving (and I very much doubt that), then we can add that. But I would like to see a complete spec first. > 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. Well, we had these discussions because we didn't have a clear product vision until recently. > 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. You are making the wrong assumption here that the same people that write the specs would also implement them. That is not any longer true and it has shown to be a good thing to split this. So there is absolutely no waste of energy if the user interaction architects and user interface designers talk about the changes that should be done in the next development cycle while the developers are busy implementing what needs to be done for the next release. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
