Does not work with devilspie about bspwm

[baskerville]

Thanks for the report of your investigation.

If you're using OpenJDK, your can drop wmname and add the following:

export _JAVA_AWT_WM_NONREPARENTING=1

to /etc/profile.d/jre.sh.

[baskerville]

I'm unable to reproduce.

Both devilspie and devilspie2 perceive current and new windows.

Here's what I've used for devilspie:

devilspie /etc/devilspie/example.ds

And for devilspie2:

devilspie2 -d -f foo

where foo is a directory holding one file: foo.lua which content is:

debug_print("Window Name: " .. get_window_name())

[Stebalien]

Still happening however, this bug appears to affect any application that uses libwnck not just devilspie. Also, if I stop bspwm, start awesome, stop awesome, and then start bspwm, this bug disappears.

Here is the simple python script that listens for window_open events, in case you are interested:

#!/usr/bin/python2

from wnck import screen_get_default
from gobject import MainLoop

def test(*args):
    print "event"

ml = MainLoop()
s = screen_get_default()
s.connect('window_opened', test)
ml.run()

[baskerville]

(The above script works for me.)

What you might do is to store the output of xprop -root when the above script fails and when it succeeds.

And paste diff output_fails output_succeeds here.

Could you also paste your autostart?

[baskerville]

It seems libwnck relies on _NET_CLIENT_LIST and _NET_CLIENT_LIST_STACKING to detect new windows.

[baskerville]

Maybe you could run xprop -root -spy _NET_CLIENT_LIST while testing the script to see if the property evolves correctly?

[Stebalien]

I found the problem: I was running wmname to set the window manager name to LG3D (awesome/java fix). wmname appears to add _NET_SUPPORTING_WM_CHECK to the root window.

_NET_CLIENT_LIST works as expected.

[Stebalien]

http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2731172

[baskerville]

Does the Java fix requires _NET_SUPPORTING_WM_CHECK?
I.e.: isn't bspc set wm_name LG3D enough?

[baskerville]

http://lists.suckless.org/dev/1201/10649.html

[Stebalien]

The main issue here is not the java bug but the fact that calling wmname under bspwm breaks bspwm but not awesome. While the obvious solution is to just not run wmname, It would be kind of nice to figure out why this doesn't cause any problems under awesome.

[Stebalien]

OK I lied. Running wmname under awesome also breaks libwnck. This wasn't apparent because awesome sets _NET_SUPPORTING_WM_CHECK and I was running wmname before starting awesome. Technically bspwm should set this to be EWMH compliant but it probably doesn't make a difference.

[sampowers]

Working around the java awt blank window bug for non-reparenting WMs such as bspwm does in fact appear require _NET_SUPPORTING_WM_CHECK to be set to the root window as wmname does.

_NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0x800000 is what bspwm does
_NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0x260 is what wmname does, that refers to the root window i believe.

Without _NET_SUPPORTING_WM_CHECK set in this way, java apps only show empty windows. The reason for this... is a mystery.

I compiled a version of wmname with the _NET_SUPPORTING_WM_CHECK modification line commented out, leaving _NET_SUPPORTING_WM_CHECK at the bspwm value, ran jmeter, empty window. Then I ran the unmodified wmname where it put the property back to the root window, ran jmeter, no empty window.

[sampowers]

Thank goodness that patch was put into openjdk, and that's probably the way forward for most people. I am stuck using the aforementioned workaround due to another JDK7 bug.

I apologize for posting this in a somewhat unrelated issue, but want to get the information where other bspwm users can find it. There was another java bug in openjdk to do with input focus that was a real killer. I don't think it's a bspwm problem, but I think other people might run into it.

While _JAVA_AWT_WM_NONREPARENTING=1 flag would get java to paint windows, one could not actually enter text into text boxes once the window was re-focused. When the window was mapped, input focus was correct, but as soon as the window was manually refocused (this now referring to bspwm), all possibility of entering text into the window (text boxes, alt+keys for menus, arrows for navigating in menus) was gone.

Some xmonad users were discussing this particular issue in some detail here: https://code.google.com/p/xmonad/issues/detail?id=177

Some of them had better luck with JDK6 than JDK7, which for me meant going back to a version that didn't have _JAVA_AWT_WM_NONREPARENTING support. Bummer.

If it were possible to make bspwm deal with the focus situation, I would be a happy camper with openjdk 7. The solution was something about compliance to WM_TAKE_FOCUS in the WM_PROTOCOLS window property, which jmeter for example does have, you can see it with xprop.

http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7

XcbUtil does have some support for dealing with the WM_PROTOCOLS atom. What to do with it? I don't know. There may be additional clues here:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=778

[baskerville]

Sam Powers:

If it were possible to make bspwm deal with the focus situation, I
would be a happy camper with openjdk 7. The solution was something
about compliance to WM_TAKE_FOCUS in the WM_PROTOCOLS window property,
which jmeter for example does have, you can see it with xprop.

The relevant part of ICCCM is brought by 387ece3.

Can you confirm that jmeter behaves correctly now?

[sampowers]

Nice! That commit fixes the focus issue with jmeter fedora 18's openjdk. Up and running without the Oracle JVM, thanks.

java version "1.7.0_25"
OpenJDK Runtime Environment (fedora-2.3.12.3.fc18-x86_64)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)

For future generations and the good of mankind, the following information, which is unrelated to the focus issue which is now fixed in bspwm (in 6 hours) and unfixed in xmonad (in years).

This being my second attempt at openjdk7 use... It turned out that I still needed both behaviors of wmname, even with _JAVA_AWT_WM_NONREPARENTING set.

Java, even openjdk7, seems to really need both properties to be set: _NET_SUPPORTING_WM_CHECK (DefaultRootWindow(dpy)?) && _NET_WM_NAME=(LG3D|compiz)

Each property when set on its own was not enough to work around the issue.

Furthermore, the _NET_SUPPORTING_WM_CHECK value set by bspwm (xcb_generate_id(dpy)?) was not workable for Java, only the _NET_SUPPORTING_WM_CHECK from wmname did the trick.

in other words, boo java yay bspwm.