For the sake of making place for FvwmPager which will have it’s size calculated with DeskTopScale, which can sometimes be 12, 14, 16, 18 etc I need to know in advance what will be that values if I know DeskTopScale value.
By looking into fvwm3/modules/FvwmPager/x_pager.c around line cca 712-715 I see this definitions:
Now, If my screen width is 1920, pages are 2x2, and DeskTopScale of FvwmPager 14, then this calculation should be: (2 * 1920 * 2) / (14 + 2) = 480. However, according to xwininfo or FvwmIdent, in reality it will be 497. I have tried with other DeskTopScale factors too. It sometimes “around” (like when is 16), but calculation from shell does not match this from the code.
For height it is probably even harder, because label_h is a additional value of label, but also as width, manual calculation doesn’t function either.
What am I doing wrong? Is there a way to get width and height in pixels back from DeskTopScale?
Your order of operations doesn’t match the code. You don’t divide by (14 + 2), you added parenthesis which are not there. With those numbers that formula will compute (2 * 1920 * 2)/14 + 2 = 550. Now after this computation the size is adjusted slightly to ensure that each page has the exact number of pixels. Since you have 4 total pages (2 pages and 2 desks) the size must be a multiple of 4 plus 1 (due to the 1-pixel boundary between desks), so the initialize width in your case would be int((550 - 1)/4)*4 + 1 = 549. But as you pointed out this is not the case.
So I decided to try to debug this some, and the code you posted is correctly computing the initial size. So the size is set according to that formula (then slightly adjusted a few pixels) when the function initialize_pager() is run.
Now somewhere during the creation of the window the function Reconfigure() gets called, and by the time this function is called the width has changed (it is less than the value calculated in initialize_pager()`). So in mapping the window the size is not the same as is computed by that formula.
I am not quite sure what is going on, but in the creation of the window something is making the window smaller than the initial size that is computed, and thus is unpredictable. Maybe Thomas can better track down why this is the case, but right now I don’t see it in the FvwmPager code.
As for having a more predictable pager size, you could use InitialMapCommand to Resize the pager to fit the computation. Maybe not ideal, but I cannot track down what is causing the window to be different size than the computations. The math is fine, but something in the mapping of the window is getting in the way (maybe file an issue, but Thomas won’t have time to look at this for a few months).
I think I tracked down the issue, but need to figure out how to fix it.
It appears that the aspect ratio isn’t being set correctly (it is slightly off), and so when the window is created, fvwm is adjusting the window size to fit the aspect ratiosetting, which is slightly shirking the pager from the calculated size. I will look into this deeper and see if I can find a fix.
Yes, this was observed also by me, I was thinking that some additional post-calculation is considering something into calculation, probably the header part of each desk, where desk title is located, and I even didn’t suceeded to spot the chaning pattern. Now I see this can also mean a bug.
It was not possible to use InitialMapCommand, because FvwmPager gets swallowd into NsCDE implementation of CDE GWM which is FvwmScript.
Even if this bug is solved, it will stay on older versions, so I decided to abadon DeskTopScale, take $[vp.width] and $[vp.height] and recalculate everything on this basis to get things to work out of the box. Here it is: https://github.com/NsCDE/NsCDE/blob/master/NsCDE/libexec/GWM.sh
Nevertheless, if you need additional info or to debug something, I can jump in and test. My intuitive suspition lays on title header beeing substracted twice - because width is preserved well, and pager only shinks in height … someware near the size of the bar for desk title.
I don’t need any additional information, the issue is with the size hints, and for some reason fvwm gets confused. If I remove the hints, the issue goes away. So all the computations are working just fine. I just am not sure what fvwm is doing when placing the window to recalculate the size if aspect ratio size hints are applied.