
On Tue, Jul 24, 2007 at 03:44:26PM +1000, Donald Bruce Stewart wrote:
gmane.xmonad.zed2323:
I wrote (in summary):
The thing I'm most missing from ratpoison and wmii is an external api, which makes them extensible from external programs (and any language.)
Are there any plans to offer such an interface in Xmonad in the future?
Donald Bruce Stewart
writes: There's the Command.hs interface in the contrib module, used for some of this. At the moment I don't think there's any plan to embed a scripting language directly in xmonad: far better to extend Commands.hs to say, use ghc-api, to allow arbitrary haskell extension if you want it.
I wasn't referring to an embedded scripting language, but a generic API that would allow external scripts to communicate with Xmonad, both to read its state and to issue commands, like ratpoison's and wmii's APIs do. This would open up scripting in any language. Ease of scripting is what I find to be one of the attractions of those languages, and it'd be great to be able to script Xmonad in a language I already know (thought it's also nice to have the excuse to learn Haskell...)
Have a look at Commands.hs, which is currently used to control xmonad from the shell, but you surely can interact with it any way you want.
Actually, commands uses dmenu synchronously and parses the string in-process. While it would be nice to control xmonad using a socket model, ISTR sjanssen saying { -package X11 is nearly impossible to use with threads, and this is one of the main motivations for XHSB. }. You can kluge around it by adding a handler for root PropertyNotify events on XMONAD_COMMAND and dispatching accordingly, then use xprop to control it; thus embedding the control channel over X11. (Not a small task, but most of the details could be in a re-usable contrib module...) Stefan