We were already considering the plugins under /common but
not the plug-ins that have their own subdirectories. So,
plugin_executables did not match custom_plugin_targets and
the build started to fail on macOS where install_name_tool
neeeds to process the plugins setting the right LC_RPATH.
This patch reduces three sets of warnings
when compiling on Windows:
* In gimp-layer-modes.c, we move the
g_return_val_if_reached () in
gimp_layer_mode_get_format () to the
default case in the last switch statement
to prevent a warning about an unhandled
switch case
* In spline.c, we initialize V[] to prevent
a warning about uninitialized values
* In flame.c, we unconditionally call
g_bytes_unref () to prevent a warning
about dangling pointers.
This is a followup of previous commit. We must set the win_subsystem
option on executable() so that the result binary is compiled as a GUI
application (and doesn't output a console every time).
The previous commit is still needed and is what allows us to control
when to actually display a console.
With the new API introduced int d1c4457f,
we next need to port all plug-ins using
the argument macros to functions.
This will allow us to remove the macros
as part of the 3.0 API clean-up.
Resolves#11292
Since the GimpProcedureDialog port, the "settings-data"
parameter has been used to save and load the selected
color map. However, the parameter was not being updated
when the user switched colormaps in the GUI - therefore, it
always used the "Custom Gradient" option.
This patch updates the "settings-data" parameter after the
change to resolve the issue.
Resolves#11283
In the GUI, set_flame_preview () is connected to GimpProcedureConfig's
"notify" signal. However it is not disconnected afterwards, so it runs again
after the plug-in is finished and the "setting-data" parameter is updated.
Since the preview area no longer exists, this causes a crash.
This patch resolves the issue by storing the callback ID and then disconnecting
after the GUI is closed.
I added a bunch of arguments, in particular nearly all the settings in the main
dialog, except for "Colormap" as I'm unsure yet how to handle it. It looks like
a mix of GimpChoice and GimpDrawable. I guess it could just be both (2 args,
using values from the GimpChoice if GimpDrawable arg is NULL).
And I didn't make the settings in the "Edit Flame" dialog into arguments as I'm
not sure if the "Speed" and "Variation" in particular should be args, or are
just temporary args only meant to construct a flame (in particular, it looks
like it builds data defining the flame?). These data should be their own args
probably?
Maybe we could also have the "file" as alternative way to init the flame data
(the "Open" button)?
For now, I'm just storing the whole settings struct as an aux argument, so that
"Load/Save Settings" work, as well as the initial values from previous run.
Also the whole code is still a bit of a mess. I feel like we could really
simplify a lot of the code, all these values stored globally or duplicated now
in both the GimpProcedureConfig and the control_point structure.
If we leave a space between the macro name and opening parenthese for argument
lists, the args are not considered macro args (which will be discovered when
using it). I experienced this issue while testing code on some plug-in
yesterday, so thought I might as well fix all these broken macros for casting to
the specific GimpPlugIn subclass, so that we won't have a next time.
- Use g_malloc* functions instead of malloc, so we don't continue on
failed allocations unless we test for NULL.
- Make sure we don't iterate past the known number of control points (ncps).
- Safely allocate, initialize and free points. Since points seems to be
used uninitialized, we use g_malloc0 to set everything to 0.
Thanks to a report by Stefan Cornelius, we became aware that the flame
plug-in does no checking for correct input when loading a pre-saved
settings file.
I reworked the parser to read one or more values based on the type of
token, making sure we also don't read past the end of our token buffer.
All int values have a min and max value set. If any unexpected input is
encountered, we will give a warning.
The flame plug-in can read stored settings from a file. The expected
input is that a ; signifies the end of input.
However, with user input we cannot depend on this to be true, so we need
to make sure that we do not read past the end of our input buffer.
To do so, we add a length check.
We were using the plug-in name with underscores, which is incorrect.
Since nobody ever complained about this, this doesn't seem to be used
very often.
We will use the const that defines the plug-in name instead.
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
This is the consequence of previous commit. Plug-ins' label and
documentation are now localized before sending these data to GIMP core.
In other words, we replace N_() macros with basic gettext calls.
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.
The gimp_drawable_type() is an issue though as gimp_drawable_get_type()
is already defined as a common GObject API.
Though I'm actually wondering if GimpImageType is well called. Rather
than Type, shouldn't we go with ColorModel?
sed -i 's/\<gimp_drawable_bpp\>/gimp_drawable_get_bpp/g' "$@"
sed -i 's/\<gimp_drawable_width\>/gimp_drawable_get_width/g' "$@"
sed -i 's/\<gimp_drawable_height\>/gimp_drawable_get_height/g' "$@"
sed -i 's/\<gimp_drawable_offsets\>/gimp_drawable_get_offsets/g' "$@"
Renaming the temporary function gimp_scale_entry_new2() into
gimp_scale_entry_new() now that the original code is entirely gone. This
is now a fully-fledged widget with a nice and proper introspectable API.
This gives a big cleanup in the meson.build files of the plug-ins.
It's also quite a bit more maintainable, since anything that changes in
libgimp's dependencies, linkage, ... doesn't have to be copy-pasted into
each plug-in.
I am going to forbid plug-ins from being installed directly in the root
of the plug-ins/ directory. They will have to be installed in a
subdirectory named the same as the entry point binary.
This may seem useless for our core plug-ins which are nearly all
self-contained in single binaries, but this is actually a necessary
restriction to eliminate totally the DLL hell issue on Windows. Moving
core plug-ins in subfolders is only a necessary consequence for it.
