xfce panel workspace switcher applet loses track of bspwm state

[sampowers]

When bspwm starts up, the workspace switcher will show the layout of windows, but after some window opening and desktop switching, its state becomes inconsistent with bspwm. The worst part is that the applet loses track of what desktop I'm on.

I am curious if this is intended to be part of the EWMH support you added a while back?

Tint2 can show the list of tasks, but is this covered under EWMH as well?

[baskerville]

Could you provide precise instructions on how to reproduce this?

[sampowers]

Sure, I will edit this in a minute with more detail.. I had too many things going on to blow away my session for clean state.

[sampowers]

I was not able to quickly reproduce this! I am so disappointed in me right now. :)

Give me another day or two, this tends to happen more on my work machine than my home machine.

Things that it turned out not to be that I was just about certain of until restarting my x server:

Using the xfce workspace switcher to switch workspaces rather than bspc desktop -f
Starting xfce panel or bspwm in some kind of incorrect order -- doesn't matter which happens first

[sampowers]

Not a bspwm bug, this is something that happens when wmname screws up the value of _NET_SUPPORTING_WM_CHECK. Later on, the xfce pager will check this, and that's what triggers the problem.

When one uses wmname to work around that java blank window problem, it does only two things, one more than necessary, and both are incorrect for a NetWM compliant wm:

1. Sets the root window's _NET_WM_NAME property
2. Points the root window's _NET_SUPPORTING_WM_CHECK at the root window itself rather than the child/anchor window created by the WM (bspwm's motion_recorder).

If it's setting _NET_WM_NAME on the root window, it's assuming the WM is not NetWM compliant. If that's the case, it should not concern itself with _NET_SUPPORTING_WM_CHECK. But it goes ahead and changes it anyway, apparently. That's wrong for a NetWM wm.

IF and only if the WM is net supporting, java will change its behavior re: reparenting based on the value (UTF8_STRING OR STRING) of _NET_WM_NAME on the NET Anchor Window. So we can work around the problem as follows, rather than using wmname:

https://github.com/sampowers/dotfiles/blob/100a4530485ddd36ff8787f9f657f7578983bfc8/bin/java_nonreparenting_wm_hack.sh

This sets the _NET_WM_NAME of the window referred to by the root window's _NET_SUPPORTING_WM_CHECK value. Since xprop cannot always use utf-8, we use a string. Java is OK with this.