Since it appeared with GLib 2.68.0, we could not change this until we
bumped the dependency which has only become possible a few days ago
(since Debian testing is our baseline for dependency bumps). Cf.
previous commit.
As this is a drop-in replacement (just a guint parameter changed to
gsize to avoid integer overflow), search-and-replace with:
> sed -i 's/g_memdup\>/g_memdup2/g' `grep -rIl 'g_memdup\>' *`
… followed by a few manual alignment tweaks when necessary.
This gets rid of the many deprecation warnings which we had lately when
building with a recent GLib version.
libgimp is anyway processed at the very end after all other libgimp*
were built. This way, it also fixes#3746, by removing the $(top_srcdir)
everywhere from introspected files, hence making the build work again
with older automake.
Only libgimpwidgets is not introspected yet as it didn't work from
scratch and I don't have the time right now to look into it. Anyway with
all the others, we already have so many warnings during the GObject
Introspection step now that we have a lot of work to do already!
... off-by one size in special cases
The last commit wasn't drastic enough. We changed SIGNED_ROUND()
to use RINT(), which, in turn, may use rint(). However, rint()
effectively breaks ties to even, so that we get stuff like
'rint (1.5) - rint (0.5) == 2.0 - 0.0 == 2.0'. This can't be
good--it's entirely possible that we're bitten by this in other
cases without noticing.
Avoid rint() entirely in RINT(), and always use 'floor (x) + 0.5'
instead, which always breaks ties up. Hopefully, this doesn't
break anything else...
... off-by one size in special cases
SIGNED_ROUND(), which is used by GimpToolRectangle, among other
things, used to round negative values which lie exactly between
two integers, i.e., -foo.5, down. This could lead to the rectangle
being one pixel bigger than expected, in either dimension, when one
of its edges had a negative coordinate, and the opposite edge had a
positive coordinate.
Fix SIGNED_ROUND() to always round such values up, regardless of
sign.
...instead of transforming it
Add gimp_matrix3_will_explode() which determines if a transform
matrix will blow up something in a rectangle to infinity, and use
the function so set both the GIMP and GEGL code paths to clip the
transform to the input size.
because it confuses gtk-doc and breaks some links. Also change the
"Index of new symbols in GIMP 2.x" sections to be what seems to be the
modern standard (looked at the GLib and GTK+ docs), and update some
other stuff.
The foo_DEPENDENCIES rule replaces the default dependencies, where
EXTRA_foo_DEPENDENCIES just appends to it. This was causing libgimp
and libgimpui to build out of order.
ROUND() is consistent only on positive values, and bad rounding
creates an offset when negative values are involved. Introduce
SIGNED_ROUND() and use it in gimprectangletool.c. It should probably
be used in much more places.
This only helps to maintain proper includes in app/ and shouldn't
affect plug-ins at all, because these are supposed to only include the
main headers from libgimp/ since the beginning of time.
The gimpfootypes.h files do not have these guards, so we can continue
to maintain app/'s include policy that is very likely to error out if
wrong things are included.
Niels De Graef