Hence avoiding the stderr messages. These are going to be localized with
centrally installed catalogs "gimp*-std-plugins", "gimp*-script-fu" and
"gimp*-python".
We now handle core plug-in localizations differently and in particular,
with kind of a reverse logic:
- We don't consider "gimp*-std-plugins" to be the default catalog
anymore. It made sense in the old world where we would consider the
core plug-ins to be the most important and numerous ones. But we want
to push a world where people are even more encouraged to develop their
own plug-ins. These won't use the standard catalog anymore (because
there are nearly no reasons that the strings are the same, it's only a
confusing logic). So let's explicitly set the standard catalogs with
DEFINE_STD_SET_I18N macro (which maps to a different catalog for
script-fu plug-ins).
- Doing something similar for Python plug-ins which have again their own
catalog.
- Getting rid of the INIT_I18N macro since now all the locale domain
binding is done automatically by libgimp when using the set_i18n()
method infrastructure.
- Set the "gimp30-python" Gettext domain and bind it to the proper
locale directory as installed by GIMP.
- Localize various strings with gettext.
- Remove calls to self.set_translation_domain() in
do_query_procedures(). This is technically wrong right now but I am
going to get rid of the menu item localization for plug-ins done by
the core.
Older palette-to-gradient used to have a palette argument. Bring it
back. The logics is that if the string is empty or None, the procedure
will use the currently selected palette. Otherwise it will try to
transform the named palette into a gradient and will fail with an error
if this palette does not exist.
Since GParamSpec are not working fine (cf. pygobject#227), we have this
trick of initializing new arguments or return values with properties.
Use this trick in the palette-to-gradient plug-in.
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.
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.
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.
lloyd konneker