Problems dragging windows on "wide" desks, multiple monitors, multiple pagers
Closed this issue · 10 comments
fvwm3 1.1.0 (1.0.9-77-g94da9d16)
with support for: ReadLine, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, XRandR, XRender, XCursor, XFT, NLS
Linux 6.9.6-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jun 21 15:48:21 UTC 2024 x86_64 GNU/Linux
I've always used Zaphod heads and one fvwm per :display:screen. Giving non-zaphod a try and still not convinced the extra confusion is worth the ability to move windows across screens, but I digress. The reason to mention this is that the problem described below does not happen on the zaphod split screen configuration (well, it can't).
My fvwm pager layout has always been 3 x number of F, i.e. show 3 rows (desks -1, 0, and 1), and columns/pages used to be 1 through 8 when keyboards only had 8 function keys, and now 1 through 12. I can move to page/column , with key binding Alt-F.
At home I have two 1920x1080 monitors side by side (left/right), and a pager showing a grid with 3 rows of 12 columns, one pager per monitor.
First problem:
If I create a window, say xterm, on say 0/0, left monitor, the left pager shows it correctly. When I drag, with middle button, the window horizontally to page 0/1, 0/2 ..., etc, the window moves and is mapped into that page correctly, that is until I try to go into 0/10. At that point the windows shows up in the right monitor's pager at 0/9 and it is mapped there. Same if I dragged it in the left monitor's pager to 0/11 or 0/12. And if I drag it in the right monitor's pager to 0/10, 0/11 and 0/12, it goes back to 0/9, right monitor. Fvwm3 log shows: GetOnePositionArgument: new position is out of range: 38692. If I click on page 0/10 on the left monitor and start an xterm via a menu, the window shows up there.
Second problem::
If I drag a window itself (i.e. not on the pager) on the left monitor and drag it to the right monitor (again, not possible on zaphod) the window is always shown in the left pager (when at some point it could be half on the left, half on the right). If Iet it go it disappears from the left pager, shows up in the right pager and thinks seems fine. If instead of letting go, I keep going, the window does keep going on the right monitor eventually showing up half in both monitors, but never reentering the left monitor at the left edge, and keeps going through pages of the right monitor until I left go of the drag. There doesn't seem to be a way to drag a window one "page to the right on the left" monitor.
Hi @ileGITimo,
First problem:
If I create a window, say xterm, on say 0/0, left monitor, the left pager shows it correctly. When I drag, with middle button, the window horizontally to page 0/1, 0/2 ..., etc, the window moves and is mapped into that page correctly, that is until I try to go into 0/10. At that point the windows shows up in the right monitor's pager at 0/9 and it is mapped there. Same if I dragged it in the left monitor's pager to 0/11 or 0/12. And if I drag it in the right monitor's pager to 0/10, 0/11 and 0/12, it goes back to 0/9, right monitor. Fvwm3 log shows: GetOnePositionArgument: new position is out of range: 38692. If I click on page 0/10 on the left monitor and start an xterm via a menu, the window shows up there.
I suspect this is down to the resolution you're using across all of your screens, including the virtual screen size of having an NxM pager (whatever your DesktopSize is set to).
Over certain values, the pager will show coordinates of windows which will have "wrapped around", and will therefore be incorrectly shown in the pager as being in the wrong place.
As to your second problem -- I'm struggling to visualise this. If you'd be willing to make a small video on this, that might help.
First a correction to the above! Pages are 0/0 through 0/11 not 0/12, obviously. Thus I can't drag from the pager into pages 0/9, 0/10 and 0/11.
The position out of range comes from the fvwm_debug call on line 664 of fvwm/move_resize.c, where final_pos is greater than MAX_X_WINDOW_POSITION, which is an int 16 defined in lib/defaults.h as 32767.
At that point the code instead of using a position as page_relative (+ page position) uses the absolute virtual position which can be much larger. E.g. I just moved to page 0,11 opened an xterm, moved to page 0/0, called WindowList which shows an x virtual position of almost 43000.
The position out of range comes from the fvwm_debug call on line 664 of fvwm/move_resize.c, where final_pos is greater than MAX_X_WINDOW_POSITION, which is an int 16 defined in lib/defaults.h as 32767.
Which is what I suspected would be the case (see above). I'll have to check with X11 if we can increase this to a 32 or 64 bit integer.
I suspect this is down to the resolution you're using across all of your screens, including the virtual screen size of having an NxM pager (whatever your
DesktopSizeis set to).
My DesktopSize is 12x1. I'm going to try this on my still zaphod configuration at work and a DesktopSize of 20x1 to overflow 2^15-1. This being all virtual, I should be able to keep on dragging to the right to my heart's content until I reach 2^63-1 these days, shouldn't I?
As to your second problem -- I'm struggling to visualise this. If you'd be willing to make a small video on this, that might help.
I'll try to see if OBS still works with this setup.
Which is what I suspected would be the case (see above). I'll have to check with X11 if we can increase this to a 32 or 64 bit integer.
It is conflicting me that I can place a window there, but not drag it there.
As to your second problem -- I'm struggling to visualise this. If you'd be willing to make a small video on this, that might help.
Attached video is my attempt to move the window one page to the right on the left screen.
dragging.mp4
Went into move_resize_position and commented out the coercing of the position to be between - and + MIN/MAX_X_WINDOW_POSITION, and now I can drag the pager icon to pages with virtual positions larger than those values.
No longer familiar with the code beyond some 1.x version. Is there a case where GetOnePositionArgument can cause fvwm to try and map a window beyond xlib limits?
(Also tried to compile the head revision, 1.1.1, and it broke my pagers badly upon restart. (Maybe it will work from scratch but I can't go there now) My pager went from showing -1, 0, 1 to only showing 0,1 and all images ended up in desk 0. Went back to 1.1.0)
Hi @ileGITimo
Was there any conclusion on this?
Behavior with today's clone of fvwmorg/fvwm3 and ilegitimo/fvwm3, which includes all my closed pull requests.
This is strictly for the X/Y WINDOW POSITION placement. Still can't drag right from the right monitor into the left monitor, which is quite different from zaphod.
wide-desktop.mp4
This is just an example of the "wrap-around" fvwm has in connection with virtual-screens.
Not sure there's much that can be done here.