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.
and make the places who need it dispatch between it and
_gimp_read_expect_msg() depending on whether there is a GimpPlugIn
instance. Also clean up some includes.
Documentation-wise in C, this doesn't matter a lot, but it allows
GObject-Introspection based bindings to use their built-in versions when
they want to render any kind of documentation (for example, docs for
Python plugins can render `%NULL` as `None`).
Instead of calling _gimp_close() and returning from both the main
plug-in loop variants, simply only return and call gimp_close() from
where both loops return to, at the end of gimp_main_internal().
Move the legacy loop code to gimplegacy.c. Also remove some more stuff
from gimp.c, old and new are now completely separate apart from one
glitch which wll go next...
Start copying all the actual wire communication to GimpPlugIn, and
move the legacy versions to gimplegacy.c.
This implies having the entire protocol code twice, but without any
if(PLUG_IN) { plug_in_stuff(); } else { legacy_stuff(); }
At the moment it is a wild mixture of old and new, but when finished
the wire code in gimplegacy.c will be entirely separate from the wire
code in GimpPlugIn, which will make it easy to g_assert() that only
one API is used by a plug-in.
which must be called by GIMP_EXTENSION procedures when they are ready
to run their temporary procedures. Move gimp_extension_ack() to
gimpobsolete.[ch].
which takes and returns GimpValueArrays. This or something similar is
the new central function for running core procedures. Use the new
function from gimp_run_procedure2().
- libgimpbase: change GPParam to transfer all information about the
GValues we use, in the same way done for GPParamDef. GPParam is now
different from GimpParam from libgimp, pointers can't be casted any
longer. The protocol is now completely GimpPDBArgType-free. Remove
gp_params_destroy() from the public API.
- libgimp: add API to convert between an array of GPParams and
GimpValueArray, the latter is now the new official API for dealing
with procedure arguments and return values, GimpParam is cruft (the
wire now talks with GimpPlugIn more directly than with the members
of GimpPlugInInfo, which need additional compat conversions).
- libgimp, app: rename gimpgpparamspecs.[ch] to simply
gimpgpparams.[ch] which is also more accurate because they now
contain GValue functions too. The code that used to live in
app/plug-in/plug-in-params.h is now completely in libgimp.
- app: contains no protocol compat code any longer, the only place
that uses GimpPDBArgType is the PDB query procedure implementation,
which also needs to change.
- app: change some forgotten int32 run-modes to enums.
The `data` property of a GimpParam is a union. Unfortunately setting a
union is not supported by GObject Introspection yet. So I create some
APIs to create GimpParam-s from values. Note that this is temporary API
(i.e. it may be removed before GIMP 3 release) since we likely won't use
this GimpParam type anymore with the new plug-in API. But for now, this
is necessary, at least for testing and porting Python plug-ins.
Also for GimpParam to be actually introspectable, I had to make it a
boxed type, but since no length information is available for various
variants of the type (arrays, whose length information is a separate
parameter), the copy and free functions are basically broken or leaking
respectively for all types requiring a length.
Bottom line: this is ugly and we really need a new introspectable
parameter type. But for now, it allows to start porting some of our
Python plug-ins.
- Change the wire protocol's GPProcInstall to transmit the entire
information needed for constructing all GParamSpecs we use, don't
use GimpPDBArgType in GPProcInstall but an enum private to the wire
protocol plus the GParamSpec's GType name. Bump the wire protocol
version.
- Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which
take care of converting between GPParamDef and GParamSpec. They
share code as far as possible.
- Change pluginrc writing and parsing to re-use GPParamDef and the
utility functions from gimpgpparamspecs.
- Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch],
the entire core uses proper GParamSpecs from the wire protocol now,
the whole file will follow down the drain once we use a GValue
representation on the wire too.
- In gimp_plug_in_handle_proc_install(), change the "run-mode"
parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not
already an enum). and change all places in app/ to treat it as an
enum value.
- plug-ins: fix cml-explorer to register correctly, a typo in
"run-mode" was never noticed until now.
- Add gimpgpcompat.[ch] in libgimp to deal with all the transforms
between old-style wire communication and using GParamSpec and
GValue, it contains some functions that are subject to change or
even removal in the next steps.
- Change the libgimp GimpProcedure and GimpPlugIn in many ways to be
able to actually install procedures the new way.
- plug-ins: change goat-exercise to completely use the new GimpPlugIn
and GimpProcedure API, look here to see how plug-ins will look in
the future, of course subject to change until this is finished.
- Next: changing GPParam to transmit all information about a GValue.
The new way of doing plug-ins:
- subclass GimpPlugIn in your plug-in
- implement its query() and run() methods, run() will move to a
new GimpProcedure class soon
- instead of MAIN(), say GIMP_MAIN(YOUR_PLUG_IN_TYPE)
Instead of keeping around a GimpPlugInInfo struct, libgimp will
create an instance of your plug-in class, keep it around during
the plug-in's lifetime, and call its virtual functions.
... GimpRunProc function type.
In gimp_install_procedure(), make sure that @params and @return_vals are
processed as arrays, otherwise they are unusable.
As for the run procedure, make so that @return_vals and @n_return_vals
are considered as returned values. In Python binding for instance, that
makes these not parameters anymore, but actually returnable by the run
function.
With these changes, I made the first fully functional GI Python plug-in,
which just creates a new image and a display for this image. Still a lot
to improve clearly, but we are on the right track. :-)
This is an alternative way to set up a plug-in callbacks, apart from
setting directly the PlugInInfo struct properties.
The reason is that setting directly the Gimp*Proc properties crashes the
plug-in, when done through the Python GI binding.
It is most likely a bug in Pygobject, unless we need the proper
annotation (which I haven't found yet). See:
https://gitlab.gnome.org/GNOME/pygobject/issues/24#note_564968
Setting these callbacks from the C code works fine though, hence this
new API. It is to be noted that the '(scope async)' is the most
important part in this function annotations. Without these annotations,
the function pointers become invalid at the end of the set_callbacks()
call, hence the plug-in crashes when they are actually called.
Unfortunally I am also notified by ebassi that using (scope) at all (any
of the 3 possible values) is just wrong. An API change will be
necessary. For the time being, I leave this like this, for the sake of
testing further, but we'll need to improve things.
With GObject introspection, this allows to properly use this function,
otherwise it sees the argv argument as a string (and not an array of
string), which cannot be used properly.
For instance, with Python binding, you can just call it like this:
> Gimp.main (info, sys.argv)
