... only shows the color (and nothing else) when "Convert bitmaps to
vector graphics where possible" was set.
This is because gimp_drawable_histogram() only checks selected pixels.
So let's make sure we work on a duplicate of the image so that we can
safely remove the selection before processing the export.
In all themes, fix the color of selected text, while editing a
tree-view's item text (such as when renaming a layer), by
overriding tree-view specific styling with the global text-entry
style, for nested text entries inside tree-views. The text would
previously use the same color as the selection background, making
it unreadable.
This issue affects the Dark and Gray themes, although this fix only
takes care of the Dark theme.
Add devel-docs/performance-logs/performance-logs.md, which
describes how to record and view performance logs, and how to
report perofrmance-related issues.
(cherry picked from commit fa9161e4f2)
Blacklist the "threaded-ml" thread, which seems to mask the
backtrace signal.
Improve signal-handler synchronozation, to avoid segfaulting when
giving up on waiting for all threads to handle the signal.
Furthermore, when one or more threads fail to handle the signal in
time, return a GimpBacktrace instance with backtraces for all the
other threads, and with empty backtraces for all the non-responding
threads, instead of returning NULL and leaking the allocated
instance. Don't blacklist threads that failed to handle the signal
in time, and instead shorten the wait period for handling the
signal, and yield execution during waiting to lower the CPU usage.
(cherry picked from commit a29d040db5)
In sample-search predicates, remove the "exclusive" parameter of
the "function()" function, and replace it with optional "id" and
"state" parameters, which limit the match to the call-stacks of
matching threads, as per the "thread()" function.
Sort the backtrace thread-list by thread ID.
(cherry picked from commit 0b2d41635a)
Fix delta-encoding of performance-log backtraces in certain cases,
and distinguish between empty call-stacks and removed threads.
(cherry picked from commit eec1e1f189)
Connect GimpImage's gimp:mask-components node to the layers node
*before* connecting the channels node, so that the image's
component mask doesn't affect the channel colors, as is the case in
2.8.
(cherry picked from commit 56920dcdbf)
In gimp_view_renderer_drawable_render(), make sure the preview size
is always at least 1x1.
Fixes commit 8009ea342a.
(cherry picked from commit 963322fdd4)
In the preformance-log viewer, show instrumentation-variable
descriptions as tooltips for the corresponding treeview rows.
(cherry picked from commit 21b36cd864)
Include instrumentation-variable descriptions in the var-defs
section of performance logs, so that they can be displayed
alongside their names when viewing the log.
(cherry picked from commit 646208eff0)
Simplify gimp_view_renderer_drawable_render(), by consolidating
common code paths. In particular, when rendering the preview as
part of an image, always crop the preview to the bounds of the
image, even when downscaling, to avoid unnecessarily downscaling/
convering cropped-out regions. We previously only did this when
upscaling the preview by a factor of 2 or more; whatever the reason
for this used to be, it's no longer there.
(cherry picked from commit 8009ea342a)
In gimp_view_renderer_drawable_render(), avoid overflow in preview-
area calculation. This prevents erroneously setting 'scaling_up'
to FALSE while upscaling the drawable by a very large amount, which
can lead to the creation of a very large GimpTempBuf for the
preview, causing memory allocation to fail.
(cherry picked from commit 0cdbe91e5a)
Add line data padding when necessary.
Additionally I realize we should convert to little-endian after checking
the bytesperline oddness (this bug was most likely unnoticed until now
as most desktop proc are little endian now anyway).
(cherry picked from commit 5d319b77bf)
file_save(): make sure we always set an error on failure
file_save_dialog_save_image(): additionally, check that "error" exists
before dereferencing it.
(cherry picked from commit c55f2308e1)
... the second time you do a 180 degrees rotation
In gimp_transform_resize_adjust(), nudge the transformed layer
boundary by EPSILON toward the center, to avoid enlarging the layer
unnecessarily, as a result of numeric error amplified by rounding,
when the tranformed boundary should land on integer coordinates.
In particular, this avoids enlarging the layer when rotating by 180
degrees.
(cherry picked from commit c271992aa0)
...via hover tooltips
Use the GtkWidget::query_tooltip() signal on GimpFgBgEditor to emit an
own signal "tooltip" that has the hovered widget area as parameter.
Connect to GimpFgBgEditor::tooltip() in gimptoolbox-color-area.c and
set separate tooltips on the widget's areas, including the shortcuts
for "Swap colors" and "Default colors".
(cherry picked from commit ae9d84dd22)
Use a single segment with a "step" blending function, added in the
previous commit, instead of two separate segments, for the "FG to
BG (Hardedge)" internal gradient. This makes it simpler to change
its endpoint colors by modifying the gradient, instead of changing
the FG/BG colors.
(cherry picked from commit 84066ca26a)
... 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)
Add xyY color space to the color spaces for sampling colors.
Also add code to xcf-load.c that makes sure the sample point loading
code handles unknown future GimpColorPickMode values (fall back to
PIXEL pick mode).
(cherry picked from commit 298cc57042)
Add pattern offset parameters to gimp_fill_options_create_buffer() and
pass the selection's top-left corner so that pattern fills on the same
drawable are aligned.
(cherry picked from commit 38dcb73bfc)
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)
Seems we were drawing marching ants for hidden tabs ever since the
introduction of SWM, which is both a horrible waste of CPU time, and
also makes all selections visible on all displays on GTK+ 3.x.
Implement GtkWidget::unmap() in GimpDisplayShell and stop the ants
when the shell is unmapped.
(cherry picked from commit 1d43e2ff37)
In the performance-log viewer's profile view, allow sorting the
call-graph tree-views by function name, in addition to the
inclusive/exclusive frequencies.
(cherry picked from commit 4664fa73fb)
On macOS, the "drag-end" signal does not seem to be emitted in some
cases, which leaves dockables in an unsensitive state. Rather than
trying to fix GTK+2 which is half-maintained nowadays anyway, let's drop
the unsensitivity. As a comment notes, this was anyway only a visual
cue. Dragging dockables in GIMP 2.10 already shows a lot of other visual
cues, so this is redundant.
In case of drop failure, we also had to cleanup the icon widget and
detach the dockable. This can be handled by the "drag-failed" (which
hopefully work better on macOS).
As an additional improvement, I raise the newly created dockable window,
since this is the most likely behavior when you just detached a dock
(and I realize it usually appeared behind other GIMP windows, at least
on GNOME).
Note: this is a gimp-2-10 only fix as master relies on GtkNotebook DnD
code which (hopefully, as I haven't tested) doesn't have this issue. The
detached window behind other windows issue doesn't exist on master, at
the very least.
In the performance-log viewer's profile view, displasy in-line bar-
chart-like visualization of function and source-line sample
percentages, as part of the corresponding tree-view cells.
(cherry picked from commit 26ea334825)
Add missing fclose invocations and fix copy-paste issue.
This issues has been discovered by coverity scan proceeded by Red Hat.
Fixed some mistakes in the patch and added more fclose() (Mitch)
GTK/OSX does not automatically assign focus to the new windows (upstream
issue), so activateIgnoringOtherApps is called. However, if it is called
before gtk initialized it may cause number of focus issues.
In gimp_file_proc_view_get_proc(), when there is no selected
procedure (which can happen, in particular, when searching the
list), return the "automatic" procedure and its corresponding name/
filter, if one exists, instead of bailing.
Additionally, in GimpFileDialog, use a match-all filter when
gimp_file_proc_view_get_proc() returns no filter, avoiding
CRITICALs/segfault.
(cherry picked from commit e26a220a6f)
In GimpDeviceInfo, make sure that the info->axes and info->keys arrays
always have info->n_axes and info->n_keys members. Also sync axes and
keys between GdkDevice and GimpDeviceInfo more often, and some
cleanup.
(cherry picked from commit 7adb6c26e5)
In performance-log-viewer.py, fix thread-state toggling in the
profile-view thread-filter popover, when not all threads are
included in the current selection.
(cherry picked from commit 43b492ff83)
In the GimpBacktrace Linux backend, always use libunwind, when
available, to find symbol names, even if dladdr() or libbacktrace
had already found one. libunwind provides more descriptive names
in certain cases, and, in particular, full symbol names for C++
lambdas.
Note that, in some cases, this can result in a discrepancy between
the reported symbol name, and the corresponding source location.
(cherry picked from commit 72fc01742b)
In the GUI implementation of gimp_wait(), explicitly finish the
input-pipe async operation after the busy-dialog plug-in
terminates, to avoid the async callback function from being
repeatedly called, stalling the main thread. Previously, this code
relied on gimp-parallel implicitly aborting the async operation,
but this is no longer the case since commit
4969d75785.
(cherry picked from commit 85b16b9eaa)
Add a new performance-log-coalesce.py tool, which groups together
performance-log address-map entries belonging to the same function
into a single symbol, by filling-in missing base symbol addresses.
The addresses are grouped such that each set of addresses
corresponding to a symbol of the same name, in the same source
file, are given the same (unique, but arbitrary) base address.
See the previous commit for why this is necessary.
This should work fine in most cases, however, for logs produced on
Windows, it can over-coalesce addresses belonging to different C++
lambda-functions in the same source file, since they all seem to be
given the same _FUN symbol name.
Use the new tool as part of the pipeline in performance-log-viewer.
(cherry picked from commit cb51ea981a)
In the GimpBacktrace Windows backend, avoid reporting meaningless
symbol addresses when failing to retrieve meaningful ones.
Unfortunately, it seems that we never get symbol addresses for
symbols that have debug information, which negatively affects the
log viewer's call graph. We're going to have to work around this.
(cherry picked from commit 52772cf3ff)
When initializing the GimpBacktrace Windows backend, set the name
of the current thread (which is assumed to be the main thread) to
the program's name, to match its name on Linux. We normally rely
on the SET_THREAD_NAME exception to set thread names on Windows,
which isn't raised for the main thread.
(cherry picked from commit 52908f397f)
In the gimp_parallel_run_async() family of functions, allow the
async callback to return without completing the async operation, in
which case the callback will be called again, until the operation
is either completed, or canceled, in which case it is aborted
(previously, returning from the callback without completing the
operation would cause it to be aborted.) It is guaranteed that all
operations of the same priority will get a chance to run, even if
some of them contuinuosly return without completing.
This allows potentially time-consuming operations to yield
execution in favor of other same-priority operations, and, in
particular, of higher-priority operations, to avoid priority
inversion. Essentially, this allows a simple form of cooperative
multitasking among async operations.
(cherry picked from commit 4969d75785)
Replace GimpTransformTool's 'drawable' field with an 'item' field,
and have GimpTransformGridTool set it to the active item, to which
the transformation is applied, during its initialization. In
gimp_transform_tool_get_active_item(), return the value of the
transform tool's 'item' field, if not NULL, instead of the image's
active item. This makes sure we apply that transform-grid tools
apply the transformation for the item for which they were
activated, even if the image's active item has changed.
(cherry picked from commit 3eaae58595)
Apply the check/radio-button style to GtkTreeView, so that
GtkCellRendererToggle picks the right check/radio-button graphic.
Otherwise, it falls back to a graphic that depends on the system
theme, and which may not play well with the current theme colors.
Note that this only affects the Dark theme; in the Light and Gray
themes, one of the KDE-hack styles "takes care" of this, but this
commit applies the same change to these themes anyway.
When shutting-down gimp-parallel, cancel and/or abort any ongoing
and queued async operations, instead of finishing them (async
operations that already started executing will be canceled, but
execution will be blocked until they're finished.) This is
especially important since we're shutting down gimp-parallel before
the destruction of data factories. This commit causes any ongoing
async operations of the factories to be canceled on shutdown,
rather than waiting for them to finish normally.
(cherry picked from commit e46fdc714e)
Add a new GimpData::data_cancel() virtual function, and a
corresponding gimp_data_factory_data_cancel() function. This
function should cancel any ongoing async operations related to the
factory (i.e., included in its async set), and wait for the
operations to finish. Provide a default implementation that simply
cancels and waits on the factory's async set.
Use this function to cancel any ongoing operations during factory
destruction, and in gimp_data_factory_data_free().
Override this function in GimpFontFactory, for which we can't
really cancel font loading, and simply cancel and clear the
factory's async set without waiting for loading to finish, making
sure that nothing happens (and, in particular, that the factory
isn't being accessed, since it might be already dead) when loading
does finish.
(cherry picked from commit 6bc0b3b8ad)
In gimp_data_factory_data_foreach(), don't rely on internal
GimpData objects being sorted first (while this is currently true
for all types of GimpData, they may override the sort order.)
(cherry picked from commit 50bab438ce)
Add an annotated source view to the performance-log viewer's
profile view. When selecting the [Self] entry of a function's
profile, for which source information is available and whose source
is found locally, a new column opens, showing the function's
source, annotated with sample statistics. Header-bar buttons allow
navigation through the annotated lines, selection of all the
samples corresponding to a given line, and opening the text editor
at the current line.
(cherry picked from commit 88438c5055)
... when selecting a function's samples
Since we now preserve the call-graph path across state changes,
there's no need to explictly set the path after selecting a
function's samples in the profile view.
(cherry picked from commit b672f20075)
... in backtraces
In the performance-log viewer's backtrace viewer, show a document
icon next to stack frames with source-location information, whose
source file is found locally. Clicking the icon opens the source
file in a text editor at the relevant line.
Two environment variables control this feature:
- PERFORMANCE_LOG_VIEWER_PATH is a list of colon-separated
directories in which to look for source files. If this
variable is undefined, the current directory is used.
- PERFORMANCE_LOG_VIEWER_EDITOR is the command to use to launch
the text editor, for editing a specific file at a specific
line. The special strings "{file}" and "{line}" are replaced
with the filename and line-number, respectively. If this
variable is undefined, "xdg-open {file}" is used.
(cherry picked from commit 0f38709259)
Don't take infinite values into account when calculating the
vertical scale of sample graphs, and rather display infinite values
as dashed lines at the top of the graph.
(cherry picked from commit 46e5e4d478)
When re-activating an operation tool by clicking on a different
drawable while the tool is active, we re-call the corresponding
procedure to re-activate the tool, which implictly initializes it.
Avoid initializaing it explicitly in addition to that, since this
leads to the creation of a new config object by the filter tool,
while the GUI still refers to the old, now-dead, config object,
causing CRITICALs or segfaults when changing any parameter.
(cherry picked from commit a21667821c)
In the warp tool, don't commit a trivial (empty) transform. This
is especially important now that exiting the tool through undo
causes it to get comitted (... with a trivial transform).
(cherry picked from commit d12dd3fb35)
... changing layers and warping layer B
Add a new GimpToolControl::dirty_action field, which specifies the
tool action to perform when the a dirty event matching the tool
control's dirty mask occurs; this field defaults to HALT. Apply
this action to the active tool in tool-manager in response to a
matching dirty event, instead of unconditionally halting the tool.
Likewise, use this action to stop the active tool in response to a
button-press event on a different drawable in the same image.
Set the dirty action of the gradient and warp tools to COMMIT, so
that they get comitted, rather than stopped, in cases such as
switching layers (including switching to/from quick-mask mode),
and, for the warp tool, changing the selection.
(cherry picked from commit ed20393f0e)
In gimp_drawable_real_{apply,replace}_buffer(), bail if the
applcation region, after intersection with the drawable and mask
extents, is empty. This avoids trying to create a GeglBuffer with
negative width/height.
(cherry picked from commit ae3c006293)
... (some sort of corruption)
In gimp_drawable_real_replace_buffer(), adjust the processed buffer
and mask_buffer regions according to the changes made to the
application region, as calculated by intersecting it with the
drawable and mask extents. This fixes wrong application position
when painting using the heal, dodge/burn, smudge, or convolve
tools, on a drawable whose origin is above/to the left of the
image's origin, and there's a selection active.
(cherry picked from commit a782acab57)
... the XCF file
Add a "saving" signal to GimpImage, which is emitted when the image
is about to be saved or exported (but before it's actually saved/
exported). Connect to this signal in tool-manager, and commit the
current tool in response (unless its GimpToolControl::preserve is
TRUE).
(cherry picked from commit ae628a8664)
Add undo functionality to the performance-log viewer, which allows
undoing/redoing changes to the sample selection, and the call-graph
state.
(cherry picked from commit 6ad3dbdb17)
Please everyone, feel free to update the list of upcoming
changes/features, if you feel some particular change should be more
prominently exposed in this list (or at the opposite that some change is
not worth mentionning), or for rewording, etc.
(cherry picked from commit ba53a833b2)
We currently construct the tool-options GUI for all the tools at
startup, which takes a significant amount of time. Instead,
only register the GUI construction function with the tool-options
object, using the new gimp_tools_set_tool_options_gui_func()
function, and use the registered function to construct the GUI when
actually needed.
(cherry picked from commit c1347a7f26)
Fix int-ratio variable formatting when the input is NaN, which can
happen when calculating the standard deviation, if all the values
are infinite.
Fix keyboard sample-range selection.
Deselect all samples when right-clicking a sample graph.
(cherry picked from commit d33fb0e7b8)
script-fu used to query the information of every PDB procedure on
startup, in order to get the number of parameters for each
procedure. This was done so that nullary procedures were defined
in such a way as to accept (and ignore) any number of arguments
(and at least one of the scripts we ship relies on this behavior).
However, this requires expensive back-and-forth communication with
the main GIMP process, which notable slowed down script-fu's
startup, and had a non-negligible impact on GIMP's startup time.
Instead, avoid querying procedure information, and implement the
special behavior for nullary procedures at call time. We do this
by defining, in addition to the "strict" gimp-proc-db-call
procedure, a "permissive" -gimp-proc-db-call internal procedure,
and using the latter to call the predefined PDB procedures.
(cherry picked from commit 9a2999a553)
... after erasing all points
When erasing the last remaining point in the iscissors tool, halt
the tool, rather than leaving the tool active with an empty curve,
which it is not prepared to handle, and which results in a segfault
once trying to add a new point.
Additionally, when erasing the last remaining segment (i.e., the
two last remaining points), don't erase the entire segment (i.e.,
both points), but rather convert the segment to its initial point,
so that, in effect, we only erase the last point of the segment.
(cherry picked from commit a5baba5539)
In GimpTransformTools, precalculate the resulting size of the
transformed item(s), and request confirmation if the size grows to
over 10 times the size of the image (in either dimension). This
protects against transformations that can result in suprprisingly
large items, such as inverted transformations, and, specifically,
perspective-correction transformations performed using the measure
tool, which will be added in the following commits.
(cherry picked from commit 20a6a3583b)
When removing the focus widget of a GimpToolWidgetGroup, use the
last child, rather than the first child, as the new focus widget.
This plays nicer with auto-raise, and is probably better anyway.
(cherry picked from commit 24fb597196)
When a focused widget is added to a group, make it the new focus-
widget of the group, instead of unsetting its focus if another
widget already has focus.
When removing the focused widget from a group, set a different
widget as the group's focus widget (if one exists), instead of
unsetting the focus widget, so that nonempty groups always have a
focus widget.
(cherry picked from commit 95d2c92ff2)
In gimp_tool_widget_group_button_press(), explicitly call
gimp_tool_widget_group_hover() before forwarding the event to the
group's hover widget, so that the hover widget gets recalculated.
If a widget is added to the group as a result of a button-press
event, this guarantees that it gets considered as a target for the
same event.
(cherry picked from commit 5b217b3ad4)
In the performance-log viewer, add an option to filter which
threads, and which states of each thread, are included in the
profile. By default, all threads in the RUNNING state are
included.
(cherry picked from commit 3f630378b0)
In the performance-log viewer, defer updates to the various UI
elements when the selection changes until they're actually shown.
This improves responsiveness when changing the selection.
(cherry picked from commit a7afbe13ec)
When libbacktrace is available, use it to retrieve source location
information in the Linux GimpBacktrace backend.
(cherry picked from commit 7cdd1ebeef)
Use the less-ambiguous, if just as clumsy,
"format-indent-more/less" icons, to stand for the
caller -> callee, and callee -> caller, directions, respectively.
(cherry picked from commit c7a4eb4602)
Commit 6484e91f82 broke the arrow
color of menu items with a submenu in the Dark theme; it seems to
have always been broken in the Light and Gray themes.
Fix this, by applying the default style to the GtkMenuItem class.
Fix searching for samples by thread name, in particular, when there
are unnamed threads.
Use GtkMenuButton, instead of GtkButton, for the find-samples
header button.
Add mnemonics to the find-samples popover.
(cherry picked from commit c537341d35)
... provided by RawTherapee's installer (version 5.5+).
See https://github.com/Beep6581/RawTherapee/issues/4783.
This patch required a small change to file_raw_get_executable_path
because the RawTherapee installer is supposed to work without admin
privileges and therefore can't write to HKLM.
Reviewer's note (Jehan): RawTherapee's installer does not add the
registry entry yet. We assume the upstream bug report will end up doing
so (someone has to make the first step!). :-)
(cherry picked from commit 829ca6583d)
... and G_TYPE_INSTANCE_GET_PRIVATE()
g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() were
deprecated in GLib 2.58. Instead, use
G_DEFINE_[ABSTRACT_]TYPE_WITH_PRIVATE(), and
G_ADD_PRIVATE[_DYNAMIC](), and the implictly-defined
foo_get_instance_private() functions, all of which are available in
the GLib versions we depend on.
This commit only covers types registered using one of the
G_DEFINE_FOO() macros (i.e., most types), but not types with a
custom registration function, of which we still have a few -- GLib
currently only provides a (non-deprecated) public API for adding a
private struct using the G_DEFINE_FOO() macros.
Note that this commit was 99% auto-generated (because I'm not
*that* crazy :), so if there are any style mismatches... we'll have
to live with them for now.
In gimp_paint_core_loops_process(), initialize the iterator with
sufficient room for the number of iterators used by the algorithm
hierarchy, instead of a fixed number.
Add an additional 'rect' parameter to the init_step() and
process_rows() algorithm member functions, which receives the area
of the currently-processed chunk, to be used instead of the
iterator's ROI member. This allows us to pass a NULL iterator to
hierarchies that don't use an iterator, and avoid the stack-
allocated iterator hack we used in this case (and which became even
more problematic with the new iterator API).
(cherry picked from commit 6c6a7514a4)
... for applying the global style.
Last commit *might* have fixed the need to use "*" instead of
"GtkWidget", although it's hard to tell -- nothing seems to be
obviously wrong, anyway. Let's just try restoring this, and see if
anything breaks.
In the gtkrc files of the Dark and Light themes, replace a bunch of
"widget" selectors with "widget_class" selectors, which is what
they really should be (they should probably also use angle-bracket
notation for classes, but as long as it works...) This allows the
different styles to be merged correctly, and fixes the active layer
name color (more generally, the text color of selected rows of
focused tree-views inside dockables.) The Gray theme seems to be
double-broken in such a way that "fixing" it causes it to do the
"wrong" thing... I'm not touching that :)
My previous commit answers the forever question "do we want to require
this?" which was in comments and can now be removed.
We don't need to actually require this operation for running GIMP, as it
runs fine without. Just testing in configure is enough of a warning for
the missing feature.
(cherry picked from commit 97247f41ea)
This is a runtime dependency. If absent, we simply won't have access to
the alternative Matting Levin engine in the foreground selection tool.
If we don't add a test in configure, this may be easily forgotten. I
created the `gegl --exists` feature specifically for this kind of
checks, so let's check operation existence.
(cherry picked from commit 9560a653c5)
After Dirk Farin had another look in the specs, it turns out that "mif1"
is actually allowed as major brand for HEIF. Also adding "msf1" which is
the equivalent for image sequences.
(cherry picked from commit 64b00b5c7f)
Just looking for "ftyp" would also match other ISOBMFF files (.mov or
.mp4 files for instance). These are the possible 4-byte "brand" code
which can follow "ftyp", as listed by Dirk Farin from libheif.
I add the "mif1" brand, as I encountered some files using this magic
(even though this should normally not be valid apparently, yet the file
loaded fine in GIMP).
This is not perfect as the standard allows potentially very big box
headers, in which case 8 bytes (the "largesize" slot) may be inserted
between "ftyp" and the brand, as I understand it. But this is actually
unlikely enough to probably never happen (the compatible brands list
would have to be huuuge, as it looks like this is the only extendable
part in a ftyp box). So let's assume this just never happens.
See also: https://github.com/strukturag/libheif/issues/83
(cherry picked from commit 4ad3993eca)
Nicknames on IRC/gitlab are hard, even more when they change depending
on the media! I realize we are regularly asking them or unsure of who to
contact (for instance here for releases). Let's associate each package
with its current maintainer to make it easy to contact the right person
to prepare our official packages before a release.
(cherry picked from commit dc9a30446b)
Adding a magic number for HEIC/HEIF, which would allow to discard
obvious non-HEIC images even with the wrong extension.
Note: it looks like this magic number would also match more generically
other ISO base media file format (ISOBMFF) formats, like .mov or .mp4
files. I am enquiring for better magic but for now, this is better than
nothing.
(cherry picked from commit d738d2f645)
performance-log-viewer.py is a viewer for GIMP performance logs.
The viewer is made up of two parts: a sample-selection area at the
top, and an information area at the bottom.
The sample-selection area visualizes the sampled variables and
markers using a simultaneous set of plots, and displays the
currently selected samples. Samples can be selected directly
through the sample-selection area, or by other means, such as
searching for all samples satisfying a certain condition, or
containing a certain function.
The information area shows global information stored in the log, as
well as information specific to the currently selected samples,
including variable listing and statistics, full backtrace, and
profile/call-graph information.
Note that performance-log-viewer.py takes its input from STDIN,
like the rest of the performance-log tools, and is therefore
suitable for use as part of a pipeline. For standalone use, the
performance-log-viewer driver is also included, which takes the log
file as a command-line argument, and processes it through an
appropriate pipeline before feeding it to the viewer.
(cherry picked from commit 3601c9189b)
... which statistically deduces the correct thread states based on
backtrace address frequency, fixing local inaccuracies.
(cherry picked from commit 7e186f3e5d)
In addition to the verbose GIMP version, include in performance
logs the values of all environment variables beginning with BABL_,
GEGL_, or GIMP_, and of all the GEGL config options.
(cherry picked from commit 2c6b5c371e)
* The minimum GIMP version for this XCF is always written down when it
is GIMP 2.8 or over.
* The list of features warrating the minimum version is now listed in an
expander container rather than as tooltip (making the list actually
discoverable!).
* The warning on compression is now displayed as its own text under the
checkbox (only when checking the box actually changes anything
compatibility-wise), and not as additional text to the minimum GIMP
version label. Otherwise it had far too much weight on the minimum
compatible GIMP version text and people were wondering what it meant.
We should not tell people what the checkbox cannot do (it cannot
improve compatibility in some cases), only what it can do (it can
improve compatibility in other cases).
* Update the feature list real-time when checking the compression box
(making it even more obvious that tile compression may have a say in
compatibility).
* Metadata info is still added on the GIMP version label as it does not
limit compatibility of the XCF file itself.
(cherry picked from commit 573d817539)
Even though chosen as a parameter to gimp_image_get_xcf_version() and
not a feature within the image itself, we also want to list this reason
in the compatibility list.
(cherry picked from commit 0fa2ef9118)
When moving a text layer using the text tool (through alt+drag),
don't change the layer's box mode to "fixed", which is unnecessary,
since the layer's size isn't affected.
(cherry picked from commit 601c213c7a)
While editing a text layer with the text tool, update the layer's
frame when the layer moves, which most notably happens when
undoing/redoing a move operation while the text tool is active.
(cherry picked from commit 238c1035db)
The various functions of the text tool currently block and unblock
drawing (through gimp_text_tool_[un]block_drawing()) implicitly,
and in a non-symmetric fashion, which makes the tool's logic rather
fragile. Instead, require blocking/unblocking to be done
symmetrically, and explicitly block/unblock drawing as necessary in
all functions.
(cherry picked from commit a03183b266)
Improve out-of-range check in gimp_backtrace_find_thread_by_id().
Remove unnecessary #include <exchndl.h> in gimpbacktrace-windows.c,
and revert commit 644234e99d (the
DrMingw detection happens at runtime). The Windows backend can
work without DrMingw, it just can't find all the symbols, and
doesn't provide source-location information.
(cherry picked from commit b9f1ab8f53)
The "running" attribute (readable through
gimp_backtrace_is_thread_running(), and recorded in the performance
log) specifies if the thread was in a running or suspended state at
the time the backtrace was taken. It is accurate on Linux, but
only approximated on Windows.
Adapt the performance-log-expand.py tool to maintain this attribute
(and any future thread attributes we might add).
(cherry picked from commit 78adb7c900)
The Windows backend produces full, multithreaded backtraces. When
DrMingw is available, it also provides full symbol and (where
available) source-location information. Otherwise, it provides
symbol information for most of our libraries, but not for the GIMP
binary itself.
(cherry picked from commit 667efc221d)
Add source filename and line number fields to the
GimpBacktraceAddressInfo struct, populated through
gimp_backtrace_get_address_info(). This is not currently supported
by the Linux backend, but is supported by the Windows backend,
which we'll be added in the next commit.
(cherry picked from commit a6ec857123)
This function returns information about the given address, which
is currently mostly limited to the corresponding symbol
information, but we might want to add address-specific information
in the future, such as a line number.
(cherry picked from commit 7ac87dc01e)
In all the selection tools, show an error (and a BAD cursor
modifier) wheh starting a selection, if the current selection is
empty, and the tool is in SUBTRACT or INTERSECT mode (in which
case, the selection has no effect).
(cherry picked from commit 0e26525e65)
We're currently only using GimpHighlightableButton in the layers
dialog, which defines its own set of highlight colors. We're going
to use highlightable buttons in the dashboard too, so let's move
the highlight colors to gimphighlightablebutton.h, and give them
standard names. We currently define
GIMP_HIGHLIGHTABLE_BUTTON_COLOR_AFFIRMATIVE (green), and
GIMP_HIGHLIGHTABLE_BUTTON_COLOR_NEGATIVE (red).
(This commit was accidentally dropped from the gimp-2-10 branch; it
should have gone before 40ac4f7bc0f43aee24dc7ae1cf674d1a59612f55.)
performance-log-expand.py decodes a delta-encoded performance log
by expanding the deltas, producing a log where each sample (and
other relevant elements) contain complete information. Note that
the structure of expanded logs is identical to that of delta-
encoded logs, the expanded log simply has no deltas.
performance-log-resolve.py resolves symbol information in
backtraces. The logs produced by GIMP only specify the program
counter at each stack frame, providing an address-map to map
program-counter addresses to actual symbols separately. This tool
looks up each program-counter address in the address map,
incorporating the relevant symbol information directly into the
backtrace.
Both tools read their input from STDIN, and write their output to
STDOUT, and can be chained in a pipeline (with
gimp-performance-log-expand.py appearing first).
Note that these tools require Python 3.
(cherry picked from commit d7c74a615b)
Add an option to record a performance log through the dashboard.
The log contains a series of samples of the dashboard variables, as
well as the full program backtrace, when available. As such, it
essentially acts as a built-in profiler, which allows us to
correlate program execution with the information available through
the dashboard. It is meant to be used for creating logs to
accompany perofrmance-related bug reports, as well as for profiling
GIMP during development.
The sample frequency defaults to 10 samples per second, but can be
overridden using the GIMP_PERFORMANCE_LOG_SAMPLE_FREQUENCY
environment variable. Backtraces are included by default when
available, but can be suppressed using the
GIMP_PERFORMANCE_LOG_NO_BACKTRACE environment variable.
Logs are created through the new "record" button at the bottom of
the dashboard dialog. When pressed, a file dialog is opened to
select the log file, and, once confirmed, data is being recorded to
the selected file. Recording is stopped by pressing the "record"
button again (we use a highlight to indicate that recording is
active.)
While recording, the "reset" button is replaced with an "add marker"
button, which can be used to add event markers to the log. These
can be used to mark events of interest, such as "started painting"
and "stopped painting", which then appear in the log as part of the
sample stream. Markers are numbered sequentually, and the number
of the next (to-be-added) marker appears on the button. Shift-
clicking the button adds an empty (description-less) marker, which
is only identified by its number; this can be used when markers
need to be added quickly.
The log is an XML file, containing some extra information (such as
the output of "$ gimp -v", and symbol information) in addition to
the samples. The data in the file is delta-encoded to reduce the
file size, meaning that samples (as well as some other elements)
only specify the changes since the previous sample. This adds a
necessary decoding step before data can be processed; the next
commit adds a tool that does that.
There are currently no tools to actually analyze the data -- that's
still TBD -- but at least we can start gathering it.
GimpBacktrace provides an interface for creating and traversing
multi-threaded backtraces, as well as querying symbol information.
While we already have some backtrace functionality, it relies on
external tools for the most part, and as such is rather expensive,
and is only meant for producing opaque backtraces. GimpBacktrace,
on the other hand, is meant to be relatively cheap (we're going to
use it for profiling,) and allow inspection of the backtrace data.
In the future, it might make sense to replace some, or all, of the
other backtrace functions with GimpBacktrace.
GimpBacktrace currently only supports Linux. By default, it uses
dladdr() to query symbol information, which is somewhat limited (in
particular, it doesn't work for static functions.) When libunwind
is installed, GimpBacktrace uses it to get more complete symbol
information. libunwind is currently an optional dependency, but it
might make sense to promote it to a mandatory, or opt-out,
dependency, as it's lightweight and widely available.
On other platforms, the GimpBacktrace interface can still be used,
but it always returns NULL backtraces.
(cherry picked from commit 80bf686c94)
Move the call to gimp_filter_tool_disable_color_picking() from the
filter-tool's dialog "unmap" handler to gimp_filter_tool_halt().
Since commit ec80a88513, we
explicitly destroy the GUI when halting the filter tool, which
happens before the dialog's unmap handler is called, which could
potentially result in a dangling pointer to the active color-picker
widget in gimp_filter_tool_disable_color_picking().
(cherry picked from commit 072d6b0d12)
... 100% position anymore
In GimpGuideTool, use a closed [0, max_position] range as the
allowable range for new/repositioned guides (where max_position is
either the image's width or height), so that guides can be placed
at the right/bottom edge of the image.
(cherry picked from commit 547190faa8)
In gimp_image_merge_layers(), explicitly fetch the graph of the top
layer's parent layer (if exists), to make sure that the top layer's
graph has a parent node. We already fetch the image graph, which
takes care of top-level layers, however, if the top layer is a
child of an invisible layer group, as is the case in the wavelet-
decompose plug-in, this is not generally enough to guarantee that
the group's graph is constructed.
(cherry picked from commit e563845174)
In gimp_filter_tool_halt(), explicitly clear the GUI container
before clearing filter_tool->config, since the tool might be halted
during the GUI dialog's delete event, in which case the GUI will
only be implicitly destroyed *after* the function returns. The
destruction of the GUI might fire signals whose handlers rely on
filter_tool->config, so we need to make sure it happens while it's
still alive.
In particular, this fixes a CRITICAL in the threshold tool, which
occurs due to the histogram view's "range-changhed" signal being
fired during its destruction, and its handler accessing
filter_tool->config.
(cherry picked from commit ec80a88513)
gimp_device_info_set_device(): don't just bail out if a device with
the same name is added again, instead, simply continue and overwrite
the info's old device with the new one.
NOTE that this only happens if something is wrong on the USB or udev
or libinput or whatever side and the same device is present multiple
times. The only "safe" thing is to assume that devices listed earlier
are dead and dangling entities and that the last registered device is
the one actually delivering events.
(cherry picked from commit 717c183a3e)
In GimpProjection, use an adaptive chunk size when rendering the
projection asynchronously, rather than using a fixed chunk size.
The chunk size is determined according to the number of pixels
processed during the last frame, and the time it took to process
them, aiming for some target frame-rate (currently, 15 FPS). In
other words, the chunks become bigger when processing is fast, and
smaller when processing is slow. We're currently aiming for
generally-square chunks, whose sides are powers of 2, within a
predefined range.
Note that the chunk size represents a trade off between throughput
and responsiveness: bigger chunks result in better throughput,
since each individual chunk incurs an overhead, in particular when
rendering area filters or multithreaded ops, while smaller chunks
result in better responsiveness, since the time each chunk
individual takes to render is smaller, allowing us to more
accurately meet the target frame rate. With this commit, we aim to
find a good compromise dynamically, rather than statically.
The use of adaptive chunk sizes can be disabled by defining the
environment variable GIMP_NO_ADAPTIVE_CHUNK_SIZE, in which case we
use a fixed chunk size, as before.
(cherry picked from commit a1706bbd29)
Add a boolean "chunk" parameter to
gimp_projection_chunk_render_iteration(), which determines whether
the work area should be sub-divided into chunks prior to rendering
(previously, the work area would always be sub-divided.) Only
pass TRUE when rendering the projection asynchronously, in the
render callback, and pass FALSE when rendering the projection
synchronously, in gimp_projection_finish_draw(), which is called
when flushing the projection through the GimpPickable interface.
Rendering the projection using as big chunks as possible improves
performance, while worsening responsiveness. Since responsiveness
doesn't matter when rendering synchronously, there's no reason to
render in chunks.
(cherry picked from commit 105ffc787d)
In gimp_transform_tool_transform(), use "active_item", instead of
"tool->drawable", when cutting/pasting the selected portion of a
layer for transformation. The latter is a remnant of the old
transform-tool code, and is not guaranteed to be correspond to the
correct drawable, or even to a valid drawable (i.e., it can
potentially produce wrong results, or segfault.)
(cherry picked from commit 9420805525)
In the command handler of GimpTileBackendPlugin, forward unhandled
commands to gegl_tile_backend_command(), instead of asserting that
they're within range (which has already been disabled by commit
bc3b076caf). See GEGL commit
30047e65723ebb44fcde9c6b5f60ceecb43b0895.
(cherry picked from commit 668fee966a)
... which reports the amount of data queued for writing to the
swap (see GEGL commit 64021786ee067cf66c038622719acc590e6341db.)
When the swap queue is full, a yellow color underlay is shown in
the history graph.
(cherry picked from commit cd54457d46)
The "compression" field reports the ratio between the total size of
the data in the swap, and the total size the data would have had if
all tiles in the swap occupied a unique data block.
See GEGL commit 185f4450f2a51690b39112973c61f894c1ec3e41.
(cherry picked from commit b6e552a74b)
In gimp_tile_backend_plugin_command(), disable the range check for
the input tile command. This check prevents us from adding new
tile commands to GEGL without breaking the ABI; yet, the next GEGL
release will add a new command. We're going to have to decide what
to do about this, but for now, let's just disable the check, so
that at least GIMP 2.10.6 is compatible with newer versions of
GEGL, no matter how we end up handling this.
Do not set the interpreter to `python2` but to whatever was found by the
AM_PATH_PYTHON2() m4 macro.
It looks like the Python2 binary we ship in our DMG may be call "python"
only (without the '2'). Let's just make our code more resilient to
various builds.
I am not sure yet this is the only/actual problem for this issue on
macOS, but this is at least in the right way.
If I override the `program` variable, and it is not found in PATH
environment, then it is NULL and the error message is unhelpful. Make
the return value of g_find_program_in_path() into a separate variable
instead, and only override `program` in the end, when we know it is
non-NULL.
The python path with directory are generated files and should not be in
the dist. The previous commit was fixing an in-tree `make check` but
this one fixes the `make distcheck` as the dist was packaging the wrong
python files.
This issue was invisible when making VPATH builds, but appeared only in
source-tree builds as gettext tools are apparently mixing source and
build files. So we need to add these in the POTFILES.skip.
It seems I forgot to also install python plug-ins in a subdirectory
(because they are deactivated on master for the time being). I even
found a year-old patch from myself rotting in the tracker, and which was
doing exactly this.
I redid it, improved to fit changes.
(cherry picked from commit dbb9555d2f)
I am going to forbid plug-ins from being installed directly in the root
of the plug-ins/ directory. They will have to be installed in a
subdirectory named the same as the entry point binary.
This may seem useless for our core plug-ins which are nearly all
self-contained in single binaries, but this is actually a necessary
restriction to eliminate totally the DLL hell issue on Windows. Moving
core plug-ins in subfolders is only a necessary consequence for it.
(cherry picked from commit 870ca6334d)
... Windows installation of GIMP.
Our default installer installs 32-bit version of the various DLLs in
32/bin/ (under the installation prefix). Currently this additional
folder is simply added in the PATH, so it works most of the time.
Unfortunately the PATH is searched last for DLLs, and in particular, it
is searched after system directories. So it means that if any misbehaved
application is installing DLLs in system dirs (and in particular
incompatible/older versions of the same DLLs a GIMP plug-in uses), it
breaks the 32-bit plug-in.
SetDllDirectoryW() bypasses this order and the set folder is searched in
between the binary directory and the system dirs. We were already
setting this for our main bin/ directory, which was good for 64-bit
plug-ins, but this was not protecting 32-bit plug-ins. Now our code to
run plug-ins check the bitness of the executable before running it, and
updates the DLL folder accordingly.
The alternative 32-bit folder can be overridden by the configure option
--with-win32-32bit-dll-folder (default: 32/bin/). This option can only
be set when building for 64-bit Windows obviously.
Alternatively we could have put copies of 32-bit DLLs in a subfolder
with each 32-bit plug-in, but this is at best a terrible workaround, as
we would duplicate DLLs for every such case. And this would not have
protected third-party plug-ins which wish to use some of our DLLs.
Last alternative is to use AddDllDirectory(), but it works since Windows
7 with a given update only. And our current official support is any
Windows since Windows 7. So we don't want to use this right now (also
I'm not sure it would actually be much better than current
implementation, and it seems to have a bit more limitations than
SetDllDirectoryW(), though I have not tested).
This will go with the next commit, but I broke it so I can backport the
code without extension handling in gimp-2-10 first.
(cherry picked from commit c7b5977637)
Debugging stable versions under Windows is a pain because we don't have
access to the standard outputs. The debug console is indeed only built
on unstable builds. Let's make the debug console a separate build option
to allow building stable versions for debug (obviously the default
behavior when not configuring, is same as before, i.e. stable without
console and unstable with console).
When cross-compiling, I got various linking errors for printf() calls:
> undefined reference to `libintl_printf'
I am unsure why, since this is not recent code, and it used to build
fine with mingw64 compilers (last I cross-built, which is many months
ago). Anyway g_printf() works fine, all necessary libs are already
linked, and it is supposed to be a synonym. So let's just go the easy
way and use g_printf() only.
AM_PATH_GLIB_2_0 m4 macro actually computes this value using
$PKG_CONFIG. Yet $PKG_CONFIG variable is the pkg-config tool looking for
target libraries (not host), hence it would return the executable
`glib-compile-resources` built for the target.
Also using the same variable name invalidates our test: our own
AC_PATH_PROG was never run as the variable was already set. And no
environment variable could override this test anymore either. This is
why I rename the test variable to HOST_GLIB_COMPILE_RESOURCES.
Though no error was raised during a native build, a cross-build was
choking on this missing link to libgimpbase and failing.
The error returned by the linker though was a bit amiss.
Fixes:
> gimp-test-clipboard.o: In function `test_clipboard_copy_callback':
> tools/gimp-test-clipboard.c:419: undefined reference to `g_file_get_contents'
> collect2: error: ld returned 1 exit status
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)
Removing unused declaration of icons_set_icon_theme().
And reorder a bit the declarations to match the definition order.
(cherry picked from commit ae19441ddc)
In gimp_group_layer_update_size(), never suspend drawable updates
(and, in fact, remove the option to suspend drawable updates
entirely,) and instead never update the drawable during the call to
gimp_drawable_set_buffer_full(), and flush the group's projection
*after* setting the drawable's buffer, so that any pending updates
will happen after the group's buffer and size are up-to-date.
This fixes some missed drawable updates.
(cherry picked from commit fc2c640ca2)
In GimpProjection, change gimp_projection_add_update_area() to take
coordinates in the projection's coordinate system, rather than the
image coordinate system, and move the offset adjustment to the
projectable invalidation handler.
Modify gimp_projection_projectable_structure_changed() to pass
projection-space coordinates to gimp_projection_add_update_area().
gimp_projection_get_buffer() and
gimp_projection_projectable_bounds_changed() already pass
projection-space coordinates to gimp_projection_add_update_area(),
which was wrong before, when the projection had a nontrivial
offset, but is correct now.
(cherry picked from commit 2d63bc6e0a)
Fixed by implementing Massimo's two findings:
gimp_operation_cage_transform_process(): if aux_buf is NULL, bail out
after initializing out_buf with identity vectors, fixes the crash.
gimp_cage_tool_create_filter(): set the drawable filter's region to
GIMP_FILTER_REGION_DRAWABLE, fixes offset when there is a selection.
(cherry picked from commit 49dfc6143d)
In GimpCanvasTransformPreview, add the necessary bits to the
preview graph so that, when transforming a layer, the layer's
opacity and mask are correctly applied to the preview. Note that
since we're still not rendering the preview as part of the image
graph, the output is not always accurate, but it should be good
enough in most cases.
(cherry picked from commit 2ac91e0fc3)
Ok my previous fix was wrong (at least for the part in the macro). This
is a macro, not a function. So each time we write _reason, the call to
g_strdup_printf() is reevaluated, hence data is allocated.
The right fix is to prepend `tmp` to the list, not `_reason`.
Thanks to Massimo for the debugging, as always!
(cherry picked from commit 2912fe7c17)
ADD_REASON macro was leaking the allocated string when version_reason
return value was NULL (i.e. when we didn't care about the version
reasons).
Also we were not properly freeing all the reason strings at the end,
only the list. Use g_list_free_full() instead of g_list_free().
(cherry picked from commit 0ab682b0f5)
In gimp_projection_projectable_bounds_changed(), bail early by
calling gimp_projection_projectable_structure_changed() instead, if
the new bounds don't intersect the old bounds.
(cherry picked from commit c6b8a4213c)
In gimp_projection_projectable_bounds_changed(), which is called by
GimpProjection in response to a GimpProjectable::bounds-changed
signal, invalidate all regions of the new projection that weren't
copied from the old projection, so that they get rendered upon
flushing, instead of remaining empty.
Additionally, fix preview invalidation -- in particular, don't
directly invalidate the projectable's preview, even if preview
invalidation is already queued and chunk rendering was finished by
the boundary change, and instead always queue a preview
invalidation.
(cherry picked from commit bb5e3fd926)
Make sure we don't unnecessarily update the group layer's drawable
while flusing the group's projection during resizing, since we want
to either update the entire drawable, or avoid any updates, when
replacing the drawable's buffer. Note that explicitly supressing
updates in this case should theoretically not be necessary, but the
fact that the call to gimp_projectable_bounds_changed() can result
in reconstructing the projection (see the FIXME comment in that
function) makes it necessary in some cases nonetheless.
(cherry picked from commit bd726c96bf)
When translating group layers, there's no need to re-render the
group's projection -- we can simply update the group's offset (and
offset node) directly, and redirect any layer-stack "update"
signals to the group's drawable. This significantly improves
performance when moving groups.
(cherry picked from commit 3ff820a00a)
In GimpGroupLayer, use gimp_projectable_bounds_changed() when
updating the group layer's size, instead of reconstructing the
projection, unless reallocation of the projection has been
requested. This is more efficient, since it simply copies the
content of the projection's old buffer to the new buffer, rather
than re-rendering the graph.
(cherry picked from commit 1bb3e962f6)
In gimp_group_layer_flush(), stop any idle rendering, initiated
when a new buffer is allocated, before flushing the group's
pickable. Otherwise, the idle rendering is finished synchronously,
which unnecessarily introduces a noticeable lag.
(cherry picked from commit a4957c7c76)
... which specifies whether or not to update the drawable in
response to the buffer change.
Pass TRUE for "update" at all existing call sites, to keep the
current behavior.
(cherry picked from commit 26a8d141f6)
In GimpProjection, respond to the projectable's "bounds-changed"
signal, by reallocating the buffer, and copying the corresponding
region of the old buffer (using
gimp_tile_handler_validate_buffer_copy(), added a few commits back,
so that the relevant portion of the validate handler's dirty region
is also copied). Additionally, shift and clip all outstanding
update regions as necessary (actually, we avoid copying the buffer
when a shift is necessary, and simply reconstruct the projection;
see FIXME comment in the code.)
(cherry picked from commit fbeae36118)
... and a corresponding gimp_projectable_bounds_changed() function.
This signal can be emitted by implementers of GimpProjectable,
instead of the GimpProjectable::structure-changed signal, when the
projectable's bounds change, but its content does not -- i.e., the
old content simply gets cropped to the new bounds.
(cherry picked from commit 460c3d1349)
Add gimp_tile_handler_validate_buffer_copy(), which can be used
instead of gegl_buffer_copy(), to copy a (subregion of a) source
buffer to a destination buffer with a GimpTileHandlerValidate,
uninvalidating, and avoiding unnecessarily rendering, the
affected region. Additionally, if the source buffer also uses a
GimpTileHandlerValidate, the relevant parts of the source buffer's
dirty region are copied to the destination's dirty region as well.
(cherry picked from commit eeed4778a2)
... which should be used to properly remove a
GimpTileHandlerValidate from a buffer, instead of using
gegl_buffer_remove_handler() directly.
Use gimp_tile_handler_validate_unassign(), instead of
gegl_buffer_remove_handler(), in gimp_projection_free_buffer().
(cherry picked from commit 12530e21b2)
In GimpTileHandlerValidate, when allocating a new tile upon a
TILE_GET command, but not rendering the whole tile, clear the tile
data before rendering, so that the unrendered regions of the tile
contain zeros, rather than junk.
(cherry picked from commit e1e4ba9c8b)
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)
Adding spaces between function names and parenthese.
I would normally have just amended the contributed patches and pushed,
but gitlab is making our review process over-complicated with many
roundtrips with contributors, and review quality drops. Stating it here
for the records!
See commit 70945b8960 (where this cleaning
should have directly been done).
(cherry picked from commit 5c56f8cb3a)
anchor of LTR is top-left corner.
anchor of TTB-RTL is top-right cornner.
anchor of TTB-LTR is top-left cornner.
(cherry picked from commit 70945b8960)
Back when I implemented this as a recommendation, gettext 0.19 was not
even out yet. Nowadays it is in Debian Testing (Debian Stable even!), so
it makes no sense to continue just "recommend" it, especially as it was
breaking script-fu localization.
See old commit feb1bf2797.
(cherry picked from commit 8e6afe10a6)
This fish is used for text layers, so if we let it to be
lazy-initialized, the first time one writes text in a text layer, it
generates a few seconds delay, which is really not great.
(cherry picked from commit a03e52ea08)
Fixes:
> WARNING: Failed to validate desktop file […] for locale string list
> key "Keywords[mr]" in group "Desktop Entry" does not have a semicolon
> (';') as trailing character
I just added a semicolon.
(cherry picked from commit 79a5c304d2)
In gimp_layer_convert(), avoid converting the drawable type when
the source and destination color profiles are equal, if otherwise
unnecessary. Otherwise, text layers get unnecessarily re-rendered
during conversion, and, by extension, during image duplication
(which happens when exporting to any format that requires merging
down the image). This may cause the text layer to appear
differently in the duplicated image, or even use a different font
if the original font doesn't exist.
(cherry picked from commit a826a19359)
When duplicating an image, copy the source image's is-color-managed
status to the duplicated image, instead of having the duplicated
image always be color managed. In particular, do this before
duplicating the layers, so that we don't convert the duplicated
layers from sRGB to the image's profile when duplicating an image
with a non-sRGB profile but with color management turned off.
(cherry picked from commit f38443f3b0)
They are not perfect (not a designer here!) but a bit less packed than
the previous one. So hopefully more understandable.
(cherry picked from commit e326faa77c)
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)
Just like it was until now, the default filtering should not be all
files, but only relevant files (i.e. XCF when saving, exportable images
when exporting and loadable images/XCF when opening).
Now all files will only be available through the "Show All Files"
checkbox.
This is simpler than previous implementations where the list was
proposing "All Files", "All Images" and "All XCF/export images". That is
just too much.
With this default, I get the "All Files" checkbox out of the expander so
that it is visible immediately even when the format list is unexpanded
(you don't want people to get pissed when not finding how to display all
their files).
(cherry picked from commit 6b4b3bad13)
... format selection.
Second step: add a "Show All Files" checkbox so that one can still
prevent view filtering even when forcing a load format.
This is useful when loading files with unusual extensions, for instance.
(cherry picked from commit 6369445874)
... format selection.
As discussed, the first step is to get rid of the filter list. Our extra
widget now has both roles of filtering the file list and forcing a
loading procedure.
(cherry picked from commit 9ae7827f9b)
In subdirs containing a generated foomarshal.h header, add the
generated sources to BUILT_SOURCES, so that they're generated
before the rest of the source files are built. Otherwise, since
there is no rule specifying the dependency between the rest of the
source files and foomarshal.h, and since foomarshal.h is not
checked into git (and hence doesn't exist when doing a clean
build), compilation of the said source files may fail if they're
built before foomarshal.h is generated.
(cherry picked from commit a5102a7dba)
In GimpFilterTool, bind the controller's lifetime to the lifetime
of the config object, rather than to the lifetime of the
corresponding tool widget; make the controller's widget pointer a
weak pointer to the widget, and bail out of the controller "set()"
functions when the widget pointer is NULL.
This fixes an issue arising when the properties of a config object
that outlives the widget change after the widget had died,
triggering a call to the controller's set() function, resulting in
a segafult when trying to access the widget.
(cherry picked from commit 78abe756f1)
When constructing a prop-GUI widget for an angle property with a
dial, use the the property's "direction" UI-meta, if exists, to set
the direction of the dial. Together with GEGL commit
7b0578073a0f20334b5a8a8fe57b649d9f302454, this fixes wrong dial
direction in certain ops that use clockwise angles.
(cherry picked from commit 6976e87dac)
... and rename "clockwise" to "clockwise-delta"
Add a boolean "clockwise-angles" property to GimpDial, which, when
set, causes the dial legs' angles to be measured clockwise, rather
than counter-clockwise. The property is FALSE by default.
Rename the "clockwise" property, which controls the direction of
the measured delta between the two angles, to "clockwise-delta", to
avoid confusion, and adapt the rest of the code.
(cherry picked from commit 0c477564ad)
... from layer context menu
In gimp_text_tool_set_layer(), do nothing if the input layer is the
currently-edited layer, otherwise we get a CRITICAL.
(cherry picked from commit 6b1d77b11c)
Second parameter of gimp_scanner_parse_token() and
gimp_scanner_parse_identifier() is not a return value. It is a value to
compare with.
(cherry picked from commit bc427479e0)
This is a "for info" comment so that packagers don't forget them when we
sometimes depend on some specific GEGL dependencies.
(cherry picked from commit 530a2bd9a5)
In the dynamics editor, use the neutral curve color, which depends
on the current theme, for the "fade" curve, instead of hard-coding
it to dark gray, which is hardly visible with dark themes.
(cherry picked from commit b2a9bb4688)
... depending on UI language
Use gimp_register_file_handler_priority(), added in the previous
commit, to increase the priority of the merged PSD loader, so that
the non-merged loader is always preferred over it (unless
explicitly chosen), regardless of the UI language.
(cherry picked from commit 0320126254)
Add a gimp-register-file-handler-priority procedure, which can be
used to set the priority of a file-handler procedure. When more
than one file-handler procedure matches a file, the procedure with
the lowest priority is used; if more than one procedure has the
lowest priority, it is unspecified which one of them is used. The
default priority of file-handler procedures is 0.
Add the necessary plumbing (plus some fixes) to the plug-in manager
to handle file-handler priorities. In particular, use two
different lists for each type of file-handler procedures: one meant
for searching, and is sorted according to priority, and one meant
for display, and is sorted alphabetically.
(cherry picked from commit b4ac956859)
In GimpToolCompass (and, as a consequence, in the measure tool),
update the measured angle when the shell is scaled, rotated, or
flipped, so that we always satisfy the compass's constrains, and
render correctly.
(cherry picked from commit a810c6b60b)
When using a GimpToolCompass in 3-point mode, add a small gap after
the angle arc to the line corresponding to the "second" non-origin
point, so that it's visually distinguishable from the line
corresponding to the "first" point. This has significance for the
measure tool, since it determines the direction of the rotation
when straightening the image (the first point is rotated toward the
second point.)
(cherry picked from commit 0f03f9e9f5)
... does not restore the measure points
Halt the measure tool after straightening, thus removing the
expectation that undoing the operation should restore the original
points.
Halting the tool, rather than making undo work "as expected",
sidesteps several issues:
- Implementing undo correctly is tricky, since image-undo and
tool-undo are handled separately.
- In fact, the measure tool doesn't provide tool-undo, so that
image edits can be undone while the tool is active without
affecting the tool, and it's not clear that we want to change
this behavior. However, this makes undoing a straighten
operation a special case, and it's not entirely clear what the
behavior should be when undoing other kinds of transformations,
or when the measure points had changed since the straighten
operation.
- Perhaps most importantly, measure tool points are restricted to
the pixel grid, which means that when measuring an angle
against an orientation that's not fully horizontal or vertical
in image space (either using a 3-point angle, or when the
canvas is rotated), the resulting transformed point after
straightening doesn't generally land on the pixel grid, causing
it to be rounded, which can result in a non-zero angle after
the rotation. This is especially ugly, since clicking
"straighten" again at this point would cause another non-
trivial rotation.
(cherry picked from commit 2e08c9164a)
Rename XCF property PROP_SAMPLE_POINT to PROP_OLD_SAMPLE_POINT and add
new PROP_SAMPLE_POINT.
The new property saves the sample point's pick mode plus some padding
for whatever else we might want to add. Always save the old property
too so nothing changes for older GIMP versions, and avoid loading the
old property if the new one was loaded before.
(cherry picked from commit 47a008be97)
Bind the "orientation" property of the measure-tool options to the
tool's compass widget's "orientation" property, instead of manually
synchronizing their values.
(cherry picked from commit 7a91aabf37)
Add an "orientation" option to the measure tool, corresponding to
the "orientation" property of GimpToolCompass (i.e., it controls
the orientation against which the angle is measured, when not in 3-
point mode.) The orientation is "auto" by default, so that the
angle is always <= 45 deg. Note that the "orientation" option
affects the tool's "straighten" function, so that the layer is
rotated toward the current orientation.
Use the "pixel-angle" and "unit-angle" properies of
GimpToolCompass to read the measured angle, instead of duplicating
the angle-measurement logic, in particular, so that we benefit from
the improvements/fixes of the previous commit.
(cherry picked from commit cb3b7a1ba5)
Add an "orientation" property to GimpToolCompass, which can be one
of "auto", "horizontal", or "vertical", and which controls the
orientation of the line against which the angle is measured, when
not in 3-point mode (previously, the line would always be
horizontal.) When "orientation" is "auto", the orientation is
automatically set to either horizontal or vertical, such that the
measured angle is <= 45 deg.
Keep the line horizontal, or vertical, in display-space, rather
than in image-space, so that the compass works correctly even when
the canvas is rotated and/or flipped.
Fix the compass's behavior when the image's horizontal and vertical
resolutions are different, both with and without dot-for-dot.
Add "pixel-angle" and "unit-angle" read-only properties, which
return the measured angle either with or without taking the image's
resolution into account, respectively. These properties will be
used by the measure tool in the next commit, instead of having it
implement its own angle calculation.
(cherry picked from commit d2f33cf1be)
Fix gimp_constrain_line() and friends to properly constrain line
angles when the image's horizontal and vertical resolutions are
different, and dot-for-dot is disabled.
(cherry picked from commit 4fefab1798)
Remember the sample point's GimpColorPickMode in the sample point
itself, so it is remembered across switching between images.
Not persistent in the XCF yet tho...
(cherry picked from commit a0129504c8)
This is just some preparation for fixing issue #1805, but actually
"target" is a much better name so I went the full way and also changed
GUI labels and the color picker tool options config property
accordingly.
If anyone notices at all, how horrible is it to lose your saved pick
target...
(cherry picked from commit b140b283dc)
In gimp-parallel, always flush the async-operations queue (by
executing all remaining operations on the caller thread) when
setting the async-pool thread count to 0 (as happens when setting
GEGL_THREADS=1, per the previous commit,) and not only when
shutting GIMP down. Otherwise, pending asynchronous operations
can "get lost" when setting GEGL_THREADS to 1.
Additionally, in gimp_gegl_init(), initialize gimp-parallel before
before connecting to GimpGeglConfig's "notify::num-processors"
signal, so that the number of async threads is set *before*
GEGL_THREADS, in order to avoid setting GEGL_THREADS to 1 while
async operations are still executing.
Also, allow setting the number of gimp-parallel-distribute threads
while a gimp-parallel-distribute function is running (which can
happen if gimp-parallel-distribute is used in an async operation,
as is the case for histogram calculation), by waiting for the
parallel-distribute function to finish before setting the number of
threads.
(cherry picked from commit 432a884715)
When GEGL_THREADS=1, concurrent access to the same buffer is not
safe, which can result in errors if asynchronous operations are
allowed to run in parallel to the main thread (see
https://gitlab.gnome.org/GNOME/gimp/issues/1721#note_265898.)
Disable parallel execution of asynchronous operations when
GEGL_THREADS=1 for now, to fix this. Ultimately, GEGL should be
able to remain thread-safe even when GEGL_THREADS=1. Note that we
want to execute asynchronous operations on a separate thread even
when GEGL_THREADS=1, since the goal here is mainly to avoid
blocking the main thread during their execution, rather than
speeding their execution up (in particular, it's benecifical to run
asynchronous operations in parallel even on a single-core machine,
while parallelizing GEGL operations generally isn't.)
(cherry picked from commit 408540659f)
In GimpContainerTreeView, don't process updates in response to a
selection-change if the selection is empty (for the reason this is
necessary in the first place (though not in this particular case),
see commit f9a71fb6de5a2e65e0d88c6b7aaa39f589d6cdc4.) When
clearing the container-view's context, we deselect all items after
setting the context to NULL, in which case
gimp_view_renderer_draw() warns, breaking one of our tests.
...not found if language changed since last session
For various reasons, (gimp-context-get-brush, pattern, gradient, ...)
can return "Standard" which is the untranslatable name of the internal
fallback object.
Therefore, we must accept "Standard" as fallback in all PDB functions
that take brush, pattern, gradient etc. names.
(cherry picked from commit 397ae027ba)
...and successfully fails
Commit d2ad2928 removed "gradient-repeat" from GimpPaintOptions, not
considering that it is also used in the PDB.
Move "gradient-repeat" from GimpGradientOptions back to
GimpPaintOptions, and add a comment that it is only used by the
gradient tool, not for painting.
(cherry picked from commit c3d37140eb)
- "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 GimpContainerTreeView, work around a GTK bug which can cause the
window containing the tree view to stop processing updates,
resulting in an apprarent freeze, until update-processing is
explicitly requested. This can be triggered by adding layers to a
layer group until the layers-dialog tree view is almost full, but
still doesn't have a scrollbar, and then duplicating the group.
This doesn't seem to affect GTK3, so not applying to master.
Don't destroy the color frames when the number of points changes.
Instead, simply hide them so they keep their color model, but add an
upper limit of an arbitrary number of 16 frames to keep around.
(cherry picked from commit 370680f9bc)
Use gimp_babl_is_valid(), added in the previous commit, to validate
image-type/precision combinations in various functions.
(cherry picked from commit 49ca383fa4)
... (valgrind reports Invalid read)
Add gimp_babl_is_valid(), which takes a GimpImageBaseType and a
GimpPrecision, and determines whether the image-type/precision
combination is valid. Use this function to validate that loaded
XCFs use a valid type/precision combination, before trying to
create the image. Otherwise, we get a CRITICAL, and eventually a
segfault, when the combination is invalid.
Use the same function to validate the arguments of
gimp_image_new().
(cherry picked from commit a0a62656d2)
Introduce GIMP_PATTERN_MAX_SIZE (10000) and GIMP_PATTERN_MAX_NAME (256)
and validate pattern dimensions and pattern name length against them.
Add GIMP_BRUSH_MAX_NAME and validate that too.
Also make sure that the names are properly terminated, and some
cleanup.
(cherry picked from commit 9b56ca8c1d)
In app_exit_after_callback(), call gimp_gegl_exit() before
gegl_exit() when performing a quick shut-down in stable versions,
so that gimp-parallel, and, in particular, the async thread pool,
is properly shut down. Code running in the async thread pool may
use GEGL (in particular, now the drawable previews are rendered
asynchronously), and calling gegl_exit() while it's still running
is unsafe.
(cherry picked from commit ed033b1cb5)
In GimpAction, instead of connecting the action-history log
function to the action's "activate" signal as a user-provided
handler, call it directly from the default handler.
In subclasses of GimpAction, chain to the parent's activate()
function before emitting the "selected" signal, so that we always
log the action in the history before responding to it.
This allows us to avoid the hack in commit
6544ce4301.
(cherry picked from commit 114d49510f)
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)
In xcf_write_int8(), avoid calling g_output_stream_write_all() with
data == NULL and count == 0, in which case it raises a CRITICAL and
doesn't set bytes_written, which we proceed to use uninitialized.
This can happen, e.g., when writing an empty parasite.
(cherry picked from commit 8e798e9cf2)
In gimp_color_profile_new_from_icc_profile() and
gimp_image_validate_icc_profile(), don't raise a critical when
encountering an empty profile, but rather reject it gracefully with
an error.
(cherry picked from commit 10f33b080b)
... (Invalid read reported by valgrind)
In gimp_image_parasite_validate(), don't segfault when validating
a "gimp-comment" parasite of size 0 (i.e., whose data is a 0-byte
array, not an empty string), and just consider it invalid.
(cherry picked from commit f384a0713d)
... (Invalid read reported by valgrind)
In xcf_read_int8(), avoid calling g_input_stream_read_all() with
data == NULL and count == 0, in which case it raises a CRITICAL and
doesn't set bytes_read, which we proceed to use uninitialized.
This can happen, e.g., when reading an empty parasite.
(cherry picked from commit 6ebadea7c1)
In gimp_action_history_activate_callback(), bail if history.gimp is
NULL, instead of dereferencing it. This can happen if GIMP is shut
down during the execution of a temporary procedure, such as a
script-fu script. See the code comment for details.
(cherry picked from commit 6544ce4301)
Remove the now-useless "independent" parmaeter. It is supplanted
by the new gimp_parallel_run_async_independent() function.
(cherry picked from commit 00d034a1d4)
Add an "async" field to the dashboard's "misc" group, showing the
number of async operations currently in the "running" state (i.e.,
all those GimpAsync objects for which gimp_async_finish[_full]() or
gimp_async_abort() haven't been called yet).
(cherry picked from commit aa382650a1)
Preview generation for layer groups is more expensive than for
other types of drawables, mostly since we can't currently generate
layer-group previews asynchronously. Add a preferences option for
enabling layer-group previews separately from the rest of the
layer/channel previews; both of these options are enabled by
default. This can be desirable regardless of performance
considerations, since it makes layer groups easily distinguishable
from ordinary layers.
(cherry picked from commit 30cc85fd63)
In the preferences dialog, make the "dither images when promoting
to floating point" option insensitive when the "promote impoprted
images to floating point precision" option is unchecked.
(cherry picked from commit 5b9bc0aadd)
In GimpViewRendererDrawable, use
gimp_drawable_get_sub_preview_async(), added in the previous
commit, to render drawable previews asynchronously. While the
preview is being rendered, either keep showing the previous
preview, or render a placeholder icon.
This commit also fixes an issue where, under certain conditions, a
drawable preview would be rendered, even when layer/channel
previews are disabled in the preferences.
(cherry picked from commit 8a81bfd2f1)
... which is an asynchronous version of
gimp_drawable_get_sub_preview().
We currently support async preview generation for drawables whose
buffer isn't backed by a GimpTileHandlerValidate tile handler
(i.e., anything other than group layers), since preview generation
fir such drawables may involve processing the corresponding graph,
which isn't thread-safe.
When the GIMP_NO_ASYNC_DRAWABLE_PREVIEWS environment variable is
defined, all drawable previews are synchronously generated.
(cherry picked from commit d79e3fbd6f)
Remove the "independent" parameter of gimp_parallel_run_async(),
and have the function always execute the passed callback in the
shared async thread-pool.
Add a new gimp_parallel_run_async_full() function, taking, in
addition to a callback and a data pointer:
- A priority value, controlling the priority of the callback in
the async thread-pool queue. 0 is the default priority (used
by gimp_parallel_run_async()), negative values have higher
priority, and positive values have lower priority.
- A destructor function for the data pointer. This function is
called to free the user data in case the async operation is
canceled before execution of the callback function begins, and
the operation is dropped from the queue and aborted without
executing the callback. Note that if the callback *is*
executed, the destructor is *not* used -- it's the callback's
responsibility to free/recycle the user data.
Add a separate gimp_parallel_run_async_independent() function,
taking the same parameters, and executing the passed callback in
an independent thread, rather than the thread pool. This function
doesn't take a priority value or a destructor (and there's no
corresponding "_full()" variant that does), since they're pointless
for independent threads.
Adapt the rest of the code to the changes.
(cherry picked from commit b74e600c12)
and remove all other tool options parent setting/unsetting and
property copying code. Also select a tool at the end of
tool_manager_init() so it is in sync with what the tool options
manager does.
(cherry picked from commit 37f69457b7)
tool_options_manager_tool_changed(): also copy the non-global paint
options of the new tool to the global paint options, so they get used
when "global_foo" is enabled.
(cherry picked from commit 1b858eb4ad)
tool_options_manager_paint_options_notify(): sync properties between
tool paint options and global paint options if the property is global
*or* the active tool is involved.
tool_options_manager_global_notify(): don't mess with the active
tool's connection to the user context or its properties at all, it is
always fully connected to the user context anyway.
(cherry picked from commit 54257da7c4)
The way we currently manage tool options, and particularly copy things
around for "global_brush", "global_pattern" etc. sucks, is spread
across files, happens only on tool change, is thus buggy and leads to
all sorts of small inconsistencies.
This new manager will replace all of that stuff, and it does it in one
place, and will keep the user context, the global paint options, and
all tool options connected permanently, and only connect/disconnect
things when settings change, so everything is always in a consistent
state.
Pushed for review only, nothing is used yet.
(cherry picked from commit ef952f2926)
In GimpMeter, use cairo_path_extents() for getting the history
graph's extents, rather than cairo_clip_extents(), since the latter
may also include clipping applied by GTK.
(cherry picked from commit b8e08cddbc)
According to some bug reports, it seems that under some (unknown)
conditions we might save an empty custom gradient file on exit (for
equally unknown reasons). The only difference in the way we save
internal data files, such as the custom gradient, compared to
gimp_data_save(), is the fact that we currently don't explicitly
close the output stream, but rather only unref it.
The output stream should be implicitly closed (and hence flushed)
upon destruction, but maybe the unreffing is not enough to
guarantee that it's actually destroyed (maybe it spawns an extra
reference for some reason, who knows.) Anyway, let's just
explicitly close it, which also gives us a chance to catch and
report any errors occursing during flushing/closing (which,
altenatively, might be the culprit).
Additionally, a few more error-reporting improvements, to match
gimp_data_save().
(cherry picked from commit a72f7f1ace)
In gimp_data_factory_finalize(), wait on the factory's async set
after canceling it, and before continuing destruction. It's not
generally safe to just abandon an async op without waiting on it
-- this is a font-specific hack, due to the fact we can't actually
cancel font loading, and GimpFontFactory is prepared to handle
this.
Instead, in gimp_font_factory_finalize(), cancel and clear the
async set, so that GimpDataFactory doesn't actually wait for
loading to finish.
In gimp_font_factory_load_async_callback(), don't try to acess the
factory when the operation is canceled, since cancelation means the
factory is already dead. On the other hand, when the opeation
isn't canceled, make sure to thaw the container even when font
loading failed, so that we always match the freeze at the begining
of the operation.
(cherry picked from commit b5890e05b8)
GIMP_BRUSH_MAX_SIZE was already defined (as 10.000 pixels per dimension,
which is big for a brush) in gimpbrush.h. Let's just use this to
validate the size returned by the header.
(cherry picked from commit b3de0bb7a5)
The "move-current" flag does not apply to selection mode and our current
code was simply setting the radio buttons insensitive while showing the
same labels on both buttons. This was not wrong per-se, yet very
confusing.
Instead let's just hide the radio buttons in selection mode, and update
the option title to "Move selection" (old label of both buttons) to keep
this mode as understandable as possible.
(cherry picked from commit 7cbbb8cba8)
When defining a dashboard group, allow specifying multiple
variables as input to the group meter's LED. The LED is active
when any of the specified variables evaluates to TRUE, and its
color is the combination of the active variable colors.
Remove the swap-busy variable, and use swap-reading and
swap-writing as inputs to the swap group's LED instead, so that the
LED's color indicates whether the swap is currently being read-
from, written-to, or both.
(cherry picked from commit 716510cb83)
Put the center_image_on_size_allocate() code into the canvas'
size-allocate callbacck.
As a side effect we now have a flag in GimpDisplayShell which
indicates that there will be a size allocate before the next frame, so
simply skip drawing the canvas completely. This fixes new images
jumping around when they are first shown.
(cherry picked from commit c0480f502d)
(this fix is actually a side effect from fixing something else in
master)
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.
As discussed on IRC with Mitch and Samm.
Older versions may work, and Samm says he will build for 10.9 actually,
but we officially only supports for 10.10.
When ENABLE_RELOCATABLE_RESOURCES is set, override libwmf fontdir. This
is actually an alternate version of MR !9 by Alex Samorukov assuming a
bundled GIMP on a single prefix rather than depending on an environment
variable.
This especially makes the relocatable feature more discoverable (rather
than some random environment variable for which you'd need to read the
code to discover it then make some wrapper script for GIMP).
(cherry picked from commit 4ff856f68d)
... --enable-relocatable-bundle option.
This will allow to use this option for more than MyPaint brushes. For
macOS and Windows, we default to "yes" and "no" for other OS, though it
is always possible to set an explicit value.
(cherry picked from commit 8da2646372)
And uncommenting the <release> tag for translators to be able to work on
it. Also using short list items without finale points to agree with
`appstream-util` rules.
(cherry picked from commit 4fa5f61dae)
As asked by Samm and solid_black on IRC.
Apparently tested and the change is fine, while getting rid of
deprecated API. I cannot test myself.
(cherry picked from commit 1b9729d46d)
We should not have essential signal connections (such as setting tool
options from brush properties) implemented in the tool options GUI
files, because they are not active until the options GUI is created.
Also, that magic is simply too hidden in the options GUI files.
Move the signal connections and the brush property copying code to
gimppaintoptions.c where is can also be done cleaner.
However, this must only be done for the main tool options instance
that is used for the GUI. Therefore, add a "gui_mode" boolean to
GimpToolOptions and set it to TRUE for all main tool options.
(this is ugly, but much less ugly and much less hidden than all the
places where code lives (like tool_manager.c) that can now be moved
into GimpToolOptions and its subclasses, and implemented cleanly
there).
(cherry picked from commit cb0e6c65d0)
GTK always returns 72 dpi due to API used. This patch using Cocoa
directly instead. Tested on Retina and non-hidpi displays.
GTK+2 version of commit 5b6126146a.
Cf. MR !14.
... 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)
... metadata by default".
Also for other metadata, and doing it both for the tooltip and the label
of the option.
(cherry picked from commit 50bcc8db3c)
Let the split and replicate segments dialogs keep their own data and
don't use GimpGradientEditor struct members. Remove redundant members
and indent the struct.
(cherry picked from commit b8e75a0201)
This reverts commit d997b2b897.
This is not needed anymore since gimp_widget_load_icon() always returns
a non-NULL GdkPixbuf now. Cf. commit 32931c4606.
We were already doing so when an icon was simply absent from the icon
theme. But we may still end up in cases where the icon is seemingly
present, yet it fails to load (for instance the image file is
corrupted). When this happens, let's also try to load the wilber-eek
fallback.
Note that it doesn't completely stops gimp_widget_load_icon() from
possibly returning NULL (in the case where "gimp-wilber-eek" is also
missing/corrupted for instance), so calling code must still account for
possible NULL return value.
If "gimp-swap-colors" or "gimp-default-colors" are present in the theme,
yet broken somehow, GIMP would crash because it was not checking if the
icons had been successfully loaded.
Just make the relevant checks and output on standard error that the swap
and/or default color areas are invisible.
Set the tooltip in GimpColorHexEntry itself and remove all other
tooltip setting. This just moves the translatable string sround in
libgimpwidgets/, and even removes it from app/.
(cherry picked from commit 2b8b780b6a)
This will allow a designer to simply "tag" an object so that its color
does not get overrided by GTK+ without needing to edit the file as text.
(cherry picked from commit 8a36b786bc)
It should now be possible to fully export our symbolic icons from a
single central file.
My long-standing bug of librsvg#250 is still opened and unfixed, but it
turns out most issues I encountered are anyway also problems when
recoloring symbolic icons in GTK+ (like using strokes instead of
fills!). So let's just bypass all problems at once by accounting for
these issues in the design.
(cherry picked from commit 4c68d5dfc9)
I tried to fix all the icons I could see which had issues regarding all
recoloring matters (using fill not stroke, change circle/ellipses to
paths, etc.) when looking at a blank canvas.
I'm sure I still miss a lot but that will do for now.
(cherry picked from commit 8811b0d916)
Sometimes even within symbolic icons, parts of the design must keep
fixed colors, when they are semantic. For instance this is the case for
the color-picker-(black|gray|white) icons or the gimp-default-colors.
The trick used by GTK+ to recolor is by supplying an additional CSS
style to icons which overrides inline CSS thanks to "! important"
keyword. Our own trick to circumvent this trick is to set "!important"
in inline CSS when one wishes not to have it overrided by the general
colors.
Right now I am doing the edit by hand with vim because Inkscape doesn't
seem to validate this keyword if I add it manually in its XML editor. So
what I did is add the "color-important" label on such object, and I will
later modify my SVG export tool to add !important on such object "fill"
values at export time.
(cherry picked from commit 5d5bbeb88b)
The current recolorization code only recolors paths and rectangles. In
particular it leaves circles and ellipses as-is.
I opened the merge request gtk!214 for this issue. But in the meantime,
it is quite easy to change circles and ellipses into path with "object
to path" in Inkscape.
A second problem is that it only recolors fills, not strokes, as
previously stated. So I need to remove strokes from icons, or transform
them to paths.
(cherry picked from commit fd46018203)
It seems not wide enough to differentiate easily the broken and
non-broken chains. So let's make this gap bigger.
(cherry picked from commit a5afb04501)
This time, 2 icons still had problems because of visible rectangles.
Fixing "gimp-prefs-folders" and "gimp-prefs-folders-mypaint-brushes".
(cherry picked from commit 2bb8afd119)
For anyone wishing to help me fix icons, here is the trick: apparently
GTK+ would fill the paths with CSS colors, not stroke them. So when we
have icon drawing based on path-stroking, they don't end up as expected.
In Inkscape, just run "Stroke to Path" to transform a stroke design in a
fill design.
I am fixing "gimp-tool-cage", "document-revert", "gimp-image-reload",
"gimp-reset" and "view-refresh". More to follow as we discover them, I
guess.
(cherry picked from commit 4b6869dd67)
Return an optional tooltip from gimp_procedure_get_sensitive(), in
GimpPlugInProcedure, build that tooltip from the image types the
procedure works on.
(cherry picked from commit 63817485c0)
... to satisfy the inter-variable dependencies, so that the READING/
WRITING variables are based on the READ/WRITTEN values of the
current sample, and not the previous one.
(cherry picked from commit 51793b114a)
... and gimppaintcore-loops
When a rectangle argument is NULL, use the extents of the
corresponding buffer, instead of raising a CRITICAL, to match the
old behavior.
(cherry picked from commit 8a881ca61a)
Don't show percentage for the swap read/written fields, and make
sure their history underlays are displayed correctly even if the
swap limit changes.
(cherry picked from commit fda671841c)
Add "read" and "written" fields to the dashboard swap group, which
report the total amount of data read-from/written-to the tile swap,
respetively. These fields are non-active by default. When these
fields are active, show a color underlay in the swap group's meter,
indicating when data was beging read-from/written-to the swap.
Improve the swap busy indicator (used as the meter's LED), so that
it's active whenever data has been read-from/written-to the swap
during the last sampling interval, rather than at the point of
sampling.
(cherry picked from commit 6b9aba3067)
Use gimp_input_data_stream_read_line_always(), instead of
g_input_data_stream_read_line(), in a bunch of places that don't
expect EOF. If we don't do that, the code assumes the GError
parameter is set by the function and returns an error indication,
causing the caller to segfault when it tries to access
error->message. Instead, we now process an empty line when EOF is
reached, which is caught by the normal parsing logic.
Additionally:
- Use gimp_ascii_strto[id]() when loading gradients, generated
brushes, and palettes, to improve error checking for invalid
numeric input.
- Improve gradient-segment endpoint consistency check.
- Allow loading palette files with 0 colors. They can be created
during the session, so we might as well successfully load them.
(cherry picked from commit 993bbd354e)
... which are similar to g_ascii_strtoll() (except that
gimp_ascii_strtoi returns a gint, and not a gint64), and
g_ascii_strtod(), however, they make error checking simpler, by
returning a boolean value, indicating whether the conversion was
successful (taking both conversion and range errors into account),
and return the actual value through a pointer.
(cherry picked from commit 3301c06163)
... which is a drop-in replacement for
g_data_input_stream_read_line(), however, it always returns a non-
NULL value when there's no error. If the end-of-file is reached,
an empty string is returned.
(cherry picked from commit e090b910c0)
same code as in GimpDeviceManager, should be only ever needed in the
presence of debug modules like GtkInspector.
(cherry picked from commit bf66882878)
...while other windows are on the second monitor if window positions
are saved at exit
Add some lines of code to color_area_color_clicked() which position
the already existing color dialog exactly like a newly created dialog
would be positioned by gimp_dialog_factory_add_dialog().
This should be part of GimpDialogFactory but let's wait for another
case before we generalize it.
(cherry picked from commit 1ae2b5d573)
When using the color-picker tool's info window, set the tool's
display when a color is picked, and the gui is updated, so that we
properly halt the tool when the display is closed. Otherwise, we
may segfault.
(cherry picked from commit 335023b127)
The memory group shows memory-usage information: the currently used
memory size, the available physical memory size, and the total
physical memory size. It can also show the tile-cache size, for
comparison against the other memory stats. The memory group is
active but contracted by default.
Note that the upper-bound of the meter is the physical memory size,
so the memory usage may be > 100% when GIMP uses the swap.
This is currently implemented for *nix systems with Linux-like
procfs, and Windows.
(cherry picked from commit 8d0766c1fc)
gimp_layer_create_mask(): make sure we don't do a gamma conversion
when initializing the mask from a channel. This was probably not the
last place to need this fix.
Also get rid of a second switch(add_mask_type), must be some leftover
from long gone logic.
(cherry picked from commit f815a2d922)
PSD files may include a "merged", pre-composited, version of the
image (in Photoshop, this is the case when saving files with
"Maximize Compatibility" enabled; GIMP always saves the merged
image data in exported PSD files.) This commit adds support for
loading the merged image version from PSDs, instead of the full
layer hierarchy. This is useful when loading PSD files that use
features that we don't currently support, and therefore can't
render correctly, such as adjustment layers.
When loading the merged image version, we avoid loading certain
additional data from the file, such as channels, paths, and
guides, while still loading metadata, making this akin to loading
other "flat" image formats.
This option is currently exposed as an additional file type
("Photoshop image (merged)"), which has to be explicitly selected
from the file-type list when opening the image.
(cherry picked from commit 1d9a8a91ab)
...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)
Mostly formatting and thortening variables. Only real change is adding
gimp_clipboard_new() and moving most init() code there.
(cherry picked from commit e0f46d1dc9)
Make the bottom-left entry request only minimal width, it expands
anyway. Also replace the "Columns:" label by a "grid" icon and set a
tooltip on the columns spinbutton.
Addresses Issue #1223 too.
(cherry picked from commit 0aa018dec2)
Replace "Selection Bounding Box" by simply "Selection" and add a tooltip
to the frame that says it's the bounding box.
Addressed Issue #1223.
(cherry picked from commit 33d2595d22)
Our plug-ins have no "optional" parameters per-se. Clarify the
description to make explicit that the last 4 parameters are simply only
taken into account when the shoot type is SHOOT-REGION.
(cherry picked from commit 3a0c03a61c)
Turn the boolean "root" argument into enum ShootType and reorder that
enum to { WINDOW, ROOT, REGION } so that the "0", and "1" values match
the former boolean. Adapt parameter checking accordingly so that
callers without optional arguments (e.g. script-fu) can call all the
plug-ins's features.
(cherry picked from commit d94b954c2a)
... with a color profile other than the gimp built-in.
When initializing the smude tool's accum buffer, use
gimp_pickable_get_pixel_at(), instead of
gimp_pickable_get_color_at(), for picking the initial color to fill
the buffer with, so that we don't erroneously apply the image's
color tranform to it when the image has a profile. Previously,
this would result in wrong colors when painting from the drawable
edges inward, with flow < 100%.
(cherry picked from commit 5a07876c78)
gimp_eek(): simply increase gimp->busy so XCF saving calling
gimp_set_busy() and gimp_unset_busy() won't call the GUI layer and do
whatever windowing system calls to set busy cursors.
(cherry picked from commit eaddef595e)
... with a color profile other than the gimp built-in.
Remove the separate alpha-channel copy in
gimp_image_color_profile_srgb_to_pixel(). We no longer need it,
since GimpColorTransform already takes care of that itself.
We used babl_process() to copy the alpha, which would also
transform the input color from R'G'B' to the output color space.
When the same buffer was used for both input and output, this call
would overwrite the input to the subsequent
gimp_color_transform_process_pixels() call; when the output color
space was different than R'G'B', this meant we'd pass the input to
gimp_color_transform_process_pixels() in the wrong color space,
producing wrong results. This was the case when converting the
foreground color for use with the smudge tool.
(cherry picked from commit e58e2ec5dc)
resize_dialog_new(): create the preview with "popup = TRUE", so we
really get a preview of layer size and not of the layer within the
image context like used for the layers dialog.
(cherry picked from commit 93d28ceccc)
when the GimpDeviceInfo already has a device. This is not a programming
error that should trigger a bug report popup, it's something else about
non-uniqueness of device names, or whatever. Simply g_printerr() a more
useful message that can help to debug this and bail out.
(cherry picked from commit f06d0485e6)
...after program restart
GimpContext was always supposed to keep the names of objects (brush,
pattern, font etc.) around even if these objects don't exist, for
cases like refreshing the data in a GimpDataFactory (which worked
fine), but also for deserializing the names of objects which don't
exist *yet* (delayed loading, no-data or whatever).
This commit fixes the delayed loading case (particularly affects fonts):
gimp_context_deserialize_property(): always keep the name of the
object around when it is not found, not only in the no-data case.
gimp_context_copy_property(): always copy the object *and* its name to
the dest context.
Add GimpConfig::duplicate() and ::copy() implementations which chain
up for duplicating/copying all properties and additionally copy all
object names to the new/dest context.
(cherry picked from commit ed1e2b1524)
It seems it was simply forgotten. PROP_MASK_ALL is used at some very
central places, so this commit might fix a few subtle bugs, or
introduce new ones, everybody look for strange tool preset behavior
please :)
(cherry picked from commit b3690b48d9)
Same as we did for binfmt-style lines, if the executable part (for
instance in `pygimp.interp`) is not an absolute path, let's allow
ourselves to find it in the environment $PATH.
Our configure test checks the presence of a Python2, but then uses
"python" as interpreter, which is a problem nowadays as the default
python is set to be Python 3 on some distributions (and this will be
more and more the case). So GIMP may end up trying to run our plug-ins
through Python 3 (which would fail) even if Python 2 is present.
Now AM_PATH_PYTHON2() m4 macro will set $PYTHON to a more accurate
Python version as priority.
Similarly let's use "python2" in the binfmt string for extension search.
So basically our binfmt set for Python simply never worked since we just
set 'python' and not a full path, but current code was not looking in
the $PATH environment. This was dead code. Now it's fixed.
Current code of gimp_interpreter_db_resolve() was only resolving the
interpreter by the file extension when the file could not be opened for
reading or if it was empty/coult not be read. This basically made this
test completely useless.
Let's fix this. Now it will be run all the time, but simply at the end,
if shebang and magic failed.
In GimpScaleTool, fix scaling around the center-point, and make
sure the width and height are always >= 1 when updating the
transformation in response to a widget change.
(cherry picked from commit 1516bfc14b)
Get rid of GimpTransformGridTool::recalc_matrix() and
gimp_transform_grid_tool_recalc_matrix(), and have
GimpTransformGridTool and its subclasses use
GimpTransformTool::recalc_matrix() and
gimp_transform_tool_recalc_matrix() directly instead.
In order to break the GimpToolWidget::changed/
GimpTransformTool::recalc_matrix() loop, add a
GimpTransformGridTool::update_widget() vfunc, which subclasses
should override to update their tool-widget (instead of doing this
in ::recalc_matrix()), and ::widget_changed(), which is called when
the tool-widget changes (and which subclasses should override
instead of connecting to the tool-widget's "changed" signal
directly.) GimpTransformGridTool calls these functions as
necessary, instead of relying on extra parameters passed to
recalc_matrix().
Adapt all the direct and indirect subclasses of
GimpTransformGridTool to the change.
(cherry picked from commit 6a3fc6c1b9)
As noted by Massimo, we can just make the argument of raw_input() an
optional argument.
Also adding a modal implementation for input() so that it doesn't lock
the Python console waiting from input from the plug-in stdin. As noted
in Python doc, input() is equivalent to `eval(raw_input(prompt))`.
Not all that safe, but in the end, it is the developer's responsibility.
... GIMP_TOOL_VERSION rather than hardcoding versions.
Mostly cherry picked from commit 276d9b60b3
except pkg-config still checks gtk+-2.0 (not 3.0) on gimp-2-10 branch.
In GimpTool, always clear tool->drawable upon halting, even for
tools that don't use it explicitly.
GimpTool sets tool->drawable in its default button_press()
implementation, and we potentially access it in
gimp_display_shell_initialize_tool(), so failing to clear it when
halting the tool may leave it as a dangling pointer, which can
result in a segfault when trying to initialize the tool in the
above function. In particular, this happens with the iscissors
tool.
(cherry picked from commit 58c96f596e)
In GimpCanvasTransformPreview, when the image mask is not empty,
make sure to align it with the drawable using a gegl:translate
node, before combining both at the gegl:opacity node. Otherwise,
the mask is applied at the wrong offset when the drawable's offset
is not (0, 0).
(cherry picked from commit d3a3c35317)
Make gimp_free_select_tool_halt() protected, and call it in
gimp_foreground_select_tool_set_trimap(), so that the free-select
subobject of the foreground-select tool is properly shut down
before switching to trimap mode. In particular, this clears the
free-select tool widget at the right point; failing to do this
leads to CRITICALs later on.
(cherry picked from commit e15733236c)
In GimpToolRectangle, call gimp_tool_rectangle_update_options()
when the "[xy][12]" properties change, so that the "x", "y",
"width", and "height" properties are updated accordingly.
In particular, we set these properties when committing an empty
rectangle select tool, to init the rectangle to the current
selection bounds, and this call is necessary so that the "x", "y",
"width", and "height" tool options are properly updated as well.
(cherry picked from commit 47b7e7be7d)
With the symbolic-awareness of GTK+, vector icons are recolored (using
fg, success, warning and error colors). Unfortunately it was also
recoloring some rectangles with neither fill nor stroke, which were
using only to get appropriate icon size (these icons were therefore
displayed as just a square).
I made a quick pass in our icons to "fix" these. I expect I may have
missed some icons, or at the opposite, I may have broken other icons by
removing rectangles which should not have been removed. If you find any
such icon, please fix.
Also some icons do not look quite right just now. We will have to create
new guidelines on how to make symbolic icons and fix/redesign some, I
guess.
(cherry picked from commit 0c3659c5f1)
The 2 major changes seem to be the much-awaited font loading in
background, and this new "Auto straighten" option on Measurement tool.
Please everyone, feel free to tweak the release description while it is
still commented out. Once we remove the comment tags, it will be
submitted for translation.
In gimp_image_set_colormap(), make sure the image's colormap always
has at least one color -- babl palette formats must have at least
one color.
If the function is called with 0 colors, use black. We still need
to support this case, in particular, since existing XCFs may have
an empty colormap, and since plug-ins can call
gimp-image-set-colormap with 0 colors.
(cherry picked from commit c16c68e63e)
Introduced in commit 032e95fad6, Makefile.am was apparently directly
edited instead of plugin-defs.pl. This also fixes a typo:
s/bust-dialog/busy-dialog/
(cherry picked from commit 4117c98655)
Set the libpng error_fn to NULL *after* png_read_end() not before.
png_read_end() can throw errors and we recover what's partially loaded
from an image in the error handler.
(cherry picked from commit db08271d16)
There is something broken in the obscure "text_column" and
"pixbuf_column" code in GtkIconView, and I don't have the nerve to
debug it.
Enable opening an image on activation (double click).
(cherry picked from commit 625aa514f6)
(picking the icon view change was not neccessary but this plug-in will
get more updates so let's keep the code in sync)
Last commit reintroduced this bug.
Allow transforming invisible layers using transform-grid tools, by
adding a 'drawable' member to GimpTransformTool, and setting/
clearing it when initializing/halting a GimpTransformTool. In
gimp_transform_tool_check_active_item(), skip the visibility check
if the active item equals the GimpTransformTool's 'drawable'
member.
(cherry picked from commit cea6f1dc73)
Split gimp_transform_tool_get_active_item() into two functions:
gimp_transform_tool_get_active_item(), which returns the item
without checking for errors, and
gimp_transform_tool_check_active_item(), which returns the active
item while checking for errors. Adapt the rest of the code to the
change.
Remove the invisible_layer_ok parameter of
gimp_transform_tool_check_active_item(), and always return an error
when the active layer is invisible. This causes the flip and
measure tools to correctly reject invisible layers. Un-hide the
active item in GimpTransformGridTool before transforming, to avoid
rejecting layers that were hidden by the tool.
(cherry picked from commit 360b25b9a8)
... and various other palette formats
Change accidental 'G_IS_INPUT_STREAM (file)' argument validation to
'G_IS_INPUT_STREAM (input)'.
(cherry picked from commit ea6d997e56)
Derive GimpMeasureTool from GimpTransformTool (and
GimpMeasureOptions from GimpTransformOptions), so that we can reuse
GimpTransformTool's logic for the "straighten" function. This
simplifies the code, aligns the measure tool with the rest of the
transform tools in terms of transform-related options (it can now
transform selections and paths, in addition to layers, and the
resampling method and clipping behavior are adjustable,) and fixes
straightening of layer groups.
Rename the function from "auto straighten" to just "straighten".
Don't resize the canvas after straightening. Since we only
transform the active layer, and not the entire image, resizing the
canvas doesn't make much sense.
When in 3-point mode, rotate the second point toward the third
point, rather than toward the x-axis.
(cherry picked from commit b0cf2e435a)
While most of our transform tools use an interactive transform
grid, and have similar behavior, the flip tool is an odd one out.
The new "auto straighten" function of the measure tool introduces
another tool that performs transformations, while not behaving like
the rest of the transform tools.
Factor out the parts of GimpTransformTool that handle user
interaction into GimpTransformGridTool (with corresponding
GimpTransformGridOptions, and GimpTransformGridToolUndo), and only
leave the basic transform functionality and options in
GimpTransformTool (and GimpTransformOptions).
Derive all the transform tools (and transform-tool base classes)
that previously derived from GimpTransformTool, from
GimpTransformGridTool. The one exception is GimpFlipTool, which
still derives from GimpTransformTool directly. The next commit
will derive GimpMeasureTool from GimpTransformTool as well.
Never return an internal image/buffer/svg/curve from any
gimp_clipboard function if we are not the owner of the display's
clipboard. The clipboard is supposed to be a global thing, and we must
only offer to ourselves what would be pasted in any other app.
(cherry picked from commit 7d3a129ddd)
Add GimpPaintTool::paint_[xy] members, and periodically assign the
paint core's current coords to them in
gimp_paint_tool_paint_timeout(), while the main thread and the
paint thread are synchronized, during painting.
In gimp_paint_tool_draw(), fetch the current coords for the brush
outline from the above members during painting, instead of directly
from the paint core, to avoid a race condition with the paint
thread, so that we always use the correct coordinates at the time
the paint buffer was flushed back to the drawable.
(cherry picked from commit 5c17d2a43b)
...won't work with older GIMP?
Make gimp_image_get_xcf_version() return a "reason" string which lists
all reasons why the image can't be saved with compatibility for older
GIMP versions. Display the reason as tooltip on the compat hint label
in the save dialog.
(cherry picked from commit a4061a6b0d)
When creating a layer group, or a text layer, use the image's
default new-layer mode, instead of always using (non-legacy)
NORMAL.
(cherry picked from commit 7c7b6eb537)
Instead just transform the measurement extremities appropriately to
still map to the same points.
To do so, I also added out parameters to gimp_image_resize_to_layers()
so that calling code can get offsets from old origin (as well as new
image dimensions).
(cherry picked from commit d56a8d439e)
In particular, this tool should not make huge rotation where the top
ends up in the bottom and it should not depend on whether we started the
measure tool from the left, right, bottom or top. This is fixed by using
atan() instead of atan2().
Also make a proper tooltip text. Help id is unneeded most likely though.
Finally do some cleaning and alignment.
(cherry picked from commit ba1d937dfb)
gegl:recursive-transform-plus is an extension of
gegl:recursive-transform, allowing multiple transformations to be
applied simultaneously; it will eventually be merged back into
gegl:recursive-transform. See GEGL commit
9829bc22e85526d789c4e80c05949d4c6202a207.
The GUI uses the new TRANSFORM_GRIDS controller, allowing adding,
duplicating, and removing transformations, and controlling them
through on-canvas transform grids.
(cherry picked from commit 99828a697a)
... which is similar to the TRANSFORM_GRID controller, supporting
multiple transformation matrices.
Implement the TRANSFORM_GRIDS controller in GimpFilterTool, using
the new GimpToolWidgetGroup to display multiple transform grids.
(cherry picked from commit 5e953ece85)
GimpToolWidgetGroup is a tool widget acting as a container for
child widgets, multiplexing widget events and demultiplexing tool
events. It can be used by tools to display multiple widgets
simultaneously.
The group keeps track of the current focus widget, and hover
widget. Certain events are only dispatched to/forwarded from these
widgets.
The hover widget is determined by performing a hit test for all the
children, starting from the last child. The first widget returning
GIMP_HIT_DIRECT, if any, is selected as the hover widget;
otherwise, if the current focus widget returns GIMP_HIT_INDIRECT,
it's selected; otherwise, if exactly one widget returns
GIMP_HIT_INDIRECT, it's selected; otherwise, there is no hover
widget.
The focus widget is set when clicking on a widget (or
programatically, using gimp_tool_widget_set_focus()).
Additionally, the group can raise the clicked widget to the top of
the stack (see gimp_tool_widget_group_set_auto_raise().)
(cherry picked from commit 4ef06b9922)
... which emits the "changed" signal, for use in subclasses to
notify the tool about widget changes not resulting from property
changes.
(cherry picked from commit 614cdcc0a8)
... which takes the same arguments as GimpToolWidget::hover(), and
performs a hit-test, returning one of the following values:
- GIMP_HIT_DIRECT: The point corresponds to one of the widget's
elements directly.
- GIMP_HIT_INDIRECT: The point does not correspond to one of the
widget's elements directly, but the widget otherwise responds
to press events at this point.
- GIMP_HIT_NONE: The widget does not respond to press events at
this point.
Unlike hover(), hit() should not have any side effects.
(cherry picked from commit 385203f4d6)
... by having them disable item highlights, and any other proximity
indication, when the cursor leaves the widget.
(cherry picked from commit 5e736c697f)
... which should be called on a widget when the cursor leaves the
widget, i.e., when it stops receiving hover events.
Have the default implementation clear the tool status.
(cherry picked from commit be7eff980e)
The next few commits are going to add support for using multiple
tool widgets simultaneously. As a first step, add a notion of a
focused tool widget, by adding gimp_tool_widget_{set,get}_focus(),
which tools/subclasses can use to control focus, and a
corresponding "focus-changed" signal, which tools/subclasses can
use to respond to focus changes.
(cherry picked from commit eeed9c413b)
specified by GimpDataLoaderEntry structs. Remove the same code from
GimpDataFactory and make it an abstract base class that only serves as
an interface for actual implementations. Also move around some stuff
in GimpDataFactory and remove virtual functions that were a bad idea
in the first place.
(cherry picked from commit 73da7c9a54)
When Control-Button2-Zooming, remember the start point, pass it to
gimp_display_shell_scale_drag() and force gimp_display_shell_scale()
to zoom around that point by passing GIMP_ZOOM_FOCUS_POINTER and
faking the point using gimp_display_shell_push_zoom_focus_pointer_pos().
(cherry picked from commit 792cd581a2)
so pull it to the parent class. Also remove the "no_data" parameter
from the data_init() virtual function and handle it in
gimp_font_factory_data_init() itself.
(cherry picked from commit d1b9f74c6f)
Sans-serif is also an actual font from the list and the standard font
is being used when there is really no font at all.
(cherry picked from commit 6b5fd27943)
Also, make sure we freeze() and thaw() the font container correctly,
so that all places keep their fonts across a refresh.
The only thing to make this actually work seems to be a bug in the
list views, grid views work perfectly.
(cherry picked from commit 1b1739bb06)
which contains all the font loading and refreshing including all async
stuff and is a complete replacement for gimp-fonts.c and GimpFontList.
(cherry picked from commit 0763ea2a69)
Virtualize a lot of functions and move their code into the default
implementation. Also connect to changes of the "path" property and
reload data automatically when the path changes. Add "wait" method
which is by default empty but is to be implemented by fonts.
(cherry picked from commit 01e4104236)
Make sure gimp_async_set_wait() and gimp_async_set_cancel() work
correctly, even if the set changes in nontrivial ways as a result
of waiting-on/canceling individual operations. This is purely
theoretic right now, but why not.
(cherry picked from commit ec5f4d03fa)
Increase the percision of the "position" property of
guides-new-percent.scm to two decimal places. Currently, it only
accepts integers, which limits its accuracy to 100px.
(cherry picked from commit 8e6a5298c1)
Add support for exponentiation (using the ^ operator) to eevl.
This is occasionally useful, e.g., in geometrically-derived
quantities involving square roots.
(cherry picked from commit 8d35299410)
This is mostly core code which we want to keep in sync with master as
long as possible, so I picked this one even though not strictly
neccessary.
(cherry picked from commit 1b7d63cce9)
When font loading is finished, restore the font list in the
corresponding async completion callback, and not in the
"notify::empty" signal handler of the fonts async set
This solves a problem arising when gimp_fonts_wait() is called
*inside* a "notify::empty" signal handler, emitted when reloading
fonts (causing the "empty" property of the fonts async set to
switch from TRUE to FALSE): When the wait is over, "empty" will
switch back from FALSE to TRUE, however, since the "notify" signal
is non-recursive, the corresponding handler will not be called,
gimp_fonts_wait() will return *before* the font list is restored,
and the caller will see an empty font list. This can happen under
certain circumstances when reloading fonts while the text tool is
active.
(cherry picked from commit 0e19f159f5)
... Windows.
Reviewer note (Jehan): I have not built on Windows because I need to
refresh my crossbuild environment, but it looks sane enough, and Gil
previously did good patches. I push as-is, hoping it still builds fine
on Windows. :-)
(cherry picked from commit 2caa400a96)
In the threshold and levels tools, use gimp_wait() to wait for
histogram calculation to complete before applying auto-adjustment,
so that a message is displayed in the meantime. Allow the
operation to be canceled, in which case we simply abort the auto-
adjustment, but let the histogram calculation continue.
Use gimp_fonts_wait(), added in the previous commit, to wait for
fonts to finish loading before operations that depend on font
availability. In particular, this includes font- and text-related
PDB functions, and text-layer rendering.
... which waits for font-loading to complete, using gimp_wait() to
show a message while waiting.
Note that we don't currently allow the wait to be canceled, since
it may have unpredictable effects on plug-ins, but the interface is
such that the wait might not complete, so calling code should be
prepared for that.
Add a GimpGui::wait() virtual function, and a corresponding
gimp_wait() function. The function takes an object implementing
the GimpWaitable interface, and a printf-style message, and waits
for the object to become ready, displaying the message as
indication in the meantime. The default implementation simply
prints the message to STDERR.
Implement the function in gui-vtable, using the busy-dialog plug-
in added in the previous commit, to display the message in a
dialog. Additionally, if the object implements the GimpCancelable
interface, provide a "cancel" button in the dialog, which, when
pressed, causes gimp_cancelable_cancel() to be called on the
object. Note that the function keeps waiting on the object even
after requesting cancelation; GimpTriviallyCancelableWaitable can
be used to stop the wait once cancelation has been requested.
This plug-in is used internally to show an interactive dialog in a
separate process, while the main process is blocking waiting for an
operation to complete. The dialog shows a custom message in a
GimpBusyBox, and potentially a "cancel" button, allowing the
operation to be canceled. Communication with the main process is
performed through a pair of file descriptors, passed to the plug-in
as arguments.
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.
While fonts are loading, show a GimpBusyBox with an appropriate
message above the text tool options, and make the options
themselves insensitive, and in font views, such as in the fonts
dialog (through gimp_container_editor_bind_to_async_set(), added in
the previous commit).
... which takes a GimpAsyncSet and a message, and shows a
GimpBusyBox with that message, instead of the container view, while
the async set is nonempty.
We're going to use this for font-loading indication in font views,
such as in the fonts dialog.
GimpBusyBox is used to show a message indicating an operation is in
progress. It's basically just a spinner and a label, with some
styling.
We're going to use it both in app/ and in a plug-in.
We already avoid rendering text layers while fonts are loading,
showing an appropriate message, but this will soon be replaced with
waiting for the fonts to finish loading.
Instead, don't allow the text tool to start at all while the fonts
are loading (showing an appropriate tool message, and a BAD cursor
modifier), and halt the tool when reloading fonts if it's already
started.
Replace the boolean fonts_loading member of Gimp with
fonts_async_set, which is a GimpAsyncSet object. This allows us
to easily respond to the completion of font loading and reloading,
as will be done in the next commits.
Additionally, move the call to FcConfigSetCurrent(), used to
activate the loaded font configuration, from the async thread to
the main thread, just to be on the safe side, and avoid calling
FcInitReinitialize() in gimp_fonts_reset() if font loading is still
in progress, which is unsafe.
GimpAsyncSet represents a dynamic set of running GimpAsync objects.
The objects are automatically removed from the set once they're
synced.
GimpAsyncSet implements the GimpWaitable and GimpCancelable
interfaces, allowing the entire set to be waited-on or canceled.
Additionally, GimpAsyncSet provides an "empty" property, which
indicates whether the set is empty or not. This allows responding
to the completion of all the GimpAsync objects through the set's
"notify::empty" signal, or drive UI changes through property
bindings.
GimpTriviallyCancelableWaitable is a proxy object for another
GimpWaitable object, implementing both the GimpWaitable interface
and the GimpCancelable interface. While waiting on the proxy
simply waits on the underlying waitable, canceling the proxy
doesn't affect the underlying waitable, even if it implements
the GimpCancelable interface as well, but rather causes subsequent
wait operations on the proxy to successfully complete immediately.
This essentially causes cancelation to abort only the wait, rather
than the underlying operation.
GimpUncancelableWaitable is a simple proxy object for another
GimpWaitable object, implementing only the GimpWaitable interface.
Its main purpose is to mask away the cancelability of an object
implementing both GimpWaitable and GimpCancelable.
In gimp_parallel_run_async(), lower the priority of threads
executing independent async operations. Independent operations
are generally potentially long-standing background tasks, which we
don't want to bog down the rest of the program.
This is currently only implemented on Linux and Windows.
The GIMP version string and the backtrace both look completely wrong
when pasted as-is on gitlab. Somehow all linefeed are gone.
This can be fixed by surrounding these as blocks (triple backticks),
using markdown syntax. Of course now the debug content is not for our
tracker only since packagers are encouraged to replace with their own
tracker URL, but this small markdown syntax is simple enough that it
should not break formatting on other platforms (as far as I know).
(cherry picked from commit d4ff504735)
In gimp_parallel_run_async(), when aborting a GimpAsync operation
in reponse to its "cancel" signal, properly clean up internal data
attached to the object, to avoid use-after-free if the signal is
emitted again.
(cherry picked from commit 3fa4c01bcf)
Add a boolean "independent" parameter to gimp_parallel_run_async().
When FALSE, the passed function is run in the shared async thread
pool; when TRUE, the passed function is run in an independent
thread.
Generally, async operations should run in the async pool, however,
it might be desirable to run long-standing operations, especially
ones that can't be canceled, in independent threads. This avoids
stalling quicker operations, and shutdown.
Adapt the rest of the code for the change. In particular,
initialize the font cache in an independent thread.
(cherry picked from commit ad8add6808)
In gimp_parallel_run_async(), connect to the returned GimpAsync's
"cancel" signal, and abort the operation in response if it's still
enqueued, i.e., if its execution hasn't started yet.
(cherry picked from commit 3958ffbe50)
Have GimpAsync implement the GimpWaitable and GimpCancelable
interfaces, added in the previous two commits, instead of providing
its own public version of the corresponding functions.
Add gimp_async_cancel_and_wait() as a convenience function for both
canceling an async operation, and waiting for it to complete.
Adapt the rest of the code to the change.
(cherry picked from commit e2c56ef407)
The code was basically leaking memory everywhere, and apparently on
purpose (according to a top comment). Even on short-lived process, not
properly managing memory is not a good habit, especially if we plan to
maintain a program for the long run.
So here are some fixes. I'm sure I must have missed some places (code
was a mess), and hopefully I broke nothing. But that's good for now. At
least it is somewhat sane code now.
(cherry picked from commit f3de5cd3fe)
Since commit 58fa382001, gimptool would accept source files with
non-standard extensions when using known C or C++ compilers. This would
include source with no extensions at all.
When this happens, do not try to set a pointer to a non-existing dot
separator to '\0'. That obviously segfaults.
(cherry picked from commit 02fc818bf6)
Unlike the last two commits, we don't port GimpConfig to
G_DEFINE_INTERFACE(), since we need to provide a base initializer
for it. However, this commit aligns it with the rest of our
intefaces, by renaming gimp_config_interface_get_type() to
gimp_config_get_type(), and by performing class initialization for
the interface in a separate function than base initialization.
Keep gimp_config_interface_get_type() around as a deprecated
function, to maintain ABI compatibility. It will be removed in a
separate commit in master, so that this commit can be easily
cherry-picked to gimp-2-10.
(cherry picked from commit 5f8643a6ee)
... instead of calling g_type_register_static() ourselves.
Keep the old foo_interface_get_type() (replaced with
foo_get_type()) around as deprecated functions, to maintain ABI
compatibility. They will be removed in a separate commit in
master, so that this commit can be easily cherry-picked to
gimp-2-10.
(cherry picked from commit 6b40c7f37a)
Fonts should not be blocking startup as this provides a very bad
experience when people have a lot of fonts. This was experienced even
more on Windows where loading time are often excessively long.
We were already running font loading in a thread, yet were still
blocking startup (thread was only so that the loading status GUI could
get updated as a feedback). Now we will only start loading and proceed
directly to next steps.
While fonts are not loaded, the text tool will not be usable, yet all
other activities can be performed.
(cherry picked from commit 2484dec7d5)
Improve the formalism of a GimpAsync object being "sycned"
(previously referred to as the main thread being "synced" with the
async thread), by both providing a gimp_async_is_synced() function,
separate from gimp_async_is_stopped(), and by improving the type
and function descriptions.
Make sure all previously added callbacks have been called after a
call to gimp_async_wait[_until](), even if these functions are
called from within a callback.
(cherry picked from commit a901c3c1f4)
Replace the custom threading code with a call to
gimp_parallel_run_async(). This simplifies the code, while
maintaining the current (blocking) behavior. In the future, we
might build upon this to actually load the fonts in the background.
(cherry picked from commit 3e92e7a449)
... which is similar to gimp_async_wait(), taking an 'end_time'
parameter, controlling how long to wait for the async operation to
complete.
(cherry picked from commit 68c57548fd)
The default stack size for new threads on MacOS is 512 KiB, making
our 512 KiB limit for stack-allocated buffers in
gimp_operation_layer_mode_real_process() too high. Lower it to
256 KiB.
(cherry picked from commit 367399e5c0)
In gimp_drawable_gradient(), pass the undo description ("Gradient")
to gimp_gegl_apply_operation(), so that its displayed as the
progress text while rendering the gradient, even when applying a
shaped gradient, in which case we end the progress after
calculating the distance map, causing the progress text be NULL
during rendering unless explicitly set.
(cherry picked from commit deee2f14f5)
... which is a drop-in replacement for gegl_buffer_copy(),
parallelizing the copy operation when the source and destination
formats are different, requiring a conversion.
(cherry picked from commit fded25b38c)
and remove all clipping hacks for drawing the canvas background, turns
out they never worked and we were relying on the pattern set on the
window, gah! This optimizes away one entire step of drawing of image
size, for each expose...
"magnification-api-win32.h" was not included in the dist!
Note that I know that alphabetical order is wrong. I am planning to
actually change the name of the file (more in line with other filenames)
but I am waiting to finish a review of another patch from Gil before
doing so. So just let it as-is for now! ;-)
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
* along with this program. If not, see <https://www.gnu.org/licenses/>.
*/
#include"config.h"
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
