-
-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple Pages (3x3) and RandR is confusing and broken #17
Comments
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 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, " Some URI scheme for proper adresing is really needed. Like fvwm://desk/page/screen ... |
I think I've managed to fix this with commit: d1f2678 Please give this a try. This is still on the In terms of the expanded variables, I'll consider it. But see also: https://github.com/fvwmorg/fvwm3/blob/master/dev-docs/NEW-COMMANDS.md -- which are just some thoughts. |
When moving between pages, where DesktopConfiguration is per-monitor, skip over those windows which aren't on the current monitor. This fixes the pathological case, but likely breaks the Scroll command. Goes someway to helping to address #17
Wow! Looks like you got it. Cannot make it to break. Sorry, no gdb backtrace nor video for you this time. Congrats! :) I have read it. I know this is draft with throughts and ideas. This is exactly some URL scheme for addressing windows with full "path", plus pages which are in my opinion too useful powerful concept of sub-desks to die. Now it looks like there is a way to get it to work. Ok, not all is 100% ok after Restart. I have found windows from Virtual-0 on Virtual-1 (When 1 0 is selected on Virtual-0, 1 1 from Virtual-0 was visible on Virtual-1). But if it worked before Restart FVWM command, the path (and math) is probably already here, and this are glitches. It has become a bit hard to open 4 x 2x2 on Virtual-0 and the same amount of windows on Virtual-1 manually. In the evening when I catch a time, will make some Func to "walk" all this, then open some window (xterm) with screen,desk,pagex,pagey indicator file in less, make a control with stderr debug output, then I will repeat Restart and will send you a results. P. S. |
@NsCDE - Thanks! The reason why strange things happen on Would you mind opening a separate issue with regards to the Thanks. |
Ok, we will open separate one. But at the evening when I make detailed tests. Now there is too much noise at work around me and human error or wrongly transferred observation risk is high. :) |
Closing this per: d1f2678 which fixes this issue. Will reword the commit message later on. |
When moving between pages, where DesktopConfiguration is per-monitor, skip over those windows which aren't on the current monitor. This fixes the pathological case, but likely breaks the Scroll command. Goes someway to helping to address #17
If
FVWM3
is configured with >1 monitor and the following configuration:... and
FvwmPager
is 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,
FvwmPager
has the ability to move windows around within the pager usingAlt + mouse button 3
to other pages/desks.Because tracking windows on monitors uses their
x/y
position on screen, withDesktopSize 1x1
the bounding page is within the configured monitor's coordinates as given by RandR. But withDesktopSize 3x3
the x/y positions of windows as changed throughFvwmPager
will 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
FvwmPager
when it draws windows, doesn't limit itself to one monitor (but rather, all monitors), it's perfectly possible to drag a window from withinFvwmPager
and 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
DesktopSize
is 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
FvwmPager
to 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 2162
are 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!
The text was updated successfully, but these errors were encountered: