Here is a brain dump about XCF and state persistence. It is just food for thought and does not require immediate action for 2.6, except maybe for the handling of the flag GIMP_PARASITE_PERSISTENT:

Some time ago, Peter mentioned that he would like the XCF file format to save all state associated with the image, so that you can reload the file later and continue exactly where you left off. This implies that each XCF file would have to save the state of the image as well as a bit of the GIMP state but we still have to discuss how far we want to go with that. For example: do we save the state of all tools in each XCF file? Do we save the current settings for all plug-ins? Do we allow the user to remove that information before sharing the XCF file with other users?

But besides the state of the environment (GIMP tools and plug-ins), we should also ensure that the state of the image is correctly saved. With the current GIMP, this is not perfect because some information about the image exists only in internal (temporary) data structures and some other data is stored in image or layer parasites that are not persistent so these things are not saved in the XCF file.

For example, if you save a work-in-progress as XCF and come back to it later, then you may have lost the original file name, you may not be able to recompose layers that were decomposed from another layer and you may get different settings if you save the image as TIFF or JPEG (because the parasites "decompose-data" or "tiff-save-options" are not persistent).

If we want to solve some of these problems in 2.6 or later releases, then a first step would be to make all parasites persistent (as if GIMP_PARASITE_PERSISTENT was always included in the flags). We will also have to ensure that all binary parasites handle byte ordering correctly because any XCF file could be loaded later on a different platform. Would there be any objection to making all parasites persistent by default?

-Raphaël

After the quick feedback that I got on IRC, I think that I should clarify a few things...

If I understood correctly what Peter was suggesting some time ago, this was about making sure that the XCF files contain all the information necessary to continue your work in such a way that it would make no difference if you close GIMP and reload the XCF file(s) or if you just continue working without closing GIMP in the meantime.

Of course there are some conflicting goals here: XCF was not designed as a "save workspace" format that would include all open images (not just one) and the complete state of the user interface including window positions, tool state, etc. And personally, I do not think that we should go in that direction because that would belong to a new "GIMP workspace" file format that would not be an image file format like XCF is supposed to be. I deliberately included the examples about tools and plug-ins in my previous mail because I wanted to see how other developers would react. And it looks like mitch reacted strongly on IRC. ;-)

However, if you consider only the information that is directly related to each image, then it would make sense to save as much of it as possible in the XCF file so that it makes (almost) no difference if you close GIMP and re-open the XCF file or if you just continue editing it.

So here is a short list of what I think makes sense to include in XCF files:
- All image parasites and layer/drawable parasites. They should all be persistent - no reason to have exceptions. - All settings of file plug-ins, because these settings should be associated with each image (e.g., using image parasites) instead of using global last vals. It does not make sense to save the settings of other plug-ins (filters) because these are usually shared globally and would change if you load/save several images. - Some other image data that is currently in internal data structures and not in parasites. For the file name, the best solution may be to keep the current get/set_filename() functions using the internal file name (which would change once the file is reloaded from XCF) but add a new gimp-file-name or gimp-original-file-name parasite so that it is still possible to associate an image with its original file.

-Raphaël

On Fri, 9 Nov 2007 10:15:42 -0800, "William Skaggs" wrote:

From: Raphaël Quinet

- All image parasites and layer/drawable parasites. They should all be persistent - no reason to have exceptions.

The problem is that when a parasite gets saved, it becomes in effect a part of the API that must be supported forever. [...] This sort of thing may
make sense for stable releases, but during development it is often a great convenience to be able to experiment with formats without every attempt being a commitment that will bind you forever.

Well, the developer releases are not supposed to be stable. And as long as the development tree is still far from any feature freeze, then it is not wise to expect that its APIs will be supported forever. The format of some persistent parasites has been changed during the 1.3.x development cycle in a way that was not backwards-compatible (maybe during other cycles as well, I didn't check). So I don't think that we have a real problem here.

If you really think that unstable releases should never save stuff that may be changed before the stable release, then we could add a new flag GIMP_PARASITE_UNSTABLE or GIMP_PARASITE_EXPERIMENTAL and define that flag only if GIMP_UNSTABLE is defined. That would do exactly the opposite of what we have now: parasites would be saved unless marked as unstable. But that's a bit overkill...

-Raphaël