IconMan GROW_UP window moves upwards when shrinking by >1 button

[sam6816]

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.

[ThomasAdam]

Hi @sam6816

Can you try sending me a PR to address this?

[sam6816]

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)