XMonad.Actions.Volume
I've written a module to interface with the command-line utility "amixer". It tries to be relatively smart about dealing with devices with lots of different controls, and has a fallback interface for when smart is wrong. It includes a full parser for amixer's output, as well, though currently it only reports two aggregate statistics: total volume among all channels and mute-ness. 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. Cheers! ~d
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
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
Quoting Russell Adams
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:
You're right. The actions themselves aren't that interesting. For amixer, you don't even need a shell script for changing the volume, just spawn "amixer Master 10%+" or "amixer Master 10%-" to raise or lower the volume, respectively. What's interesting about the module is that it returns the result of the change to the caller. The idea is that you can then connect this to an OSD. Daniel Schoepe already showed an example for osd_cat, and I plan on making something for ghosd as well in my copious free time. ;-) Cheers, ~d
Quoting Brent Yorgey
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
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
Right, the more I think about it, the more I recognize that extra dependencies of any kind could be a problem for xmonad-contrib. I recognize that the target audience includes non-Haskell people who can't really be expected to (and shouldn't really have to) understand the Haskell library landscape. On the other hand, the library landscape is there precisely so that people who do know Haskell can use it. =) I haven't decided what I want to do about this yet. The way I see it, I have two choices if I want to publish this for other people to use (and in either case, the patch I sent previously should not be applied): 1. Rip out code from Data.List.Split and convert the Parsec stuff to ReadP. This sucks because I'd have to waste time rewriting the code, it would make me feel icky to duplicate code from other libraries, and it wouldn't really settle the issue for people who want to write contributions in the future that depend on libraries with less obvious counterparts. 2. Publish a separate package. This sucks because it means it wouldn't be in the "blessed" collection of code we call xmonad-contrib; people would be less likely to find it, they would waste more time duplicating it if it was something they wanted, and they would file fewer bug reports. I am open to suggestions. ~d
wagnerdm@seas.upenn.edu wrote:
Right, the more I think about it, the more I recognize that extra dependencies of any kind could be a problem for xmonad-contrib. I recognize that the target audience includes non-Haskell people who can't really be expected to (and shouldn't really have to) understand the Haskell library landscape. On the other hand, the library landscape is there precisely so that people who do know Haskell can use it. =)
I don't think that common libraries such as parsec would be that much of a problem as a dependency. Almost all users install xmonad either via cabal-install or their package manager. In the first case, cabal will take care of the extra dependencies without any required user interaction. If the user uses the package manager, it should be up to the maintainers to also provide a package for, say, parsec, which is not that much to ask, when the package is widely used, as it is the case with parsec. Also, such a package would not take that much effort to create, since cabalised Haskell packages don't differ much in terms of installation and they already packaged xmonad, so it should be just a matter of changing a few URLs in the package building process. If the maintainers provide such packages, it would be no more trouble for the user than installing another "ordinary" package as a dependency.
participants (4)
-
Brent Yorgey -
Daniel Schoepe -
Russell Adams -
wagnerdm＠seas.upenn.edu