Re: [Pan-users] Body pane is wrongly resizing pan's top-level window

[Duncan]

walt posted on Thu, 02 Jul 2015 08:34:34 -0700 as excerpted:

> About once a year I get bored enough to try to fix this ancient bug in
> pan's behavior and every time I conclude that gtk is a horrible mess,
> designed by the devil to torture innocent soft- ware developers.
> 
> Anyway, here's the behavior that I consider to be wrong:
> 
> When pan displays an image (typically a jpeg) in the body pane,
> if the image is is too large to fit properly then the body pane somehow
> manages to enlarge the entire pan window enough so that it's too big to
> fit on my monitor screen.
> 
> I think, in general, that a child window should never resize a top-level
> parent window under any circumstances, so this should be fixed.  I keep
> looking at the code but I don't understand it enough to fix it myself.
> 
> Anyone else have any clues?
> 
> Thanks.
> 
> BTW, note that the body pane already has a scroll-bar to allow the user
> to view the entire image, so resizing the top-level window is completely
> unnecessary in any case.

What OS/window-manager are you using, and do you have pan's main window 
setup with any custom rules?  And do you have pan set to size images to 
fit by default, or not?

I ask because I've /never/ seen pan behave like that, here, running kde4/
kwin4.  I do have some custom window rules setup for pan's main window, 
but I'm not forcing height, tho I am forcing width.

(The following takes my usual long, "scenic route" approach, to the reply 
at hand.  Just sit back and enjoy the scenery.  We'll get there 
eventually!  =:^)

While most of the time I don't do binary groups, mainly only some 
primarily textual technical mailing lists like this one via gmane's 
list2news service, I did sign up for a huge 1 TB (10-power) block from 
astraweb for $50 a couple years ago, so I have binary access, and I do 
use it occasionally, tho at my usage it could last me well over a decade, 
perhaps even several... my lifetime (which is why I went big, despite low 
general use, for $50 it doesn't expire, and I may well never have to 
worry about buying more access ever again, even if I live several more 
decades!).

Between the occasional binary/images groups usage and the occasional 
screen shot on the technical groups, I get enough images that if the pan 
main-window-resizing was a problem, I'm sure I'd have seen it, but I 
haven't...

FWIW, here's my relevant settings:

Pan: view > body pane > size pictures to fit : checked

(But IIRC, last I used the toggle with a large image, it gave me scroll 
bars as expected.)

KWin window rules: 

Match tab:

Window class: substring match: "pan pan"
Window role: exact match: "pan-main-window"
Window type: normal window
Window title: substring match: "Pan"

Size & Position tab (see explanation):

Position: apply initially: 0,2180
Size: apply initially: 1920,1060
Maximized horizontally: force: yes
Initial placement: force: no placement

(Nothing set on the other tabs.)

Explanation:

My desktop consists of three full-hd monitors, 1080x1920 resolution, 
logically stacked for 1920x3240 total resolution.  The two lower 
monitors, my normal working space, are actually big-screen TVs, a 48-inch 
(122 cm) on the bottom, with a 42-inch (106 cm) above it, logically in 
the center.  That's actually the wall at the foot of my bed. =:^)  
Logically above them but physically off on the right side wall, is my 
third monitor, actually left over from before my big-screen upgrade; 
while the same resolution, it's only a 21-inch.

The small top (actually right) monitor is my system status dashboard, a 
superkarumba theme with real-time per-second-sampled line graphing per-
core multi-category cpu usage (user/system/nice/io-wait/total), multi-
category RAM usage (app/buffer/cache/total), voltage/fan/power/temp 
readouts, network usage, and displaying top apps by cpu and memory usage 
and the last 20-ish general syslog entries.

That superkaramba theme display window is full-width, almost full height 
of that monitor, "almost", because if I have the other two monitors full, 
sometimes the narrow bit at the bottom of that monitor is the only bit of 
the actual desktop I can access, I have plasma set so vert-scrolling the 
desktop changes vertical desktops, and that's the usual way I do so (tho 
I also have hotkeys for it), so I need access to at least a /small/ bit 
of the desktop in ordered to switch desktops.

The two big-screen monitors, then, are my normal workspace.  Actually, 
the bottom one is, with the middle one (the 42-inch) being aux/overflow.  
Often, I'll have youtube playing full-screen on the 42-inch middle 
monitor, while I actually work in the bottom (48-inch) one.

FWIW, here's a screenshot (which I've posted here before, IIRC), now a 
couple years dated but it'll give you an idea.  Just imagine the top 
third off to the side, on a normal size computer monitor, while the 
bottom two thirds are my main workspace on the wall in front of me.  In 
it, pan (open to a kde list/group on gmane) is on the middle monitor, 
with my claws-mail feeds instance open on the bottom monitor, with 
firefox/aurora open behind it, half-width.

http://wstaw.org/m/2013/05/11/duncan-fullscreen.png


OK, now that you have a general picture of my desktop in mind, I can 
better explain the kwin size and position settings I use for pan...

In general, I want pan open at full width (horizontal maximized), but 
not /quite/ the full height of the monitor, with it starting on the 
bottom monitor.  In the screenshot, the claws feed instance, with firefox 
open behind it, illustrates the reason behind the _almost_ but _not_ 
_quite_ full height.  I use a mouse policy of (sloppy) focus follows 
mouse, click-to-raise.  With pan (or claws in either feeds or mail mode) 
in three-pane-mode, I need full-width to get all three panes on-screen 
without crimping on header or body display area.  The /almost/ full-
height, bottomed on the monitor, leaves just enough room for a title-bar 
to stick out above.  That arrangement, with vertically maximized (to 
monitor) half-width browser, compose-window, and terminal (konsole) 
windows, combined with window transparency set just so, lets me work with 
upto three windows visible on the monitor at once.  In particular, I can 
have the almost-maximized window in front, with another half-width window 
or two behind, set so I can make any of the three active and type into 
them, while still viewing the others.  At a click I can bring any of the 
three to the top, and as long as I don't bring both half-width windows to 
the top at the same time thus hiding the full-width window, I can 
continue to work with all three at once.

Of course, this is usually on the bottom monitor, leaving the middle one 
for either more reference windows (normally full-height, half-width, so 
two, side-by-side), or for that full-screen youtube or the like.

So, a pan size, applied initially, of 1920x1060, with horizontally-
maximized forced on, and position, applied initially, of 0x2180, sizes 
and positions pan exactly as you see claws positioned in the screenshot, 
at the bottom of the bottom/primary-working monitor, with just enough 
room above pan for the titlebars of two full-height, half-width windows 
to stick out.

The applied-initially on the (vertical) size and position let me move pan 
to the aux monitor if desired, or, occasionally if I'm browsing the 
images groups, expand pan vertically to cover both working monitors, 
which if I toggle the groups pane off, gives me full 1920 width for image 
display, with a tall enough (2160 px) window I can still have a few 
headers showing in the headers list, while leaving the rest for image 
display.  I can then either have the body pane taking the full bottom 
monitor with the middle one for headers, giving me full-HD resolution 
image viewing in landscape mode, or, if some images are portrait mode, 
increase the body pane size a bit further at the expense of shrinking the 
number of headers displayed, to give portrait mode images a bit more room 
to display.

Meanwhile, the forced horizontal-max means my header column widths don't 
get screwed up as pan is always full-display-width.  =:^)  And the forced 
no-placement avoids the smart-window-placement that could otherwise 
override the apply-initially positioning.

(We'll forget about, for now, the other pan/gtk bug where it sometimes 
initializes column widths to zero, my guess being that it has to do with 
a gtk-icon resource loading race.  That always screws up column widths.  
Unfortunately, I'm not enough of a coder to fix it properly, but 
fortunately, I've scripted a workaround for it that patches the zeroed-
out column config, such that when it happens, I only have to shutdown and 
restart pan, and it automatically fixes the problem for me.)


So... Obviously I occasionally deal with images larger than my standard-
size body pane, or I could simply set the size to forced instead of
apply-initially.  Equally obviously, I'm not seeing pan resize itself 
displaying those images, because if it were to do so, I'd have been 
annoyed enough to set kwin to force size anyway, thereby stopping the 
problem.  The fact that I've not done so confirms my memory of never 
having that happen, thereby provoking the annoyance that would have lead 
to setting kwin to force the size.


So... it's not happening here.  Possible explanations/solutions:

1) It's some weird interaction between your window manager and pan.

S: Try a different window manager, or configure your window manager to 
avoid that interaction or force the size.

2) If pan is maximized, at least horizontally, the bug doesn't trigger.

S: Set pan maximized, at least horizontally.  Consider configuring your 
window manager to force it, if necessary.  If your window manager lacks 
such configurability, consider switching window managers to something 
that has it.

3) If pan's size, likely width, is over some minimum, the bug doesn't 
trigger.  Various people have reported issues with pan when run on 
extremely low resolution, typically under 1280 or 1024 px width, 
screens.  One problem, I believe now fixed, was that pan wouldn't resize 
smaller than its toolbar width.  Given the number of icons in the toolbar, 
it was wider than 1024 px, and people on netbooks with displays narrower 
than that really had problems.  Perhaps it can be resized smaller than 
that now, but certain conditions, including large images, triggers a 
resize larger, once again.

S: Configure the window manager to force width.  See #2's solution if 
your window manager can't be so configured.

4) It doesn't trigger if pan is set to size images to fit.

S: This one's easy to check, and to use as a workaround if it helps.  
Simply toggle that setting, as mentioned above, in the view menu, body 
pane submenu. =:^)

5) It's a gtk3 problem.  While pan has nominally been ported to build and 
use gtk3 instead of gtk2 for many years now, a gtk2-based build is still 
very much recommended as there continue to be various strange and 
unresolved bugs reported by folks running pan built against gtk3.  Of 
course the bugs remain unresolved because the users with enough knowledge 
to fix them simply build pan against gtk2 as recommended when the find 
such a bug, instead of bothering to trace it down and develop and submit 
a patch for it, but there you have it.

If you're running a gtk3-based pan-build, this is very likely one of 
those "strange and unresolved" gtk3-related bugs!  I'd definitely call 
this the prime suspect if your pan is gtk3 based.

S: Build pan against gtk2, not gtk3.  Or either find and fix the gtk3 
related bug, submitting a patch as appropriate, or file it with your 
distro building it against gtk3 so hopefully they will either find and 
fix the bug and submit a patch, or switch back to building against gtk2.  

(FWIW, firefox being in the position it's in, even if chrome/chromium is 
gaining share, with it still gtk2-based by default, few distros will 
remove gtk2 entirely, tho they might well deprecate it, building what 
they can against gtk3 and making gtk2 a dependency only installed if 
firefox or other remaining gtk2-based packages are installed to pull it 
in.)

6) Something else I didn't think of?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman