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)
After discussing with Mitch and understanding better the X bitmap/pixmap
history, I make the warning more specific to X bitmap cursors only (not
pixmap).
Also I can see our code always exports RGBA data, so I am not quite sure
if this warning even makes sense since X bitmaps are bicolor maps. On
the other hand, Mitch tells me that "these days gdk turns pixbufs into
bitmaps if the x server doesn't support rgba cursors", so maybe that can
still be of use to warn cursor designers for max compatibility.
Still that's pretty old compatibility stuff, so let's replace "may" by
"might".
Leading 0s have no special value, we use base 10 anyway. Removing
leading 0s allows to not trigger the 8-digit test, hence modify a valid
cursor size unecessarily.
We were basing our max export size on a macro value defined in
libXCursor code: MAX_BITMAP_CURSOR_SIZE. This macro is still defined in
libXCursor and still has the same value (64), yet it is unsure how far
or even where this is enforced since it seems we can get at least 96px
cursors in GNOME/X11.
As a consequence, this commit:
- still warns when cursor size is over this value, with more explicit
text, yet does not change the cursor size anymore! So it is now
possible to export bigger cursors, but you still get a warning.
- only changes the cursor size for the existing more-than-8-digits test
and I add a warning when it does so (we should never modify an image
silently!).
- adds the size 96 as not triggering the warning about GNOME Settings
since it definitely looks like this size is valid there (according to
my own empirical tests). Also since 96 is higher than the libXCursor
current MAX macro value, this really raises the question to where this
max is enforced and whether we should not just drop the first warning.
Note that it breaks a bit the string freeze since I modify one string
and adds one. Sorry for this!
A malicious XMC file can contain an invalid TOC count, which could lead
to an out of boundary write on 32 bit systems due to integer overflow.
This error occurs during thumbnail creation.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
...in both the core and libgimp.
Images now know what the default mode for new layers is:
- NORMAL for empty images
- NORMAL for images with any non-legacy layer
- NORMAL_LEGAVY for images with only legacy layers
This changes behavior when layers are created from the UI, but *also*
when created by plug-ins (yes there is a compat issue here):
- Most (all?) single-layer file importers now create NORMAL layers
- Screenshot, Webpage etc also create NORMAL layers
Scripts that create images from scratch (logos etc) should not be
affected because they usually have NORMAL_LEGACY hardcoded.
3rd party plug-ins and scripts will also behave old-style unless they
get ported to gimp_image_get_default_new_layer_mode().
with proper value names. Mark most values as _BROKEN because they use
weird alpha compositing that has to die. Move GimpLayerModeEffects to
libgimpbase, deprecate it, and set it as compat enum for GimpLayerMode.
Add the GimpLayerModeEffects values as compat constants to script-fu
and pygimp.
and clean up the formatting of the call and the lines around it. Now
we can check the various (disabled) export options for regressions
again by changing a single line in gimp_export_image().
Don't register a second file procedure for extension-less exporting as
XMC, this approach is totally bogus. Fixes the duplicate XMC entry in
File->Export.
I'm sure some plug-ins need to add their items *not* at the toplevel,
but since making plug-ins really tree-aware is a lot more work than
just fixing insert positions, I went for passing -1 as parent in
almost all cases. And because of laziness...
