… drawable array instead of a single drawable.
Instead of expecting a single drawable, GimpImageProcedure's run()
function will now have an array of drawable as parameter.
As a consequence, all existing plug-ins are broken again. I am going to
fix them in the next commit so that this change can be easily reviewed
and examined if needed later.
I only fix the Vala demo plug-in now (or rather, I just use the first
layer in the array for now) because otherwise the build fails.
Make sure we regenerate the appdata file when po files are updated. It
should not be too much of a problem for release builds made from
scratch, but on incremental dev builds, the appdata was not regenerated
even when new translation got added.
… with N_().
Also fix the domain in self.set_translation_domain() call.
Actually I'll have to dig deeper in this function which apparently is
only used for menu entries. Yet it does feel quite redundant with
calling textdomain() and other gettext calls ourselves. Probably we can
make plug-in localization more straightforward.
Though GObject Introspection is normally not an option, the only case we
don't build it yet is when cross-compiling (as we haven't found the
right way to do it). So let's not build the Goat Exercise plug-in in
Vala in such case as we needed the introspected libgimp.
All our plug-ins are named "plug-in-*", and in particular our goat
exercise plug-ins are all named "plug-in-goat-exercise-*". Only the
Python 3 and Lua were named differently. This fixes the inconsistency.
Probably forgotten remnants from the C to Python port, as I copy-pasted
the C plug-in and converted each line of code to Python 3, one by one.
These semicolons are not breaking the plug-in, but that is still not
very "Python-style". Let's say it's valid, though useless in this case
and clearly not considered beautiful Python.
The metadata format being appdata, I simply use standard intltool
merging on the XML templates.
For Automake, I use a custom rule instead of INTLTOOL_XML_RULE because
the m4 macro hardcoded $(top_srcdir)/po as translation source directory
(yet we want to use po-plug-ins/ for these). Meson on the other side
already used a custom command.
This is an extension containing a few demo plug-ins. This is good to
demonstrate the extension format. It will also allow to disable these
plug-ins (if at some point, one doesn't want to show these demo
plug-ins anymore).
And finally it deals with the fact that our plug-in code is stupid, as
it just tries to find the first executable with the same name (minus
extension) as the plug-in folder. This doesn't go well on Windows, where
the permission system is non-existent. So our code just ends up trying
to run the first file with a similar name in a plug-in folder. As the C
goat-exercise contains both an exe and the C source (and the system
probably returns files in alphabetic order), GIMP under Windows tries to
run the C source instead of the executable (this obviously doesn't go
well).
We could try to do more complex logics, like not aborting if the first
file run fails and try the next one in the plug-in folder. Or maybe just
rename the C file to another name. But any of these is just in the end
the proof that our plug-in discovery right now is just bogus. The
extension system is explicit, not based on randomly trying out files.
Plug-ins entry points are explicitly listed in the metadata manifest.
Jehan