... starting with toolbox buttons.
This is particularly a problem in single window mode (and sometimes in
multi-window mode) where canvas easily loses focus, hence key events.
Place the rulers' origin at the top-left corner of the canvas
(screen space) bounding box, and set their scale to the image-
space scale along the screen-space horizontal/vertical directions
(in other words, measuring a distance using the rulers should
give the same results as the measure tool; note that rotation
comes into play here only when the horizontal and vertical
image or screen resolutions are different, since otherwise the
scale is direction invariant.)
Make scrollbar step match ruler step under the new behavior.
This explains a little better why some systems (i.e. GNOME…) would show
no icons in menus whereas other (i.e. Linux Mint, Windows…) would show
them. GIMP_ICONS_LIKE_A_BOSS environment variable is a developer trick
to show icons in menus anyway to see how things render on such systems.
...after entering single window mode
This commit fixes dangling pointers in GimpDockColumns, it doesn't fix
the bug but it's a prerequisite. Original patch by Massimo.
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.
