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.

[ThomasAdam]

Hi @NsCDE,

I hope you're well and sane! Have you recovered (as much as one can in such circumstances) from the earthquake? Bloody awful timing given how the world is having to deal with Coronavirus as well. :/

I've pushed some further commits to ta/gh-22 which I think helps the problems you were having where the Wait command seemed to be ignored. This was happening because when a MapEvent was received, we were (sometimes) looking at the wrong monitor, which meant that sometimes a grab on the pointer didn't always take place.

So now, using f_TestSDP3.txt, if I do:

f_TestSDP3 HDMI1

Where HDMI1 is the screen where the XTerms will end up, but my pointer is on a completely different monitor, then get XTerms are placed properly.

If though, I do:

f_TestSDP3 HDMI2

Where HDMI2 is the current monitor (but not the monitor the XTerms will end up being placed on), then all that happens is that the GotoPageAndDesk commands operate on HDMI2 correctly, and all the XTerms start up on the same page on HDMI1.

This is expected bahviour. One approach to this would be to do:

Style XTerm InitialMapCommand MoveToScreen HDMI2

Which would then mean the XTerms are placed correctly on each page for HDMI2.

Please give this your usual thorough testing which you've been so good and supportive of. I really do appreciate it!

With regards to the FvwmButtons observation, I've not seen that yet -- if that's still happening for you, let me know and I'll install NsCDE and take a look. But I'm really keen to make sure that the per-monitor per-page stuff is looking OK.

There is a slight bug at the moment with Recapture -- but I'll fix that in a bit, and it's separate to your testing anyhow.

Cheers again,
Thomas

[ThomasAdam]

Hello,

So, in addition to what I put in #24 (comment), the following other changes have happened:

• Removed deprecated Recapture and RecaptureWindow commands;
• Various changes to how windows are managed across restarts of FVWM3;
• Fixed page handling arguments, so that the correct monitor is referenced;
• Removed debug;

I've tested a few versions of your f_TestSDPx scripts, and they seem to be working OK for me. This also includes when DesktopConfiguration is set to global or per-monitor.

Please break it and let me know the results!

[NsCDE]

Hi Thomas,

There were some pros and cons in that having stongest earthquake in 140 years with corona quarantine. Many waiters preparing terraces in the old town center would be injured or dead from ornaments falling from the buildings, but since all this was closed just 3 days before the earthquaqe in all country, this was a lucky occurence. Only 1 person died and 20 were injured ... which is unbelivable small for he city of 1 million. Things are fixing slowly ... it could be worse seizmoligists said. Now we are probably ok for next century and have the chance to use better materials than 19th century Austria-Hungary "K und K" monarchy architects. :)

Let's go to the bussines:

f_TestSDP3 is using not only new GotoDeskAndPage syntax with monitor name, but also starting xterm with "-name ID-$[desk.n]-$[page.nx]-$[page.ny]" to ensure every desk/page combinations gets unique X resource name, and this is waited for. If I try it with "old" f_TestSDP, it fires up everything after passing desk 0 on the second monitor as usual.

Important finding:

I have suspected this days something ... and tried this test function with fvwm2.

1. It exercises exactly the same behaviour with "Wait XTerm" as on fvwm3 - fires up everything after finishing desk 0.

2. If started as f_TestSDP3 (with class name ID-$[...) and of course old syntax for gotos, all windows end up on the primary screen too. No matter if pointer is on the second $[pointer.screen]. Of course, if I use "Style * StartsOnScreen c" then windows are on the pointer screen, but you told me some months ago to remove that on fvwm3, can't remember on which debugging occasion.

3. Walking desk and pages, waiting for unique class ID's is making windows appear on the wrong pages while two monitors are active and configured. When in one monitor mode, everything works as expected.

Now, this means two things:

1. This is not fvwm3 bug. This with "Wait" for a name which already exists on page/desk is old behaviour, but was never triggered until now.

2. I have created f_TestSDP to test fvwm3 behaviour with desks and pages in different configuration modes, but in the process, triggered some old unusual behaviours which may be bugs.

Now you should decide what to do with this: should we debug this situation anyway, or revert on manual (or invent different function for) testing (opening windows) without f_TestSDP in the future?

I'm attaching that version of f_TestSDP6
TestSDP6.txt

P. S.
FvwmButtons position: It is a double problem. This is my Geometry line for FvwmButtons:

PipeRead 'echo "*FrontPanel: Geometry 1015x79+$(($[infostore.lscrn.$[pointer.screen].width] / 2 - 1019 / 2 - 2))-0"'

This expands nicely on FVWM 2.6.X, but fails on FVWM3. On full HD screen $[infostore.lscrn.$[pointer.screen].width] expands to 1920, then it is further divided, so in any resolution, I get FvwmButtons/FrontPanel in the middle bottom of the screen.

If I remove nested infostore definition (BTW, this nesting works nicely across FVWM), and hardcode number that will come there, I still don't get it where it shoud be. It ends up someware over the top. I can get it again back with one keybinding (Ctrl+Escape) which between other things makes "Move screen c 50-50w -0p ewmhiwa". This started on fvwm3 approx ... some month ago.

[NsCDE]

Hi Again,

I saw your next comment when I alredy send the past one. :) I have started to write it yesterday and didn't had a chance to finish it until few minutes ago.

Please see my findings. In the meantimem I'm going to fetch your new commits, recompile and test.

[NsCDE]

In global ConfigurationMode page numbers are now totally correct. Perfect with no omission on all 4x4 pages! This solves not only fvwm3, but even older problem.

• In "Wait ID-$[desk.n]-$[page.nx]-$[page.ny]" with xterm -name Virtual-0 is filled as expected.

• Virtual-1 is not respected, everything ends up on Virtual-0, but I suspect this can be something with pointer grabbing on virtualized displays. I have tried also putting GotoDeskAndPage $[pointer.screen] X Y Z after Wait, but my pointer went alone on Virtual-1. I will investigate further if I can get into full mouse grab mode and re-test.

• In "Wait XTerm" mode, old story here still.

P. S.
For a FvwmButtons, I must investigate. If I close it and re-open manually with
FvwmCommand 'Module FvwmButtons FrontPanel' it ends up where it should be. It is ok on start, only on restart it ends up someware above the screen. I don't have anything for meddling with this in RestartFunction ... never mind. Let's get desk/page sorting first. :)

EDIT:
FYI in per-monitor mode, it behaves exactly the same. Everything is placed on Virtual-0.

[ThomasAdam]

Hi @NsCDE

I'll take a look at FvwmButtons via #28 as it will be the same problem whereby parameter expansion wil be using the wrong monitor, and I don't yet have a good solution for this.

This is why TestSDP6 is failing -- if you stop using unique names for XTerms and use:

+ I Wait XTerm

... that should help. Also, don't forget that if you're expecting those XTerms to be on a different screen to where the geometry string is going to put them, you will have to use:

Style XTerm InitialMapCommand MoveToScreen <some_screen_name>

This is what's working for me (or seems to be).

As far as the behaviour of the Wait command goes on fvwm2, thank you for checking that. I suspect this fails because of how events from X11 are now being sent -- it's possible this has changed recently.

@NsCDE -- please can you itemise the things which I need to look at and fix? I'm starting to drown a little with all the information, and want to make sure I don't miss anything. Perhaps you could use a markdown table or something?

Cheers,
Thomas

[NsCDE]

Hi Thomas,

Ok, let's make some order here. You are right, I'm mixing couple of things in this issue as I find them on the fly. Let's continue with FvwmButtons geometry on restart at #28 and I can tell you that focusing problems dissapeared in latest ta/gh-22, so let's focus on desk and page dance.

Current state of the things:

• If I stop using unique names for XTerms and Wait for XTerm, they fail after passing desk 0 and put everything on one page. Either on fvwm3 or on fvwm2. Tried that again right now.

• You are right: X geometry string had +32+32 on the end. When position arguments are removed, everything comes on the screen where $[pointer.screen] is. This was placed just to have all xterms uniformly placed near the upper left corner, but I didn't counted on screen impact with this. It should be nice if "StartsOnScreen c" style is respected again.

• Pages are still failing a bit: they are correct for desk 0, but after going on desk 1, xterm for page 0 0 ends either on page 0 1, or page 1 0 - 0 1 more often.

Here is the video: https://youtu.be/FYtarL29488

• f_TestSDP6 is using unique names and -geometry 88x6 without position arguments. All is well for Virtual-0 and for Virtual-1 only xterm for page 0 0 runs away. See preview on the "global" FvwmPager.

• f_TestSDP7 runs xterms without -name argument and Wait-s for "XTerm". After desk 0, thigs are failing, I end up on desk 0, page 00, and all xterms are fired up there.

[ThomasAdam]

Hi Thomas,

Hello!

Ok, let's make some order here. You are right, I'm mixing couple of things in this issue as I find them on the fly. Let's continue with FvwmButtons geometry on restart at #28 and I can tell you that focusing problems dissapeared in latest ta/gh-22, so let's focus on desk and page dance.

OK, thank you. That's encouraging. Although FvwmPager largely works, there's still a few other things which #44 will need to be addressed by. I'm going to close #22 for now.

Current state of the things:

* If I stop using unique names for XTerms and Wait for XTerm, they fail after passing desk 0 and put everything on one page. Either on fvwm3 or on fvwm2. Tried that again right now.

OK, that's interesting, as I cannot reproduce this behaviour at all. It's working fine for me on both my main computer, and a dual-head setup in virt-manager. If you say this is happening in fvwm2, then it's an existing bug I need to look at, but not something that's going to block fvwm3's 1.0 release.

As an aside, @NsCDE -- can you also try your script (f_testSDP6000000 :P) using StartsOnPage only (so no more "GotoDeskAndPage` commands), to see what the behaviour is? The coupling of:

+ I Exec foo
+ I Wait foo
+ I GotoPage ....

is rather old-fashioned, and most people will be using:

Style foo StartsOnPage x y z, StartsOnScreen ABC

Potentially, with SkipMapping as well. Certainly, this will side-step this bug with Wait,

* You are right: X geometry string had **+32+32** on the end. When position arguments are removed, everything comes on the screen where $[pointer.screen] is. This was placed just to have all xterms uniformly placed near the upper left corner, but I didn't counted on screen impact with this. It should be nice if "StartsOnScreen c" style is respected again.

StartsOnScreen $[pointer.screen] should work in place of the old c syntax.

* Pages are still failing a bit: they are correct for desk 0, but after going on desk 1, xterm for page 0 0 ends either on page 0 1, or page 1 0 - 0 1 more often.

Strange, as I can't reproduce this. Once the window is on the page, it's all good, and I don't see windows being moved incorrectly or incorrectly assigned.

Here is the video: https://youtu.be/FYtarL29488

So what I notice here is when one of the windows is put on the wrong page, it's probably because of the Wait bug we've seen -- so I'm hoping a combination of StartsOnScreen and StartsOnPage will help here.

So, just to summarise:

• Wait doesn't work well on fvwm2 and the same observations from using Wait with fvwm3 apply to fvwm2 -- there's an existing bug which will need looking at, although in my own testing, the impact seems low.
• StartsOnPage and StartsOnScreen styles (possibly with SkipMapping) should work well.
• When using an X geometry string: 80x24+32+32, that's an absolute position, and this means the window could end up on a different monitor to the current monitor. This means:
  • Commands that use the current monitor (GotoDeskAndPage for example) won't match where the newly-placed window is. This isn't a bug, but I suppose it could be improved somehow.
  • Parameter expansion $[vp.width] when expecting that to work on a specific window, won't work, as a lot of the parameter expansions assume the current monitor which could be different from the monitor the newly-placed window is on.

I think that:

1. I'm going to ignore the Wait bug for now;
2. The bug about parameter expansion is different from window placement, and needs logging as a separate bug;
3. If the use of StartsOnPage, etc., works well (for both global and per-monitor) then I will declare this bug closed, and the state of ta/gh-22 will be merged to master.

@NsCDE -- I don't want to push too much on to you, but are you happy to rewrite a script that uses StartsOnPage and StartsOnScreen instead of using Wait and GotoDeskAndPage? I'm happy to file a new bug about parameter expansion.

[NsCDE]

I have wrote f_TestSDP8. :)

It avoids Wait bug, but with the effect of segfault if ommiting SkipMapping. Even in one-screen mode. If defined in Style, It even crashes while running older versions of f_TestSDP (with goto's) as soon as it finishes desk 0 - on the same action/place as "Wait XTerm", but it doesn't fire up all at current page, but crashes fvwm3. SkipMapping covers/masks this crash.

I will fill new issue, but first let me comment other things in this issue:

• f_TestSDP8 works as you expected, no error (with SkipMapping)

• Style StartsOnScreen $[pointer.screen] has an effect like "StartsOnScreen p": all windows end up on primary monitor. Even if manually executing vim, file manager etc ... looks like macro is not expanded in style and "p" from $[pointer.screen] is read.

• For reporoducing Wait omission on desks 1-3, but not 0, this probably has something with setup of FVWM Style or other things in NsCDE. I should try this with more/less default fvwm setup with 4x4 desk/page matrix to see if this happens too. Don't have time to do it right now, will come back after some boring meeting on work ... and to fill crash issue ... it is something about BroadcastNewPacket and BroadcastConfig ...

f_TestSDP8.txt

EDIT: f_TestSDP8 is without SkipMapping on Style commands.

[ThomasAdam]

Thanks,

I've pushed a fix for FVWM3 segfaulting when DesktopConfiguration global was set.

I'll take a look at the other issues. Thanks for f_TestSDP8.txt! :)

[ThomasAdam]

Hi @NsCDE,

So, I think I have solved the problem of StartsOnScreen $[pointer.screen] not working. Here's the fix you'll need to use in your fvwm2rc file...

Style foo StartsOnScreen $$[pointer.screen]

This makes FVWM3 now expand $$[pointer.screen] twice, once when FVWM expands it for the Style command, and once more when we use the StartsOnScreen value.

Please update your git repo in the usual way and give things another test, if you can.

For reference, this is commit 211a17f

[NsCDE]

Just be careful when intepreting data from f_TestSDP8: info aboud desk and pages after DYNAMIC word in xterms is false. This is expected with StartsOn* vs Goto* approach as I understand.

BTW, there is a strange behaviour of f_TestSDP8 with per-monitor desktop configuration: with pager and with firing xterms on second monitor. I will fill another issue ...

EDIT: coming with 211a17f ...

[NsCDE]

That's it. StartsOnScreen is correct.

P. S.
Shouldn't "c" argument of StartsOnScreen remain for configuration compatibility, since it served for the same purpose in fvwm2?

[ThomasAdam]

That's it. StartsOnScreen is correct.

Finally!

P. S.
Shouldn't "c" argument of StartsOnScreen remain for configuration compatibility, since it served for the same purpose in fvwm2?

Maybe. I'll think about it.

So, @NsCDE -- given all of your really thorough testing (which I can't thank you for enough!), are there any further problems with window placement, either with global or per-monitor that you can see?

Are there any major things I've not addressed yet here? If not, I'll move on to fixing FvwmPager...

[NsCDE]

Wait behaviour will probably Wait (!) some time since it exists obviously for long ago, so I think approach with StartsOn* proved that behaviour in global mode is now ok.

In per-monitor mode, it behaves well as well. There are some glitches here and there, but I think we can address them one by one as time comes for that. :-)

[ThomasAdam]

Shouldn't "c" argument of StartsOnScreen remain for configuration compatibility, since it served for the same purpose in fvwm2?

Maybe. I'll think about it.

See: 8709aaf

(Not tested this, but it looks correct. :P)

[ThomasAdam]

Wait behaviour will probably Wait (!) some time since it exists obviously for long ago, so I think approach with StartsOn* proved that behaviour in global mode is now ok.

Yes. I suspect moving to XCB would help here as well, but that's a larger task.

In per-monitor mode, it behaves well as well. There are some glitches here and there, but I think we can address them one by one as time comes for that. :-)

Cool. In my daily use of this branch it's generally been OK.

I'll merge this to master soon, and close this bug off -- and we can move on to other fun bugs. :)

[NsCDE]

1: 8709aaf - yes, this looks like good compatibility alias :) Looks simple, but I tested it anyway. It is ok.

2. while global mode is more fvwm2 style multi screen environment, per-monitor mode gives more powerfull impression. Of course, when FvwmBacker will be aware of that mode, It will not be so confusing anymore. Not once, I found myself in "WTF..." while testing things, and then "... oh I'm in per-monitor mode" - because backdrop from desk on one screen changes on second, as in global mode. :)

[ThomasAdam]

OK, thanks. Closing this now, as ta/gh-22 merged to master.

Please open additional issue(s) around any broken functionality.