-
-
Notifications
You must be signed in to change notification settings - Fork 83
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
Position of windows on screens, desks and pages is not accurate after FVWM 3 Restart #20
Comments
Start writing out monitor information in to the state file, and provide a monitor output helper function to do this. Using monitor output IDs rather than a monitor name is more consistent. This is the beginning of addressing issue #20
Start writing out monitor information in to the state file, and provide a monitor output helper function to do this. Using monitor output IDs rather than a monitor name is more consistent. This is the beginning of addressing issue #20
I have compiled this last one and tested: I'm afraid that we have some regression here. With 2x2 DesktopSize, after opening window of each page, and going back to 0 0, on secondary screen Virtual-1, window from page "1 0" is visible, and when that page/window is selected on Virtual-0, on Virtual-1 "1 1" page is visible. Consistent on all desks. Video: https://youtu.be/154CtQpZcsg About restart: all windows are concentrated on current screen+desk, page 0 0, on the same geometry position, one below another. Attach 1: FVWM test function used |
Notice: in fvwm-func-test-scr-dsk-page.txt "Virtual-0" should be replaced with $[pointer.screen]. My omission. Luckily, this doesn't change result of my testing (see video), because pointer has been on screen Virtual-0. I repeated tests and it shows the same output. Looks like "left side" of the pages is reproduced on another screen. Notice 2: When testing with pointer on another screen, which is --right-of Virtual-0, nothing wrong is reproduced on Virtual-0. |
Hi, Thanks -- I'm going to take a look at this now. The function you wrote is really useful for testing, so I'll be using that! |
When handling page coordinates, irrespective of the setting for DesktopConfiguration, always use the combined widths and heights for the attached monitors. Because pages have to handle mapped windows (that is, unlike switching desks, windows are not unmapped), when switching pages, windows are moved in/out of view, depending on the page (rectangle) which is coming in to view. In the case of DesktopConfiguration being 'per-monitor', we want to still use the global screen; those windows on different monitors which aren't on the monitor we're actively paging for, will still be ignored. This should go someway to addressing #20.
Right... Please can you take a look at the commit (d23ff5c) which I've just pushed to I've tested this only lightly, so please do give it your usual rigorous testing! Thanks. |
Start writing out monitor information in to the state file, and provide a monitor output helper function to do this. Using monitor output IDs rather than a monitor name is more consistent. When loading the state file back in, move the call after monitors have been initialised so that the monitor matching can work correctly. This addresses issue #20
When handling page coordinates, irrespective of the setting for DesktopConfiguration, always use the combined widths and heights for the attached monitors. Because pages have to handle mapped windows (that is, unlike switching desks, windows are not unmapped), when switching pages, windows are moved in/out of view, depending on the page (rectangle) which is coming in to view. In the case of DesktopConfiguration being 'per-monitor', we want to still use the global screen; those windows on different monitors which aren't on the monitor we're actively paging for, will still be ignored. This should go someway to addressing #20.
Hi Thomas, There are no xterms from screen 0 on 1 and vice versa, but now we have another interesting situation: static information for pages and dynamic ($[page.nxy]) are out of sync. Somehow, page number 2 find it's place in DesktopSize 2x2 configuration, shift of static and dynamic information is not the same on Virtual-0 and Virtual-1. Attachment 1: f_TestSDP FVWM function that I used: revisited for more readable information. Starts with screen argument because of comparation with dynamic information (example: f_TestSDP Virtual-0). Attachment 2: screenshot with the WindowList after running f_TestSDP on both screens. From the window name, (all which starts with "echo STATIC") I think clear review can be made. |
I also think I've fixed the restart issue -- can you check that as well? I'll take a look at the page offset problem. |
Restart: nope, not yet. All xterms are concentrated on desk 0, pages 0 0. |
Really? That's weird; restarts are working fine for me. Can you take a screencast? |
When handling page coordinates, irrespective of the setting for DesktopConfiguration, always use the combined widths and heights for the attached monitors. Because pages have to handle mapped windows (that is, unlike switching desks, windows are not unmapped), when switching pages, windows are moved in/out of view, depending on the page (rectangle) which is coming in to view. In the case of DesktopConfiguration being 'per-monitor', we want to still use the global screen; those windows on different monitors which aren't on the monitor we're actively paging for, will still be ignored. This should go someway to addressing #20.
OK, please try again -- I've squashed in a fix for reporting the correct pages for
|
Page indicators are now back in sync. |
Thanks -- looking forward to watching that. Just to recap then:
What about:
|
Actually, while checking for your point 3, I have found that I have 64 xterms opened instead od 32. Looks like Restart is half working, because on other pages there are initial xterms which are belonging there according to info text in them. It just happens that on restart xterm windows are duplicated, but not that of the mate-terminal (one per screen is opened on d0 p 0 0).
I'm testing it like that. I add monitor while fvwm is active and turn it on with xrandr - as I have captured on video and describet in past issues. For DesktopConfiguration global, I will test in the morning. Have really to go to sleep now. :) |
For a DesktopConfiguration global: Case monitor added during FVWM session: Case second monitor exists during login: Must go now, no time for screencast next 8 hours, use latest version of my function to test on DesktopSize 2x2, who knows how it will be on different setup. |
Let me sumarize my last two posts:
|
OK. I'll concentrate on the restart issues for now. Thanks! |
Start writing out monitor information in to the state file, and provide a monitor output helper function to do this. Using monitor output IDs rather than a monitor name is more consistent. When loading the state file back in, move the call after monitors have been initialised so that the monitor matching can work correctly. This addresses issue #20
When handling page coordinates, irrespective of the setting for DesktopConfiguration, always use the combined widths and heights for the attached monitors. Because pages have to handle mapped windows (that is, unlike switching desks, windows are not unmapped), when switching pages, windows are moved in/out of view, depending on the page (rectangle) which is coming in to view. In the case of DesktopConfiguration being 'per-monitor', we want to still use the global screen; those windows on different monitors which aren't on the monitor we're actively paging for, will still be ignored. This should go someway to addressing #20.
Hi @NsCDE, Please can you update your repository:
... and try again? I've tested with your scripts, and things seem to be working correctly now. I've tried with both |
Hi Thomas, Ok, situation is this:
|
Hi @NsCDE, Cool. Plesee open separate issues for your other observations, and I really appreciate your scripts, so any minimal configs I can use would really help me. What I'll do is merge the changes to master and go from there. |
As for FvwmPager, I'm well aware of that. :-) |
Start writing out monitor information in to the state file, and provide a monitor output helper function to do this. Using monitor output IDs rather than a monitor name is more consistent. When loading the state file back in, move the call after monitors have been initialised so that the monitor matching can work correctly. This addresses issue #20
When handling page coordinates, irrespective of the setting for DesktopConfiguration, always use the combined widths and heights for the attached monitors. Because pages have to handle mapped windows (that is, unlike switching desks, windows are not unmapped), when switching pages, windows are moved in/out of view, depending on the page (rectangle) which is coming in to view. In the case of DesktopConfiguration being 'per-monitor', we want to still use the global screen; those windows on different monitors which aren't on the monitor we're actively paging for, will still be ignored. This should go someway to addressing #20.
As subject tells.
Preliminary observation:
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) after 'Restart'.
According to conversation on #17 state from temporary file is read by FVWM on restart, but at that point, FVWM doesn't understand anything about monitors.
I will make more detailed tests later ...
The text was updated successfully, but these errors were encountered: