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 `GIMP_CONFIG_PROP_*` macros do not automatically set
`G_PARAM_STATIC_STRINGS`, which means each property that uses such a
macro does not have this flag set by default (and almost none set it
themselves). By adding `G_PARAM_STATIC_STRINGS` to
`GIMP_CONFIG_PARAM_FLAGS`, we can prevent this from happening, which
should lead to some unnecessary string copies being prevented.
In the various PDB transform functions, avoid erroneously creating
a floating selection when transforming the image mask, and rather
transform the mask normally.
Remove the special clipping-mode handling for channels throughout
the transform (and drawable-filter) code, and rather use
gimp_item_get_clip(), added in the previous commit, instead. As
mentioned in the previous commit, we only modify the clipping mode
in top-level code, while having lower-level code use the clipping
mode as-is. This not only hides the actual clipping-mode logic
from the transform code, but, in particular, allows code performing
transformation internally to use arbitrary clipping modes.
Also, this commit fixes a bunch of PDB bugs all over the place :)
Add a new GimpItem::get_clip() virtual function, and a
corresponding gimp_item_get_clip() function, which return the
actual clipping mode to be used when transforming (or applying a
filter to) a given item, given the original clipping mode. This
applies only to whole-item transformations (i.e., when not creating
a floating selection), and should be used by the top-level code
applying the transformation, rather than by the actual
transformation code, so that the item can be transformed using a
different clipping mode internally.
Provide a default implementation that simply returns the input
clipping mode, and override for GimpChannel (to always return CLIP)
and for GimpVecotrs (to always return ADJUST).
As discussed on IRC, I am not sure if really this is needed, since
theoretically we now have support for a whole bunch of languages without
doing anything (languages supported by GObject Introspection) and we are
not going to check for all of them.
Yet since now we install one JS plug-in, let's still do a quick check.
We'll see later if we want to change how we handle supported script
languages.
Rather than looking for pygobject-3.0 with pkg-config, run an actual
test in python, loading the 'gi' module.
I also added a version parameter making it possible to even check for a
required version of PyGObject, though it is currently unused (as I have
no idea if we have a minimum requirement for our plug-ins to work well).
This is an improvement of commit 8e938e0960 as I realized that we don't
need any development files, therefore I don't think that searching with
pkg-config was the right idea in our case.
We don't actually need any of the Python dependencies at runtime. We
only check for these to make packagers aware of the runtime need. Force
the build to go forward even with these deps.
If we decide to look for Python dependencies, we should also look for
pygobject as it provides the GI binding to Python.
I'm still not sure if we should look for these runtime dependencies at
configure time. But for the time being, if we continue doing so, let's
do it right.
The file path was already the same as ARGV first argument (i.e.
System.programInvocationName as I added this myself!). Why did I even
bothered with this annoying trick!
This makes the code much simpler, which is better for demo code.
Right now it is not working, always because of the same bug about not
being able to create GParamSpec (pygobject#227). As a consequence, I
tried a workaround by creating object properties and using their spec
instead. But it turns out that in pygobject, I cannot create random
properties for custom types (well I could for boxed types or GObject
subclasses, not for GimpImageID or GimpDrawableID). Cf. pygobject#357.
So I am stuck again.
Anyway I still push this demo file which would just work as it is, if we
coult at least got the image/drawable ID.
I comment out the Makefile.am part for now until we can get the issues
sorted out.
and proper callback annotations. Also move the three callback typedefs
from gimpcolortypes.h to gimpadaptivesupersample.h because they are
needed nowhere else.
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.
Michael Natterer