Implementing a shiny new GimpFileProcedure doesn't mean the libraries
we use to load/save files are automatically capable of handling remote
files, so we still need this flag.
which are GimpProcedure subclasses with API to register as load/save
handlers and their own kind of run functions that get their standard
arguments passed directly instead of packed into a GimpValueArray.
They also register their standard arguments themselves, which removes
quite some boilerplate from load/save plug-ins.
Remove gimpprocedure-private.[ch] because install() and uninstall()
are now virtual functions of GimpProcedure.
While doing so, better break the various source categories in libgimp/.
Otherwise we were duplicating some of the header list, hence we forgot
to install some of the headers.
The dialog was still calling the old API gimp_pdb_query() everywhere,
which made it fail to run when called with the new API (e.g. from the
Python console or directly from an action) whereas it worked well when
called from the old API (e.g. from the Script-fu console). By testing
the existence of the GimpPDB singleton, we can have this dialog work in
both cases.
because they are deprecated.
Change GIMP_ICON_TYPE_INLINE_PIXBUF to GIMP_ICON_TYPE_PIXBUF and the
libgimp API to (icon-name, GdkPixbuf, GFile). Use the file's uri and a
PNG blob of the pixbuf to pass around on the wire and for storage in
pluginrc.
gimp_procedure_set_icon() and gimp_procedure_get_icon() are not very
nice functions for bindings. They are still usable, but in most
bindings, the data parameter/returned value would end up like a uint
list which you'd want to convert to a string in the icon name or file
path case. It's still possible but very cumbersome.
Instead, I skip both functions for bindings and create specific
gimp_procedure_set_icon_*() and gimp_procedure_get_icon_*() functions,
which are much more binding-friendly.
Autotools were not able to recognize that libgimp-@GIMP_API_VERSION@.la
and ../libgimp/libgimp-@GIMP_API_VERSION@.la were the same dependency.
Hence with multi-thread builds, GI scanner was not waiting for the lib
to be totally built then failed randomly. Make the path recognizable,
and do the same for libgimpui.
For other libgimp*, I still need to keep a more complicated relative
path, but since libgimp/ is the last processed folder, AFAIK it won't
make problems.
libgimp is anyway processed at the very end after all other libgimp*
were built. This way, it also fixes#3746, by removing the $(top_srcdir)
everywhere from introspected files, hence making the build work again
with older automake.
So a value array can now we created like this:
array = gimp_value_array_new_from_types (&error_msg,
G_TYPE_STRING, "foo",
G_TYPE_INT, 23,
G_TYPE_NONE);
Change PDB generation to use this, which makes for much nicer code in
the libgimp wrappers, and only set arrays separately instead of all
values.
Pass the help-id specified by the procedure to the core, and use it in
the core if set instead of always using the procedure's name (which
was probably good enough for all eternity, but it's still more
consistent this way).
They only contain private functions and don't need to be installed or
included by gimp_pdb_headers.h.
The PDB generation part is done by adding a "lib_private" variable
that can be set on PDB groups which should not be public API; the rest
is manual Makefile fiddling.
gpointer is not introspectable, and we should always prefer boxed types
over generic pointer types (thanks nielsdg!).
This also fixes gjs (JavaScript) binding of our API which was dropping
our properties even though they didn't need to be handled in JS.
See https://gitlab.gnome.org/GNOME/gjs/issues/266
for procedure arguments. This implies creating a new value array in
gimp_procedure_run() if the passed array is too short, instead of
just appending to the passed array, which was ugly anyway.
Add gimplegacy-private.h to keep it separate from gimp-private.h.
The legacy code could now be removed and GimpPlugIn-ported plug-ins
would not notice.
Michael Natterer