October 2007 - xmonad

Remote Controlling XMonad: Cases and Materials
by Andrea Rossato 24 Feb '08

24 Feb '08

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=r… [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… [9] http://search.cpan.org/~rbs/Eesh-0.3/

7 11

darcs patch: WindowNavigation: don't export the confi... (and 1 more)
by David Roundy 19 Nov '07

19 Nov '07

I'm ambivalent about whether this goes into 0.4. It's a pretty peripheral extension, so maybe this should go in so it'll change less on its second stable release. Or we could leave it out. I don't care. The default layout uses an extremely hokey computation of an average of the focussed and normal border colors, but it seems to give qualitatively reasonable colors anyhow. David Sat Oct 13 05:05:24 EDT 2007 Andrea Rossato <andrea.rossato(a)unibz.it> * WindowNavigation: don't export the config constructor and some haddock fixes I told to David I would have taken care of that: instead of exporting the config constructor we export 2 functions: navigateColor and noNavigateBorders. Updated documentation accordingly. Mon Oct 15 12:55:04 EDT 2007 David Roundy <droundy(a)darcs.net> * compute a reasonable navigation color based on focussed color.

3 3

darcs patch: zombie_children
by David Benbennick 10 Nov '07

10 Nov '07

Wed Oct 24 18:10:16 PDT 2007 David Benbennick <dbenbenn(a)gmail.com> * zombie_children Second version. This patch sets SIGCHLD to SIG_IGN, so that any child processes that end will be immediately cleaned up. It also waits on all existing zombie child processes, in case they already exist. I'm not too happy about waitAllChildren; it doesn't seem very Haskelley. I was surprised that the following didn't work: try $ forever_ $ getAnyProcessStatus False False >>= return . fromJust

5 8

darcs patch: code to define a strut-avoiding layout.
by David Roundy 09 Nov '07

09 Nov '07

Hi all, This is an amend-recorded version of my avoidStruts layout modifier, which crashes on my machine (but probably works on 32-bit machines). I've just gotten rid of some of the debug output. David Tue Oct 23 18:00:25 EDT 2007 David Roundy <droundy(a)darcs.net> * code to define a strut-avoiding layout.

3 5

darcs patch: added ppc compile to FAQ
by Kyle Spaans 01 Nov '07

01 Nov '07

Alright, so here's a quick addition to the FAQ, explaining how to compile xmonad if your ghc complains about not being interactive.

2 1

darcs patch: sketch of config/main inversion. (and 3 more)
by David Roundy 01 Nov '07

01 Nov '07

Hi all, Here's a somewhat cleaner version of the main/config inversion patch. I recommend applying this sooner, rather than later, if we are going to make this change, as there are many small things that need to be fixed, which can be more easily accomplished collaboratively. This set of patches only does the very crudest hacks. But as we've discussed on IRC, making xmonad available as a library would be a Very Good Thing, and this is the only attempt we've gotten going so far at getting this working. David Thu Oct 18 09:42:30 PDT 2007 David Roundy <droundy(a)darcs.net> * sketch of config/main inversion. Thu Oct 18 10:00:58 PDT 2007 David Roundy <droundy(a)darcs.net> * make xmonad work with inverted main/config. Wed Oct 24 16:12:50 PDT 2007 David Roundy <droundy(a)darcs.net> * make setLayout a bit more inclusive. Mon Oct 29 11:48:23 PDT 2007 David Roundy <droundy(a)darcs.net> * cleaner version of main/config inversion.

2 2

darcs patch: fix parse error in ToggleLayouts
by Brent Yorgey 01 Nov '07

01 Nov '07

ToggleLayouts.hs: Fix for parse error in pattern match.

3 2

darcs patch: expose dzenWithArgs, dzenUrgencyHookWithArgs (for colo...
by Devin Mullins 01 Nov '07

01 Nov '07

Tue Oct 30 03:24:55 EDT 2007 Devin Mullins <me(a)twifkak.com> * expose dzenWithArgs, dzenUrgencyHookWithArgs (for colors!)

2 1

Removing the X11-extras dependency
by Don Stewart 01 Nov '07

01 Nov '07

I'm about to remove the X11-extras dependency, by merging it into the main X11 library for Haskell. Could people test that the new X11 snapshot builds on their machines? http://galois.com/~dons/X11-1.3.0.tar.gz The brave can even go ahead and edit this xmonad.cabal file to remove the X11-extras dependency, to confirm that xmonad continues to build. Any failures should be reported. Thanks! Don

3 6

Issue 78 in xmonad: Extension state
by codesite-noreply＠google.com 01 Nov '07

01 Nov '07

Issue 78: Extension state http://code.google.com/p/xmonad/issues/detail?id=78 Comment #1 by daveroundy: Note, we could also make other hooks use the same mechanism as Layouts. The Layout mechanism is similar in effect to a writer monad, but with a special-case for when the state doesn't change, so we won't have to redraw the windows if a message doesn't change the layout. This approach seems to work well for Layouts, but I suppose isn't needed for other hooks (as we don't care whether or not they've changed). It also make it pretty easy to write buggy layout combinators, since it's all too easy to ignore that return value. I wonder if perhaps a custom monad would be helpful for Layouts? And whether perhaps we could use a similar approach for hooks? i.e. if we put hooks into a monad that allows them to return a modified hook, wouldn't that be enough? -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

2 1