Before commit 20523c61ac
PF_FILE used to open a "open file" filechooser dialog.
That commit, while adding the ability to open
a "save dialog" filechooser dialog using PF_FILENAME,
changed the behavior of the existing gimpfu PF_FILE type.
Restore the previous behavior and update the
built-in plug-ins using a save dialog to the new
PF_FILENAME.
FileChooser 'action' and 'buttons' should be consistent
and call set_alternative_button_order to be consistent
on platforms using the alternative button order.
Remove gimp_ui_init call from gimpui module initialization.
Add gimp_ui_init method to gimpui module and call it from
gimpplugin _run method before running the user code.
Separate clearing/creating the image's cached color transforms from
clearing/creating its color profile. Clear the transforms when the
color profile changes, and when image type or precision change. Create
the transforms only on demand, so clearing them multiple times doesn't
trigger any redundant (and expensive) transform creations.
Completing fix from commit 3cb70e6.
Checking further into libtiff logs, I can see another version of the
warning message for private tags which was used before libtiff 3.7.
For sake of completeness, let's check against this version of the
warning as well.
This is a regression from bug 131975. Any unknown tag over 32768 is not
an error. This is a reserved zone where it is allowed to create custom
tags.
The warning indeed changed since libtiff 4.0.0alpha where it has become:
"Unknown field with tag %d (0x%x) encountered"
This explains why it was not recognized anymore.
... not screen space
Flip and rotate the canvas around the center of the viewport,
instead of the center of the image. Scroll the display as
necessary to keep the center of the viewport fixed during
these operations. This applies to both the corresponding
menu items, and rotation using Shift+Space.
Likewise, flip the canvas across the designated axis in
screen space, instead of image space. Rotate the display as
necessary, such that the reflection appears to happen in
screen space, regardless of the current rotation angle of the
canvas.
As proposed by Mitch. This completes first renaming attempt (commit
08ffc10) with even less ambiguous names.
"horizontal-axis-position" and "vertical-axis-position" are now
respectively "mirror-position-y" and "mirror-position-x".
"Horizontal position" and "Vertical position" could be mistaken as
meaning respectively the x and y coordinates, hence the vertical (resp.
horizontal) guide's positions.
The more accurate "horizontal-axis-position" and "vertical-axis-position"
namings are less misleading.
...selection on the canvas
if the editor dialog is active do not copy to the
clipboard the text selected, copy it instead when
selected with keys <Shift>-left/right.
Don't remove the GDK_KEY_space in GimpSearchPopup because that's
impossible and removes it from the entire GimpPopup class. Instead,
don't handle the "space -> confirm" binding manually if the focus
widget is a text widget.
