... to make multi-color hard-edge gradient fills possible
Add a new "step" gradient-segment blending function, which is 0
before the midpoint, and 1 at, and after, the midpoint. This
creates a hard-edge transition between the two adjacent color stops
at the midpoint. Creating such a transition was already possible,
but required duplicating the same color at the opposing ends of two
adjacent stops, which is cumbersome.
(cherry picked from commit 68bf99e806)
In gimp_metadata_add_xmp_history(), make sure the string returned by
strftime() has a terminating \0 after we mess with its format.
(cherry picked from commit 8421221b60)
It seems that calling `lldb` when it is absent triggers some popup
proposing to install Xcode on macOS. This is obviously not good. Let's
check presence with g_find_program_in_path() instead. I was refraining
from doing so until now, because this function allocates memory, hence
may not do well during a crash.
Fortunately we don't need to check for lldb during crash (unlike gdb
which has some unacceptable behavior for older versions, at least on
FreeBSD) so that should be ok.
(cherry picked from commit 04bbe941d5)
This is my attempt to get better labels, shorter and also (hopefully)
improved English.
As Mitch states though, this is a Japanese-French-German conspiracy! So
any of you native English speakers out there, please review and suggest
proper English if needed. :-)
(cherry picked from commit 9cdedc98f8)
Squashed commit of the following:
commit ee1ff7d502658cfa1248a13a3f0348495db07eda
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sun Jul 29 00:31:47 2018 +0900
Fixed that gimp-text-dir-ttb-* icons are lacked in Symbolic.
commit d87d012d697628da28fe90199cc04b95b72ba8ef
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 16:23:10 2018 +0900
Fix a typo.
commit cf0238bf7df56c384cdf3b7ec69557d14740f853
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 15:50:57 2018 +0900
Fixed seg fault error.
commit b07f60d06fa1a753fda5b4d46af01698c344154e
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Fri Jul 27 17:15:34 2018 +0900
Add support for vertical text writing.
https://gitlab.gnome.org/GNOME/gimp/issues/641
(cherry picked from commit 587d9bbb03)
- "LCh" intead of "LCH"
- "CIE LCh" instead of "CIELCh"
- "HSV Hue" instead of "Hue (HSV)" for all models/components
(cherry picked from commit 926dc070ef)
In gimp_metadata_set_from_{exif,iptc,xmp}(), gracefully reject data
of invalid size, returning an error instead of raising a critical.
In particular, this avoids a CRITICAL when loading an XCF with an
empty exif-ata parasite.
(cherry picked from commit eafefc7d81)
The flag `free_selection_string` is used to track an array of strings
with some of them being static and others allocated. This should have
been an array of boolean but we can't change it because it is public API
(though it should really not have been!).
So let's just allocate every string of the `selection` array instead,
which makes the boolean flag useless now.
... after each successful read().
I completely missed this declaration after a statement during the review
of !13 even though I saw another similar issue!
Also let's reset the error counter to 0 each time a successful read()
happens so that we can continue reading even if a lot of EINTR were to
happen, as long as we globally go forward. Only consecutive errors
increment the counter.
Finally add a small comment to explain why we let EINTR pass instead of
breaking directly.
(cherry picked from commit 49b4b1a5c2)
When lldb attaching to the process it triggers few "-1" errors on read with
EINTR error. After 1-2 errors read() call works again.
Also this patch fixing TID detection, syscall SYS_gettid is oficially deprecated
now and does not work. Also adding safecheck to avoid enldless loop.
(cherry picked from commit 559d9b89e3)
...upon exporting an image
Step 1: make it configurable just like "Export EXIF" etc.
app, libgimp: add "export-color-profile" config option
Add it to the preferences dialog, and pass it on to plug-ins in the
GPConfig message. Add gimp_export_color_profile() to libgimp.
Nothing uses this yet.
(cherry picked from commit 8c9c091021)
Pass the current icon theme directory to plug-ins through the
config message, and add a gimp_icon_theme_dir() libgimp function
for retrieving it. Note that we already have a similar
gimp_icon_get_theme_dir() PDB function, which we keep around, since
it can be used to dynamically query for the current icon dir,
unlike the former, and since it returns a dynamically-allocated
string, while the rest of the config-related functions return
statically allocated strings.
Use the new function, instead of gimp_get_icon_theme_dir(), in
gimp_ui_init(). This allows gimp_ui_init() to run without making
any PDB calls. Consequently, this allows us to start plug-ins that
call gimp_ui_init() without entering the main loop in the main app.
We're going to add a plug-in that displays an interactive dialog
while the main app is blocking waiting for an operation to
complete, and we need to be able to start the plug-in without
entering the main loop, to avoid the possibility of arbitrary code
being executed during the wait.
Bump the protocol version.
Let's make our various usages of this broken function more robust, or at
least return with errors when we can. But this is still seriously
broken. Inside gimp_locale_directory() though, there was nothing I could
do, so I just added a FIXME for at least keeping an eye on it.
I could not find for sure what to use on FreeBSD instead, so let's just
not get this information there. It is quite useful information to know
where thread traces were asked from, but it is more important to make
sure the program can be compiled everywhere. Also we can just check
which thread has gimp_stack_trace*() calls. Thus it can be seen as
redundant information in any case.
SYS_gettid is apparently defined as a macro, so let's simply check for
it being defined.
First WIP commit, adds:
- enum GimpGradientBlendColorSpace { RGB_PERCEPTUAL, RGB_LINEAR }
- linear blending mode for gradient segments
- tool options GUI for the blend and paint tools which use gradients
Since commit bb52431cdd, we get multi-thread traces in functions
gimp_stack_trace_*(). Adding now the LLDB equivalent improvement.
Also adding the process and thread id information, from which the trace
order was made, atop the listing, as well as the thread list. This would
allow to easily find and associate the threads.
The problem is that sometimes the thread where we got a trace from may
not matter (for instance signals, even such as SIGABRT or SIGSEGV, seem
to sent a bit randomly to either the thread which provoked them or the
main thread; there is a bit of contradictory info on this when reading
on the topic, in my case I experienced this), in such case, getting all
thread stack is important to find the origin of the signal.
Other times it will highly matter, in particular when getting a trace
for a WARNING or CRITICAL. This information will help to discriminate
between thread traces.
Last commit caused -xobjective-c to be passed during linking on
Mac, causing object files to be treated as source files. Add a
-xnone flag to AM_LDFLAGS, canceling the effect of -xobjective-c.
Additinally, add a -xobjective-c++ flag to AM_CXXFLAGS, so that we
can use Objective-C in C++ files on Mac, if we ever need to.
On Mac, pass -xobjective-c to the compiler through AM_CFLAGS, not
AM_CPPFLAGS, so that it's only used for C sources, and not C++
sources. In the latter case, it clashes with the -std=... flag,
spewing an error. Thanks, Partha :)
... non-latin unicode path.
g_win32_locale_filename_from_utf8() was sometimes returning NULL for
some paths on Windows. Then the call to gexiv2_metadata_open_path() with
a NULL value was crashing plug-ins.
This commit only prevents from crashing by simply failing to load
metadata when this occurs, which means losing metadata support on
Windows depending on filenames. A proper solution will have to be
implemented.
It seems old blend tool (from GIMP 2.8) was using manhattan distance,
whereas the new one uses euclidean. I guess there must be use cases for
both. In any case, it is a good idea to simply propose the option since
the property exists in the "gegl:distance-transform" operation.
See also bug 781621.
Reap the child *after* we're done reading its output, so that we
can disable ptracing after reading, but before reaping. This
avoids a window during which the child is gone, but ptracing using
its PID is still allowed.
Clear the ptrace permission given to the child after it terminates,
so that a future process that happens to have the same PID the
child had can't ptrace us.
On Linux, when /proc/sys/kernel/yama/ptrace_scope is 1, a process
may only ptrace its descendants by default, which prevents the GDB
process spawned by gimp_stack_trace_print() from attaching to, and
producing a backtrace for, the calling process.
Use prctl() with PR_SET_PTRACER, when available, in the parent
process, to allow the child process to ptrace it.
It seems that older GDB (under version 7) are not handling very well
some common debug information format, in particular DWARF > 3. Such
version of GDB is usually not a problem since it is quite old (more than
10 years old, it would seem) so you don't see it anymore on any modern
GNU/Linux distribution. On FreeBSD on the other hand, it is still
available (probably for license reasons) and even installed by default!
As a consequence, it makes debugging fail, even though LLDB is also
installed by default.
That is even more of a problem because it would seem that GIMP is killed
(most likely by FreeBSD kernel according to the reporter tests) as a
side-effect of GDB failing, which is seriously bad, in particular since
we also use the debug dialog for non-fatal errors (which could therefore
end up killing GIMP as side effect of a bad GDB!).
So I add some GDB version check. I implement this without any dynamic
memory management, as usual, since this needs to happen also during
crash handling where the state is unstable and prone to memory
allocation failure.
I also add gimp_utils_backtrace_available() public API which can be used
by the Preferences.
The only debugger command which uses this value currently is gdb. And
even there, it doesn't look mandatory. The alternative call using "-p"
option does not require the program name. The manual doesn't say if
calling with the program name has any advantage (but I don't see why it
would, the PID is enough to find a process). Just in case, I leave the
prog_name parameter (because it's easier to make a parameter useless
than changing a libgimp* API) but simply allows setting it to NULL.
... backtrace_symbols() when possible.
When we allocate a new string, anyway we have memory allocation. But
when we just print to a file descriptor, this version of the API is
guaranteed without any memory allocation and therefore should always
work. This is important since allocations may fail in particular after
memory errors.
