Desktop Names wrongly reported by wmctrl under fvwm3

[NsCDE]

Hi!

I have found another one.

Upfront Information

Please provide the following information by running the command and providing
the output.

• Fvwm3 version: current master (17. 4. 2021.)

• Linux distribution: Fedora 33

• Platform: Linux x86_64

Expected Behaviour

[rjeremy@testbox9 ~]$ wmctrl -d
0  * DG: 3840x2400  VP: 0,0  WA: 0,0 1920x1114  Papaya
1  - DG: 3840x2400  VP: 0,0  WA: 0,0 1920x1114  Mango
2  - DG: 3840x2400  VP: 0,0  WA: 0,0 1920x1114  Kiwi
3  - DG: 3840x2400  VP: 0,0  WA: 0,0 1920x1114  Passion Fruit

Actual Behaviour

[rjeremy@testbox9 ~]$ wmctrl -d
0  * DG: 3840x2400  VP: N/A  WA: N/A  Papaya

DesktopConfiguration mode diesn't matter.

What should have happened, but didn't?

List of all virtual desks, not just up to the current one. That is, if I run "wmctrl -d" on desk 1, I will get two lines:

[rjeremy@testbox9 ~]$ wmctrl -d
0  - DG: 3840x2400  VP: N/A  WA: N/A  Papaya
1  * DG: 3840x2400  VP: N/A  WA: N/A  Mango

... if I go to the last one (desk 3 in this case), I will get them all. Going back to 2, 1 or 0 again narows this list.

This is maybe normal or legal behaviour in FVWM3, but in FVWM2 it was for sure not like that. If this is not a bug, there should be some notice about this list beeing dynamic.

Steps to Reproduce

The usual ... NsCDE current master on fvwm3, install wmctrl tool, run it with "-d" to show desktops.

Does the problem also happen with Fvwm2?

No.

Does Fvwm3 crash?

No.

P. S.
Additionally, as I see now, viewport info and resolution info is also missing under fvwm3.

[ThomasAdam]

Hi @NsCDE

Indeed. Can you pleae try ta/gh-477 for me?

One side-effect of this (although I'd argue it is correct in this case), is that if you have per-monitor mode set, the _NET_CURRENT_DESKTOP value will change to reflect the desktop which has the focused window on it -- so, if this will keep updating _NET_CURRENT_DESKTOP correctly, as you pass through monitors which different desktops.

The EWMH is not at all clear about what to do here -- then again, this entire model of having different desktops per monitor is breaking the EWMH to begin with, but it's become so common across different WMs that it does need considering. But most other WMs are not EWMH-compliant...

You can see for yourself what I mean though, just start a terminal on a screen, and run: xprop -root -spy | grep _NET_CURRENT and move the window between screens... the _NET_WM_DESKTOP Atom updates accordingly.

[NsCDE]

Hi @ThomasAdam

Yes, it works now properly in global mode. You solved what I initially reported as a bug in this issue, but with your comments you opened Pandora's box of other inconsistencies now. :-)

Your observations for per-monitor are correct. There are some inconsistencies here. For example, if I'm in per-monitor and have two monitors, one Virtual-0, one on Virtual-1, terminal on each, wmctrl and xprop will NOT so easly switch from desk 0 to desk 1. I need to produce some movement: move or start app windows or walk desks on the monitor, before _NET_CURRENT_DESKTOP is refreshed - changing window focus does not change _NET_CURRENT_DESKTOP. OTOH, FvwmIdent always knows for every window where it is without omission while testing this.

What is really interesting, if I have desk 0 active, change desk on monitor Virtual-1 back and forth, _NET_CURRENT_DESKTOP gets updates. But on primary Virtual-0, and output from xprop and wmctrl on focused terminal this is not the case.

[ThomasAdam]

Your observations for per-monitor are correct. There are some inconsistencies here. For example, if I'm in per-monitor and have two monitors, one Virtual-0, one on Virtual-1, terminal on each, wmctrl and xprop will NOT so easly switch from desk 0 to desk 1. I need to produce some movement: move or start app windows or walk desks on the monitor, before _NET_CURRENT_DESKTOP is refreshed - changing window focus does not change _NET_CURRENT_DESKTOP. OTOH, FvwmIdent always knows for every window where it is without omission while testing this.

You'll find these inconsistencies in other WMs which operate in this way -- spectrwm will have this problem, for example. The issue here is that wmctrl has no notion of the monitor you mean to use when you say wmctrl -s 1 -- desktop 1 on which monitor? There's no information FVWM can use to even determine this.

I could intern an XAtom to track the current monitor and use that, but that's going to lead to other inconsistencies as well, so I think I'll avoid it for now.

What you're seeing here is what I said earlier: per-monitor mode breaks EWMH for all WMs which operate like it.

I'm happy with the fix I've provided and I'll merge that.