This should in principle allow loading plugins (which are executables)
from foreign architectures, although it will not allow loading foreign
modules (which are dlopen'ed).
I'm deliberately not changing the ${libdir} at this stage, because gimp
seems to treat the plugin directories derived from the ${libdir} as
configuration parameters that might be saved in user configuration, so
modifying plugin-loading code to look in /usr/lib in addition to
/usr/lib/${multiarch} will not necessarily be effective.
Closes: #737725
This should be sufficient to make *some* dependent packages
cross-compile. Packages that need to run gimptool-2.0 during build
will still not cross-compile, unless they are able to run
host-architecture executables, for example via qemu.
Thanks: Helmut Grohne
Closes: #872424
Simplify data transfer in the twain plug-in, and add support for
16-bit RGB/grayscale images.
(cherry picked from commit 30f65bb6c5fdbbb48edd3d07d764763d6a2477c4)
... since GEGLification of the twain plug-in (2.10.14 and later
versions)
In the data-transfer functions, allocate a temporary buffer for the
converted data on each call using the current chunk size, instead
of reusing the buffer allocated on the first chunk. This allows
for different chunks sizes across calls.
(cherry picked from commit 9a1d43c978)
... by grouping the geometry options, which can be controlled
through the on-canvas UI, in an expandable frame, which is
collapsed by default. The shape option is not part of the group,
and is moved to the top.
(cherry picked from commit 438babea6b)
In _gimp_prop_gui_new_generic(), when a pair of consecutive
properties have "range-start" and "range-end" roles, respectively,
and "luminance" units, use a range prop-widget for both properties,
as per the previous commits.
The range is sorted by default, unless the first property has a
"range-sorted" key of "false".
(cherry picked from commit 8eb752b194)
