After ab626e79, Script-Fu v3 now has the
SF-OPTION parameter again. This patch
ports a few scripts that use it or were
not otherwise covered by other merge
requests.
Note that further improvements are
necessary to allow these to work on
multiple layers simultaneously.
For version 3 scripts, using script-fu-register-filter
Widgets for SF-OPTION and SF-DIRNAME
Fixes#9992
Test case is Sphere v3.
Note that SF-VECTORS is still not supported,
until there is a VectorsChooser widget in libgimp.
A step towards deprecating old-style scripts using script-fu-register,
and deleting script-fu-interface, the duplicate dialog for SF.
But we still need to change or replace script-fu-register (for non-filter plugins)
to use GimpProcedureDialog.
Some GIMP-custom GEGL operations do not use GimpConfig to
store their properties (for instance, Threshold).
Previously, we weren't copying over their values when editing an
NDE filter.
This patch adds code to copy over the Gegl properties if there is
not a GimpConfig object attached to the filter.
In particular in a cross-compilation environment where you don't have an exe
wrapper or cross-host run ability, you still want to be able to configure GIMP.
It is also possible to install lua scripts anyway with -Dlua=enabled, bypassing
ability to test lua-lgi presence (a warning will be outputted at configuration
time, but no error).
While this is the job of `set -e`, putting parts of the script in shell
functions hid error returns in the build-deps-msys2 script.
Cf. #10729.
For the build-gimp-crossroad script, let's just add `set -e`.
Cf. #10725.
I believe there is a real use case for darker or lighter themes, but this
particular theme is not particularly maintained and has no light variant (or to
be accurate: the light variant is just a link to the "Default" one). If someone
is interested in such themes, we'll welcome contributions to revive a new theme
which should have at the very least both a light and dark version, and we could
name it "Contrast" (rather than "Darker" which focuses on a dark variant only).
I think it's better to do it this way rather than releasing with a half-done
job.
The Compact theme code is nearly the same as the Default one, apart from setting
palette icon size to small (which is already something done by the "Override
icon sizes" setting in Preferences), setting font-size to small (which can be
independently set by our "Font Scaling" setting) and setting 3 paddings.
Rather than having this separate theme, it feels like just moving the padding
changes as part of the icon size makes sense. In particular since, when setting
icons to "Small" right now, the default padding really feels a bit huge and out
of place. So all-in-one seems a better choice.
At first, I wanted to set a padding proportional to the icon size, but it didn't
work well. For now, I'll just choose padding sizes manually.
If you run the GEGL Operation tool without choosing
a filter, it leaves a "gegl:nop" layer effect behind.
This is not useful, so we check and set such filters as
destructive to get rid of when applying an effect.
This was provoking a CRITICAL in #9712, in the GimpFgBgEditor which was tracking
the active image, but even before this, I experienced a crash in
GimpLayerTreeView code with the same steps.
The problem is that in some cases, the image switch happens once the currently
active image is already disposed. In particular we had the case in multi-window
mode where closing a window would free a GimpImage yet without necessarily
setting another image as active, since it depends on window focus in MWM (and
the other image windows may not gain focus immediately; this depends on the
window management logic).
Therefore we had various handlers in Gimp*TreeView (or GimpFgBgEditor and
possibly other places) code which tried to disconnect or work on now freed
pointers. To handle such case, let's connect to image finalization and set the
context to NULL image.
When working on #9712, I encountered this crash first before the main issue
(with the same reproduction steps as listed by Wormnest): reason may not be set
by the method. It's better to always explicitly set this variable to NULL first.
The current GTK algorithm for finding an icon seems to be:
main icon theme in choosen style > fallback icon theme in choosen style >
main icon theme in another style > fallback icon theme in another style
Where "style" is either color or symbolic variant of a given icon. The problem
is therefore if say your prefered style is "Symbolic" and you choose a
Color-only icon theme. In such a configuration, all icons which are also
available in the system theme with a symbolic variant will be used from the
system theme (even when they are actually available in the chosen icon theme
too, yet in a color variant) and you get a weird mix of part of the icons as
symbolic from system theme and another part as color from the chosen theme.
In order to avoid this weird situation, we only set -gtk-icon-style CSS value to
the prefer-symbolic-icons property if the chosen icon theme has both style
variants. Otherwise we force the only variant of the chosen icon theme.
The icon "gimp-wilber" is used to determine whether an icon theme has both
variants, which should be documented in the developer website for icon theme
makers.
The -Dlua option has 3 cases:
1. disabled: lua plug-ins aren't installed at all.
2. auto: lua plug-ins are only installed if we find a lua installation
with access to the 'lgi' module. We now do the actual test at configuration
(not only lua existence test, but also lua-lgi).
3. enabled: lua plug-ins are always installed but if no lua installation with
'lgi' module is found, a warning is displayed at end of configuration step.
Add tests of context stack ops.
Add test of paint methods.
Test convert to all precisions.
Test paint dynamics.
Test PDB as database.
Test PDBProcedure methods.
Test display methods.
Test drawable operations.
While the script is made aware of multiple selected layers,
it still only works on the top selected layer.
Mnemonics were also added to the GUI fields,
and an unused "type" parameter was removed.
The list contains, in addition to the GIMP deps, all babl and GEGL deps.
So, let's use it.
Also, nothing new under the sun. We already use a unique list on the
Windows build instruction page (for stable branch) and do the same to
Debian image job.
The merged icon theme is simply named "Default" and contains a color and
symbolic variant for all icons. While in 2.10, it made sense to have both icon
themes because a theme had no concept of a "symbolic" variant back then, icon
themes in 3.0 have this concept and we support this in GIMP through the "Use
symbolic icons if available" option in Preferences.
Until now, it was confusing to have both themes + this option, even more as you
could use the Color icons with the "Use symbolic icons" option, which meant that
if some icons were missing, you could end up with a mix of color and symbolic
icons (and oppositely using the Symbolic theme with the option unchecked).
The new state is much simpler and less confusing. Just 1 icon theme with both
color and symbolic variants (the latter being used by default).
Note that the identical meson.build in each size subfolder is still mandatory
because of the inability of meson (still!) to generate files with
custom_target() in a subfolder as output.
We were skipping tests when there is no display, which is always the
case on Windows. However, these tests always showed as succeeded.
Unless you looked at the test log, you wouldn't noticed that most of
the tests weren't actually performed.
Exit these tests with the value GIMP_EXIT_TEST_SKIPPED instead of
EXIT_SUCCESS.
You are not supposed to use g_assert in tests because g_assert can be
disabled using -DG_DISABLE_ASSERT, which makes tests fail.
Instead let's use the recommended replacement g_assert_true. At this
time we are not bothering using more specific g_assert_* functions,
since there are plans to change our test suite.
gimp_config_writer_printf () is used to print out a gsize variable, data_length.
gsize's actual size varies depending on platform, so using the format "%lu" throws
a warning on some platforms and switching to "%llu" throws a warning on others.
@Wormnest suggested ("%" G_GSIZE_FORMAT) as a universal format to resolve
this warning.
Until now, we were following a similar concept of color schemes as what most OS
are doing. For instance, Freedesktop recently introduced a tri-state color
scheme of "Prefer Light", "Prefer Dark" and "Default", the latter being either
whatever the software prefers (e.g. we prefer either Dark or Gray for graphics
software usually) or what the system prefers. See #8675.
Until now, with GTK, we only had a boolean "prefer dark" setting through the
"gtk-application-prefer-dark-theme" settings. There is not even a "prefer
light".
Nevertheless for graphics application, there is clearly a third case (fourth if
we added a "follow system color preferences" which we don't implement for now):
gray mode and in particular middle gray. Having a middle gray UI is often
considered a necessity when working on colors in order to protect our perception
of color from being influenced by surrounding UI.
To fill this need, we were proposing a Default vs. a Gray theme in GIMP, but
this was a bit confusing and felt illogical, as discussed on IRC some time ago.
Also depending on whether you chose "prefer dark" or not for the gray theme,
this one was itself 2 themes, which made things odd and harder to work on.
Instead this commit:
- adds a color scheme concept in GIMP with 3 variants so far: light, gray and
dark. A possible fourth (future) variant might be to follow the system
preference (do all OS provide such a queriable option?).
- Our Gray theme is merged into Default (as the gray color scheme variant).
- Custom themes can add the following CSS files: gimp-light.css, gimp-gray.css,
gimp-dark.css which are the base file for their respective scheme. gimp.css is
still used as a fallback though it is not necessary (our own Default theme
does not provide a gimp.css anymore). Custom themes don't have to provide all
3 variants. A theme can just provide one or 2 variants if it only wants to
support 1 or 2 use cases.
Daniel Novomeský