Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
We did port it to the new API but we are doubting it is useful at all.
It might have been, historically, when foreground extract algorithm was
first introduced, but probably not anymore, even more as the algorithm
is now implemented mostly on GEGL side anyway. So if any benchmark were
to be done, it should probably be added as GEGL tests.
Also as we are planning to update even more the API lately, it feels
really like a waste of time to also fix this plug-in while we currently
believe it to be useless.
Still we move it to the gimp-data-extras repository for being able to
easily bring it back in case we missed some use.
Per polls on Twitter, Reddit, Patreon and Tipeee, most people were
willing to drop this plug-in as not being relevant anymore (247 for
dropping and 63 for keeping it, so nearly 80% out of 310 participants).
So let's move it to gimp-data-extras allowing it to still have a
possible life, and who knows, maybe to even evolve.
See also corresponding commit beffc6b to gimp-data-extras repository.
shadow_bevel.py and sphere.py are unfinished and have been in the
"Unstable" only builds for years. This is probably not worth porting
them. Let's just delete them.
I have actually move these (as well clothify and whirlpinch removed
yesterday) to the gimp-data-extras repository so if anyone wants to
revive them, and port them to GIMP 3, they can start off from there.
Following Elad Shahar advice (cf. #4368), let's delete whirlpinch.py and
clothify.py.
The rational is that whirlpinch.py does the same thing as the existing
"plug-in-whirl-pinch" which is itself a compat plug-in to
"gegl:whirl-pinch" operation. Also the Python file has an explicit
command saying it is exactly the same algorithm, yet with no preview and
slower. Finally it was not even installed on stable build. It doesn't
look like there is any reason to keep it (it was probably a demo/test
Python plug-in).
As for clothify.py, a quick look at the short code shows it is exactly
the same algorithm as clothify.scm, with the same arguments and
installed on the same `Filters > Artistic` menu (except that the Python
version is not installed on stable builds).
So let's just keep the script-fu version as it has been the used version
until now, and there is no deprecation going on in one side or another.
So let's keep what already works.
Note by reviewer (Jehan): merging this port as it was in GIMP 2.10
anyway, but is this even still needed code? This plug-in is not even
available on stable release, it looks like for-development only
benchmark, and I'm not sure if it's relevant anymore, especially in our
GEGL-fueled new world.
Please anyone who knows a bit more on the history of this plug-in and
the evolution of our gimp_drawable_foreground_extract() algorithm, feel
free to weigh in and tell us what this was for exactly and if it's still
relevant.
This is a basic port without any UI.
Invoking the plugin will just sort the entire palette based on
default parameters.
The original plugin had several broken options, which I tried to fix.
Without the write permission for the owner, the `make install-plug-ins`
special target fails on Python plug-ins. And anyway I don't see a reason
why not give write permission to the owner (like all other plug-ins are
installed).
