On Monday, December 13th, 2021 at 2:51 AM, Dominik Vogt <dominik.v...@gmx.de> wrote:
> I've committed a patch to master that truncates out of range sizes > and positions to the max/min values instead of rejecting them. Yes, it is ok now. > Is there anything else in your config that's out of range? The X > protocol is limited to 16 bit values for positions (signed) and > window sizes (unsigned). I.e. -32768 to +32767 and 0 to 65535. It appears that on "Restart" Front Panel ends up in the +0 +0, upper left corner of the screen. It starts ok, it is placed at the bottom center part, but something relocates it in the last moment. I remember we had this problem often introduced and then fixed again. Now it seems that "All (FrontPanel,CirculateHit) PlaceAgain" is causing the problem. That is, it behaves differently that on fvwm3 1.0.4 and fvwm 2.6.9. It looks like PlaceAgain is ignoring Style for panel: PositionPlacement $[infostore.frontpanel.pos.placement] ... where infostore.frontpanel.pos.placement is "screen c 50-50w -0p ewmhiwa" hardcoding this in styles instead of infostore variable doesn't change this. A bit of more diagnostic: If I execute PlaceAgain with FvwmCommand from terminal in this branch, Front Panel (FvwmButtons) ends up on +0 +0. If I execute "Move screen c 50-50w -0p ewmhiwa" it ends up where it needs to be. > -32768 is probably the better choice for "out of view" windows. > Fvwm doesn't use negative coordinates. Thanks, I will make it like that. Now if I can only remember what I need to test, and what behaviour to expect from the FvwmPager. :-) I have set it up on two monitors now, and it looks consistent on the both screens with and without "Monitor" setting. When without "Monitor" setting, it shows both screens and it is horizontaly wide. I have tried with DeskTopScale too, it is ok. -- Miroslav
