IconMan GROW_UP window moves upwards when shrinking by >1 button
Opened this issue · 2 comments
fvwm3 1.0.6a (released)
with support for: ReadLine, XPM, PNG, SVG, XShm, XRandR, XRender, XCursor, XFT
I am running it on archlinux.
Expected Behaviour
Well I configured a FvwmIconMan module to show only icons and to grow upwards. I also made some iconify and deiconify menu functions, so I can eg. deiconify all on the current page.
I want to place the IconMan at the bottom of the screen and then to stay there.
Actual Behaviour
With fvwm3 the problem is (only?) when I do:
+ "&Open all" All (iconic, CurrentPage, !Fvwm*) Iconify false
With 10 buttons=iconic windows the top edge does move back down, but only by 1. The bottom edge moves up by 8 or so.
Enabling logging: oh so that is how it works?
Steps to Reproduce:
GROW_UP ie. neg. y-geometry is needed, plus a empty-IconMan-at-once conditional command.
Place the lower edge at a special point, or do it with a dozen windows/buttons.
An empty IconMan has the same height as one with one button.
Extra Information
I saw the change from 2.6.9 to 2.7.0 about size hint warnings. Now with fvwm3 these are gone. But that new waiting loop in xmanager.c has a high counter. I put some stderr-fprintfs there to see what is going on. I reduced the counter from 20000 to 500.
I place the IconMan at y -55 to have the y coordinate "1000".
starting
size_manager page ICONS: 1120 1005 200 20
queried: y: 1000, h: 20, queried: 20
counter:500 20 20
after:500 20 20
queried: y: 1000, h: 20, queried: 20
counter:500 20 20
after:500 20 20
iconify manually
queried: y: 1000, h: 40, queried: 20
counter:500 20 40
after:481 40 40
queried: y: 980, h: 60, queried: 40
counter:500 40 60
after:491 60 60
deiconify manual
queried: y: 960, h: 40, queried: 60
counter:500 60 40
after:488 40 40
queried: y: 980, h: 20, queried: 40
counter:500 40 20
after:486 20 20
again manual -- is/was back to y:1000
queried: y: 1000, h: 40, queried: 20
counter:500 20 40
after:491 40 40
queried: y: 980, h: 60, queried: 40
counter:500 40 60
after:489 60 60
queried: y: 960, h: 40, queried: 60
counter:500 60 40
after:490 40 40
queried: y: 980, h: 20, queried: 40
counter:500 40 20
after:490 20 20
now iconify all 3 with cond. command All (Raised,...)
queried: y: 1000, h: 40, queried: 20
counter:500 20 40
after:0 20 40
queried: y: 1000, h: 60, queried: 20
counter:500 20 60
after:0 40 60
queried: y: 980, h: 60, queried: 40
counter:500 40 60
after:490 60 60
manual deicon
queried: y: 960, h: 40, queried: 60
counter:500 60 40
after:491 40 40
queried: y: 980, h: 20, queried: 40
counter:500 40 20
after:486 20 20
man icon 2x
queried: y: 1000, h: 40, queried: 20
counter:500 20 40
after:485 40 40
####deicon
queried: y: 980, h: 20, queried: 40
counter:500 40 20
after:485 20 20
man icon: 3 windows = 2 additional buttons
queried: y: 1000, h: 40, queried: 20
counter:500 20 40
after:484 40 40
queried: y: 980, h: 60, queried: 40
counter:500 40 60
after:488 60 60
now...
all DE-icon with cond. command = shrink the man-window at once
queried: y: 960, h: 40, queried: 60
counter:500 60 40
after:0 60 40
queried: y: 960, h: 20, queried: 60
counter:500 60 20
after:0 60 20
#here the window has moved upwards to 980
man. icon.: should be at y:1000
queried: y: 980, h: 40, queried: 20
counter:500 20 40
after:489 40 40
The "after:0 60 20" means even after the waiting loop the two don't match.
Mathematically speaking it shouldn't be hard to get "1000" with 960, 60 and 20. But I see this GROW_UP flag is tricky.
Hi @sam6816
Can you try sending me a PR to address this?
Not directly I'm afraid...I guess "PR" is pull request, so doesn't that mean you are expecting a (first) fix from me?
(sorry I don't check my email every day)