The way currently implemented plug-ins are, they are already
NULL-terminating the returned arrays. Since a procedure name cannot be
NULL itself by definition, defining the array length by a terminal NULL
is enough. There is no need to also add a n_procedures parameters which
is just one more possible bug source, even more as we were already
expecting the NULL termination by using g_strfreev() to free the memory.
Anyway a length parameter does not bring any advantage since a plug-in
can still "lie" about its array size (just as it can forget to
NULL-terminate it) and when this happens, the plug-in will segfault.
That's it, it's just a plug-in programming error.
Last but not least, some binding seem to have issues with returned array
setting an (out) parameter as the length. In pygobject at least, the
length parameter doesn't disappear and we end up with this ugly
signature:
> In [3]: Gimp.PlugIn.do_query_procedures.__doc__
> Out[3]: 'query_procedures(self) -> list, n_procedures:int'
See bug report pygobject#352.
To avoid this, we should either set both the array and the length as
(out) parameters or just set the returned array as NULL-terminated
(which is the solution I chose).
It's a bit weird because this has to happen during the query() step, but
plug-ins don't have access to this step anymore, apart from
query_procedures(), which then turns out to be badly named.
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.
Several aspects of the new API are kind of broken in the Python binding,
especially the arguments. So this first version has no arguments at all.
This also means it cannot be installed in "<Palettes>" menu for the time
being. This is work-in-progress and the missing parts will be
uncommented later when we figure out how to fix the problems.
The latter is broken and doesn't guarantee a decimal point with the
current bug. Also, g_ascii_dtostr() doesn't need the format parameter
and produces nicer output.
I may have missed things. That is the problem of non-compiled script
languages. There is also a known warning:
> DeprecationWarning: Gtk.Dialog.set_alternative_button_order_from_array is deprecated
I'll see later about this one.
Push-time note: calling various functions is actually broken right now
in the console since the late API changes (it was working fine yesterday
evening when I tested the same python-console code). Pushing anyway for
now.
Python scripts should already properly run, whether you run them with a
direct python shebang or a `env python` one (cf. previous commit). But
it's still nice to install a `.interp` file, which allows to control
exactly the interpreter to use, overriding the shebang. With this file,
Python scripts will use installation-time Python interpreter.
Also update old code to make the interp contents about Python 3 instead
of 2.
In particular, if the shebang is `#!/usr/bin/env lang` and we have not
registered a specific interpreter for `lang`, the system should leave
the env tool search the right interpreter for us. We only bypass env
when we set our own explicit interpreter.
Apply this to palette-to-gradient.py plug-in.
Localization still doesn't work, but this is normal (po-python is not
installed). I will later make the proper tests for this.
Other than this, it is a pretty simple port. It lost all particularities
and facilities of pygimp, but the fact that it now works similarly to
the C API is quite nice too.
It still uses the legacy API for plug-ins though and will have to be
ported further when the new API will be stable.
Also I still haven't figured out why we need to return the number of
returned values. With the proper annotations, an array length parameter
disappears in introspected Python (because it is useless as Python lists
know their length). But it would seem that this annotation doesn't work
the same for returned values, which is a bit sad as it creates ugly
redundancy.
It can be noted that I an going to move all Python plug-ins from
plug-ins/pygimp/plug-ins/ to plug-ins/python/. The whole pygimp/
subdirectory will actually be deleted eventually (I keep it around for
now as reference) as Python plug-in should not need to be considered
particularly from now on. They can just be considered as generic
executables.
- 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.
Improve my previous commit: I added babl_init|exit() for
"file-pdf-load-thumb". But these was actually also missing from
non-interactive calls to "file-pdf-load", since the initialization was
done as part of gimp_ui_init() so far.
Just run them down the call stack around the needed part. It's not a
problem if it's called double (for the interactive code path).
This is run as part of gimp_ui_init() in the normal "file-pdf-load"
calls, but such calls have been forgotten for the thumbnail load
procedure.
Also the GimpRunMode is only a parameter in "file-pdf-load". For
"file-pdf-load-thumb", the first parameter is directly the filename. The
fact it might have used to work is chance as it were only tested against
GIMP_RUN_INTERACTIVE, which is 0, so the test would end up FALSE, which
is what we want for thumbnail loading. Anyway now we get a proper call
(thumbnail loading always considered non-interactive).
No need to call babl_format() to then use the encoding part only with
babl_format_get_encoding(). Just keep the encoding as constant string
and use it on babl_format_with_space() at the end.
This doesn't actually change the logics, but make code a bit simpler,
and also remove calls to babl_format(), which makes discovering non
space-invaded code with grep-s easier.
Not for 2.10 because the GEGL op's result looks different. I have no
clue how softglow is supposed to look at all, but the removed plug-in
did things that can't possibly be done with physical light in a
darkroom, so chances are the GEGL op is more correct.
carve-it.scm, chrome-it.scm: apply slightly modified patch from Carol
Spears which replaces hardcoding round brush names by creating a brush
on the fly and setting its radius.
Also fixed both scripts to not use deprecated color API which is
even completely gone from master.
This improves commit bbd5ebbe8a. Several parameters did not need to go
inside draw_layer(). In particular this function should not take care of
filling return values on errors. It should just return a success boolean
with a GError which is processed on the main function. This also allows
proper shortcut to end the loop earlier on the first error.
Also the layer index parameter does not need to be a pointer since it
never requires updates.
Finally declare variables in smaller scopes for cleaner code.
Michael Natterer