NsCDE
commented
4 years ago Hello Thomas,
I have put DesktopConfiguration per-monitor, avoided bug #19 and tried to figure out how is this even meant to work. In short, please provide some explanation or documentation draft. I have read doc/commands/DesktopConfiguration.xml, and it has one sentence, and my experience things are very confusing in the present clone of the ta/desktops.
Observation: when pointer is on one screen and I change desk, windows from the other screen are still visible - that's ok, like, it is still on the old desk.n/page.nx/page.ny combination. But if I put "sleep 5 && FvwmCommand 'Echo $[desk.n] $[page.nx] $[page.ny]" on the terminal in left screen, and change desk/page on the right screen (BTW, copied FvwmCommandS from 2.6.9, I'm lost without FvwmCommand), this Echo will show on stderr that desk and page also changed for left screen. Additionally, FvwmBacker is likely agnostic about screens presently, and $[screen] parameter is not expanded anymore.
In desk 0, pages 0 0, I have x terminal and gvim. If I bring "FvwmPager 0 3" and navigate around, then move pager with pointer to other screen and back, x terminal and gvim will somehow end up from page 0 0 to page 0 1 (from top left to bottom left), and Echo confirms this. After navigating around, some windows are lost - visible in pager, but can be accessed only via WindowList again.
Maybe it will be better if I make screen(s) capture of two screens with ffmpeg and upload someware mp4 video for visual inspection. I can do it later.
About this problem itself, from my currently limited view of this problem:
Can some page "tagging" be introduced once desks+pages configuration is known? From physical screen geometry, it is known where every page is, so in addition to "0 0", "0 1", "1 1" etc, "0 0 @1", "0 1 @1", "1 1 @2" can be introduced? Where @X is a monitor number as optional 3rd parameter, and something which is attached to every window, and orientation for FvwmPager to which screen window belongs? This tag should then be changed if window changes the screen, and for halved windows, active screen is where more than 50% of it resides, etc ...
Some URI scheme for proper adresing is really needed. Like fvwm://desk/page/screen ...
ThomasAdam
If
FVWM3is configured with >1 monitor and the following configuration:... and
FvwmPageris started with the following, to match the number of configured desktops above:Opening some terminals (xterms) will correctly assign those to the relevant screen and page. However,
FvwmPagerhas the ability to move windows around within the pager usingAlt + mouse button 3to other pages/desks.Because tracking windows on monitors uses their
x/yposition on screen, withDesktopSize 1x1the bounding page is within the configured monitor's coordinates as given by RandR. But withDesktopSize 3x3the x/y positions of windows as changed throughFvwmPagerwill be far greater than the physical dimensions of the given monitor, because pages are additions to the configured screen.So the question becomes, how can we ensure when a window is on a given page, that the correct monitor is assigned, given that the x/y dimensions aren't going to match?
Indeed, because
FvwmPagerwhen it draws windows, doesn't limit itself to one monitor (but rather, all monitors), it's perfectly possible to drag a window from withinFvwmPagerand have it move to a different page and monitor. How are we going to ensure the correct monitor is picked up?Part of the problem is that because
DesktopSizeis the same for all outputs, trying to use$[desk.width]and$[desk.height]won't work, as these dimensions will be the same across monitors.For instance, when dragging a window in
FvwmPagerto a different page, you'll see in the logs:The geometry of the window is valid, but in this case, the window has not only changed page, but also desk to what it was on originally. This is because
9462 x 2162are on the page that represents a different monitor, but there's no way of mapping that back to the physical dimensions of the monitor itself.Suggestions welcomed on how we can solve this!