The rotation was actually applied but the image had an orientation
metadata stored which is not visible in GIMP canvas (only checked at
import).
If GIMP had on-canvas viewing support of the orientation metadata, then
it would make sense to keep it between import and export, but since it
doesn't, we should assume that when someone asks to "Keep Original"
during import, they are actually asking to drop the metadata (which
actually can be wrong in various cases, in particular when you snap
pictures of the ground or the sky, then sensors are lost anyway and
regularly can't guess what orientation you wanted). This will make for
less unexpected exports.
Removed the WinMain specific stuff for the plug-in and determine
hInstance in twainMain which made porting a lot easier.
The _DEBUG enabled functions I have mostly left alone and
should be revised at a later time.
The proposed defaults for export should be the less destructive
possible. So for any 16 or 32 bpc GIMP images, since our HEIF plug-in
only supports up to 12 bpc, this should be what we export to.
… and have gimp_prop_int_combo_box_new() bind to "value" instead of
"active".
The "active" property is defined by GtkComboBox and is the index of the
combo box, not its values, whereas with gimp_prop_int_combo_box_new(),
we want to bind an int property to the combobox value. Therefore the
commit 0828a371c2 was only properly working when we were creating a
combo box with values starting at 0 and incremented by 1.
By adding a "value" property to GimpIntComboBox, I allow binding any
property to the int value rather than the index.
See also !265 where the issue was raised as it affected our HEIF
plug-in.
gimpimagemetadata.[ch] was built into libgimpui because GTK+ was used
for dialog query for rotation metadata. gimpimagemetadata-save.c only
was built into libgimp, which made no sense as the declaration for its
public function was inside gimpimagemetadata.h!
That was a weird situation and somehow only made visible in the build
system because GIR build was complaining about missing annotations to
gimp_image_metadata_save_prepare() (the annotation was actually present
but in the implementation which was not in the same library as the
header, how weird!):
> Warning: GimpUi: gimp_image_metadata_save_prepare: return value: Missing (transfer) annotation
Moreover it means that only plug-ins linking libgimpui had access to the
gimp_image_metadata*() API, which is obviously not cool (that should be
a core API).
Instead I moved everything into libgimp and replaced
gimp_image_metadata_load_finish() with
gimp_image_metadata_load_finish_batch(), which is essentially the same
function except that it's not interactive (it will proceed to rotate the
image without user confirmation, provided the right flag is present).
Then I add gimpimagemetadata-interactive.[ch] which contains only
gimp_image_metadata_load_finish() and is the alternative interactive
version of gimp_image_metadata_load_finish_batch(). Most plug-ins won't
even have to be changed (at least none in core GIMP) and would still
work as before, whereas now a non-interactive version exists, which
doesn't mandate to link GTK+.
Current dev code of GEGL is necessary as it fixes its VAPI dependency
(see gegl!83). Without this, with a recent meson version, Vala plug-in
build fails.
See !334 for some more background.
This adds a blend mode for all known psp blend modes that were not
converted yet except for adjust.
I couldn't find any information about adjust and it's value of
255 suggests that it is not a normal blend mode.
Reduce number of undo steps created by Spryrogimp previews.
First, by grouping them into a single undo.
The implementation adds a function for clearing the
incremental preview drawing that is being executed as an idle task,
and closing an undo group in case the preview left it open (which
would usually be the case). A second way to reduce undos is
by generating a new preview only upon mouse button release of
scales in the UI, and not while dragging the scale.
Jehan