...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().
It's about importing in fact.
Parse BITMAPV4HEADER / BITMAPV5HEADER and use GIMP's BMP
implementation instead of using gdk_pixbuf.
Also, remove an old hack about 32bits bmp v3 + alpha. The alpha
channel is already ignored in that case.
These were erroneously parsed before. Now we reject them. It is
trivial to implement support for them, but we can't test it unless
someone comes up with a sample BMP file. They don't seem to be
available in the wild.
See #678250, #678252, etc. for example bug reports.
This fix should be sufficient in fixing BMP output, but it looks
like some apps like Firefox have broken BMP loaders which do not
care for the masks. We would have to change the masks for them.
Make writing BITMAPV5HEADER color space information optional since
there are compatibility problems with writing color space
information. Unity 3D and BlitzMax have been reported to not support
such BMP images.
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...
Created a resource file for plug-ins and a rule to link it to them.
The application icon file is smaller than the default one, there's no
point in doubling the size of a plug-in executable just for an icon.
If no problems turn up, this will close the bug.
Michael Natterer