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] proposed solution for: protection from protection from data loss
[EMAIL PROTECTED] wrote: This is definately not a bug. [..] Gimp does all these things correctly. It is aimed at a competant user base, it does not try to be a beginner's guide using different formats. It is true that GIMP provides correct functionality for export/save. The corresponding user interface however must allow the user to form habits. It wouldn't be an urgent problem even if five confirmation steps were required for writing a simple file format. Users form a habit out of it. The problem begins when these steps become unpredictable. Suddenly, the user's habits are considered wrong (this is why users are so upset). The problem gets serious when this may lead to data loss [1]. This is not talking GIMP into an educational tool for beginners. Habits are an inevitable part of human nature. In fact, they are the workhorse of advanced users. If users are not allowed to form secure habits it is a serious bug in the user interface. peter [1] Alexia gave an example: https://lists.xcf.berkeley.edu/lists/gimp-developer/2008-June/020296.html -- 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
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
[Gimp-developer] Gimp Customizable Toolbar
Since one of the replies to my toolbar patch mentioned this should be moved to the mailing list, here the mail and here the patch: http://bugzilla.gnome.org/attachment.cgi?id=112325action=view The bug report is at: http://bugzilla.gnome.org/show_bug.cgi?id=133030 The patch adds a very simple standard Gtk toolbar to the Gimp image window: http://pingus.seul.org/~grumbel/tmp/gimp-toolbar.png It currently only supports a single toolbar and isn't customizable via the GUI, but only by editing menus/image-toolbar.xml. Which of course isn't much, but it allows the patch to be pretty simple and integrate well into the Gimp, since the toolbar behaves no different then any of the other Image windows accessory (menubar, rulers, scrollbars, etc.) and can be disabled just as them. Since this patch is rather harmless I don't see much reason to not include it into Gimp2.6, especially since the toolbar can be quite useful in many cases, for example when using a graphic tablet and not having the keyboard in an easy reachable position and is easy to disable when not wanted. A toolbar is also a standard item that one expects from an application, basically every other application has one, just not the Gimp. And it is simply one of the features that I have missed the most in Gimp for quite a long long time[1], which is the reason why I implemented it. One open question: Can menus/image-toolbar.xml currently be stored inside ~/.gimp directory, i.e. is there a way to customize those .xml files without messing around with the systemwide Gimp installation? [1] I listed some other features that I have been missing for a while at: http://happypenguin.org/forums/viewtopic.php?p=20741#20741 But no promise that I will implement them to, just public brainstream of stuff I miss. -- 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
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] Gimp Customizable Toolbar
Hi, On Sat, 2008-06-14 at 19:03 +0200, Ingo Ruhnke wrote: It currently only supports a single toolbar and isn't customizable via the GUI, but only by editing menus/image-toolbar.xml. In my opinion this is useless as long as it is not configurable by the user. And editing XML files doesn't count as being configurable by the user. One open question: Can menus/image-toolbar.xml currently be stored inside ~/.gimp directory, i.e. is there a way to customize those .xml files without messing around with the systemwide Gimp installation? No, there isn't. I dount that this would be implementable at all, at least not without changes in GTK+. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GEGL-0.0.18 released
GEGL 0.0.18 ⎺⎺⎺ GEGL (Generic Graphics Library) is a graph based image processing framework. GEGL provides infrastructure to do demand based cached non destructive image editing on larger than RAM buffers. Through babl it provides support for a wide range of color models and pixel storage formats for input and output. This development release will include optimizations for the cpu capabilities of the host system. Pass --disable-mmx and --disable-sse to configure to disable these when building packages that should work on a wider range of hardware. Making GEGL adapt at runtime is a blocker for the next release. There is no new API in this release thus bindings do not need to be updated. Changes in this release ⎺⎺⎺ • Configuration both from commandline arguments and at runtime. • GeglBuffer • New raw tiled raster file format, used both as swap and stored buffers. • Sharing between processes through synced swap. • Babl powered scan iteration infrastructure for efficient access. • Cubic and lanczos samplers re-enabled. • Operations • Use scan iterator for point-filter, point-composer and point-render base classes internally for minimal amount of copies. • Optimized variants of some point and compositing operations reimplemented using a new data type /g4float/ that allows writing cpu agnostic vectorized code for GCC. • New temporal filter base class, for operations operating on color values from neighbouring frames in a video stream. • Autogenerated operation reference installed for use with devhelp. • New operations: write-buffer, v4l, color-temperature. A new release of babl is also available for the quickest operations GEGL work best with babl-0.0.22 or newer. This release appears due to contributions from: Øyvind Kolås, Kevin Cozens, Sven Neumann, Manish Singh, Martin Nordholts, Étienne Bersac, Hans Petter Jansson, Jan Heller, dmacks at netspace.org, Sven Anders, Hubert Figuiere and Geert Jordaens. Where to get GEGL ⎺ GEGL and it's dependencies babl and glib can be fetched from: ftp://ftp.gimp.org/pub/babl/0.0/babl-0.0.22.tar.bz2 ftp://ftp.gimp.org/pub/gegl/0.0/gegl-0.0.18.tar.bz2 ftp://ftp.gimp.org/pub/glib/2.14/glib-2.14.5.tar.bz2 The integrity of the tarballs can be verified with: sha1sum *.bz2 9de50fb5833f41691f50f6e735d6422aad52ea94 babl-0.0.22.tar.bz2 f8113ad33161337eb107ad84c0ac968dca1d02d2 gegl-0.0.18.tar.bz2 d8ae9dcb744ebfcb23809c3c552f4d724cb2458c glib-2.14.5.tar.bz2 Where to get more information about GEGL Information about GEGL can be found at the GEGL website http://www.gegl.org/ -- «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] 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] proposed solution for: protection from information loss
On Fri, 2008-06-13 at 06:20 +0200, [EMAIL PROTECTED] wrote: 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] Yesterday I saved an image in xcf by mistake, by mistyping the .png at the end of the filename (left off the dot). Usually if I type a filename ending in .png though, I don't want an xcf file to be created. What about using just Import/Export? The GIMP could take care of saving automatically, e.g. by writing XCFs to a private folder. How then do I give the xcf file to someone else, or back it up? I'd quickly have several hundred gigabytes of data there if I wasn't careful, too. Throwing out Open/Save/Save_as_Copy as a whole solves a lot of issues. A long-term gnomish model might be to make it easier to drag things onto the desktop (or into folders in the file manager), but people use gimp also in other environments. It's important to remember that some of the interactions between gimp and content management systems are and will remain manual (e.g. when to save an interim milestone copy, and when the work is finished...) Also, right now, I can use Save As, do some changes, undo the changes, and see where I had got to when the image is marked as unchanged (the star goes away from the window title for example). But maybe a note in the Undo History about image was saved here would be even more useful to me and clearer to others. 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] Gimp Customizable Toolbar
Ingo Ruhnke wrote: [1] I listed some other features that I have been missing for a while at: http://happypenguin.org/forums/viewtopic.php?p=20741#20741 But no promise that I will implement them to, just public brainstream of stuff I miss. Hi I see that one of the items on your list is * Overscroll - Bug #362915 http://bugzilla.gnome.org/show_bug.cgi?id=362915: and it is worth mentioning that this bug is one of the few bugs/enhancment requests that blocks a GIMP 2.6 release, so any help with it would be much appreciated. 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] Gimp Customizable Toolbar
On Saturday 14 June 2008, Sven Neumann wrote: Hi, On Sat, 2008-06-14 at 19:03 +0200, Ingo Ruhnke wrote: It currently only supports a single toolbar and isn't customizable via the GUI, but only by editing menus/image-toolbar.xml. In my opinion this is useless as long as it is not configurable by the user. And editing XML files doesn't count as being configurable by the user. And in my opinion, this is a 80% done feature that should not be simply called useless and disregarded. I myself had never missed such a toolbar, but as well, I am not a tablet user. From where it is, it does not seen it will be to hard to implement some drag and drop using the actions (configure keyboard shortcuts) dialog. I would agree that it imight be too late for consideration for 2.6, and of course we just can't just go bloating the UI, but I think shuch a toolbar would be highly praised and the UI team shoudl take a look at it. Moreover, once configurable, it could keep the most used tool icons, making the toolbox really optional, which is one of the ains of the whole set of UI large changes for 2.6. js -- One open question: Can menus/image-toolbar.xml currently be stored inside ~/.gimp directory, i.e. is there a way to customize those .xml files without messing around with the systemwide Gimp installation? No, there isn't. I dount that this would be implementable at all, at least not without changes in GTK+. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp Customizable Toolbar
On Sat, Jun 14, 2008 at 10:34 AM, Sven Neumann [EMAIL PROTECTED] wrote: One open question: Can menus/image-toolbar.xml currently be stored inside ~/.gimp directory, i.e. is there a way to customize those .xml files without messing around with the systemwide Gimp installation? No, there isn't. I dount that this would be implementable at all, at least not without changes in GTK+. I haven't tried this myself, but isn't this exactly the sort of thing that gtk_ui_manager_get_ui() is intended for? Or am I missing something? -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
