… gimp_label_spin_set_digits() and deleted gimp_prop_opacity_entry_new()
- The "digits" argument for the number of decimal places in
gimp_prop_scale_entry_new() is now mostly useless since GimpLabelSpin
(hence GimpScaleEntry too) got a nice estimation algorithm of sensible
values.
- Add gimp_label_spin_set_digits() function to manually set the digits
property when we don't like the estimated value.
- Also add a new "factor" argument to gimp_prop_scale_entry_new(). Its
role is to allow a GimpScaleEntry showing a factored range, typically
a [0, 100] range for some types of [0, 1] properties.
- Remove gimp_prop_opacity_entry_new() which was basically a
special-case of gimp_prop_scale_entry_new() and which can now be
easily reproduced by simply set factor=100.0.
- Update all usage of gimp_prop_scale_entry_new() in app/ and plug-ins/
with updated arguments. It is interesting to note that all existing
usage were either integers (digits=1) or when double, the estimated
decimal places are the same as the ones which were manually set (hence
showing the generic estimation is not too bad). So the new function
gimp_label_spin_set_digits() was not even needed once in current code.
The values of Description tab - Copyright Status and IPTC tab - Urgency were not saved.
We are fixing that with this commit. Urgency is also saved to Iptc.Application2.Urgency.
Iptc equivalent tags of Xmp tags were only read if the Xmp tag had no value
which doesn't make sense since there is no guarantee that they are the same.
We changed this to always read the Iptc tags too and if the value differs
from the Xmp tag we add both values. That way the user can decide
which values are relevant.
This is one of the problems mentioned in issue #5863. This commit fixes
this problem in the metadata-editor by using gexiv2_metadata_get_tag_multiple.
Empty string values will be skipped.
Basically the same design as before (but a bit prettier, by using a
2 columns flowbox rather than a grid), yet 80 lines smaller according to
git stats. Also still the exact same code logics as before. No feature
loss (and actually a feature gain as there was the "Save comment"
checkbox but no text field to edit the comment as we get in other
plug-ins).
Basically better and prettier dialog in just a few lines. Moreover it's
still work-in-progress. We can even do better, but this is things to
come.
… fails.
My previous commit was just assuming there is one page when the libtiff
function fails. But thinking a bit more on this, there are 2 edge cases
even here:
- If the image is actually really corrupted to the point there are no
TIFF directories to read.
- If there are actually more available directories. It would be much
better if GIMP were able to salvage them from a broken file.
To handle these cases, I actually count manually the number of
directories by looping with TIFFSetDirectory() (which still works fine
on our minimal image). I use 65535 as a max value because in libtiff's
TIFFNumberOfDirectories() implementation, it says this is the max value
(even though I couldn't confirm this in the spec; there is a "Number of
Directory Entries" on 2 bytes, but this is about various fields for each
directories, not a number of directories; still anyway this is already a
huge number and since libtiff won't likely be able to handle directories
over this limit, not need to go over either).
I am also adding a test in the end so that we can output an appropriate
message if we actually failed to read any data from the TIFF (whether or
not TIFFNumberOfDirectories() succeeded, when we actually tried to read
the contents, we couldn't).
On a provided minimal 1×1px TIFF file, TIFFNumberOfDirectories() seems
to choke on some missing field and returns 0. I am not sure if the file
is actually valid or not, but let's make some kind of exception
(outputting a warning of our own when we do) by assuming there is at
least 1 page/image in the file when TIFFNumberOfDirectories() returns 0.
Other than this minimal file (which probably has no other interest than
being a test case), it could actually help salvage corrupted TIFF file
by attempting to read more data.
- New GimpLabelIntWidget which is a label associated to any widget with
an integer "value" property.
- New gimp_procedure_dialog_get_int_combo() which creates a labeled
combo box from an integer property of the GimpProcedureConfig.
- Renamed gimp_procedure_dialog_populate*() with
gimp_procedure_dialog_fill*(). Naming is hard! I hesitated using
_pack() as well (similarly to GtkBox API).
- New gimp_procedure_dialog_fill_flowbox*() functions to create a
GtkFlowBox filled with property widgets (or other container widgets as
we can pack them one in another). This is an alternative way to build
your GUI with sane defaults, with list of property names.
Probably one of the simplest plug-in dialogs, with only few properties
and all in the main box. So it's quite easy to port, even with the still
limited generation API.
file-tiff plugin can read and write GeoTIFF tags
New checkbox 'Save GeoTIFF data' has been added to Export dialog.
Signed-off-by: Ruthra Kumar <ruthrab@gmail.com>
… gimp_scale_entry_set_bounds().
I realized that this function may look like the set() opposite for
gimp_scale_entry_get_range(), which it is not at all. The get_range() is
for getting back the GtkRange widget packed in the GimpScaleEntry,
whereas the set_range() is to change the minimum and maximum allowed
values.
I had recently renamed the former, and could just rename it back into
gimp_scale_entry_get_scale() as it was, but since the class we rely on
is actually called GtkRange (GtkScale is a subclass), I think it could
be misleading. So in the end, let's rather rename the function setting
the widget minimum and maximum as gimp_scale_entry_set_bounds() instead.
Hopefully this is even more understandable. Naming is hard!
Renaming the temporary function gimp_scale_entry_new2() into
gimp_scale_entry_new() now that the original code is entirely gone. This
is now a fully-fledged widget with a nice and proper introspectable API.
Former gimp_color_scale_entry_new() is finally replaced by the
GimpColorScaleEntry implementation.
Both places which used it (GimpColorScales and compose plug-in) now use
the new widget.
Also making "upper" and "lower" properties of GimpScaleEntry into
construction properties, and create the main GtkAjustment at init, so
that we are sure that lower and upper bounds are properly set before we
set the value (when setting all properties at once, we cannot ensure
that these limit properties are set before the "value" one).
Similarly to GimpScaleEntry, this is meant to replace usage of
gimp_color_scale_entry_new() by having a proper widget. This is a child
class of GimpScaleEntry which simply replaces the GtkScale by a
GimpColorScale by adding a GimpScaleEntry class method to create the
scale widget (only restriction: it must be a GtkRange subtype).
This also triggers me to rename gimp_scale_entry_get_scale() into
gimp_scale_entry_get_range() (as well as the 2 plug-ins already using
this function).
This fixes#5838 which was caused by an incomplete port
of this plug-in to the new introspection API.
For now we do keep the n_drawables parameter of save_ora until
issue #5312 is fixed. Not doing this would cause saving to fail.
I got rid of gimp_scale_entry_set_sensitive(), as we can now use the
generic gtk_widget_set_sensitive(), and I ported the 2 plug-ins using
this function.
I also created gimp_scale_entry_set_value() to set the value (nicer than
setting object properties).
Instead of setting always manually the step and page increments when
creating a GimpScaleEntry, let's just generate some common cases
automatically. Indeed the increments are rarely something you want to
care about. The algorithm used is:
- For a range under 1.0, use a hundredth and a tenth (typically a [0,
1.0] range will step-increment of 0.01 and page-increment of 0.1).
- For small ranges (under 40), step-increment by 1, page-increment by 2.
- For bigger ranges, step-increment by 1, page-increment by 10.
For use cases when you absolutely want specific increment values, I add
the gimp_scale_entry_set_increments() function. It is much better to
have a small and understandable constructor call followed by
configuration calls (only when needed) rather than a constructor with a
crazy amount of parameters. Hence gimp_scale_entry_new() went from 17
arguments (absolutely unreadable calls) to now 5.
This is the bug which triggered me to do previous commit because the
error message was talking about a procedure name. Now the error message
is right, but let's not have an error at all! ;-)
… of query_procedures().
Since our procedure list is now fully dynamic with runtime check, it's
much better to run it at every startup. Basically if some has updated
libheif with new encoders/decoders, we want GIMP to be aware at it at
next startup even if the plug-in has not been updated.
We didn't check whether TIFFSetDirectory succeeded nor did
we check TIFFReadScanline for failure which can cause
unresponsiveness.
We will not try to read a tiff page if setting its directory fails
and we will stop reading a page if reading scanline fails.
Since obj->type_data is also int anyway, multiplying by a double value
is unneeded anyway. So let's just make an integer multiplication.
Fixes the following warning:
> warning: using integer absolute value function ‘abs’ when argument is
> of floating point type ‘double’ [-Wabsolute-value]
The correct tag for sub images is Exif.SubImage instead of
Exif.Image. I also added Exif.Image.InterColorProfile since
that didn't seem to get deleted when saving without
color profile.
Also added a FIXME note since most of this stuff should be
genealized for all gimpmetadata handling.
libheif pc files provides variables which are actually older than our
minimum libheif requirement (so it's usable generically) to determinate
if libheif was built for HEIC/AVIF support. This is quite useful as we
had our share of annoyance with missing support of some encoder/decoder
even when libheif requirement was alright.
Also adding image/avif (if relevant decoder is present) to list of
supported mimetypes.
