xtrace revealed to me that Haskell Xlib was not even sending the event.
After some further inspection of XMonad code they apparently call
Xlib.Event.Sync d False a lot at. I'm not entirely sure why Haskell needs
it as the Xlib pages say it shouldn't be needed but it works when calling
it. xdotool does not seem to use it in it's C code. Is there any reason why
Haskell's Xlib needs it?
On 10 December 2013 19:03, Brandon Allbery
On Tue, Dec 10, 2013 at 12:24 PM, EatsKittens < temporalabstraction@gmail.com> wrote:
where root in the Win record is derived from:
(root, parent, _) <- Xlib.Extras.queryTree d xid;
That looks like it should be the right one, but normally I'd just get the root window of the default Screen.
For what it's worth, I see one issue: setClientMessageEvent does only the basic information necessary for a client message, which is insufficient for the _NET_ACTIVE_WINDOW message. (It's missing the client active window, which in this case should probably be 0 anyway so it may not be an issue that it's missing.)
The code compiles and type checks, it just doesn't... work, it does nothing. Replacing the code with:
raiseWin w = System.Process.rawSystem "xdotool" ["windowactivate", show x] >> return () where { x = xid w; }
Makes it work without errors, inspecting the code of xdotool makes it reveal to use the "_NET_ACTIVE_WINDOW" client message to the root hole? Any idea what I could be doing wrongly, is this the correct root window?
You might use something like xtrace/xscope/xmon to make sure that xdotool and your program are actually sending the same client message.
-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net