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 <allbery.b@gmail.com> wrote:
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