Since SRTM-1 and SRTM-3 data have a fixed image size, it is actually
very easy to auto-detect these by checking the file size. There is no
need to ask the user to select between the 2 variants (even though these
values are made quite obvious by official download links).
I still left the dropdown appear optionally if the detection fails for
some reason (we never know, at least that makes a fallback, for instance
to be able to load partial data!). Yet now by default, HGT file settings
should be fully auto-detected.
g_set_error() so that when samplespacing is not a valid argument for
file-hgt-load, the error is properly propagated.
Also add a g_warning() to get the error in the terminal as well.
This allows for it to show as a separate item in the open dialog, with
proper naming. Also add proper arguments so that the handler works as a
PDB function in non-interactive mode, unlike file-raw-load which works
only interactively.
- Display title "Digital Elevation Model data" instead of just "Image".
- Don't show the type combo anymore, since HGT is always 16-bit signed
integer in big endian.
- Don't show the width and height either, but instead show a dropdown
list to choose between either SRTM-1 or SRTM-3 data. There seems to be
only these 2 types of data, and this will determine the width and
height. This choice (SRTM-1 vs 3) will mostly likely be better known
by people than knowing what image dimension they have to set,
especially since official links for such files seem to all include the
information.
- Add some parentheses to sizeof (*pointer). Maybe it's just me, but it
is just a bit clearer to me.
- Free in_raw when out_raw allocation failed.
- Use strrchr() instead of strchr() to get the extension (I had a case
when testing where the file was inside a folder named similarly with a
".hgt" and it would break the comparison test).
- Do a case-insensitive comparison. Even though the original files from
NASA use lowercase, just to be sure.
...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().
The signature of the original file-raw-save procedure must not change,
so change it to use the old parameters.
Change the other procedure (with additional arguments) to
file-raw-save2.
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.
It's deprecated in GTK+ 3.x, so we get rid of some deprecation
warnings. Also, it has always only been a utility function that hides
what is really going on in the widget hierarchy.