Skip to content
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

Closed
NsCDE opened this issue Jan 21, 2020 · 19 comments
Assignees
Labels
type:bug Something's broken!

Comments

@NsCDE
Copy link
Contributor

NsCDE commented Jan 21, 2020

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 ...

ThomasAdam added a commit that referenced this issue Jan 21, 2020
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
ThomasAdam added a commit that referenced this issue Jan 21, 2020
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
@NsCDE
Copy link
Contributor Author

NsCDE commented Jan 21, 2020

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
Attach 2: non-unlinked .fs-restart from $FVWM_USERDIR

fvwm-func-test-scr-dsk-page.txt
fs-restart.txt

@NsCDE
Copy link
Contributor Author

NsCDE commented Jan 22, 2020

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.

@ThomasAdam
Copy link
Member

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!

ThomasAdam added a commit that referenced this issue Jan 23, 2020
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.
@ThomasAdam
Copy link
Member

ThomasAdam commented Jan 23, 2020

Right...

Please can you take a look at the commit (d23ff5c) which I've just pushed to ta/fix-gh-20, please? I think I've addressed the problem of moving windows (the WIP of getting windows/pages in the correct position after a reboot is still something I'm working on).

I've tested this only lightly, so please do give it your usual rigorous testing!

Thanks.

ThomasAdam added a commit that referenced this issue Jan 23, 2020
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
ThomasAdam added a commit that referenced this issue Jan 23, 2020
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.
@NsCDE
Copy link
Contributor Author

NsCDE commented Jan 23, 2020

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.

f_TestSDP.txt

f_TestSDP-WindowList

@ThomasAdam
Copy link
Member

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.

@NsCDE
Copy link
Contributor Author

NsCDE commented Jan 23, 2020

Restart: nope, not yet. All xterms are concentrated on desk 0, pages 0 0.

@ThomasAdam
Copy link
Member

Really? That's weird; restarts are working fine for me. Can you take a screencast?

ThomasAdam added a commit that referenced this issue Jan 23, 2020
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.
@ThomasAdam
Copy link
Member

OK, please try again -- I've squashed in a fix for reporting the correct pages for $[page.nx] $[page.ny]. Just in case, please update as:

git fetch
git checkout ta/fix-gh-20
git reset --hard @{u}

@NsCDE
Copy link
Contributor Author

NsCDE commented Jan 24, 2020

Page indicators are now back in sync.
I'm producing screencast for Restart ...

@ThomasAdam
Copy link
Member

Thanks -- looking forward to watching that. Just to recap then:

  1. Restarts are still broken -- will fix
  2. Page indicators are now fixed;
  3. GotoPage with DesktopConfiguration per-monitor is fixed?

What about:

  • DesktopConfiguation global? Is that doing the same thing across all monitors?
  • What happens if you add an additional monitor while fvwm is running? Do things continue to still work correctly?
  • I know that removing a monitor is broken -- I need to rework that as as a configurable function, but find a sensible default.

@NsCDE
Copy link
Contributor Author

NsCDE commented Jan 24, 2020

  1. Here is the screencast for restart after all desks and pages are filled with xterms with usual info: https://youtu.be/FzHkJg0WieY

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).

  1. They are accurate now, yes.

  2. Looks like it is.

What happens if you add an additional monitor while fvwm is running? Do things continue to still work correctly?

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.
Actually, now when you have mentioned this, I have tested by logging in while both monitors are on, and xterm for 0 0 ends up on 0 1, xterm for 1 0 end up on 1 1, and 1 1 who knows where and 0 0 is empty. Catching 1 1 with WindowList selects empty place on 0 0.

For DesktopConfiguration global, I will test in the morning. Have really to go to sleep now. :)

@NsCDE
Copy link
Contributor Author

NsCDE commented Jan 24, 2020

For a DesktopConfiguration global:

Case monitor added during FVWM session:
It behaves correctly for screen 0, but but if windows from the screen 0 are left opened, test on screen 1 passes ok for desk 0, but when moving to desk 1, suddenly like there is no "Wait" in a function, it starts to open all xterms on the first screen to the end of function.

Case second monitor exists during login:
Same as when added during FVWM session (test on screen 1 breaks Wait after 1st desk is populated), including page shift same as with per-monitor which I described 5 hours ago: "0 0" is empty, "1 0" gets xterm for "0 1", "0 1" gets xterm for "0 0", and "1 1" gets xterm for "1 0", desk 1 page "0 0" gets xterm for desk 0, page "1 1", desk 1 "1 0" gets xterm for "0 1", desk 1 "0 1" for desk 1 "0 0" ... and that order goes to the end.

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.

@NsCDE
Copy link
Contributor Author

NsCDE commented Jan 24, 2020

Let me sumarize my last two posts:

  1. Only accurate thing presently for me is DesktopConfiguration per-monitor when secondary screen is turned on and configured during active FVWM3 session. If second screen is active prior to FVWM3 start, page shift described above occurs.

  2. For DesktopConfiguration global, both prior and after FVWM3 monitor states are currently inaccurate, as described above - it speeds up after desk 0 and places everything on the 0 0 page, plus page shift if monitor was active prior to FVWM3 startup.

  3. Restart duplicates xterm windows. Even if working with one monitor. But if I try with gvim on page 1 1 on desks 1 2 3, Restart will concentrate them all on desk 1.

@ThomasAdam
Copy link
Member

OK. I'll concentrate on the restart issues for now. Thanks!

@ThomasAdam ThomasAdam self-assigned this Jan 24, 2020
@ThomasAdam ThomasAdam added the type:bug Something's broken! label Jan 24, 2020
ThomasAdam added a commit that referenced this issue Jan 28, 2020
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
ThomasAdam added a commit that referenced this issue Jan 28, 2020
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.
@ThomasAdam
Copy link
Member

Hi @NsCDE,

Please can you update your repository:

git fetch
git checkout ta/fix-gh-20
git reset --hard @{u}

... and try again? I've tested with your scripts, and things seem to be working correctly now. I've tried with both global and per-desktop. There's a lot of moving parts here though, so I'm assuming I'll have broken something else along the way. :)

@NsCDE
Copy link
Contributor Author

NsCDE commented Jan 28, 2020

Hi Thomas,

Ok, situation is this:

  • Positions of windows (test: xterms) on screen on restart are now correct. There is no duplication nor inconsistencies. Looks like we can move to some other issue, since subject of Position of windows on screens, desks and pages is not accurate after FVWM 3 Restart #20 looks like fixed, but this other issues below should be then continued someware. Should I open new issue?

  • f_TestSDP works ok in one screen mode, in two screens mode it is working ok if second screen is added during FVWM3 session with xrandr, but if FVWM3 is restarted (or logout + login with secondary screen on), pages are still shifted: after f_TestSDP, on "0 0" there is nothing. On "0 1" tthere is "0 0", on "1 0" there is "0 1", and on "1 1" there is "1 0" - after another Restart, xterm from desk 3, page "1 1" is positioned on desk 0, page "0 0" but iconified. Same behaviour is observed in global and per-monitor mode. If second screen is forced --off with xrandr and FVWM3 restarted, f_TestSDP works again - until FVWM3 is restarted with secondary screen on. This occurs no matter on which page I'm positioned with terminal from which I call f_TestSDP. Screenshot attached here shows window list on Virtual-0 after running f_TestSDP in such conditions. In working state, window list is correct. Probably some buffer must be cleared or shifted back ... you will see this from the order on window list.
    Screenshot2

  • In global mode, f_TestSDP speeds up after finishing on desk 0, probably "Wait XTerm" is observing some other existing xterm mappig or moving. If I kill xterms from Virtual-0 prior to testing on Virtual-1, this "speedup" does not occur.

  • FvwmPager is not functional currently, other modules (like Backer) are not aware ... but this is probably you already know.

@ThomasAdam
Copy link
Member

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.

@ThomasAdam
Copy link
Member

As for FvwmPager, I'm well aware of that. :-)

ThomasAdam added a commit that referenced this issue Jan 28, 2020
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
ThomasAdam added a commit that referenced this issue Jan 28, 2020
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.
@ThomasAdam ThomasAdam moved this to Done in FVWM3 Sep 18, 2022
@ThomasAdam ThomasAdam added this to FVWM3 Sep 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:bug Something's broken!
Projects
Status: Done
Development

No branches or pull requests

2 participants