Resolves#5627
The current limit for Clipboard Brush and
Pattern maximum size is set to 1024 because
that is the largest value that a 32-bit
architecture can safely handle.
64-bit architectures can support larger
dimensions, as confirmed by
Stanislav Grinkov during testing. This patch
therefore uses macros to increase the
size limit if we detect a 64-bit architecture,
and otherwise default to the 32-bit limit.
Resolves#15292
The IFF specification states that EHB format images
have exactly 32 colors in their palette. However, it
is possible for images in the wild to place an incorrect
palette size. This patch checks for this, and either limits
the palette size or breaks accordingly.
Resolves#13570
The SVG specification prohibits certain characters
from being used as part of a path id attribute, such as
whitespace and hyphens. Rather than try to filter the
path name selected by the user, this patch switches to
an auto-incrementing "path%d" format to ensure any
exported path can be read by strict parsers. This also
matches how we implemented ids in the SVG export
plug-in.
This last argument in libmypaint's mypaint_brush_stroke_to_2() is called
barrel_rotation. If you look at MyPaint's code (in particular file
gui/freehand.py), you see it is taken from GDK_AXIS_WHEEL of the input
event, which corresponds to our coords->wheel (there is this
long-standing question about the difference with GDK_AXIS_ROTATION
because as far as we know, this is probably the same value anyway; as
was explained to us by a Wacom developer long ago).
Unfortunately I can't test as we don't have any stylus with such barrel
rotation feature (and unfortunately this hardware feature is
discontinued and getting a stylus with this is extra-hard now), but that
should work. And at the very least, it does match with MyPaint's
implementation.
Resolves#12755
gimp_edit_selection_tool_active_modifier_key () assumed
that if you press a modifier key while a selection/move tool
is active, we should move the selected item to the last place
recorded. However, it's possible to run this function before
we've moved anything, thus defaulting the "original position"
to 0, 0.
This is most noticeable in the Move Tool, where pressing Ctrl
or Shift after clicking a layer but before moving it will cause
the layer to "jump" based on where the cursor is placed on the
item.
This patch adds an additional condition to the motion function
in gimp_edit_selection_tool_active_modifier_key (), so that
we only do it if we've already moved the cursor at least once.
See: Infrastructure/gimp-web-devel@7be7fbe0
In short, such information is not needed to making/building the
packages, just to submitt/release them, which is maintainer-thing.
But let's keep at least a reference so making them easier to find.
Since we don't necessarily re-render the color area when the color
change, let's store the actually rendered color, additionally to the
supposedly rendered color. Otherwise when changing the color by very
small increments, small enough that the color is always perceptually
identical to the previous color, we never re-render the widget, even
when the rendered color is now quite different. Indeed the "identical
color" algorithm, based on CIE2000 distance, is not transitive.
Additionally I do not check for perceptual identity in
GimpColorSelection anymore, because we also check for this in the
GimpColorArea. Better always having the right color set in the area.
This was raised in #11339 (even though the initial issue was about the
hexadecimal field).
MR glib!4901, backported as glib!4912, will be available in version
2.86.3. Let's keep the workaround so that link layers work without
having to bump the minimum requirement, but add a GLIB_CHECK_VERSION
test. This way, it will be clear that we have to get rid of this part of
the code even if we bump the GLib requirements years ago, when we'll
have completely forgotten about this issue.
Resolves#153494812fddc adds the ability to delete multiple items
at once. However, the limit to delete was accidentally
set to greater than 1, rather than 0. This patch fixes
this mistake.
As of 443947c6, we no longer require passing
the selected drawables to the export plug-ins
(as each plug-in now grabs those from the
image itself).
Therefore, we can remove the restriction that
there must be a selected layer before you
can export or save an image.
This should be unnecessary since GExiv2 did the break properly by
renaming files (making it possible to install side-by-side an older
version of GExiv2 and a newer version). But some packagers are wrongly
renaming the .pc file, tricking our build system into accepting the
newer incompatible libgexiv2.
So let's add an additional test, explicitly forbidding newer GExiv2.
We'll move on to the new version when we'll be ready. For the time
being, there is a reason why files were renamed and packagers should not
force incompatible versions to fit.
