I don't see the point in extending Xmonad to do this. I have a ton of items bound to keys for Amarok (vol up/down, next/prior, del, start/stop) all via shell scripts: , (( mod1Mask .|. controlMask, xK_Left ), spawn "/home/rladams/.e-scripts/amarok_control.sh prev") , (( mod1Mask .|. controlMask, xK_Right ), spawn "/home/rladams/.e-scripts/amarok_control.sh next") , (( mod1Mask .|. controlMask, xK_Up ), spawn "/home/rladams/.e-scripts/amarok_control.sh volumeUp") , (( mod1Mask .|. controlMask, xK_Down ), spawn "/home/rladams/.e-scripts/amarok_control.sh volumeDown") , (( mod1Mask .|. controlMask, xK_space ), spawn "/home/rladams/.e-scripts/amarok_control.sh playPause") , (( mod1Mask .|. controlMask, xK_x ), spawn "/bin/sh -c \"/usr/bin/dcop amarok playlist removeCurrentTrack ; /home/rladams/.e-scripts/amarok_control.sh next\"") , (( mod1Mask .|. controlMask, xK_z ), spawn "/bin/sh -c \"/usr/bin/dcop amarok playlist togglePlaylist || /usr/bin/amarok\"") $ cat amarok_control.sh #!/bin/sh { MYPREFIX="" . ~/.keychain/${HOSTNAME}-sh [ -f /home/rladams/.washu_amarok ] && MYPREFIX="ssh washu DISPLAY=:0" $MYPREFIX /usr/bin/dcop amarok player $1 } > /home/rladams/.e-scripts/amarok_control.log 2>&1 I hope someone finds these useful. On Thu, Jun 18, 2009 at 07:05:43PM -0400, Brent Yorgey wrote:
On Thu, Jun 18, 2009 at 08:30:20AM -0400, wagnerdm@seas.upenn.edu wrote:
This is probably something of a controversial patch: it adds two dependencies. I don't think the "parsec" dependency is a big deal, since that comes with GHC, and we can therefore expect most users to have it already. The other dependency is the "split" package. Let me know if you want me to just pull in the definition of the particular splitting function I'm using.
+ build-depends: mtl, unix, X11>=1.4.3, xmonad>=0.8, xmonad<0.9, utf8-string, parsec, split
Hmm. I'm not sure how I feel about the extra dependencies. (Literally---I'm not using "I'm not sure how I feel" as a euphemism for "I don't like it"). But I thought I should point out at the very least that writing 'parsec' with no version constraints is just asking for trouble--versions 2 and 3 (which both occur in the wild) aren't quite compatible. I don't imagine the API of split changing much, but just to be safe it's probably a good idea to put version constraints on that too, something like split >= 0.1.1 && < 0.2. It's just good practice to put version constraints on things--in fact, word has it that at some point in the not-too-distant future Hackage will stop accepting packages that don't specify upper bounds on their dependencies. see
http://haskell.org/haskellwiki/Package_versioning_policy
-Brent _______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
------------------------------------------------------------------ Russell Adams RLAdams@AdamsInfoServ.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint: 1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3