febb2126 was proposed temporarely while we had hope of having a fix.
Now, we have !1860 (apparently 99% done) but the main maintainer of
crossbuilds refused to look at it because he is focused on core code
until 3.0 so, with this timeframe, the commit lost its reason to exist.
So, to avoid keeping runners work unnecessarelly with abandoned jobs,
let's not trigger them ('when: never') as I proposed on IRC months ago.
On Linux the string for GPS coordinates was broken when the
string it was strtok:d from was freed. Move the free until we
have finished using the resulting string.
gimp_drawable_filter_apply () uses the current
selection as a boundary to draw/redraw a
filter. When editing a filter, if there's an
active selection created after the filter is
added, it interferes with the filter's redraw.
This patch adds a new gimp_drawable_filter_apply_with_mask ()
function, which can be called if we want
to use the existing filter's boundaries to
draw the new filter.
Symptom is "Arg 3 invalid or out of range". Issue not formally reported.
Broke because Distress Selection plugin signature changed: arg Threshold type Int=>Float
Refactor: extract methods for int and float range errors
Enhance by naming the called PDB procedure
This helps script authors find the location of an error.
These errors can occur either when first authoring a plugin,
when a user stresses a plugin in a way not previously tested,
or when a called PDB procedure or plugin changes an argument type or range.
Note that calls from SF scripts to other SF plugins
are not always via a PDB call and then not range checked.
Issue #3471 Unexpected results from luma darken only blend mode
Having the blend mode be perceptual results in the unexpected
result that a color with a lower actual XYZ "Y" value - that's
also clearly visibly darker than the underlying layer - can be
considered as "lighter" than a color with a higher "Y" value.
Reviewer's (Jehan) note: this only changes the default's blend space,
but in fact, we should probably even make the blend space immutable for
these 2 layer modes because the algorithm doesn't make sense in
perceptual (see #3471). We are not doing this right now in order to
not break existing XCF files using these modes in perceptual. We'll have
to figure out later how to have an immutable blend space going forward
while allowing the broken blend space but only for existing XCF images.
This should also fix the build on Windows wich fails with:
> ../app/app.c:537:7: error: call to undeclared function 'gimp_signal_private'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
Right now, running GIMP non-interactively (i.e. either as gimp-console
or with --no-interface) without --quit, the process was still exiting
immediately, yet not properly cleaning after itself. This is a
regression, since there used to be use cases with people wanting
long-running GIMP (for instance with a long-running plug-in waiting for
input through whatever inter-process communication method).
With this commit:
* GIMP now continues running when run non-interactively without --quit;
* It will catch SIGINT (typically Ctrl-C) and will quit cleanly when the
signal happens.
* At the end of the normal process (processing command line options,
such as opening images or running batch commands) and before going
on-hold, it will display some info text saying that the process can be
exited with SIGINT and informing that --quit exists if you were in
fact intending to quit immediately after the normal process actions.
* This also fixes the "gimp_finalize: list of contexts not empty upon
exit" WARNING we had when it was exiting without --quit (because of no
proper cleanup).
Note that I add some CLI text which ideally should be localized. But
since we are in string freeze, I am letting them untranslated with a
TODO (also assuming CLI-using people have more chances being used to
English, which may be or not a wrong assumption; but anyway most people
don't read the terminal output, and people running GIMP
non-interactively are even less).
Since this was not just an enhancement but also really a regression fix,
I prefer to do this now despite the string freeze and lack of
localization.
No intended change to function.
Style changes for easier reading.
Use v3 binding of PDB returns (elide many car), TRUE=>#t, etc.
Also condense trailing right parens to one line
Was "GRAY" without alpha.
Now "*" i.e. any image mode, w or w/o alpha.
The effect is more or less the same,
and should be exactly the same if the user submits a GRAY.
When the user does not choose a file of a secondary image,
use a copy of the primary image as the secondary image.
Rather than throw an error.
The filter still has effects, if not quite the same as when user
chooses a secondary image that is not the primary image.
Represent passed Gfile args having unknown files
or invalid GFile by an empty string.
Instead of by an error string.
A script can treat an empty string as a None choice of file,
or as a user error.
This was mixing 2 features: the debug on crash and performance logs in
the Dashboard dockable.
1. DrMingw is for debug on crash on Windows and has already a report in
the meson summary. So I remove it from the test.
2. Linux specifically with libbacktrace and/or libunwind and Windows but
only x86 (32/64) only are supported. Test updated.
3. Summary field updated to "Detailed backtraces (Dashboard)" for more
clarity.
Script authors declare defaults by name strings.
Which can be valid name, or empty string, or "from context".
ScriptFu declares formal arguments to the PDB,
either with a default GimpResource, or defaulting dynamically from context.
Works with both new-style dialogs (ProcedureDialog and ProcedureConfig)
or with old-style dialog (script-fu-interface.c)
This feature was broken during the initial
port to GimpProcedureConfig, due to the
Out Level parameters not being properly
clamped when interacted with. This patch
fixes the clamping and restores the call
to level_in_draw () to show the arrows.
It also sets the gamma widget's increments
to match 2.10's range.
Since the port to GimpProcedureDialog,
the Threshold label was not being shown
due to it accidentally having an invalid
tag, <-->.
This patch renames it to just "Threshold"
and updates the range to be clearer,
which was the purpose of the original
extended label.
Resolves#12034
Previously, we used the Filter Tool's drawable when updating an
existing filter. However, if the user has a different layer selected than
what the edited filter is attached to, the edited filter is always put at
the top of the filter stack.
This patch retrieves the drawable from the existing filter itself, rather
than assuming the filter tool's drawable is the same one.
