Also remove all traces of it from the plug-in protocol and raise the
protocol version to 0x0100 (we now allow features and therefore
version bumps in stable, and the master protocol version should always
be higher). Fix the code that aborts plug-in startup on protocol
version mismatch, we can't use gimp_message() because we have no
protocol.
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.
even if we don't have private members (yet). Also make class padding 8
pointers in all headers. This commit moves nothing to private, it just
makes all headers consistent and adjusts .c files accordigly.
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.
The value descriptions of GimpGradientColor,
GimpGradientSegmentColor, and GimpGradientSegmentType enums appear
in the on-canvas gradient editor UI, as combo-box items in the tool
GUI overlay. Since we want to keep the overlay as small as
possible, we previously used abbreviations for these descriptions
(e.g., "FG (t)", instead of "Foreground (transparent)").
Replace the abbreviated descriptions with unabbreviated ones, and
move the abbreviations to the "abbrev" parameter. This way we get
the abbreviated version in the combo-box, and the full version in
the combo-box's menu.
Update the dprod production of generated enum files to include
abbreviated value descriptions, as per the previous commits.
Add a comment for translators above the abbreviated descriptions,
specifying the full description they abbreviate.
Add support for specifying an abbreviated description for enum/
flags values, which can be used in contexts where the full
description is too long.
Since the exact layout and size of Gimp{Enum,Flags}Desc is part of
the ABI, we can't simply add a field to these structs to hold the
abbreviated description. Instead, we use the fact that entries
with a repeated value in the value descriptions array are ignored,
and that the array is NULL terminated (in particular, that all non-
NULL entries are followed by at least one additional entry), and
specify the abbreviation in the "value_desc" field of the entry
that immediately follows the initial entry for a given value,
setting the "value" field of both entries to the same value.
Right now this behavior is undocumented, so there is no proper way
to specify abbreviated descriptions in the API, and is only meant
to be used in generated enum files.
to gimp_base_compat_enums_init() and move its prototype from
gimputils.h to gimpbase-private.h; it's not supposed to be
public API even though it's callable from the outside.
Michael Natterer