In global DesktopConfiguration mode, Wait XTerm fails after changing current desk from 0 0 to 0 1

[NsCDE]

While testing with f_TestSDP in "DesktopConfiguration global" mode, everything works on 1st screen. On second screen it works until desk is changed. In that moment pages "0 0", "0 1", "1 0" are omitted by Wait, and all 4 xterms are concentrated on page "1 1".

Notice: I have tested with only with desks 0 and 1, 2 and 3 were commented out for brevity.

• In per-monitor mode, this behaviour is not reproducable.
• If there is no XTerm's on left (first) monitor (pkill xterm before running f_TestSDP on Virtual-1), this doesn't happen.

[ThomasAdam]

Hi,

I've tried, but I can't seem to reproduce this. If I set DesktopConfiguration global, with two monitors, and open FvwmConsole on the second monitor, and run the f_TestSDP function, then all windows open up on the appropriate desks and pages as I'd expect, and I can't see any problems with the Wait command.

This is tested on master. What am I not doing correctly to reproduce this, @NsCDE ?

[NsCDE]

Hi Thomas,

I belive this behaviour was introduced outside master, during this "ta/gh-20-2" session.

I have made video with this "xterm stampedo". To reproduce, conditions must be met: ta/gh-20-2, DesktopConfiguration global, and function finished on first screen with xterms left on place. If xterms on Virtual-0 are killed before running this on Virtual-1, bug will not be triggered. Beware of "ps -ef | grep xterm" on the end: it was bad match, because grep matched also "sh -c" line + one non-function xterm on Virtual-1. There are really 16 xterms on Virtual-0 and 16 on Virtual-1 (ps -ef | egrep 'xterm.*Virtual-1' | grep -v sleep | grep -v grep | wc -l), but on Virtual-1 xterms for pages on desks 1, 2 and 3 (my Two, Three and Four) are all concentrated on desk 0 (my One), page 0 0. See WinList on the end of the video.

https://youtu.be/1L3kkaZPiR8

[ThomasAdam]

Hi,

Hmm, that's weird. I'll take a look on that branch, thanks. The video definitely helps. :)

[ThomasAdam]

Hi,

@NsCDE -- hope you're well. Can you check if this bug report is still valid, by using the latest commit on ta/gh-22?

[NsCDE]

Hi Thomas,

Yeah, pretty much well. Working from home, in the same shit as the rest of the planet, plus calculating damage from nasty earthquake from 22. 3. 2020. for part of city works funds for repairs of the roof and one wall. At least optic cable from ISP is working well. :)

Let's go to business!

FvwmPager in gh-22 branch is working, altrough it is not aware of the geometry when second screen is turned on and configured until FVWM is restarted. My testing function is working ok, altrough on the end of the function, page 1 0 is visible on the right monitor, but this should be just an extension of the page 0 0 (doesn't happen after 'Restart').

After FVWM Restart command, f_TestSDP correctly places xterm windows on Virtual-0 screen, but when I repeat this on the Virtual-1, all XTerm windows are fired up fast, and end up on Virtual-0, Desk 1, page 0 0. This can be seen on my "Global Pager" configuration of the FvwmPager on the end, and even better as WindowList after that.

Here is the video of the test:
https://youtu.be/a3bHdFq0yLc

[NsCDE]

EDIT: After Fvwm Restart (with my dialog) on video, you can see how Front Panel (FvwmButtons) ended up in top right corner and I manually (Ctrl+Esc) placed it back to the bottom center of the screen. Maybe this is related to the work on #28 described by other reporters.

[ThomasAdam]

Hi @NsCDE,

Yes, this is weird. I get slightly different behaviour with Wait, in that FVWM freezes, rather than what your video shows which is to forget about the Wait command entirely.

Can you attach the latest version of your script you're using for f_TestSDP, please? Just to see if I get different behaviours?

Cheers,
Thomas

[NsCDE]

Hi Thomas,

Attaching f_TestSDP used to create latest video and f_TestSDP2 which I created now and with which this bug is not triggered. Difference is: I'm calling xterm with custom class "-name ID-$[desk.n]-$[page.nx]-$[page.ny]" and Wait-ing for "ID-$[desk.n]-$[page.nx]-$[page.ny]" instead of "XTerm". So every xterm window gets it's unique resource name. In that case, function plays to the end not only on Virtual-0, but also on Virtual-1, but I get all windows started on Virtual-0. If I run programs from Virtual-1 manually, they got started on Virtual-1, but when run f_TestSDP from FvwmCommand (copied FvwmCommandS from 2.6.9) all windows ends on Virtual-0. Even $[pointer.screen] indicates they are on Virtual-1, but my pointer was on Virtual-1.

f_TestSDP.txt
f_TestSDP2.txt

EDIT: In DesktopConfiguration per-monitor, with f_TestSDP2 function plays to the end respecting Wait's, but when pointer is on Virtual-1, nevertheless all xterms end up on Virtual-0, in per-monitor is the difference they all end up on desk 0, page 0 0.

[ThomasAdam]

Hi @NsCDE,

The problem here is that without specifying a monitor, or knowing the destination of the window we're about to place on the screen, we don't know which monitor we should move the page for.

When you don't specify a monitor, the monitor with the cursor is assumed to be the target monitor.

On ta/gh-22, I have augmented the GotoDesk and GotoDeskAndPage commands to take a monitor name, for example:

GotoDeskAndPage HDMI1 4 1 1

Would switch to desk 4, page 1 1, on screen HDMI1.

If you change your script(s) to make use of the GotoDeskAndPage command, do you get the results you should do?

It's difficult to know how to solve this properly. I suppose your script could infer that the monitor we should reference is the same monitor that we are placing XTerm on, but that's going to get very difficult to do.

So I'm not sure how to "fix" this, in that the solution is to specify the monitor you want, but I'm sure we could do better than that.

[NsCDE]

Hi Thomas,

Thomas Adam wrote:

When you don't specify a monitor, the monitor with the cursor is assumed to be the target monitor.

That's what I'm trying to tell you. Even if cursor is on the Virtual-1, window pops up on Virtual-0. Fvwm command "Echo $[pointer.screen]" correctly identifies screen on which cursor resides. Maybe we can move this as different / separate issue?

On ta/gh-22, I have augmented the GotoDesk and GotoDeskAndPage commands to take a monitor name, for example:

GotoDeskAndPage HDMI1 4 1 1

Would switch to desk 4, page 1 1, on screen HDMI1.

Good, but I will like to propose two things here:

1. Introduce new command for this kind of addressing. For example GotoDeskPageAndScreen. For the existing GotoDeskAndPage, GotoDesk and GotoPage, default should be $[pointer.screen].

2. Since screen is the last logical component in FVWM, maybe it should probably be specified on the end, after desk and page, for the consistency and uniformity.

If you change your script(s) to make use of the GotoDeskAndPage command, do you get the results you should do?

I'm attaching you f_TestSDP3 and f_TestSDP4. They use GotoDeskAndPage with monitor name as you proposed. f_TestSDP3 is specifying custom unique resource name for xterm windows, while f_TestSDP is not.

• DesktopConfiguration per-monitor: both functions are played to the end without forgetting about Wait. All windows are placed on Virtual-0, even if cursor is on the Virtual-1.

• DesktopConfiguration global: f_TestSDP3 plays to the end and Wait is respected, while f_TestSDP4 plays (as usual) to the end of desk 0, and after 0 1 1 when it must go to the 1 0 0, forgets about Wait and fires all xterms simultaneously. All windows are placed on Virtual-0, no matter if I put mouse cursor on the Virtual-1 before performing function for that screen.

It's difficult to know how to solve this properly. I suppose your script could infer that the monitor we should reference is the same monitor that we are placing XTerm on, but that's going to get very difficult to do.

To me it looks like window placing from function somehow cannot read $[pointer.screen], but echoed text inside xterm (after word DYNAMIC) clearly indicates that this part of fvwm3 knows on which monitor is the cursor, while xterm is nevertheless positioned on Virtual-0, even if cursor is on Virtual-1.

So I'm not sure how to "fix" this, in that the solution is to specify the monitor you want, but I'm sure we could do better than that.

Even when I specify monitor (see attachments, $0 is monitor name), xterm goes on the wrong screen.
f_TestSDP3.txt
f_TestSDP4.txt

[NsCDE]

Hi Thomas,

Important! New discovery:

After logging out and in, configuring second monitor again, this behaviour where all windows are put on Virtual-0 stopped.

This should be treated as a glitch, maybe some bad interaction with Xorg or some other fvwm3 bug which should be triggered again to be confirmed.

Nevertheless, problems with "Wait XTerm" in global DesktopConfiguration mode when going from desk 0 to desk 1 remains. Since f_TestSDP version with xterms with unique resource ID doesn't trigger this behaviour, my assumption is that "Wait" in fvwm3 (global) somehow "sees" xterms from the desk 0 on desk 1 as if they just appeared and "Wait" breaks, all xterms are fired even before GotoDesk, GotoPage, or GotoDeskAndPage can be finished.

Additionally, page numbers are again incorrect. xterm for page 1 1 ends up on 0 0, 0 1 on 1 0, 0 0 on 0 1, and 1 0 on 1 1. Tested with f_TestSDP3 attached above. In per-monitor mode, pages are correct. I'm using 2x2 page matrix.

Moreover, in DesktopConfiguration per-monitor, f_TestSDP now simply dies after filling desk 0, and first page (0 0) of desk 1. Tried logging out and in, same thing. Pager occasionally segfaults (will fill separate issue when I catch more time).

P. S.
This ta/gh-22 has some new problems with geometry. On "Restart" my FvwmButtons based Front Panel is positioned in upper left corner instead where it's geometry specifies. Subpanels from the main FvwmButtons are not visible when popped up.