GNOME Bugzilla – Bug 164709
Export dialog should not allow to ignore mandatory export actions
Last modified: 2009-07-16 10:22:53 UTC
Currently, the Export dialog allows the user to select "Ignore" even if skipping some or all of the suggested conversions will certainly cause the plug-in to fail. For example, skipping the conversion from RGB to indexed mode for a plug-in that only supports indexed mode. On the other hand, some conversions such as merging visible layers can be safely skipped in most cases (only the active drawable will be saved, instead of the whole image). See the discussion in bug #75459. It would be better if the GimpExportCapabilities could be split between those that can be ignored and those that cannot be ignored. For example, GIMP_EXPORT_CAN_HANDLE_LAYERS can be ignored, but the absence of GIMP_EXPORT_CAN_HANDLE_RGB cannot be ignored if the image is RGB. Then, gimp_export_image() could have a boolean flag checking if the capabilities that are not satisifed by the current image can be safely ignored or not. It would pass that to export_dialog() so that the Ignore button could be grayed out if some export actions cannot be ignored. In that case, the user could accept or cancel, but not "ignore" because it would cause the plug-in to fail anyway. Additional improvement: if there are several export actions suggested and some of them can be safely ignored while some others cannot, then pressing "ignore" could return GIMP_EXPORT_EXPORT and execute the mandatory conversions while skipping the optional ones. For example, saving a multi-layer RGB image with the GIF plug-in results in an Export dialog that asks if the image should be flattened and if it should be converted to indexed or grayscale. Selecting "Ignore" could skip the optional first step (thus saving only the current layer) but still enforce the second one (converting to indexed mode). Alternate solution: get rid of the "Ignore" button completely (while still keeping the internal logic for GIMP_EXPORT_IGNORE). The export actions that can be safely ignored, such as flattening the image, would simply contain an additional choice: (X) Ignore this conversion Or even better, use a more descriptive option that tells the user what will happen, like in the case of !GIMP_EXPORT_CAN_HANDLE_LAYERS: (X) Save active layer only The dialog would then contain only "Export" and "Cancel" options and gimp_export_image() would return GIMP_EXPORT_EXPORT or GIMP_EXPORT_IGNORE depending on whether the combination of selected options results caused a new image to be created or not.
Err, we all know that the Export functionality needs to be redone for GIMP 2.4. Why do you file a bug report that suggests some small but incompatible changes to the framework that is known to be broken beyond repair? What are we supposed to do with this but closing it as WONTFIX? Please try to propose a new export framework on the mailing-list and leave the old system alone.
A new export framework is likely to require an upgrade of all file plug-ins because it would break the current API. The proposal outlined here allows the current API to stay in place and only introduces changes in the libgimp implementation (that's why I suggested to keep things like GIMP_EXPORT_IGNORE). I thought that 2.4 would not introduce major API changes for third-party plug-ins, so I expected that a rewrite of the export framework would wait until 3.0. If my assumption was wrong and 2.4 is allowed to break the API, then of course this proposal could be replace by a better one. In this case, feel free to close this bug report as WONTFIX.
GIMP 2.4 will of course maintain backward compatibility. That should not keep us from introducing new APIs and deprecating existing cruft.
I want to look closer at what this means in the context of this spec that I am implementing atm and that we will have in 2.8: http://gui.gimp.org/index.php/Save_%2B_export_specification
In the new export plug-in API the dialog in question is not shown, so this is a not an issue any longer. The gimp_export_image() API will be obsoleted. Closing this as OBSOLETE.