geeqie
geeqie copied to clipboard
BestImageViewer
"Fit horizontally" and "fit vertically" don't fit. Repeating the keypresses switches between two wrong situations
ISSUE TYPE
- Bug Report
GEEQIE VERSION
/usr/bin/geeqie --version
Geeqie 1.5.1
What GTK toolkit is used to compile Geeqie?
Mmh, it's from official Ubuntu 20.04 repositories.
Appears to be gtk2, see below.
ldd /usr/bin/geeqie | grep -i gtk
libgtk-x11-2.0.so.0 => /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 (0x00007f81b1987000)
OS / DISTRIBUTION
Xubuntu 20.04, running XFCE.
No magic program of any kind trying to snoop on window sizes and doing anything nasty. Just plain XFCE.
SUMMARY
In some cases (easy to reproduce) "fit horizontally" and "fit vertically" don't fit. Repeating the keypress switches between two wrong situations.
STEPS TO REPRODUCE
-
Ensure that in preferences, "Windows", "Fit window to image when tools are hidden/floating" is checked.
-
If file list is floating, you have another bug: press h or w, and observe that the main window does not resize, in spite of the checked configuration. After seeing that bug, press "L" so that it is integrated in main window.
-
Now press "L" to ensure that file list is floating.
-
Now the geeqie logo (or any image) is visible in its own window, with some border (unless you are in an extraordinary case where the window already has exactly the image dimension, in this case resize the window somehow).
-
Press "w" or "h" to fit.
-
Second, press again the same key at will.
-
Third, use the other key (h or w), several times or alternating.
Expected
-
After first "w" or "h", displayed image is resized to fit window height or width, and the other dimension of the window is adjusted so that the image exactly fits, no border.
-
Second, pressing again the same key does not change anything (the image already fits as ordered).
-
Third, pressing another key should do nothing (perhaps in some cases due to rounding errors, there might be some drift in window dimensions, but that would be another bug so let's ignore for now).
Observed
-
After first "w" or "h", displayed image does not fit, neither window height nor width.
-
Second, pressing again the same key produces a new effect but still not fitting neither window.
-
Third, pressing "h" or "w" always toggles between two window sizes that are both wrong. It does not matter if you press "h" or "w", the effect is the same.
More precisely, it looks like geeqie applies a zoom Za and a window size Wa, then another zoom Zb and another window size Wb, but the zoom Za would fit windows size Wb not Wa, and the zoom Zb would fit window size Wa not Wb.
Analysis
Possible workarounds:
- (not a serious workaround) claim that it does not make sense to have both "fit window to image" and ask to fit image to window. It does make sense, meaning: "keep on window dimension constant and, adjust the zoom to fit that dimension, then adjust the other dimension of the window to fit zoomed image" and that's what geeqie was doing for years.
- uncheck "Fit window to image when tools are hidden/floating" and the window will never resize, losing the feature above
So, all in all what is lost in this bug is the possibility of for example, adjusting window to a certain height (for example docking it to the left half of the screen like gnome offers, or quicktile offers on all X11 desktops) then pressing h to adjust the width of the window, keeping the height set (and similar with other combinations).
Latest master 955709eb5885dd130cc47aee493d193df982a3de did not change the situation, compared to the time of reporting the bug.
Behavior on 1.5.1 is good.
Perhaps there is something wrong with this bug report: the bug occurs on master, perhaps it never occurred on 1.5.1.
ldd /path/to/compiled/bin/geeqie | grep gtk
libgtk-3.so.0 => /lib/x86_64-linux-gnu/libgtk-3.so.0 (0x00007ff1f47ac000)
Of the series reported in a row #785, #786, #787, #788, #789, #790, two, #786 and this one #789 occur on master. They are both indeed annoying enough to not use geeqie master and stick to 1.5.1 instead.
One specific reason why it's annoying that I just noticed is when advancing through a series of pictures, some in portrait, some in landscape.
When moving from one picture to another picture, either by pressing pageup, pagedown, or clicking in the tool window, the image window size does not correspond to the image currently being displayed, but to the one that we went away from.
In other words, if the new picture has a different aspect ratio, the window is not resized to that new. It gets resized only after we switched to a third image, and the same thing goes on and on as more pictures are selected. When selecting 3 images of the same size in a row, the problem is no longer observable, but one guesses it's still there, just has no effect.
In case it's useful, desktop environment is XFCE 4.14, wifh its window manager xfwm, version 4.15.3git.8c86c4eeb .
Using a fixed size window works around this bug #789, but #786 still strikes.
Will stick to 1.5.1 . Feel free to ask me more test with more recent git versions.
Thank you for your attention.
[ While looking at this problem I see that when tools are floating, the image window is anchored on the top left corner - unless the image is wider than the screen, in which case the top left corner may move left. Switching between images of different sizes produces a disconcerting effect (to me). Maybe anchoring on image centre would be better. ]
Does the fix for #786 fix this problem also?
Hi. I don't see a fix for #786, or even a workaround.