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.
Since GimpProcedureDialog automatically adds labels
to GimpChoice parameters when they're displayed in the
GUI, we don't need to add "Red", "Green", or "Blue" labels
to the frames that contain the radio buttons like we did in
2.10.
Whenever we change the colormap colors in the
Fractal Explorer plug-in, we call set_cmap_preview ()
to update the gradient widget. However, this only changes
the colors if the total number is different than the previous
one, since the only time we change the colors is via a
size reallocation. As a result, most of the time the GUI
display doesn't change.
This patch adds an initial size request of 0, 0, to ensure
the second resize actually triggers the size reallocation
code.
In activate_fractal (), we copy over preset Fractal values into the current
config object. Since "color-mode" is now a GimpChoice instead of an int,
this caused a crash when applied. This patch switches it to set a string in
g_object_set () rather than the original int.
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.
* file-sunras, sparkle, and fractal-explorer
were converted to use GimpChoice with
the RadioFrame setting
* Unnecessary store variables were
removed from hot and file-psp
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.
No functional change.
I did this while chasing #10590 and #10591
The refactoring moves replicated code into functions.
So readers can understand better without having to compare sections
of replicated code.
The comments also highlight issue #10590.
Use g_connect_signal_swapped for "resource-set" signal from Resource Choosers,
to match the signal handler expecting "callback data" in the first arg.
Otherwise the first arg is the object emitting the signal.
Resolves#10537.
During the port, the "green_invert" variable
was repeated twice rather than using the
"blue_invert" variable. This prevented the
fractal from updating when blue was changed.
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.
This name was really irking me because it's not a button (anymore? Maybe it used
to be just a button). Depending on the specific widget, it will have several
sub-widgets, including a label. And it can theoretically even be something else
than a button.
So let's just rename these widgets with the more generic "chooser" name.
- Move the property widget functions for GimpResource properties into a new
libgimp/gimppropwidgets.[ch] file. This mirrors the files
libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types.
- Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new().
- gimp_prop_chooser_factory() doesn't need to be public.
- Add a label to GimpResourceSelectButton, make so that the
gimp_prop_chooser_*_new() functions set the property nick to this label and
add this label to the size group in GimpProcedureDialog.
This is not the main reason for the specific output in #9994. These ones are
more probably because of similar usage in GTK (which updated its own calls to
g_file_info_get_is_hidden|backup() in version 3.24.38). But we should likely
also update the various calls we have to use the generic
g_file_info_get_attribute_*() variants.
To be fair, it is unclear to me when we can be sure that an attribute is set.
For instance, when we call g_file_enumerate_children() or g_file_query_info()
with specific attributes, docs say that it is still possible for these
attributes to not be set. So I assume it means we should never use direct
accessor functions.
The only exception is that I didn't remove usage of g_file_info_get_name(),
since its docs says:
> * Gets a display name for a file. This is guaranteed to always be set.
Even though it also says just after:
> * It is an error to call this if the #GFileInfo does not contain
> * %G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME.
Which is very contradictory. But assuming that this error warning was
over-zealous documentation, I kept the direct accessors since they are supposed
to be slightly more optimized (still according to in-code documentation) so
let's priorize them when we know they are set for sure.
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.
I got rid of gimp_scale_entry_set_sensitive(), as we can now use the
generic gtk_widget_set_sensitive(), and I ported the 2 plug-ins using
this function.
I also created gimp_scale_entry_set_value() to set the value (nicer than
setting object properties).
This is the bug which triggered me to do previous commit because the
error message was talking about a procedure name. Now the error message
is right, but let's not have an error at all! ;-)
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.
gimp_int_radio_group_new() was still complaining about the scope of
radio_button_callback(). Make it (scope notified) because it needs to
stay alive after the function returns and may be called multiple times.
Also adding a GDestroyNotify to free the callback data once the widget
is destroyed (additionally it will also serve as a notifier for bindings
to properly free the callback closure itself, not only it's data).
With this last one done, GObject Introspection generation now happens
without any warning output.
paste as brush, paste as pattern, select to new brush, select to new pattern
fill selection outline, fill path, stroke selection, distort, rounded rectangle
indexed color conversion, merge visible layers, new guide, new guide (by percent)
image properties, newsprint, fractal explorer, sample colorize, new layer
metadata editor (just a button), spyroplus (only common buttons)
