GNOME Bugzilla – Bug 138373
Autosave
Last modified: 2018-05-24 11:01:06 UTC
An emacs/vi/nano-style autosave feature would be muchly appreciated (after losing a couple hours of work). It would save a file named as ~filename in xcf format every user-specified minutes. Might be turnable off for the times when saving a file takes ten minutes a pop.
Since this is on the TODO for years now (but noone ever wrote the code), I am surprised that there wasn't a bug report about it already. But I couldn't find one. Since this should be an easy but useful feature, I will optimistically put it on the 2.2 milestone.
have been looking at this. I would say that the autosave belongs to a GimpImage object. However when saving a GimpImage object you need a GimpContext for the pdb call. Could somebody give a little explanation on this?
Autosave is a GUI feature, it certainly doesn't belong into the core (the core being the core component of the gimp application vs. the GUI component). So it should not live in the GimpImage object or at least it shouldn't be the GimpImage object that triggers the save.
Could you give me a hint, where should it be implemented. Where would it be best to hook up such a functionality?
Auto-saving should not be implemented without careful planning, because .xcf files are often quite large and an incorrect implementation could easily leave a lot of junk files lying around. Probably a good way to start would be by making a close examination of the way Emacs does auto-saving -- it is the result of many years of experience and works very well. (In Emacs, Help -> Read the Emacs Manual -> Major Structures of Emacs -> Files -> Auto Save).
With Sven's remarks in mind. I was looking if it is possible to implement it in GimpDisplayShell. The creation off the temporary file could be done in gimp_display_shell_new which seems to be called in gui_create_display every time a "New/or open image call. The cleanup could be done in gimp_display_shell_close.
You are right that only images that have a display should autosave but since an image has multiple displays it's probably not the right spot. Before we discuss where to put the code, we should discuss how autosave should work, i.e. what should trigger it?
Well for me : if autosave option set in prefs. Always create a tmp file even a empty one. Also in prefs I would like to be able to specify a gimp temp path. I no path is specified i would fallback on (insequence): 1. current working path 2. users home dir 3. tmp dir Check at a regular interval if the image is dirty (and i do mean the flag)use something like g_timeout_add or whatever is appropriate at the right spot. If the image is dirty save a xcf copy of the file.
Emacs triggers autosave either (a) after a certain number of characters have been entered, or (b) after a certain period of idleness, whose length is a function of the size of the buffer. Autosaving can be turned on or off by the user for each buffer. It turns off automatically if the buffer shrinks by more than a certain percentage, but reactivates if the buffer is saved or if the user explicitly reactivates it. Autosave files are automatically deleted when a file is saved. If you open a file and Emacs detects an autosave file for it, it asks whether you would like to use the autosave file instead.
I'm not familiar with Emacs but could one realy compare an editor with a graphics manipultaing program? maybe (a) could be a trigger based on the undo count. For (b) I would prefer saving after at a regular interval if the image is dirty. I like the ideas to make : - autosaving switchable (on/off) for a image. - ask if the autosave file has to be opened or at least warn the user about it and ask if it should be overwritten.
_the_ autosave file? Would that imply that there's only a single autosave file? That won't work very well. We need to figure out how to name the autosave files, keeping in mind that images may be unnamed and that multiple instances of gimp might be running at the same time (unlikely but not impossible).
Would derive the temp name from the current name if there is one. For instance prefix it with ~ as suggested before. Fo unnamed files we have to do some creative thinking althoug we could do something like glib does with g_file_open_tmp ()
See also bug 122934.
Yes, please! It's sort of unconscionable to have a program with as much skill and features as the GIMP that doesn't allow you to autosave when you've worked on something obsessively for hours... Please? Even if it was every 30 minutes, and disabled/delayed if the program was in the middle of a transformation/complicated operation...
*** Bug 432159 has been marked as a duplicate of this bug. ***
Although I'm a relative (almost complete) newcomer to open-source programs, I would agree that an autosave feature would be an important project goal, I've lost plenty of graphics work from fluke bugs, and it *almost* made me give up on using this great program, but not quite. Either way it's nice to know that it's been recognized. My idea would be to have a tmp directory in either the gimp's directory, or the directory of the image being worked on, and just put the autosave files in there. Upon a successful program exit, the folder is emptied and deleted (eliminating junk files, similar to the way M$ Word does it), and a flag of some sort is entered in a local MRU-type database. If Gimp crashes, the MRU entry is there, but the flag isn't entered so it knows it wasn't successfully saved at exit, and it prompts you upon opening as to whether or not you want to open the autorecover file in the tmp directory.. if you choose no, it prompts you to delete the temp file... It doesn't seem incredibly difficult in theory, definitely a worthwhile addition to the program for the effort involved in my opinion.
I think we all know very well how an autosave feature would have to be implemented. It just isn't a priority for the developers because GIMP is extremely stable on Linux so there is hardly any motivation to implement this. If it bothers you, patches are welcome.
"Extremely stable on Linux"???? GIMP crashes on me at least twice per hour and I've lost hours of work due to it. Haven't figured out yet why it crashes, but I think it's something with my Wacom Graphire 3 Tablet. I'm running GIMP 2.2.16 on Gentoo, but all versions since about 2.2.12 had this problem. And no other software crashes on me that often (well... most other stuff doesn't crash at all). I'm already saving obsessively but sometimes you just forget it. I will file a bug for the crashes as soon as I can be bothered to compile a debug version...
(In reply to comment #17) > It just isn't a priority for the developers because GIMP is > extremely stable on Linux so there is hardly any motivation to implement this. For an outsider this seems like a pretty shortsighted point of view, especially for a flagship product of the Open Source movement like the GIMP. Shouldn't usability be just as important, if not more important, than stability? Do you not care about expanding your user base, and making them happier and more productive? Just my two cents.
The major point of Open Source is that features can be added and are added by people who need them.
I agree that Autosave IS an important feature that has been asked for for over six years (see http://lists.xcf.berkeley.edu/lists/gimp-developer/2001-August/005481.html) In many years of use, I've never had Gimp crash on me, and I often use files with up to 100 layers and over 1GB in size. However, I've had computers crash more often than I'd like to experience. For instance, I just lost over an hour of GIMP work when a power fluctuation crashed my computer. Yes, I should save often, but I'm sure I'm not the only one who becomes so focussed on the creative process that time passes without notice until the screen goes black. And lets face it, GIMP is a creative tool. Getting lost in the creation is a part of the process. If I were able to code, I'd put my time here. I'm sure there are more interesting and possibly more pressing things on the ToDo list, but are there many that have been asked for so often for so long? At the same time, I'd like to personally thank each and every contributor to this beautiful piece of software.
Actually there may be a way you can help anyway. The tricky thing about autosaving is not implementing it (in my opinion), but figuring out exactly how it should work. Autosaving an image that may be several hundred megabytes in size is a more dangerous operation than autosaving a text file that usually isn't larger than a few K. Because of this, I don't believe that autosaving should generally be automatic (as it is in emacs, for example), but rather, something that you explicitly turn on. Some people might like to set it up to be automatic, though. In any case, here are some of the questions that need to be answered before an implementation can be coded up: 1) How should autosaving be activated? 2) Should there be a Preferences option for automatic autosaving? 3) Where should the autosave files go? 4) How often should saving occur? Should it be measured in operations, time, or some combination of the two? Should it depend on image size? 5) What should the autosave file be called? 6) Should the answers to (3), (4), and (5) be set automatically, or in Preferences, or in a dialog that pops up when you enable autosaving? 7) When do you get rid of existing autosave files? 8) How do you check whether you will have enough disk space for an autosave file? What do you do if you don't, or if this will bring the remaining space low? Should you warn the user, and if so, under what circumstances? 9) What do you do, if in spite of the check, the disk gets full while autosaving? (This can happen even if you check, because something else can write to the disk while you are saving?) Having clear answers to these questions would go a long way toward making this implementable. If you are interested in pursuing this, it would perhaps be best to try to settle on a plan by means of discussion in the gimp developer list, rather than here -- with a summary of the outcome presented here at the end.
After using the Gimp for around 5 years on Windows, its stability has definitely improved, however, it still crashes on me roughly once every 4 to 5 hours of use. For example, if I am editing images all day (~7 hours), it will crash once or twice a day on average. From my experience, it crashes most often when I go into a drop-down menu or sub-menu (before selecting an option), in which the Gimp interface totally locks-up and the only thing I can do is kill the Gimp process in task manager. This happens to me with three PCs (all running Windows XP). After losing many hours of work, an auto-save feature is something that I would definitely like to see implemented. While I know that auto-saving could mean having to wait a few seconds every set period for a large project when the auto-saving takes place, it would be well worth the small periodic wait instead of having to repeat an hour or two of work once in a while. I'll try to answer the above questions based on my use of the Gimp: 1 - Disabled by default, maybe with a tip displayed about this feature when Gimp is run for the first time. This will leave the Gimp as present for those who never have any crashing issues. Those who encounter periodic crashing or even other issues such as intermittent power failures or OS crashes will then have the ability to enable the feature to minimise the amount of work they lose for the next time they encounter a problem. 2 - I would suggest placing it in "Environment" section of the Gimp preferences. 3 - User defined location field in the “Folders” section of the Gimp preferences. 4 - For simplicity, time based auto-saving would be fine, e.g. every 10 minutes. Operation based is less suitable, for example, I can easily spend 5 minutes manually selecting something with the path tool, which would only count as one operation, where as I can easily carry out several hundred operations in the same period using the clone tool. For image size, maybe a warning could be displayed if the project exceeds a preset size, such that if the user opens a very large multi-layer project or image, a warning is displayed with the option to disable auto-save for this project. 5 - For simplicity - the project name with "(Auto-save)" appended to the file name. For new projects - "Untitled project [Date] - [Time] (Auto-Save)". 6 - For Q3, the Gimp's temporary folder may be fine as a default. For Q4, I would suggest 10 minutes as default. See Q5 for my suggestion as a default. 7 - When the user saves or closes their their project. 8 - I would suggest using a method similar to trying to save the project. If there is not enough disk space, then warn the user. 9 - I'm not quite sure here, but it would be worth checking how the Gimp currently deals with low disk space when it runs out of disk space while writing to its temporary and swap files. Maybe useful as a tip: When a project is open, there is a "Save a Copy..." option in the file menu to save a copy of the open project to a separate file. As a start, it would be worth checking if there is a way to create the auto-save feature based on this "Save a copy..." procedure. For example, every X minutes, trigger the "Save a copy" routine, but instead of displaying a save dialogue, supply it with the auto-save filename and path and display a dialogue something like "Auto-saving, please wait a moment.." while the process takes place.
Hi Sean, if GIMP crashes for you that often I encourage you to help us fix the crash. I believe crashing that often is completely unacceptable. The first step would be to figure out a way to consistently (or frequently) reproduce the crash. If you do that, please file a bug report about it and we'll work our way onwards from there.
Crash Recovery is what's really desired here. I think that is best achieved by writing some sort of journal to disk, mimicking journaling file systems. With GEGL in place, this ideally boils down to recording the user's operations plus references to the source bitmap files. Which at least should not pose a performance problem. (Maybe even GEGL's disk cache can be helpful for desaster recovery?!?) Saving the XCF every few minutes - be it automatically or manually - is IMHO just a hackish workaround for lack of proper failure protection. Besides being cumbersome this is likely to collide with a future versioning system, for which it is appealing to grab the Save command for committing/setting a checkpoint. Back to crash recovery, it is debatable wether aquired bitmaps should be logged to the journal. Probably not, if a subsequent Save operation requires moving the full bitmap on disk.
(In reply to comment #24) > Hi Sean, if GIMP crashes for you that often I encourage you to help us fix the > crash. I believe crashing that often is completely unacceptable. The first step > would be to figure out a way to consistently (or frequently) reproduce the > crash. If you do that, please file a bug report about it and we'll work our way > onwards from there. What if the X server or whatever else crashes ? Crashes don't have to be necessarily from GIMP itself ! I just lost one day of work on several images just because my X server crashes, and there's nothing I can do to recover this work appart spending about as much time as I already spent on it, because I'm not used to save my work and there's no autosave function. I know, that's probably half my fault. But almost EVERY SOFTWARE have recovery tools. There is not even one file in /tmp related to gimp, as far as I can see. Nothing I can do. That seriously sucks.
One possible solution is to help implement - or first, spec out - this feature.
Since the time I posted above, so far I have not managed to work out a way to replicate steps to reproduce a crash. When GIMP crashes on Windows XP, it seems to happen most often just after I've made a selection and then go into a menu. So far I haven't experienced GIMP crash on Linux, although I only use a PC running Linux on occasion. Similar to what I mentioned above, a simple way to implement this feature would be to add some sort of routine schedule within GIMP such that every certain number of minutes, automatically save every open modified image as an XCF in the temp directory (e.g. /tmp in Linux.) As I'm sure this will take a few seconds if several large images are being worked on, just display a message saying something like "Autosaving... Saving image 2 of 12". I know this may be intrusive, but I'm happy to wait, knowing that what I've been working on up to this point is now safe! For those who don't like this idea, add a preference to choose whether to enable autosave and how often (e.g. ## minutes). Even Microsoft Word stops responding for a few seconds when autosaving a very large document, so I'm well use to this and well worth the wait from my experience of having to turn to autosaved work after an unexpected crash or power outage. This way if the electricity goes out, GIMP crashes or the PC has a BSOD (or Kernel Panic), all GIMP would need to do is when launched, automatically open up every XCF file in the temp folder.
Autosaving might become a lot easier when 90% of the work done to an image is changing some values in an OpenRaster XML file. Saving images can take minutes if we're talking about multiple 6000x8000 pixel ones.
What about saving the history ? There is no need to save the image if you remember everything that has been done on it… BTW, saving history is a feature that would be highly welcome, regardless of crashes issues.
Saving the history is bug #148930.
Hello, I would like to push this bug up the priority list. * Gimp is a piece of software. We all agree about that. * AFAIK, Gimp isn't developped using a proof-based development process. * So NOBODY can say that Gimp is bug-free, or even crash-free. * Gimp runs on unreliable operating systems (linux, which crashes sometimes, windows, which crashes sometimes, mac, which probably crashes sometimes (can't say, never used it much myself)) * Gimp runs on unreliable hardware, which can crash at any time, do a hardware freeze, experience power failure. Thus, we can make the basic assumption that gimp, or something it relies upon, will crash some day or the other. Crashing isn't that bad, we're used to just reboot the computer when it freezes, or restart an application when it fails itself. The problem is what happens with the user's data when such a failure occurs. In OpenOffice, the user gets prompted for a recovery of his work. In emacs, the user gets a banner indicating how to recover his work. In firefox, the user gets prompted to recover his opened tabs. In quite a lot of programs, the user has the option to recover his work. In gimp, the user LOOSES HIS WORK. The user's work is what the program is there for, the program wouldn't be used if the user didn't produce any work. Thus, the user's work should be the first concern of programmers. The usual answer to the recover-my-work problem is "Save more often". Yes. I surely do this out of experience. But not everybody does. Most average desktop users don't think about saving often enough. My girlfriend, a graphist, usually thinks about saving only when she's finished working. Oh yes, she *is* lame. So is Gimp. Isn't a computer's purpose to avoid doing repetitive tasks ? I'd consider she matches the "average user" knowledge. The "Desktop user. If Gimp can't cope with the "average user"'s mistakes, then it's not ready for desktop usage. Go back to everybody you told (GNU/)Linux was ready for desktop, and tell them you made a mistake, as it lacks a proper image processing program. Go back to everybody you told they had a free "equivalent" to photo$#0P, and tell them it is actually still in the experimental / beta stage. The average user doesn't save often. Don't count upon that. The other usual answer is "You're a developper. Take out GDB, and fill a bug report". GDB and bug reports won't do anything about power failures. And, although I'm a developer, I won't run GDB on my kernel to see why it crashed after several hours of intensive usage. I simply won't have a clue of what happened, and the bug is probably un-reproducible. And my girlfriend is something like 70km away from me at the moment. So when she sends me a mail saying that Gimp crashed yesterday, and giving me a screenshot of what happened today : http://img99.imageshack.us/img99/6987/bip.jpg I simply can't run GDB over the net, thank you. Yes this happened on window$, but she lost a couple hours of work this summer using linux. And probably a lot in-between. So my request is, IF you wont GIMP to be available as a desktop program, ready for the AVERAGE USER : * Don't ignore requests about auto-save. It has been asked for for years. * Implement auto-save * Make this as a bug, not a feature request. With the hope that the average user and his work will be more respected, Regards, Gerorges Dupéron.
Have you read the previous comments on this bug? If not, then you should do so now, they contain useful information and implementations details that have to be taken into account. If you want to work on this, then you should join the irc channel and developer mailing list (see http://www.gimp.org/develop/ for more information). If you aren't able to work on the code yourself, then maybe you're able to help find someone who is?
I insist on my comment #30. Bug #148930 (proposed in comment #31 as a reply to mine) is not relevant here since it asks for saving the history *within the image*, which is a completely different issue. What I'm suggesting is to dump the history into the hard drive (every once in a while or each time it is modified, this has to be discussed later). Technically this must be the simplest way to implement autosave, since you just have to copy what is already handled by gimp (the history) from memory to hard drive, which must be straightforward. Again, once you have the history and the original image, you have your work back. This option would have many advantages with regard to autosaving the current image. It must be easier to implement, it may need less disk space, there is no need to choose a format or image options, and most of all you have all your history back. Maybe there are some drawbacks, but I can't see any.
> Technically this must be the simplest way to implement autosave, since you just > have to copy what is already handled by gimp (the history) from memory to hard > drive, which must be straightforward. Interesting. Do you actually have *any* clue *whatsoever* what programming is?
Here's a working prototype of an Autosave plugin: https://lists.xcf.berkeley.edu/lists/gimp-developer/2009-July/022738.html
(In reply to comment #35) > Interesting. Do you actually have *any* clue *whatsoever* what programming is? Thanks for this very useful comment. Actually, yes I do, though I don't have any clue about how gimp is coded. I guess that the history is implemented as a vector or something. In C++ only basic knowledge is needed to export such a thing into a file.
One of the most interesting questions is how to handle user interaction while a save is in progress. How does this work with the script prototype - I'd expect to get a trnasitional state, because I can't find any attempts to lock the image? Please note that a discussion in Bugzilla only reaches a fraction of the people that could be addressed via the gimp-developer mailing list. This should be discussed here, and the people who bring it up there are strongly encouraged to offer their support, for example by helping with specifying or implementing this feature. The GIMP source code is freely available, so everyone can have a look at it.
(In reply to comment #38) > One of the most interesting questions is how to handle user interaction while a > save is in progress. How does this work with the script prototype - I'd expect > to get a trnasitional state, because I can't find any attempts to lock the > image? right, the script doesn't handle this. The blurb from the original posting to the devel's list was more accurate than calling it a 'working' prototype: "" here's some dirty PyGIMP which at first glance seems to do the job ""
(In reply to comment #38) Typo: > discussed *t*here,
Georges Dupéron: We don't need your respectless and useless rants, we need a patch written by someone with enough time and motivation.
*** Bug 676062 has been marked as a duplicate of this bug. ***
*** Bug 691736 has been marked as a duplicate of this bug. ***
*** Bug 742161 has been marked as a duplicate of this bug. ***
Reading link to the 2009 workaround script mentioned above (I think the mail list historic is gone forever :-( ) https://bitbucket.org/jsbueno/gimp_scripts/raw/dde0f80c965f8c9dfa908619dfbf08ca5fe7c304/auto_save.py Just reiterating: this is a plain and simple work that "gets autosaving done" in a very simplistic way. It abuses the plug-in system to do that. Still, it is better if people can find it somewhere than having nothing to do about system crashes. (that might not be related to GIMP at all - the person that came asking me for this today is having a problem with another program that crashes the system, and is needing the feature)
From Gimp version 2.6.x i developed my own Autosave feature written in Applescript. (In reply to Michael Schumacher from comment #38) > One of the most interesting questions is how to handle user interaction > while a save is in progress. How does this work with the script prototype - > I'd expect to get a trnasitional state, because I can't find any attempts to > lock the image? > From Gimp 2.6.x up i started to use my self-made autosave feature coded in Applescript. Why? Although your port works well and Mac and Linux share Unix, Gimp isnt a Mac application, strictly speaking. And Gimp uses Gtk for example, so there are some differences who can create conflicts. I like Gimp how it is, dont get me wrong, but i want only to highlight that Gimp wasnt always that stable, especially in the past, if you used Gimp with demanding workflow speed, so the need for an autosave feature. I wrote a very simple code: using a 2 time custom beep sound, followed by saving the frontmost document, every 10 minutes. Its an interruption of 2 seconds, ca.
*** Bug 756856 has been marked as a duplicate of this bug. ***
Gimp needs the same time to save smaller/bigger changes, so my question, why? Gimp could save modifications in a more modern way. 1-write changes in as a separate tmp file 2- overwrite our original file with the changes written in the chunk file of point 1) in two ways (options): a) running in the background, (meanwhile we work) stepwise, automatically, and every n-minutes b)via shortcut, like the usual, old-baken way to save.
Just lost an hour of work due to a crash in GIMP. Did you ever consider adding a blocked autosave at least until a better variant has been implemented? I know there are plugins, but sometimes I simply forget to install them so it'd be better to have something that works out of the box..
Gimp-Perl includes an autosave program. It is implemented as a no-params "Extension" which means it starts automatically as soon as GIMP does. See https://metacpan.org/release/Gimp or https://metacpan.org/pod/distribution/Gimp/examples/autosave2 . Install it with `cpanm Gimp`.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/67.