And always pass URIs to all file procedures, the ones what didn't
register as "handles remove" will only ever get local file:// URIs.
Change all file plug-ins (also legacy ones) to expect URIs instead
of filenames, and convert to local paths in the plug-in.
The wire protocol should now be almost 100% clean of non-UTF-8 strings.
I am going to forbid plug-ins from being installed directly in the root
of the plug-ins/ directory. They will have to be installed in a
subdirectory named the same as the entry point binary.
This may seem useless for our core plug-ins which are nearly all
self-contained in single binaries, but this is actually a necessary
restriction to eliminate totally the DLL hell issue on Windows. Moving
core plug-ins in subfolders is only a necessary consequence for it.
...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.
Michael Natterer