Also remove '.' at end of some <li>. `appstream-util` does not like full
stops in item lists, when in `validate-strict` mode (we don't test in
this mode, but it is worth improving the warning list a bit).
The jpeg_save_markers API has existed since 27th March 1998! So it's
safe to assume that everybody has it, and there's no need to check for
it.
libjpeg-turbo has had a libjpeg.pc since 2016, and the IJG's software
has it too. Dropping support for old libraries is a small price to pay
for the benefits of a simpler build.
https://gitlab.gnome.org/GNOME/gimp/merge_requests/28
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().
This code was originally written by Thomas G. Lane and Todd Newman,
and proposed for inclusion in the Independent JPEG Group's software.
However, that fell through when Tom left the IJG. It was not written by
Marti Maria - Little cms only had a copy of that code.
This code has recently been merged into libjpeg-turbo, so it seems
reasonable to now consider libjpeg-turbo as the canonical source of
these files. However, since the GIMP carries the original version of
the code proposed for IJG's JPEG, and doesn't contain any of the more
recent and minor tweaks made during its inclusion in libjpeg-turbo,
only the original copyright holders (ie., Thomas G. Lane and Todd
Newman) are mentioned.
The relevant license text was lifted from the Independent JPEG Group's
software, similar to the way it's done in Chromium and other users of
this code.
https://gitlab.gnome.org/GNOME/gimp/issues/2119
... 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.
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.
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.
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.
This tool has been outdated for some time now as we don't generate an
"inverted icons" theme anymore. This is all done through CSS from a
single symbolic icon theme.
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.
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.
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.)
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.
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.
(cherry picked from commit 90ed3c8d3a)
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.
(cherry picked from commit 8f21c9483a)
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.
(cherry picked from commit 87a9feb6d9)
... 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.
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.
That's the problem of having alternative build options! My previous
commits were made when testing the build with PNG icons.
Anyway I am planning to soon merge the 2 options.
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.
(cherry picked from commit 55a7872e1b)
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.
(cherry picked from commit 8ec5f44f2f)
We don't need to commit PNG symbolic icons as `gtk-encode-symbolic-svg`
is perfectly able to generate them from the SVG.
Moreover its man says that it makes "specially prepared png files",
whatever that means. So I don't think we should just rename our
self-exported PNG files as '*-symbolic.symbolic.png'. It is better to
generate them with this tool.
Note that I am now splitting icon-list.mk into 2 files. This is only a
temporary stepback, as I am actually going to merge the 2 icon themes
into one very soon, and hopefully we should be able to generate the list
to ensure we don't miss an icon.
Anyway the icon lists had already diverged earlier, even though it was
only all still in a single file.
A single icon theme can contain both regular and symbolic icons. Let's
give possibility to switch from one style to the other within GIMP
Preferences.
This won't work very well in all cases yet, especially if an icon theme
only has symbolic icons (and no regular ones) because of inconsistencies
in glib which are being fixed (patches which I submitted and which were
merged in glib on 2018-08-17).
So this will work as expected when we will bump our glib requirement to
whatever is the next release.
Ell