[Gimp-developer] Save + export spec essentials implemented
peter sikking wrote: Michal wrote: 2. When I open image foo.png, do some changes and close it, GIMP message says: Save the changes to image 'Untitled' before closing? If you don't save the image, changes from the last minute will be lost. There are options: Close without Saving, Cancel, Save As. I think it'd be very useful to have option: Export and even Export to foo.png. Obviously in this case GIMP message should be different as well. This is a point that Martin and I discussed on irc. Here is the main point that the changes are clarifying is: a file is only safe when it is Saved (in xcf) this means that export is never the solution to unsaved changes and Export and Export to foo.png cannot be there in the dialog as ways to resolve the situation. O.K., but I may not care if file is safe or not. All I want is to have that changed file on my disk. I don't mind if it's saved or exported. Why make things complicated for this kind of users? Next: It's not clear what will happen to my foo.png file after I choose Save image as 'Untitled.xcf'. Will my foo.png be changed as well? Will my foo.png disappear because it's now safe as 'Untitled.xcf' and I don't need it any longer? Maybe it'd be better to completely rearrange that dialog to something like: If you close the image, changes from last minute will be lost. You can either save image as 'Untilted.xcf' or export it to any other format CLOSE CANCEL SAVE EXPORT Best Regards Michal (mmiicc) -- Michal Predotka (via www.gimpusers.com) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
Michal wrote: This is a point that Martin and I discussed on irc. Here is the main point that the changes are clarifying is: a file is only safe when it is Saved (in xcf) this means that export is never the solution to unsaved changes and Export and Export to foo.png cannot be there in the dialog as ways to resolve the situation. O.K., but I may not care if file is safe or not. All I want is to have that changed file on my disk. I don't mind if it's saved or exported. Why make things complicated for this kind of users? we currently have a mess and it needed straightening out by a clear separation of save and export. the clear separation is destroyed for users as soon as there is one hint that and export is also save/safe. Next: It's not clear what will happen to my foo.png file after I choose Save image as 'Untitled.xcf'. Will my foo.png be changed as well? Will my foo.png disappear because it's now safe as 'Untitled.xcf' and I don't need it any longer? foo.png was never inside GIMP. it was an xcf that had foo.png as a starting point. we try to reflect this in every way. one way that came up during LGM discussions was that the layer should be always (even for background) be named after the image that was imported as its starting point. I think we should do that. to answer your question: foo.png is not touched on disk unless you use Export to foo.png in the file menu. easy, no? Maybe it'd be better to completely rearrange that dialog to something like: If you close the image, changes from last minute will be lost. You can either save image as 'Untilted.xcf' or export it to any other format CLOSE CANCEL SAVE EXPORT sorry, not a hint... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
Hi all, peter sikking schrieb: foo.png was never inside GIMP. it was an xcf that had foo.png as a starting point. we try to reflect this in every way. one way that came up during LGM discussions was that the layer should be always (even for background) be named after the image that was imported as its starting point. I think we should do that. that's a really good idea! Regarding export/import, GIMP's document model is much like Inkscape's, with the difference that for the latter, it is immediately understandable why... Still, i very much hate to send users into one-way streets, and for the open=import case, this is not planned. I wonder if we can't somehow ease the case where export=save? Perhaps via a shortcut like 'export to PNG close document discard data'? When export is just a branch in the workflow and editing continues on the GIMP document in RAM, it might be beneficial to offer one-click Save into a backup-directory without having to choose a filename. Perhaps 'export to PNG save backup'? just a rough thought, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
peter (yahvuu) wrote: peter sikking schrieb: foo.png was never inside GIMP. it was an xcf that had foo.png as a starting point. we try to reflect this in every way. one way that came up during LGM discussions was that the layer should be always (even for background) be named after the image that was imported as its starting point. I think we should do that. that's a really good idea! Regarding export/import, GIMP's document model is much like Inkscape's, with the difference that for the latter, it is immediately understandable why... Still, i very much hate to send users into one-way streets, and for the open=import case, this is not planned. right, that is an obvious optimisation. I wonder if we can't somehow ease the case where export=save? Perhaps via a shortcut like 'export to PNG close document discard data'? When export is just a branch in the workflow and editing continues on the GIMP document in RAM, it might be beneficial to offer one-click Save into a backup-directory without having to choose a filename. Perhaps 'export to PNG save backup'? it is absolutely a design goal that after we have helped users so much to open(/import) foo.png, make some edits and do a 'Export to foo.png' in one click, without dialogs, users must be fully aware that they are throwing away the GIMP document (LGM discussion result: call it a composition) that they used to reach their goal. we cannot have accident with GIMP compositions not being saved because we offered a too-clever-by-half shortcut. and to show again our priorities: at LGM Hylke Bons (works on visual design all day long) said: of course all my work is in project-type files. enough said. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
Can one guarantee GIMP compositions will be at least correctly rendered with third-party viewers as image browsing is not in GIMP goals? At least recently xcf has been considered as internal GIMP format. Having thousands files what cannot be easily and quickly viewed and organized is not a good idea IMHO. That will be a reality a user runs into. What is you vision of that problem? peter sikking wrote: and to show again our priorities: at LGM Hylke Bons (works on visual design all day long) said: of course all my work is in project-type files. enough said. With respect Alexander Rabtchevich ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Plans for GEGL GPU-support (feedback needed)
Hello everyone, I have another mailing list post detailing how I plan to implement GPU-support to GEGL here: http://lists.xcf.berkeley.edu/lists/gegl-developer/2009-May/001078.html Please read through and live comments as you see fit. Thank you. Kind regards, Daerd ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
On Wed, May 13, 2009 at 9:57 AM, Alexander Rabtchevich wrote: Pleasant interactive cropping In fact tools like Lightroom or Rawstudio beat GIMP for me when it comes to cropping of photos -- for reasons multiple times explained to GIMP developers. and scaling, required for web are enough reasons. Red eyes reduction sometimes... All of the above including cropping can be perfectly done in tools like Rawstudio or F-Spot or digiKam or even in Darktable (which is becoming GEGL based btw). This is why they are (becoming) *workflow* tools. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
Alexander Rabtchevich wrote: Can one guarantee GIMP compositions will be at least correctly rendered with third-party viewers as image browsing is not in GIMP goals? At least recently xcf has been considered as internal GIMP format. Having thousands files what cannot be easily and quickly viewed and organized is not a good idea IMHO. That will be a reality a user runs into. What is you vision of that problem? The solution to this is to provide a, probably GIMP maintained, plug-inable component that can do the thumbnailing. Since the current XCF format is tightly coupled with the GIMP internals this is a bit messy but will likely become much easier once we do our rendering with the GEGL library. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save + export spec essentials implemented
I suspect thumbnailing will not be enough. Let's see an example of high end workflow for photography. One has taken a bunch of RAW images. He has to browse them and compare, delete the bad ones. Then the images need conversion with desired comparing at that stage and the selection goes on... Some of them need postprocessing. And _after_ postprocessing they need scalable up to full-size browsing. Not thumbnails, but full-size preview. No thumbnail would replace large image when selecting which to print, handle, convert to flat format or delete. So the library should be able to make full-size preview. Martin Nordholts wrote: Alexander Rabtchevich wrote: Can one guarantee GIMP compositions will be at least correctly rendered with third-party viewers as image browsing is not in GIMP goals? At least recently xcf has been considered as internal GIMP format. Having thousands files what cannot be easily and quickly viewed and organized is not a good idea IMHO. That will be a reality a user runs into. What is you vision of that problem? The solution to this is to provide a, probably GIMP maintained, plug-inable component that can do the thumbnailing. Since the current XCF format is tightly coupled with the GIMP internals this is a bit messy but will likely become much easier once we do our rendering with the GEGL library. With respect Alexander Rabtchevich ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
