Hi, this is a follow up of the thread started by Zed Lopez[1] on controlling XMonad remotely. Stefan O'Rear proposed a solution[2] and I implemented it[3]. We briefly discussed this solution on the #xmonad channel[4] and I thought some more documentation was needed on the methodology to use to achieve the goal. allbery_b reported that such an approach has been used by Mozilla, so I wanted to find more examples to study. Zed said that it was missing this feature from Ratpoison.[5] BTW, the successor of Ratpoison, Stumpwm is developed in Common Lisp...;-) So I went to have a look at how ratpoison deals with the subject and this is what I discovered[7,8]. This is what happens in Ratpoison: a. the Client (that sends the command): 1. creates w simple window 1 pixel width 2. sets an atom (RP_COMMAND) with a command to that window 3. sets an atom (RP_COMMAND_REQUEST) in the root window with XChangeProperty: this atom carries the first window id 4. waits for a propertyNotify to be sent to this window b. Ratpoison: 1. gets the property of the root window (which will return the id of the window containing the command string) 2. searches the window with the command string and executes the command 3. writes an atom (RP_COMMAND_RESULT) to the window with the command result. This will send the propertyNotify the will unblock the client. A similar approach is also used by Enlightment (see src/comms.c) and its remote shell Eesh (see Eesh.xs). WMII, instead, uses libipx and a Plan9 approach (I must confess I don't know much about P9), while DWM has no remote control capability. Now, attached you'll find two archives. The first one is a simple way of running commands from an external program, without a two way communication. It is basically a refactoring of the patch I've already sent[3]. It is simple and effective. I had no problem running it here. The second archive (xrcRatpoisonWay.tar.gz) instead is the ratpoison implementation: I literally copied the algorithm. And there's is a problem. This code produces an X server crash every now and then. I cannot reproduce it and, no matter how many times I read it, I cannot find a bug in my code. I believe there's something wrong with Xlib.Extras.rawGetWindowProperty (a null pointer?). Indeed if you change in ServerMode.hs: let c' = Just [118,105,101,119,49] --c' <- io $ getWindowProperty8 dpy c win no more crashes. You may also see that the command execution sometimes fails. Is that something that used to happen in Ratpoison too? Anyway it is something I think it is worth to investigate a bit more. And I think I will. BTW, these patches require a vary small modification to XMonad itself. XMonad has just to wait for a propertyNotify event sent to the root window. If that happens a hook is called (I named that hook serverHook). I do not want you to equivocate: I'm not pushing for this patch to be included, but I thought to report here some of the information I was able to gather on the subject. Moreover, as far as I can understand, there's is not so much interest in this feature. But here this stuff proved to be quite addictive...;-) Thanks for your kind attention. Andrea [1] see http://www.haskell.org/pipermail/xmonad/2007-July/001502.html [2] see http://www.haskell.org/pipermail/xmonad/2007-July/001509.html [3] see http://www.haskell.org/pipermail/xmonad/2007-July/001533.html [4] see http://www.cse.unsw.edu.au/~dons/irc/xmonad/2007-07-26.txt [5] http://www.nongnu.org/ratpoison/ [6] http://www.nongnu.org/stumpwm/ [7] see also http://cvs.savannah.nongnu.org/viewvc/ratpoison/src/communications.c?root=ratpoison&view=markup [8] see also receive_command() and execute_remote_command() and related comments here: http://cvs.savannah.nongnu.org/viewvc/ratpoison/src/events.c?root=ratpoison&view=markup [9] http://search.cpan.org/~rbs/Eesh-0.3/