On Sat, 2009-07-18 at 19:10 +0200, Martin Nordholts wrote:
> > I wonder how much sense it makes to actually create a duplicate image.
> > Most export plug-ins will want to save what's visible. So it would be
> > better if we would use this chance to get away from the
> > copy-image-on-export semantics and let file plug-ins save the projection
> > instead. About a year ago I tried to change gimp-export-image so that it
> > does not create a duplicate, but that wasn't possible w/o breaking
> > backwards compatibility. Now would be a very good chance to get this
> > done right.
> I did considerer the possibility of using the projection directly with
> the API you added a while back, but I decided to go the safe and
> easy-to-port path instead. I don't think it is worth the effort to
> rewrite a lot of code that is likely to go obsolete with GEGL later anyway.
By changing the file plug-ins to use the projection, we can throw out a
lot of very awkward code from these plug-ins. No more would there be a
need to deal with the exported image and the original image and all the
hassle that is needed when it comes to attaching parasites to the
original image or showing a preview in the original image when the
plug-in is actually working on a copy. So by doing this we would make it
a lot easier to port these plug-ins to GEGL later.
The semantics of gimp_export_image() are complete crap (I wrote this
code in the first place, so I have the right to say that). So let's not
make this error worse by introducing a new function that has the same
broken semantics. If you really need the semantics of
gimp_export_image() as an interim solution, that's fine. But then we
don't need to add an extra API for this. If you pass NULL as
'format_name' to gimp_export_image(), then it will not ask the user any
dialogs. So it will do exactly what you proposed for
We can then start to port save plug-ins away from using
gimp_export_image() and deprecate this function. That would be a good
goal for 2.10.
Gimp-developer mailing list