libgimpbase:
- Mew GimpFileChooserAction enum type: basically a near-mapping of
GtkFileChooserAction (GTK is not accessible from libgimpbase) with
an added GIMP_FILE_CHOOSER_ACTION_ANY.
- New GimpParamSpecFile param spec type: based off
GimpParamSpecObject, it has a default value, but also a none_ok and
action argument. This way, we can also know from the argument type
if this is a file argument meant for selecting a normal file or a
folder, or for saving into a file, or for creating a directory.
libgimp, plug-ins:
- All existing file arguments (until now using a standard
GParamSpecObject param with GFile value type) were moved to the new
GimpParamSpecFile.
- Script-Fu in particular will now generate the appropriate param type
depending on whether it is an SF-FILENAME or SF-DIRNAME.
- File arguments are now stored between runs as a URI rather than as a
path. As far as I can tell, a GFile always has a URI, but not always
a path (in particular remote file won't have a path).
Followup of the save/export difference, plug-ins can only register
"export" handler procedure (save handlers are registered by core). Also
rename _gimp_pdb_set_file_proc_save_handler() though it's private so it
doesn't matter much.
Now gimp_file_save() is a special case, because it can indeed "save" to
XCF or "export" to any other format. So I just leave it named this way,
but I make the function's documentation more exhaustive.
The param option just contains an options object, not a separate
capabilities. Also even when passing the options object across the wire,
the capabilities within this object are not part of the "options". These
are actually handled separated by GimpExportProcedure.
Therefore the changes are:
* GimpExportCapabilities moved to gimpbaseenums.h with a proper GType.
* "capabilities" properties are changed to flags param spec with type
GimpExportCapabilities.
* GimpParamSpecExportOptions doesn't have a capabilities variable
anymore.
* Consequently gimp_param_spec_export_options() doesn't have a
capabilities arg.
* Wire protocol updated as we don't need to pass any capabilities
neither for the param definition, nor for the argument values.
* GimpExportOptionsEditFunc renamed GimpExportGetCapabilitiesFunc and
returning GimpExportCapabilities flags, instead of setting the
"capabilities" property. I believe it makes it much more obvious what
this callback is for and how to use it.
* Annotations improved or completed.
* Don't make the GimpParamSpecExportOptions public anymore since it is
the same as its parent.
Even though it's not public yet (and won't really be for GIMP 3.0), I
created a new concept of "GIMP Extension" (.gex files) which bundles
various types of data for GIMP, such as plug-ins but also brushes and
other resources, themes, icons, etc.
Having 2 different concepts named the same is confusing, especially
since one of them is not really self-explaining IMO (why are "always-ON"
plug-ins called "extensions"?). So even though this is the older
concept, and since we are anyway massively breaking the API for GIMP
3.0, let's rename this older concept. "Persistent Plug-Ins" is much more
self-defining.
- Fix annotations for gimp_export_options_get_image() to make it
actually introspectable with the GimpImage being both input and
output. Even though the logic doesn't change much (the input image may
be overriden or not), it doesn't matter for introspection because
images are handled centrally by libgimp and therefore must not be
freed. Actually deleting the image from the central list of images
though remains a manual action depending on code logic, not some
automatic action to be handled by binding engines.
- Add G_GNUC_WARN_UNUSED_RESULT to gimp_export_options_get_image()
because ignoring the returned value is rarely a good idea (as you
usually want to delete the image).
- Remove gimp_export_options_new(): we don't need this constructor
because at this point, the best is to tell plug-in developers to just
pass NULL everywhere. This leaves us free to create a more useful
default constructor if needed, in the future. Main description for
GimpExportOptions has also been updated to say this.
- Add a data_destroy callback for the user data passed in
gimp_export_procedure_set_capabilities().
- Fixing annotations of 'export_options' object from pdb/pdb.pl: input
args would actually be (nullable) and would not transfer ownership
(calling code must still free the object). Return value's ownership on
the other hand is fully transfered.
- Add C and Python unit testing for GimpExportOptions and
gimp_export_options_get_image() in particular.
- Fix or improve various details.
Note that I have also considered for a long time changing the signature
of gimp_export_options_get_image() to return a boolean indicating
whether `image` had been replaced (hence needed deletion) or not. This
also meant getting rid of the GimpExportReturn enum. Right now it would
work because there are no third case, but I was considering the future
possibility that for instance we got some impossible conversion for some
future capability. I'm not sure it would ever happen; and for sure, this
is not desirable because it implies an export failure a bit late in the
workflow. But just in case, let's keep the enum return value. It does
not even make the using code that much more complicated (well just a
value comparison instead of a simple boolean test).
This patch creates a GimpExportOptions class in both
libgimpbase and in libgimp. Currently it is a mostly empty
object, but it will be added to after 3.0 to allow for
additional export options (like resizing on export while
leaving the original image intact)
libgimp/gimpexport.c was removed, and most of its content
was copied into libgimp/gimpexportoptions.c. gimp_export_image ()
was replaced with gimp_export_options_get_image () in all
export plug-ins.
GimpExportProcedure has a new function to set the default
image capabilities for each plug-in on creation. It also sets up
a new callback function, which allows the options to respond to
user setting changes (such as toggling 'Save as Animation' in the
GIF or WEBP Plug-in).
Though I am not fond of these macros for our core code (it makes the
code more cumbersome especially for using private data in derivable
types), this definitely makes sense for public API, since it would allow
easier modifications with less chances of messing API/ABI stability.
With the new API introduced int d1c4457f,
we next need to port all plug-ins using
the argument macros to functions.
This will allow us to remove the macros
as part of the 3.0 API clean-up.
Previous gimp_procedure_run_config() was in fact only good for private usage
inside the various run() methods for the different GimpProcedure subtypes. The
problem with this implementation is that the returned config object is not
complete. For instance, for a GimpLoadProcedure, the "run-mode" and "file"
properties are not part of the config object so you cannot call a
GimpLoadProcedure with any of the gimp_procedure_run*() functions.
Note: we had some working usage, e.g. in file-openraster, but only because it
was running the load procedure as a GimpPDBProcedure whose returned config
object was indeed always complete!
As a consequence, I rename gimp_procedure_run_config() as an internal-only
function _gimp_procedure_create_run_config() and I create a new
gimp_procedure_run_config() which always return a full config with all
arguments.
Port all plug-ins to retrieve the layers
directly from the image rather than
having them passed in. This resolves some
issues with introspection and sets the
foundation for future API work.
- Fix a few broken references and an inconsistent argument name.
- Add the new headers in the introspectable header list.
- Add a few missing class descriptions for GimpProcedure and subclasses.
