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.
Apart from being less code, this actually gives us a nice performance
improvement. Up until a few years ago, if you pass `NULL` as the
marshaller for a signal, GLib would fall back to
`g_cclosure_marshal_generic` which uses libffi to pack/unpack its
arguments. One could avoid this by specifying a more specific
marshaller which would then be used to immediately pack and unpack into
GValues with the correct type.
Lately however, as a way of optimizing signal emission (which can be
quite expensive), GLib added a possibility to set a va_marshaller, which
skips the unnecessary GValue packing and unpacking and just uses a
valist variant.
Since the performance difference is big enough, if the marshaller
argument is NULL, `g_signal_new()` will now check for the simple
marshallers (return type NONE and a single argument) and set both the
generic and the valist marshaller. In other words, less code for us with
bigger optimizations.
In case you also want va_marshallers for more complex signals, you can
use `g_signal_set_va_marshaller()`.
In gimp_palette_mru_add(), if the added color doesn't match an
existing color, don't look for two duplicate existing colors (which
has quadratic complexity), since there shouldn't be any under
normal circumstances (as we're not adding duplicates to begin
with).
This just adds a dialog before running the actual processing of data.
- it also shows what the run-mode is for;
- the purpose of the plug-in becomes explicit (plug-in creation
documentation);
- it shows some GTK+ code too.
- last but not least, the code is actually shown for people to study,
with a button to access the last version of the code on gitlab.
This makes the plug-in a lot more useful and understandable this way.
Other exercise plug-ins in other languages will have to do the same
thing.
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
It is not installed yet, I am just committing my first version. Further
version should look like goat-exercise as an example of what must be
done in javascript.
Also the plug-in stopped working with one of the recent libgimp commits,
without any change in the plug-in code. This will need to be
investigated before installing.
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.
We will fill this up with more examples of plug-ins in other languages.
Also we will improve a bit the examples to redirect people to source
code so that they understand what these plug-ins are.
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.
Move all old wire code to gimplegacy.c and add wire code to
GimpPlugIn, which now talks with the GIMP core all by itself.
Add some more ASSERT_NO_PLUG_IN_EXISTS assertions to gimplegacy.c and
fix new code that was still using legacy API.
Especially as an example of setting a (rename-to) since variable
arguments are not introspectable, hence gimp_pdb_run_procedure() won't
be available for non-C plug-ins.
1/ First I realize we were still using AM_PATH_PYTHON() and not
AM_PATH_PYTHON3().
2/ We don't need to check anymore for pygtk, pycairo, nor do we need
Python headers. Everything is now taken care of by GObject
Introspection and we have nothing else to build GIMP-side.
3/ Change --enable-python into --with-python. We don't actually build
anything now. There is no Python support to enable or disable
anymore. We simply install Python plug-ins or not. The 3 values are
"yes" (default, configure breaks if a Python 3 interpreter is not
found), "no" (Python plug-ins are not installed, not recommended) and
"force" (install Python plug-ins anyway even if an interpreter is not
found; this can be useful especially for cross-compilation since
Python is not useful at build-time anymore).
Note that --with-python=force, if an interpreter is not found, the
file `pygimp.interp` won't be installed. This is not a problem at all
if the interpreter can be found at runtime the standard way.
Otherwise packagers should add themselves a pygimp.interp file with
the known interpreter path.
Cf !84. We don't want to just replace the old path without versionned
python, because I assume it has been set for a reason. So there may be
machines with a versionned python path, others without. Let's test both
on Windows.
Michael Natterer