Re: [Gimp-developer] API proposal for libgimp export dialog
Hi again, This is what we ended up in the last discussion. Anyone have some final comments or objections before I push this to master and port plug-ins to use this? / Martin /** * gimp_export_prepare_image: * @image_ID: Pointer to the image_ID. * @drawable_ID: Pointer to the drawable_ID. * @capabilities: What can the image_format do? * * Takes an image and a drawable to be saved together with a * description of the capabilities of the image_format. If the type of * image doesn't match the capabilities of the format a copy is * created. This copy is then converted, the image_ID and drawable_ID * are changed to point to the new image and the procedure returns * GIMP_EXPORT_EXPORT. The save_plugin has to take care of deleting * the created image using gimp_image_delete() when it has saved it. * * If no converson is done, the image_ID and drawable_ID is not * altered, GIMP_EXPORT_IGNORE is returned and the save_plugin should * try to save the original image. * * This function has identical semantics to gimp_export_image() except * that it doesn't ask the user any questions. * * Returns: An enum of #GimpExportReturn describing the action. * * Since: GIMP 2.8 **/ GimpExportReturn gimp_export_prepare_image (gint32 *image_ID, gint32 *drawable_ID, GimpExportCapabilities capabilities) /** * gimp_export_dialog_new: * @format_name: The short name of the image_format (e.g. JPEG or PNG). * @role:The dialog's @role which will be set with * gtk_window_set_role(). * @help_id: The GIMP help id. * * Creates a new export dialog. All file plug-ins should use this * dialog to get a consistent look on the export dialogs. Use * gimp_export_dialog_get_content_area() to get a #GtkVBox to be * filled with export options. The export dialog is a wrapped * #GimpDialog. * * Returns: The new export dialog. * * Since: GIMP 2.8 **/ GtkWidget * gimp_export_dialog_new (const gchar *format_name, const gchar *role, const gchar *help_id) /** * gimp_export_dialog_get_content_area: * @dialog: A dialog created with gimp_export_dialog_new() * * Returns the #GtkVBox of the passed export dialog to be filled with * export options. * * Returns: The #GtkVBox to fill with export options. * * Since: GIMP 2.8 **/ GtkWidget * gimp_export_dialog_get_content_area (GtkWidget *dialog) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] API proposal for libgimp export dialog
Hi, On Sat, 2009-07-18 at 15:02 +0200, Martin Nordholts wrote: This is what we ended up in the last discussion. Anyone have some final comments or objections before I push this to master and port plug-ins to use this? 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. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] API proposal for libgimp export dialog
On 07/18/2009 06:53 PM, Sven Neumann wrote: Hi, On Sat, 2009-07-18 at 15:02 +0200, Martin Nordholts wrote: This is what we ended up in the last discussion. Anyone have some final comments or objections before I push this to master and port plug-ins to use this? 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. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] API proposal for libgimp export dialog
Hi, 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 gimp_export_prepare_image(). 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. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gegl-developer] GEGL-0.1.0
Sven Neumann wrote: Note to all users of GIMP 2.6: The gimp-2.6 releases that we have done so far will not work with GEGL 0.1.0 (or babl 0.1.0). This is not because GEGL would be incompatible, but rather because of a stupid bug in the run-time version check. This is fixed in git and we plan to do GIMP 2.6.7 release with this fix soonish. There are however a few more patches pending that we'd like to get into 2.6.7 as well. So give us a few more days... Any update on a GEGL 1.0 compatible GIMP 2.6.7? Thanks Dave ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
