Same as with gimp_procedure_new2(), I will end up renaming the function to
gimp_image_procedure_new() once all usage of this function will have been ported
to the new function using GimpProcedureConfig instead of GimpValueArray
arguments.
The one in GimpResourceSelect is a very nice example of why using config objects
is much nicer, getting arguments by their name instead of an index (which in
this case had to be tracked down by a private function to handle different
cases).
Also in gimp_procedure_config_begin_run(), make sure we sync the arguments with
the config object first thing, even in interactive and with-last-vals case
(where the args may be further overridden). This was especially important for
Script-fu scripts as the image and drawable were not provided separately, so we
need to make sure that the config file has the right values.
Otherwise we will always try to reuse previous values or use the default,
bypassing the actual passed values.
I encountered this issue while porting file-glob and realizing that the
"pattern" argument was always passed to NULL, ignoring the explicitly set
pattern.
When a procedure has no run-mode argument, we should simply not assume anything
and use the passed arguments (which is what the non-interactive mode does).
A lot less lines for the same functionalities!
This includes improvements too:
* "include-pointer" as new PDB argument;
* settings storage thanks to GimpProcedureDialog;
* it should hopefully work better in non-interactive (though it's untested).
The macOS and Windows screenshots are untested after this change, though they
should still work the same. Please report if there is any problem!
This function allows to change the sensitivity of a widget depending on the
value of another property.
We already had gimp_procedure_dialog_set_sensitive() except it was only syncing
with a boolean property, whereas the new function can compare with any property
type.
This new function is meant to replace gimp_procedure_new() when all plug-in
usage will have been switched.
This function creates the GimpProcedureConfig object on behalf of the plug-in
and calls gimp_procedure_config_begin_run() and gimp_procedure_config_end_run().
This way we ensure that all plug-in calls with successful result are properly
stored without asking the developer not to forget to call these (if a "good
practice" is in fact something we request to do every time, especially for good
user experience, we might as well make it rather a core process).
Advantages:
* Better interactive experience: using any plug-in will result in saved
previously used settings.
* for developers, working on config objects is also much more comfortable than
working on GValueArray;
* step forward for the future macro infrastructure: if we can ensure that all
plug-in calls are properly logged, then we can replay plug-in actions, in
NON_INTERACTIVE with the same settings.
Resolves#10069
Currently, the DDS header information for the width, height, and bytes per scan line
are read in and assumed to be correct. As these values are used for memory allocation
and reading, it would be good to verify they do not exceed the file size.
This patch adds a condition after the header is read in to verify those values. If they exceed
the file size (mins an offset), the file is not read in and an error message is shown.
Resolves#9996.
While GIMP has background-colors set for specific buttons,
it did not have a default button background-color. This resulted
in "random" buttons showing system theme colors like the
[Reload Current Theme] button.
This patch defines a default background-color while leaving the
specific button themes intact.
This adds a border when hovering over icons in various
grid views (brushes, gradients, etc). This makes it more
visually apparent which option you can click to select.
Also refactoring: extract two functions
Add test case scripts/test/register-fail
Catches more registration errors.
Any errors not caught at least will not crash.
Remains to be ported to 2.10, but only a few lines, without the refactoring.
The bug is in fact in GTK. "image-missing" is supposed to never missing since
GTK embeds an icon as GResource. But it turns out that the code is buggy. So if
an icon is missing from GIMP theme, then system theme, then "icon-missing" icon
as well, GIMP crashes.
See: https://gitlab.gnome.org/GNOME/gtk/-/issues/3526
As a workaround for now, let's at least add our own "image-missing", at least in
our main themes (Color and Symbolic, not Legacy). This will make GIMP not
crashing at least by default when another icon is missing.
Of course a crash could still happen if one use Legacy or a third-party theme
and if their system theme doesn't contain "image-missing" as well, until GTK is
fixed.
This localization was added recently but it was not in the installer scripts.
Discovered with unit testing: meson test gimp:build / windows-installer-langs
Though GTK+3 is supposed to take care of scaling fonts with high density
displays, it turns out it is not enough for many, for various reasons (taste,
eyesight, distance to the display…). So we add this additional settings to tweak
further the font size.
With Aryeom, we experimented/discussed both a percentage UI vs. an absolute font
size field (e.g. as they provide in GNOME Tweaks). In the end, we went for a
percentage UI because we realize that we don't necessarily know what is the
current size at all. Mostly you just want bigger or smaller, and don't
necessarily care so much at which value is the font size.
This settings only has a single limitation (that we could find), which is when
used on a theme with widget rules using absolute font-size rules (px, or
keywords such as small/medium/large). As long as the CSS rules are relative
though (either to the parent widget, or to the root size), then it works fine.
Basically a theme hard-coding font sizes won't fare well with this settings, but
since we can consider this bad practice, it's an acceptable limitation.
GTK docs is pretty clear:
> It is a programmer error to pass an invalid accelerator string. If you are
> unsure, check it with gtk_accelerator_parse() first.
So now we verify validity of accelerator strings before using shortcuts from
config files (which can be consider "human input" as the file can be modified).
A first attempt at fixing this was going through the idea of changing the
concept of radio actions, such as allowing an active action in an action group
to be called again. Or having some action in the radio group which can be called
but never set active.
But in fact, I just realized that these zoom actions are simply not meant to be
radio actions. They are not stateful actions, nor are they exhaustive.
I also updated the `other_scale` storage logic. Instead of updating it each time
the zoom changed (which was even broken in some cases, like when changing zoom
through another action), I simply save the last custom zoom value. This is the
one which is reused across calls. I don't think always resetting to the current
zoom value is very useful (if you call this dialog, it's not to zoom to the
current zoom!). Also there was some concept of flagging this stored zoom value
as "dirty" by making it negative, but this was never actually used, which makes
me believe that current logic was not the original intent anyway.
Saving the previous custom zoom explicitly set seems to be a good enough
behavior, so let's go with it.
Jehan