First of all: sorry to all translators who started working on these new
strings!
We use CamelCase for our titles, and in particular "Plug-In" is
capitalized with 'I'.
Furthermore, let's use understandable titles like "Plug-In Example in C"
and not just "In C", because while the short title works OK in the menu,
it makes for very broken action names in non-contextual parts of the
software, such as the action search.
Note that we in fact have a concept of short label for actions since
commit 89772351c9. I added support for it to GEGL actions (cf. commit
6dc5f6792e), and to a few core actions (e.g. commit ea1205f094).
Unfortunately I don't think I added an API yet for short label in
plug-ins. Maybe I'll add it soon. But for now, if we have to have a
single label, it should be long, so that it works in every situation.
P.S.: not sure if it's useful to keep documentation strings just
repeating the title, but for now, let's leave them.
The old menu label was confusing to users.
Remove translatable strings having joke "goat" so translators not confused.
Move the goat plugins to the menu.
The items under the menu should all be example plugins.
The menu is in a release.
Test plugins should not be in this menu.
Test plugins should not ship in a stable release.
!!! Note that 2.10 does not ship with example plugins.
If we don't want 3.0 to ship stable build with example plugins,
then the meson.build for goat-exercises needs to change
and the menu removed entirely in menus/image-menu.ui.in.in.
Since these are demos, for the sake of showing how the localization
works, let's localize the goat-exercises with a locally installed
catalog.
Note that actually use the gimp30-std-plug-ins catalog, simply I copy it
in the plug-in folder and rename it as org.gimp.extension.goat-exercises
domain.
As a consequence:
- The C plug-in does not need the INIT_I18N anymore, which was
specifically for the centrally installed catalog and cannot be used by
third-party plug-in developers (so it's not a good demo code).
- I now use GLib.dgettext() for Python instead of the gettext Python
module, because the later won't "catch" the catalog declared in
libgimp.
- The other Goat exercises are now localized correctly, unlike before.
- Just setting GETTEXT_PACKAGE is apparently enough for the Vala
plug-in.
- Lua is untested. Hopefully the code will work.
I added this call originally, mimicking the C plug-ins. Yet in Python,
this function is deprecated since Python 3.8 and removed in 3.10.
Looking closer in the docs, it looks like Python's gettext module works
differently.
While all the *gettext() functions return strings in the locale's
encoding in C, unless overriden by bind_textdomain_codeset() (therefore
we need this call, in order to have locale-independent string encoding),
this is not the case in Python, whose gettext() call is already
locale-independent. The gettext.bind_textdomain_codeset() function only
applies to the specific l*gettext() functions which are deprecated too.
Fixes the warning:
> goat-exercise-py3.py:37: DeprecationWarning: bind_textdomain_codeset() is deprecated
… 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.
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.
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.
2020-10-09 15:30:54 +02:00
Renamed from plug-ins/goat-exercises/goat-exercise-py3.py (Browse further)
